2024/10月社内Tech勉強会レポート – AWSを使ったイベント駆動サイトを開発した時の話 & Miroでブレストワークショップ -

2024/10月のオンラインTech勉強会レポートとなります。
今月は以下のお品書きとなりました。

AWS使ったイベント駆動サイトを開発した時の話
ワークショップ「みんな若手エンジニアの頃どうやって学んだ？？ブレスト」

AWS使ったイベント駆動サイトを開発した時の話

パートナーK氏による、過去PJの構成とノウハウの紹介となります。

ざっくり要件として「メールの文面の内容を解析して次の作業を自動的に行いたい。」がありまして、課題解決のために、イベント駆動で動作するアプリケーション・システムをAWSで構築したよ。その時こんな苦労もありましたが、こう解決しましたよ。という内容でした。

↑のような構成で構築。

かいつまんで紹介しますと、

S3
- メールの保存
SES
- メール送信に使用
  - バウンスになった場合、SQSにバウンスになった旨のイベントが飛んできて、それをバッチサーバが処理する
ECS
- アプリケーションの本体
- Fargateを使用
ECR
- ECSで動かすDocker Imageが保存されている
- CircleCIを用いてビルド→ECRにイメージ配置→ECSのタスク更新を自動で実施できるように設定
SQS
- イベントを配信したり受け取ったりといった部分を管理
- DLQを設定し、イベントが処理されなかったorできなかったものは後で再度実施されるように設定
- ここからバッチサーバが各イベントを取得し、更にバッチサーバでそのイベントに合致するフローを実行、その結果をまたここにイベントとして配信、それを取得し…という形で順番にフローが実施される機構に
SNS
- SQSへ向けてイベントを配信する目的で使用しているサービス
  - 後述する EventBridge がこのSNSへ向けて定時イベントを送信し、SNSがそのイベントを受け取り、SQSへ向けて改めてイベントを送る形となっている
EventBridge
- システム側で定時実行するイベント（ex 毎日X:XXに△△を実施させたい）をここから発行する目的で使用
- SNSを介してSQSへイベントをキューに貯め、バッチ側でそのイベントを取得することで定時実行したいイベントを動かすようにしている

構築しての感想

文献（ベストプラクティス）が足りない

特にECSについて、コンテナ管理部分を楽するためにFargateを選択したものの、この当時(5,6年前) Fargateに関する文献がどこにもなくAWSのドキュメントとにらめっこする日々
Fargateの場合、ECSのタスクが動かない時にコンテナの中に直接入ってエラーログの確認という手法が取れないため、AWS側で出力されているログの内容から推測して対応しないといけない
(※今でしたらSSMとかで代用できるかもしれないですが、未検証です。)

非機能要件を含めた、やりたいことが実施できる設定項目を各サービスのドキュメントから探し出す必要があるため、構築中は常に公式ドキュメントを検索＆適宜サンドボックスで実験し続けることに