海外向けサービスQuipperに起こった変化
Quipperがインドネシア政府より推奨教育サービス認定されたことにより、利用者数は大幅に増加しました。その結果として、アクセスはこれまでの10倍以上を記録することになりました。
インドネシアではロックダウンがあったため、学校が始まるのが遅くなりました。そして、定期試験をQuipper上で実施したところ、一斉アクセスによりサーバダウンが発生してしまいました。
オートスケーリングはコンテナのイメージPull、インスタンスのスケールアウトといった処理が入るため、どうしても5分程度はかかります。つまり、急激なスパイクに対しては対応仕切れない。今回は、まさにオートスケーリングの限界が引き起こしたサーバダウンでした。
対策としては、まず日中は事前にサーバをスケールアウトするという方法をとりました。また、先生には試験開始の24時間以前に登録を依頼し、翌日どのくらいリクエストがくるか、という予測に使う「運用でカバー」の方法もとられました。
けれども、やりたいのはエンジニアリングで解決すること。”できることはなんでもやる”というキーワードが再び登場しました。
事前スケール（Scheduled-Scaling）を実現するに当たって、Global DevelopmentのVPoEとSREが手を組むことになりました。ドメイン知識が豊富なVPoEと、Kubernetesやプラットフォームに詳しいSRE。双方の知見を組み合わせ、対策を講じていきました。
試行錯誤の末、データベースにある試験の開始時間と受験人数の情報をもとに、事前にスケールアウトする、という方法が採用されました。
結果として、トータルでのコストは低減させながらも、ピークに応じたスケーリングを実現することができました。ドメイン知識とエンジニアリングの力が美しく融合した、素晴らしい成果ですね。
まとめ
負荷対策にはエンジニアリングチーム以外の事業に関わるすべての人の協力が必要でした。「運用でカバー」という言葉にはネガティブなイメージがついていますが、必要なタイミングであれば運用でカバーも正となります。問題vs私たちで考え、意思決定していくことが大切です。
事実ベースで判断するための負荷試験の重要性は、ますます高まっていきます。そのためにはパフォーマンステストが必要となるのですが、パフォーマンステストは難しいものです。であるからこそ、複数のチームの協力が必要なのです。
個人的に、エンジニアリング、ビジネス、ドメインが連携して問題と向き合い解決していく様は、とても美しいと感じました。これを書いている私も、読んでいるあなたも、いつ自分のサービスが同様の状況に置かれるかわかりません（むしろ、困るくらいのアクセス急増は体験してみたくもありますね）。そんなときは、このセッションで語られた「なんでもやる」姿勢が重要になるのではないでしょうか。
Ask the Speaker
――ご登壇されていかがでしたか？
「デブサミのテーマがNew Normal。まさにうちの事例だなと確信していたので、話すことができてうれしかった」
――セッションでの発表にあたっての工夫は？
「話の構成として、うまくいったポイントをキーメッセージとして軸にすえた。シンプルでストレートなプレゼンにした」
――参加者に一番伝えたいポイントは？
「何倍まで耐えられるかわからない、負荷試験は難しい。多くの人がそう思っているはずで、その難しいことを乗り越えるにはいろいろな人のコラボレーションが必要。情報交換などがとても重要」
――より本番に沿った負荷テストを行うために工夫した点、工夫しようとした点はありますか?
「国内に関しては本番で流しているクエリをそのまま使った。負荷試験のジレンマは、完全に本番通りとはいかないところ。いかに本番に近い形を再現するかが大切。
海外に関しても難しかった。実際の環境では試験以外のトラフィックも流れているので、それを含めて再現することはとても難しい。本番を完全に再現することは難しいという前提に立って、どこまで近づけるかが勝負」
――AWSのDynamoDBではなくMongoDBを選定した意図は？
「かなり初期からMongoDBを使っていた。スキーマレスDBの流行があった時期に選定された」
――MongoDBの抜本対策で最も効果的だったのは?
「負荷分散としてはシャーディングが一番効果的だった。物理DBを分けるのも効果はあったので、初手としては悪くなかった」
