2023年のお仕事まとめ

2023年のお仕事をまとめてみた。

複雑化するデータパイプラインへの対応

クロスアカウントのリストア

現職では、開発、テスト、カスタマーサポート、データ分析などに使うデータベースを日次もしくは不定期で本番環境から同期する仕組みを整備している。今年は検証環境を独立した AWS アカウントに移行する作業を進めていた。データパイプラインもクロスアカウントに対応した。

本番環境のデータベースには個人情報が含まれるものがあるため、本番環境の AWS アカウント内で個人情報のマスク処理を完結させる必要がある。そのため、本番環境の AWS アカウントでマスク済みの EBS スナップショットや RDS スナップショットを作成し、検証環境の AWS アカウントに共有する構成にしている。以下のはまりどころがあった。

スナップショットの内容は共有されるが、スナップショットのタグは共有されない
AWS Managed Key で暗号化されているスナップショットは共有できない。代わりに CMK (Customer Managed Key) で暗号化し、別のアカウントから CMK へのアクセスを許可する必要がある
EC2 API や RDS API でスナップショットを検索する場合は共有されたものを含めるオプションが必要になる

本番環境の AWS アカウントでスナップショットを作成したら、検証環境の AWS アカウントでスナップショットをリストアする。スナップショットの作成やリストアはもともと Step Functions と ECS Fargate Task で実装しているため、AWS アカウントごとに Step Functions と ECS Fargate Task を配置し、EventBridge を経由して Step Functions が連携する構成にした。以下のはまりどころがあった。

EventBridge を経由してデータを送ることも可能だが、キーの間違いや再実行時の考慮不足などで Step Functions の実行時エラーが多発するおそれがある。Step Functions のエラー詳細は Sentry や Datadog などで捕捉できず、AWS コンソールから調査する必要がある。運用負荷を下げるため、基本的にタスクを冪等にして、入出力の受け渡しのないシンプルな設計にしている。
クロスアカウントでイベントをやり取りする場合は Event Rule や IAM の設定が難しい。あらかじめ練習用の AWS アカウントで試行錯誤してから Terraform を書いた

2023年の春ごろにクロスアカウントのパイプラインが完成した。当初はマイクロサービスのデータベースごとに大量の Step Functions 定義をコピペしてしまったので、後から Terraform module でリファクタリングした。マイクロサービスのオーナーチームは Terraform module の設定値を埋めるだけでよくなったので、認知負荷もだいぶ下がったと思う。

同時に実行できない制約の解消

現職では基本的に Aurora を利用しているが、歴史的経緯で EC2 self-hosted MongoDB も利用している。MongoDB では EBS スナップショットを経由してデータベースをリストアしている。開発やカスタマーサポートなどの環境によってマスク処理が異なるため、複数のスナップショットが必要になる。

これまで1台の EC2 で EBS スナップショットを作成していたため、同時に複数のスナップショットを作成できない制約があった。Step Functions を直列実行することで対応していたが、問題が起きた場合の手動運用が複雑になる課題があった。また、バージョンアップなどで異なるバージョンの MongoDB サーバが混在する状況に対応できない課題もあった。

そのため、一時的な使い捨ての EC2 を起動してスナップショットを作成する実装に改善した。

スナップショット作成処理はもともと ECS Fargate Task で実行しているが、Fargate では EBS スナップショットを扱えない。そこで、ECS Fargate Task から一時的な EC2 を起動し、Systems Manager を利用してコマンドを実行する構成にしている
独自の AMI を用意するとメンテナンスの負荷が発生する。そこで、AWS が提供している AMI に Docker をインストールし、mongo コンテナを実行することで、メンテナンスフリーにしている
Systems Manager や Docker で複雑なシェルスクリプトを流すと実行時エラーが起きやすい。なるべく ECS Fargate Task 側の Go で複雑な処理を表現するようにしている

これにより、スナップショット作成の Step Functions を同時に実行できるようになり、実行を直列化したり、実行時刻をずらすといった変なハックが不要になった。しかしながら、CloudWatch Logs のログが ECS Fargate Task、 Systems Manager、EC2 上のコンテナで分散してしまうため、問題が起きた場合の調査がつらい課題を抱えている。Datadog APM で一連のトレースを可視化して調査しやすいように工夫しているが、今後の改善としたい。

オーナーシップの明確化による運用負荷の改善

現職ではデータ基盤に Airflow (Cloud Composer) が採用されており、Data Engineer がオーナーシップを持っている。データパイプラインで問題が起きるとデータ分析に影響が出てしまうため、Data Engineer だけで速やかに復旧できることが望ましい。しかし、AWS 上のデータベースについては私が所属する SRE がオーナーシップを持っているので、問題が起きた場合のやり取りが複雑になる傾向があった。

そこで、以下の構成に移行することで運用負荷の改善を図った。

データ基盤用のデータベースをリストア/エクスポートする Step Functions を用意し、Airflow から Step Functions を呼び出す構成にする
Airflow の構成は Data Engineer がオーナーシップを持つ。問題が起きた場合の判断や再実行は Data Engineer で完結できるようにしている
データベースをリストアする実装は SRE がオーナーシップを持つ。アラートの調査や継続的なバージョンアップなどの運用を担う

このようにオーナーシップを明確にすることで、問題が起きた場合に Slack 上で速やかに復旧対応を進めやすくなっている。まだ移行できていないデータベースもあるので、引き続き改善を進めたい。

CI/CD パイプラインの改善

actions-runner-controller の移行

2023年5月ごろから新しい actions-runner-controller が Public Beta になった。新しい actions-runner-controller に移行することで、以下のメリットがあった。

オートスケーリングが Pull 方式に変わるため、GitHub Actions のジョブが急激に増えた場合でも安定してスケールアウトできるようになった。現職では大規模な monorepo を運用しているので、開発体験が大きく改善された
オートスケーリングのために GitHub から Webhook を受け取る必要がなくなった

しかしながら、公式で用意されている actions/runner イメージには以下の課題があった。

インストールされているパッケージが最小限になっている。git や build-essentials すら入っていない
Runner と Docker daemon が別のコンテナに分かれている。例えば、テストジョブでは Runner コンテナのリソースが大量に消費されるが、ビルドジョブで Docker daemon コンテナのリソースが大量に消費される、といった不均衡が生じてしまう。Pod のリソース割り当てを最適化するには両者を同じコンテナで実行することが望ましい
当初は arm64 のイメージが提供されていなかった（後に amd64, arm64 の両対応になった）
当初はベースイメージが Debian であった。GitHub-hosted runners は Ubuntu なので環境差異が発生する（後にベースイメージが Ubuntu になった）

現在は独自の runner イメージを用意している。詳細は https://github.com/quipper/actions-runner を参照されたい。

Reusable workflows によるリファクタリング

今年になって Reusable workflows の制限が大きく緩和されたため、抽象化されたワークフローを再利用する構成を採用しやすくなった。現職では、以下のようなユースケースでリファクタリングを進めている。

コンテナイメージのビルド
コンテナイメージの multi-architectures ビルド
言語ごとの共通的な検査（golangci-lint, eslint, standardrb など）
マイクロサービスのデプロイ
Kubernetes クラスタでのジョブの実行

Reusable workflows には認知負荷やメンテナンスを減らせるだけでなくガバナンスを効かせる効果もある。GitHub Actions から AWS にアクセスしている場合、特定の Reusable workflow を経由している場合だけ IAM で許可することも可能だ。デプロイパイプラインのセキュリティ改善を今後進めていきたい。

Buildx への移行

現職ではコンテナイメージのビルドに Kaniko を採用していた。Buildx は特殊なキャッシュマニフェストを採用しているため ECR にキャッシュを保存できないが、Kaniko は通常のイメージなので ECR にキャッシュを保存できる。multi-stage build で効率的にキャッシュを活用できるため、ビルド時間の短縮に大きく貢献していた。

github.com

今年の夏ごろに ECR が Buildx のキャッシュに対応したため、Kaniko から Buildx への移行を検討することにした。Buildx への移行で、キャッシュが効いている場合の所要時間が大きく短縮された。しかし、ECR リポジトリの構成を以下のように変えた影響の可能性もあるので、要因はよく分かっていない。

移行前：イメージと Kaniko キャッシュを別の ECR リポジトリで管理する
移行後：イメージと Buildx キャッシュを同じ ECR リポジトリで管理する

開発体験の改善

Google Cloud Pub/Sub の Kubernetes operator

現職では、一部のマイクロサービスで非同期のイベント連携に Google Cloud Pub/Sub を採用している。Pub/Sub の Topic や Subscription は基本的に Terraform で管理している。Pull Request ごとにデプロイされるプレビュー環境では同じ Topic や Subscription を共有するため、イベント連携がうまく動かない課題がある。ある Pull Request 環境でイベントを流しても他の Pull Request 環境に吸い取られてしまうためだ。

そこで、Pull Request 環境ごとに独立した Topic や Subscription を用意できるように Kubernetes operator を提供している。私は Kubebuilder の開発経験があったが、プロダクトチームで仕事をしていないので開発体験の課題には詳しくない。そこで、プロダクトチームの経験が豊富でかつ Go のエキスパートである同僚と協力して、Kubernetes operator の開発に取り組むことにした。実際にプロダクト開発で Operator を利用してみると以下の課題が見つかった。

マイクロサービスのデプロイと Topic や Subscription の作成は並行で実行される。マイクロサービスの起動時に Topic が存在しない場合はエラーが出てしまう。Crash loop backoff で最終的には起動するが、エラーの通知が荒れてしまう
Topic と Subscription は独立した Kubernetes リソースで定義しているので、それぞれ並行で作成される。Pub/Sub の仕様では Subscription の作成時に Topic がないとエラーになる。Operator の reconciliation loop で最終的には作成に成功するが、Kubernetes events が荒れてしまう。一定時間が経過してもエラーになった場合だけ Kubernetes events に通知することで、アラートハンドリングを改善した

また、Kubernetes や Kubebuilder のバージョンアップで今後も定常的にメンテナンスは必要になる。引き続き mob programming を続けていきたい。