
InstanaはApache Cassandraを使用して数十億のメトリクスをクエリしています
パートナー情報
-
可観測性とメトリクス
-
従業員数150名以上
-
毎秒数百万のメトリクス
-
5つの運用リージョン、各リージョンに15ノード
-
AWSとGCPの両方で稼働
メリット
-
固定クエリのための分散モデル
-
小規模なチームでも保守可能な複雑なデータモデリング
-
Cassandra TTLを組み込みのデータモデルとして使用
-
保持ポリシーの容易な実装
-
数百万のメトリクスのリアルタイムクエリ
-
Cassandra 3.0の時間ウィンドウ圧縮戦略による時間ウィンドウビューの容易な作成
イリノイ州シカゴに拠点を置くIBMの企業であるInstanaは、CI/CDパイプラインの可視性を備えた最新のアプリケーション向けのアプリケーションパフォーマンス管理ソフトウェアを提供し、クローズドループDevOpsの自動化を実現しています。Instanaは、1日に数十億ものメトリクスをリアルタイムで収集することで、豊富なコンテキストインテリジェンスとAIベースの問題解決を提供し、Apache Cassandraを使用して大規模なデータの保存と処理を行っています。その高性能で高スケーラブルなアーキテクチャは、ハイブリッドクラウドの大規模な分散アプリケーションにおいて、1秒間隔でトランザクションの100%をキャプチャします。
Instanaの監視ツール(Instanaとも呼ばれます)は、CPUやメモリ使用量などのホストレベルのデータを収集し、ホスト上で実行されているプロセスをマッピングします。このツールはアプリケーション層まで監視し、システムを通過する1つのリクエストを追跡します。
課題
Instanaの顧客基盤は拡大しており、新規ユーザーの期待値は高まっていました。ユーザーは結果を見るのに1分待つことを望んでいませんでした。リアルタイムで結果を見たいと考えていました。
Instanaは現在、5つのリージョンで運用されており、各リージョンには数千のセンサーを実行する4つのクラスタがあります。各センサーは1秒間に1000個以上のメトリクスを送信できます。「これだけの量のデータを保存してクエリできるものが必要でした。クエリに対しては常にどのセンサーからのデータが必要であるかを把握しており、時間範囲に制限されていました。これが、時系列データモデルのCassandraを選んだ理由です」と、InstanaのStaff Site Reliability EngineerであるMarcel Birkner氏は述べています。
Instanaチームにとって、Apache Cassandraは特定のユースケースに非常にうまく対応していました。
お客様の声
Cassandraはうまく機能します。非常にスムーズに動作します。データが失われたことは一度もなく、問題も簡単に解決できます。率直に言って、Cassandraがなければ、Instanaを運用することはできませんでした。
Staff Site Reliability Engineer, Instana
Instanaを始めた頃は、スタートアップ企業としてよくあることですが、特に100種類の異なるテクノロジーと1000種類の異なるライブラリを監視している私たちの場合、Cassandraを使用したマイクロサービスアーキテクチャは、単一のコンポーネントが失敗した場合にグレースフルデグラデーションを行うことを意味していました。
Staff Software Engineer, Instana
大量クエリの高性能
複雑なシステムを監視するには、1秒単位の粒度でメトリクスをレポートする必要があります。Instanaは、システムパフォーマンスデータを収集し、CPU使用率やトリビアルなGC時間などのさまざまなメトリクスをレポートするセンサーと連携します。通常、環境には数千のセンサーがあり、各センサーは毎秒最大1000個以上のメトリクスを送信できます。その結果、単一ユーザーに対して大量のデータが発生します。
この大量のデータ取り込みに加えて、ユーザーはデータをクエリできる必要があります。一般的には、時間範囲の制約のある単一のセンサーに焦点を当てています。Cassandraの時系列データモデルはこのニーズに合致していました。
グレースフルデグラデーション
Instanaは、モノリシックアーキテクチャでは解決できないデータモデリングの課題に直面しました。特に、アプリケーションは数百のテクノロジーと数千のライブラリを監視しており、ユーザーはそれらを数百万もの構成に組み合わせていました。データ受信システムの一部が停止したり、廃止されたりした場合でも、グレースフルデグラデーションを可能にするのは、Apache Cassandraによってサポートされているマイクロサービスアーキテクチャのみでした。
時間ウィンドウ圧縮
当初、大きな課題は、圧縮の適切なウィンドウとその他の設定を見つけることでした。適切な戦略がないと、すぐに制御不能になる可能性があります。圧縮プロセスはキーをマージし、列を結合し、墓石を削除し、SSTableを統合し、マージされたSSTableに新しいインデックスを作成します。このアプローチを安易に使用すると、新しいロールアップされたデータポイントを書き込む際に、毎秒数百万の挿入が発生する可能性があります。ある時点で、単一のクラスタに30,000個のSSTableを持つ単一のテーブルがあり、チームはそれを管理可能なサイズに削減するために手動で圧縮を実行する必要がありました。
1秒単位のデータ分解能の規模は、長期的な保存や長期間にわたるクエリ(たとえば、過去3か月間のメモリ使用量を確認するなど)には意味がありませんでした。このユースケースのために、Instanaは、たとえば5秒間隔で平均化されたデータを示すロールアップデータが必要としました。ユーザー向けの固定時間ウィンドウビュー(1秒、1時間、1日、1週間のビュー)を表示するという選択肢が選ばれました。ロールアップデータには異なる保持ポリシーがあり、Cassandra TTL(存続可能時間)はデータモデルに自然に適合していました。
Instanaのユーザーは、Instanaデータを表示するために時間ウィンドウ付きの要求を行うため、Cassandraは完璧な選択肢でした。Cassandra 3.0の時間ウィンドウ圧縮戦略により、Instanaは、時間ウィンドウ別にグループ化されるディスク上のデータをグループ化することができました。
具体的な成果
Instanaは、運用開始以来、大規模なApache Cassandraのメリットを享受しています。Cassandraは、エンタープライズ規模のエンジニアリングチームなしで複雑なデータモデルを実行する能力を提供し、100種類の異なるテクノロジーを監視し、そのデータをスムーズにクエリできるように表示する能力を実現しました。
Instanaは、ベアメタルの自己ホスト型サーバーから、パブリッククラウドでサーバーレスに実行されるアプリケーション、モバイルアプリケーションまで、あらゆるものからデータを消費し続けています。Cassandraは、小規模なチームが競争の激しい可観測性分野で最高レベルのパフォーマンスを提供できるようにするためのInstanaの重要なパスの一部でした。
Instanaについて
IBMの企業であるInstanaは、オンプレミスまたはパブリックおよびプライベートクラウド(モバイルデバイスやIBM Zを含む)に関係なく、複雑で最新のクラウドネイティブアプリケーションを運用する企業向けに、自動化されたアプリケーション監視機能を備えたエンタープライズ可観測性プラットフォームを提供しています。
InstanaのAIを活用したハイブリッドアプリケーション内部の深いコンテキスト依存関係の検出により、ハイブリッドな最新のハイブリッドアプリケーションを制御します。Instanaは、開発パイプラインの可視性も提供し、クローズドループDevOpsの自動化を実現します。
これにより、クライアントがアプリケーションのパフォーマンスを最適化し、イノベーションを促進し、リスクを軽減するために必要な実行可能なフィードバックが提供され、Dev + Opsがソフトウェアデリバリーパイプラインに価値と効率を追加しながら、サービスとビジネスレベルの目標を達成するのに役立ちます。