CodeZine(コードジン)

特集ページ一覧

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

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

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

目次

想定外の負荷にエンジニアリングでどのように挑んだか

データによる需要予測と負荷緩和

 対応するべき負荷増加は、目の前で起こっていました。まずはすぐに取れる対策を、ということで、データによる需要予測を行うことにしました。しかし、2020年は完全にイレギュラーな年。COVID-19の影響により、これまでの定量的データによる予測では太刀打ちできませんでした。そこで、営業から定性情報をヒアリングし予測に反映する、という方法をとりました。

 この危機を乗り切るために、セクションを超えた情報連携を強化。例えば導入校が増加する場合や一括受注の可能性がでてきたタイミングで共有する、その情報をもとに登録日や利用開始日を分散し負荷を平準化する、といったことを実施していました。運用で負荷をなだらかにする、というのは地道ながらも効果的な方法ですね。

エンジニアリングでできることはなんでもやった

 続いては、エンジニアリングでの対処。「できることはなんでもやった」という言葉の通り、とにかくさまざまな打ち手が講じられました。

 SREの取り組みは以下の通り。

  • RDS PostgreSQLのAurora化
  • Reverse ProxyのScaleup
  • HPA導入
  • Worker Node Group分離
  • Memcached Scaleup
  • Amazon GuardDuty導入

 Web開発者の取り組みとしては以下のようなものがありました。

  • 意図しない実装による不要なupdateの削減
  • 不要なWriteの削減
  • 不要なデータの削除
  • 学習データ更新サービスのrate limiting
  • Native ClientからのAPI call数削減
  • MongoDBへの抜本的対処

 そしていよいよ、本丸であるMongoDBへの抜本的対処が始まりました。

 まず、Write Access/データ量ともに多い学習データをDBごと分離。本当はひとつのDBで扱いたいため、これは苦肉の策でもありました。

 続いて、UsageDBをAtlasへ移行し、シャーディングを有効化しました。運用負荷を下げるため、マネージドサービスであるAtlasを使ったとのことです。

 MongoReplayによるパフォーマンステストを行ったところ、現状の3倍のトラフィックまで耐えられることが確認できました。

通常の3倍のトラフィックが来ても耐えられることが明らかになった
通常の3倍のトラフィックが来ても耐えられることが明らかになった

 営業と連携した需要予測と負荷緩和、エンジニアリングでのアプローチ、そして抜本的なMongoDBの改善。こういった対策を講じることで、大きな障害ゼロで緊急事態宣言下でのピークを乗り切ることができました。


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

バックナンバー

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

もっと読む

著者プロフィール

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

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

あなたにオススメ

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