Google Cloud Platform

ダーク ローンチの実用性 : CRE が現場で学んだこと

ダーク ローンチに関する前回の記事では、この手法のコンセプトについてお話ししました。ダーク ローンチでは、受信トラフィックのコピーを新サービスに送信し、結果を破棄します。これは、既存サービスの新バージョンを立ち上げるにあたって、実際の立ち上げ時に予想外の事態が発生することを避けたい場合に便利です。

ダーク ローンチは簡単なことであるように思えるかもしれませんが、必ずしもそうとは限りません。今回の記事では、困難な状況に追い込まれる可能性のある例をいくつか紹介するとともに、その対処法についても解説します。

ライブ トラフィックの想定

サービスの既存トラフィックは実際に手元にあるのでしょうか。新たなウェブ サービスを立ち上げようとしていて、それが既存サービスをほぼ直接置き換えるようなものでない場合、その答えは “No”(手元にはない)となるのではないでしょうか。

たとえば、オンライン カタログ会社がユーザーに対して、実際の店舗の在庫から商品を閲覧できるようにしているとします。システムは問題なく動いていますが、その商品をユーザーが購入できるような機能を追加するとなったら、その機能に対するダーク ローンチはどのように実施すればよいのでしょうか。商品を購入する機能がユーザーから見えない状態で、実際の利用状況をどうやって把握すればよいのでしょうか。

その方法の 1 つとして考えられるのは、既存コンポーネントに対するユーザーのクエリが発生するたびに、新しいコンポーネントにダーク ローンチのクエリを送り込むことです。上述の例の場合は、ユーザーがある商品に対して “閲覧” というリクエストを送信したときに、その都度バックグラウンドでその商品に “購入” リクエストを送るのです。実際には商品を閲覧したユーザー全員が購入するわけではないので、5 回の閲覧につき一度だけ購入リクエストを送るといったようにダーク ローンチをランダム化します。

こうすることで、ライブ トラフィックの量やパターンがだいたい想定できます。ただし、これがサービス開始時に発生するライブ トラフィックを完全に再現したものだと考えてはいけません。「何もないよりはいい」という程度にとらえるべきでしょう。

ミューテーション クエリのダーク ローンチ

一般に、読み取り専用のサービスではダーク ローンチも比較的簡単です。ただし、バックエンド ストレージにミューテーションを与えるようなクエリが発生するサービスの場合は、そう簡単にはいきません。それでも、そうした状況でダーク ローンチを実施すべき大きな理由があります。他ではきちんと実施できそうにないテストがある程度できるためです。とはいえ、ダーク ローンチを最大限活用するには大変な努力を必要とします。

ストレージを移行する場合を除き、ミューテーション クエリのダーク ローンチには多大な努力が必要となり、見返りや代償も伴います。一番簡単なのは、ダーク ローンチのトラフィックに対するミューテーションを無効にし、ミューテーションの準備が整ったにもかかわらず、それが送信される前にダミーのレスポンスを返す方法です。

この方法は安全ですが、ダーク ローンチしたサービスを完全には測定できないことになります。これでミューテーション リクエストの 10 % が間違って指定されるようなバグがあったら大変です。

代替案として、ミューテーションを既存ストレージの臨時コピーに送る方法もあります。テストの精度を上げるにはこちらのほうがよいのですが、臨時コピーからのレスポンスを実際のユーザーに送信しないよう細心の注意を払う必要があります。また、ダーク ローンチが終わり、新サービスが稼働した後も臨時コピーのストレージにミューテーションを送り続けていると、非常に残念なことになります。

ストレージの移行

既存システムの保管データをあるストレージから別のシステムに移行するような場合(たとえば、MySQL はもう必要ないので MongoDB に移行する場合)、ダーク ローンチが非常に重要となります。ただし、クエリを含め、ミューテーションの扱いには特に気をつけてください。最終的に新旧ストレージ システムの両方でミューテーションを実施する必要があり、その際に新ストレージ システムを全ユーザーのクエリの標準ストレージとする必要があるのです。

移行中は、新ストレージ システムに何か不具合が発生した場合に備えて、常に古いシステムに戻せるようにしておくことを原則としてください。新旧システムのどちらがクエリのマスターで、どちらが基準の状態を保っているのかも把握しておきましょう。一般にマスターのステータスは容易に変更可能としておく必要があり、データを紛失することなく元のストレージ システムがマスターになれるようにしておかなくてはなりません。

どんなストレージ移行においても、システムの利害関係者と関連システムの技術専門家によってレビューされた詳細な計画書が必要です。ただし、完璧な計画書というものは存在せず、欠けている部分は移行の過程で補うことになるでしょう。ストレージ システムの移行は非常に大変な冒険となることもあるので、今後このブログで取り上げたいと思います。

2 重トラフィックのコスト

うまく実装されているダーク ローンチのメリットは、新旧サービスの両方のクエリ処理という面で完全なサービスが実践できる点です。ただし、これは各クエリの処理に 2 倍のコストがかかるということでもあります。つまり、次の点で注意が必要です。

  • バックエンドが既存トラフィックの 2 倍に対処できるようにプロビジョニングを適切に行ってください。他チームのバックエンドも担当している場合は、そちらもダーク ローンチの影響を受けないようにクォータ(割当量)を一時的に増やしておきましょう。
  • 接続が気になるときは、フロントエンドが 2 倍の接続数に十分対応できるようにしておきましょう。
  • 既存のフロントエンドからのレイテンシは当然監視すべきですが、その数値にしっかり注意を払い、既存のアラートのしきい値を上げることも検討してください。サービスのレイテンシが増加すると、サービスのメモリも増える傾向にあります。そのため、これらの数値が既存の制限を超えないことを常に確認するようにしましょう。

場合によっては、サービスのトラフィックが大きすぎるために 100 % のダーク ローンチが現実的でないこともあります。その場合は、現実的なローンチの最大値を見極めたうえで計画を立て、ダーク ローンチで最も代表的なトラフィックを選択するようにしてください。

ちなみに Google の場合は、新サービスを一般公開するにあたって、まず社員に対して公開することが多いのですが、これまでの経験から、Google 社員のサービスの使い方は必ずしも他の人たちの使い方を代表するわけではないことがわかってきました。

サービスが非常に多くのキャッシュを利用するときに気をつけるべき重要なことは、50 % 以下のダーク ローンチではキャッシュの物質的な恩恵が受けられず、想定される負荷を大幅に水増しして 100 % とする可能性が高いことです。

新サービスを現状のトラフィックの 100 % 以上の負荷でテストしてみるのもよいでしょう。たとえば、既存のクエリが発生するたびに 2 つのクエリを新サービスに送るといったように、一部のトラフィックを倍増させるのです。これも悪くはないのですが、それに応じてクォータも増やしておくようにしましょう。ただし、キャッシュの影響を受けるサービスの場合は、キャッシュのヒット率が人工的に高くなっているため、この方法はあまり役に立たないかもしれません。

2 重トラフィックによる負荷の影響があるため、このテストではロード シェディングの利用方法を注意深く検討する必要があります。特に、ダーク ローンチのトラフィックはすべてシェディング可能とし、負荷が高いときはシステムによって最初に破棄されるリクエストとなるべきです。

いずれにしても、CPU / メモリの使用量やレイテンシが予想外に上昇したときは、サービスのオンコール担当者はダーク ローンチを 0 % に落として様子を見るようにしてください。

まとめ

新サービスのダーク ローンチを検討しているのであれば、ダーク ローンチ計画書を書いてみましょう。そして、計画書の中で以下の質問に答えるようにしてください。

  • 分岐させて新サービスに送ることができる既存トラフィックが手元にあるか。
  • どこでトラフィックを分岐させるのか。アプリケーションのフロントエンドなのか、それとも別の場所なのか。
  • 新バックエンドにメッセージを非同期に送り込むのか、それとも待機してタイムアウトを適用させるのか。
  • ミューテーションを起こすリクエストにどう対処するのか。
  • 新旧サービスのレスポンスをどのように、そしてどこでログ化するのか。また、どう比較するのか。
  • レスポンス コード、バックエンドのレイテンシ、レスポンス メッセージのサイズなどはログ化するのか。
  • レスポンスの差分は行うのか。意味のある差分を見いだせず、比較しなくてもよいフィールドはないのか。
  • バックエンドが現状のピーク トラフィックの 2 倍に対応できるようになっていて、臨時のクォータを配分しているのか。
  • もし未対応の場合は、何 % のトラフィックでダーク ローンチを停止するのか。
  • ダーク ローンチを実施するにあたり、対象となるトラフィックをどのように選択するのか。ランダムに選択するのか、それともユーザー ID などによって分けるのか。
  • ダーク ローンチの実施を知らせておくべき部署はどこなのか。その部署は懸念の連絡方法を把握しているのか。
  • 新サービス稼働後のロールバックのプランはどうなっているのか。

「人生、そんなにサプライズや興奮することなんてない」と言う人もいるでしょう。そういう人はダーク ローンチを実施しなくてもいいと思います。ただ、現状のサービスだとアドレナリンが出て困るというような人はダーク ローンチをお試しください。そうすれば、新サービスを立ち上げたときに退屈でたまらない時間が過ごせることでしょう。

* この投稿は米国時間 8 月 11 日、Customer Reliability Engineer である Adrian Hilton によって投稿されたもの(投稿はこちら)の抄訳です。

- By Adrian Hilton, Customer Reliability Engineer