先生!CognitoがToo Manyです!

はじめまして。
QBオンライン担当にアサインされましたSです。

今回はQBオンライン内製化のミッションを担った私がブログを書かせていただきます。
QB(クエスチョン・バンク)についてはこちらをご覧ください。
https://informa.medilink-study.com/regularpost/11206/

QBオンラインはお陰様で、大変多くの方にご利用頂いている状況ということもあり、
昨年度の医師国家試験直前のピーク時にはシステムが負荷に耐えられない状況となっていました。

この状況をなんとかしなければとアサインされたのが私を含めた3名です。

そのQBオンラインの現在の構成について軽く触れますと、AWSのサーバーレスで構築されたシステムとなっています。
Lambda、APIGateway、DynamoDB、Cognito、S3(フロントエンドのVue.js格納用バケット)etc…という鉄板の構成です。

Lambdaが水平スケーリングのため、負荷に耐えられないのかな…と、
アサイン前は考えていたこともありましたが、どうやら原因は異なるようで。

問題はCognitoの利用方法にありました。

Cognitoをはじめ、各種サービスには様々な制限があります。
クラウドファーストの時代には、必ずチェックしなければならない事項ですね。
※参考リンク:Amazon Cognito における制限
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/limits.html

今回、ひたすら出力されていたエラーは「429 Too Many Requests
それぞれの API で定められたリミット (1秒あたり) を超過した場合に発生するものです。

AWSへも問い合わせたそうですが、以下の回答が来たとのこと。


synchronize操作を複数のクライアントから多数行われたことによりスロットルが発生していたものであると考えられます。
synchronize操作は、実際にはListRecordsとUpdateRecordsの操作から成り立ちますので、データを更新されるような動作をされているのであれば、実際のところUpdateRecordsについてもスロットルが発生していた可能性はございます。
【今後の対応について】
基本的に、アプリケーション内で実行されているsynchronize操作の数を減らして頂くことが対策として有効になります。
以下のドキュメントに記載がございますように、現在はAppSyncというサービスがございますので、こちらをご利用いただくことも併せてご検討頂ければと思います。

…一言で言ってしまえば、設計から見直しましょう、ということですかね。
そういった経緯で、私たちがアサインされた次第であります。

そんな私たちが現在行っていることはCognitoを用いた認証処理の見直しです。
現在のアーキテクチャをゼロから作り変えることがマストとなります。

ユーザーの方には快適に利用頂くことが必須事項となりますので、負荷に耐えられることはもちろんですが、
さらにオフラインでも同期が取れるような抜本的改造をしております。
こちらは隣に座っているフロントエンド担当が絶賛PoC中です。
※当ブログでたびたび扱われているfirebaseをお試し中。
私はAWSのアーキテクチャと機能追加に追われる中、楽しそうにやっていて羨まs。

話が逸れましたが、クラウドを用いた短期間の開発が出来る今の時代だからこそ、
それぞれのサービスについて熟知して設計をすることが何よりも大切なことであると改めて実感した次第です。

タイトルはひどいですが、決してCognitoが悪いわけではありませんので!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Bitnami