linotice

linotice

2021.11.15

クラウドオペレーターアワード2021受賞! ──「超PayPay祭」のインフラを支えたヤフーエンジニアの底力

画像
クラウド運用者に焦点を当てた技術者向けのテックイベント「第2回Cloud Operator Days Tokyo 2021」(以下、CODT2021)で、ヤフーのエンジニアチームが実行委員会賞を受賞しました。チームが発表したのは、2020年秋と2021年春にYahoo!ショッピングで開催した「超PayPay祭」の高負荷対策。膨大なアクセスで予期せぬ不具合が発生した経験を踏まえ、新たな対策と十全なテストを実施。2度目の「超PayPay祭」では、トラブルもなく、前回を上回るアクセスをさばくことに成功しました。その対策と課題解決への取り組みについて聞きました。

プロフィール

COOショッピング統括本部プロダクション2本部
サービスプラットフォーム技術部SRE 小中 史人
Yahoo!ショッピングにおける広告配信システムや顧客ターゲティングシステムの刷新、汎用配信システムの要件定義や設計・開発・テスト・運用およびプロジェクトリーダーを担当。
COOショッピング統括本部プロダクション2本部
サービスプラットフォーム技術部SRE 信原 有志
Yahoo!ショッピングの運用開発に従事。主に Kubernetesを用いた基盤構築やアプリケーションの設計・開発を担当。前職は調理師。
テクノロジーグループシステム統括本部
クラウドプラットフォーム本部技術1部コンピュート 大岩 朗
プライベートクラウド(IaaS)の開発と運用に従事。2020年度はクラウド領域の負荷対策を担当。また、GPUインフラやSDSなどにも関わっている。CODTの実行委員としても活動中。

2020年秋の「超PayPay祭」。グランドフィナーレで何が起こったのか

Yahoo!ショッピングでは毎年11月11日前後に「いい買い物の日」として大規模なセールを行ってきました。2020年からは名称を「超PayPay祭」に変え、Yahoo!ショッピングの事業部ではもちろんのこと、全社的にも注目度の高い大規模なイベントになっています。
例年、最終日の「グランドフィナーレ」はポイント還元率が1年を通して最も高く、多くのユーザーが訪れるため、その負荷は通常の1.5倍と推定されました。その対応のために「セール高負荷対策チーム」が組織されたのは、セール半年前の2020年3月のこと。Yahoo!ショッピング・ヤフオク!などのサービス組織のSRE(サイトリライアビリティ・エンジニア)や、クラウド・データベースなどのプラットフォーム組織のエンジニアなど、総勢10数名が集められました。

——まずは、高負荷対策チームがどのようなものなのか教えてください。

ヤフー全体の開発組織は、サービス開発を行うサービス組織と、その基盤を開発・運用するプラットフォーム組織があります。今回のセール対策ではサービス組織側から私と小中さん、プラットフォーム組織からは大岩さんが担当として招集されました。
サービス組織の主な役割は、想定されるサービスへの負荷見積もり、要求されるマシンリソースやネットワーク通信量の算出、過負荷時のアプリケーションレイヤーでの対策でした。プラットフォーム組織側は、サービス側から要求されたリソースの確保、各プラットフォームのSLO(サービスレベル目標)の遵守が任務になります。
「超PayPay祭」は経営層からの期待も高く、なによりユーザーのために、当日のサービスダウンは絶対に許されないという思いをもっていました。まずは「ユーザーが確実に商品を買えること」が大前提。それにプラスアルファとして、検索やトップページへの閲覧導線など、Yahoo!ショッピングに訪れたユーザーが使う基本的な機能はストップさせないことが目標でした。

これまでも大規模セールのときは、障害は少なからず発生していました。その都度、改修が行われ、同じ不具合が起きない体制で取り組んできたのです。

私たちプラットフォーム組織は、ショッピング事業部から共有された情報をもとに各プラットフォームのリソースを割り当て、常に安定したプラットフォームを提供することがミッションです。例えば、これまでもショッピングの大規模セールにてネットワーク帯域に懸念がある状態となっていたことに対して事前対策を行っていました。

ただ、ショッピング側としては、万全の自信はなかったというのが正直なところ。 ただ、さまざまな対策を行っても、想定を上回るアクセスなど想定外の出来事は起きるものなので、どこまでリスクを洗い出して対策ができているのか、直前まで不安でしたね。

——そこで迎えた2020年秋の「超PayPay祭」ですが、どんな障害が発生したのですか。

グランドフィナーレの前日までは、なんとか持ちこたえていました。しかし、還元率が最も高いグランドフィナーレの最終日、深夜0時になった瞬間から見積もりの数倍規模のアクセスが殺到。 その負荷でカートシステムがクラッシュし、商品を購入しようとしても、ユーザーがカートのページにたどり着けない状態になってしまいました。われわれの予想をはるかに超えるアクセス数だったのです。

グランドフィナーレの日の深夜は、対策チームがオフィスや自宅で待機して、アクセスログを監視していました。例年の傾向では、深夜2時にはだいたいアクセス数も落ち着いていく。それを確認できたら、安心して眠れるはずでした。

だいたい深夜2時には待機は終了し、解散という予定でしたね。

ただしすべてのアクセスができなくなったわけではなく、一部の注文は受け付けることができました。しかし、注文したはずなのに注文履歴が表示されない障害も同時に発生したのです。
注文を処理するデータベースが非常に高負荷となり、ユーザーの注文情報を取得できなかったことが原因です。当然ながら、注文できていないと思ったユーザーが同じ商品を何度も注文するため、 ユーザーからのリクエストがさらに上積みされてしまうなど、さまざまな不具合が重なりました。

そのままでは同じ商品がいくつも届いてしまうため、セール後に対象の注文をすべて抽出し、キャンセルの処理をしました。その結果、同じ商品が何個も届いてしまう事態はなんとか避けられました。
とはいえ、なかなか商品が買えなかったので、SNSでもご指摘の声がありましたね。

根本的な問題は、注文に関わるデータベースにありました。その日はデータベース担当エンジニアも待機していてくれたので、データベースが落ちたことにすぐに気づいて、対策がとられました。

▲COOショッピング統括本部プロダクション2本部 サービスプラットフォーム技術部SRE 小中 史人

これまでの方程式に頼らない「予測困難な負荷に対する負荷対策」とは

注文履歴に反映されないことでご不安を招いてしまい、サイトから離脱するユーザーも多かったようで、大変なご迷惑をお掛けしてしまいました。また、ビジネス面で見ても、セールによる売上の期待値に対して約34%の損失が発生したことが後日判明し、 出店いただいているストア様にも大変なご迷惑をお掛けしてしまったとともに、ヤフーにとっても大きな機会損失となりました。

——社内の反応はどうでしたか。

影響が大きかったので、正直厳しい声も覚悟していたのですが、むしろ多くの社内の人から、「大変でしたね」「頑張って」と温かい言葉をかけてもらえました。こうした障害は自分の部署でも起こりうること。「けっしてひとごとではない」「今後の障害対策はどう進めるのか、参考にしたい」という声も寄せられました。

——翌年の「超PayPay祭」の開催もすでに予定されていましたが、その対策の基本方針「予測困難な負荷に対する負荷対策」について教えてください。

それまでの対策は、すべて予測負荷が前提で成り立っていました。例えばセールなどの特定イベントは、今年度の予算を前年度の予算で割り、前年度と同じ負荷を掛けることで、今年度の負荷を予測していました。
つまり、売上目標である予算が2倍になれば、負荷も2倍になる予測方法です。これまでは、その方程式が現実から大きく乖離することがなく、多少の誤差に対応できるだけのバッファは用意していたので、それを盲信していたところがありました。
しかし本当に必要なのは、予測された負荷を耐えるのではなく、流入を完全に読み切ることはできない前提で流入制限をかけたり、特定のコンポーネントが過負荷によってダウンした際にサービス全体がダウンしないように構成を改善したりなど、予測を超えてもサービスを継続できるようにする考え方だったのです。それが「予測困難な負荷に対する負荷対策」です。

——これまでの経験は重要ですが、それを過信すると失敗するということですね。 ところで、通常「超PayPay祭」は年に一度のビッグイベントですが、今年はLINEとの経営統合を記念して3月にも行われました。つまり、1年後だと思っていた次回のイベントが3カ月後になったことで、早急な対策が求められたということですね。

2020年の「超PayPay祭」直後に想定していた計画は現実的に不可能ですから、3月までに実現可能な対策を検討せざるをえませんでした。時間がないという状況が一番つらかったですね。

初めての「流入制限」を導入。社内中のサーバーを集めて「爆速増強祭り」

——具体的にはどんな対策を行ったのですか。

詳細については、CODT2021に登壇した動画にてご確認いただけますが、重要なポイントは、高負荷時にユーザーのアクセスをあらかじめ流入制限する考え方を導入したことです。サービスにさばききれない高負荷が押し寄せた際は、システム全体のダウンを防ぎながら、最低限、商品購入可能な状態を維持するわけです。
そのために、私たちは「RateLimit(レートリミット)」という技術を導入しました。カートページがダウンしない程度で流入を制限し、ページにアクセスできなかったユーザーには、「ただいま混み合っているので、もう少しお待ちください」というアナウンスページに誘導し、しばらく入場を待っていただくのです。

障害時には、サービスがどのように挙動するかが重要です。さらに、アクセスがスムーズにさばけるようになるまで、ユーザーとどうコミュニケーションをとるのかも大切なポイントだと思います。
発生しうる障害ごとにユーザーコミュニケーションを整理し、たとえ遅延があったとしても、なるべく多くのユーザーが検索や購入をできる環境を作っていく。全員へ常に100%の機能を提供するのではなく、混雑時にはあえて70%、60%に落とすことでサービスとして一定の価値を保ち続けるというわけです。
もちろん、「すべてのユーザーに対し、いついかなるときも同じサービスを提供するべきでは」「RateLimit導入はサービスのコンセプトに合わないのでは」という意見もあったものの、現状を考慮して最終的には導入することになりました。今回の障害発生によって、そうした制限策が許容される文化になったのは一つの転換だと思います。

——サービスコンセプトと導入技術に矛盾がある場合は、部内で意思を統一することが難しいでしょうね。

機能に関しては、すべてショッピングの経営層に必ず承認を得て導入するプロセスだったので、そこは納得していたと思います。

▲COOショッピング統括本部プロダクション2本部 サービスプラットフォーム技術部SRE 信原 有志
——プラットフォーム側の対策として、最も重要だったことは何ですか?

ヤフーは自社のプライベートクラウド上に、IaaS、PaaS、CaaSを構築してさまざまなサービスの基盤としています。プライベートクラウドで大規模セールを運用していくためには、必要となるリソースの把握や大規模セールが影響する対象の把握、突発事態を想定したリソース確保が重要です。
コンポーネントが大量に動くサービスの場合、プラットフォーム側も全体像の把握が難しいという課題もあります。実際、2021年秋の「超PayPay祭」でも、渦中にキャパ不足となり、当日緊急にスケールアウトする利用者が現れました。
3月の「超PayPay祭」では、事前対策としてサービス側との連携をこれまで以上に強めて、サービス側のコンポーネントの構成図を共有。システムのボトルネックを洗い出し、本番同様の試験を繰り返し実施しました。余剰リソースを社内から500台近くかき集め増強対応を実施することになり、その模様を「爆速増強祭り」と自身では呼んでいました。

サービスとプラットフォーム側が膝突き合わせ、相互理解を深めた

こうしたサービス・プラットフォーム側の対策は功を奏し、3月の「超PayPay祭」は、大きな障害もなく、無事にグランドフィナーレを乗りきることができました。最終日の取扱高は前回比約1.8倍と、過去最高を記録。セール高負荷対策チームは最初の失敗からすぐに立ち直り、リベンジを成功させることができたのでした。
大岩さんはCODT2021の発表のなかで、高負荷に立ち向かうためにサービス運用者、プラットフォーム運用者の双方に必要な考え方を整理しています。例えば、サービス運用者(クラウド利用者)にとって大切なのは、適切なキャパシティー・リソースの見積もりに加えて、自分たちが活用しているシステムの内容をプラットフォーム側にも知ってもらうことだと述べています。
また、プラットフォーム運用者も突発の負荷を常に想定して余剰リソースを把握するなどの準備が必要なこと、そして日常的なコンサルティング活動などを通して、サービス側との相互理解を深めることもまた重要だと指摘しています。

——サービス側とプラットフォーム側が、一緒に負荷試験を行うことはこれまでもあったのですか。

ほとんどなかったですね。これまではサービス側から話を聞いて、プラットフォーム側はリソースを用意します。運用はサービス側に任せて、何かあったら対応するといった具合です。しかし、3月の「超PayPay祭」の対策では、負荷試験の設計もともに実施し、試験当日も一緒にシステムの挙動をチェックしました。システム全体のアーキテクチャについても、徹底的に話し合って対策を練りましたね。

実際の環境を用意し、負荷試験をやりながら検証しました。テストしながら設定値をチューニングすることも、かなり細かくやっていましたね。プラットフォームのエンジニアと話す機会が増えたので、プラットフォーム側の事情が理解することが容易になりました。

それはプラットフォーム側も同じですね。サービスが何を求めているかを具体的に知ることができたのは、プラットフォームの改善にも大きく役立っていると思います。

▲テクノロジーグループシステム統括本部 クラウドプラットフォーム本部技術1部コンピュート 大岩 朗

——大岩さんとしては、プライベートクラウドをオンプレミスで運用するうえでのメリットとデメリットが明確になった、良い機会だったのではないですか。

プライベートクラウドは、ヤフーのような大規模利用ではパブリッククラウドに比べてコストが安くなることが大きなメリットです。ヤフーは膨大なユーザー情報を扱うので、それを安易にパブリッククラウドには置けません。 さらに、さまざまな社内システムと連携し、大規模にクラウドを運用しているので、開発のしやすさでもやはりプライベートクラウドのメリットが大きいと思っています。
ただ、前年の12月の時点で翌年3月までに対策をたてる必要があったため、例えば会社のデータセンターにサーバーやラックを増設する方法は時間的にも人手的にも大変。パブリッククラウドなら手軽にスケールアウトできます。そうしたメリット、デメリットをあらためて認識することができました。

——今回の失敗と成功の体験は、その後のクラウドやサービス運用どのように役立っていますか。

プラットフォーム側は、「超PayPay祭」だけではなく、例えばYahoo!ニュースなど、ヤフーすべてのサービスを支えています。その後もオリンピックでYahoo!ニュースのアクセスが爆発的に増えるなど、一時的な高負荷がありましたが、「超PayPay祭」の経験がその対策にも役立ちました。

サービス運用側も、できるだけスケールしやすいシステム作りを意識したり、緊急時にどんなオプションが必要かを考えたりするようになりました。

一つのシステムで障害が起こった場合、サービス全体にどういう影響を与えるのか。そのコンポーネントレベルではなくて、システム全体に与える影響を見たうえでの対策はどうなのか。サービス全体を俯瞰する視点を得られたのが、今回の最大の教訓だと思います。

大規模ECサイトにおけるシステム障害と対策について、赤裸々にアウトプット

大岩、小中、信原の3人は、2021年8月オンラインで開催されたCODT2021に登壇。「超PayPay祭による高負荷にショッピングはどのように立ち向かったか」と題して、サービスへの高負荷を乗りきった経験を発表。大規模ECサービスの事業者の内部から、システムダウンの経緯も含めて、負荷対策が具体的に語られるのは珍しいこと。その希少価値も含めて高い評価を得ることができ、実行委員会賞を受賞しました。

——障害発生の具体的な部分を語らざるを得ないわけですから、登壇は迷われたのでは?

サービス運用において、負荷の問題は避けては通れない問題ですが、障害の内容をどこまで話したらいいかは迷いましたね。

CODT21のスピーカーに応募したのは、3月のセールが終わる直前でした。11月に障害が発生して、短期間でその対策を講じ、 3月には無事成功するストーリーを考えていたのですが、もし同様の障害が発生したら、登壇は辞退すると主催者側に話していました。そうならなくて、本当に良かったです(笑)。
大規模ECサービスでは、システム運用に使っている技術を発表することは多いと思うのですが、障害事例をもとに話すのは珍しい。その面では意味のある発表だったと思っています。

オンラインイベントだったので、来場者の生の反応は見られなかったのですが、Twitterでは「うちもRateLimit入れてみようかな」など、それなりの反響がありました。

——今年も10月18日から11月29日まで「超PayPay祭」が行われていますね。今年のメンバーたちにはどんな引き継ぎやアドバイスをされましたか。

3月の取り組みは初めてだったこともあり、うまくいかずに次回持ち越しになっていた案もあったのですが、そこで見えてきた改善ポイントを現チームに伝えました。

今回は担当から外れましたが、やはり積み残された課題はいくつもあって、それを引き継いで、改善を続けましょうという話をしています。

今年どう動くかは、担当者の考え方次第なので、深く介入はしないものの、何か相談を受けたときは何でも率直に答えるようにしたいと思います。

国内有数のサービスとクラウド基盤で、負荷をさばく醍醐味

——インターネットサービスのインフラに関わるクラウドエンジニアやSREは、業界内では貴重な存在です。ただ、縁の下的な存在で、その仕事ぶりが一般に伝わらないもどかしさもあります。 インフラエンジニアとして、自らの仕事にどんな誇りや自負を感じていますか。

ヤフーはサービスの多様さに加えて、トラフィックの規模は国内有数です。それを開発し運用していく難しさは、他企業ではあまり経験できないことだと思います。そこにやりがいを感じているし、同時に課題でもあると思っています。
そのなかで自分が大切にしていることは、あらゆる角度からリスクを想定する視点です。サービスの規模が非常に大きいので、ユーザーの動きが予測しにくい。自分が関わっているシステムがどんなリスクにさらされる可能性があるのか、それを予測するのは大変なことです。しかし、それを考えて技術を磨いていくのは、エンジニアとしてのプライドであり、面白みのあることだと思います。

Yahoo!ショッピングのなかでも、毎秒2万ものリクエストがくるサービスもあります。その大量負荷を処理しながら、サービスを安定的に運用することはほかではなかなか体験できないこと。 もう一つヤフーが面白いのは、負荷対策のためにどう開発・運用をしていくのか、現場のエンジニアが自由に発想して、実装できるところです。一人のアイデアがシステムに反映されることがかなりあるのです。
もちろん、適切なシステムであるかどうかは、ビジネスチームとエンジニアとの間で議論します。ビジネスサイドの提案に対しても、実現が困難であったり、もしくはインパクトを感じられなかったりする場合は、必ず定量的な根拠を示して、最後まで議論するようにしています。
それが私にとってのエンジニアの自負かもしれません。どんなに込み入った課題でも、徹底して議論すればきっと双方が納得いく着地点が見えてくると思っています。

私がヤフーに魅力を感じているのは、日本最大級規模のプライベートクラウドを自分で設計・構築・運用できること、それに尽きますね。日本でこの規模のプライベートクラウド基盤を運用できるのは、ヤフーだけと言っても過言じゃないと思っています。
しかもクラウドを単に運用するだけではなく、そのうえで自社のさまざまなサービスを展開している。インフラがユーザーとの接点になるし、事業の収益源にもなる。サービスチームと連携しながら、技術的な努力や工夫を日々重ねることで、ユーザーの皆さんに安心して利用してもらえる。 ずっと縁の下にいて私はかまわない。みんなを支えているということが、私の大きなやりがいになっていますから。

採用情報 公式SNSアカウント

このページの先頭へ