資料
人事システム「COMPANY」のバッチ処理の裏(側) の話 - Qiita
バッチサーバーを ”Fargate化” しました - Qiita
アジェンダ: バッチサーバーFargate化総括
- 概要
- 稼働状況
- 評価
- 今後の課題
概要
動機
バッチサーバーにおける以下を達成する。
- よりシンプルな冗長構成
- コスト削減
従来構成
動機に伴う主題
AWS ECS Fargate を用い、コンテナ起動でバッチごと必要時のみのバッチサーバーサービス起動を行い、バッチ実行を実現する。
動機に伴う解決策
現プロダクトの「バッチ実行」の以下処理フロー
- 実行命令
- キュー指定、バッチサーバー選択
- 処理実行
2以降をFargateに置き換える。
フロー詳細: 人事システム「COMPANY」のバッチ処理の裏(側) の話 - Qiita
稼働状況
バッチサーバーを ”Fargate化” しました - Qiita
設定を切り替えることにより使用可能な状態（かつ既存動作に影響は出ない状態）を2020年末までに達成。
評価
評価点・反省点
2021年1月より稼働検証を行った。以下が考えられる。
| メリット | デメリット | |
|---|---|---|
| 対ユーザー | 可用性の向上 | - EC2リソースに制限されないバッチ実行 (並列に実行できるバッチの増加・キューの制限の解消)。 - 実行時間の増加による業務実行への影響。 |
| 対製品全体 | コスト削減。AWS移行によって独自キュー管理をなくせる (最適化された構成・保守工数の削減) | - |
| 対インフラ | 可用性の向上、クラウドコスト削減 | トラブルシュート時の運用の変化。 |
| 対ドメイン | 可用性の向上 | - 問い合わせ時のログ取得の簡易化が必要。 - トラブルシュート時の運用の変化。 - 実行時間の増加による問い合わせの懸念。 |
今後の課題
問題点
現段階では既存の冗長化機能を利用した現状維持 or 制約を受け入れてFargate版を使う、の2択である。以下比較。
-
既存のバッチ処理
- 構成: AZ-aにインスタンス1台を作成。冗長性は確保できない。
- 冗長性: 無し。
- コスト: バッチを実行しない時間でもインスタンス起動料金がかかる。
- 時間: テストバッチで10~20秒ほど。
- メリット: 実行時間が他2つと比較して早い。
- デメリット: インスタンス管理が必要。冗長性を確保できないため、障害時はインスタンスの復旧までダウンタイムがかかる。
-
ECS Fargate TASK起動
- 構成: インスタンスは保持しない。都度TASKを作成、コンテナ起動。冗長性が確保できる(必要に応じてフルマネージドでコンテナが起動可能)
- 冗長性: 担保可能。
- コスト: 実行時間分のみの課金→最適なコストの実現。
- 時間: テストバッチで1分30秒ほど。TASK作成からコンテナ起動までが50秒ほどかかる。
- メリット: インスタンス管理が不要。コストの最適化。冗長性を確保でき、バッチ処理のだダウンタイムをなくせる。
- デメリット: コンテナ起動時間が遅く、短いバッチを何度も実行する場合、オーバーヘッドが無視できない。
-
ECS EC2
- 構成: ECSインスタンスを作成・保持。ECSインスタンスを複数保持することで冗長性が確保できる。
- 冗長性: 担保可能。
- コスト: バッチを実行しない時間でもインスタンス起動料金がかかる。本番環境ではコスト増になる。
- 時間: テストバッチで1分ほど。TASK作成からコンテナ起動までが15秒ほどかかる。Fargateよりは30~40秒起動が早い。
- 制約: インスタンスタイプによって同時に起動できるTASKに制限がある。
- メリット: 冗長性を確保でき、バッチ処理のダウンタイムをなくせる。Fargateよりは早い起動時間であり、許容範囲に収まる可能性。
- デメリット: インスタンス管理が必要。同時に起動できるバッチに制限が生まれる。制限を拡張する場合、インスタンスコストが増えるので、コスト増につながる。
改善要望・ほか参考資料
AWS Fargateを本番運用した所感 - コネヒト開発者ブログ
タスクの起動速度がEC2バックエンドと比べるとやはり遅い
Fargateにするとホストが固定されないため、Docker Pull時のレイヤキャッシュが効かなくなります。それが理由でEC2バックエンド時代と比べるとECSサービス更新からコンテナが立ち上がるまでの時間が約1.5〜2分程遅くなりました。その分デプロイ速度が遅くなってしまいます。これはDockerイメージのサイズも大きく影響するので一概には言えないですが、アーキテクチャ上仕方ないとは思いつつ、AWSの今後の進化に期待したい部分だと思っています。Cron的な起動時間が厳格に求められるスケジュールバッチのバックエンドには、FargateでなくEC2バックエンドを使うのが今のところは正解かなと個人的には思っています。
Amazon ECS Fargate/EC2 起動タイプでの理論的なコスト最適化手法 | Amazon Web Services ブログ
AWS Fargate のイメージサイズ毎の起動時間の違い - Qiita
AWSでバッチ処理を実装する際の選択肢とサービス比較
AWS Batchの使い所 - Qiita
Amazon ECS on AWS Fargate のコスト最適化チェックリスト | Amazon Web Services ブログ
Amazon ECS で実行するコンテナをローカルでテストする - Qiita
別案
「バッチ処理」の再整理。10秒20秒で終了する処理をバッチ形式で実行している背景の整理など。
参考:
- バッチ処理を作る際に押さえておくこと - Qiita
- バッチ処理について考える - Qiita
- わざわざバッチサーバを用意してバッチ処理する時代を終わらせたい - Qiita
- バッチ処理 プラクティス
- バッチシステムをクラウドネイティブにするために考えたこと - Speaker Deck
「バッチ処理は時代遅れ」として議論になった記事、一方のCOBOL
次フェーズ・タスクの再開条件
Fargate でのバッチ実行時間が今よりも30秒ほど短くなっていること。あるいは、ボトルネックになっている短いバッチ実行をアプリケーションサーバーなどに移設すること。
以上公開可能な範囲でまとめたもの。参考になればさいわいです。