こんにちは。
経営企画室 プロトタイプビルダーの山下です。
ラーニングサービス本部 テクニカルトレーニング第一部と兼務でプロトタイプビルダーを始めました。
身の回りで行っているちょっとしたプロトタイピングなどを紹介していきたいと思います。
今日ご紹介するのは、トレーニングコース中に受講者さんからのご質問を匿名で受け付けるご質問フォームの最近のアーキテクチャです。
2019年6月からブログでは更新していなかったのですが、少しずつ見直しを図ったり、機能追加していました。

2019年6月時点のアーキテクチャ

2020年10月時点のアーキテクチャ

ここ最近のアーキテクチャは、アイキャッチにも使用していますこちらです。

このご質問フォームは、匿名でご質問を受付できる、という目的だけではなく、このアーキテクチャそのものを、Architecting on  AWS、Developing on AWSというAWS認定クラスルームトレーニング(現時点では山下実施時のみ)でベストプラクティスを解説するための体験型デモとしての役割も担っています。

疎結合化

AWSの設計/開発ベストプラクティスの一つに、疎結合化があります。
このブログでは、ソフトウェアの制約があるようなケースで、疎結合化によって機会損失を減らし、耐障害性をどのようにして向上するか、一つのユースケースとして解説します。

RocketChatの役割と位置づけ

解説しやすくするため、対象のアーキテクチャを絞ります。

データの流れは、S3にデプロイした静的フォームに入力されたご質問メッセージが、API Gatewayに送信されて、SNSからSQSへファンアウト、Lambdaがキューコンシューマーとしてメッセージを受信してRocketChatというOSSのAPIにPOSTしています。

こうすることで、受講者さんからのご質問を受講者さん全員が手元で共有することができ、講師やサブ講師からの返答もリアルタイムに確認することができます。
匿名ですので、ご質問の敷居も下がります。

RocketChatはOSS(オープンソースソフトウェア)です。
構築のやり方によっては、データベースを別のインスタンスにして、複数のEC2やコンテナで冗長化を図ることも可能かと思いますが、今回は迅速にシンプルに構築するために、Ubuntuサーバーで "sudo snap install rocketchat-server"  コマンドを実行することによって、一式をインストールしています。

例えば、このRocketChatサーバーを、自分たちではカスタマイズすることのできない制約付きのソフトウェア、または外部のサービスAPIと仮定します。
そう仮定したとき、RocketChatはいつ止まるか分からないSPOF(単一障害点)と位置づけることができます。

RocketChatを単一障害点と位置づけた上で、RocketChatサーバーが停止しても受講者さんがご質問を送り続けられる設計を考えたいと思います。

SQSを使った疎結合化

LambdaからRocketChat APIへのPOSTが失敗してもSQSにご質問メッセージは残ります。
そして、デッドレターキューを指定しているので、30回再試行してPOSTできなかったメッセージはデッドレターキューへ移動します。

RocketChatが復旧してからメッセージをLambdaに渡してあげれば、メッセージを失うことなく、RocketChatへPOSTできます。

障害発生時

RocketChatをあえて、t3a.small という小さめのインスタンスで起動しています。
だいたい3日コースであれば、1回はCPUが高騰してユーザーアクセスも、APIアクセスも受け付けられなくなる事象が発生します。
今のところ、原因はCPU高騰で、再起動によって復旧するので、CloudWatchアラームで自動再起動を設定しています。
発生した場合は10分ほどRocketChatにはアクセスできなくなりますが、その間もご質問は送信し続けていただくことができます。
そうして復旧後に、CloudWatchアラームが実際にどう動いたかを見ていただくこともできます。
(t3なのでCPUバーストの解説にも重宝しています)

AWSで構築したツールを使いながら、AWS認定クラスルームトレーニングを受講されてみてはいかがでしょうか。
皆さまのご受講を心よりお待ちしております。