皆様こんにちは、ユニファ CTO の赤沼です。
もう1ヶ月以上前になってしまいますが、 AWS Startup Architecture of the Year Japan 2020 で優勝したことはこのブログにも書かせていただきました。
ですが実際のアーキテクチャの内容についてはほとんど書いていなかったので、今回は改めてどのような点が Well-Architected であると評価されたのか、ピッチでアピールした内容を説明させていただきたいと思います。 ピッチで使用したスライドは下記に公開していますので、よろしければご覧ください。
www.slideshare.net
ピークタイムに合わせた Auto Scaling
iPadから送信される午睡チェックデータを受け取るサーバサイドのRailsアプリケーションはEC2インスタンス上で稼働しています。ピークタイムはある程度特定されていますので、時間指定でオートスケールし、インスタンス数を増やして負荷に対応します。午睡チェックの開発開始当初は今ほどにコンテナ関連の環境が充実していなかったり、メンバーのナレッジ等の都合でコンテナ化はしませんでしたが、アクセスパターンがある程度読めて、急激なトラフィック増加の懸念もあまりないプロダクトであれば、EC2でも十分に安定的な運用ができますので、何でもコンテナ化するのではなく、それがどれぐらいメリットがあるのか、ビジネスに貢献するのかを考えてアーキテクチャを選定するのが良いかと思います。
Redis を使用した処理順番の担保
サーバサイドで受け取ったセンサーデータは、後述するように SQS に格納され、Worker によって DynamoDB に格納されます。その際に Worker が複数の場合には SQS からデータが取り出される順番は保証されません。ただこのプロダクトにとっては処理順番も重要ですので、サーバサイドでデータを受け取るとまず Redis(ElastiCache) に午睡チェックシートの各セルのステータスをフラグ情報として書き込みます。そして Worker が SQS からデータを取り出した際には、そのフラグ情報を確認し、期待した通りのステータスになっていれば DynamoDB に書き込むことで、処理順番を担保するようにしています。
SQSを介した非同期処理によるDynamoDBへの書き込み
このプロダクトのアクセス特性として、5分毎に数千施設の iPad アプリから一斉に午睡チェックシートのデータが送信されてくるという点があります。それをサーバサイドで直接 DynamoDB に書き込もうとすると、 DynamoDB のスケールが間に合わない、もしくはオンデマンドキャパシティーでオートスケールが間に合ったとしても、スパイクするアクセスパターンの最大値にフィットしてしまい、利用料金が高額になってしまうということになります。そこでデータを一度 SQS に格納し、Worker が非同期で順次処理していくようにすることで、安定的に処理をしていくと共に、キャパシティー値をリーズナブルな範囲に止めておくことができています。
また、Worker は EC2 インスタンスに相乗りしているため、オートスケールによって EC2 インスタンスが増えると Worker も増えるのですが、その場合にキャパシティーの設定値を超過しないように、 ElastiCache に DynamoDB のキャパシティーの設定値を登録しておき、各 Worker は起動時に自身の情報を ElastiCache に登録すると共に、稼働中の Worker の情報とキャパシティーの設定値を取得し、キャパシティーを超えないように書き込み速度を調整するようにしています。
DLQを使用した失敗データ対応
SQS から取り出した午睡チェックデータが正しく処理されなかった場合、10回まではリトライされますが、10回処理に失敗したデータは DLQ（Dead Letter Queue）に格納され、エンジニアに通知が来るようになっています。エンジニアは通知を受けるとそのデータの内容を確認し、対応が必要であれば対応を行います。対応が必要ないデータは4日間DLQに格納されたままになると削除されます。
Design for Failure
プロダクトの利用中に、ネットワーク障害等で iPad アプリがサーバに接続できなくなった場合に、既に午睡チェック業務が開始されている状態であれば午睡センサーと iPad アプリ間だけで最低限の午睡チェック業務が継続可能になっています。
セルラー回線使用によるネットワーク安定性の担保
iPad アプリからサーバへの接続は、 SORACOM Air Sim によるセルラー回線を使用しています。これによって保育園の Wi-Fi 環境の有無や安定性に左右されることなく、安定的なネットワーク接続を提供することができます。
また、サービスの導入時に保育園側で Wi-Fi 接続の設定を行うのはハードルが高い場合も多いのですが、SORACOM Air Sim をセットし、アカウント登録も済ませた状態で iPad や午睡センサーをお届けすることで、箱から出したらそのまますぐにお使いいただくことができるようになっていますので、導入に対する保育園側のハードルを下げることにも役立っています。
まとめ（そして We are hiring!!）
以上がピッチの中でアピールさせていただいた、ルクミー午睡チェックの Well-Architected なポイントになります。アーキテクチャには絶対的な正解はなく、そのプロダクトの特性や制約、ビジネスメリットを考慮して適切な選択をしていくべきですが、ご紹介した内容が参考になれば幸いです。
そしてユニファでは、より良いプロダクトを提供するためのアーキテクチャ構成に挑戦したいインフラエンジニアの方を始めとして各種ポジションを絶賛募集中ですので、興味がありましたらぜひご連絡ください！！
