運用上の認識
信頼性の監視作業を開始するには、前段階として行う必要がある作業があります。 最初に、適切なレベルの運用上の認識があることを確認する必要があります。
わかりやすく言うと、運用環境のシステムの信頼性向上に取り組むには、最初に、それらのシステムと、それらが運用環境でどのように機能しているかをきちんと理解する必要があるということです。
現在の構成に関する情報を収集する
奇妙に聞こえるかもしれませんが、多くの環境で最初に答える必要があるのは、"本番環境で実行されているのは正確には何か" という質問です。最近の本番環境と、それらの環境に展開するパスは十分に複雑であり、通常は最初にちょっとした検出を行う必要があります。 たとえば、特定のアプリケーションについては、"その構成要素は何か?"、 "他の部分とやり取りするのはどの部分か?"、 "このアプリケーションの明白な (およびそれほど明白ではない) 依存関係は何か?" などがあります。
通常と過去のパフォーマンスに関する情報を収集する
この情報を取得したら、システムのパフォーマンスと "通常"の動作に関するベースラインを把握できます。 この情報が必要になる可能性がある理由は数多くありますが、特に重要なのは、アプリケーションに関する問題をトリアージする必要がある場合に役立つということです。 データベース サーバーが 80% の CPU を使用して稼働していることが良いことなのか悪いことなのかを、停電の最中に判断するのは適切ではありません。
そのベースラインを把握する一環として、過去のパフォーマンスを調べる必要があります。 "過去のパフォーマンスは、将来の結果を保証しない" というのは真実ですが、期待値を調整するために役立つ場合もあります。 同様に、過去に発生したサービスの停止または中断に関する情報を入手できれば、少なくとも、潜在的な障害モードを信頼性に関する考え方に取り入れる必要がある意味を理解することができるでしょう。
コンテキストに関する情報を収集する
最終的に、これは、システムに関するいくつかのコンテキストの知識を得るのに役立ちます。 コンテキストはさまざまなバケットに分けることができ、その多くは社会技術的です。 たとえば、社会的な側面では、サービスまたはアプリケーションに関係がある利害関係者について適切な情報を収集する必要があります。
"特定のアプリまたはサービスを誰が所有しているか、または関心を持っているかは明らかである" と思うかもしれませんが、企業の状況やその他の複雑な組織では、これは想像以上に難しい場合があります。
悲しい真実は、利害関係者が誰であるかを明確に理解していなければ、システムの信頼性を大きく向上させることはできないということです。その理由は、後で SLI と SLO について説明するときに明らかになります。
コンテキストに関する質問の技術的な側面では、"このアプリケーションはどのようにして本番環境に導入されたのか" などの技術的な質問に注意を払うことが非常に役立ちます。"エピック" デプロイ中に手動でデプロイされましたか、それとも一連の優れた単体テストで自動 CI/CD パイプラインを介してデプロイされましたか?
この情報は、信頼性を向上させる更新を行う場合があればそのときに、どれだけ簡単に反復できるかなど、多くの影響を与える可能性があります。 また、実際に違いを生み出す、実行することのできる作業の有用な指標になる可能性もあります。
運用上の認識のための Azure ツール
多くの場合、運用上の認識を得ることは簡単ではありませんが、このプロセスに役立つ、Azure によって提供されているツールをいくつか見ていきます。 ここでは非常に簡単に簡単に説明します。これらのいずれかのツールについて詳しく知りたい場合は、このモジュールの最後に、他の Microsoft Learn モジュールおよびドキュメントの参照先を示しています。
Application Insights
最初に紹介するツールは、"実行されているのは実際には何か" という質問の助けとなります。 運用担当者にとって、既に運用環境で実行されているアプリケーションでの作業を求められることは珍しくありません。 設計段階から、ソフトウェアのライフサイクル全体に関わることが理想ですが、常に (または多くの場合) そうであるとは限りません。 このような状況が発生した場合、特により複雑な多層アプリケーションやマイクロサービス ベースのアプリケーションでは、すべての可動部分を把握するだけでも労力を要することがよくあります。
その手間を省き、しかも運用環境でのアプリケーションの動作に関する情報を提供できるツールの 1 つが、Application Insights です。 開発者は、最小限の労力で、アプリケーションをインストルメント化して、Azure で実行されているコレクターにテレメトリ情報を自動的に送信できます。 Application Insights では、この情報を利用して、アプリケーションのコンポーネントと、これらのコンポーネント間の通信を示すビジュアル マップを作成できます。
次に例を示します。
前の図では、アプリケーションのコンポーネントだけでなく、それらのコンポーネント間の通信も確認できます。 コンポーネント間の接続の 1 つを拡大すると、コンポーネント間で行われた呼び出しの回数と、それらの呼び出しの平均待機時間が表示されます。 また、呼び出しが成功した回数と失敗した回数を表示することもできます。 これらのマップ要素のいずれかをクリックすると、Application Insights によって、情報を掘り下げて、これらの呼び出しのパフォーマンスと成功/失敗のメトリックに関する詳細な統計を表示することができます。 これは、アプリケーションのコンポーネントの全体像と、それらがベースラインとしてどのように機能するかを十分に理解できるすばらしい方法です。 停止が発生する "前" に、Application Insights が提供するアプリケーション マップとすべてを確認することを忘れないでください。
Azure Resource Graph
Application Insights は、アプリケーションに関する一部の運用上の認識を得るための優れた方法ですが、さらに理解を深め、Azure で持っている、サブスクリプション内のすべてのリソースを確認したい場合はどうなるでしょうか? 以前は、レポートをダウンロードするか、PowerShell を作成して、この情報を収集していましたが、今ははるかに簡単な方法があります。
Azure Resource Graph エクスプローラーは、Azure portal から直接必要なデータを得るための対話型のクエリ環境を提供します。 そこでは、現在使用中のリソースに基づいて、リアルタイムの回答を返す任意のクエリを実行できます。 たとえば、現在実行中のすべての VM を確認し、
サブスクリプションで使用されている VM の完全な詳細リストを取得する場合は、次のクエリを実行できます。
この環境で使用されているクエリ言語は Kusto クエリ言語 (KQL) です。 それについては、このモジュールの後半で Azure Monitor Log Analytics について取り上げるときに詳しく説明します。
ダッシュボード
運用上の認識のための最も一般的な運用ツールは、従来からあるダッシュボードです。 多くの場合、運用を行う人のことを考えるとき、大きなモニターの前に座り、グラフやチャート、カウンターでいっぱいのダッシュボードを凝視しているところを想像します。 このモジュールでは、ダッシュボードの作成、編集、使用の方法については説明しません。 それは主に、ポータル内の他の場所からコンテンツをピン留めし、必要に応じて移動することで行われます。
代わりに、あまり使用されていない、実際に役に立つ可能性がある 2 つのダッシュボード機能を見てみましょう。 これらの機能は、すべてのダッシュボードの上部にあります。
2 つの強調表示された矢印を使用して、ダッシュボードの JSON 表現をアップロードおよびエクスポートできます。
まず、エクスポート機能から始めましょう。 [エクスポート]、[ダウンロード] の順に選択すると、現在のダッシュボードを表す JSON ファイルがコンピューターにダウンロードされます。 必要に応じて、ポータルにログインして製品メニューの [ダッシュボード] を選択し、[エクスポート]>[ダウンロード] を選択して、試してみてください。
このファイルを使用してできる便利なことが少なくとも 2 つあります。
このファイルをソース管理システムにチェックインすることができます。 これにより、さまざまなバージョンのダッシュボードを管理することができ、また、他のユーザーがあなたのダッシュボードを使いたい場合、それらのダッシュボードにアクセスできるようになります。 これを "コードとしてのダッシュボード" と呼ぶ人もいます。
このファイルを新しいダッシュボードの基礎として使用できます。 ここに 1 つの具体的な例があります (これについては、このラーニング パスの後半で再度取り上げます)。たとえば、先週発生した停電中の 1 時間に特定のダッシュボードがどのような状況であったかを同僚に示す必要があるとします。 ダッシュボードを公開し、正確な時間と期間を選択するよう同僚に依頼することもできるでしょう。 しかし、はるかに簡単でエラーが発生しにくい方法として、必要に合わせて設定したダッシュボードをダウンロードし、その JSON ファイルを共有できます。 同じダッシュボードから 2 つ目の期間 (たとえば現在より後の 1 時間) を強調表示する場合、JSON を編集することは簡単です。
これがエクスポート機能です。 次に、アップロード機能の用途について重点的に説明します。 前のセクションでバージョン管理または編集されたファイルを読み込むことができるだけでなく、アップロード機能を使用して、ダッシュボードを構築するときに、他のユーザーの綿密な作業を活用することができます。
このユニットに含まれるアイデアのうちの 2 つをうまく結合した、このセクションの最後の例を見てみましょう。 次の JSON ファイル:
をコンピューターにダウンロードしてから、ダッシュボードにアップロードすると、次のように表示されます。
これで、サブスクリプションで使用されているリソースのインベントリを非常にわかりやすく示すライブ ダッシュボードが完成しました。 このダッシュボードのデータは、前に見た Azure Resource Graph エクスプローラーと同じソースから取得されています。 実際にタイルの 1 つを選択すると、その四角に表示された情報を得るために実行されている正確なクエリを表示 (および必要に応じて編集) できます。 すばらしいですね。
それを運用上の認識に役立てながら、信頼性向上の支援になるように何を監視すればよいかを確認していきましょう。