こんにちは。ペイルドの id:pranc1ngpegasus です。
今回は外部サービスから連携されるクリアリングファイルを仕様書に沿ってパースし、内部サービスに取り込む処理を再構築したので紹介します。
Before
上記にこれまで稼動していたシステムの全体像を示します。
これまでデータのパースと内部サービスのリクエストは全てWindowsサーバ上で動くバッチで実行されていました。
Windowsサーバが外部サービスからクリアリングファイルを受け取りとバッチの実行をしており、以下のような問題点がありました。
- 永続化レイヤーを持たなかったためエラー時の復旧が面倒
- EC2上で実行されるためバックアップ関係がEBSに依存している
- キューがなく処理全体が密結合になっている
After
上記に完成したシステムの全体像を示します。
インフラまわりの構成要素と役割は以下のとおりです。
- S3: クリアリングファイルの保管
- EventBridge: S3に対するファイル作成イベントから別サービスをキック
- ECS task: クリアリングファイルのパースと一部情報の問い合わせ、取り込みデータ組み立て
- SQS: 取り込みデータの保管
- Lambda: 内部サービスへのデータ取り込みリクエスト
効果
上記の構成に移行したことで以下のような効果がありました。
- バッチの実行場所がWindowsサーバからマネージドサービス群へ
- EventBridgeやSQSを利用したイベント駆動な構成により処理全体が疎結合に
- SQSを利用したキューイングにより大量のデータを内部サービスに負荷をかけずに実行できるように
おまけ
インフラ構成の話ではないですが、、
SQSからLambdaをキックするときに1つのLambdaイベントには複数のSQSメッセージが格納されます。(標準キューの場合は最大10,000、FIFOキューの場合は最大10)
内部サービスにHTTPリクエストを送信するだけのLambdaアプリケーションのプログラムで、Lambdaイベントに含まれるSQSメッセージのうち1件目だけを処理するように書いてしまい、SQSから10メッセージが削除されるのにHTTPリクエストは1件しか飛ばないという事件を起こしてしまいました。
安直に event.record[0]などと書かないようにしましょう。
