想定外の負荷にエンジニアリングでどのように挑んだか
データによる需要予測と負荷緩和
対応するべき負荷増加は、目の前で起こっていました。まずはすぐに取れる対策を、ということで、データによる需要予測を行うことにしました。しかし、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倍のトラフィックまで耐えられることが確認できました。
営業と連携した需要予測と負荷緩和、エンジニアリングでのアプローチ、そして抜本的なMongoDBの改善。こういった対策を講じることで、大きな障害ゼロで緊急事態宣言下でのピークを乗り切ることができました。
