数百以上の様々なバッチが動いているバッチ基盤をECS on FargateからEKS on EC2へ移行した話

Transcript

1. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 数百以上の様々なバッチが 動いているバッチ基盤を ECS on Fargate から EKS on EC2 へ移行した話 JAWS FESTA 2023 2023年10月07日
2. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy About Me Hikaru Sasamoto (@hisamouna34) - 株式会社エウレカ - 2022年に入社 - SREチームに所属
3. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy Agenda - マッチングアプリ「ペアーズ」の紹介 - 本セッションについて - Pairs におけるバッチ運用 - 旧バッチ基盤 ( ECS on Fargate ) について - 新バッチ基盤 ( EKS on EC2 ) について - まとめ - 結局、ECS on Fargate / EKS on EC2 どっちが良いのか
4. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy
5. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 本セッションの対象の方 - AWS でバッチ基盤を運用している・運用を検討している方 - 特に、 Lambda や AWS Batch 以外の選択肢を検討中の方 - 色々詰め込んだ結果、AWS サービスや Kubernetes などの細かい説明を盛り込むことができなかったので、講演後 などに質問いただけると助かります
6. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 本セッションについて 話すこと - ペアーズにおけるバッチ - 移行前のバッチ基盤 ( ECS on Fargate ) の紹介 - 移行後のバッチ基盤 ( EKS on EC2 ) の紹介 あまり話さないこと - バッチのベストプラクティス - 扱われている要素技術 ( Kubernetes, Terraform, CUE, KEDA など) - 安定稼働に向けての取り組み (監視など) - (この辺りについては別途話したい)
7. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ペアーズにおけるバッチ運用 - バッチで行っていること - 例) プッシュ通知、審査処理、Elasticsearch のドキュメント更新 など - バッチの種類: 332 - ペアーズは3カ国(日本/台湾/韓国) 展開していて、それぞれのリージョンごとにバッチがあるので、実質 ×3 - 基盤の構築・監視は SRE チームが行っている - 新規バッチ作成は開発チームが行う - 開発チームが作成しやすいような構造になっていることが望ましい
8. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ペアーズにおけるバッチには 2種類ある スケジューリング型バッチ メッセージレシーブ型バッチ - 実行タイミング : cronによる定期スケジュール - 要件 : - 単一プロセスがスケジューリングされる (排他 実行) - モノによっては、時間依存がなく、数分おきに繰 り返し実行しているケースもある - 実行タイミング : SQS のキューイング - 要件 : - メッセージ数に応じて実行プロセス数をスケール させる
9. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 旧バッチ基盤について概要 - ECS on Fargate を採用 - そのさらに前は、 EC2 に crontab の設定ファイルをおいていた - 当時のサービスはバッチ以外のサービス基盤も ECS on Fargate で運用 - ECS タスクにはバッチ処理コンテナと別に、metrics 転送用コンテナの Datadog と log 転送用コンテナとして fluentd が同居 - アドホックな実行も可能 - 問題があった際のリカバリーなどの要件で必要 - GitHub Actions から AWS CLI で ECS run task をコール
10. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy FAQ Q. なぜ、Lambda や AWS Batch 使わなかったのか？ - Lambda の max timeout 15分の制約に引っかかる バッチ があったから - AWS Batch で メッセージレシーブ型 バッチ を扱う場合の改修工数が懸念された
11. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 旧バッチ基盤のバッチ定義は Terraform で管理 - 定義を管理する専用のリポジトリを用意 - 開発者はバッチを作成する際に tf ファイルを修正していた - 開発者の修正負荷軽減や準拠してほしい設定を書いてもらうために Terraform module 化
12. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 旧バッチ基盤のアーキテクチャ ECS Cluster : 1バッチ1クラスタ Lambda : 1バッチ1ファンクション DynamoDB : Lambda と ECS 用でそれぞれ1 テーブル 詳しく紹介していきます
13. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 旧バッチ基盤 - スケジューリング型 - EventBridge による Cron 実行で、ECS Task を作成 - EFS を利用し、排他実行を実装 - 実行時に lockfile の存在を確認し、存在する場合は処理をスキップ - 存在しない場合は、 lockfile を作成し、バッチ処理を実行
14. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 旧バッチ基盤 - メッセージレシーブ型 - EventBridge で2分おきに Lambda を起動し、ECS run task をコール - ECS Task は、SQS からメッセージを dequeue し、メッセージ内容に応じた処理を行う
15. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy メッセージレシーブ型 - Lambda で task 数を計算 - バッチごとに同時起動数を制限したい - ECS run task 当たりの起動タスクには quota がある - 上限10タスクで、調整はできないよう https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-quotas.html - 外部リソース ( DBMS, DynamoDB, SQS … ) の負荷を鑑みて - 同時起動タスク数は、SQS の visible messages 数 と 実行中の tasks 数から計算 - バッチ定義ファイルにバッチごとのタスク数の上限値を定義
16. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy メッセージレシーブ型 - exactly once 実行 - SQS には同一メッセージが複数回 dequeue される可能性がある - exactly once 実行を保証するために Dynamo DB を活用 - メッセージ内容から一意になる生成IDをパーティションキーにしたアイテムを Put - Put 時にすでに同一のパーティションキーが存在する場合はエラーを返却させて、後続処理を行わずに終了させ て exactly once 実行を実現 - AWS 公式で紹介されている手法 https://aws.amazon.com/jp/blogs/database/building-distributed-locks-with-the-dynamodb-lock-client/
17. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy うまく運用していたが、一部に辛みがあった - 一番辛かったのは、GuardDuty のコスト - 現状、Fargate ではコンテナイメージのキャッシュができない - そのため、CloudTrail での ECR image pull イベント検出回数が非常に多く、結果として GuardDuty のコスト が高くついてしまった - バッチ の数が増えたことでコンピューティングリソースコストが辛くなってきた - Fargate は EC2 と比較してしまうとコストがかかる。 その分、楽できるところもあるので、一概にどっちが良いと いうわけではない - アプリケーション基盤は EKS on EC2 で稼働しており、管理するクラスタが複数ある状態だった - 開発者のバッチ作成体験を良くしたい 他
18. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 新バッチ基盤へ移行 - (アプリケーション基盤と同じ) EKS on EC2 にのせることに - Lambda, AWS Batch は元々要件上厳しかった - EKS をどこにのせておくかとを考えた時、運用コストよりも費用コストを優先したので、 Fargate ではなく EC2 を選択 - アプリケーション基盤と統合できるのは管理面でも大きなメリット - ECS on EC2 での運用は結構大変そう - どうやって EC2 をスケールインさせるかは作り込みが必要かも - 移行するついでに前スライドの辛みを解消させたい…
19. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 新バッチ基盤のアーキテクチャ EKS Cluster: アプリケーションと同じクラスタ CD: ArgoCD による GitOps Namespace: リージョンとバッチタイプごと * なぜバッチタイプが3つなのかは後述 Sidecar: 専用の Namespace に Deployment リソースで Pod 作成。Service 経由でバッチからリクエスト 詳しく紹介していきます
20. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy (再掲) ペアーズにおけるバッチには 2種類ある スケジューリング型バッチ メッセージレシーブ型バッチ - 実行タイミング : cronによる定期スケジュール - 要件 : - 単一プロセスがスケジューリングされる (排他 実行) - モノによっては、時間依存がなく、数分おきに繰 り返し実行しているケースもある - 実行タイミング : SQS のキューイング - 要件 : - メッセージ数に応じて実行プロセス数をスケール させる
21. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 新バッチ基盤 - スケジューリング型 - さらに2つのタイプに分離 - 実行時間が決まっているスケジュール実行用の batch - 実行時間依存のない短いスパンで定期実行する batch-iterator
22. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 新バッチ基盤 - スケジューリング型 ( batch ) - Kubernetes の CronJob リソースで cron とバッチ処理を定義 - 排他実行要件を満たすために - concurrencyPolicy に Forbid を設定することで、処理が終わっていなければ、新しいスケ ジュール実行をスキップ
23. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 新バッチ基盤 - スケジューリング型 ( batch-iterator ) - Kubernetes の Deployment リソースで定義 - 処理の内容 - バッチ処理を実行 - 可変時間 sleep - 処理の exit code が0であれば再度バッチ処理 / 0以外であれば、podを異常終了 - 実行のたびに pod 生成をしないので、Kubernetes の API コール数を減らせたり、バッチ処理までの リードタイムを短縮 - replicas を1として、strategy を Recreate に設定することで排他実行を保証
24. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 新バッチ基盤 - メッセージレシーブ型 ( batch-worker ) - SQS の subscribe と pod の作成のために KEDA を導入 - イベント駆動で pod を作成する kind: ScaledJob を利用 - KEDA は SQS のメッセージ数から起動 pod 数を計算してくれる - Lambda を使って実装していた処理を移譲させることができた - 1 pod での想定最大処理メッセージ数や最大 pod 数を設定可能 - 関係する設定を一箇所にまとめることができた
25. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy バッチ定義管理には CUE を導入 - マニフェストのテンプレート化をしたかった - CUE 言語とは - https://cuelang.org - 構成管理を目的とした言語 - 構成ファイルのバリデーション、構成のマージ、設定のデフォルト値を持たせることができるのが特徴 - データの定義と制約をファイルにまとめて記載可能
26. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy CUE の活用 - 開発者がバッチ作成時に、CUEの理解がなくて済むように抽象化させた構成に - 実質1行でバッチが作成可能。SRE チームによる追加の作業も不要 - リソース割り当て ( CPU や memory ) をデフォルト値を用意 - 最低限必要なリソースは決めておいて、足りなかったらよしなに設定変更とすることで、バッチ作成 時のコミュニケーションを減らす - 最終的には ArgoCD で kustomize build されるので、CUEで生成された yaml をリポジトリで管理し、ArgoCD の 参照ファイルに設定
27. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy CUE を広める活動 #CUEでキュッと - CUE について README やブログを書いたり、勉強会を実施したり - 新しい技術に対する壁を無くす取り組みが大事 - 導入したのに積極的に利用してくれないのが一番辛い
28. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy バッチ基盤を Kubernetes で運用する際の注意点 - 処理が終了した pod は削除する - pod は削除しない限り IP アドレスを保持し続ける - pod が起動しているサブネットの IP 枯渇リスクが生じてしまう - CronJob / ScaledJob リソースで successfulJobsHistoryLimit / failedJobsHistoryLimit を設定して、 処理を終えた pod の数を最小限にする - 調査のために、メトリクスやログを保存しておくことを忘れずに
29. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy バッチ基盤を Kubernetes で運用する際の注意点 - 同一 node 上により多くの pod を配置するようにする ( = node 内の pod 濃度を高める) - pod が 多くの node に分散配置されてしまうと、リソース効率が悪い - pod が残った状態だと node のスケールインができない - podAffinity を設定しましょう - すべてのバッチに同じラベル ( app-type: batch ) を 付与 - この設定により、バッチ pod が起動している node に優先的に pod を配置
30. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy まとめ
31. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy バッチ基盤はどう変わったか 定期実行される Lambda が ECS Task を起動。仕組みの 作り込みが必要だった EKS on EC2 スケジューリング型 ( batch ) KEDA で Pod 作成。簡潔になった メッセージレシーブ型 ( batch-worker ) スケジューリング型 ( batch-iterator ) ECS on Fargate EventBridge による cron 結構シンプルで良かった EventBridge による cron 1分おきにタスク実行させる CronJob によって、cronとバッチ定義を1箇所 にまとめられた Deployment で 永続化 Pod 作成 都度、プロセスを作り直さなくてよくなった
32. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ECS on Fargate と EKS on EC2 運用してみて EKS on EC2 ECS on Fargate 運用のしやすさ Nodeの管理が不要 Nodeの管理が必要 (とはいえ、アプリケーションのNodeもあるので特 別負荷があるというわけではない) コスト バッチ数が多くなるほど、Fargate と EC2 ではコ スト差が出る 管理コンポーネント Lambda や EventBridge, EFS など、 障害点は複数存在 全てを Kubernetes に閉じることができた
33. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 結局、ECS on Fargate / EKS on EC2 どっちが良いのか ケースバイケース
34. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy AWS でのバッチ運用の選択肢はたくさんある - ECS on Fargate - インスタンスの管理が不要なのはありがたい - ECS はバージョンの定期アップデートがないのも運用者としては嬉しい - AWS のコンポーネントを組み合わせることで複雑なスケーリング機構を作れる - EKS on EC2 - Kubernetes 単体での柔軟性が高い - バッチ基盤だけ Kubernetes で運用するのはおすすめしない - 慣れるまではの運用負荷は Fargate より高い - 定期アップデートの工数はそこそこある - Lambda も AWS Batch も考慮してみましょう
35. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy まだまだ SRE チームでやることがいっぱい - バッチ基盤の移行は完了し安定稼働はできているけど、やりたいことはたくさん - Spot Instance の導入 - AWS Graviton 利用のために、Arm 化 - 他にも、 - Developer Experience 改善 - モバイル監視の充実 - データ基盤の整備
36. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy We’re hiring! ペアーズではエンジニアを積極採用中！ 
 カジュアル面談もお待ちしております！ 
 (X: @hisamouna34)