OpenTelemetry と Grafana Cloud で実現した ComplyAdvantage の柔軟なオブザーバビリティ戦略

フィンテックの世界では、企業は常に詐欺師や悪意ある攻撃者に目を光らせています。企業向けにコンプライアンスおよびリスク管理ツールを提供する ComplyAdvantage は、マネーロンダリングをはじめとする犯罪を見つけ出す鍵の一つが、企業のシステム内で何が起きているのかを明確に把握することだと理解しています。

Observability CON 2023 の講演で、Comply Advantage のプリンシパル SRE である Adam Wilson 氏は、チームのオブザーバビリティへの取り組みにおいて Grafana が重要な役割を果たしてきた経緯を振り返りました。同社は、オンプレミスの Grafana OSS から Grafana Cloud へと移行しました。その途中には、別のプロプライエタリなクラウド型ベンダーを利用した時期もあり、その経験を通じてチームは Grafana の価値をさらに強く実感することになりました。Wilson 氏によると、OpenTelemetry のおかげでこの 2 回の切り替えが容易になり、選択肢を検討しながら、メトリクス、ログ、トレース、Kubernetes の監視などを最大限に活用できる最適なソリューションを見つけられたといいます。

オブザーバビリティの背景

ComplyAdvantage が扱うスパンは 1 日あたり 60 億件に上ります。これには、分散型のマイクロサービスベースのアプリケーションを場所を問わず実行できるよう支援するオープンソースのサービスメッシュ Istio を通過する分は含まれていません。同社は約 41 の Kubernetes クラスターと約 2,000 のノードを運用しており、メトリクス系列の約 20% は OpenTelemetry、残りは Prometheus で扱っています。

同社は Grafana OSS からスタートしました。Wilson 氏が入社した当初はフェデレーションがなく、オブザーバビリティスタックのすべてが各クラスターに個別にデプロイされていました。そのため、2 つの異なるクラスターをまたいで何が起きているのかを把握するのは複雑な作業でした。

Wilson 氏は、同社には「優れたオープンソースのオブザーバビリティスタックを構成する部品はそろっていた」と感じていたものの、それらは統合されておらず、特にインシデント発生時にはチームのニーズを満たしていなかったと話します。「結局のところ、本番クラスターに対して、あまりにも多くの人が過剰なアクセス権を持っていました」と同氏は述べました。「コンプライアンスとデータセキュリティを重視するフィンテック企業として、それでは通用しませんでした。」

もう一つの問題もありました。当時のオブザーバビリティをめぐる文化では、ログを永久に保存したいという要望があり、メトリクスの数も増え続けていました。その結果、ComplyAdvantage の Prometheus サーバーは「絶えずダウンする」状態だったと Wilson 氏は言います。「ほぼ毎日のように、Prometheus サーバーを維持するため一晩中対応し、翌日は休まざるを得ない SRE がいました。」

解決策を探す

この問題を解決するため、Wilson 氏は Open Telemetry に目を向けました。特に魅力的だったのは、オープンソースであり、ベンダーニュートラルであることです。また、OpenTelemetry のドロップイン型の計装にも大きな価値を感じたといいます。「わずか数行のコードから始めて、最大限の効果を得られます。組織内の人たちが使い始めると、その力に気づき、さらに活用したいと思うようになります。」

Wilson 氏は、ComplyAdvantage のオブザーバビリティ戦略で重要となるOpenTelemetry エコシステムの 2 つの要素を挙げました。1 つは、さまざまな種類のオブザーバビリティデータを取り込む Go バイナリである Open Telemetry Collector です。同氏は Open Census と OpenTelemetry の両方で利用しています。もう 1 つは、Collector と組み合わせて使う可視化ツールの OTel Bin です。

背景を説明するため、Wilson 氏は Grafana Cloud のスクリーンショットを示し、バックエンドで分散トレーシングがどのように見えるかを説明しました。トレーシングに詳しくない人向けには、図全体が 1 つのトレースであり、最上段の線の下にある各要素がスパンだと補足しました。

同氏によると、上の例は 1 つのアプリケーションの一部を示しているにすぎません。

ComplyAdvantage の Kubernetes クラスターには Istio ゲートウェイがあり、リクエストはアプリケーション Pod に入る前にそこを通過します。その動きは最上段の線で追跡されています。その下では、別の色で Istio プロキシを可視化できます。このプロキシは、アプリケーションと同じ Pod 内でサイドカーとして動作します。さらに下には、アプリケーション内で実行される処理が表示されます。「これらはすべて ID で関連付けられており、OpenTelemetry スキーマで定義されたリクエストヘッダーによって実現されています」と同氏は説明しました。

ComplyAdvantage は、複数のカスタムリソース定義 (CRD) とともに OpenTelemetry Operator を運用しています。専任のオブザーバビリティチームが、Operator のデプロイと、関連するサイドカーの設定を管理しています。「Operator は、アプリケーションそのものと並ぶ形で、OpenTelemetry Collector のバイナリをアプリケーション Pod に注入します」と Wilson 氏は説明しました。同氏が「本当にすばらしい」と感じているのは、OpenTelemetry を使う場所であれば、設定を少し変えるだけでまったく同じ Go バイナリを利用できることです。「ある Collector を次の Collector に向け、パイプラインから別のパイプラインへ、さらにその先のパイプラインへとデータを流す構成を作れます。」

OpenTelemetry ゲートウェイでは、チームが最終的な制御を実施し、正しい環境タグが付いていることを確認できるようにしました。サポートチームにとって分かりやすくし、社内のコミュニケーションも容易にするため、UI のドロップダウンに表示する環境は 3 つだけに絞りました。

OpenTelemetry はトレース、メトリクス、ログを扱いますが、Wilson 氏は、特にトレースを「オブザーバビリティにおける第一級の存在」として扱っている点を指摘しました。一方、ログの転送については、OpenTelemetry ではなくプロプライエタリなオブザーバビリティベンダーを選択したといいます。

Grafana Cloud への移行

サンプリングの経験について説明した後、Wilson 氏は Comply Advantage の Grafana Cloud への移行を取り上げました。採用していたプロプライエタリなオブザーバビリティベンダーと自社の文化が合わないと感じたためです。「まるで別の言語で話しているようでした」と Wilson 氏は述べています。そこで同社は、オブザーバビリティのバックエンドを担う新たなベンダーを再び探し始めました。

Grafana Labs と協議した結果、Grafana に戻ることは「まったく理にかなっていた」と同氏は話します。Grafana がオープンソースを背景に持つことも魅力でした。双方の技術チームが対話したところ、「すべてが以前よりはるかに、はるかに、はるかにうまくかみ合った」といいます。

Wilson 氏によると、Comply Advantage の Grafana Cloud への移行期間は、OpenTelemetry を利用していたため、最初の移行よりも大幅に短くなりました。Grafana Cloud は Open Telemetry とネイティブに統合されているため、SDK を再実装する必要がなかったのです。

Comply Advantage の新しいオブザーバビリティ基盤では、アプリケーションの監視データが、現在スパンメトリクスを利用しているゲートウェイへ送られます。Open Telemetry ゲートウェイの第 1 層を通過するすべてのトレースからメタデータとメトリクスが抽出され、そのまま Grafana Cloud に送信されます。

「Open Telemetry ゲートウェイの第 1 層はロードバランシングエクスポーターを使い、同じトレースに属するすべてのスパンを第 2 層の Open Telemetry ゲートウェイに送ります。そこでサンプリングの判断を行います」と Wilson 氏は説明しました。どちらの層も Kubernetes の Deployment として動作しています。そのため現時点では、リクエストヘッダーを使ってオブザーバビリティ基盤に状態を持たせるという、いわばハックを行っていると同氏は述べています。

「以前はプロプライエタリなエージェントを使っていましたが、そこを Grafana Agent に置き換えました」と同氏は説明します。「Grafana Agent がログを処理します。また、Prometheus エンドポイント向けのメトリクスを扱うため、エージェントモードで動作する Prometheus をクラスター内に再導入しました。」

一部のノードでは RabbitMQ が動作しており、RabbitMQ のメトリクスをスクレイプして、ほかのすべてのデータとともに Grafana Cloud に送信できます。

大きな成果

Grafana Cloud への移行が完了すると、社内の働き方にも変化が生まれました。「私たちにとって最も大きかったのは、人々がデータでストーリーを語り始めたことです」と Wilson 氏は説明しました。

たとえば、トレース (下図左) から円グラフ (下図右) を作成することで、「それまで一度もなかったような会話が組織全体で始まった」と同氏は述べています。

以前は、ComplyAdvantage の CEO がシステム全体で何件の検索が実行されたかを知りたい場合、複数の場所を確認し、数字をつなぎ合わせる必要がありました。しかしトレースを使えば、ダッシュボードを見るだけで答えを得られます。

さらに重要なのは、CEO がインフラストラクチャデータを円グラフで示し、顧客やパートナーが ComplyAdvantage をどのように利用しているかについての対話を組み立てる材料にできることです。

「アプリケーションにいくつかのリクエストヘッダーを追加しただけで、製品や営業など事業側にまで影響を与えられたことは、本当に画期的でした」と Wilson 氏は述べました。

同氏は、OpenTelemetry とベンダーニュートラル性について、1 つ留意すべき点があると指摘しました。「テクノロジー自体は複数のベンダーに対応できるかもしれません。特定のベンダーが提供する“魔法”のような機能を気に入り、そのベンダー独自の機能への依存を徐々に深めていったとしても、もはやベンダーニュートラルではないと慌てる必要はない、と彼は言います。

「必要になれば移行できます」と、彼はObsCONの聴衆に念を押しました。

今後の展望

Grafana Cloud への移行後、ComplyAdvantage は Grafana SLO のアーリーアダプターになりました。Grafana SLO は Grafana Cloud のソリューションで、サービスレベル目標 (SLO)、SLO ダッシュボード、エラーバジェットアラートを簡単に作成、管理し、規模に応じて拡張できるようにします。「Grafana Labs との関係の一環として、開発中の新しいプロジェクトや製品に実際にフィードバックを提供できるのは、とても良いことです」と同氏は述べました。

Wilson 氏は、自社と文化が合うオブザーバビリティベンダーと協働できることも喜ばしいと話します。「今は本当に満足できる場所にたどり着き、以前よりもずっと緊密なパートナーシップで一緒に取り組めています。」