ピークシーズンに対する準備

この記事では、プロジェクト マネージャーや技術リーダーがアプリケーションに対するユーザー トラフィックのピーク期間の実行プランを作成する際に役立つ情報を提供します。たとえば、米国では 11 月の最終金曜日はブラック フライデーと呼ばれ、1 年で最も多くの買い物が行われます。他の国でも、小売業者がトラフィックの急増を期待できる日や週があります。この記事では、ブラック フライデーのようなイベントに向けて組織的な準備、システムの信頼性、Google とお客様とのエンゲージメントを高める方法について説明します。

この記事では、次のシステムの概要を説明します。

  • イベントに対応するための 3 つの段階(計画、準備、実行)を管理する。
  • 技術チーム、運用チーム、リーダーの各関係者をプロセスや協力体制の改善に関与させる。
  • ブラック フライデーのようなイベントに対応するためのアーキテクチャ パターンを確立する。
  • Google のサイト信頼性エンジニアリング(SRE)のベスト プラクティスを推進する。

はじめに

小売業界の商取引システムは、短期間に平均負荷の 5 倍以上にもなるピーク時のリクエストを処理するという大きな技術的課題に直面しています。米国では、このようなイベントが、感謝祭の後の 11 月にあるブラック マンデーとサイバー マンデーで発生します。他の国でも、同様のピーク時イベントが他の時期に発生します。

この課題に対応する方法のひとつとして、クラウド ネイティブ システム戦略の採用があげられます。この戦略により、従来の手法と比較して、ピーク時の計画と実行が改善され、さらに新しい方式の導入も可能になります。

ブラック フライデーは米国における一大商業イベントですが、投票日の夜またはクリスマスや大みそかなどの祝日といった、他の状況で見られる特性もあわせ持っています。ピークイベントには一般的に次のような特徴があります。

  • トラフィックが 5 倍から 20 倍以上増加し、一般的にはコンバージョン率とバックエンド システムでの負荷が増大する。
  • イベントが始まりトラフィックが増加すると、短期間で急速なスケーリングが発生する。
  • イベント後にトラフィックが通常の水準まで減少する。通常、減少の速度はピークに達するときの速度よりも遅い。

トラフィックの大部分がトランザクションであるコマース システムでは、フロントエンドの増加はそれほど大きくならないこともあります。たとえば、フロントエンドのウェブ トラフィックの増加が 2~4 倍程度になる場合があります。一方で、バックエンド システムの負荷(注文/分)は 10 倍以上に増加することがあります。

次の図は、一般的なユーザー トラフィックの増加を示しています。トラフィックの特徴として、トラフィックが突然、大きな変動幅で上昇し、その後にゆるやかに通常状態に戻ることがあげられます。

ブラック フライデー イベントでのトラフィックの急増

ブラック フライデー イベントへの対応は、計画準備実行の 3 段階で行うことをおすすめします。次の図は、各段階で重要なロール、スキル、プロセスを示しています。

ブラック フライデー準備の 3 つの段階

運用スタッフと管理スタッフは、ピークイベントの戦術面について組織を主導します。3 つの段階とその中の活動を見直すことで、ピークイベントに適切に対応できるようチームの準備を進めることができます。イベント中に予期しない問題が発生した場合でも、この準備により、優先順位を迅速かつ正確に定め、問題の影響を小さくするための解決策を講じることができるようになります。

用語

ブラック フライデー
アプリケーションで発生する、あらゆるタイプのピーク トラフィック イベント。
QPS
秒間クエリ数。トラフィックの量についての共通指標。QPS はボリュームに関して一般的に使用され、注文/分より技術的な用語です。
注文/分
トランザクションの指標。この用語には、カート追加/秒などの他の指標も含まれます。これらの指標は詳細なトランザクション ボリュームを示していますが、QPS よりもビジネスとの関連性が高くなっています。
SLI
サービスレベル指標。サービスが許容範囲内にあるかどうかを判断するために使用される指標。ページの読み込み時間の SLI の例として、「95 パーセンタイルでの、ウェブページの読み込みと、基盤となるすべての API 呼び出し」などがあります。
SLO
サービスレベル目標。SLI とターゲット目標を使用して定義されます。SLO の例として、「直前の SLI レイテンシは 400 ミリ秒未満でなければならない」などがあります。
SLA
サービスレベル契約顧客とサプライヤー間の契約で定義されているサービスの信頼性目標、条件、結果(金融など)。SLA の例として、SLI レイテンシが 10 分間連続して 1 秒を超える場合、お客様には SLA 違反が発生してから 100 QPS を超えるトラフィックの請求使用料に対して、50% の割引が適用されます。

計画段階

「希望は戦略ではない」という格言は、綿密な計画や準備を行う根拠としてよく引用されます。複数の部門にまたがる計画と、組織内やサードパーティ ベンダーとの調整を十分に行うことにより、成功の可能性が高くなります。エンジニアリング、アーキテクチャ、運用、およびビジネスの各関係者は、測定する内容に同意し、ピークイベントが本番環境システムに与える影響を把握する必要があります。計画および運用システム サポートでは、データに基づいた意思決定により、チームの選択とトレードオフが決まります。

次の表は、計画段階の主な手順をまとめたものです。

計画の手順 タスク
データの収集 測定データを把握する。
以前のピークイベントを確認する。
ビジネス予測を準備する。
プログラム管理の確立 通信チャネルを設定する。
共有状態を確認する。
モニタリングと調査を設定する。
システムのモニタリングを確認する。
容量計画を作成する。
チェックリストを作成する。
リスク分析を共有し、優先順位を付ける。
アーキテクチャの計画 設計アーキテクチャを確認する。
ブラック フライデーのアーキテクチャ パターンを確認する。
フェイルオーバー戦略を作成する。

データの収集

計画段階の最初の手順は、データの収集です。

測定データを把握する

既存の測定データ(リクエスト/秒、命令/分、カート追加/秒)から始めると、ピークイベントの理解と計画の基礎を構築できます。このプロセスの最初に、次の質問を考えてみます。

  • 過去の平常時の運用とピーク時の運用について、どのようなデータを使用できますか。
  • そのデータはシステム上とビジネス上の適切な指標を測定していますか。
  • システムがどのように動作しているかを正確に把握するには、どのようなデータを収集する必要がありますか。

ここでの目標は、どのデータが使用可能であるか、過去にそのデータがどのような値であったかを判別することです。現在収集されていない指標や SLI がある場合は、そのデータに優先順位を付け、システムがこのデータを収集できるように準備段階で変更します。

データを収集するだけでなく、指標から得られる分析情報を把握することも重要です。指標がユーザー満足度やビジネス成功指標とどのように関係しているかを知れば、システムが非常に大規模な場合でも、指標をどのように解釈すればよいかがわかります。

以前のピークイベントを確認する

どのプロセスでも、以前のイベントから学ぶことは重要です。負荷の大きい状況におけるシステムの既知の制約の存在が明らかな場合には特に重要となります。テクノロジーの世界において、事後調査はデータを収集し、発生したインシデントを理解するための有用なテクニックです。

ビジネス予測を準備する

ブラック フライデーの影響を予測することで、商品の調達方法や販売の準備方法を計画できます。在庫管理、サプライ チェーン管理、人員配置などの要素は、ビジネス予測の正確さに左右されます。システムが急激なトラフィック増加に対応できるよう準備できるかどうかも、この予測の影響を受けます。以前の予測を詳しく知ることができれば、新しいビジネス販売予測はより正確なものとなります。これらの新しい予測は、システムに対する需要の予測を行うための重要な入力情報となります。

以下の主要ビジネス要因指標は、ほとんどの e コマースサイトで共通です。

  • アクセス数
  • コンバージョン数
  • 平均注文額

これらの要因を基礎として、システムが分析できる形式に指標を変換できます。このような指標には、次のようなものがあります。

  • クエリ/秒
  • 注文/分
  • カート追加/秒

さらに、これらの指標を SLI と SLO に変換し、システムの動作を測定したりシステムの正常性を示すことができます。

プログラム管理の確立

調整はブラック フライデーの成功の鍵となります。計画、準備、実行の各段階は、エンジニアリング チーム、アーキテクト チーム、運用チーム、リーダー、その他の内部関係者、サードパーティのベンダーと調整し、同意を得る必要があります。目標を共有するには、関係者が透明性の高いコミュニケーションと協力を行う必要があります。

適切な方法として、関係者をまとめるための部門間チームと実行委員会を設立することがあげられます。プログラム管理者がタイムラインを設定できるように、これらのチームを早期に設定します。プログラム管理者はインフラストラクチャの追加、テストのサポート、トレーニングのための予算とリソースを確保する必要もあります。

コミュニケーション チャネルを設定する

コミュニケーションは、ピークイベント実施のどの段階でも重要です。計画段階では、以下のものを作成します。

  • ピークイベント計画ドキュメント。次のようなものがあります。

    • 前提条件のリスト
    • 不明事項のリスト
    • イベントに関わるチーム、チームリーダー、関係者、責任者。担当範囲を明確に周知するため、責任分担表(RACI)またはそれに似た形式のリストを使用します。
    • 重要なタスクとそれを担当するチームを正確に示したタイムライン。明確であいまいな点のないもの。
  • 目的を明確にした定期的な会議。すべてのチームに進捗状況を知らせるための議事録も作成します。懸念事項を早期に把握し、問題が深刻化する前に全員で取り組みます。一般的にピークイベントは発生時期が決まっており、スケジュールが遅れると調整が困難になります。

  • エグゼクティブ サマリー ドキュメント。ピークイベントに関する最も重要な情報を、1~2 ページにまとめます。このようなドキュメントは配布しやすく、関係者が計画情報を把握するのに役立ち、簡単な問題の解決につながります。このドキュメントがあれば、新しく参加したメンバーもピークイベントの計画についてすぐに把握できます。

  • 運用チームがシステムの各要素を迅速に理解するための簡潔なアーキテクチャ ドキュメント。システム全体を把握する時間がある場合は、何百ものコンポーネント ボックスと多数の連結線を使用したアーキテクチャ ドキュメントがあると便利です。しかし、運用プロセスでは、主要コンポーネントの相互関係を理解しやすい図を使用すると、問題を迅速に特定し、早期に解決できます。

  • 運用サポート ドキュメントと問題の報告手順。これらの資料には、運用チームが問題の特定と報告を行う方法を明確に記述します。また、問題への対処方法を示し、開発者やベンダー サポートなど、他のチームとのエンゲージメントについても評価します。各種のインシデントを迅速に解決するための、共通のインシデント管理プロセスとテンプレートがあることを確認してください。

共有状態を確認する

共有状態とは、さまざまな視点を集めて、チーム間の合意を得ることです。視点が 1 つだけの場合とは異なり、この合意によりシステムを広い視野でとらえることができます。共有状態では、集団的な決定が、個人の決定の範囲を超えてシステムに影響します。たとえば、技術的な構成を少し変更しただけで、ビジネス指標に大きく影響することがあります。

各共有状態のレビューは、担当チームと、すべての関連チームの間で行われます。これらのレビューで Google Cloud チームと連携することにより、ブラック フライデーに関わる Google チームのコンテキストが構築され、Google チームは他のお客様への対応からベスト プラクティスについてのフィードバックを提供できるようになります。

モニタリングとプローブを設定する

モニタリングにより、システムの運用効率の維持について、十分な情報を得てから決定できます。また、モニタリングにより、システムの正常性を追跡でき、さらに今後発生する問題について事前に把握したり、次のようなアプリケーションの 4 つのゴールデン シグナルについての分析情報を得ることができます。

  • レイテンシ。システムへのリクエストを処理するために必要な時間。
  • トラフィック。システムに対するリクエスト。通常、1 秒あたりのリクエスト数で測定されます。
  • エラー。失敗したリクエストの比率。絶対比率、またはすべてのリクエストに対する割合で表します。
  • 飽和度。重要なシステム リソースの使用状況を示す指標。こうした指標は、データベース ストレージなどのリソースの残量不足を事前に通知するために使用されることもあります。

ピークイベントの問題を検出するには、これらの 4 つのシグナルの臨界値を理解することが不可欠です。実行可能な個別のモニタリング手順には、次のようなものがあります。

  • 収益や注文数などの主要ビジネス指標をモニタリングします。これらの指標により、個別のコンポーネントが正常に機能していてもシステム全体で見ると問題のあることが示される場合があります。また、メール マーケティング キャンペーンのスケジュールをモニタリングし、いつどれだけのメールが送信され、いつトラフィックがサイトに到達するかを追跡します。最後の 1 分でメールが爆発的に増えて予想以上のトラフィックが発生したり、キャッシュが不十分なページへのトラフィックが発生したりすることがあります。

  • ユーザー満足度を示す指標をモニタリングします。サービスの正常性について大まかな状況を示すダッシュボードをいくつか選び、個々のサブシステムまたはロケーションの詳細について確認します。

  • 詳細な予防策を作成します。たとえば、ブラックボックス モニタリング(プローブなど)とホワイトボックス モニタリング(エクスポートされたアプリケーション指標など)を組み合わせます。具体的には以下のような例があります。

    • プローブを設定して、Google Cloud からオンプレミス ネットワーク(VPN や直接接続など)にまたがるネットワーク接続のレイテンシ、パケット損失、スループットを測定します。

    • ブラックボックス プローブを設定して、利用しているサードパーティ サービスの可用性とレイテンシを測定します。さらに、サードパーティに対して、ダッシュボードとアラートの利用を依頼します。

  • トラフィックが突然増加するピークイベントは、システムに対する分散型サービス拒否(DDoS)攻撃に似ています。DDoS 攻撃対策の調整方法について検討しておくことで、保護システムによりコマース システムを利用する正当なお客様がブロックされないように備えることができます。

  • サイトのコンテンツと価格情報を収集するウェブボットは、ピークイベントの時期になると競争が激化するため、活動が最も活発になります。実際のトラフィックに対するボット トラフィックの割合(および種類)、ピークイベント時のボット トラフィックの変化、不要なトラフィックからシステムを保護する方法について定めておきます。

システムのモニタリングを確認する

用語の節にあるとおり、SLI は SLO の測定に使用します。モニタリングにより、SLI やその他の重要なシステム値をキャプチャできます。この方法で、以下のことを確認できます。

  • モニタリングによりどのシステム指標がキャプチャされているか
  • モニタリング レポートのレイテンシ
  • 目的のアラートレベル

モニタリングの理想的な用途は、パフォーマンスと SLO を確認するために重要な、関連するすべてのインフラストラクチャおよびアプリケーション指標をキャプチャすることです。

モニタリングは多くの分野で使用できます。

  • インフラストラクチャ指標:

    • 仮想マシン統計 - インスタンス、CPU、メモリ、件数対使用率。
    • コンテナベースの統計 - クラスタ使用率、クラスタ容量、ポッドレベル使用率、件数。
    • ネットワーク統計 - 上り / 下り、コンポーネント間の帯域幅、スループット対レイテンシ。
  • アプリケーション指標。QPS、書き込み/秒、送信メッセージ/秒など、アプリケーション固有の動作の指標。

  • マネージド サービス統計。Google が管理する API などのサービスや、BigQuery、App Engine、Cloud Bigtable などのプロダクトの QPS、スループット、レイテンシ、使用率など。

  • 接続統計。オンプレミス システムまたは Google Cloud 外のシステムへの接続に関する VPN / 相互接続関連の統計。

  • SLI。システムの全体的な正常性に関連する指標。これらの指標は一般的に特定のインフラストラクチャ コンポーネントよりも範囲が広く、API QPS レート、注文/分、カート追加/秒などの形で表されます。

  • アラートの応答時間やアラートのしきい値を考慮します。たとえば、問題が発生してから数分後に注文が 10% 減少したことを示すアラートを発信することもできますが、「1 秒間注文がない」というアラートを発信すればもっと早く問題が判明する可能性があります。

SLO を選択したら、すべての関係者から広く合意を得て、システム全体の正常性を示す主要指標の組み合わせを 1 通りに定めます。次に、システム異常動作のアラートと通知を構成するために必要なデータを絞り込みます。

容量計画を作成する

容量計画は、小売コマース システムでは重要なアクティビティです。クラウド ネイティブ システムでは、容量が動的に割り当てられるため、従来のシステムよりアーキテクチャの面でも技術的な面でも利点が多くなります。クラウド ネイティブ システムでは多くの場合、何千もの計算コアを使用し、大規模な容量を何万ものコアに分割することにより、負荷を平均水準に押さえています。この場合、クラウド プロバイダとクラウド インフラストラクチャ チームは容量計画について共同で責任を負うことになり、運用チームは信頼区間のある容量計画を作成する必要があります。これらの間隔により、VM を追加してさらにスケーリングを行うことができないなどの予期しない事態を回避できます。

これらの動的容量システムは、小規模で散発的な容量増加に対しては十分に機能します。しかし、自動スケーリングやジャストインタイム プロビジョニングに頼るのではなく、容量計画を確認して事前プロビジョニング容量を評価することをおすすめします。事前スケーリングや予約などの機能をどのように使用すれば自分やクラウド プロバイダがシステムの可用性を拡大できるか考えてみましょう。ピークイベントの直前にこのインフラストラクチャをプロビジョニングし、直後に規模を縮小して、クラウドの不要なコストが発生しないようにすることができます。

容量計画の効果を高めるため、Google は Google のお客様と次のようなベスト プラクティスを作り上げました。

  • 指標をピーク時の推定使用量にマッピングします。推定が誤っていないかどうかを評価するための計画を作成します。そのような計画を用意することで、確実性が増し、推定値を上回った場合にすばやく対応できます。
  • ピーク時に必要な容量と信頼区間を評価します。
  • クラウド プロバイダおよびインフラストラクチャ チームと協力し、容量を確認して確定します。
  • 「割り当て」と「容量」は異なります。割り当てはリソースを確保するための方法であり、容量はそのリソースがどれくらい必要かを表します。
  • 使用可能なリソース(コンピューティング、メモリ、ストレージ、ネットワーク、API 使用など)ごとに割り当てと容量を評価します。この評価は、負荷テスト時に、割り当てと容量に関する未知の問題を発見するのに役立ちます。
  • 全リージョンでの障害に対応できる割り当てと容量を設定します。
  • 計画段階で割り当てと容量を評価し、準備段階で調整します。

チェックリストを作成する

ブラック フライデーのようなイベントは定期的に発生します。次の年にもブラック フライデーはあります。他のプロモーション キャンペーンを実施したり、将来的に大規模なプロダクトをリリースすることもあるでしょう。各イベントには固有の情報がありますが、アセットは再利用と拡張が可能です。イベントが連続して発生するたびに、管理作業を少なくするためのチェックリストの作成、選定、改善を行い、プロセスを改善できます。チェックリストは航空機操縦士の飛行前チェックと同じで、エラーを防止し、一貫性のある実行を実現するために使用します。

チェックリストについては、次のようなベスト プラクティスがあります。

リスク分析を共有し、優先順位を付ける

リスク分析を関係者と共有し、優先順位を伝えることは重要です。分析では、システム、内部チーム、クラウド プロバイダ、およびサードパーティ ベンダーが保有するリスクを特定する必要があります。また、クラウド プロバイダやベンダーとリスクを共有します。リスクの中にはすでに判明していて許容できるものもありますが、その他のリスクについては、対策の作成にクラウド プロバイダやベンダーの協力が必要です。

アーキテクチャの計画

ブラック フライデーのアーキテクチャの計画は他とは異なる問題領域であり、独自におすすめの方法があります。ピークシステムの制約は、リスク分析に影響し、ピーク負荷テストを成功させるために重要な要素です。

設計アーキテクチャを確認する

すべての関係者が解決策を理解できるように、上位レベルの設計アーキテクチャを確認することをおすすめします。この確認により、チームに対して信頼性の問題を周知させることができます。たとえば、単一障害点(SPOF)や、Google からの alpha コンポーネントや beta コンポーネントの使用があげられます。すべての問題に対応することはできないかもしれませんが、問題の存在を認識することはすべてのチームにとって有益です。

システムの本番環境に向けた準備を進める際には、それぞれに特定のユーザー層を対象とする 2 種類のアーキテクチャが必要です。

  • システム アーキテクチャは、運用チームが重要なシステム コンポーネントを理解するのに役立ちます。主要コンポーネントの相互関係を明確な図で示すことで、問題の特定と解決をより迅速に行えます。

  • コンポーネント アーキテクチャは、コンポーネント間の重要な入出力点、依存関係、主要ワークフローをアーキテクトと開発者に説明する際に使用します。これらのコンポーネントは複雑なユーザーの行動プロセスを把握する上で重要であり、コンポーネントとデータフローのどの部分(在庫、価格、マスター商品データ、注文、請求書など)で問題が発生しているかを特定するのに役立ちます。また、データフローは、SLO の向上やモニタリング、プローブの判別を行う際にも活用できます。

ブラック フライデーのアーキテクチャ パターンを確認する

アーキテクチャ パターンは、クラウド ネイティブ システムを改善し、クラウド分散システムの課題の一部を管理するのに役立ちます。次のベスト プラクティスにより、ピークイベント中のクラウド システムの信頼性を向上させることができます。

  • キャッシュ システムを使用します。ただし、スケーリング操作中にこのシステムがどのように動作するかは把握しておきます。スケーリングの間は、キャッシュ システムは同じキャッシュ ヒット率では反応しません。この違いは、スケーリング プロセス中のキャッシュミスにより負荷が増大して起こるカスケードの問題につながり、想定よりも早くシステムを圧迫するおそれがあります。

  • Cloud CDN などのコンテンツ配信ネットワーク(CDN)を使用して、大規模なトラフィックの急増を緩和し、信頼性と可用性を高めます。CDN を使用すると、トラフィックが配信元サーバーに到達する前に、大規模なトラフィックの急増を抑制できます。

  • Cloud Interconnect インスタンスを、アクティブ - アクティブで構成されたインターネット ベースの VPN と組み合わせて使用します。アクティブ - アクティブとは、プライマリ接続パスとセカンダリ接続パスの両方が常時トラフィックの処理に使用されていることを意味します。一方、アクティブ - パッシブでは、プライマリで障害が発生するとセカンダリに引き継がれます。相互接続は、クラウド プロバイダとデータセンターの間の専用帯域幅をサポートします。さまざまな大都市圏とプロバイダで複数の相互接続をプロビジョニングすることをおすすめします。そうすれば、Dedicated Interconnect で 99.99% の可用性を実現するで説明するように、SLA と信頼性が向上します。VPN は、相互接続の障害が発生した場合や、短期的に容量が増加した場合に使用されます。

フェイルオーバー戦略を作成する

ブラック フライデーのような重要なイベントでは、準備ができていないチームは機能停止や十分でないカスタマー エクスペリエンスに悩むことになります。フェイルオーバー戦略を作成すると、チームが障害の根本原因を調査している間もシステムの稼働時間を確保できます。すべてが失敗し、障害に関連するリスクの評価とシステムの SLO の把握により信頼性とコストの間のトレードオフが生じます。

クラウド システムでは、次のフェイルオーバー パターンが使用されます。

  • 局所的な障害に対応する。パターンを作成することにより、各リージョン間で永続データを同期し、リージョンの障害に対処します。ステートレスなアプリケーション サーバーの処理は、データの同期に比べ容易です。マネージド サービスを事前に検討し、信頼性の向上と管理オーバーヘッドの削減のために使用します。また、同期パターンは、データ プラットフォームの機能と密接に関係しています。詳細な研究については以下のような記事があります。

  • システムを複数の場所にデプロイする。少なくとも 2 つ、できれば 3 つのリージョンにデプロイし、特定のゾーンやリージョンでクラウド プロバイダに問題が発生した場合のリスクを緩和します。

    • リージョンのフェイルオーバーや復元に備え、各リージョンで複数のゾーンを使用し、リージョン全体のフェイルオーバーを実行しなくても運用が継続できるようにします。複数のリージョンに対するデプロイは、お客様側でのレイテンシを減少させるほか、リージョンの機能停止へ対処する場合に役立ちます。

    • 採用したシナリオに最も適した種類のロードバランサを使用します。Google Cloud には、豊富な機能を持つさまざまなロードバランサが用意されています。詳細については、Cloud Load Balancing のドキュメントをご覧ください。

  • ピーク時の需要に対応するために、キャッシュなしでもシステムが機能することを確認する。キャッシュ システムで障害が発生した場合や、キャッシュのヒット率が低下した場合に備えて、事前にシステムのテストを行います。キャッシュ システムの障害やキャッシュの消去を原因とするカスケード障害によって、他のコンポーネントが過負荷状態になり障害を起こすおそれがあります。

  • CDN 障害に備えて計画する。この障害は、キャッシュ システムの障害に似ています。CDN プロバイダと協力して、CDN システムの障害により、ブラック フライデー中の負荷が想定以上に増大する場合の対応策を準備します。

  • すべてのフェイルオーバーのシナリオを自動化する。手動での作業を回避します。手動での対応には時間がかかり、間違いが起こりやすくなります。特に、機能停止への対応に追われる際にはその傾向が強まります。

  • 外部サービスへの依存に対する復元力を構築する。復元パターンを作成します。たとえば、サービス障害の発生時にカスケード障害を防ぐ「回路ブレーカー」パターンなどがあります。

  • サードパーティ製品のレイテンシを制限する。ウェブサイトのクライアント側コードで、サードパーティのウェブサービスに対する HTTP 呼び出しのブロックを制限または除去します。サードパーティでレイテンシや可用性の問題が発生すると、ウェブサイトがユーザーに応答しなくなる場合があります。

  • ネットワーク攻撃から保護する。DDoS 攻撃やウェブボットからサイトを保護します。Cloud Armor や、お使いになっている CDN のセキュリティ プラットフォームなどのウェブ セキュリティ ツールを使用します。

計画段階の成果物

準備段階と実行段階では、次のような計画段階の成果物が使用されます。

  • リスク分析。プロジェクトのさまざまなリスクについての可能性と影響を特定します。運用面、技術面、ビジネス面での要因、時間的な要因などがあります。
  • アーキテクチャ変更計画。通常より大きな規模での運用に対応するため、システムのどの部分を変更するかなどを計画します。
  • テストプラン。通常の想定を超えるレベルのトラフィックに基づいてシステムを評価した上で、一般的な障害テストのシナリオについて見直します。
  • コミュニケーション計画。すべての関係者と継続的に情報を共有します。問題が発生した場合の連絡手順に加え、関係者への周知や対応が重要になる問題が発生した場合のエスカレーション手順についても計画します。
  • SLO/SLI 合意。収集するモニタリング指標と SLI に関する合意内容について明記します。お客様の視点から見たシステムの可用性(SLO)についての合意も含まれます。また、SLO の遵守状況を確認しやすくするために、現時点で収集されていない指標やモニタリング ダッシュボードを実装する方法についても計画しておきます。サードパーティ ベンダーの SLA が採用する SLO の指標にどう影響するかについても確認しておきます。
  • チェックリストの一覧。一定の共通した手順に則って作業が実施され、一貫性を保った方法で確認されることを担保します。
  • 運用ハンドブックの一覧。ブラック フライデーの間に発生する恐れのあるインシデント シナリオについて記したハンドブックの一覧を用意します。ハンドブックを用意しておけば、正常な運用に迅速に復帰できるよう備えることができます。

準備段階

準備段階の目的は、システムがピーク時のユーザー トラフィックのスケーリングと結果の文書化を行う能力をテストすることです。準備段階を完了すると、アーキテクチャが高度になり、これによりピーク時のトラフィックはより効率的に処理され、システムの信頼性が向上します。また、この段階では、ピークイベントや発生する可能性がある問題を処理するためにプロセスの合理化をする際の、運用とサポートの手順も決定されます。この段階は、システムと運用の観点から見たピークイベントの方針となります。

次の表は、計画段階の主な手順をまとめたものです。

準備手順 タスク
信頼性を確保する 負荷とパフォーマンスのテストを設定します。
シナリオの評価とテストを行います。
スケーリングと信頼性のためにアーキテクチャを変更する キューとメッセージ仲介のための中間層を導入します。
キャッシュを実装してパフォーマンスを改善します。
負荷制限を実装します。
回路ブレーカー パターンを実装します。
モニタリングとロギングを設定する モニタリングを構成します。
ダッシュボードを使用してモニタリングを配信します。
フィードバックを使用して運用とサポートを修正する チェックリストとハンドブックを作成します。
サポートと問題の報告手順についてのトレーニングを行います。
成功のための運用チームを設立します。
容量へのリクエストを調整する 予想される必要なリソース容量を Google Cloud で確認し、共有します。
変更保留を決定する イベントの前に、新しいソフトウェアとインフラストラクチャをデプロイするための時間を割り当てます。
イベントをサポートするプロモーション アクティビティの間は、変更を行わないようにしてください。
バグの修正とタイミングについて、開発チームと調整してください。

信頼性を確保する

Google のサイト信頼性エンジニアは、Google サービスの信頼性と速度を重視しています。SRE はプラットフォームの正常性を担い、Google サービスの信頼性を可能な限り高いものにします。Google SRE のチームが 2 冊のを出版しました。この中では、大規模なシステムのビルド、リリース、運用を行う方法について、数多くのベスト プラクティスと、経験に基づくアドバイスを紹介しています。役に立つ情報がたくさんありますが、中でも特にブラック フライデー イベントを成功させる上で重要になるのは、負荷テストと障害テストです。

負荷テストとパフォーマンス テストを設定する

負荷テストは、システムのテスト バージョンをデプロイし、リクエストを作成して、システムの高い使用率をシミュレーションするプロセスです。負荷テストは通常、絶対的なピークより下の特定のパーセンタイルにおける、持続可能でユーザーが認識する動作のテストに重点を置いています。ピークのテストでは、その上位パーセンタイルで一定の良好なパフォーマンスを実現する必要があります。

負荷とパフォーマンスのテストでは、次のベスト プラクティスに従ってください。

  • 負荷テストとパフォーマンス テストはピーク時の 100% 以上のトラフィックで行う。パーセンタイルを調整して、ピークが 100% を超えるようにします。そうすることで、システムの動作性能がわずかに低下する可能性がありますが、トラフィックがピークに達した際に適切なパフォーマンスを発揮できます。

    ピーク時をどの程度超えるトラフィックのテストが必要でしょうか。その答えは、ピークイベントのトラフィックの信頼区間からわかります。ピークイベントの成功率を高くするには、信頼度が低いほど高い負荷が必要となります。事後の信頼区間が狭く正確である場合、ピークを超える割合を低くしてテストを行う必要があります。

  • 通常のトラフィックからピーク時のトラフィックまでの速度をテストする。ブラック フライデーで各店舗がオープンするときなど、ピークイベントによっては、トラフィックが数秒の間に突然変化する場合があります。そこで、通常時のトラフィックからピーク時のトラフィックに迅速にスケーリングできるかどうかをテストしておきます。システムによっては、負荷の発生を示すシグナルに対して反応が遅れることがあります。

  • 負荷がかかった状態でゾーン / リージョン単位のフェイルオーバー、再デプロイ、キャッシュ消去の各シナリオをテストする

  • 負荷がかかった状態でお客様の行動プロセスを想定したテストを行う。システム全体をテストして、ピーク時でもお客様のエクスペリエンスに問題が生じないことを確認します。個別のコンポーネントや実行パスの技術面でのテストでは、システムの信頼性は改善できますが、お客様のエクスペリエンスは測定できません。

  • カスケード障害を回避するために負荷制限を検討する。負荷制限を実装することにより、重要性の低いエクスペリエンスの優先度を下げ、最も重要なお客様の行動プロセスに障害の影響が出ないよう保護します。たとえば、カタログの閲覧やユーザー レビューの検索を無効にし、購入時のエクスペリエンスで SLO が維持されるようにします。

  • テスト結果の評価と共有を広く行う事後調査プロセスでは過失を責めるのではなく、問題に対処するためのオープンで公正な評価と建設的なフィードバックを促します。データベースのホットスポット、リソースの割り当てが適切でなかった項目、負荷により想定外の影響が波及した箇所など、原因の特定と修正の難しい要因に対してチームで取り組みます。

  • さまざまな負荷の組み合わせをテストする。モバイルとデスクトップの比較テスト、トラフィック発生元を地理的に変更した上でのテスト、トランザクションの種類ごとのテストなどを行います。それぞれで、システム上での負荷の発生箇所が異なります。

シナリオの評価とテストを行う

ピークイベントの成功の可能性を高めるには、イベント中に発生する可能性のあるシナリオを評価し、テストすることが重要です。システムが障害状況に対応できるかどうかをテストするため、Google DiRT、Netflix Chaos Monkey などの多数のプロセスやツールが設計されています。

最も影響が深刻になるシナリオのテストを準備段階で行うと、成功の可能性が高くなります。そのような状況がピーク時に発生しても、問題に対処するためのプロセスや技術的解決策があります。次のベスト プラクティスに従ってください。

  • 最も可能性が高い障害のシナリオをテストする。可能性 / リスク要因の重み付けにより、ピークイベント中に発生する可能性がある最も影響が大きい問題を特定します。負荷がかかった状態でその障害の状態を設計およびシミュレートし、システムの反応を確認します。事前に具体的な障害発生のシナリオを検討しておくことで、障害時の混乱に備えることができます。

  • 回路ブレーカー パターンの使用を検討する。アーキテクチャで回路ブレーカー パターンを実装できる場所を特定し、一部のコンポーネント / 機能をオフラインにした状態で運用を続けます。このアプローチは、システムが直接制御できる範囲にないサードパーティとの依存関係がある場合に特に重要です。サードパーティに依存しないようにすることで、大きく機能を損なうことなく一定のユーザー エクスペリエンスを維持できます。

  • 運用上の対応をテストする。運用チームによる障害対応は、システムによる対応より重要です。意図的に障害を起こしてテストするだけでなく、運用チームが予期せぬ事態への対応に習熟できていれば、非常に効果的です。

  • 可能な限り実際に近い形のテストをシミュレーションする。運用チームとサポートチームに内部情報を伝えずにテストします。内部サポートと外部サポートの連携についてテストし、対応にかかる時間や協力体制を検証します。また、問題発生時に運用チームがどのように行動するかも確認します。

  • 事後調査プロセスでは過失を責めない。問題の状況や対応、改善できる領域を文書化することで、今後、問題が発生した場合に確実に復旧できるようにします。

スケーリングと信頼性のためにアーキテクチャを変更する

負荷テストと障害テストは、アーキテクチャ レビューと同様に、限定された範囲でのアーキテクチャの変更を促進し、システムの規模と信頼性を高めるために役立ちます。ただし、変更を適用するとリスクも高くなるため、変更はわずかな時間範囲にとどめておくようにします。

考慮すべき変更の例をいくつか示します。

  • キュー / メッセージ仲介中間層を導入する。これにより、トラフィックと負荷の影響を受けやすいシステム(たとえば、在庫管理や注文処理などの小規模なシステム)を管理します。キューを使用することで、バックエンド システムでの負荷の急増を抑え、一定の過負荷動作を回避できます。
  • キャッシュを実装してパフォーマンスを改善する。キャッシュには次の 3 つの基本的なカテゴリがあります。

    • フロントエンド: Cloud CDN などのコンテンツ配信ネットワークの導入により、ユーザーに近いアセットを分散してシステムの負荷を軽減します。
    • アプリケーション レベル: バックエンド サービスのユーザーが、変化の少ないデータ(顧客レベルでの商品情報など)を Memorystore のキャッシュに保存できるようにします。
    • API レベル: Memorystore を利用する API を使用することで、API でデータをキャッシュに保存します。

    キャッシュへの過剰依存により誤ってカスケード障害が発生しないようにしてください。キャッシュを利用できず、基盤となるシステムがトラフィックを処理できない場合、スケールを達成するためのキャッシングは大変なものになります。

  • システム全体の障害を回避するために負荷制限を実装する。このアプローチでは、重要度の高いユーザーの行動プロセスに関わるシステムは高い負荷がかかっても処理が続行できるようにし、重要度の低いものに関わるシステムでは負荷を意図的に制限します。

  • 回路ブレーカー パターンを実装する。このアプローチでは、コンポーネントの障害が適切に処理され、カスケード障害が制御されます。このパターンを実装すれば、特定のコンポーネントで過負荷が発生した場合にも、呼び出し元コンポーネントに障害が波及することを防ぎます。

理想的には、これらのアーキテクチャの変更の多くは機能開発の段階で実装されているはずです。所定のリスクと十分なリソースがある場合、アーキテクチャの変更はシステムの可用性を向上させるのに役立ちます。

モニタリングとロギングを設定する

システムの動作を確認する場合、主要なイントロスペクション ツールとしてモニタリングとロギングを使用します。適切な情報の粒度と深度を適切に設定することにより、モニタリングとロギングのパフォーマンスに最適な量の計算とストレージを実現できます。

モニタリングを構成する

モニタリングでは、過去のイベントから適切な指標を特定し、現在のイベントと将来のイベントの指標の候補となる指標を確認し、システムを実装して指標の収集、集計、レポートをできるようにする必要があります。モニタリング構成の一部として、次の要素を考慮してください。

  • 計画段階で特定された新しい指標や SLI を取り込み、適切なシステム範囲を指定します。
  • モニタリングの構成内容を監査して、リソースのモニタリングが適切に行われるようにします。よくある誤りとしては、リソース作成の際に、リソースをモニタリングの対象とするプロセスが適切に指定されていないということがあります。

  • オートスケーラーや自己修復システムなどの自動化システムに通知を行う際に、モニタリング システムの指標を使用します。

  • モニタリングを運用ハンドブックの重要な要素として使用します。

ダッシュボードを使用してモニタリングを配信する

関係者間の共有状態を維持するため、モニタリング ダッシュボードを使用すると、すべての関係者が細かな指標ではなく SLO に注目するようにできます。ダッシュボードには次の利点があります。

  • 閲覧用画面が 1 つですむ。単一のシステムで指標を共有できるダッシュボードを使用することで、運用時の即応性が向上し、認識に相違の生じる可能性が低くなります。
  • レポートの粒度が適切になる。個々のリソースの問題は把握しづらくなりますが、情報を集約することで傾向をとらえやすくなります。
  • アラートが適切に行われる。適切なチームにアラートを送り、そのチームに標準的な方法で通知します。たとえば、ハンドブックに基づいて、モニタリング アラートをメール、SMS、ポケベル通知などで構成します。

フィードバックを使用して運用とサポートを修正する

既知の文書化可能な項目は計画段階で提示されています。準備段階では、アーキテクチャの変更、負荷テスト、および障害テストからのフィードバックを使用して、これらの文書を更新する必要があります。

チェックリストとハンドブックを作成する

有益なチェックリストを作成するには、次のベスト プラクティスに従ってください。

  • チェックリストが適切に使用されているかどうかをチェックリストのオーナーが確認できるようにします。また、オーナーがチェックリストの目標に沿って内容を変更できるようにします。
  • 許容可能なリスクに基づいて、問題を解決または緩和する計画を立てます。チェックリストの項目を実施できない場合は、次善の緩和策について部門間の合意を得ます。すべてのチームが緩和の影響を理解していることを確認します。

既知の問題や、障害テスト中に発見した一般的な問題のハンドブックを作成します。

サポートと問題の報告手順についてのトレーニングを行う

すべての運用チームメンバーが、自分の責任範囲と他のチームの責任範囲を認識していることを確認します。

  • オンコール チームメンバーが応答時間要件を把握していることを確認します。また、既存のドキュメントとハンドブックを使用して問題を早期に解決する方法を理解していることも確認します。
  • 仮想インシデント管理演習を作成します。ブラック フライデーの仮想指令室(このドキュメントで後述)を想定した指令室を用意します。さまざまなインシデントをテストし、チームの対応をテストします。また、インシデント時に適切な調整が行われるよう、Google へのイベントの報告もプロセスの一環に含めます。ただし、架空の P1 チケットを作成して Google に連絡をとる場合は、先に CE / サポート向けの P1 チケットを取り消してからにしてください。テストもしくは架空のものであると明確にラベルが付けられた P4 チケットであれば問題はありません。

    • Wheel of Misfortune 演習を実施します。この演習では、運用チームの準備状況、手順とハンドブックに抜けがないか、他のチームとの連携がうまくとれているかを評価します。
    • CDN でのキャッシュ処理の停止、価格設定の誤りでお客様が特定の SKU に殺到した場合の運用、リージョン単位での障害など、さまざまな状況を用意します。そして、運用チームがそれらの事態にどのように対処するかを確認します。

仮想演習を複数回実行して応答時間を短くできるようにし、シミュレーションを連続して行うことで調整を改善していきます。事後調査により、各演習の結果をキャプチャし、次の演習で段階的に改善していきます。

ベンダー サポートを調整する

連絡方法を確認し、詳細を他のチームメンバーやベンダー サポートに詳細を伝達します。ベンダーはサポート手順を複数の方法で実装するため、サポート提案にどのように対応するのが最適であるか把握することは重要です。サポートの応答と、可用性とレイテンシの指標についてのベンダー SLA を確認します。

Google Cloud サポートを利用する

Google Cloud は、Google Cloud サポートの利用を改善する方法についての情報を提供します。公開されているドキュメントはすべての顧客が閲覧できます。Google Cloud カスタマー エンジニアリングを直接利用している顧客、またはプラチナ サポートに登録している顧客は、Google 担当者に直接連絡して、サポート範囲を確認し把握できます。詳細については、このドキュメントの実行段階のセクションにある Google Cloud サポートをご覧ください。

成功のための運用チームを設立する

ピークイベントの対応は負担が大きく、感情面で左右されやすく、仕事が激務になりがちです。運営チームの過労を防ぐために、ローテーション プロセスを設定します。運用チームの休みを確保することにより、エラーが少なくなり、重大なインシデントが発生した場合の追加サポート要員も確保できます。以下のことを確認してください。

  • 運用チームがピークイベント時に担当する作業量が適切である。
  • 停止時間がスケジュールされている。
  • 全員が十分な睡眠時間を確保できている。
  • 運用チームによる問題報告のパスやバックアップが定められており、支援が必要な場合の連絡先が周知されている。

ほとんどの運用チームには、問題解決のために徹夜をした経験があります。このような努力は称賛されることが多いですが、超人的な努力を求めるよりは人員を交替させる方がよい解決策です。チームメンバーのクロス トレーニングを実施してスペシャリストを複数用意できれば、緊張とエラー率を少なくできます。

容量へのリクエストを調整する

計画段階では、Google Cloud や他のベンダーと容量計画を共有し、調整しました。この他に考慮する必要がある容量計画戦略には、次のようなものがあります。

  • 予想される必要なリソース容量をできるだけ具体的に Google Cloud で確認し、共有します。CPU、コア、ディスク、API QPS などの情報を共有します。組織の割り当てと個別のプロジェクトの割り当てが適切であることを確認します。必要に応じて調整します。
  • 予想を超えるトラフィックが発生した場合に備えて、割り当ての水準を予想使用量より大幅に高くする必要があります。
  • 割り当ては容量とは別のもので、システムに対する影響も異なります。大規模な負荷テストを行うと、API 呼び出しの上限などの Google Cloud での割り当てや、OAuth2 などの他の Google システムの割り当てを把握できます。
  • Google チームと定期的に会合を持ち、現在の容量に対する要求を確認した上で、必要に応じてその要求に対応できるようにしておきます。

変更保留を決定する

ブラック フライデーは、ビジネスにとって年間で最も重要なイベントのひとつになると思われます。ウェブ インフラストラクチャの負荷が膨大になりますが、一方でビジネスの収益を上げる可能性もあります。障害の主な原因は変更(想定されていたかいなかったかにかかわらず)です。さらに、アーキテクチャの変更はインフラストラクチャのスケーリング機能に影響する場合があります。そのため、ピークイベント中や、ピークイベントに到るまでの期間は、変更を保留することをおすすめします。

変更を保留する場合、次のベスト プラクティスに従ってください。

  • 新しいソフトウェアやインフラストラクチャをデプロイする場合は、イベントまでに十分な猶予期間を持つようにします。変更の保留を始める際には、正常時の負荷のピークと障害テストの結果を基準に含めます。
  • ビジネス プロモーション活動(たとえば、ブラック フライデー前の販売キャンペーンやマーケティング キャンペーン)は中断せず、それらの期間中は変更を行わないようにします。
  • マイナーなバグ修正のデプロイをいつまで行うか、開発チームと調整して合意しておきます。バグ修正は、アーキテクチャやインフラストラクチャの変更ほど早くに保留する必要はありませんが、このような変更がピークイベント近くにずれ込まないようにします。
  • サードパーティのサービスが変更保留を遵守していることを確認します。サードパーティがいつからいつまで変更を保留するか確認してください。拘束力を持たせるために、契約時の SLA の更新についても検討します。
  • クラウド プロバイダの変更管理プロセスについて確認します。ピーク期間中になんらかの変更が行われる可能性がある場合は、その内容についても把握しておきます。

準備段階の成果物

準備段階では、計画段階のドキュメントや準備段階で新たに生じた項目について修正を行います。次のような内容が例に挙げられます。

  • 準備段階のプロセスで計画段階の内容から修正されたものについて、見直しや修正を行った上で配布します。負荷テストおよび障害テストの結果、想定していた内容では不十分だと判明することがあります。その場合、スケジュール、リスク評価、対応能力、運用計画の修正が必要となるケースがみられます。
  • 情報を共有している関係者のグループに負荷テストと障害テストの結果を配布します。問題のなかった項目、改善された項目、新たにリスクが発見された項目について、全員が把握できているようにします。
  • モニタリングに際し、すべての担当者が同じ単一の画面を共有しており、問題なく利用できていることを確認します。情報へのスムーズなアクセスを確保することで、解決策を迅速に決定できるようになります。
  • 運用チームが実行段階に全面的に関わり、主導権を得ていることを確認します。
  • 人員配置計画が適切かつ合理的であること、担当者の休息が充分で適切な意思決定が可能であること、人員交替時の引き継ぎ手順があることを確認します。
  • キャパシティ プランが詳細まで文書化されており、その割り当てが Google Cloud 上で検証済みであること、また Google のシステム上で実装されていることを確認します。
  • 各ベンダーのベンダー サポート準備状況評価を完了します。サポートケースの作成手順と、ケースのエスカレーション手順について把握しておきます。

実行段階

計画段階と準備段階が完了すると、ブラック フライデーのプロセスは運に頼る段階ではなくなります。すべてが計画どおりに進んだ場合、ピークイベントは優れたサポートにより無事に終了します。運用チームには十分な情報と準備があり、予期されていないインシデントは発生していません。インシデントが発生した場合でも、そのインシデントを迅速に特定して解決できます。

次の表は、実行段階の主な手順をまとめたものです。

実行手順 タスク
ピーク容量まで手動でスケーリングする 規模を拡大するには、まずブラック フライデーの後に徐々に規模を縮小する計画が必要です。
迅速な復旧のために実行する 仮想指令室を準備します。
インシデント管理の経験を活用します。
ハンドブックの記載内容を実践します。
Google Cloud サポートと連携します。
データ配信プロセスを改善する 根本原因の分析を行います。
予測と実績を分析します。
事後調査と振り返りの結果をまとめます。
成功を伝えます。

ピーク容量まで手動でスケーリングする

自動スケーリング システムは予期しない急増には適していますが、ほとんどの場合、トラフィックの 5~10 倍の増加に対応するためのメインのスケーリング プロセスとしてはおすすめしません。一般的に、自動スケーリング システムは小さな増加幅でしか使用されません。通常は評価サイクルごとに追加容量の VM 1 つです。システムが追加容量の VM 数十個から数百個にまたがり迅速にスケーリングする必要がある場合は、システムを手動で適切な範囲にスケーリングすると、ユーザー エクスペリエンスが向上します。

手動スケーリングを使用すると、システム容量がゆっくりと増加します。これにより、システムが準備され、キャッシュも利用できるようになり、仮想マシンの起動などの時間のかかるイベントを、ピークイベントの開始前に発生させることもできます。このプロセスは、システムで容量が使用可能であることを確認する安全上のチェックとしても有効です。

ピーク時のトラフィックまでスケーリングすることが第一の目標ですが、ブラック フライデーの後に徐々に規模を縮小する計画も必要です。通常のトラフィックを対象とした元のスケーリング戦略が実行されていて、一方でトラフィックがまだ通常の水準に戻っていない場合は、規模の縮小が速すぎると機能が停止する可能性があります。

迅速な復旧のために実行する

運用チームの第一の目標は、システムの信頼性と運用性を維持することです。エンジニアは、問題の発生中に問題の根本的な原因を調べて、問題に関するデータを収集しようとする傾向があります。根本原因の分析は重要ですが、ここでは復旧に集中しましょう。データを収集して分析のため保存する一方、労力の大部分はシステム復旧に費やすことになります。たとえば、容量の追加、パフォーマンスが低いコンポーネントの削除、システムの再起動などがあげられます。インシデントが緩和した後、いつでも問題の原因をオフラインで分析できます。

仮想指令室を設置する

実行を主導する立場にあるのは運用チームのメンバーですが、関わる人間は他にもいます。チーム間の協力体制により、運用チームは社内およびベンダーからのサポートを得られるようになります。

仮想指令室では、すべての関係者がピークイベント中にチームワークの精神を共有します。関係者は迅速にアイデアを共有できます。非同期チャット システムやメール通信のような時間差はありません。仮想指令室の導入により、作業速度は向上し、参加も簡単になります。

また、ピークイベント専用のサブチーム スペースの作成もおすすめします。このようなサブスペースの導入により、メインの指令室では複数のインシデントが発生した場合に迅速に優先順位を設定して委任できます。

インシデント管理の経験を活用する

適切な人物がインシデントに対応していることを確認するため、インシデント管理プロセスで障害テスト、卓上実験、テスト実行を行います。運用チームがインシデント管理プロセスを問題なく実行できれば、全体的な対応と解決率が向上します。

ハンドブックの記載内容を実践する

進行中のインシデント、システム アラート、および報告された問題にはハンドブックが必要です。チームはハンドブックにより迅速に各状況に優先順位を設定し、解決方法があるかどうかを判定します。予期しない問題が発生した場合のために、ハンドブックには、チームが問題を迅速に特定して解決するのに役立つデータが含まれています。しかし、ハンドブック用のメモを追加し、建設的なフィードバックを集めることは、最優先事項ではありません。その代わりに、情報を記録し、事後調査をスケジュールして、ハンドブックの実行を確認します。

Google Cloud サポートと連携する

Google Cloud サポートを利用する場合は、できるだけ具体的に情報を述べるようにし、明記されていない情報を前提としないでください。これにより、サポートは問題をお客様の視点からとらえることができ、調査対象を正確に絞り込むことができます。次の 4 つの重要な詳細情報に注目してください。

  • 時間。明確に表現し、相対的な表現を避けます(「今日の朝」や「昨日」などは使わないでください)。タイムゾーンも明示します(できれば UTC を使用します)。Google のエンジニアがログやその他のデータを参照する際、お客様のローカル タイムゾーンで確認できない場合があります。また、エンジニアがお客様とは異なるタイムゾーンにいる場合もあり、お客様の伝える時刻を正しく把握できないことがあります。

  • プロダクト。プロダクトと、そのプロダクトに対して実行している処理を明らかにします。「機能しない」というだけでは、お客様側で見えている現象と Google で確認できる現象が同じものなのかどうか正確に判別できません。

  • ロケーション。リージョンとゾーンを明示します。この情報は、ソフトウェアのロールアウトなど、ロケーション特有のイベントが発生している場合に有用です。また、お客様の問題と別のイベントとの相関関係が明らかになる場合もあります。

  • 特定の識別子。プロジェクト ID、請求 ID、個別の VM、その他の関連する識別子を明示します。お客様は多くのプロジェクトとリソースを所有していますが、Google が認識していないお客様独自の命名方式を使用していることがあります。Google が正しいプロジェクト、請求アカウント、リソースを認識できれば、早期の解決が可能になります。

サポートのケースを開始するには、できるだけ多くのデータを提供し、エンジニアからの情報のリクエストに確実に回答するようにしてください。迅速な解決ができるように、スクリーンショット、tcpdump 出力、ログファイル スニペット、およびその他のリクエストされた情報を提供してください。

Google では次のようにトラブルシューティングを行います。

  1. システム観測情報を収集して共有します。
  2. 観測情報を説明する仮説を作成します。
  3. 仮説を証明または否定できるテストを特定します。
  4. テストを実行し、結果の内容に合意します。
  5. 次の仮説に移ります。
  6. 解決するまで繰り返します。

これらの手順を一緒に進め、進捗に関する情報を共有することで、ケースの解決を劇的に早めることができます。

データ配信プロセスを改善する

新しいサイクルの最初の手順はデータ収集ですが、実行段階の最後の手順はデータ配信となります。指標とログ、プロセス中に作成された他の成果物が揃っていることを確認します。これにより、次のサイクルを開始して新しく計画段階を始めるための基礎を固めることができます。

根本原因を分析する

根本原因の分析(RCA)では、除去されればシステムが正常に動作するようになる、システム内の最低レベルの障害を特定します。データ収集コンポーネントの場合を除き、障害発生時に RCA を実行することはおすすめしません。システムのバックアップ時に、イベントの発生中およびその直後に生成されたデータの収集と保存を行います。システムの復旧が完了したら、すぐに RCA を実行し、時間の経過に伴うデータの劣化や減少が発生しないようにします。

RCA では次の作業を行います。

  • 「5 つのなぜ」分析を利用して発生した問題を記述する。
  • データがシステム障害のどの時点のものであるかを示す詳細なタイムラインを作成する。
  • システム障害の二次的要因を一次的要因から切り離す。問題の根本にある要因の特定を試みる。それぞれの要因について分析を繰り返すことで、障害に関与している最低レベルのコンポーネントを特定できます。
  • 検出、アラート、および自動緩和の可能性に注目する。

    • 問題の検出と診断にはどれくらいの時間がかかるか。
    • テレメトリーはすべて使用可能であったか。
    • 早期の警告があったか。
    • アラームはトリガーされたか。どのくらい早くトリガーされたか。運用チームが即座に把握して行動するのに十分な情報がその中に含まれていたか。
    • 依存関係アラームは多すぎなかったか。関連するものをまとめたり、制限をかけたりする必要はあるか。
    • アラームを自動緩和アクションに関連付けることはできたか。

インシデントごとに個別の調査が必要です。インシデントが重複する場合は、サポートと協力して、原因となる関係が存在しないか確認します。根本原因が判明した場合は、将来のインシデントを防止するためにすぐに実行できるアクティビティのリストを作成します。インシデントを緩和し、再発を防止するためのリソース、時間、コストを特定します。インシデントのためシステムが SLO を満たせない場合、必要に応じて再発防止のためのスケジュールを設定します。

予測と実績を分析する

サイクルの最初の手順のひとつに、過去のイベントからデータを収集して、将来の需要を予測するための基礎とすることがあります。相違点とその原因を特定することで、将来のピークイベントの計画担当者を支援できます。ビジネス指標が SLO に与える影響を理解することにより、システムの信頼性を高める方法を特定できます。

また、容量計画も確認します。容量が期待値以下の領域では、インシデントで追加容量が発生する可能性があります。

事後調査と振り返りの結果をまとめる

事後処理と振り返りのプロセスを行うことをおすすめします。このプロセスでは、すべてのチームが発生したすべてのイベントについて詳細な情報を共有します。また、ピーク時のお客様の行動や Google のシステム動作に関する情報についても共有します。すべてのチームでそれらの事例を確認し、将来の計画に反映させます。

事後調査と振り返りのプロセスでは次の情報を収集します。

  • プロセスおよび計画段階のどの手順が効果的だったかの分析。
  • 準備段階と実行段階で実施された作業のさまざまな観点からの考察。また、それらの段階の改善に関するフィードバック。
  • ベスト プラクティスと解決策を発表し、他の顧客が Google Cloud を有効に利用できるようにする。
  • エンジニアリング、運用、プロジェクト管理、ビジネス、リーダーのそれぞれの視点からの情報。必要に応じて、より広い範囲のお客様から経験した内容を聴取します。
  • 書面の情報と、会議で議論された情報。会議から得られた考察が、初期の段階では書面に反映されていない場合があります。

成功を伝える

ブラック フライデーの成功に貢献した部門間チームのメンバーに成功を伝えます。チームと各個人に感謝し、成功を祝います。

チームがこの成功を振り返り、評価することで、長く苦労の多いプロセスから解放されることになります。仕事の満足度は、長期的なチームの成功のための重要な要素です。立ち止まって、これまでのことを思い出しながら、成功を祝いましょう。

実行段階の成果物

実行段階の成果物は、ブラック フライデー イベントの成功、および計画、準備、実行の各段階の終了です。この段階の最大の成果物は、次のようなデータの収集と分析です。

  • 指標、SLO、キャパシティ プランにおける予測データと実際のデータの見直し。
  • 実行段階で発生したインシデントの根本原因の分析。
  • 事後調査と振り返り。問題のなかった項目と改善が必要な項目(および具体的なアクション アイテム)を特定します。

次のステップ

この記事だけで十分とは言えません。ブラック フライデーの前や期間中の不安を軽減できるように、社内で、あるいは Google Cloud チームと協力して、この記事で取り上げていない質問やコメントをまとめてください。また、次のトピックも参考にしてください。

  • 他の SRE プラクティスについても研究し、スケーラブルな本番環境をサポートする体制を編成する。
  • YouTube Next 2018 のプレゼンテーションで、このドキュメントの内容と Google 顧客の視点を確認する。
  • 顧客信頼性エンジニアリングを参照する。これは、Google がお客様と提携する際のエンゲージメント モデルで、より信頼性の高いシステムをサポートするためのものです。
  • Cloud Load Balancing について学習する。これは、いくつかのアーキテクチャ設計パターンで使用されているツールです。
  • 経験を同僚や新しいチームメンバーと共有する。成功(と失敗)の経験から学んで、チームの次回の成功につなげられるようにします。得られた知識は、Google Cloud コミュニティに投稿できます。
  • Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。