spring boot の環境とログ設定

0時に寝て4時に起きて6時に起きた。

spring のプロファイル設定

spring の Profiles の仕組みを使って環境ごとの設定を作る。デプロイは k8s で管理しているため、spring boot の Externalized Configuration の仕組みを使って、環境変数から application.yml に定義された設定を書き換える。k8s は kustomize で管理していて prod, test, dev の3つの環境で任意の設定を記述できる。

問題はログ出力の設定を環境ごとに変えたい。具体的には datadog に連携されるログは構造化ログ (json lines) を、ローカルの開発ではコンソールログをみたい。Log4j Spring Boot Support によると、1つの設定ファイルに複数のプロファイル設定を記述できるようにもみえるけど、実際にやってみたらうまく動かなかった。xml ではなく yml を使っているせいかもしれないし、私の記述方法が誤っているのかもしれない。いずれにしても yml で複数のプロファイルを設定しているサンプルをみつけられなかった。

そこで Different Log4j2 Configurations per Spring Profile をみて、環境ごとにログ設定ファイルも分割することにした。application.yml には次のように記述する。

spring:
  profiles:
    active: dev

logging:
  config: classpath:log4j2-${spring.profiles.active}.yml

ローカル開発向けの lgo4j2-dev.yml は次のようになる。

Configuration:
  status: warn
  name: YAMLConfig
  appenders:
    Console:
      name: STDOUT
      target: SYSTEM_OUT
      PatternLayout:
        Pattern: "%d{yyyy-MM-dd HH:mm:ss.SSS}[%t]%-5level %logger{36} - %msg%n"

k8s のマニフェストで環境変数を次のように定義すれば prod というプロファイルが設定される。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
      - name: my-service
        env:
        - name: spring.profiles.active
          value: "prod"

クラウド環境向けの log4j2-prod.yml は次のようになる。

Configuration:
  status: warn
  name: YAMLConfig
  appenders:
    Console:
      name: STDOUT
      target: SYSTEM_OUT
      EcsLayout:
        serviceName: my-service
        serviceNodeName: null
        includeMarkers: true
        KeyValuePair:
        - key: type
          value: app

暇な一日

23時に寝て3時に起きて5時までだらだらしててそのまま起きた。

タスクがない

開発のロードマップ全体の計画が遅れているのに私のタスクが全くないみたいな状態になっている。昨日、開発のリーダーにタスクがないので適当なタスクをアサインしてくださいとお願いして、すぐアサインされるんだと思ってたら1日待ってもアサインされなかった。現スプリントのチケットはたくさんあるのにアサイン可能なチケットがないのか、アサインしなくても他の開発者で間に合うのか、その両方なのか、開発チームは5人いて、そのうち4人が外部の協力会社になる。私の感覚的には2人は余剰でタイミングが悪いとタスクがないみたいな状況になる。期限までにやらないといけないことは溜まっているのに。

workrooms 雑談

月に1回の はんなりPython メタバース会 #4 に参加した。workrooms で雑談会するのもだいぶ慣れてきた。毎月1-2回はやっている。Brave というプライバシーを重視したブラウザがよいみたいな話しがあって、とくに Brave Talk のビデオ通話がよく出来ているという話しがあった。課金しないと4人まで参加できて、$7/月でプレミアムプランになるみたい。コミュニティ用途なら zoom から Brave Talk に移行した方がよいとまで言ってたので、そんなによいものなのか、また後日触ってみたいと思う。

イベント登壇のススメ

1時に寝て7時に起きた。今日も雨。雨降りの日が増えると春が来たなって感じがしてきた。

cfp のススメ

先日、過去に私が jjug ccc に登壇した資料を紹介していて、そう言えば jjug ccc とかいまぐらいの時期かな?と思って調べたら、ちょうど3月27日が cfp の締め切りになる。「ぼくのかんがえたさいきょうのでぷろい」は java アプリケーション開発の基本には沿っていないやり方なので発表したらおもしろいかもしれないと、slack に軽く書き込んだらわりといいねが付いたので社員さんに cfp 送ったら?と勧めた。その社員さんは島根県在住なのでリモートで登壇できるならいいかも?という話しになってイベントの要項を確認したらオンライン開催なので大丈夫そう。

今日がスクラムのプランニングだったのでチームに共有して業務として cfp を送るための工数も確保した。私が発表してもよいのだけど、なるべく若い人がイベントに登壇すべきだし、業務でやったことはその会社の人が発表すべきだろうというのもあって、私はバックアップにまわって発表は社員さんに任せようと思う。今月末に事例紹介させてほしいという交渉をする予定なので、それがうまくいったら、技術協力として当社のクレジットだけスライドに入れてもらえればみたいところが私の狙い。いずれにしても cfp が採択されないとその展望もないので cfp 作りにも協力していきたい。

github actions の課金金額

2時に寝て何度か起きてだらだらしながら10時に起きた。

gihtub-api-tools のリファクタリングとデータ分析

実際に使ってみながらリファクタリングしたり、足りない機能を追加したりした。ツールに拡張した機能が使えるかどうかの検証のため、お仕事のプライベートリポジトリのデータを使って分析をし始めて、気付いたら分析ならびに分析結果の資料まで作ってしまった。軽く半日ぐらいのお仕事をやってしまっていた。過去5ヶ月分の課金時間の合計を算出し、単体テストの実行を github actions に追加することで増える課金時間の見積もりと金額を算出した。月間でいまより3時間30分、全体の課金時間に対して20%弱程度の追加が見込まれる。それによる課金金額を算出すると 210 * $0.008 = $1.68 になる。いままで無料枠を超えないように運用してきたわけだが、こんな200円程度の金額を節約するために github actions 上でテスト実行しないといった判断がくだされていた。開発者は誰も実際の課金金額を知らなかったし、課金金額を算出するとあほらしくなった。あと github actions はめちゃくちゃ安い。

gihtub-api-tools の拡張

5時に寝て9時過ぎに起きた。昨日は久しぶりに夜更ししてコードを書いてた。

github actions のいろいろな時間の算出

以前作った github-api-tools を拡張して github actions の実行履歴の分析するための機能を作っている。

ひとまずワークフローの実行履歴からジョブのステップの実行時間を積み上げた時間を算出してみた。いくつか API を調べているうちに課金時間は直接 API から取得できることに気付いた。この3つの時間は全然別の意味をもっていて、それぞれの時間は一致しない。

  • ステップ実行時間: ジョブのそれぞれのステップの実行時間の合計
  • 課金時間: 課金対象として数えられている時間の合計
  • ワークフロー実行時間: アクションのワークフローの実行にかかった時間

github actions は public リポジトリに関しては課金対象ではないんやね。private リポジトリ且つ github-hosted ランナーを使っている場合のみ課金対象となるみたい。

workrooms 雑談会をした

0時に寝てたぶん夜中に起きて7時に起きた。

映像研には手を出すな

先日から 見始めて1週間ぐらいかけて12話を見終えた。個人的には4話の そのマチェットを強く握れ! がよかった。最初の4話をみて、この物語の演出や構成の仕組みが理解できて、その後の話しもみてみようという気になった。4話がおもしろかったから8話と12話も期待したんだけど、4話が私の中で一番はまった分だけ、8話と12話は期待し過ぎになってしまった。別におもしろくなかったわけではない。パブリック・エネミー という言葉が出てきて、こんな言葉を使ったことないし、人生で1度は言ってみたい言葉だなと思った。よくよく考えたらクリエイターって既存の価値観に捕われず新しい価値観を創造するのだから、それは従来の価値観や秩序をよしとする人たちからみたら秩序の破壊者にみえることもあって、クリエイターをパブリック・エネミーと呼ぶのはそれほど的外れでもないかもしれないなとか思ったりもした。

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後162cmだった。今週もまったくやらなかったので先週より数値が悪くなった。そろそろ暖かくなってきたし、お仕事も一段落ついて落ち着いたので新たに生活のスタイルも変えていきたいと思う。そうやってさぼっていても週に1回はストレッチを受けられて本当にラッキーだと思う。

workrooms 雑談

てらださんが週末は暇だから Horizon Workrooms をしたいと話しているのをみかけて参加してみることにした。workrooms のよいところの1つとして、現時点では仮想空間内でパソコンを扱い難いので内職をしないことがあげられる。私はもはやパソコンを持ち込まないようにしていて、その場での会話に100%集中している。これが普通のオンライン会議ツールだと、自分が関心のない話題なら個人の作業を始めたり、外部とのインタラクションがあったりするとそれに反応したりする。そういったことをしないためのツールとして workrooms がいいなと思うところもある。これはただの運用の話しだけど。

workrooms で2時間ほど4人で雑談した。メタバースや仮想空間の技術への取っ掛かりの1つとして workrooms を始める人が私の周りでは少しずつ増えていて、徐々にメタバースに関するなにかは盛り上がっていくのかもしれないという雰囲気も出てきている。私の場合、月に1-2回は workrooms で雑談会をするようになってきた。私もただのユーザーではなく、なにかしらツールかコンテンツを作ったりする方に行くべきかもしれないけど、まだまだ他の現実のお仕事でできていないことが山ほどあって傍観している程度。

github actions の改善

0時に寝て3時に起きて6時に起きた。

失敗したジョブの再実行

せらさんのツィートをみかけて調べたら2日ほど前に失敗したジョブからの再実行の改善が行われたらしい。

たまにだけど、i/o エラーみたいな内容で github actions のワークフロー実行が異常終了することがある。そんなときに途中から再実行できるといいなぁとは思っていた。これはステップ単位ではなく、ジョブ単位の実行みたいだけど、それでも途中から再実行できればワークフローの自由度や効率は上がると思う。github actions がどんどん強力になっていくのが楽しみ。あとやぎさんから教えてもらった GitHub Actions 実践入門 も購入した。ある程度触ったところで雰囲気は掴めてきたので体系的に学んでみる。

マージできると開発が楽しい

0時に寝て3時に起きて5時半に起きた。

開発のコミット/マージのルール改定

過去のスクラムのふりかえりをみていて、12月15日にレビューアが1人のため、Pull Request (以下PR) のレビューにかなり時間がかかっているという指摘をしてから3ヶ月かかって、ようやくレビュー負荷が集中していた社員からレビュープロセスの改善の機会がもたらされた。なぜレビュー負荷が1人に集中するかというと、チームの開発者は5人で、正社員1人で他4人は外部の協力会社であるため、正社員の approve なしでマージすることに躊躇するという状況だった。

大幅にレビュープロセスが緩和された。

  • 軽微な変更は PR を作って自分でマージしてよい
  • (所属問わず) 1人以上のレビューアによる apprve があればマージしてよい
  • PO が最終レビューするものは PR レビューアの approve を得なくてもよい

私の作業時間の1/3は PR レビューの待ち時間だったのでこれだけで私の生産性は1.5倍になる。どんどんコミットしていけると開発していて楽しい。

オンライン飲み会

余りまくっている交際費の予算消化も兼ねて前にお手伝いしていた会社のたにがきさんと雑談した。近況を話したりもしつつ、たにがきさんは私が過去に働いていた会社の親会社で働いていて、その時期も重なっていて、その親会社の話しを主にしていた。その親会社は主力プロダクトの完全な作り直しを宣言して、1000億円ぐらい開発費を投じたものの、実際にはプロダクトの作り直しに失敗して、資金繰りが悪化して事実上の倒産をした。親会社の社長はカリスマ社長で新興宗教の教祖みたいな感じだったんだけど、会社がファンドに買収されて、取締役を退任させられて、しばらくは鳴りを潜めていたけど、最近はまた会社を作って精力的に活動しているらしい。近く OB 会のようなイベントがカリスマ社長から呼びかけられているらしく、どう考えてもリクルーティングの場なんだろうと話していた。また1年ぐらいしたら近況報告会をしてもいいかもしれない。

最低1000万件のデータがあると思え

0時に寝て6時半に起きた。

映像研には手を出すな

お奨めされたので 映像研には手を出すな を見始めた。あまり現実と空想が入り交じる展開が新鮮と言えば新鮮だし、ストーリーがわかりにくい気もしてもやもやする。浅草氏も「アニメは設定が命」と言っているし、この設定はどうなの?とか思いながら、それでもみているんだからいいんだろうって感じ?最初はごちゃごちゃしててわかりにくい感じがしたんだけど、見続けていると徐々に独特の世界観に慣れてきたのか、ところどころおもしろいなと思うようにはなってきた。また全話みてから総括する。

サブクエリで group by

お仕事でたまたま触っているところの sql をみたら次のようなものがあった。サブクエリで group by 句を使っている。仮に mytable_detail が1億件ぐらいあったらこんな sql 動くわけがない。データが溜まるごとに遅くなっていって、しきい値を超えると急激にパフォーマンスが悪化する時限爆弾みたいな sql だと思う。お手伝い先は or mapper を使っていないので開発者が sql を手で書いているにも関わらず、こんな sql が実運用されてしまうような開発体制には大きな課題があるなぁとか考え込んでしまった。

SELECT mytable.*, t.is_some
FROM mytable
LEFT JOIN LATERAL (
    SELECT mytable_id, bool_or(mytable_detail.is_some) as is_some
    FROM mytable_detail
    WHERE mytable_detail.mytable_id = mytable.mytable_id
    GROUP BY mytable_detail.mytable_id
) as t on t.mytable_id = mytable.mytable_id
WHERE mytable.foreign_key_id = :foreignKeyId
ORDER BY mytable.mytable_id;

以前、お手伝いしていた会社の CTO が社内の開発者のデータの取り扱いの指針として書いた記事が次になる。社内では 最低 1000万件のデータがあると思ってコードを書けと強く啓蒙していた。いまどきのデータ量として1000万件というのはよい指標だと思う。

フロントエンド開発着手

0時に寝て3時に起きて6時に起きた。やっぱり起きてからドラクエタクトしてた。

フロントエンド開発

デプロイ改善が完了したので新しいタスクに取り組み始めた。もともとこの開発チームはバックエンドもフロントエンドも全部やるというチームなので、やりかけ中のタスクのフロントエンド側の変更に着手して、既存の画面に新規項目を追加するといった作業をやってみた。フロントエンドは vue.js + nuxt で開発している。ビルドに30秒ぐらいかかる。ちょっと遅い。宣言型 ui のよいところかもしれないけど、vue.js も nuxt もまったく触ったことないけど、ripgrep で検索してちょちょっとコピペしたらそれっぽく動いた。これはまさにあれだ。

全然わからない。俺たちは雰囲気で開発している。

動いたらラッキーみたいな感じで PR を作って、たまたまレビューも通って、テスト環境で動いたんでラッキーだった。

平穏な一日

0時に寝て5時半に起きた。一仕事を終えて淡々と前の作業の続きのリファクタリングなどをしていた。

デプロイ改善のタスク完了報告

週末にパイプライン処理の検証やロールバック処理の実装を行った。ドキュメントも一通り書いた。チームの開発者にそれらを説明して3スプリント(3週間)に渡った改善が完了したことを報告した。チケットにすると26、そのうち私が担当したのが22なので、私がイニシアティブをとって完遂させた。github actions を始めとする、github のサービスの理解が深まってそれなりに学びがあった。自分でもいくつかカスタム action を作ってみようと思う。