ALB TargetGroup を切り替えて S3 上の静的ページを表示する(HaMaMo! ハマスタモバイルオーダーの事例）[DeNA インフラ SRE]

はじめに

こんにちは，IT 本部 IT 基盤部第一グループの大田です． IT 基盤部では，DeNA のグループ子会社等も含めて横断的に複数のサービスのインフラ運用を行っています．

今回は，横浜DeNAベイスターズ（以下，YDB）の HaMaMo! というサービスについて，IT 基盤部が関わっているインフラ部分の構成について一部ご紹介します．

HaMaMo! とは

HaMaMo!（ハマスタモバイルオーダー）は、ハマスタオリジナルフードを、スマホでオーダーして、完成通知を受信後に、受け取りに行くだけの便利なオーダーシステムです。 https://www.baystars.co.jp/foods/mobileorder/

HaMaMo!（ハマスタモバイルオーダー）とは，YDB から 2023/04/04 にリリースされた，横浜スタジアムで利用可能なフード・ドリンクのモバイルオーダーサービスです．試合観戦などで球場を訪れたお客様がスマホから注文して料理を受け取ることができます．

リリース記事

要件

ハマスタモバイルオーダーのシステムは，AWS の EC2 インスタンス上に構築されています．IT 基盤部では，クライアントがモバイルオーダーの URL にアクセスしてから，システムサーバー（EC2）へ接続するまでに必要なインフラリソースの管理を行っています．それだけであれば，AWS の Route53 や Elastic Load Balancing などのマネージドサービスを使用して，ほとんどメンテナンスフリーでサービスを維持することができます．

しかし，野球場内でのサービスであるため，球場が閉まっている日にはモバイルオーダーは営業時間外になります．営業時間外にサーバーを起動しておくのは不要なコストがかかるので

営業時間外の間はサーバーを停止して，たとえば S3 上に設置した静的な Closed ページをお客様に表示したい

といった要件があります．

他にも

モバイルオーダーのサーバーに何らかの障害が発生した際に，Sorry ページを表示したい
その他，情報共有用途に Info ページを表示したい

といった要件もあります．

Closed Page のイメージ

Sorry Page のイメージ

このような要件を実現するためには，何らかの仕組みが必要になります．通常時であれば，ALB　→ TargetGroup(EC2) でルーティングすれば良いですが，S3 上の静的ページにルーティングの向き先を切り替えたい場合，たとえば ALB のリスナールールを別途作成して，リスナールールの優先度を都度変更する必要があります¹．

設計

ルーティング先を決定する設定値

ALB リスナールールの優先度を変更するためには，「今は営業時間内なのか？/時間外なのか？/時間内だけどシステム障害発生中なのか？/それとも何らかの Info ページを表示したいのか？」といったことがわかるようにする必要があります．そのために，Dynamo DB に設定値を保持するようにしました²．

設定値は OPEN, CLOSED, INFO の3種としました．

設定値	ルーティング先
`OPEN`	EC2
`CLOSED`	Closed ページ
`INFO`	Info ページ

Sorry ページをルーティングする設定値はありません．こちらは，「OPEN なのにも関わらず，EC2 に障害発生してしまっているとき」にルーティングされるものなので，設定値自体は OPEN となります．別途，EC2 の Health を CloudWatch Alarm で確認して，障害発生中かどうかを判断するようにしました．

設定値を参照してルーティング先を切り替える仕組み

この設定値を参照して，定期実行している Lambda がリスナールールの優先度を変更するようにしました³．

Lambda のコードロジックは以下のようになります．

設定値を変更する仕組み

DynamoDB 上の設定値を変更する仕組みは単純なもので，Slack から AWS Chatbot を使用してオペレーターが値を設定する仕組みになっています．

全体像

ここまでの全体像は以下のようになります．オペレーターが横浜スタジアムのスケジュールをもとに設定値を決定し，それに基づいてシステムのルーティング先が自動的に変更されます．

おわりに

以上のような仕組みで，クライアントからのリクエストが適切なエンドポイントにルーティングされるようになっています．今回のような要件を達成するための方法は他にも色々ありますが，一つの事例としてご紹介できれば幸いです．

今後可能な機能開発としては，現在オペレーターが設定値を都度変更しているため，横浜スタジアムのカレンダースケジュールに基づいて自動的に設定値が決まるような仕組みなどを導入して，運用の手間を減らす事ができればより良いと思っています．

「EC2 に障害発生しているときに Sorry ページを表示したい」という要件のみであれば，Route53 のフェイルオーバールーティングが使用できそうですが，今回は他要件もあるため，ルーティング先の切り替えは ALB リスナールールで統一したほうがシンプルで良いと考えました． ↩︎
単純な設定の書き込み/読み取りであれば，SystemsManager ParameterStore の方が適切だったかもしれません． ↩︎
DynamoDB Streams を使用すれば，DynamoDB の設定値変更時に直接 Lambda をトリガーすることが可能なので，よりリアルタイムな変更が可能になります． https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.Lambda.html ↩︎