メッセージの配信ペースにも工夫を
調査当日までにはシステム実装以外にもさまざまな準備を行った。
まずは調査ページに案内するメッセージの配信について。調査ページの流入のほとんどはメッセージとなるため、調査ページのトラフィックをコントロールする必要があったという。本調査では約8300万人に回答を促すメッセージを送信する。「万全を期すためにピーク時のトラフィックを抑えるような配信ペースにしたいと考えた」と小川氏。だが、普段使っているメッセージ配信の仕組みには配信ペースを抑える機能を有していない。
そこで「配信を手動でコントロールすることにした」と小川氏は語る。オペレーションを行うチームと開発チームが連携し、随時モニタリングしながら、配信ペースの調整やインフラの増強を行ったという。システムのモニタリングには普段から利用しているPrometheusを採用。その他、Grafanaを用いてダッシュボードを構築したり、Alert Managerでアラートの設定を行ったりした。さらに1回目の調査以降、実装したものとして、PrometheusからAPIで回答数を取得し、LINE Notifyで通知するような仕組みも構築。「Grafanaでは、開発者が問題なく調査できているか回答数や回答数の増加を一目でわかるようにしています。またLINE Notifyを使って、定期的に通知することで、能動的に確認しなくても大まかに確認できるようにしています」（小川氏）
3月31日の午前10時頃に小規模なメッセージ配信を行い、その後、モニタリングや最終確認を経て、午後から本格的なメッセージ配信を実施。「ピーク時のイベント数は毎秒5000件近くに達していた。2日間を通じて特にトラブルなく調査を終えることができた」と小川氏は振り返る。
最終的に集めた回答数は約2500万件。その裏側では、一部の処理で遅延が発生していたという。配信が進むにつれ、秒間イベント数が増加し、秒間2000件に達したあたりからIDトークンの検証に遅延が生じ始め、1次的に350万件のイベントが処理待ちになったのだ。もちろん、遅延が起きないように配信を抑えることもできたが、「夜遅くにユーザーに通知が飛ぶことと、LINE自体のトラフィックのピークに重なることを避けるために、遅延を許容して配信を早期に終えることを優先した」と小川氏は話す。こういうことができたのも、先述したように非同期処理を導入したからだ。
「8300万人に対してメッセージを送信し、2500万件の回答を集める非常に大規模な調査をたった6日という開発期間で実現できた最大の要因は、シンプルな設計にしたこと。そうすることで短期間での開発と多数のトラフィックを安定して処理することを両立することができた」
最後にこう語り、小川氏はセッションを締めた。
