2024年の仕事をまとめてみた。年末に風邪を引いてそのままお蔵入りになっていたが、だいぶ遅れて公開した。
指標に基づく開発体験の継続的な改善
大規模な monorepo で GitHub Actions (self-hosted runners) を運用している。プロダクトチームへのサーベイでは CI が遅いというフィードバックが多数あったが、私は継続的にプロダクト開発に関わる機会がないため、開発体験の改善が後手になっていた。
CI が遅い、flaky といったフィードバックは主観的で漠然としているため、そのままでは解決が難しい。そこで、フィードバックで発見した問題を分解し、指標による継続的な改善を目指すことにした。
テストケースやビルドプロセスの問題
コードベースの肥大化や歴史的経緯によって、スローテストや flaky テストで困っている開発組織は多いと思う。膨大なテストケースに手をつけるためのメトリクスを計測することにした。具体的には、Datadog のダッシュボードで以下のメトリクスを確認できるようにしている。
- テストワークフローの所要時間
- 遅いテストケース
- 最近失敗したテストケース
このようなメトリクスをテスト改善で利用してもらうには工夫が必要そうである。例えば、直近1週間でよく失敗しているテストケースを通知したり、所要時間の長いテストケースのランキングを通知したり、といった広報活動を考えていきたい。
GitHub Actions ワークフローの問題
GitHub Actions のワークフローは
- ワークフローの branches が適切に設定されておらず、不要なブランチで CI が実行されていた
- ワークフローの paths が適切に設定されておらず、テストが必要ない場合にも実行されていた
- ジョブの実行条件が適切に設定されておらず、Dependabot などの bot で不要なジョブも実行されていた
- ジョブが必要以上に細分化されており、ワークフロー全体の待ち時間のうちジョブの起動待ちが支配的になっていることがあった
- 並列テストのジョブ数が不適切に設定されており、無駄に時間がかかったり、失敗の確率が高くなってしまっていた
Self-hosted runners の問題
大規模な monorepo を運用しているため、同時に多数のジョブが実行されることが多い。その結果、self-hosted runners が頻繁に詰まるという問題が頻発していた。しかし、self-hosted runners が詰まるという事象をモニタリングできておらず、何らかの改善策を打っても効果を計測できていなかった。
また、リポジトリによっては Runner のメモリ割り当てが適切に設定されておらず、OOM によるジョブのタイムアウトエラーが多発していた。しかし、何も計測していないので長らく放置されていた。
そこで、以下のメトリクスを取得して、Datadog の SLO で定期的に確認するようにした。
- リポジトリで queued になっているジョブ数（ジョブの event, actor, branch などで集計できるようにしておく）
- actions-runner-controller の startup duration
- コンテナの OOM 発生数
開発フローにおけるトイルの削減と継続的改善
リリースプロセスの省力化
EKS クラスタの運用改善
Blue-green update から In-place update への移行
これまで EKS クラスタのバージョンを更新する時は新しいクラスタを作り直していた。もし新しいバージョンで問題が起きた場合に素早く切り戻せるように考慮していた。しかし、新旧バージョンのクラスタを並行運用することで以下の課題が発生していた。
- バージョンアップの間隔が長くなってしまう
- 新旧クラスタの並行運用期間にマニフェストの変更漏れが起きていた
- 新旧クラスタでアプリケーションが同時に実行されるため、非同期処理などで不整合が起きることがある
- ユーザーに kubeconfig を切り替えてもらう負担が大きい
そこで、同じ EKS クラスタでバージョンを更新していくプロセスに変えることにした。バージョンアップ作業が Terraform で完結するようになり、kubeconfig を切り替える必要もなくなったので、運用のトイルが大きく改善された。
アクセス制御
以前はユーザーのアクセス制御を aws-auth ConfigMap で設定していた。誤った ConfigMap を apply すると本番障害が起きるリスクがあるため、変更の心理的抵抗が高いという課題があった。また、新しいクラスタを構築する手順が複雑になっているという課題もあった。EKS access entries への移行で以下のメリットがあった。
- アクセス制御の設定を Terraform (aws provider) のみで管理できるので認知負荷が下がった
- ノードが利用する権限などを誤って書き換えてしまうリスクがなくなった
- 緊急時でも確実に特権を付与できるようになった
いくつかのコンポーネントについては IRSA から EKS Pod Identity への移行を進めている。IRSA では IAM Role と Service Account で相互に参照関係を設定する必要があるが、EKS Pod Identity では IAM Role から Service Account への参照関係を設定するだけでよいため、認知負荷が大きく下がる。現状では EKS Pod Identity がワイルドカードの namespace に対応していないため、pull request のプレビュー環境では利用できないという課題が残っている。
