re:Invent 2023: Prime Videoが実践する大規模システムのレジリエンス向上策
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Practice like you play: How Amazon scales resilience to new heights (ARC316)
この動画では、Prime VideoのNFLストリーミングを例に、大規模システムの可用性とレジリエンスを高める方法を学べます。週3回の自動負荷テスト、Operational Readiness Score、カオスエンジニアリング実験など、具体的な取り組みが紹介されます。また、予測不可能な事態に備えるドレスリハーサルの実施方法や、インシデントからの学びを活かすCOEプロセスなど、Prime Videoならではの興味深い実践例を知ることができます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Prime Videoのレジリエンス・プレイブックの紹介
1時間あたり30万ドル。これが、業界全体でのダウンタイムの平均コストです。そして、ダウンタイムを経験した企業のほぼ半数、46%が結果として顧客にサービスを提供できなくなっています。NFLのような最も成功しているスポーツチームの原則、戦略、戦術を、あなたに合わせたレジリエンス・プレイブックの形で適用できたら素晴らしいと思いませんか？そのプレイブックを使って、チームを予測不可能な事態に対してレジリエントになるよう訓練できるのです。
Laurent、それは素晴らしいアイデアだと思います。そして、これこそが私たちが今日ここにいる理由だと思います。Prime Videoは2年連続で木曜日のNFLの試合を独占配信しており、その数年前からも他のパートナーと共同で配信していました。今年、視聴者数は26%増加し、毎週木曜日に1200万人以上のお客様がフットボールを視聴しています。これは驚くべきことです。私たちはこれを長年行ってきました。また、エンジニアリングチームをピーク時の負荷やストリーミングに備えさせることが、チームがSuper Bowlに向けて準備するのと非常に似ていることも学び、認識しました。
そこで私たちは、すべての教訓、実践的な洞察、ストーリーを取り入れ、レジリエンス・プレイブックを作成しました。これを今日のセッションで皆さんと共有し、皆さんのホームチームに持ち帰っていただけます。私はOlga Hallと申します。Prime Video SportsのLive Events Availability and Resilience Engineeringのディレクターを務めています。そして、今日は私と一緒に、Amazon Web Servicesのfinancial and federal sectorに焦点を当てたChief Technologistで、chaos engineeringの世界的な責任者でもあるLaurent Dombが参加しています。ご参加いただき、ありがとうございます。
レジリエンスのための勝利のマインドセットと「Think global, act local」
Olga、ここに来られて光栄です。今日は、レジリエンスを考える際に必要な勝利のマインドセットを構築することについて説明します。そして、共通の目標を考えることから始めます。目標ができたら、Prime Videoでの方法と同じように、チームをトレーニングする方法について説明します。予測可能なことから始めます。次に、より多くの実験に進み、レジリエンスを考える際に何が間違う可能性があるか、予期せぬことについて考えます。そして、学んださまざまな側面をどのように分析するかを考える必要があります。それをお見せし、次に何か起こったときに備えて、筋肉の記憶を作り、準備ができるように、さまざまな学びをどのように記憶すべきかについて説明します。
さて、少し思い出していただきましょう。皆さんのほとんどは、お気に入りの番組があるためPrime Videoをご存知でしょう。Jack Ryanかもしれませんし、私の永遠のお気に入りであるMarvelous Mrs. Maiselかもしれません。あるいはCitadelかもしれません。私たちの豊富なカタログには何百万ものタイトルがあります。Prime Videoはスポーツも配信しています。テニス、野球、バレーボール、ニュージーランドのクリケットなど、挙げればきりがありません。私たちは、エンターテイメントのハブとしてスポーツでお客様を喜ばせることができて、とても嬉しく思っています。今年だけでも、世界中で約5万のイベントを配信しました。
シーズンの準備を年初に行う際、私たちはこう考え始めます。「私たちの主要なメンタルモデルは何か？ グローバルなイベントに向けて、分散したチームでどのように成功を収めるか？」 毎年必ず、私たちは同じメンタルモデルに立ち返ります。それは「Think global, act local（グローバルに考え、ローカルに行動する）」です。今日のプレゼンテーションを通して、これが実際にどのように機能しているか、なぜそのように行動したのかの例を挙げていきますが、まずは、なぜそこから始めるのかについてお話しします。グローバルレベルでは、目標、プログラム、特定のリソースの割り当て、特定の作業ストリームについて合意します。
そして、私たちはチームにガイダンスを提供します。このガイダンスを持ち帰り、グローバルにストリーミングされるイベントに向けて、各チームが独立して実行できるようにします。
予測不可能な状況への対応：Black Friday Footballの例
200カ国を対象に、長年Thursday Night Footballをストリーミングしてきて、ここではBlack Friday Footballも見られますが、Black Fridayと聞くと、興奮して人々が店に殺到する様子を思い浮かべます。このような予測不可能な状況にどのように備えるのでしょうか？
実は、Black Fridayは私たちにとって特別なイベントです。新しいNFLの伝統を確立できたと期待しています。しかし、よく考えてみると、そこまで予測不可能ではありません。なぜなら、Black Fridayには何があるでしょうか？ 家族や友人が集まり、一緒に時間を過ごし、できればフットボールを見ながら楽しむ、そういった時間があります。そのため、視聴者や顧客の行動について、ある程度の仮定を立てることができるのです。
予測不可能なことは、少し厄介です。天候や試合中に起こることを本当に予測することはできません。ちょっとした面白い事実をお話ししますが、Prime Videoが初めてThursday Night Footballを配信したとき、完全に雨で中止になりました。試合は延期され、かなりの時間延長しなければなりませんでした。「それがどうした」と思う方もいるかもしれません。しかし、そのピーク時のワークロードが予想以上に長く続くことになったのです。そういったシナリオを考えなければなりませんでした。ピーク時のワークロード時間が延長された場合はどうするか？テストする必要があるか？準備する必要があるか？これらは影響を与える可能性のあることです。
チーム構成、選手の健康状態はどうか？それがリアルタイムで観客の動員にも影響を与える可能性があります。全く予測不可能です。そして最後に、私たち全員が今この文化的な瞬間を生きています。多くの人が愛するある有名人がKansas City Chiefsのファンであることが判明しました。彼女と共に、NFLファンやNFLが楽しむ新しいエネルギーと注目が集まっています。これを事前に予測するのは難しいですよね？年初の時点では。
多くの方は、「どうやってそういった予測不可能なことを見つけるのか」と考えているでしょう。そういった予測不可能なことは、新聞や、あるいはニュースフィード、つまりあなたがニュースを得る方法から現れることが多いです。また、「もしこれが起こったら？」「その時どうするか？」といった考えが頭の片隅にあります。そこで皆さんに質問です。こういったシナリオに対するプレイブックはありますか？もしなければ、それでも大丈夫です。今日得た洞察を持ち帰り、チームと一緒にプレイブックを作成してみてください。
勝利のマインドセットと筋肉の記憶の構築
プレイブックを考える際には、勝利のマインドセットを構築する必要があります。成功しているスポーツチームの勝利のマインドセットを見ると、彼らが全員行っていることが一つあります。それは、プレイするように練習し、練習したようにプレイするということです。
彼らは筋肉の記憶を作り出し、ゲーム内で行っていることを視覚化することで、どのようにしてピークパフォーマンスを発揮するかを理解します。Olga、Prime Videoがどのように練習してピークに到達しているかについて教えてください。
筋肉の記憶を作り出すというのは良い表現ですね。Prime Videoでは筋肉の記憶を作り出すために、各リージョンで週に3回、自動化された負荷テストを実行するプログラムを持っています。私たちはそのピークを計算します。時には週単位で、時には月単位で行います。そのピークを見つけ、基本的に負荷テスト（私たちはこれをgame daysと呼んでいます）を実行して、スケーリングルールの確実性を確保し、オートスケーリングをテストし、チームの対応をテストします。
これは少し大変そうだと思われる方もいるかもしれませんが、このようなピークに向けた週次テストは、チームの運用面での筋肉の記憶を鍛え、コードパスを新鮮に保ち、スケールで現れる可能性のあるバグを特定するのに役立ちます。そして、チームの筋肉を非常に新鮮に保つのです。
Prime Videoの可用性重視アプローチと運用準備度スコア
勝利のマインドセットを考える際には、目標を持つ必要があります。
皆さんに、どのようにしてチームを結集し、全員が支持する目標を作り上げたのか、お聞かせいただけますか？ - もちろん、喜んでお話しします。先ほど申し上げたように、年初に新シーズンに向けて考え始める時、私たちは可用性が最重要機能であることに同意します。特定のサービスや製品全体で、可用性のバーをどれだけ上げたいかという具体的な目標を設定します。そして、「可用性が最重要機能」という基本方針を掲げます。
これは単なる言葉ではありません。製品リーダーやエンジニアリングリーダーと同じ部屋に座り、新機能の一覧表を前にしているところを想像してください。その一覧表の最上位には、可用性に関するワークストリームやプロジェクトが並び、予算と人員が割り当てられ、リーダーシップの支援を受けています。Amazon Prime Videoで使用している可用性の定義をご紹介しましょう。長年にわたってテストし、実践してきた結果、私たちはこの定義を気に入っています。私たちにとって可用性とは、各重要コンポーネントが協力し、連携し、リスクから保護する分散システムから生まれる品質のことです。この定義で興味深いのは、ソフトウェアだけでなく、リーダーやチームも含まれていることです。
リーダーと言えば、遠くを探す必要はありません。 Prime VideoのVice PresidentでGlobal Head of SportsのJay Marineは、エンジニアリングチームや製品チームとのあらゆるミーティングで可用性について話します。彼がよく言うのは次のようなことです：「お客様はスポーツに情熱を持っており、私たちはシームレスで高品質な視聴体験を提供することに全力を尽くしています。」彼はAll Handsミーティングでこのことを話し、機能レビューの際にも議論します。このようなリーダーシップのサポートがあれば、プログラムの構造を作るのは簡単です。
プログラムの構造をお見せしましょう。最初のワークストリームには、運用の卓越性に関するプロジェクトがあります。私たちは運用準備度スコアと呼ぶアプローチメカニズムを開発し、チームと協力して今年の運用準備度スコアの目標値を決めます。このアルゴリズムについては後ほどご紹介します。次のプロジェクト群はサービスのレジリエンシーに焦点を当てています。これは実際には何を意味するのでしょうか？年初や年間を通じて、チームは必要な緊急対策、フォールバック、レバー、機能の調整方法、そしてそのテスト方法について考えます。これらすべてが、サービスレジリエンシーと呼ばれる非常に具体的なプログラムにまとめられます。
最初の2つは、observabilityとreportingがなければ成功しません。年々の絶対的な進歩を遂げ、availabilityの姿勢を改善するためには、observabilityとreportingに投資する必要があります。今日は、サービスとエンドポイント間の接続のobservabilityについて、私たちが行ってきたことの例をいくつか共有できることを嬉しく思います。また、availabilityに関して私たちが行っているreportingについてもハイライトしていきます。
Operational Readiness Scoreの構成要素と重要性
operational readiness scoreを考える際、Amazon Prime Videoはそれを構築するために何が重要かを理解するための多くの研究を行いました。ここに4つの柱があります：deployment safety、code coverage、operational readiness completion and review、そしてcorrection of error actionsです。では、これがPrime Videoでどのように見えるかをお見せしましょう。 彼らは、Prime Videoに組み込まれるあらゆるサービスの健全性に関する透明性を提供するresilience portalを構築しました。 開発者が作成した新しいサービスを自動的に取り込むカタログがあります。先ほど述べたように、game daysを通じてこれらのサービスを分析することができます。load testingとこれらのサービスの健全性に関するレポートを得ることができます。operational readiness scoreは開発者にとって非常に重要ですが、リーダーにとっても同様です。
また、これらのシナリオがPrime Videoにどのように適用されるか、そしてobservabilityに関してinsightsの側面がどのように機能するかについても見ていきます。operational readiness scoreは100点満点で、この100点は、deployment safetyに45点、code coverageとcorrection of errorsに15点、そしてoperational readiness reviewに25点で構成されています。
deployment safetyに重点が置かれている理由があります。それは、顧客ベース全体を見渡すと、ほとんどのエラーがデプロイメント中に発生するからです。もう一つの側面は、開発者が革新するための安全な環境を持つことです。これらのスコアと様々な側面やメカニズムを通じて、私たちは開発者がそうできるようにしています。 deployment safetyについて考える際、皆さんも自分の環境で使用できるいくつかの項目を共有したいと思います。例えば、automatic rollbackを実装することで、非常に迅速に操作可能な状態に戻ることができます。特にAWSで運用している場合は、まずavailability zoneへのデプロイメントから始め、他の複数のavailability zoneにロールアウトし、そしてregionへ、さらに別のregionでも同じことを行います。さらに、プロビジョニング時には常に66%のhealthy nodesを確保することが重要です。これもまた、常に顧客にサービスを提供できるようにするためです。
次に、code coverageとcode reviewsについて考えることができます。これは単に コードに対するテストの割合を理解することだけではありません。Prime Videoは、pipelinesの障害処理や、そこで発生する障害についても検討しています。また、機能し、resilientであることがわかっているdesign patternsの再利用性に関する側面もあります。そして、distributed systemを考える際に重要となるdependenciesについても検討します。その後、operational readiness reviewsに進みます。operational readiness reviewsについて考える際、これはスポーツチームが試合前にルームでハドルを組むのと同じことです。
目標を設定し、実行したいことに関するベストプラクティスを網羅した計画を立てます。ここでは、セキュリティのベストプラクティス、先ほど話した安全なデプロイメント、サービスの予測と拡張性、そして特に何か問題が発生した際に対応できるようにするためのイベント管理とインシデント対応について検討します。もちろん、これらを実行するためには、アラームとメトリクスが適切に設定され、最新の状態に保たれている必要があります。そして最後に、予測不可能な事態に備えて、可用性レポートやインパクト、カオスエンジニアリングを活用し、システムに障害や故障が発生した場合に対応できるようにします。
エラー修正プロセスとOperational Readiness Scoreの継続的な評価
これらの点はすべて、おそらくお気づきのように、追加項目です。そして、 Operational Readiness Score（運用準備度スコア）について考える際、例えば障害から得られた教訓をどのように確実に実装するかが重要になります。私たちは、これを「correction of error（エラー修正）」プロセスと呼んでいます。多くの方は業界標準の名称である「root cause analysis（根本原因分析）」をご存じでしょう。AWS blogをフォローしている方々は、インシデント時にこれについて読んだことがあるかもしれません。これは従来のRCAで、非常に構造化されており、顧客への影響、タイムライン、5回のなぜなぜ分析、学んだ教訓、そして最も重要なアクションが含まれています。
チームと協力する際、私はよくアクションに焦点を当てるようアドバイスします。アクションは予防の鍵となります。どの業界にいても、ニュース、医療、金融など、常に多くの仕事があり、トレードオフについての議論や、新機能のリリースを急ぐべきか、それとも過去のCOEから学んだことを強化することに集中すべきかという議論が行われます。COEレビューとエラー修正のメカニズムは、COEから得られた未解決の点や行動が対処されていない場合、ポイントを差し引くことで、これらの問題に対処する助けとなります。
Operational Readiness Scoreは一度きりのものではなく、生きて呼吸しているもののように、常に変化します。いつでもサービスのOperational Readiness Scoreを確認し、現状について合理的な推論や仮説を立てることができます。スコアは上がっているのか、下がっているのか、そしてその理由は何か。これにより、リーダーはサービスのレジリエンスと可用性をチェックするメカニズムを持つことができます。
目標の設定、チームの結集、そしてOperational Readiness Scoreを通じてチームが期待通りに機能しているかを確認する方法について話しました。しかし、自分のサービスが本当にその労力に値するのかと疑問に思うかもしれません。サービスを評価する際、あなたが取り組んでいるコンポーネントが顧客に影響を与えるものかどうか、多くの上流または下流の依存関係を持っているかどうかを考えてみてください。もしそうであれば、Operational Readiness Scoreへの投資は十分に価値があるということです。
TEAMメカニズムと予測可能・不可能な事態への対応
レジリエンスの全体的な旅を考えやすくするために、私たちは TEAM というメカニズムを作りました。なぜなら、レジリエンスはチームスポーツだからです。レジリエンスはチームスポーツなのです。Laurent と私がこれを作った理由は、膨大な会話や情報が皆さんに押し寄せてくるからです。そこで、簡単に理解できる構造をどのように作るか考えました。これらのセッションの準備をしている中で、私たちは基本的に、少し抽象化すれば世界は実際にとてもシンプルだと気づいたのです。
2つのスライスに分けることができます。1つは予測可能なもの、例えば顧客の行動などの予測です。ある日の顧客の行動を予測できます。もちろん、ばらつきやリスクの度合いはありますが、予測可能です。そして、予測不可能な出来事があります。予測可能な出来事や予測可能な input に対しては、私たちは Amazon でチームをトレーニングします。予測不可能な input に対しては、実験を行います。予測不可能性に対してトレーニングするのは難しいですが、実験を行い、そこから学ぶことはできます。
両方のケースからデータを収集し、集約し、分析し、レビューし、学んだことを運用メモリーに入れ、そしてサイクルを繰り返します。では、トレーニングから始めましょう。ここから始めたいと思います。エリア1のようなものですから。つまり、どういう意味かと聞かれるかもしれません。 では、予測と言うときに何を意味するのか説明しましょう。ストリーミングメディアに携わっている方々にとって、ピーク時のワークロードを定義する主要な指標は実はとてもシンプルです。これらは同時ストリーム数です。ピーク時に何人の顧客がいるかということです。
2つ目の指標はストリーム開始数です。最後の1分というのは本当に最後の1分で、その通りです。試合開始5分前の顧客の行動は、ほとんど変わりません。EPL（English Premier League）や TNF（Thursday Night Football）でも、常にこの subscription のスパイクが見られます。そして、ストリーム開始数は、顧客がどれくらい速く参加するかを判断するのに役立ちます。他に予測できることとしては、例えば引き分けの場合や、Messi が English Premier League でプレーしている場合など、誰もが一斉に参加するような瞬間があります。そのときのストリーム開始のサービスにおけるピーク TPS はどれくらいになるでしょうか。
3つ目の指標はあなたのビジネスによって異なります。これは顧客が一斉に押し寄せる入り口です。私たちの場合、それは顧客が特定の番組を見るためにランディングする detail page です。皆さんも少し考えてブレインストーミングすれば、自分のビジネスを定義する主要な指標を見つけられると確信しています。また、長年の経験から、私たちが持つすべてのサービスとエンドポイントは、これらの指標のいずれかに応じてスケールすることがわかりました。つまり、ML と AI に基づいたアルゴリズムを開発して、これら3つの主要なビジネスドライバーを予測し、同様のアルゴリズムをサービスレベルの指標に適用できるということです。
スポーツイベントやプロダクトをサポートするために関わる、サービスやカスタマージャーニーの個々のエンドポイントについて、予測と全てを手に入れました。
Prime Videoのカオスエンジニアリング実験とAWS Fault Injection Service
最後になりましたが、ストリーミングメディアなので、サービスだけでなく、当然スループットについても考慮する必要があります。これはCDNやISPに関わってきます。さて、これらの入力を全て手に入れた今、私たちは何をすべきでしょうか？ここからが面白い部分です。
各エンドポイントの週単位のTPSと、イベントのピーク時の予測が分かれば、個々のエンドポイントに対するロードテストを簡単に作成できます。Prime Videoでは、私たちは愛情を込めて「Wall-E」と呼ぶツールを作りました。これはGamedayツールです。このツールを使うと、複数の設定を組み合わせて、本番トラフィックとピーク時のワークロードフットプリントに近いGamedayを1つ作成することができます。ここでは、サブスクリプション、再生サービス、広告など、ゲーム中に異なるランプアップが予想されるシナリオのロードをモデル化できます。このアプローチでは、これらすべてが並行して実行されます。
ここで立ち止まって考えたいのは、これが非常に重要だからです。ここでグローバルとローカルの違いが出てきます。私たちの2ピザチームは、自分たちのエンドポイントに対する個々の設定とロード生成を担当します。中央チームが、イベントやスポーツのプロファイルに合わせたロードプロファイルを作成し、実行・準備します。
少し混乱しています。最初のスライドでは、チームが週に3回Gamedayを実施していると示されていました。私たちAWSでGamedayを実施する際は、大勢の人が部屋に集まり、すべてを詳細に計画します。チームでこれほどの作業量をどのように調整しているのでしょうか？
エンジニアが部屋にいた時代は過ぎ去りました。そう、私もかつてはテクニカルプログラムマネージャーとして、深夜にエンジニアたちと一緒に部屋でテストを実行していました。しかし、私たちはそれを自動化しました。現在では、このconfiguration toolを使えば、わずか数回のクリックと、gamedayをスケジュールして基本的に監視する1人の人員だけで済むのです。chaos engineeringに詳しい方々にとっては周知の事実ですが、そう、Prime Videoは本番環境で実験やテストを行っています。つまり、問題の兆候が見られた時点でgamedayや実験を停止する技術を持っているということです。多くは自動化されていますが、必要な時に同じことができるgame leaderも存在します。つまり、ボタン一つと1人の人員で済むのです。
では、自動で実行する際、何も問題が起きないと確信できるのはなぜでしょうか？そう、ここで言葉は単純です。各エンドポイントのTPSを予測し、モニターやアラームを監視することで、うまくいっているという高い確信を持つことができます。そしてもし問題があれば、停止し、一時停止し、学び、そして再度実験を行います。
本質的に、Prime Videoのgamedayのプレイブックを見てみましょう。load testingと言う時、これが私たちのgamedayです。まず予測から始めます。次に、様々なシナリオを開発します。スポーツはそれぞれ異なります。Thursday Night Footballは、私はリビングルームで最も楽しみました。しかし、日本のボクシングを例に取ると、特にその時間帯では、お客様が移動中だったためモバイルが中心です。あるいはニュージーランドのクリケットを例に取ると、これもモバイルファーストです。つまり、準備している放送に特化したシナリオを作成するのです。
チームはload generatorを更新し、ローカルレベルで維持管理します。observabilityを導入し、サービスの健全性を監視していることを確認します。そして最後の部分、十分な注目を集めていないので少し強調したいのですが。
gamadayが実行されると、レポート、発見事項、チーム向けのチケットが発行されます。これらの新しい発見事項をtechnical debt trackerに入れ、すぐにsprintに組み込むことができます。チームがsprint readinessを行う際、先ほど可用性が機能の第一番目だと言いましたが、sprintにある全ての課題を見て、可用性に関する項目が常にトップに来ます。そのため、gamedayからの発見事項の修正を優先し、集中することがより簡単になるのです。
カオスエンジニアリング実験のリスクレベルと実施方法
では、チームに目標を設定することから始め、次に運用準備スコアとトレーニングを見てきました。そして今、予測可能なことが分かりました。ここからは、Prime Videoが予測不可能なことや実験に関してどのように取り組んでいるかを見ていきましょう。レジリエンスをテストすることを考えると、さまざまな方法があります。Game Dayでよく見られるようなアドホックな実験を行うこともできますが、パイプラインでも実験を実行すべきです。パイプラインで実行すれば、障害を導入する際にパイプラインをブロックできるからです。これにより、本番環境にデプロイしてお客様に影響を与えるのではなく、素早くロールバックすることができます。また、Olgaが Prime Videoについて言及したように、スケジュールに沿って実験を実行することもできます。
予測不可能なことやレジリエンスのテストについて考えるとき、それは技術だけの問題ではありません。人とプロセスも関係してきます。コアデータベース管理者が休暇を取った時に、システムがダウンして誰もログインできなくなったのはいつだったか考えてみてください。おそらく誰もが経験したことがあるでしょう。カオスエンジニアリングの実験を考えるとき、常にリスクが伴います。特にカオスエンジニアリングの実験を始めたばかりの場合は、どれが低リスク、どれが高リスク、どれが中程度のリスクなのかを理解する必要があります。
低リスクの実験から始めることができます。例えば、CPUやメモリの負荷テストです。I/Oの一時停止実験を行って、データベースがどのように反応するかを理解することもできます。または、Auto Scaling Groupの背後にあるEC2インスタンスを再起動するような単純なことも可能です。これらは再起動後に復帰するはずだからです。KubernetesやECSでも同じことが言えます。ポッドやタスクを強制終了しても、再び起動するはずです。次に、中程度のリスクの実験に移ることができます。これらは非常に興味深いものです。インフラの障害は簡単だと言われることが多いですが、レイテンシーを注入し始めると、依存関係やそれらがレイテンシーにどう反応するかについて多くのことを学べます。そのため、下流のサービスにレイテンシーを注入したり、エラー率を上げたりして、何が起こるかを観察します。
ここで、Amazon Prime Videoが中程度のリスク項目をどのように扱っているかを共有するのは興味深いと思いました。彼らはアドホックに実行するだけでなく、パイプラインでも実行しているからです。その通りです。正直に言うと、これは私のお気に入りのスライドの1つです。非常に実用的だからです。もしスライドの写真を撮るなら、おそらくこれが一番良いでしょう。なぜでしょうか？低リスク項目については、エンジニアリングチームがローカルレベルで始めることができ、いつでも実行できるからです。中央のプログラムや計画は必要ありません。彼らは独立して実験やテストのルーティンを確立できるのです。
Prime Videoでは、私たちが参加したゲームデーの一部で、学習のために低リスクの障害注入テストも実施しています。中リスクのテストについては、時間とともにその価値を理解するようになり、今では大好きになりました。チームと協力してパイプラインに組み込むことを強くお勧めします。なぜでしょうか？よく廊下を歩いていたり、Slackのチャットを聞いていると、「この関数をコミットしたら50ミリ秒増えたんだけど、SLAの再交渉が必要かな？」といった会話をよく目にします。これは会社を問わず、ストレージ、ニュース、メディアなど、どの分野でも起こりうることです。私たちは分散型の世界に生きているので、サービス同士が統合され、依存し合っているのです。
パイプラインにこういったテストがあれば、交渉は必要ありません。50、70、500ミリ秒など、どんな数値であれテストを実行すれば、上流や下流の依存関係の契約に変更があっても、チェーンが壊れていないという確信が持てます。だからこそ、私はこの中間部分が大好きなのです。そして高リスクのテストは、グローバルな取り組みが一体となる例です。
これは、Technical Program Managerやエンジニアたちと同じ部屋に集まり、例えばデフォルトリージョン間でどれだけ迅速にワークロードをシフトできるかといった実験を行うものです。これはグローバルおよび中央チームレベルで計画する高リスクな実験です。
AWSのお客様が、クラウドの回復力に関連する障害に対してワークロードがどのように反応するかを理解できるようにするため、AWS Fault Injection Serviceがあります。先ほどお話しした高リスクな実験のために、本日、AZの可用性、停電、そしてリージョン分離の障害に関する新しい障害シナリオをリリースしました。マルチリージョンサービスを持っていて、災害復旧やリージョン分離時のワークロードの動作を確認したい場合に使用できます。素晴らしいニュースですね。早速使ってみたいと思います。
さらに、AWS Fault Injection Serviceは過去2年半、そして今年にかけて、多くの新しい障害シナリオをリリースしました。例えば、Amazon Elastic Kubernetes Service (Amazon EKS)を使用している場合、ポッドに直接レイテンシーやCPU、メモリの障害を注入できるようになりました。Amazon Elastic Container Service (Amazon ECS)についても、同様の障害シナリオが利用可能です。Amazon Elastic Block Store (Amazon EBS)に関しては、IO一時停止の障害注入を可能にし、さらに多くのネットワーク障害シナリオを追加しました。これらは単なるシミュレーションではなく、実際の障害であることを覚えておいてください。これらの障害に対してワークロードやアプリケーションがどのように反応するかを理解する必要があります。そのため、これらを実行する権限が皆さんに与えられているのです。
Prime Videoのドレスリハーサルと予期せぬシナリオへの対応
Prime Videoがどのようにカオスエンジニアリング実験を実施しているか見てみましょう。最初にお見せしたレジリエンスポータルについて、チームがカオスエンジニアリング実験を行いたい場合、まずツールにアクセスします。Olgaが予測について話しましたが、実験を考える際には定常状態が必要なので、チームの予測に基づいて負荷を増やし始めます。そして実験を定義します。ここでAWS Fault Injection ServiceとSSM chaos runnerという2つの特定のツールが見られます。SSM chaos runnerはAWS Fault Injection Serviceより前からあり、Prime Videoがパイプラインから自動的にライブラリで開始できるようにしています。
実験が実行されたら、もちろん安全な方法で行いたいと思います。Amazon CloudWatchには既にメトリクスとアラームが定義されているので、実験が範囲外になった場合は自動的に停止します。そして、観測性のためのすべてのログとトレースは、システムの改善方法を理解し行動するためのインサイトに関して、レジリエンスポータルに流れ込みます。では、Prime Videoがパイプラインでどのように行っているかをお見せしましょう。
カオスエンジニアリングについて考えると、多くの顧客が、作成できる障害の数を増やすためにカオスエンジニアリングツール全体にわたるインターフェースを構築しているのが分かります。この場合、パイプラインで実行できるSSM Chaos Runnerのライブラリがあり、AWS Fault Injection Serviceを呼び出しています。 ここでIO stressで実行するアクションが見えます。影響の範囲を確実にするためのタグ、期間と時間、そして安全な実験のための停止条件を定義できます。これで、Prime Videoのドレスリハーサル、つまりゲームデイ、実行するカオスエンジニアリングの側面に話が及びます。
これは私たちが楽しむもう一つの場所です。ご想像の通り、NFLがプレシーズンゲームを行いますよね？選手たちのウォームアップ、プレシーズンに向けてのウォームアップなどです。Prime Videoはこれらのプレシーズンストリームにアクセスでき、ここで機能をテストします。通常、これはベータプログラムで、ベータ期間中に行われます。そしてはい、チームは仮想的であったり、同じ部屋に座っていたりしますが、非常に分散しています。つまり、両方の組み合わせです。
このベータ期間中、つまり私たちが呼ぶドレスリハーサルでは、チームに何を実行するか伝えません。彼らは知りません。ただ、いくつかの実験を行うことだけを知っており、私のお気に入りの実験を共有しましょう。すべてが技術的なものではありません。想像できると思いますが、チームが機能をテストしていて、誰かがエラー注入を行うと、それが本物かどうかを判断しなければなりません。
今シーズンの私のお気に入りの1つは、不正なQRコードの実験でした。不正なQRコードがあり、それを取り下げる必要があると宣言しました。私たちはそのQRコードがどこにあるかを特定し、見つけて、そして削除するための作業を研究しました。検出までの平均時間と解決までの平均時間を測定しました。エンジニアリングチームはその場でシステムからこの不正なQRコードを取り除くためのレバーを引いていました。
プレスリリースチームとマーケティングチームは、この実験を事前に知らされていなかったため、非常に気に入りました。彼らは何をすべきか、本番チームと同じプレイブックを使うべきかを考えなければなりませんでした。本番チームも不意を突かれ、その場で従うべきプロセスを考えなければなりませんでした。私たちはこれをインシデントとして実行し、その後、すべての発見事項を振り返って検討します。
他の多くのチームや企業では、これはテーブルトップ演習やシミュレーションと呼ばれています。これは非常に強力で、実行するたびに本番チームとエンジニアリングチームの両方から素晴らしいフィードバックを得ています。他に何をしているか、もう少し詳しく説明しましょう。例として、Prime Videoではスポーツ関連の全ての機能にフィーチャーフラグを設けることを決定しました。これは基本的に、非常に素早くその機能をオフにできるということです。
なぜそれが必要なのでしょうか？例えば、Rapid Recapという機能があります。これは顧客に非常に人気のある機能の1つです。もし試合のハイライトの選択に満足できない場合、この機能をオフにし、調整して、再び戻すことができます。これが一例です。つまり、基本的にリアルタイムで行うことができるのです。
準備段階のドレスリハーサルでは、シーズンのために作成した新機能をすべてテストし、何かがおかしいと宣言した瞬間から修正して再度アップするまでの時間を測定しています。また、これらの予告なしの実験を行うと、アラームが更新されることも気に入っています。エンジニアリングチームはアラームを見直し、「正確性を確保し、ノイズと本物を区別できるようにする必要がある」と基本的に言います。
私たちはこれらの実験に対してレトロスペクティブを実施しています。これは良いことです。なぜなら、「これを自動化する必要があるか？今あるもので進めるべきか？他に何ができるか？」といった議論を引き起こすことがよくあるからです。リアルタイムスポーツでは、試合のどの瞬間も見逃す余裕はありません。そのため、私たちはこういったことを練習するのです。
もう一つお話しします。時々、天候の話題が出ることがあります。これは非常に重要ですが、一見そうは見えません。Chimeがダウンしたり、Slackがダウンしたり、停電が起きたりした場合をシミュレーションするテストもあります。私たちは異なる場所にいるハイブリッドチームですが、天候は予測不可能です。ロンドンの人々が地下鉄に乗れなくなったらどうなるでしょうか？シアトルで停電が起きたらどうなるでしょうか？そういったシナリオも検討し、冗長性を組み込んでいます。これも練習しています。
学びの分析とCorrection of Error（COE）プロセス
最初から考えると、目標の定義、それをOperational Readiness Scoreでどう追跡できるか、予測可能な訓練と予測不可能なことについて見てきました。これらから学んだことを分析します。 では、様々な学びの分析についてどう考えているか、見ていきましょう。
そうですね、そのプロセスはどうなっているのでしょうか？私たちが持っているメカニズムはCorrection of Error（COE）と呼ばれています。非常に構造化されています。時々聞かれることの一つは、「エンジニアはただ理解するだけでいいのか？マネージャーも一緒に座って話し合う必要があるのか？」ということです。これはハドルで、インシデントやニアミスに関わったエンジニアリングチームが参加します。時には、顧客に影響を与えていなくても、COEを実施することがあります。非常に近いところまで来ていて、そこから学ぶべき重要なことがある場合、COEを実施します。
マネージャーや上級リーダーもその場にいて、このドキュメントを読み、議論に参加します。なぜでしょうか？基本的に、おそらく多くの方が経験されているように、ローンチの時は決断の時です。何を優先するのか？特定の機能を保留して、運用の卓越性により多く取り組むべきか？私たちは長年にわたり、「実際、これが学んだことだ。X、Y、Zを強化する必要がある」と言って、シーズン途中で特定の機能をリリースすることもありました。
約束通り、可観測性のために私たちが行ったことをお見せしましょう。これも非常に強力です。私たちは、すべての異なるサービス間の接続を示すサービスグラフを作成しました。これの素晴らしい点は、サービスを接続するログファイルに異常があると判断した場合、またはCloudWatchアラームが鳴っている場合、リンクが赤く強調表示されることです。つまり、リアルタイムで非常に強力なのです。多くのお客様や皆さんの多くが、すでにこれを行っていることは承知しています。
私が強調したいのは、私たちのエンジニアリングチームがとても賢明に行ったと思うことですが、サービスグラフが扱いにくくなって大きな塊にならないようにしたことです。そこで、カスタマージャーニーごとにビューを作成しました。サブスクリプションのビュー、プレイブックのビュー、詳細ページに特化したビューを持ち、リアルタイムでビュー間を移動できるようにしました。問題が発生したときにリアルタイムで可視化され、それが点灯するのを見ることができるのは非常に強力です。
また、以前に議論した末に実施したもう一つのことがあります。それは長年にわたって素晴らしい投資だったことがわかりましたが、リアルタイムの可用性ダッシュボードです。このカスタマージャーニー内のいくつかの主要サービスを選択し、基本的にほぼリアルタイムで表示しています。それらのエンドポイントの可用性が誰にでもわかるようになっています。疑問の余地はなく、推測する必要もありません。単に公開されており、誰もがそれを注視しています。
お客様や皆さん、さらには私たち自身のエンジニアとお話しするときによく聞かれる質問があります。「ROIは何ですか？カオスエンジニアリングが機能することを証明してください」。そこで、インシデントの重大度に関するこのグラフをお見せします。これは昨年の実際のグラフです。昨年、私たちは多くのことを学びました。基本的に、このグラフが示しているのは、シーズンを通じて私たちが研究を重ね、取り組む必要のあるいくつかのインシデントがあったということです。私が説明しているプロセスを適用しました。それはゲームタイム、訓練、そしてカオス挿入を確実に行うことです。そして、シーズン終盤には大きく改善しました。
これが起こると、平均故障間隔が改善され、大幅に長くなる一方で、平均検出時間と平均復旧時間が短縮されるのがわかります。そしてそれがまさに望んでいることなのです。したがって、私たちは可用性が機能の第一位であるという確信を持っています。そして、それが結果をもたらすため、継続的に投資を行っています。
記憶化とプレイブックの重要性
その通りです。可用性とレジリエンスを考える際、オブザーバビリティなしでは不可能です。次に、記憶の段階に進みましょう。 記憶の段階を考えるとき、それは最初に戻ることが多いのです。チームの目標を持つ必要があります。何を改善したいのでしょうか？改善したいことが分かれば、計画を立て始めることができます。どこに向かいたいのかを視覚化できます。そして、顧客のトラフィックに通常見られる予測可能なパターンについて、戦略を定義し始めることができます。
Prime Videoが自動化された方法で行っているように、様々なゲームデーを実行することにもっと慣れることができます。システムをプリウォームし、負荷がかかったときの動作を理解し、Auto Scaling Groupsなどに基づいて回復できるはずの予測可能な障害を注入します。そして、チームに少し挑戦を与える実験に進みます。システムがどのように動作するべきかについて明確な仮説を立て、ゲームデーやPrime Videoで行っているドレスリハーサルを通じて、その仮説が実際に正しいことを確認します。
そして、記憶化を考える上で非常に重要なのは、グラフを理解することです。オブザーバビリティと何が起こっているかの理解を考えるとき、常に定常状態から始めます。それは1秒あたりのトランザクション数、1秒あたりのストリーム開始数です。影響が見られ、何かが低下している場合、掘り下げて理解し、何をより良くできるかを分析できます。これが微調整の部分です。これを繰り返し行うことで、ピーク時に実行できる運用上の筋肉記憶を持つことができます。
さらに、ランブックとプレイブックを忘れないことも重要です。 これらの様々なステップを実行し記憶する際、インシデントが発生した場合にチームメンバーが自分の役割と実行方法を知っていることを確認したいのです。Wikiでどこをクリックすべきか探させたくありません。全員が寝ていても実行方法を知っている必要があります。ここでは、コールリーダー、サブジェクトマターエキスパート、その他の役割のための様々なボタンが表示されており、彼らがすぐに何をすべきか分かるようになっています。
そして、Olga、タッチダウンを決めてください。はい、これをたくさん練習しました。やってみましょう。 これがSuper Bowlに到達する方法です。私たちは「記憶化」という言葉を何度か使いました。なぜでしょうか？私たちがこれを強調し続ける理由は、Prime Video、特にPrime Video Sportsでは、1秒1秒が重要なビジネスを行っているからです。1秒も失うことはできません。基本的に、これは考えたり議論したりする時間がないということです。決定を事前にキャッシュしておく必要があります。運用上の対応のすべての論理が筋肉記憶に入っている必要があります。Laurentが元テニス選手として言い続けていたように。
要約すると、どのようにしてその筋肉記憶を得るのでしょうか？金融、医療、またはリアルタイムの対応が非常に重要な他の業界にいる方々のために、ここにプレイブックがあります。予測可能なものと予測不可能なものについて考えてください。予測可能な入力に対してトレーニングを行います。予測不可能なものについては、実験し、改善し、実験し、改善します。予測可能なことについてシナリオを作成します。独自のメカニズムを作成します。私たちは Operational Readiness Score を共有しました。100点である必要はありません。あなたのワークロードと組織に適したものである必要があります。ここで示したロジックを使用して、適切だと思うようにそのメカニズムを開発できます。
ゲームデイを開発します。ワークロードテスト、ケーステスト、またはその両方の組み合わせでもかまいません。3つのバケットがあるスライドを覚えていますか？それは非常に強力です。そのようなシステムを開発してください。ドレスリハーサルは技術だけである必要はありません。時々頭の片隅にあって気になっているようなことです。もしこれが起こったらどうなるか？どのように展開するか？何をするつもりか？実行可能な洞察をもたらし、runbookやplaybook を更新し、そのすべてがプロアクティブな信頼性につながります。
レジリエンス・プレイブックの要約と結論
さて、それではプレイブックを作成してください。このセッションでチームをどのように組み立てるかを示しました。勝利のマインドセットについて考え、チームの目標を定義してどのように見るべきかを考えて、部隊を結集できるようにします。ゲームデイに関してどのように適応できるかを見てきました。例えば、システムに対して週に複数回予測と負荷テストを実行して、それらがどのように機能するかを理解します。次に、実験について考え、環境内で継続的に実行します。blameless learning と分析をどのように考えるべきかを定義し、チームが快適な方法で学び、成長できるようにします。
記憶し、トレーニングし、システムがどのように機能するかを理解させ、自由に行動できる環境を与えます。これらのステップはすべて、再び1つの文で要約できます。確かに。覚えておく必要があるのはたった1つのことです：練習するように本番で行動し、本番で行動するように練習する。スポーツから得た素晴らしいことで、エンジニアリングチームに非常に適用可能です。本日ご参加いただきありがとうございました。質問にお答えさせていただきます。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion