このブログは元々、tfir.ioに投稿されたものです。
Kubernetesは、Cloud Native Computing Foundationプロジェクトの中心にある、人気のコンテナーオーケストレーションシステムです。コンテナー、コンテナー化されたアプリケーション、「ポッド」（1つまたは複数のコンテナーのグループ）のデプロイ、ライフサイクル、オペレーションを自動化します。このプラットフォーム自体が、その各ワークロードとともに、イベントデータを生成することがあります。それらのプロセスに関連する各種データがあります。ログは、「ここまで来た」と示すシンプルなデバッグメッセージから、トランザクション情報を提供する詳細なWebサーバーアクセスログまで、広範なものがあります。メトリック、または時系列データは、定期的な間隔で計測される数値です。たとえば、1秒あたりの瞬間的な操作の回数、キャッシュヒット率、サイトにアクセスした顧客数や、基本的なこととして過去5秒間でコンテナーが使用したCPUまたはメモリー量などです。
オブザーバビリティは、これらのログとメトリックを取り出し、通常、相関するデータストアに検索可能な形で格納して、しばしばアプリケーショントレースデータとそれらをそれらを組み合わせます。このトレースデータ、または詳細なアプリケーションパフォーマンス監視（APM）情報は、アプリケーションまたはサービスで時間がかかっている場所、それらがやり取りしている方法と対象、および遭遇するあらゆるエラーをキャプチャします。ログとメトリックはアプリケーションのブラックボックスを見るようなものである一方、APM データはアプリケーションの内部で何が起きているかを示します。
ログ、メトリック、アプリケーショントレースデータを組み合わせることで、エラーまたはインシデントの平均検出時間および平均解決時間の短縮化に役立ちます。ただし、アプリケーションデプロイモデル（およびKubernetesデプロイ）は進化するため、動的な環境のどこで実際に発生しているのかを理解することが非常に重要となります。そこで活用できるのがメタデータです。
メタデータとは一体何か？
Websterの定義によると、メタデータとは「他のデータに関する情報を提供するデータ」です。 とても簡単です。メタデータは、多くの一般的な場所で見つかります。このブログ記事をホストしているページにもあります。それらはSEOタグ、さまざまなブラウザーがページを適切にフォーマットできるようにするためのヒント、ページを説明するキーワードなどです。同様に、モバイルデバイスの1つの写真には多くのメタデータが含まれています。下記はその一部です。
ExifTool Version Number :11.11 File Name :60398459048__A20828DD-FAA4-4133-BA1F-059DEC9E7332.jpeg Directory : . File Size :2.8 MB File Modification Date/Time :2020:02:21 08:30:01-05:00 File Access Date/Time :2020:02:21 08:30:23-05:00 File Inode Change Date/Time :2020:02:21 08:30:22-05:00 MIME Type : image/jpeg JFIF Version :1.01 Acceleration Vector : -0.03239090369 -0.9104139204 -0.3862404525 Exif Byte Order :Big-endian (Motorola, MM) Make :Apple Camera Model Name : iPhone XS Orientation :Rotate 90 CW X Resolution :72 Y Resolution :72 Exif Image Width :4032 Exif Image Height :3024
「iPhoneの写真のMIMEタイプを知ることが、オブザーバビリティイニシアティブにどのように役立つのか？」と疑問に思われることでしょう。役に立ちません。画像のメタデータはそのためにあるわけではありません。これは、メタデータが何であるかということを示す例ためのです。iPhoneのメタデータにより、サイズ、向き、写真を撮ったときの手振れ具合（これは実際に私にとっての課題ですが）で絞り込むことが可能になります。では、オブザーバビリティデータの相関付けおよびナビゲーションに役立つものを見てみましょう。それらは環境のログ、メトリック、アプリケーショントレースデータです。
ソフトウェアおよびハードウェアのデプロイのトレンド
単一のデータセンター内に、単一目的のベアメタルサーバーでモノリシックなアプリケーションを実行する時代は終わりました。確かに、専用のワークロードの実行にそのような形態が今でも使用されているのを見ることがありますが、それには何の問題もありません。多くの大規模なアプリケーションや製品は、できるだけ多くのコンピューティングを必要とします。しかし全体として、ソフトウェアとハードウェアの両方のデプロイモデルに関する業界トレンドは、マイクロサービスおよびコンテナーへと移行し始めています。
この「シフトライト」のトレンドは、ビッグバンというわけではありません。多くの企業では、複数のソフトウェアデプロイモデルに並行して取り組み、また複数のハードウェアパターンにも対応しています。仮想マシンまたはクラウドインスタンスがクライアント/サーバーまたはSOAアプリケーションを実行するとともに、コンテナーが、KubernetesまたはDockerでオーケストレーションされたマイクロサービスのイメージを実行します。多くの場合、あるデプロイメントモデル内のアプリケーションやサービスは、他のモデルのサービスを使用しています。最新のマイクロサービスでも、ベアメタルにホストされたデータベースを未だに使用している場合があるかもしれません。
このような異種混合システムの性質により、メタデータはさらにその重要性を増します。データセンターに入って行ってボックスを指し、「ここに私のアプリケーションがある」と示すようなことは、コンテナー、ポッド、および動的にスケジュールされたマイクロサービスへとシフトするにつれてさらに難しくなっています。 そこにあるかもしれませんが、あなたの後ろにある他の4つのサーバーにもあるかもしれません。
そこで役立つのがロケーションメタデータです。これは緯度と経度のことを言っているのではなく（便利だとは思いますが）、アドレススキームのことを言っています。つまり、少なくともそれぞれのデータ（ログ、メトリック、またはアプリケーショントレースデータ）がどこから来ているかを論理的に確認できるものです。
インフラストラクチャーの性質
ロケーション、ロケーション、ロケーション
何が必要かはセットアップによって異なりますが、将来に向けて計画しておくべきです。キャプチャできる量は、ジョブがどこで実行されているかによります。ベアメタル上のモノリシックなアプリケーションの場合は、Kubernetesポッドの詳細をキャプチャできませんが、問題はありません。私たちはブレッドクラムを提供したいと考えています。どこで実行されているかが分かるからです。その理由について少し説明しましょう。
ロケーション情報があることで、メタデータの階層をアプリケーションレベルまで辿っていくことができます。つまり、物理的にジョブが実行されている場所です。
データセンター
データセンターのメタデータは、各データセンターの一意の識別子（都市名など）を含む必要があります。この情報は、クラウドプロバイダーについては少しあいまいになる可能性がありますが、同様の情報はあります。このシナリオでは、クラウドプロバイダーと、実行している地域を活用できます。たとえば、GCP、europe-west1、アベイラビリティゾーンBなどです。
データセンター内に専用ティアがある場合（特定のホストが本番またはテストプロジェクトに予約済み、またはプロジェクト全体に分割されている、など）は、それもメタデータに追加する必要があります。 これは、データセンター内の壁で囲まれた部分、またはデータセンター内のデータセンターのようなものです。
ホスト情報
ベアメタル、仮想、またはクラウドインスタンス上など、どこで実行していても、利用できるホスト情報が通常はいくつかあります。各ホストには、ホスト名、IPアドレス、ハードウェアモデルまたはインスタンスタイプ、構成されたRAMおよびストレージ、さらにはオペレーティングシステム情報の属性があります。また、そのホストが存在する場所のさらに詳細な情報（データセンターのフロア番号、ラック、列、シェルフなど）を含めることもできます。ラック全体が低品質の電源や配線の影響を受けたのは初めてではないでしょう。
アプリケーションの詳細情報
ここまでで、それぞれがどこで実行されているかについて特定できる十分な情報を得ることができますが、まだホストレベルまでです。各ホストは、多くのさまざまなサービスまたはアプリケーションを実行している可能性があります。アプリケーションとサービスについて知るためには、対応するレベルのメタデータを追加する必要があります。これについては、それぞれのケースについて実行内容が異なってくるため、ここでは概要に留めるとともに、Kubernetesによってオーケストレーションされたマイクロサービスについて、さらに複雑なシナリオを説明します。それをベアメタルアプリケーションおよび仮想化環境に適用することは非常に簡単です。
KubernetesおよびDockerのコンテナーでは、自動的に何らかのレベルのメタデータが利用できるため、これらは含めておくべきです。最低でもコンテナー名および/またはポッド名、コンテナーのベースとして使用するイメージおよびバージョン、および開始時間は含めておくべきです。また、ネットワーク名とIP情報、およびネットワーク、メモリー、またはストレージのクォータも含めておくことが理想的です。ホスト情報と同じ情報がもう1つあることに気付きましたか？コンテナーおよび仮想マシンは基本的に、別のホストで実行されるホストであるため、同じ情報を抽出することは理に適っています。
つまり、仮想化された環境で作業する場合は同様の情報を引き出すことができます。仮想ホストは、ホストとしての名前、IPアドレス、メモリーおよびストレージの上限など、同じ概要情報を持つことになります。
ここで小さなジレンマが生じます。重複したフィールド名があることです。覚えておくべきなのは、階層を維持することが重要であるということです。ホストのメタデータは、その階層の中でコンテナーまたは仮想マシンよりも上位に位置します。
├── NYC DC 1
│ ├── Host 1
│ │ ├── vm 1
│ │ ├── vm 2
│ │ └── vm 3
│ └── Host 2
│ ├── vm 1
│ └── vm 2
└── NYC DC 2
└── Host 1
├── vm 1
├── vm 2
├── vm 3
└── vm 4
ここで明らかなのは、名前が競合しないように、予測可能な異なる名前空間に値を設定する必要があるということです。そのための優れた方法は、キー/値のペアとして渡すことです。たとえば、NYC DC 1のHost 1のvm 2には以下を含めます。
dc.name:"NYC DC 1" dc.floor:2 <other dc fields> host.name: "Host 1" host.IP: … host.available_memory_mb:16384 vm.name: "vm 1" vm.IP: …
階層については、コンテナーは少し異なります。1つのKubernetesクラスターが複数のホストにまたがる可能性があるからです。この場合は、任意のポッドまたはコンテナーのロケーション情報だけでなく、上述したとおり、対応するオーケストレーションメタデータにも注目する必要があります。ではここからは、アプリケーションに対するオブザーバビリティを得るためにメタデータが役立つことについて見ていきます。
アプリケーションのオブザーバビリティ
ここまでで、システムで稼働しているものに対して完全に対応する方法について分かりました。そこで、実際のデータの収集について見ていきましょう（メタデータとは、他のデータを説明するものであるということを思い出してください）。「オブザーバビリティの3つの柱」はログ、メトリック、アプリケーショントレースデータ（APMデータとも呼ばれます）であり、アップタイムデータが4つめの「柱」として示されることもあります。 ログとメトリックを収集する際には、下図で示されているように、エコシステムの各レイヤーで収集します。それぞれの抽象化について、どのようなタイプのオブザーバビリティデータに関する情報を収集すべきかが示されています。
たとえば、各ホスト、またはデータセンターのネットワーク要素から、ログ、メトリック、可用性データを収集し、アプリケーションとサービスについてはAPMを加えます。
各ティアの対応するメタデータで上記のすべてを強化し、アプリケーション、インフラストラクチャー、エコシステム全体に対する可視性を高めます。これを達成するには多くの方法があります。各イベントまたはトレースで送信することで、迅速な検索およびフィルタリングが可能になります。または、エコシステムの静的な部分からメタデータを保存して、後から相互参照を行うこともできます。後者の方法ではスペースを節約できますが、特に動的なエコシステムでは、古くなる、または最新ではないというリスクが伴います。
各ピースを集約する
メタデータで強化されたオブザーバビリティデータがあれば、自分たちが選択したファセットに基づいて、特定のAPMデータまたはログを見ることに限定されることなく、細かく確認できます。たとえば、現在のCPU使用率を各サービスのホストごとに見ることができます。
または、経時的に同じパラメーターを確認します。
これにより、調査したい詳細情報を拾い出したり、他の方法では回答を得られない以下のような質問の答えを得たりできます。
- EMEAのデータセンターと比較して、米国のデータセンターが過剰に使用されているか？
- エコシステム内で、他のラックと比較していずれかのラックに多くのエラーが発生しているか？
- 開発用インフラストラクチャーの一部を本番用に再目的化できないか？
- Eコマースアプリを実行しているコンテナーおよびポッドはどの物理ホストにあるか？
- そして最後に、私のiPhoneの写真はなぜいつも手振れしているのか？
まとめ
メタデータは分析に新たなディメンションを追加します。データの集約や細かい分析を行うための新たな方法をもたらし、ビジネスおよびオペレーションに関する質問への回答を得るのに役立ちます。オブザーバビリティイニシアティブに使用するソリューションが、組織の拡大に伴って拡張できるようになっていることを確認しましょう。また、予測どおりにメタデータが配置されるように、Elastic Common Schemaなど、検索可能でナビゲーション可能なメタデータのことを考慮に入れましょう。