「超PayPay祭」の高負荷対策――失敗からリベンジへの猶予は3カ月、ヤフーの運用チームはどう乗り切ったのか：特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理（1）

運用管理者に光を当てるオンラインイベント「Cloud Operator Days Tokyo 2021」。「超PayPay祭」における失敗と成功についてのセッション「超PayPay祭による高負荷にショッピングはどのように立ち向かったか」から、自社製プライベートクラウドで運用するWebサービスにおける高負荷対策のポイントを探る。

[谷崎朋子，＠IT]

　通常のセール時の数倍もの利用者が殺到した2020年の「超PayPay祭＋Yahoo!ショッピング大規模セール」。準備万端で挑んだヤフーの負荷対策チームだったが、無念にもシステムダウンに追い込まれた。「来年こそは」とリベンジを誓うチームメンバー。だが、そのリベンジの機会は彼らが想定しているよりも早く訪れた。

　猶予は3カ月。失敗をどう分析し、どのような対策を講じたのか。チームメンバーが「Cloud Operator Days Tokyo 2021」のセッション「超PayPay祭による高負荷にショッピングはどのように立ち向かったか」で明かした。

万全の負荷対策も、「カートにアクセスできない」といった障害が発生

　「超PayPay祭」は、対象期間中に「PayPay」で決済すると「PayPayボーナス」が通常よりも多く付与される、ヤフーの人気キャンペーンだ。2020年10月から約1カ月間開催された同キャンペーンは、年1回の「Yahoo!ショッピング大規模セール」と併催されることになり、さらにはセール最終日に最大44％のポイント還元があるということで、開催発表時から大きな注目を集めていた。

　「それだけに、経営層からの期待値も高く、セール期間中、特に最終日のグランドフィナーレでサービスダウンさせることは絶対に許容されない状況でした」。ヤフー Webエンジニアの信原有志氏は当時を振り返る。

　集客は通常セール時の数倍、システムへの負荷も相当なモノが予想される。そこで同社はセール高負荷対策の専門チームを設置。サービス開発を担当するサービス組織が、想定されるサービスへの負荷とそれを処理する上で必要なリソースの見積もり、過負荷時にシステムダウンさせない機能の実装などを担当。サービス基盤を運用、開発するプラットフォーム組織が、サービス組織が要求した各種リソースの確保や各プラットフォームのSLO（Service Level Objective）の順守を担当する体制を作った。

　対策内容は、深夜帯の負荷試験、特定の時間帯にユーザーが集中しないための、イベントやスケジュールなどの調整、サービスダウンした際のオペレーションの整理、注文の非同期化や障害時専用の静的ページの表示といった過負荷時の対策機能の実装、キャパシティープランニング、スケールアウトなど。万全の対策で、超PayPay祭＋Yahoo!ショッピング大規模セールの開始日を迎えた。

　だが、チームの努力むなしく、障害は発生した。最終日、ポイント最大還元を狙ったユーザーが、日が変わるタイミングで殺到。その数は想定の数倍に及び、結果的にシステムがクラッシュし、一部ユーザーのカートが表示されなくなった。

想定をはるかに超えるアクセスが集中してシステムダウン、一部ユーザーのカートが表示されない障害が発生（ヤフーの講演資料から引用）

　負荷対策は十分だったはずなのに、なぜシステムは落ちてしまったのだろうか？

　「セールなどのイベントでアクセスがどのくらいスパイクするかは、予測が非常に難しい」。そう前置きした信原氏は、問題は予測負荷の計算にあったと続ける。

　「予測負荷は、前年度のセールの予算と負荷をベースに、今年度の予算との比率に基づいて計算しました。つまり、予算が倍になれば負荷も倍になるだろうというもので、予算ベースで負荷を決定していました。この計算式はこれまでの大規模セールでも採用され、大きく懸け離れることがなかったので、この予測から外れることはないだろうと予測していたのです」（信原氏）

　本来チームがすべきだったのは、「予測された負荷に耐える」のではなく、「予測された負荷を超えてもサービスが継続できるようにする」ことだった。課題と目標が明確になったチームは、1年後の大規模セールに向けて改修に取り掛かった。

　だが、事態は急変した。LINEとの経営統合記念で、2021年3月に超PayPay祭を開催することが決定したのだ。

　その時点で、キャンペーンは3カ月後に迫っていた。当然、当初考えていた対策は間に合わない。3カ月で何ができるのか？　信原氏たちは実現可能な有効打を急きょ検討することにした。

猶予は3カ月、負荷試験やRate Limitで対策強化

　ヤフーでは、サービスそれぞれに対する単体負荷試験と、ユーザーの行動を模した全体負荷試験の2つを実施している。セール負荷対策チームは、それぞれにおいて工夫することにした。

　まずは単体負荷試験について、一般的にはリクエスト先や依存システムへの負荷状況などを見ながらテストする。しかし、依存先のシステムも、他のサービス内のシステムや、プラットフォーム組織が提供するシステム、さらに別のシステムに依存しているなど、影響が複雑に絡み合った状態だ。

単体負荷試験の対象（ヤフーの講演資料から引用）

　問題は、ヤフーの開発／運用体制でこうした負荷を見積もるのが難しいことだ。Yahoo!ショッピングとPayPayモールは、1チーム当たり5〜7人、約30チームで運用、開発を担当している。1チーム当たりの担当システム数は、2〜4つ。それぞれで仕様検討からテストまでのビジネス開発、リリース対応から不具合対応までの運用、リソース見積もり、負荷試験などをプランニングしている。つまり、システムごとにチームが異なるので、試験対象のシステム担当から各システムに対してどの程度の負荷がかかるかを見積もるのは困難だったことを同社Webエンジニアの小中史人氏は明かす。

　さらに、依存先のシステムには他のクライアントが存在する。そのため、理想的にはそれらクライアントからのトラフィックも考慮した上で、どの程度の負荷がかかるかを試験で把握する必要もあった。

　だが、時間的な余裕はない。安定稼働必須のシステムに対して、依存先まで含めた全体のシステム構成図を作成。それをベースに、依存先のシステムに対して負荷を試算した。

　試算では、主要システムからの負荷だけを考慮し、プラットフォーム組織が提供するシステムに対しても想定負荷を試算した。そして、結果についてはサービス／プラットフォーム負荷対策担当の複眼でチェック。さらに、負荷試験時にはプラットフォーム組織も待機してリアルタイムに監視する体制を整えた。

　「試験の結果、幾つかのシステムで不具合およびキャパシティー不足が確認されました。その都度、増強したり、実装を修正したりしてから再試験するという流れを繰り返し実施しました」（小中氏）

　一方の全体負荷試験では、単体負荷試験でシステム単体では問題ないことを確認した上で、Yahoo!ショッピングやPayPayモールとして問題なくサービスを提供できるかどうかを確認した。

　用意したのは、ユーザーの行動を模した負荷試験。トップページから検索ページや商品ページ、カートページに遷移するユーザーや、商品ページやカートページに直接アクセスするユーザーのリクエストなどの流れに基づき、各システムに対して想定負荷をかけた。

全体負荷試験の概要（ヤフーの講演資料から引用）

　結果、幾つかのシステムで不具合およびキャパシティー不足を確認。単体負荷試験と同様に、増強や実装修正、構成変更を行ってから再試験する流れを、問題が解消されるまで続けた。

　「特にこの試験によって、複数のシステムが利用するサービスでは単体負荷試験以上の負荷がかかり、これが原因でシステムダウンするケースを洗い出すことができました」（小中氏）

　この他、想定負荷を超えた場合のシステムダウンを防ぎつつ、購入可能な状態を最低限でも維持するために、同社は「Rate Limit」（レート制限）を導入した。

　特に実機を利用しているシステムでは、「即時増強」とはいかない。注文システムは、その良い例だ。そこで、購入時に必ず経由するカートページにRate Limitを設定。さらに注文手続きに進んだ場合は、注文システム手前にもRate Limitを設定した。Rate Limitに引っ掛かった場合は、カートページに再アクセスするよう促すページに遷移。これにより、システムをダウンさせることなく、ユーザーにカート表示や注文機能を提供できるようになった。

Rate Limitの使用イメージ（ヤフーの講演資料から引用）

サービスとプラットフォームの垣根をなくした試験体制でリベンジ

　続いて、チームはプラットフォーム側の負荷対策に取り掛かった。

　ヤフーのプライベートクラウドは、IaaS、PaaS、CaaSで構成され、Yahoo!天気やYahoo!ニュースだけではなく、超PayPay祭のような大規模セールに関わるショッピングのアプリケーションが多く稼働している。「特定のサービスだけに注力せず、常に安定したプラットフォームを提供し続けることが求められました」と同社マネージャーの大岩朗氏は述べる。

ヤフーのプライベートクラウド概要（ヤフーの講演資料から引用）

　同時に、大規模サービスなので関連コンポーネントは多く、超高負荷時のプラットフォームへの影響度合いを掌握するのは非常に難しかった。

　そんな中で、チームは前回の超PayPay祭で判明した課題を一つずつクリアしていくことを徹底した。セールの影響を受けるプラットフォームの把握不足やプラットフォーム上で緊急スケールアウトする利用者が当日に現れる課題については、システム構成図の作成や本番同等かつそれ以上の負荷試験を実施してボトルネックや問題を確認、対策を講じた。また、突発的に開催することになったセールなので、このためのリソースがキャパシティープランニングに入っていないという課題については、余剰リソースをかき集めて、IaaS/PaaS/CaaSで500台近くの増強を実施した。

　「負荷試験中にCPU負荷が上がり過ぎて、一部ラックの電力が上限付近に到達し、ラックが丸々落ちかけたり、PaaS環境の一部でCPUが超高負荷に陥ったりと、ひやりとさせられることもありました」と明かす大岩氏。こうした数々の困難を乗り越え、奮闘の結果、3カ月という短い対策期間にもかかわらず、一番負荷が高くなるグランドフィナーレを無事に乗り切ることができたという。

　「しかも、Yahoo!ショッピングとPayPayモールで、キャンペーン最終日の取扱高が前回比約1.8倍と、過去最高を記録しました。無事、リベンジは成功に終わりました」（大岩氏）

　最後に大岩氏は、高負荷に立ち向かうためのアドバイスを、サービス運用者とプラットフォーム運用者のそれぞれで幾つか挙げた。

　サービス運用者（クラウド利用者）は、必要なキャパシティーおよびリソースにおいて適切に見積もること、プラットフォーム担当者にもシステムを知ってもらうこと、想定以上の負荷がかかっても、サービスを提供し続けるための設計や対策が必要だ。

　プラットフォーム運用者は、突発的なイベントを常に想定して備えておくこと（余剰リソースなど）、サービス側とプラットフォーム側の相互理解を促して、より良い関係を目指すこと、適切なプラットフォーム利用の啓蒙（けいもう）を怠らないことが求められる。

　「サービス運用者とプラットフォーム運用者が疎にならず、より密に連携することが大切と実感しました」（大岩氏）

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理

ITがビジネスを加速させる昨今、多くの新規サービスが開発、リリースされ、運用管理者には安定したサービスの供給や、利用動向のログの解析などが求められている。だが、これに伴い解析すべきログや拾うべきアラートも増す一方となり、多大な負担が運用管理者の身に振り掛かっている。また、新規サービス開発でのクラウド活用、基幹システムのクラウド移行が進み、可用性や柔軟性といったクラウドならではの特性を生かす、いわゆるクラウドネイティブなアプリケーションの運用が増え、コンテナやマイクロサービスといった複雑な運用管理も求められている。しかも、オンプレミスに残さざるを得ないサーバとのハイブリッドな運用も並行しなければならない。このような中、従来の手法や技術では、とうてい運用管理業務が回らず、ビジネスに貢献することができないのが実情だ。現状を打破するためには、従来の慣習を疑い、新しい技術や自動化、AI（人工知能）などを取り入れ、現状に合った新たな運用管理の手法を実践することが大前提となる――本特集では、運用管理の最新技術や使いこなし方を徹底的に深掘りする。

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理