概要

Azure の Cloud Adoption Framework と Datadog を併用することで、オンプレミスや他のクラウド環境から、新しいクラウド環境への安全かつ迅速な移行を実現することができます。

以下が可能です。

  1. チームがワークロードの移行を効率的に実行できるように、Datadog のアカウントを準備します。これが「計画」の段階です。
  2. Datadog を使用して、元の環境と新しいワークロードの健全性を測定し、チームが新しいランディングゾーンでそれらを起動するときに使用します。これが「移行」の段階です。

このガイドは、Azure の Cloud Adoption Framework に従った組織のための移行プロセスを文書化したものです。

Datadog のアカウントをまだお持ちでない方は、2 週間のトライアルを開始することができます。

計画

移行を計画する際には、以下のようにして、新しいワークロードが Azure アカウントに移行されると同時に、Datadog アカウントで監視できるように準備します。

  1. Datadog と Azure のインテグレーションを有効にし、新しいワークロードのパフォーマンスと健全性を示すことができるようにします。
  2. 移行時にワークロードを説明するために、チームが使用できるタグ付け戦略を文書化します。
  3. 関係者が移行の進捗状況を確認し、新しいワークロードの全体的な健全性を理解するために使用できるダッシュボードを構成します。
  4. インシデント対応のためのコミュニケーションチャンネルを確立します。

Datadog と Azure のインテグレーションの有効化

Datadog と Azure は提携し、Azure アカウント内で Datadog のサービスを提供します。ランディングゾーンごとに、Datadog リソースを作成し、Datadog アカウントと Azure アカウントをリンクし、Azure 内の観測性データにアクセスすることができます。

Datadog で収集したい Azure データを決定するためのこのプロセスの詳細については、Microsoft Azure のドキュメントを参照してください。

Datadog リソースは、Datadog-Azure インテグレーションの膨大なリストのセットアップを合理化し、新しい Azure ワークロードの健全性とパフォーマンスに関するチームの可視性を大幅に向上させることができます。Datadog は、ワークロードのパフォーマンスデータをビルドおよびリリースイベントと関連付けることができるように、Azure DevOps インテグレーションを有効にすることを推奨します。

このインテグレーションの設定については、Microsoft Azure DevOps を参照してください。

Datadog は、Microsoft Teams や Slack など、チームの注意が必要なときのコミュニケーションを改善するためのインテグレーションを多数提供しています。

組織で使用するすべてのコミュニケーションインテグレーションを追加します。インテグレーションの全リストとセットアップ手順については、インテグレーションを参照してください。

タグ

アプリケーションや環境を効果的に監視するためには、タグ付けが重要です。Azure のランディングゾーンへの移行を開始する前に、タグ付けの戦略を実行する必要があります。

難しそうに聞こえるかもしれませんが、これは多くの時間や複雑さを必要としません。タグの候補としては、インフラストラクチャーやサービスを分類するのに有効なデータであれば、何でも構いません。

リソースに以下のタグを適宜追加します。

タグ名説明
envprodstagingdev の場合。
service疑わしい場合は、ApplicationName と同じ値を使用します。
version使用されているアプリケーションのバージョンを特定します。
teamリソースを構築または管理しているチームを定義します。各チーム専用の Microsoft Teams チャンネルを作成し、各チームのサービスの状態に関する情報を受け取れるようにします。
ownerリソースに対する具体的な責任者を定義します。
workloadリソースが関連するワークロードを明確にし、レガシーとクラウドのパフォーマンスや KPI を比較しやすくします。
landing-zoneリソースが存在する場合、そのランディングゾーンを特定し、レガシーとクラウドのパフォーマンスおよび KPI を比較することを支援します。

Azure の Cloud Adoption Framework は、上記のリストと若干重複する事前定義されたタグ付け戦略を提供しています。このドキュメントを確認し、自分の組織に当てはまるタグ、特に Minimum Suggested Tags セクションに記載されているタグを実装します。

ダッシュボード

Datadog では、Azure 関連サービスをご利用のお客様向けに、すぐに使えるダッシュボードをいくつかご用意しています。利用可能なダッシュボードの一覧は、Azure インテグレーションを参照してください。

組織に適したタグ付け戦略ができたら、Datadog ではすぐに使えるダッシュボードを複製することと、標準タグのリストからダッシュボードテンプレート変数を追加することを推奨しています。

ダッシュボードテンプレート変数を使用すると、Datadog ダッシュボードは、データの幅広いサマリーやタグによる特定のサブセットを可視化することができます。例えば、ダッシュボードに workload タグのテンプレート変数を追加すると、そのダッシュボードを多くのワークロードのパフォーマンスのサマリーとして使用し、ダッシュボード全体を特定のワークロードのパフォーマンスにフィルタリングすることができます。

こうすることで、ワークロードごとに個別のダッシュボードを管理する必要がなく、1 つのダッシュボードですべてのワークロードに対応できるようになり便利です。

インシデント対応のためのコミュニケーションチャンネル

多くの組織では、サービスやワークロードの所有者階層を反映した専用のコミュニケーションチャンネルを設定することを選択しています。Datadog では、このようなコミュニケーションチャンネルの命名規則を、タグ付け戦略と組み合わせることを推奨しています。

例えば、owner タグを標準的に使用している場合、その owner タグの値で定義される名前のメールグループまたはコミュニケーションチャンネルを調査用に構成します。ダイナミックハンドルを構成することで、適切なアラートが適切な対応者に送られるようにすることができます。

移行

Datadog のアカウントが準備できれば、チームは Datadog を利用して、元の環境から新しいランディングゾーンのワークロードにスムーズに移行できるようになります。

各ワークロードについて、このプロセスでは以下のことを行います。

  1. Datadog Agent のインストールと構成により、レガシー環境と新しいワークロードの包括的かつ一貫した監視を実現します。
  2. ダッシュボードを構成することで、従来の環境と新しいワークロードの健全性を並べて観察することができます。
  3. 調査チームがパフォーマンス KPI の重要な変化に対応できるように、モニターを構成します。
  4. Synthetics テストを追加して、ユーザーエクスペリエンスの予期せぬ低下を積極的に監視します。
  5. SLO を構成し、KPI の健全性を文書化することで、関係者の視認性を高めることができます。

オリジナル環境における観測性のギャップを解決する

ワークロードやサービスの所有者として、元の環境と新しい azure ワークロードの間で包括的で一貫した観測性を得るための最良の方法は、Datadog Agent をインストールすることです。

Datadog Agent は軽量で、お客様のすべてのサーバー (オンプレミスまたはクラウドプロバイダー) で動作し、サービスの健全性を検証するために必要なデータを収集し、Datadog アカウントにすべてを集約するように設計されています。

このページでは、個々のサーバーへの Agent のインストールと、選択した構成管理ツールでのインストール (推奨) を説明します。

Datadog Agent をインストールしたら、以下のデータ収集方法を追加して、環境の健全性をより完全に可視化することができます。

  1. サービスが採用している技術に特化したデータを収集するためのインテグレーションを追加します。
  2. Application Performance Monitoring (APM) を有効にして、サービスのリクエスト数、レイテンシー、エラー率を測定します。
  3. 環境から生成されるログを取得することで、メトリクスやトレースが予期せぬ動作をした場合に、より深いコンテキストを得ることができます。ログが大量にある場合は、最も重要なログのみを保存します。
  4. サービス間の効率的な通信を確保するために、Cloud Network Monitoring (CNM) を有効にします。移行プロセスでは、元の環境から新しいクラウド環境との通信が必要になることがあるため、CNM は非常に重要です。

新しいワークロードを移行する前に、Agent をインストールし、レガシー環境上で完全なデータ収集を構成し、新しいワークロードに同じ完全なデータ収集を持つ Datadog Agent を含めるように設計します。

組織のタグ付け基準に従って、すべてのパフォーマンスデータを一貫して理解し、適切なチーム、ワークロード、ランディングゾーンに識別できるようにします。

ワークロードの健全性と移行ダッシュボード

健全性データが Datadog アカウントに流れ込むと、ホストコンテナサービスネットワークトラフィックマップなど Datadog の視覚化マップや、統合したテクノロジーに固有のすぐに使えるダッシュボード から環境を表示し理解することが可能になります。

これらのダッシュボードを複製してカスタマイズしたり、特定のユースケースに必要なデータを見るためのカスタムダッシュボードを作成することができます。

場合によっては、レガシー環境と新しいワークロードのパフォーマンスを並べて視覚化することが理にかなっていることもあります。

以下の手順に従って、ダッシュボードの例を作成します。

  1. Datadog アカウントでダッシュボードの作成を行います。
  2. 右側にある Settings アイコンをクリックします。
  3. Import dashboard JSON をクリックします。詳しくは、ダッシュボードの設定を参照してください。
  4. azure_caf_side_by_side_dashboard.json にあるダッシュボードの JSON 定義を貼り付けるかアップロードします。

ワークロードの所有者に実用的なアラートを送信

ワークロードを移行する際、重要なパフォーマンス KPI のしきい値を超えたら、適切な担当者に自動的にアラートが送られるようにします。

そのためには、Datadog でモニターを作成して、ワークロードの健全性を常に観察し、Microsoft Teams、Slack、ページングサービス、発券システムなどのコミュニケーションチャンネルに通知をトリガーします。詳細については、モニターを参照してください。

タグが専用の調査チャンネルに効果的にマッピングされている場合 (たとえば、すべてのオーナー、チーム、ワークスペースに Teams チャンネルがある場合)、モニターのテンプレート変数で適切な通信チャンネルに動的に通知するようにモニターを構成することができます。

実行可能で効果的なアラートの構成は、組織によって大きく異なるため、チームのニーズに合わせて新しいモニターを構成します。サンプルモニターの定義については、azure_caf_service_errors_15_min.json ファイルを参照してください。

プロアクティブ Synthetic モニタリング

Synthetics テストを構成することで、エンドユーザーの健全なカスタマーエクスペリエンスを積極的に検証することができます。

新しいワークロードが従来の環境と同じエンドユーザーにサービスを提供する場合、Synthetic テストは非常に重要です。移行によって予期せぬエラーや劣化が発生した場合、顧客に影響が及ぶ前に問題を特定し、対応することができます。

また、Azure DevOps の CI/CD パイプラインにこれらのテストを組み込むことで、デプロイプロセスの一部としてエンドユーザーエクスペリエンスをテストすることができます。

SLO の成果を文書化する

サービスレベル目標 (SLO) を構成し、移行期間中のワークロードの可用性目標と成果を文書化します。

SLO を構成し、ダッシュボードで関係者に公開する方法の詳細については、サービスレベル目標を参照してください。

その他の参考資料