2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
提供:LINE株式会社
リンクをコピー
記事をブックマーク
小川拡氏:ここからは、システムの実装以外で調査当日までに行った準備についてお話します。まず調査ページや案内するメッセージの配信について検討しました。調査ページへの流入のほとんどはメッセージからとなるため、調査ページのトラフィックをコントロールする上でメッセージの配信について考えることが重要でした。
前半に紹介したように、本調査では約8,300万人に対して回答をお願いするメッセージを送信しました。メッセージを配信すると、内部的にはすべてのユーザーに同時に届くのではなく、受信するユーザー一人ひとりについて順番に配信や通知が行われます。
この配信ペースによって回答が行われるペースも変化します。(スライドを指して)こちらの図は同じユーザー数に対してメッセージを早く配信した場合と遅く配信した場合の回答数の増加ペースのイメージです。
同じメッセージ数を送信する場合でも、早く配信するとピーク時の回答数増加のスパイクは大きくなります。逆にゆっくり配信すると回答数の増加もゆっくりになり、ピーク時のトラフィックを低く抑えられます。
調査ページ自体も多数のリクエストを処理できるように準備を進めてきましたが、失敗の許されないプロジェクトであるため、万全を期すためにピーク時のトラフィックを抑えたいと考えました。
社内でメッセージを大量に配信する場合には、配信ペースをわざと抑える機能の導入を検討することがあります。しかし今回は特定アカウントの友だちだけでなく、全ユーザーにメッセージを届けるために普段のメッセージ配信システムとは異なる配信システムを利用する必要がありました。そのシステムは配信ペースを抑える機能を持っていませんでした。
メッセージの配信システムを改修することも検討しましたが、今回は配信を手動でコントロールすることにしました。配信対象となるユーザーのリストをいくつかに分割しておき、時間をあけて分割配信をすることで疑似的にゆっくり配信するのに近い状態を作りました。
これにより、一度にまとめて配信した場合と比べるとピーク時のスパイクを小さくできると考えられます。
なお、複数回に分割して配信することでオペレーションミスのリスクは高まります。しかし、今回はシステムを改修するには開発期間があまりにも短かったため、改修によって予期せぬ不具合が生じるほうがオペレーションミスのリスクよりも大きいと判断しました。
調査ページと回答の受付部分については事前にパフォーマンステストを行いました。ただし、時間が限られていたため、システム全体を再現してのテストではなく、1ホストに対してのみ簡易的なテストを実施しました。
その結果、少なくとも秒間1,000リクエスト程度は問題なく処理できることがわかりました。リクエストを処理する部分については単にnginxで静的なファイルを配信しているだけなので、インスタンスの追加に対して性能がスケールするはずです。これを踏まえて必要なサーバー台数を検討しました。しかし、過去に例のない取り組みなので、どの程度のアクセスがあるのかは未知数でした。
1つの目安として過去の大規模なキャンペーンで秒間25,000リクエストの実績があったため、この値の2倍の秒間5万リクエストを基準とし、50インスタンスを事前に用意しました。トラフィックについては先ほどご説明したように、メッセージの配信ペースにも大きく影響されます。
今回はメッセージの配信を手動で行うことにしたため、オペレーションを行うチームと開発チームが連携し、モニタリングを随時しながら配信ペースの調整やインフラの増強を行えるようにしました。
システムのモニタリングには、普段から利用しているPrometheusを利用しました。まず、各サーバーにはnode_exporterなど既存のエクスポーターを導入し、基本的なメトリクスをエクスポートするようにしました。
加えて、サービス固有のメトリクスをいくつか出力するようにしました。ログを検証するバッチの処理状況は、実際に処理を行った際にバッチのプログラム自身が出力するようにしました。MySQLに蓄積されたログの総数などは、MySQLのレプリカに対してクエリを発行することで、集計するようにしました。
これらのサービス固有のメトリクスはエクスポーターとして実装するよりもプッシュするほうが楽だったため、Pushgatewayを介して送るようにしました。Prometheusに集まったメトリクスを基にGrafanaでダッシュボードを構築したり、アラートマネージャでアラートを設定したりしました。
さらにこれは1回目の調査の時点では存在しておらず、あとから実装したものなのですが、PrometheusからAPIで回答数を取得し、LINE Notifyで通知する仕組みも構築しました。
(スライドを指して)こちらがGrafanaのダッシュボードとLINE Notifyでの通知の様子です。Grafanaは主に開発者が確認することを想定しています。ファーストビューで回答数や回答数の増加を表示することで調査が問題なく進んでいるのかを一目でわかるようにしています。気になる点があればスクロールしたりダッシュボードを切り替えたりすることで、詳細を確認できるようにしています。
LINE Notifyは関係者全員のいるグループ内に定期的に通知するようにして、能動的に確認しなくても大まかな状況を把握できるようにしています。簡易的な作りですが、チーム全体で数字を共有でき、またそこからコミュニケーションも発生しました。これらの準備をして調査当日を迎えました。
ここからは調査時のメトリクスを見ながら、当日の様子を紹介します。配信当日の回答状況は(スライドを指して)こちらのようになりました。こちらのグラフは回答数、最初の設問の回答と最終回答を合わせた合計イベント数、そして秒間のイベント数の推移を示しています。
3月31日の午前10時頃に小規模なメッセージ配信を行い、その後、モニタリングや最終確認を経て午後から本格的なメッセージ配信を実施しました。
秒間のイベント数は1つの大きな山のようになっていますが、ところどころで秒間のイベント数が下がっている部分があるように、分割してメッセージの配信が行われています。ピーク時の秒間イベント数は毎秒5,000件近くに達しました。もし分割せずに配信していたら、瞬間的なスパイクはさらに大きくなっていたと思います。
メッセージ配信が終わったあとは急速にイベント数は減少していき、2日間を通じてとくにトラブルなく調査を終わることができました。最終的な回答数はおよそ2,500万件、イベント数は6,600万件でした。
しかし実は裏側では一部の処理で遅延が発生していました。(スライドを指して)こちらは調査1日目におけるIDトークンの検証処理で発生した遅延の推移です。一緒に表示されている秒間イベント数は、先ほどお見せしたものと同じものです。
配信が進むに連れて、秒間イベント数が増加していき、秒間2,000件に達したあたりから遅延が生じ始め、一時的に350万件近くのイベントが処理待ちの状態になりました。
その後イベント数が減少していくに連れて遅延は解消していきました。なお、遅延の起きない程度に配信のペースを落とすことも考えられました。しかし、夜遅い時間にユーザーに通知が飛ぶのを避けたかったことと、LINE自体のトラフィックのピークに重なる可能性もあったことから、遅延については許容して早期に配信を終えることを優先しました。
もし、IDトークンの検証まで含めてユーザーからのリクエスト内で同期的に行っていたとすると、レスポンスが遅延したり、最悪の場合はリクエストを正常に受け付けられなかったかもしれません。今回は非同期処理を導入したことで、準備に時間が避けない中でもユーザーに影響が出ることは回避できました。
今回の調査を最初に立てた方針から振り返りたいと思います。まず最小限の仕様でシンプルなシステムを作るという点については、機能を絞り込むことでnginxだけでリクエストを処理する実装に落とし込むことができ、高いパフォーマンスと安定性を担保できました。
段階的に開発を進めるという方針の基、最初に目に見える部分を完成させた上で裏側の仕組みを段階的に整備していきました。これにより不確定要素が多い中でも確実にシステムを構築できました。システムトラブルを回避する設計という点では、非同期処理を導入して一部のコンポーネントが意図した通りに機能しなかったとしても全体に影響が出ないように配慮しました。
当日はIDトークンの検証処理が遅延する結果となりましたが、ユーザーに見えるかたちで影響が出ることは避けられました。
まとめです。我々は新型コロナ対策のための全国調査を開発期間3日、仕様策定やQAを含めた準備期間6日で実施しました。
本調査は8,300万人に対してメッセージを送信し、約2,500万件の回答を集める非常に大規模なものでしたが、そのシステムはシンプルなものでした。シンプルな設計にすることで、短期間での開発と多数のトラフィックを安定して処理することを両立することができました。
以上で発表を終わります。ご清聴いただき、ありがとうございました。
LINE株式会社
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには