CodeZine(コードジン)

特集ページ一覧

緊急事態宣言で負荷急増! 想定外の危機にスタディサプリはどう対処したか?【デブサミ2021】

【19-D-6】想定外の負荷を乗り切ったオンライン教育サービスの裏側

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/07/12 11:00

目次

海外向けサービスQuipperに起こった変化

 Quipperがインドネシア政府より推奨教育サービス認定されたことにより、利用者数は大幅に増加しました。その結果として、アクセスはこれまでの10倍以上を記録することになりました。

実に10倍以上ものアクセスを記録したQuipper
実に10倍以上ものアクセスを記録したQuipper

 インドネシアではロックダウンがあったため、学校が始まるのが遅くなりました。そして、定期試験をQuipper上で実施したところ、一斉アクセスによりサーバダウンが発生してしまいました。

一斉アクセスによるサーバダウン。一部の生徒が試験を開始できなかった
一斉アクセスによるサーバダウン。一部の生徒が試験を開始できなかった

 オートスケーリングはコンテナのイメージPull、インスタンスのスケールアウトといった処理が入るため、どうしても5分程度はかかります。つまり、急激なスパイクに対しては対応仕切れない。今回は、まさにオートスケーリングの限界が引き起こしたサーバダウンでした。

 対策としては、まず日中は事前にサーバをスケールアウトするという方法をとりました。また、先生には試験開始の24時間以前に登録を依頼し、翌日どのくらいリクエストがくるか、という予測に使う「運用でカバー」の方法もとられました。

 けれども、やりたいのはエンジニアリングで解決すること。”できることはなんでもやる”というキーワードが再び登場しました。

 事前スケール(Scheduled-Scaling)を実現するに当たって、Global DevelopmentのVPoEとSREが手を組むことになりました。ドメイン知識が豊富なVPoEと、Kubernetesやプラットフォームに詳しいSRE。双方の知見を組み合わせ、対策を講じていきました。

 試行錯誤の末、データベースにある試験の開始時間と受験人数の情報をもとに、事前にスケールアウトする、という方法が採用されました。

Datadogを活用し事前スケーリングを実現
Datadogを活用し事前スケーリングを実現

 結果として、トータルでのコストは低減させながらも、ピークに応じたスケーリングを実現することができました。ドメイン知識とエンジニアリングの力が美しく融合した、素晴らしい成果ですね。

だいぶ実体にあったスケーリングができている
だいぶ実体にあったスケーリングができている

まとめ

 負荷対策にはエンジニアリングチーム以外の事業に関わるすべての人の協力が必要でした。「運用でカバー」という言葉にはネガティブなイメージがついていますが、必要なタイミングであれば運用でカバーも正となります。問題vs私たちで考え、意思決定していくことが大切です。

 事実ベースで判断するための負荷試験の重要性は、ますます高まっていきます。そのためにはパフォーマンステストが必要となるのですが、パフォーマンステストは難しいものです。であるからこそ、複数のチームの協力が必要なのです。

 個人的に、エンジニアリング、ビジネス、ドメインが連携して問題と向き合い解決していく様は、とても美しいと感じました。これを書いている私も、読んでいるあなたも、いつ自分のサービスが同様の状況に置かれるかわかりません(むしろ、困るくらいのアクセス急増は体験してみたくもありますね)。そんなときは、このセッションで語られた「なんでもやる」姿勢が重要になるのではないでしょうか。

Ask the Speaker

――ご登壇されていかがでしたか?

 「デブサミのテーマがNew Normal。まさにうちの事例だなと確信していたので、話すことができてうれしかった」

――セッションでの発表にあたっての工夫は?

 「話の構成として、うまくいったポイントをキーメッセージとして軸にすえた。シンプルでストレートなプレゼンにした」

――参加者に一番伝えたいポイントは?

 「何倍まで耐えられるかわからない、負荷試験は難しい。多くの人がそう思っているはずで、その難しいことを乗り越えるにはいろいろな人のコラボレーションが必要。情報交換などがとても重要」

――より本番に沿った負荷テストを行うために工夫した点、工夫しようとした点はありますか?

 「国内に関しては本番で流しているクエリをそのまま使った。負荷試験のジレンマは、完全に本番通りとはいかないところ。いかに本番に近い形を再現するかが大切。

 海外に関しても難しかった。実際の環境では試験以外のトラフィックも流れているので、それを含めて再現することはとても難しい。本番を完全に再現することは難しいという前提に立って、どこまで近づけるかが勝負」

――AWSのDynamoDBではなくMongoDBを選定した意図は?

 「かなり初期からMongoDBを使っていた。スキーマレスDBの流行があった時期に選定された」

――MongoDBの抜本対策で最も効果的だったのは?

 「負荷分散としてはシャーディングが一番効果的だった。物理DBを分けるのも効果はあったので、初手としては悪くなかった」



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:【デブサミ2021】セッションレポート

もっと読む

著者プロフィール

  • 小田中 育生(オダナカ イクオ)

     開発(Develop)を愛する人たちの集まり、DevLOVEによく出没する人。  所属する企業においては、研究開発のディレクションとエンジニアがいきいきと働けるDX(Developer eXperience)を重視した風土づくりという両輪を回し続けている。  近年はアジャイル開発に助けられてい...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5