バックエンドエンジニアによる Amebaブログ K8s 基盤への CronJobの導入・運用経験

K8sの運用でマニフェスト管理に苦労した経験を持つエンジニアが、Amebaブログで利用する重要システムをK8s基盤へCronJobで導入・運用した体験を解説します。 具体的にはKubeVelaによりマニフェストの実装量が劇的に削減され、FluxCD/ArgoCDによるGitOpsベースの自動デプロイによってどのように開発・運用ストレスが減ったかをお伝えします。 さらに、実際にCronJobの障害に直面した際の対応を共有します。DatadogやAthenaといった高度なオブザーバビリティ環境と基盤チームによるサポートがいかに原因特定と解決を可能にしたかをお伝えします。K8sの導入・運用に課題を持つインフラ/SREエンジニアの方々に、利用者側の生の声と実践知をお届けします。

Transcript

1. バックエンドエンジニアによる Amebaブログ K8s 基盤への CronJobの導入・運用経験 Backend Engineer's Experience with CronJob Implementation 須永大生 1/31
2. 自己紹介 名前: 須永大生 所属: サイバーエージェント Amebaブログ バックエンドエンジニア SNS: X @suna_big 経歴・興味 Go/Java を用いたマイクロサービス開発、レガシーコード刷新 前職では GKE 上で K8s 運用、マニフェスト管理の苦労を経験 SRE、Platform Engineering、生成 AI による仕様駆動開発に興味 自己紹介 2/31
3. Amebaブログについて 1 3/31
4. Amebaブログについて 概要 サイバーエージェントが運営する国内最大級のブログプラットフォーム 2004年サービス開始、20年以上の歴史 著名人・芸能人の公式ブログも多数 技術スタック バックエンド: Go、Java インフラ: AWS（EC2、Lambda等）+ Ameba K8s基盤 データ周り: BigQuery、DynamoDB、Redis 開発体制 マイクロサービスアーキテクチャを採用 複数チームによる機能開発・運用 4/31
5. CronJobで移設した重要システム 2 5/31
6. CronJobで移設した重要システム 以下の3つのシステムをCronJob化しました： 1. ユーザーが利用するアクセス解析 ブロガーが自分のブログのアクセス数を確認する機能 ユーザーに直接見える機能のため、止まると問い合わせが殺到 2. サイトマップ生成 SEO対策に必須のsitemap.xml生成 止まると検索エンジンのクロールに影響 3. 記事ランキングシステム 人気記事ランキングの集計 コンテンツ発見の重要な導線 どれも止まると事業的にダメージのある重要なシステムです 6/31
7. 以前の構成と課題 Step Functions + EMR構成 複雑な構成で属人化が進行 メンバーの入れ替わりで誰もメンテナンスできない状態に 止まったらひたすら再起動するしかない… 移行の必要性 運用負荷軽減、コストカットのためにAmeba K8s基盤への移設プロジェクトが始動 BQ + CronJobへの本格的な移設の第1弾として着手 7/31
8. 前職のK8s運用 3 8/31
9. 前職のK8s環境 GKE上でのアプリケーション運用 ArgoCDは途中から導入 それまでは毎回サービスを作るたびに大量の実装が必要 必要だったマニフェスト Deployment Service HPA ConfigMap ServiceAccount Ingress 合計数百行以上のYAML 9/31
10. マニフェスト管理の課題 手動デプロイのリスク kubectl apply を手動実行 環境を間違えそうになる恐怖 コマンドが何だっけ...？となる コピペミス 適用漏れが発生 10/31
11. レビューの負担 マニフェストレビューの課題 大量のYAMLを目視でチェック 本質的なロジックレビューに時間を割けない 開発体験が悪く、デプロイが憂鬱な作業に... 11/31
12. Ameba K8s基盤の魅力 4 12/31
13. Ameba K8s基盤の特徴 基盤チームによる高度な整備 1. KubeVela - マニフェスト管理の簡素化 2. FluxCD/ArgoCD - GitOpsによる自動デプロイ 3. Datadog - 統合監視基盤 4. Athena - ログ分析環境 バックエンドエンジニアが安心してアプリケーションに集中できる環境 13/31
14. KubeVelaによるマニフェスト削減 Before（前職） # Deployment.yaml # Service.yaml # HPA.yaml # ConfigMap.yaml # 合計数百行以上... サービスごとに全てのリソースを定義 14/31
15. KubeVelaによるマニフェスト削減 After（Ameba K8s基盤） apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: access-analysis-batch spec: components: - name: access-analysis-batch properties: ... traits: ... Application定義だけでリソース・環境変数・外部シークレットまで完結！ 15/31
16. GitOpsによる自動デプロイ FluxCD + ArgoCDの組み合わせ FluxCD PRマージ ↓ イメージ更新の自動反映 ↓ デプロイ完了 ArgoCD PRマージ ↓ マニフェストの自動適用 ↓ デプロイ完了 メリット dev/stg/prdのイメージ更新が自動 Git履歴がデプロイ履歴に 16/31
17. 運用ツールの充実 ArgoCD Podの状態管理が簡単 Jobの実行状況を可視化 以前はコマンドで叩いていた作業が不要に Datadog アプリケーションの統合監視 メトリクス、ログを一元管理 アラート設定も容易 Athena クエリベースでログ確認 CloudWatchより安い 17/31
18. CronJobの実践 5 18/31
19. アクセス解析の処理フロー BigQuery アクセスログ蓄積 → CronJob データ処理 → DynamoDB 解析結果保存 処理の特徴 毎朝6時に実行 BigQueryに蓄積された1日分のアクセスログをCronJobで集計 集計結果をDynamoDBに書き込み 処理は約1時間かかる 19/31
20. WCU動的管理によるコスト最適化 DynamoDB WCU（書き込みキャパシティユニット）とは WCU: DynamoDBへの書き込み性能を決める指標 課金: WCUの設定値に応じて時間単位で課金 課題: 常時高いWCUだとコストが跳ね上がる CronJob内で動的にWCUを制御 ⬆️ WCU増加 処理開始前 → データ書き込み BigQuery → DynamoDB 約1時間の処理 → ⬇️ WCU削減 処理完了後 20/31
21. 障害対応の実体験 6 21/31
22. 障害① リリース直後、Jobが消える 状況 リリースして数日後の朝6時 1時間かかるJobが30分で途中で消えた エラーログなし 原因特定 Datadogで即座に障害を検知（Slackに通知） CPU/メモリの状態も把握できた ただし、なぜ消えたのか不明... 22/31
23. 基盤チームのサポート 心強い連携 障害報告後の次の日、プラットフォームチームの方が朝6時に一緒に起きて調査 Athenaのログを一緒に分析 安心感 一人で未知のプラットフォームを触るのは怖さがあったが、 プラットフォームチームが熱心に見てくれる安心感があった 23/31
24. 障害①の原因と対策 根本原因 リソース使用量が少ないPodを落とす仕組みが存在（Karpenter） プラットフォーム側のコスト最適化機能 対策 Podのリソース使用量を適切に設定 以降、この原因では落ちなくなった 学び 適切にリソース設定すれば、コストカットまで自動で管理してくれる 24/31
25. 障害② またPodが消えて失敗 状況 またPodが途中で消えたが、エラーログは出ていない 再実行が自動で走るがWCUが上がった状態のままWCUを上げに行ってしまいエラーに 応急処置 書き込み中に失敗したらWCUを下げる実装をGoのdefer文で追加 ただし、Podが途中で中断された場合deferが実行されない事がある可能性を考慮に入れられず 反省点 エラーログが出ていない = Podが中断している 可能性を考えきれていなかった そして、また同じ障害へ... 25/31
26. 障害③ またまたPodが消えて失敗 状況 またPodが消えて障害に 再実行中、動いているPodが消える現場を目撃 K8sによる再起動と判明 プラットフォームチームからの提案 postStartCommand / preStopCommand - コンテナ起動前後の処理を記載 Sidecar Container - メインアプリが落ちてもWCU管理を継続 最終対策 データ書き込み時、WCUが既に高ければスキップ リトライ時の冪等性を確保（アプリ側で実装） 26/31
27. まとめ 7 27/31
28. Ameba k8s基盤の効果 マニフェスト管理 実装量が劇的に削減（数百行 → 数十行） アプリケーションロジックに集中できる デプロイフロー PRマージで自動デプロイ完了 環境間違いのリスクが減る 履歴を残せる 28/31
29. 障害対応で学んだこと オブザーバビリティの重要性 Datadog: リアルタイム監視で即座に検知できると安心 Athena: 詳細なログ分析ができると問題解決が速い ArgoCD: Pod状態を可視化することで異変にすぐ気付ける 基盤チームとの連携 朝6時に一緒に調査してくれるような献身的なサポート プラットフォームならではの実装提案 技術+人のサポートで安心して開発できる 29/31
30. 最後に Ameba K8s基盤の真の魅力 高度な技術基盤(KubeVela / Datadog / Athena / ArgoCD) + 献身的なサポート体制 = バックエンドエンジニアが安心して アプリケーション開発に集中できる環境 基盤は、適切な技術導入と手厚いサポートで成り立つ 30/31
31. ご清聴ありがとうございました 31/31