[レポート] Indexless observability: オブザーバビリティコストの削減について #MAM206 #AWSreInvent

はじめに

こんにちは、リテールアプリ共創部の塚本です。

AWS re:Invent 2024で行われた『Indexless observability: How to decrease your observability costs』を視聴しましたので、そのレポートをお届けします。

セッション情報

https://www.youtube.com/watch?v=qbXOBPVfYPw&ab_channel=AWSEvents

• セッションID: MAM206
• タイトル: Indexless observability: How to decrease your observability costs
• スピーカー:
  • Christopher Cooney (Head of Developer Experience, Coralogix Ltd)

セッション概要

[セッションの公式説明]

While the cost of observability is often discussed, the main driver of cost—indexing—is rarely explored. In this session, explore the role of indexing in observability and learn how far you can go by being a little more savvy about how you process your data. This presentation is brought to you by Coralogix, an AWS Partner.

[機械翻訳]
オブザーバビリティのコストについてはよく議論されますが、コストの主要な要因であるインデックス作成についてはあまり探求されていません。このセッションでは、オブザーバビリティにおけるインデックス作成の役割を探り、データ処理方法をより賢く行うことでどこまで改善できるかを学びます。このプレゼンテーションは、AWSパートナーであるCoralogixが提供します。

学んだこと

• 昨今のオブザーバビリティの問題点
• Indexlessを実現するためのサービス
• Coralogixの紹介（登壇者の会社製品）

オブザーバビリティにおけるインデックスの現状と問題点

データベースを運用する際には、データのユースケースを考えてインデックスを付ける。
ログの管理では、オブザーバビリティのために全てのフィールドにインデックスを付ける。これはElasticSearchでログを分析するときのことを考えるとわかりやすい。

では、なぜ全てにインデックスが付けられるようになったのか？

• マイクロサービス構成が増え、複雑なデータを分析する必要が出てきたから。
• クラウドにより異なるタイプのインスタンスを使えるようになったが、合わない用途で使われることにより壊れ、複雑なデータが増える。
• コンプライアンスを守るため、アクセス可能な状態のログデータを数年保持する必要が出てきたから。

現状インデックスで何が問題になっているか？
インデックス対象のフィールドが多すぎることで、問題が起こっている。
型が変わることでマッピングを修正する運用コストが必要になる。
金額の意味でコストがかかる。

インデックスは多いが、現状99%は検索に利用されていないことがわかっている。

また、データは30%が全く使用されない。

オブザーバビリティの原則

原則1: ログとトレースはデータベースにあるものと考える。
データベースの観点でデータをどのようにクエリし、どのようにアクセスするのか、と考える。
どのように使用されるか知らなければ、最適化に苦労することになる。

原則2: 全てのデータを数秒でクエリ可能とする。
インデックスされたデータ、インデックスされていないデータの両方である。
インデックスを張ることは高速にアクセスしたいだけであり、可用性を高めるために行うわけではない。

原則3: 高速ストレージで解決することはできない。
クエリの実行が遅いからといって、高速なストレージに変換すれば良いわけではない。一時的に解決する可能性はあるが、あくまで一時的である。
遅いストレージでも、データ管理や形式を変えることで、信用できる状態にする必要がある。

原則4: ログ収集は、始まりに過ぎない。
CloudFrontのようなCDNを使う際に、ログデータを見ることは多くない。
それよりも、レイテンシの値をメトリクスで見るようなケースが多い。
メトリクスはメモリ使用率やCPU使用量が低いため、非常に効率的である。
そのため、ログをメトリクスのような形式に加工して利用したほうが良い場合がある。

原則5:自分のデータを自分で持つ。
ストレージのコストは必ず問題になるが、データは必要である。
データはLLMの誕生により、さらに価値を増している。

原則を実現するためのアーキテクチャ

OpenTelemetry

OpenTelemetryを使うのは良いアイデアである。
ベンダー特有のテレメトリコレクターを利用する必要がないため、コードにベンダー特有の実装が入り込まなくなる。
これにより、DataDogからSplunkに移行するようなとき、アプリケーションコードを触らずに移行ができる。

Kafka

Kafkaは非常に高スループットの書き込みに優れている。
常に大量のログを書き込むため、用途に合っている。
Kafkaインスタンスのバックエンドで変換ロジックを実装できるため、CDNログからメトリクスへの変換のようなロジックもここで持てる。
さらに、Kafkaは一般的によく知られているため、専門家を見つけることが他のサービスよりは簡単である。

Amazon S3

S3を使うことで、効果的にデータアクセスが可能である。
これは、多くのツールがS3からのデータの読み取り・書き込みをサポートしているため。

多くのダウンストリームとアップストリームの統合が明確なツールを使用することが、重要である。

[補足]

• ダウンストリーム：データを読み取る側のシステム
  • 分析ツール
  • 可視化ツール
  • レポーティングシステム
• アップストリーム：データを書き込む側のシステム
  • ログ収集システム
  • モニタリングツール
  • アプリケーション

Athena

Athenaは少し議論の余地がある選択肢。
いくつかのフィールドを追跡する緩やかなデータベースのようなもの。
アドホックにデータをクエリすることもできるが、これにはいくつかの欠点もある。

[補足]

アドホック（Ad-hoc）クエリとは： 事前に定義されていない、その場で必要に応じて作成されるクエリ

Thanos

Thanosが良いのは、Thanosゲートウェイにプッシュでき、メトリクスをS3に保存できるから。
S3のメトリクスは非常に高速にクエリ可能である。

[補足]
Thanosは、Prometheusのメトリクスデータを長期保存・クエリするためのオープンソースプロジェクト。
Thanosゲートウェイ（Thanos Gateway）は、Thanosの一部で、メトリクスデータを受け取り、保存するためのエンドポイントを提供するコンポーネント。

Lambda, EC2

KafkaコンシューマーをLambda関数で持つことも、インスタンスで持つこともできる。
平均してLambdaのCPU秒あたりのコストは、EC2インスタンスの約4倍。
そのため、変換ロジックに一定のデータが流れ込む場合、Lambda以外の選択肢も考えたほうが良いかもしれない。
Lambdaは一時的なワークロードには適しているが、一貫したワークロードにはEC2のような選択肢を考える。

[補足]

Kafkaコンシューマーは、Kafkaからデータを読み取って処理するアプリケーションやプログラムのこと

OpenSearch

本当に必要な箇所に、インデックスを追加することができる。
例えば決済システムのエラーログのためにOpenSearchを置くことができる。

このようなOpenSearchは管理が非常に簡単である。なぜなら、少量のデータしか含まれていないから。

全てをインデックス化する必要はなくなりつつある。
OpenTelemetryで取得したデータをOpenSearchに送信したり、Kafkaを経由させ一部をOpenSearchにルーティングすることも可能である。

様々なパターンがあるが、原則は同じ。
インデックスは例外的なものであり、必要な箇所にインデックスを利用する。

前述のアーキテクチャの問題点

Athenaの問題点

Athenaでは非常に簡単に、予期せぬコストが発生する。
これは、エンジニアのデータ探索を怖がらせてしまう。

一定のクエリを何度も実行している場合、これはあまり問題にならない。（コストが予測できるから）

Kafkaの問題点

大規模なKafkaは怖い。
スケールの問題が発生する可能性がある。

代替案として、Amazon Kinesisのようなものを利用することができる。
Kinesisは統合ポイントは少ないが、サーバー管理の負担を取り除いてくれる。

データ変換

オブザーバビリティにおいて、レイテンシーは敵である。
リアルタイムですぐに知りたい情報があるため、変換ロジックがボトルネックになる可能性がある。
変換にはLambdaがおすすめである。
Lambdaを利用することで、コスト最適化とサーバー自体の同時実行性を管理する必要がないという利点が得られる。

一方で、Lambdaには1000の同時実行数制限というソフトリミットがあるので、注意する必要がある。

Coralogix製品の紹介

CoralogixはデフォルトでOpenTelemetryを使用し、ストレージにはユーザーのS3アカウントを使用する。
内部的にはKafkaを使用している。Kafkaを直接触る必要がないので、ユーザー側でKafkaの専門家を雇う必要はない。

Coralogixは小さな会社ではなく、2017年に立ち上げ、数千の顧客をもち、グローバルに展開している。
400人の従業員がおり、2000以上のグローバルな顧客がいる。

APM, ROM, SIM, ブラウザ, バックエンド, データベース, ネットワークインフラストラクチャ, あらゆるものをサポートしている。
2週間後に新たな発表がある。

価格は一貫性があり、理解がしやすい。
ギガバイト単位でのみ課金であり、サポートも課金はなしで利用できる。

Coralogixではインデックスするものとしないものを選択する。
それにより、コスト削減が見込める。
DataDogからCoralogixに移行する場合、ほとんどの顧客は50-70%のコスト削減が見込める。
Splunkからの移行の場合でも、大きく削減が見込める。
これらを含むほぼすべてのSaaSベンダーがインデックスファーストであり、運用コストが高くなる。

モニタリングを100%にし、インデックスは削減する。
インデックス化なしで、アラームのトリガー、ダッシュボードの更新、メトリクスの生成ができ、最後にS3にプッシュする。
ブラウザモニタリングでは、SDKをフロントエンドアプリケーションに組み込むことができる。

『Show Archive』のトリガーをONにすると、S3から直接クエリができる。これがOFFであれば1秒未満、ONであれば3秒でページが読み込まれ、S3から直接全てのデータをクエリする。

APMについて、完全なAPMスタックをカバーしている。APIの使いやすさを見るためのADEXスコアも追跡し、レイテンシ、エラー率も追跡している。

深い分析をするための、クエリ言語がある。
これはData Primeと呼ばれている。
Splunkのクエリ言語と似ているが、違いは、クエリするためにデータをインデックスする必要がないところ。

インデックスファーストは古くなった。
原則・アイデアは、より責任を持つこと。テレメトリデータを、データベース管理者のように扱うこと。
これにより、コストを削減させ、プラットフォームの使いやすさも向上させ、より効率的で効果的な運用ができる。

[補足]

Coralogix: https://coralogix.com/

所感

オブザーバビリティの歴史・現状と、インデックスレスという考え方を知ることができてよかったです。
私は普段オブザーバビリティに深く関わっているわけではないのですが、共感できる話がいくつかありました。
Athenaで課金が気になってクエリするのが怖い、という話は実際に開発している中でも頻繁にあります。
インデックスを全てにつけることで、データ型が変わった時に付け直しが大変、という話も経験がありました。

オブザーバビリティ関連の製品と、現状の問題・今後の流行について知ることができる良いセッションでした！