ブログ

大規模なPrometheusを使用した場合における課題

大規模なPrometheusを使用した場合における課題

本文の内容は、2020年3月26日にSysdigのCarlos Arillaが投稿したブログ(https://sysdig.com/blog/challenges-scale-prometheus/)を元に日本語に翻訳・再構成した内容となっております。

この記事では、Prometheusを大規模に使用しようとするときに見つける可能性がある最も一般的な課題について説明します。

Prometheusは、クラウドネイティブ環境の基盤の1つです。これは、Kubernetes環境での可視性のデファクトになり、Prometheusモニタリングと呼ばれる新しいカテゴリを作りました。Prometheusの旅は、通常、Kubernetesの旅と、PoCから本番までのさまざまな開発段階に関連してきます。

Prometheusの最初のステップ

Prometheusは、開発段階にある最初のKubernetesクラスターと連携することがよくあります。一部のアプリをデプロイした後、クラスターへの洞察が必要であり、古いホストベースのツールセットが機能しないことに気付く場合があります。徹底的な調査(Google検索の結果)で、Prometheusを発見します。

Prometheusは、サーバー、一部の基本的なエクスポーター、Grafanaをデプロイした後、簡単に開始できます。ダッシュボードとアラートの作成を開始できるように、メトリクスを取得できます。

次に、Prometheusをさらに詳しく調べて、いくつかの非常に優れた機能を発見します:

  • 設定を容易にするサービス検出。
  • オープンソースコミュニティによって構築された何百ものエクスポーター。
  • アプリケーションからカスタムメトリクスを取得するためのインストルメンテーションライブラリ。
  • これは、CNCF傘下のOSSであり、Kubernetesをグラデュエートした2番目のプロジェクトです。
  • Kubernetesはすでにインストルメント化されており、すべてのサービスでPrometheusメトリクスを公開しています。
20200328-1.png

この時点で、すべてが素晴らしいように見えます。 Kubernetesはあなたの親友であり、アプリはスムーズにスケーリングし、豪華なダッシュボードから多くのものを見ることができます。 次のステップの準備が整いました。

本番環境へ移りましょう

2番目のKubernetesクラスターがここにあり、同じプロセスに従います。 Prometheus、エクスポーター、Grafanaは迅速にデプロイされています。ステージングクラスターは通常、開発環境よりも大きいですが、Prometheusはそれをうまく処理しているようです。アプリケーションのセットは少なく、ダッシュボードとユーザーの数も少ないため、移行も簡単です。

最初の小さな問題が発生します。ここに、2つの異なるGrafanaインストールがあり、それらを切り替えて、開発環境とステージング環境のメトリクスを表示する必要があります。現時点では、開発者はこれについてあまり心配していませんが、かゆみを感じ始めています。 すべてがチェックアウトされ、本番環境へのリリースは問題ありません。

20200328-2.png

そして、3番目のクラスター。 同じプロセスをもう一度実行します。 Prometheus、エクスポーター、Grafanaをデプロイし、ダッシュボードとユーザーを移行します。ユーザーは3番目のダッシュボードポータルを使用することに不満を持っていますが、使えない訳ではありません。

結果は非常に良好であるため、同社はより多くのアプリケーションをKubernetesに移行することを決定しました。新しいユーザー、設定、ダッシュボード、アラートは、各クラスターに1つずつ追加する必要があります。一貫した方法で構成を管理するには、ある程度の労力と組織が必要になります。

アプリケーションの数が増えると、新しい要件が発生し、さまざまなアプリケーションをホストし、さまざまな地域でサービスを提供し、可用性を高めるために、新しいクラスターが作成されます。それぞれに異なるPrometheusとGrafanaのインスタンスを維持することは困難になり、DevOpsと開発チームは不平を言い始めます。

20200328-3.png

グローバルな可視性の維持

分散モデルにはさまざまな課題があります:

  • グローバルな可視性は許可されていません。いくつかの本番クラスターでは、これが新しい要件になります。
  • 操作は面倒で時間がかかる場合があります。
  • このモデルは、ガバナンスと規制コンプライアンスを複雑にする可能性があります。

集中管理された視覚化ツールを使用すると、さまざまなクラスターへのアクセスが容易になるだけでなく、同じダッシュボード内の複数のクラスターにわたるサービスからの情報を視覚化して相関させることができます。

一見すると、これは簡単に思えるかもしれません。集中化されたGrafanaをデプロイし、クラスターで実行されているさまざまなPrometheusサーバーをデータソースとして追加します。

20200328-4.png

これにはいくつかの隠された課題があります:

  • セキュリティは、Prometheusに含まれている機能ではありません。 PrometheusとGrafana間の通信がクラスター内である限り、これは問題ではありません。ただし、Grafanaをクラスターから外す場合は、Prometheusの上に何かを実装して、接続を保護し、メトリクスへのアクセスをコントロールする必要があります。この問題には多くの解決策がありますが、実装と保守にいくらかの労力が必要です(証明書の管理、イングレスコントローラーの作成、Grafanaでのセキュリティの構成など)。
  • クラスターが動的または変化している場合、クラスターにPrometheusをデプロイするたびにデータソースをGrafanaに自動的に追加する方法を実装する必要があることがよくあります。
  • これにより、さまざまなソースからのダッシュボードパネルを混在させることができますが、さまざまなクラスター間でサービスをクエリしたり、実際にグローバルなクエリを実行したりすることはできません。
  • 誰がどのデータにアクセスするかをコントロールすることがより重要になり、RBACシステムが必要になる場合があります。アイデンティティサービスとの統合は、ユーザーベースを最新の状態に保つために最も必要であり、これがコンプライアンス要件になる可能性があります。

これらの問題はすべてブロッカーではありませんが、アーキテクチャの設計、開発、実装の努力が必要です。 この構造全体のメンテナンスにも、かなりのリソースが必要です。

Prometheus水平スケール

チームの努力により、きちんとした一元化されたシステムができ、新しい問題が発生するまで、すべてが完璧に見えます。 開発者は、ビジネス情報を含むカスタムメトリクスの力を理解し、コードを計測して取得します。組織が成長するにつれて、Kubernetesのサービス数が増加し、メトリクスの使用量が増加します。クラスターは拡大され、サービスにはより多くのレプリカがあります。

Prometheusサーバーが停止し始め、調査の結果、メモリの問題であるとはっきりとわかります。Prometheusのメモリ使用量は、保存されている時系列の数に正比例します。時系列が増加すると、OOMの強制終了が発生します。リソース割り当てリミットを引き上げますが、これを無制限に行うことはできません。最終的にノードのメモリキャパシティに達し、ポッドがそれを超えることはできません。数百万のメトリクスを持つPrometheusは100GBを超えるRAMを使用する可能性があり、それはKubernetesで実行されている問題である可能性があります。キャパシティを吸収するためにスケールアウトする必要がありますが、簡単に言えば、それは不可能です。Prometheusは、水平方向に拡大縮小するようには設計されていません。 垂直スケーリングの限界に達したら、終わりです。

20200328-5.png

この問題にはいくつかの回避策があります。たとえば、いくつかのPrometheusサーバー全体で異なるメトリクスをシャーディングするなどですが、これはトリッキーなプロセスです。セットアップが複雑になり、トラブルシューティングが困難になる可能性があります。

20200328-6.png

あきらめて、長期保存ソリューションを試してみましょう

多くの人がこれまでに同じ問題に直面しています。 Prometheusがそれがメトリクスストレージではないと主張していることを考えると、予想される結果は、誰かが最終的にPrometheusメトリクス用の長期ストレージを作成することでした。

現在、長期保存(LTS)を提供するいくつかのオープンソースプロジェクトがあります。これらのコミュニティプロジェクトは、Cortex、Thanos、M3など、他のプロジェクトに先行しています。

20200328-7.png

これらのサービスには複雑な問題がないわけではありませんが:

  • アーキテクチャは複雑であり、モニタリングの自己実行サービスをデプロイ、最適化、および維持するには多くの労力が必要になる場合があります。
  • 運用コストが高くなる可能性があります。DynamoDBなどのマネージドデータベースを活用できますが、残りのモニタリングサービスをスケーリングする必要があり、メトリクスのスループットが非常に高くなる可能性があります。
  • これらのプロジェクトはまだ開発の初期段階にあり、専門のチームであっても本番環境で実行するのは難しい場合があります。

次は?

Prometheusは、Kubernetesがコンテナーオーケストレーションと同様に、クラウドネイティブアプリケーションの監視ランドスケープのゲームチェンジャーでした。ただし、大規模なハイテク企業でさえ、PrometheusをDIYの方法でスケーリングするという難題に気づいています。このアプローチを維持することに専念しているフルタイムの同等のリソースはすべて、ビジネスを変革する革新的なコードを書く可能性のある開発者が1人少なくなります。

アーリーアダプターになって新しい分野を探求することはエキサイティングですが、良いサービスにお金を払い、苦痛に満ちた道を避けることができると良い場合もあります。

20200328-8.png

多くのお客様が感じている苦痛を和らげるために、Sysdigはプラットフォームを進化させるために着実に取り組んできました。私たちは、Prometheusと完全に互換性を持たせると同時に、数百万の時系列にスケーリングし、データを長期間保持する能力を向上させたいと考えています。Sysdigを使用すると、サポートされているプラットフォームを利用して、Prometheusモニタリング用のスケーラブルで安全なソリューションを提供できます。同時に、開発者がPrometheusが何ができるかを最初に発見したとき、可視性の同じ喜びを開発者にもたらします。Sysdigをまだテストしていませんか? 今すぐ無料トライアルにサインアップしてください!

ご質問・お問い合わせはこちら

top