コスト削減にも！ テレメトリーデータのコントロール方法
最後に、テレメトリーデータのコントロールについて触れておきましょう。
制約がない限りにおいて、多くのテレメトリーデータがあった方がシステムの内部状態を理解することができるようになります。ただし多くの場合、例えば、システムリソース、計装に係るコスト、オブザーバビリティバックエンドや監視ソリューションを利用する金銭的なコストなど、さまざまな制約があるはずです。その制約にあわせるようにテレメトリーデータをコントロールすることも重要なことです。
例えば、以下のようなケースでは、テレメトリーデータ量が爆発的に増加することがあります。状況に応じて、目指したいオブザーバビリティにとってそこまで重要ではないテレメトリーデータを減らしていくという取り組みを検討することになります。
例1: メトリクスに対して過剰なディメンションが付与される
例えば、数百万人いるユーザーIDごとにレスポンスタイムを計測していたとします。レスポンスタイムと言う1つのメトリクスに対して数百万人のユーザーID分のディメンションが発生することになります。こういった状態のことを「高カーディナリティ」と言うことがあります。ディメンションが豊富であるほどシステムの状態を詳細に把握することはできるようになりますが、ディメンションが膨大になりすぎると、例えばメトリクスのデータ検索パフォーマンスが下がってしまったり、ノイズとなるデータが増えてしまうことがあります。オブザーバビリティバックエンドサービス側のデータストレージを圧迫する可能性もあり、課金コストに影響を及ぼすこともあります。こういったケースでは、参照頻度が低いディメンションを取得しないように制御したり、コストの低いストレージに保管するように設定することが必要になる場合があります。
例2: 多数・大量のログを集めようとする
上でも触れた通り、ログはその性質上、保管・転送・加工に係るコストが非常に高くなる傾向にあります。自然と、ログを保存するオブザーバビリティバックエンドではデータストレージや検索・分析のためのコンピュートリソースを消費します。これが課金にそのまま影響を及ぼすこともあります。メトリクスと同様、保管コストの低いストレージを活用するのも一つの方法ですが、例えば「ログの内容自体は必要性が薄いが、障害が発生すると大量にログを出力することがある」ようなログについては、一定期間ごとに出力されているログ行をメトリクスとして取得しておけば、ログそのものは取得する必要がなくなるかもしれません。あるいは、トレースに含まれるタグ情報で代替できないか検討するのも一案です。
例3: 莫大なアクセスが発生するアプリケーションでトレースを取得する
大量のアクセスが定常的に（あるいは季節やイベントに応じて定期的に）発生するようなアプリケーションでは、すべてのトレース情報を取得する必要はないかもしれません。全量のトランザクションを確認せずとも概況としてのシステムの健全性は理解できるはずで、エラーが含まれる場合も大体は同じエラーが発生しているはずと理解して調査をすれば済むかもしれないのです。つまり、全量のトレースから一部をサンプリングして取得することで、システムの状態をある程度の正確性をもって理解しつつ、必要な問題調査も行うことができ、かつ、トレースのボリューム量を抑えるということができるはずです。
一方で、トレースのサンプリングは非常に難しい問題でもあります。よく利用されるサンプリング戦略としては、リクエストがシステムに入る際にサンプリングするか否かを決定するヘッドベースサンプリング（Head-Based Sampling）、リクエスト完了時にサンプリング可否を判断するテイルベースサンプリング（Tail-Based Sampling）、リクエストごとに一定の確率でサンプリングする確率的サンプリング（Probablistic Sampling）などがあります。ヘッドベースサンプリングや確率的サンプリングは統計的に信頼できるデータが取得できる一方で、調査したい必要なデータが取得されないリスクがあります。他方、テイルベースサンプリングは重要なリクエストを優先的に取得できるように構成することは可能ですが、リクエスト全体の完了を待つ間すべてのトレースデータを保持する必要があることからシステムリソースへの影響が起こり得る点、適切なサンプリング条件を構成・管理する必要があるという点に難しさがあります。
なお、OpenTelemetry公式サイトでもサンプリングに関して記載されています。それぞれのサンプリング手法の特徴が紹介されていますので、参考にしてください。
いずれにせよ、まずはテレメトリーデータをさまざまに取得してオブザーバビリティを高める取り組みを進めていき、その中で、例えば、オブザーバビリティに取り組むチームや組織が拡大していき、テレメトリーデータの取得対象システムが増加していく中で、どうしても必要な場合には、こういったデータ管理を検討していくのがよいでしょう。
まとめ
いかがだったでしょうか。テレメトリーデータとはどういったもので、テレメトリーデータごとの長所を生かした活用方法、そのデータコントロールなどについて理解できましたでしょうか。
文章だけでは伝わりにくい部分もあるはずです。データの取得はいずれも難しくないので、まずはデータ取得を始め、データ活用をやってみると、より具体的にイメージを持ってもらうことができるはずです。
次回
次回は、OpenTelemetry Collectorというエージェントを利用して、実際にテレメトリーデータを扱う仕組みや方法に迫ってみましょう。
