バッチ処理の改革

バッチ処理の改革はアプリケーションへの影響が大きいため、以下のノウハウを参考のうえ可能であれば検討すること。

マネージドサービスの選択

ジョブ管理を提供するサービスをどのようなユースケースでどういう選択をするのか

ジョブ管理にはジョブの実行制御を行うオーケストレーター/スケジューラー系サービスと、計算リソースを提供する実行コンピュート系サービスが存在する。

• オーケストレーター/スケジューラー: Amazon EventBridge Scheduler、AWS StepFunctions、Amazon Managed Workflow for Apache Airflow、Amazon Simple Workflow Service、
  AWS Glue
• 実行コンピュート: AWS Lambda、Amazon ECS on Fargate、Amazon ECS on EC2、Amazon EC2

オーケストレーター・スケジューラーサービス検討のポイント

スケジューラーはAmazon EventBridge Schedulerが推奨される。Amazon EventBridge Ruleも同様のスケジューラー機能を提供するが、後発のサービスであるAmazon EventBridge Schedulerの方が機能が高機能である。

ジョブオーケストレーターについては、ETLジョブの場合はAWS Glueが最適である。ETL以外の場合で、ジョブオーケストレーターが必要な場合はコストとパフォーマンスの効率がよいStepFunctionsが有力な選択肢となる。StepFunctionsで要件が満たせない場合は、Amazon Managed Workflow for Apache Airflow又はAmazon Simple Workflow Serviceを検討する必要がある。

実行コンピュート検討のポイント

コンピュート環境はAWS Lambdaで要件が満たせるワークロードの場合、AWS Lambdaの利用が推奨される。Lambdaで要件が満たせない場合においてもなるべくコンテナ化を目指し、サーバーレス環境での実行を優先的に検討することが推奨される。

各サービスの詳細

オーケストレーター/スケジューラー

実行コンピュート

イベントドリブン化

イベントドリブン処理の必要性について

従来のオンプレミスシステムでよく存在していた夜間バッチアプリケーションについては、夜間バッチ処理の処理負荷を分散するために夜間のシステムの停止（閉局）が必要になったり、夜間のジョブの監視要員が必要になったり、バッチ処理が失敗したときに朝のシステムの開始（開局）までのリカバリーが困難であるなど、システム運用の難度を上げる大きな要因であった。これを廃止、もしくは極小化し、更新イベントがあるたびに後続処理を行う、イベントドリブン処理とすることでシステム運用のシンプル化に大きく貢献することができる。また、夜間バッチアプリケーションを廃止・極小化することで、複雑なジョブ連携をジョブフローとして管理するジョブ管理サーバも不要となる。

イベントドリブン処理の基本的な構成要素

これまでの夜間バッチ処理をイベントドリブンな処理に変更する際に、基本的な構成要素がどのようになるかを以下に解説する。リクエストの呼び出しイベント、処理の完了イベント、データの変更イベントなどの状態の変化をイベント発行元（イベントプロデューサ）からイベントストア/ルーター/バスを通じて、後続の処理サービスへと伝播し処理を実装することができる。

イベントドリブン処理のデザインパターン

イベント駆動のジョブを作成するにあたって、代表的なデザインパターンとして以下の３種類のデザインパターンが存在する。ジョブを実装する際に、いずれかの方式を選択するというよりは、それぞれの方式を組み合わせて、イベント駆動のアプリケーションやジョブを構築することとなる。

コレオグラフィ

コレオグラフィの動きの概要

コレオグラフィの動きとしては、必要なすべての情報を含んだ最初のイベントを 1 つのメッセージに保存して、最初のトランザクションを完了する。他のサービスがそのメッセージを非同期的に取得し、あらかじめ定められた動作条件（振付：コレオグラフィ）にしたがって、それぞれのタスクを完了させる動きとなる。これにより、サービスが疎結合になり、直接互いに影響を与えない構成となる。その結果として、イベントメッセージの保存と取得が非同期の関係になり、スケーラビリティと信頼性が向上する。

実装例１：SNS、SQS、Lambdaの利用

• リクエストを行う「リクエストサービス」（アプリケーション等）から「SNS」にメッセージをトピックにパブリッシュする。
• 「SNS」に作成したトピックを「SQS」はサブスクライブ（購読）する。
• 「Lambda」は「SQS」がメッセージを受信された際に、何らかの「Lambda」関数を呼び出す。
• この場合、従来型のバッチ処理は「Lambda」関数として実装することとなるが、マイクロサービスとなるように役割を決めて実装することを推奨する。なお、トピックをサブスクライブしている「SQS」が複数ある場合、「SQS」に紐づく「Lambda」を並行的に実行（ファンアウト）することができる。
• この構成の利点としては、「リクエストサービス」は「SNS」のトピックにパブリッシュするだけでよく、バッチ処理などの記述はサブスクライブする「SNS」と、それに呼応する「Lambda」関数を「SQS」に紐づけることができる。すなわち、ロジックを意識せずにサービス結合ができ、疎結合な構成が可能である。

実装例２：Amazon EventBridgeの利用

• リクエストを行う「リクエストサービス」（アプリケーション等）から「EventBridge」のイベントバスに対してイベントを発行する（カスタムアプリの場合は、「EventBridge」でカスタムイベントバスを作成しておく。AWSサービスをイベントソースとする場合は、デフォルトイベントバスを利用する。）
• 「EventBridge」ではイベントバスとイベントターゲット（「支払」、「注文」などのLambda等で記述されたマイクロサービス）の関係性記述を行う。
• この構成の利点としては、「リクエストサービス」は「EventBridge」のイベントバスにイベントを発行するだけでよく、バッチ処理などの記述は「EventBridge」の機能を用いてイベントターゲットとなる「Lambda」等の関数を定義できる。すなわち、ロジックを意識せずにサービス結合ができ、疎結合な構成が可能である。

コマンド責任分離の実装例

コマンドクエリ責任分離の概要

コマンドクエリ責任分離 (CQRS) パターンは、データ変更、つまりシステムのコマンドサービス（更新部分）をクエリサービス（参照部分）から分離する。スループット、レイテンシー、または一貫性に関して、コマンドとクエリで要件が異なる場合は、CQRSパターンを使用して更新とクエリを分離することが可能となる。

実装例１：Kinesis Data StreamsとLambdaを利用

この実装方式の特徴や、実装する場合の留意点を記載する。

実装例２：DynamoDB StreamsとLambdaを利用

この実装方式の特徴や、実装する場合の留意点を記載する。

イベントソーシングの実装例

イベントソーシングの動きの概要

データベースの更新や、メッセージやイベントの発行を信頼性の高いアトミックな方法で実行したい場合に利用するパターン。イベントソーシングではデータベースなどに更新クエリを直接実行するのではなく、注文依頼、与信確認、注文受け付け、配送依頼などビジネスの事象によってデータの状態が変更されるイベントをイベントリスト（DynamoDB等）に追加して永続化する。イベントの保存は単一の操作で行われるため処理はアトミックになる。保存されたイベントを再生することで現在の状態に再構築可能なところがこのパターンの特徴。特定のデータソースへのアップデートクエリではなく状態を更新する事象を表すイベントとして保存されるため、複数のサービスがイベントストアからイベントを再生して状態を更新する際に、サービス個々のデータソース用に更新処理を実装することができる。これによって、先に紹介したCQRSパターンのようにコマンド側とクエリ側で異なるデータソースの異なるスキーマであってもイベントの再生ができるため、CQRSパターンと組み合わせて使われることもある。

実装例１：Kinesis Data Streams (or SQS FIFO)とLambdaによる実装例

イベントドリブン処理の実装を効率化するために

Amazon EventBridge Pipes

イベントドリブンなアプリケーション構築時に、発行側と受取側同士の連携を実現する、シンプルで信頼性の高い方法を提供する仕組みをAWSは提供している。イベントドリブンな処理を実装する際に、つなぎ込むためのコード開発の手間を最小化することが可能になっている。LambdaやStep Functionsなどとの連携でデータ加工・変換も可能となっている。

Amazon EventBridge Pipesの概要

監視の移行

監視は、必須で検討し、阻害要因が無い限り適用を推奨すること。

前提

Observabilityとは

Observabilityが確保されているということは、システムの監視機能が以下を達成している状態を指す。

Observabilityの要件

1. 問題発生時にアラームを発報し人へ介入を促す。
2. 問題発生時に原因を調査するために必要な情報を提供する。
3. 長期的な計画を立てるために必要となる情報（サービスの状態とリソース消費量の傾向）を提供する。
4. 更新がデプロイされる前後、又は二つの異なるバージョンを比較するための情報を提供する。
5. これらの情報のうち重要なものを視覚的に表示する。

これらの目標を達成するためにシステムの監視機能は以下3種類のデータを収集する必要がある。

• メトリクス: 特定の時刻に計測されたシステム状態を現わす数値
• ログ: システム内で発生したイベントの記録
• トレース：複数サービスを横断して連鎖的に発生したイベントの記録

監視移行の方法論

監視対象についての考え方

システムに異常が発生しているかを判断するためには最低限以下の項目を監視すべきである。

• レイテンシー（Latency）
  • 各サービスがリクエストの応答にかかる時間を計測したもの。成功時応答とエラー時応答のレイテンシーはそれぞれ個別に集計され統計値を算出すべきである。これは、例えば瞬時に応答が返るエラーがある場合、成功時応答とエラー時応答を混同した平均レイテンシーなどの統計値は有益な情報をもたらさないからである。
• トラフィック（Traffic）
  • 各サービスの需要を計測したもの。例えばHTTPベースのAPIサービスであれば秒間HTTPリクエスト数がトラフィックにあたると考えられる。ストリーミングサービスの場合、同時接続数がトラフィックを現わすメトリクスとしてより適切である。
• エラー（Errors）
  • ユーザーが期待される結果を返せないという事象。これは5XXエラーが発生した場合のみならず、HTTPコードは200だが応答内容が正しくない場合や許容範囲外のレイテンシーを要した場合など、ユーザーが期待する結果を返せない状態全てを意味する。単純なロードバランサーの5XXエラーコード数カウントだけでは不十分なことが多く、ユーザー視点から期待値と結果の整合性を担保する外形監視の導入が推奨される。
• 飽和度(Saturation)
  • 各リソースの配置済み容量の内、使用中の割合を示したもの。各サービスのボトルネックとなる可能性が高いリソースほど飽和度監視の優先度が高い(例：CPU使用率に応じてオートスケーリングするサーバークラスタのメモリ使用率)。反対に、ボトルネックになりにくいリソースは優先度が低い(例：CPU使用率に応じてオートスケーリングするサーバークラスタのCPU使用率)。

監視を実現するためのAWSサービス

監視の実現するサービスはそれらが達成するObservabilityの要件（参照：Observabilityとは）に応じて、以下の３種類に分類される。

1. 計測・通知を行うサービス(1を達成)
   • 計測手段: CloudWatch Logs、Cloudwatch Metrics、CloudWatch Synthetics、Budgets、TrustedAdvisor、CloudTrail、GuardDuty、Inspector、Config Rules、Health、X-Ray SDKとDaemon、AWS Distro for OpenTelemetry
   • 連携手段: Cloudwatch Alarm、EventBridge、SecurityHub
   • 通知手段:　Amazon SNS、ChatBot
2. ログ・メトリクスデータを保管するためのサービス(2と3を達成)
   • ストレージ: S3、CloudWatch Logs、CloudWatch Metrics
   • ストリーミング：　Kinesis Data Firehose
3. 可視化を行うサービス(2、4と5を達成)
   • CloudWatch Dashboard、QuickSight

計測通知を行うサービス

計測手段

連携手段

通知手段

以下の図に示されるよう、ログやメトリクスは途中複数の中間サービスで集計され、異常と判断される場合EメールやSlackへ通知される。トレースは異常発生時の問題切り分けやパフォーマンス分析が主な用途であり、異常・正常の判定には用いられないため、以下の図には含まれない。

ログ・メトリクスデータを保管するためのサービス

ストレージ

ストリーミング

可視化を行うサービス

通知についての考え方

システムの監視機能はメトリクス、ログ、トレースを元にシステムの状態を継続的に診断する。異常が検知された場合、システムは人へ介入を促す必要がある。通知方法には問題の緊急度に応じて以下の３つに分類される。

• ページ: 即時対応が必要
• チケット:　数日以内に対応が必要
• ロギング:　対応は不要だが記録として残す(自動修復により解決された場合など)

ページは即時対応が必要な事象が発生した場合に可能な限り厳密に限定する必要がある。
即時対応が不必要にも関わらずページされるという事象が多発した場合、運用管理者へ不必要な負担をかけてしまうだけでなく、実際に緊急度の高いページが発生した場合に運用管理者が適切な緊張感を感じなくなってしまう可能性がある。
また一度発生したページは可能な限り再発しないよう、根本的原因の解決や対応の自動化を検討する必要がある。

問題の緊急度の高さはシステムによって異なるが、ユーザーへの直接的な影響が発生している場合はページ通知が適切な場合が多い。
以下に各異常の通知方法の分類の一例を示す。

通知方法の分類例

なお上記は通知方式の分類例の一例であり、すべてのシステムにおいて必ずしも上記の例が最適であるとは限らない。

改訂履歴