WebSocket×AWS Lambdaで挑戦するリアルタイム通信

みなさんこんにちは、辺見です。今回はリアルタイム通信についてお話しさせていただきます。よろしくお願いいたします。私は、セキュリティコンサルタントです。沖縄ははじめてです。ワクワクしております。

みなさんは、リアルタイム通信が必要なアプリケーションをつくりたいと思ったことはありませんか？私はスライドのような条件でクライアントからリクエストいただき、つくることになりました。

そのときは、想定最大同時接続数とグローバルリーチという条件があったため、サーバーレスでつくることになりました。

今回の発表では、リアルタイム通信をつくるにあたり、どんなことに失敗したのかをお話しさせていただきます。

ところで、リアルタイム通信ですが、実装するときは以下のスライドに記載したようなものが候補にあがるかと思います。

今回はWebSocket通信を選びました。AWSでつくることにしたのですが、AWSのサーバーレスでSocket通信を実装します。スライドのようにフロントエンドはVue.js、バックエンドにはNode.jsを選びました。

データベースはAWSのサービスです。スライドではいくつかのAWS構成案が提示されております。

それぞれの案にはバックエンドの構成に違いがあります（以下は採用した構成）。

この構成ではAPI Gatewayに2時間のコネクション制限があり、これは解除できませんでした。また、Lambdaはユニキャストしか使えませんでした。2時間のクォータ制限ですが、クォータ解除はありませんでした。

次に、ユニキャストしか使えないこととDynamoDBについてお話しさせていただきます。こちらはチャットアプリの一般的な画面です。画面内のボタンを押すことで発火するアプリケーション内部の動きを整理します。

まず1番でログインボタンを押すと、Amazon DynamoDBでコネクションIDを作成します。2番で送信ボタンを押すことで、メッセージをDynamoDBに格納できます。

3番でメッセージは画面に表示されます。4番で退出ボタンを押すと、DynamoDBからコネクションIDを削除するという仕組みです。

次にアプリケーションを含めた全体像を見ていただきます。

この構成の場合、ユニキャストでDynamoDBに入っている全コネクションIDに対し、Lambdaでメッセージを1件1件ループで送信することになります。ここで課題が見えました。 

ユーザーへメッセージが届くのが遅かったり、届かなかったりする事象が発生しました。

サーバーサイドのログにはエラーが出ていましたが、開発者側からすると「チャット画面にログインしている人が少ないので、処理は問題なく通るはずなのですが、どうして…？」という状態になりました。

「幽霊コネクションID」という誤算を乗り越えて

トラブルシュートとして、ユーザーのコネクションIDがDynamoDBに残りつづけていることを確認しました。「切断処理を実施したはずなのに、なぜ残っているのか？」という疑問がありました。

ユーザー側のコードを解析したところ、ユーザーがチャットから離脱する際に、退出ボタンを押さずにブラウザを閉じていました。

その結果、API Gatewayはユーザーの離脱を認識できず、コネクションIDがDynamoDBに残りつづけていました。

解決方法として、新しくユーザーがログインしたときの処理に別の処理を追加しました。まず新規ユーザーの接続を確認します。

その後に全クライアントへのメッセージを送信する処理において、このとき、ユーザーがすでにブラウザを閉じていればエラーを検知し、メッセージ送信時にエラーが発生した場合、該当のコネクションIDをすべて削除するようにしました。

これで不要な処理がなくなり、コードが改善されました。

もう一つ、AWSが公式に発表している構成があります。こちらの構成を選んだらどうなっていたのかという点は、こちらのスライドをご覧ください。

ご清聴ありがとうございました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）