BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Datadogがダークローンチ監視のベストプラクティスを公開

Datadogがダークローンチ監視のベストプラクティスを公開

ブックマーク

原文(投稿日:2021/08/22)へのリンク

Datadogは先頃、ダークローンチ(Dark Launch)に関するベストプラクティスを公開した。そのブログ記事には、ダークローンチと、まざまなメトリクスやダッシュボード、さらには監視のためのベストプラクティスが詳細に説明されている。

DatadogのテクニカルコンテンツライタであるPaul Gottschling氏は、インフラストラクチャ上の問題発生を回避する手段として、ダークローンチの成功をテストする方法を説明したブログ記事を執筆した。記事の中で氏は、ダークローンチの監視に関するさまざまな面を説明する手段として、オフィスミーティングを予約するSaaSサービスの仮想デプロイメントを使用している。

Gottschling氏が推奨するのは、ダークローンチの成功を判断するための基準の確立だ。一般的にこれは、サービスのパフォーマンスを追跡するための、サービスレベル目標(SLO)の設定とサービスレベル指標(SLI)の定義によって行われる。

 

 
Datadogの厚意による

この状況では、すべての監視データにバージョンをタグ付けする必要がある、とGottschling氏は言う。そうすることによって、最新リリースとともに、ダークローンチのパフォーマンスの健全性を可視化することが容易になるからだ。

例にあげた予約サービスにおいては、SLIはサービスの稼働時間、内部サーバエラー(HTTP 500)を発生させたリクエストの割合、500ms以上の95パーセンタイル応答レイテンシのリクエストの割合、などである。

 

Datadogの厚意による

アラートやダッシュボードにもバージョンタグが必要だ。それにより、ダークローンチの動作に問題のある場合に適切なチームにアラートを伝えたり、2つのリリースのパフォーマンスを比較することが容易になる。

SLIの面でアプリケーションが正しく動作しているように見えても、データ処理においてバグのある可能性がある、とGottschling氏は注意を促す。従って、クライアントのリクエストに対する、期待に反したレスポンスを監視することが非常に重要だ。これはつまり、エンドユーザのエクスペリエンスを低下させないように、ダークローンチの問題を識別し、修正しておく必要がある、ということである。

これを実現するのは、ログの解析と自動テストの実行だ。氏が指摘するように、ダークローンチの結果からバグの調査を可能にするためには、ペイロードからの重要な情報を含む構造化ログメッセージ(JSONなど)を発行するだけではなく、バージョンによってタグ付けされたログを発行するように、サービスを設計することが重要である。この方法によって、ダークローンチからのレスポンスと、リリースバージョンのサービスのレスポンスを比較することが可能になる。

ダークローンチが実際の運用に供与可能なレベルに達したかどうかを判断するためには、SLIベースのアラートやダッシュボードに加えて自動テストも必要になる、とGottschling氏は指摘する。

ここでの自動テストは、事前定義されたユーザインタラクションのセットに対して、ダークローンチが期待された結果を返すかどうかをチェックするものだ。ダークローンチによる障害とサービスのリリースバージョンによる障害を識別するため、テストにはバージョンをラベル付けする必要がある。これらのテストはCI/CDへの統合も容易で、サービスへの問い合わせと応答の評価を行うことができる。

Gottschling氏は、ダークローンチ用に運用インフラストラクチャをスケールアップすることの重要性について論じた上で、ダークローンチがネガティブな影響を与えることのないように運用インフラストラクチャを監視することも同じように重要だ、と述べている。

これには2つの大きな理由がある — ひとつは、運用インフラストラクチャがダークローンチを処理するために十分なキャパシティを持っていることを確認するためであり、もうひとつは、ダークローンチと運用インフラストラクチャの他部分との無用なインタラクションを見つけるためだ。

ダッシュボードと自動アラートは、重要なリソースメトリクスを監視するために開発される。ここでのメトリクスは、リソース利用度のしきい値を越えたインフラストラクチャのストレスを示す。また、これらのしきい値に対する自動アラートは、提供するコンテキストのバージョンでタグ付けされていなくてはならない。

さらに、デプロイメントを管理するために使用されるインフラストラクチャのリソースも監視する必要がある。例えば、リリースされたバージョンとダークローンチの間でリクエストをミラーするためにリバースプロキシを使用しているならば、大量のリクエストを処理する上で十分なCPUとメモリ容量を用意しておかなければならない。

さらにGottschling氏は、運用されているユーザデータを保護することと、ダークローンチと永続化レイヤ間の意図しないインタラクションを監視することの重要性も指摘している。ユーザデータの保護には主として、永続性レイヤに対して読み取り専用アクセスをするようにダークローンチを調整する方法と、ダークローンチがアクセスする永続性レイヤの専用インスタンスを用意する方法との2つがある。

期待していないインタラクションを識別するためには、アプリケーションにトレース用機能を実装して、サービス間のリクエストのマップを視覚的に表示する必要がある。あるいは、ダークローンチの永続化レイヤを監視して、リリース済サービスあるいはダークローンチの結果として異常に重い読み込みや書き込みが発生していないことを監視する、というのも重要だ。

ダークローンチとは、新しい能力や機能を公的に発表する前に、システムに対する付加的ロードやパフォーマンス上の影響を測定するという、デプロイメント戦略のひとつで、一般的にエンドユーザが感知することはない。

引用したブログ記事の全体は、Datadogのブログにある。このブログには、クラウドプラットフォームを監視するためのベストプラクティスやアプローチを説明したさまざまな記事や、その他の日技術的な話題が含まれている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT