メインコンテンツまでスキップ
バージョン: 4.x

概要

オブザーバビリティとは？​

オブザーバビリティとは、システムの外部出力データを通じてシステムの内部状態を推測する能力を指します。observabilityプラットフォームは、3つのコアデータ（Logs、Traces、Metrics）を収集、保存、可視化します。これにより、チームが分散システムの運用状況を包括的に理解し、リソースの最適化、障害予測、根本原因分析をサポートし、システムの信頼性を向上させ、ユーザーエクスペリエンスを向上させます。

なぜオブザーバビリティがますます重要になっているのか​

オブザーバビリティプラットフォームには、システムの安定性向上、運用効率の最適化、ビジネスイノベーションの実現にとって重要な複数の重要なユースケースがあります。

  1. 障害診断と根本原因分析：リアルタイム監視、異常検知、トレース機能により、障害の迅速な特定と分析が可能になります。たとえば、金融業界では、observabilityをトランザクショントレースやAI技術と組み合わせることで、復旧時間を短縮し、ビジネス継続性を確保できます。また、障害シナリオをシミュレートし、システムの耐障害性を検証するchaos engineeringもサポートします。

  2. パフォーマンス最適化とリソース計画：システムのリソース使用率と応答時間を分析することで、パフォーマンスのボトルネックを特定し、設定を動的に調整できます（例：ロードバランシング、auto-scaling）。過去のデータを使用してリソースニーズを予測し、クラウドリソースの配分を最適化し、コストを削減できます。

  3. ビジネス意思決定支援：ITパフォーマンスデータをビジネス成果（ユーザーリテンション率やトランザクション量など）と関連付けることで、ビジネス戦略の策定を支援します。たとえば、ユーザーエクスペリエンス指標を分析することで、製品機能の改善を指導できます。

  4. セキュリティとコンプライアンス監視：異常な行動（例：ゼロデイ攻撃）を検出し、自動応答をトリガーしてシステムのセキュリティを強化します。同時に、ログ監査により規制要件への準拠を確保します。

  5. DevOpsコラボレーション：canaryリリース中、トラフィックタギングにより新バージョンの動作を追跡できます。コールチェーン分析と組み合わせることで、リリースの進行状況を把握し、開発者がコードパフォーマンスを最適化して本番環境でのインシデントを削減するのに役立ちます。

近年におけるobservabilityの重要性の高まりは、主に2つの要因によって推進されています：

  1. ビジネスとITシステムの複雑さの増加：クラウドコンピューティングとマイクロサービスの発展により、ビジネスシステムはますます複雑になっています。たとえば、GenAIアプリケーションのリクエストには、App、service gateway、認証サービス、課金サービス、RAG engine、エージェント engine、ベクターデータベース、ビジネスデータベース、分散キャッシュ、メッセージキュー、大規模モデルAPIなど、数十のサービスが関与する可能性があります。SSH経由でサーバー状態を確認し、ログを分析するような従来の方法は、このような複雑な環境ではもはや効果的ではありません。オブザーバビリティプラットフォームは、ログ、トレース、Metricデータの収集と保存を統一し、一元的な可視化と迅速な問題調査を提供します。

  2. ビジネス信頼性へのより高い要求：システム障害がユーザーエクスペリエンスに与える影響はますます大きくなっています。そのため、障害検出と復旧の効率がより重要になっています。オブザーバビリティは完全なデータの可視性と全面的な分析を提供し、チームが迅速に根本原因を特定し、ダウンタイムを削減し、サービスの可用性を確保できるようにします。さらに、グローバルデータ分析と予測により、潜在的なリソースのボトルネックを早期に特定し、障害が発生する前に予防できます。

オブザーバビリティソリューションの選択方法​

オブザーバビリティデータにはいくつかの特性があり、大量のデータストレージと分析の課題に対処することが、あらゆるobservabilityソリューションの鍵となります。

  1. 高いストレージ量とコスト感度：オブザーバビリティデータ、特にLogsとTracesは、通常膨大な量で継続的に生成されます。中規模から大規模企業では、日次データ生成量はしばしばテラバイトまたはペタバイトに達します。ビジネスや規制要件を満たすために、データは数ヶ月または数年間保存する必要があることが多く、ストレージ量がPBやEBスケールに達し、大幅なストレージコストが発生します。時間の経過とともに、このデータの価値は低下するため、コスト効率がますます重要になります。

  2. リアルタイム要件を伴う高スループット書き込み：TB～PBスケールのデータの日次取り込み処理では、しばしば1-10GB/sまたは数百万から数千万レコード/秒の範囲の書き込みスループットが必要です。同時に、リアルタイムトラブルシューティングとセキュリティ調査の必要性により、プラットフォームはリアルタイムデータ可用性を確保するためにサブ秒の書き込み遅延をサポートする必要があります。

  3. リアルタイム分析と全文検索機能：LogsとTracesには大量のテキストデータが含まれています。キーワードやフレーズを迅速に検索することは不可欠です。従来のフルスキャンと文字列マッチングのアプローチでは、特にこのスケール、特に高スループット、低遅延取り込み条件下では、リアルタイムパフォーマンスを提供できないことがよくあります。そのため、テキストに特化した逆インデックスの構築が、サブ秒のクエリ応答性を実現するために重要になります。

  4. 動的データスキーマと頻繁な拡張ニーズ：Logsはもともと非構造化自由テキストログとして存在していましたが、半構造化JSON形式に進化しました。プロデューサーはJSONフィールドを頻繁に変更するため、スキーマの柔軟性が不可欠です。従来のデータベースやデータウェアハウスは、このような動的スキーマを効率的に処理することに苦労する一方、datalakeシステムはストレージの柔軟性を提供しますが、リアルタイム分析パフォーマンスでは不十分です。

  5. 複数のデータソースと分析ツールとの統合：データ収集と可視化には多くのobservabilityエコシステムツールがあります。ストレージと分析エンジンは、これらの多様なツールとシームレスに統合する必要があります。

Elasticsearch、ClickHouse、Doris、クラウドベンダーが提供するログサービスなどの選択肢がある中で、どのように選択すべきでしょうか？主要な評価基準は次のとおりです：

1. パフォーマンス：書き込みとクエリパフォーマンスを含む​

オブザーバビリティはトラブルシューティングなどの緊急事態でしばしば使用されるため、クエリは迅速に応答する必要があります。特にLogsとTracesのテキストコンテンツに対しては、反復的な探索をサポートするリアルタイム全文検索が必要です。さらに、ユーザーはほぼリアルタイムのデータをクエリできる必要があります。数時間前や数分前のデータに制限されたクエリでは不十分で、過去数秒間の新鮮なデータが必要です。

  • Elasticsearchは逆インデックスと全文検索で知られ、サブ秒の検索を提供します。しかし、高スループット書き込みには苦労し、ピーク負荷時に書き込みを拒否したり高遅延を経験したりすることがよくあります。集約と統計分析パフォーマンスも比較的弱いです。
  • クラウドログサービスは豊富なリソースを通じて十分なパフォーマンスを提供しますが、より高いコストがかかります。
  • ClickHouseはカラムナストレージとベクトル実行を使用して高い書き込みスループットと高い集約クエリパフォーマンスを提供します。しかし、全文検索パフォーマンスはElasticsearchやDorisに比べて数倍遅れ、実験的で本番使用には適していません。
  • Dorisはカラムナストレージとベクトル実行を活用し、observabilityシナリオ用に逆インデックスを最適化しています。Elasticsearchよりも優れたパフォーマンスを提供し、約5倍高速な書き込みと約2倍高速なクエリを実現します。集約パフォーマンスはElasticsearchよりも最大6-21倍優れています。

2. コスト：ストレージと計算コストを含む​

オブザーバビリティデータ量は膨大で、特にLogsとTracesです。中規模から大規模企業では日次でTBまたはPBのデータを生成します。ビジネスや規制ニーズにより、データは数ヶ月または数年間保持する必要があり、ストレージ要件をPBまたはEBの範囲に押し上げます。ビジネスクリティカルなデータと比較して、observabilityデータの価値密度は低く、その価値は時間とともに減少するため、コスト感度が重要です。さらに、膨大な量のデータを処理することで相当な計算コストが発生します。

  • Elasticsearchは高コストに苦しんでいます。そのストレージモデルは行ベースの生データ、逆インデックス、docvalueカラムナストレージを組み合わせ、典型的な圧縮比は約1.5:1です。JVMとインデックス構築による高いCPUオーバーヘッドがさらに計算コストを増加させます。
  • Dorisにはobservabilityシナリオ向けの数多くの最適化が含まれています。Elasticsearchと比較して、総コストを50-80%削減します。これには、簡素化された逆インデックス、ZSTDによる圧縮を伴うカラムナストレージ（5:1-10:1）、コールドホット階層ストレージ、単一レプリカ書き込み、書き込み増幅を削減する時系列圧縮、ベクトル化インデックス構築が含まれます。
  • ClickHouseはカラムナストレージとベクトルエンジンを使用して、より低いストレージと書き込みコストを提供します。
  • クラウドログサービスはElasticsearchと同様に高価です。

3. オープン性：オープンソースとマルチクラウド中立性を含む​

オブザーバビリティプラットフォームを選択する際は、オープンソースかどうかやマルチクラウド中立性を含むオープン性を考慮してください。

  • ElasticsearchはElasticが維持するオープンソースプロジェクトで、複数のクラウドで利用可能です。そのELKエコシステムは自己完結型で他のエコシステムとの統合が困難です。例えば、KibanaはElasticsearchのみをサポートし、拡張が困難です。
  • DorisはApache Top-Levelオープンソースプロジェクトで、主要なグローバルクラウドプロバイダーでサポートされています。OpenTelemetry、Grafana、ELKとよく統合され、オープン性と中立性を維持しています。
  • ClickHouseはClickHouse Inc.が維持するオープンソースプロジェクトで、クラウド間で利用可能です。OpenTelemetryとGrafanaをサポートしていますが、observability企業の買収により将来の中立性への懸念が生じています。
  • クラウドログサービスはそれぞれのクラウドに結び付けられており、オープンソースではなく、ベンダー間で異なるため、一貫したエクスペリエンスと移行の柔軟性が制限されます。

4. 使いやすさ：管理しやすさと使用しやすさを含む​

データ量のため、observabilityプラットフォームは通常分散アーキテクチャを採用します。デプロイ、スケーリング、アップグレード、その他の管理タスクの容易さは、スケーラビリティに大きく影響します。システムが提供するインターフェースは、開発者の効率とユーザーエクスペリエンスを決定します。

  • ElasticsearchのKibana web UIは非常にユーザーフレンドリーで管理しやすいです。しかし、そのDSLクエリ言語は複雑で学習が困難で、統合と開発の課題を提起します。
  • DorisはKibanaに類似したインタラクティブ分析インターフェースを提供し、GrafanaやKibana（まもなく提供）とネイティブに統合されます。そのSQLは標準でMySQL互換であり、開発者やアナリストにとって使いやすいです。Dorisはシンプルなアーキテクチャを持ち、デプロイと保守が容易で、サービス中断なしのオンラインスケーリング、自動ロードバランシング、視覚的なCluster Managerを含みます。
  • ClickHouseはSQLインターフェースを提供しますが、独自の構文を使用します。ローカルTableと分散Tableなどの公開されたコンセプトやスケーリング時の自動リバランスの欠如により、メンテナンスは困難です。通常、カスタムクラスター管理システムの開発が必要です。
  • クラウドログサービスはSaaSの便利さを提供し、ユーザーはインフラストラクチャを管理せず、使いやすさを享受できます。

上記の分析に基づいて、Dorisは低コストを維持しながら高パフォーマンスの取り込みとクエリを実現します。そのSQLインターフェースは使いやすく、そのアーキテクチャは保守とスケーリングがシンプルです。また、複数のクラウド間での一貫したエクスペリエンスを確保し、observabilityプラットフォーム構築の最適な選択となります。

Dorisベースのobservabilityソリューション​

システムアーキテクチャ​

Apache Dorisは、ベクトル実行エンジン、CBOオプティマイザー、高度なインデックス、マテリアライズドビューを統合したMPP分散アーキテクチャを持つモダンなデータウェアハウスです。大規模リアルタイムデータセットでの超高速クエリと分析をサポートし、優れた分析エクスペリエンスを提供します。継続的な技術革新により、DorisはClickBench（単一Table）、TPC-H、TPC-DS（複数Table）などの権威あるベンチマークでトップランキングを達成しています。

オブザーバビリティシナリオでは、Dorisは逆インデックスと超高速全文検索機能を導入し、最適化された書き込みパフォーマンスとストレージ効率を実現します。これにより、ユーザーはDorisベースの高パフォーマンス、低コスト、オープンなobservabilityプラットフォームを構築できます。

Dorisベースのobservabilityプラットフォームは3つのコアコンポーネントで構成されます：

  • データ収集と前処理：OpenTelemetryやLogstash、FilebeatなどのELKエコシステムツールを含む、さまざまなobservabilityデータ収集ツールをサポートします。ログ、トレース、MetricデータはHTTP API経由でDorisに取り込まれます。
  • データストレージと分析エンジン：Dorisはobservabilityデータに対して統一された、高パフォーマンス、低コストストレージを提供し、SQLインターフェース経由で強力な検索と分析機能を公開します。
  • クエリ分析と可視化：GrafanaやKibana（ELKスタックから）などの人気のあるobservability可視化ツールと統合し、検索、分析、アラート、リアルタイム監視と迅速な応答を実現する直感的なインターフェースを提供します。

doris-observabiltiy-architecture

主要機能と利点​

高パフォーマンス​

  • 高スループット、低遅延書き込み：日次PBスケール（10GB/s）のLog、トレース、Metricデータのサブ秒遅延での安定した取り込みをサポートします。
  • 高パフォーマンス逆インデックスと全文検索：逆インデックスと全文検索をサポートし、一般的なログキーワード検索に対してサブ秒の応答時間を提供します。ClickHouseより3-10倍高速です。
  • 高パフォーマンス集約分析：MPP分散アーキテクチャとベクトル化パイプライン実行エンジンを利用し、Dorisはobservabilityシナリオでのトレンド分析とアラートに優れ、ClickBenchテストでグローバルに先導しています。

低コスト​

  • 高圧縮比と低コストストレージ：5:1-10:1の圧縮比（インデックス含む）でPBスケールストレージをサポートし、Elasticsearchと比較してストレージコストを50-80%削減します。コールドデータはS3/HDFSにオフロードでき、ストレージコストをさらに50%削減します。
  • 低コスト書き込み：同じ書き込みスループットに対してElasticsearchより70%少ないCPUを消費します。

柔軟なスキーマ​

  • トップレベルでのスキーマ変更：ユーザーはLight Schema Changeを使用して、カラムやインデックスの追加や削除（ADD/DROP COLUMN/INDEX）ができ、スキーマ変更は数秒で完了できます。オブザーバビリティプラットフォームを設計する際、ユーザーは現在のステージでどのフィールドとインデックスが必要かを考慮するだけで済みます。
  • 内部フィールド変更：スケーラブルなJSONデータ用に特別に設計されたVARIANTという半構造化データ型があります。JSON内のフィールド名と型を自動的に識別し、頻繁に発生するフィールドをカラムナストレージにさらに分割し、圧縮比と分析パフォーマンスを向上させます。ElasticsearchのDynamic Mappingと比較して、VARIANTは単一フィールドのデータ型の変更を可能にします。

ユーザーフレンドリー​

  • 標準SQLインターフェース：Dorisは標準SQLをサポートし、MySQLプロトコルと構文と互換性があり、エンジニアとアナリストにとってアクセスしやすいです。
  • オブザーバビリティエコシステムとの統合：OpenTelemetryとELKエコシステムと互換性があり、シームレスなデータ収集と分析のためのGrafanaとKibana（まもなく提供）可視化ツールをサポートします。
  • 簡単な運用：オンラインスケーリング、自動ロードバランシング、Cluster Managerによる視覚的管理をサポートします。

オープン性​

  • オープンソース：Apache Dorisは世界中の5000社以上で採用されているトップレベルオープンソースプロジェクトで、OpenTelemetry、Grafana、その他のobservabilityエコシステムをサポートしています。
  • マルチクラウド中立：主要クラウドプロバイダーがDoris SaaSサービスを提供し、クラウド間での一貫したエクスペリエンスを確保しています。

デモとスクリーンショット​

OpenTelemetryコミュニティの包括的なdemoを使用して、Dorisベースのオブザーバビリティプラットフォームを実演します。

観察対象のビジネスシステムは、フロントエンド、認証、カート、決済、物流、広告、推薦、リスクコントロールなど10以上のモジュールで構成されるeコマースウェブサイトをシミュレートし、高レベルのシステム複雑性を反映しているため、observabilityデータの収集、保存、分析に大きな課題を提示します。

Load Generatorツールはエントリーサービスに継続的なリクエストを送信し、膨大な量のobservabilityデータ（Logs、Traces、Metrics）を生成します。これらのデータは、さまざまな言語のOpenTelemetry SDKを使用して収集され、OpenTelemetry Collectorに送信され、Processorsで前処理され、最終的にOpenTelemetry Doris Exporter経由でDorisに書き込まれます。Grafanaなどのオブザーバビリティ可視化ツールはMySQLインターフェースを通じてDorisに接続し、視覚化されたクエリと分析機能を提供します。

Doris OpenTelemetry Demo

GrafanaはMySQLデータソース経由でDorisに接続し、Logs、Traces、Metricsの統一された可視化と分析、およびLogsとTraces間のクロス分析を提供します。

  • ログ log-visualization

  • トレース log-visualization

  • Metrics metrics-visualization

Grafanaのログ可視化と分析機能はKibanaと比較して比較的基本的ですが、サードパーティベンダーがKibanaライクなDiscover機能を実装しています。これらはまもなくGrafanaのDorisデータソースに統合され、統一されたobservability可視化を強化します。将来の拡張には、Elasticsearchプロトコル互換性が含まれ、DorisへのネイティブKibana接続を可能にします。ELKユーザーにとって、ElasticsearchをDorisに置き換えることで、既存のログ記録と可視化習慣を維持しながら、コストを大幅に削減し、効率を向上させることができます。

studio-visualization