Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年5月7日にAaron Newcombが投稿したブログ(https://sysdig.com/blog/prometheus-monitoring-behind-scenes/)を元に日本語に翻訳・再構成した内容となっております。
数週間前に、Sysdigは、お客様に大規模な環境で使える互換性のあるPrometheusモニタリングの提供、Prometheusエクスポーター、ダッシュボード、および、アラートのリポジトリをホストするPromCat.ioと呼ぶ、新しいWebサイトの提供を発表しました。プラットフォームでこれらを提供するために実際に必要な変更を実装する方法を考えましたが、私はSysdigに少し慣れていないので、製品管理担当副社長のPayal Chakravartyと製品管理担当ディレクターのJorge Salameroにいくつか質問をすることにしました。
ジョージ：プロメテウスは、Kubernetesもより広く採用されるようになるにつれて、ますます採用と人気を獲得しています。基本的に、彼らはコンテナマラソンで並んでいます。
Prometheusの優れている点の1つは、モニタリングを簡単に開始できることです。組織全体の開発者は、Kubernetesを使い始め、アプリケーションをそれらのクラスターにデプロイするとすぐに、CPUで何が起こっているか、メモリ使用量、実行されているインスタンスの数などの可視性を取得する必要があります。そのため、Kubernetesクラスターと一緒にPrometheusを簡単にデプロイできます。
単純なPrometheusセットアップには、非常に少数の要素が含まれています。
ジョージ：本番環境へ移行し始めると、最終的にはより多様な環境が実行され、非常にトリッキーになります。Prometheusはプルモデルを使用して構築されているため、各クラスターにローカルにデプロイする必要があります。
Prometheusは各クラスターでローカルにデプロイする必要があります
最初のクラスターは問題ありませんが、多分、2番目と3番目のクラスターもですが、クラスターがたくさん集まったら、さまざまな環境にログインしてそれらを可視化する必要があります。グローバルな視点が欠けています。次に、より多くの本番ワークロードをこれらのクラスターに移動すると、より大きなスケールが必要になります。また、このスケーリングの影響は、中規模の環境でも感じることができます。これらのクラウドネイティブ環境で何が見えるのか疑問に思われるかもしれません。コンテナが上がったり下がったりし、サービスが再起動し、ノードが停止し、ポッドが再スケジュールされると、追跡する必要のあるアセットの数は基本的に急増します。
私たちがペットと牛の牧畜を行う場合、以前は、ご存知のサービスやペットがいくつかありました。これで、Kubernetesを使用して、ポッドまたはコンテナの群れができました。それらすべてにもう名前を付けることはできません。追跡が必要なさまざまな小さなものを多数作成しました。これにより、クラウドネイティブメトリクスの爆発と呼ばれるものが生成されます。
ジョージ：まず、Prometheusとの完全な互換性を開発しました。外から見ると、まるでそれがPrometheusサーバーであるかのようにSysdigデプロイメントが表示されます。APIは同じです。Prometheusクエリ言語（PromQL）を使用して、メトリクスをクエリできます。
したがって、ダッシュボードの作成、PromQLの学習、Prometheusエクスポーターによるアプリケーションとインフラストラクチャーのインスツルメンテーションなど、開発者がPrometheusに費やしたすべての投資は、Sysdigに移行するときに捨てる必要はありません。
基本的には、バックエンドを切り替えると、自動的に、エンタープライズ向けの機能が得られ、既存の投資の上に拡張できます。これがSysdigの大きな利点です。チームやRBACなどのエンタープライズ機能を上に追加しながら、完全な互換性を持つことができます。あなたが成長しても、大丈夫、私たちがついています。ワークロードと組織の要件をサポートするために、必要に応じて拡張できます。
Payal：はい、アーロン。スケールには多くの異なる次元があります。それを、私たちが話したい最も重要なものに分けましょう。まず、ノードの数があります。第２に、時系列の数。これは監視のコンテキストで最も関連性が高いと思います。時系列は、生成されたメトリクスとラベルの組み合わせです。Prometheusの世界では、「高いカーディナリティ」という言葉を聞いたことがあるかもしれません。つまり、メトリクスとラベルの数を組み合わせて時系列を生成すると、データが突然爆発する可能性があります。カーディナリティの高いデータを処理できるシステムを理解する必要がありますよね？ 3番目に、ノードごとに実行されている多くのコンテナがあります。コンテナの数が増えると、Kubernetesオブジェクトの数も増えるため、これも要因です。Kubernetesオブジェクトとは、デプロイメントのことです。ネームスペース、ステートフルセットなど、
これらすべてを深くかつ詳細に監視するには、システムが効果的かつ効率的な方法でクエリを実行できる必要があります。これら3つのパラメーターを検討し、取り込みとクエリのアクティビティを考慮に入れると、エージェントごとに数十万の時系列にスケーリングできます。
各ノードは、システムリソース使用状況メトリクス、Kubernetesメトリクス、Prometheusメトリクス、statsd、JMX、およびカスタムメトリクスの組み合わせをレポートします。今日、私たちは通常、ノードごとに最大10,000のPrometheus時系列を送信している顧客を目にしています。これは、ホスト、コンテナ、kube stateメトリクスなど、デフォルトで利用できるエージェントメトリクスに追加されたもので、10,000にはカウントされません。平均的な環境を採用している場合、1人の顧客が数百万の時系列になる可能性があります。ここで、IBMクラウドなどのクラウド環境全体について話している場合や、数百の顧客がいるSaaS環境の1つを取り上げている場合は、すべてを処理できる数億の時系列について話していることになります。 我々は10秒毎にハンドルできるのです。
Payal：今日の場所にたどり着くまでに2年近くかかりました。一歩一歩始めました。先ほど言ったように、スケールの寸法はさまざまでした。まず、10万のノードを監視している非常に大規模な顧客がいたため、サポートするエージェントの数をスケーリングする必要がありました。ですから、それを処理できなければなりませんでした。次に、時系列スケーリングとコンテナ密度が発生しました。3年前は、平均コンテナ密度が数十から20台であることがわかりました。現在は、平均で50から70の範囲、さらには150までの範囲が見られます。したがって、密度の限界を押し上げています。
同様に、Kubernetesオブジェクトの爆発的な増加を見てきました。以前は主にレプリケーションコントローラー、ネームスペース、およびクラスターがありました。これで、ステートフルセット、デーモンセット、実行されるKubernetesジョブが増加しました。したがって、処理を求められているKubernetesデータは他にもあります。約2年前に種を植え、データのカーディナリティとコンテナ密度がどのように増加しているかを調べましたが、それが時系列の爆発的な増加につながることがわかっていました。そして、規模の限界を押し広げていた数人の顧客と話し始めました。彼らはある意味で時代を先取りしていた。私たちはシステムを調べ始め、ボトルネックがどこにあるのかを見ました。顧客が要求する規模に対応できる時系列データベースを構築する必要があることに気付きました。私たちの古典的なデータストアは、実際には純粋な時系列データベースではなく、時系列間のハイブリッドのビットでした。ホスト、コンテナ、プロセスデータベース。
InfluxDBやOpenTSDBなど、市場には多くの時系列データベースがありますが、クエリ側の微調整に関しては、すべて特定の課題に直面していました。メトリクスをプッシュして、それがどこまでできるかを確認できるので、取り込みは簡単です。この部分は、クエリの最適化よりも業界で解決されました。それで、それをパーツに分解しなければなりませんでした。1つ目は収集です。これは、エージェントが大量のデータを収集してバックエンドに転送する方法です。2番目の部分は取り込みであり、そのすべてのデータを取り込み、意味のある最適化された方法で保存する方法を提供し、クラウドのコストの急増につながらないようにしました。 3つ目は、分散クエリ処理を使用して大量のデータセットをクエリするときに、そのクエリ部分を最適化することです。それで、一歩一歩、それらのパーツを取り、それを壊しました。クエリ部分と取り込み側では、リアルタイムクエリを処理するKafkaと、Metric StoreとしてCassandraを使用することにしました。次に、長期データの処理方法を決定したいと思いました。13か月前を確認したい場合、どうすればそれを提供できますか？これらは、私たちが検討しなければならないすべてのパラメーターです。
ジョージ： Sysdig Monitorで多くのオープンソースの断片を見ることができます。それらのいくつかはオープンソースのPrometheusに関連しており、それらのいくつかはCortexのような他のプロジェクトです。したがって、Sysdigで見つけられるさまざまな要素が見つかります。たとえば、エージェントはエージェントに埋め込まれた軽量のPrometheusサーバーを使用し、バックエンドはいくつかのCortexコンポーネントを活用するPromQL APIを公開しています。私たちが使用する他のオープンソース要素は、CassandraとKafkaです。これらは、Prometheusの一部ではありません。
単にPrometheusを使用しただけでは、お客様から特定した問題は解決されません。そして、この旅において、私たちのエンジニアは私たちが使用するオープンソースプロジェクトに積極的に貢献しており、誰にとってもより良いものになるように注意することが重要です。
ジョージ：実際にダッシュボードエンジン全体を書き直して、Prometheusの観点からKubernetesを監視するときのユーザーエクスペリエンスを向上させました。それが私たちの鍵です。
私たちは、大衆が用語を作り出すためにPrometheusを持っていきたいと思っています。意欲的な経験と使いやすいインターフェースを提供することは、私たちの主な差別化要因の1つです。思いがけない体験は、機能を公開することと、ワークフローに事前定義された一連のステップを提供しながら、ある程度カスタマイズできることとのトレードオフです。したがって、その前提の下で、我々はダッシュボードを再構築しました。
まだPromQLを使用していますが、Grafanaなどの他のオープンソース要素とは異なります。これは、UIを使用してダッシュボードを構築できる合理化されたエクスペリエンスであり、ここでは、メトリクスをナビゲートし、メトリクスを選択し、平均レート、最大、最小などのさまざまな演算子または関数を選択できます。同じ画面で、PromQL互換性を使用する機能もあります。実際に両方を組み合わせてダッシュボードを作成し、メトリクスをナビゲートおよび参照して、Kubernetes環境のトラブルシューティングとモニタリングに必要なすべてのインジケーターを関連付けることができます。
Payal：少しレベルを調整するだけです。Sysdigには組み込みの統合機能があり、これはしばらくの間サポートされており、すぐに使用できるので、すぐに使用を開始できます。しかし、Prometheusの世界で進展していることは、ますます多くのアプリケーションとテクノロジーがPrometheusメトリクスをネイティブに放出しているため、特定のテクノロジーまたはアプリケーションをPrometheusで監視するために、コミュニティー全体のアプローチがあります。世の中にはたくさんあります。
今日、Prometheusを使用している組織のユーザーエクスペリエンスは、彼らが望んでいることをサポートするエクスポーターを探さなければなりません。GitHubには、さまざまなスター評価とさまざまなレベルのドキュメントが複数存在する場合があります。次に、Grafanaのダッシュボードを検索します。繰り返しになりますが、20の異なるオプションがあります。
たとえば、「ノードエクスポーター」または「Kubernetesダッシュボード」を検索するだけの場合、数十件あります。どちらをダウンロードするかを明確に決定する必要があります。おそらく、人気やそのような特定の要因に基づいて選択することになります。また、たとえば、バージョンが変更された場合、またはソフトウェアをアップグレードした場合、メトリクス名が変更されたためにダッシュボードが壊れる可能性があるなど、互換性を維持する必要もあります。ユーザーは、どの統合が機能するか、どのように設定して環境で機能させるのかを理解するのに1週間の開発者時間を要するとユーザーが言っていると聞きました。そして、それは純粋に先行投資です。継続的なメンテナンス費用もかかります。したがって、この道を歩み始めたときに、この問題を解決したいと考えました。
完全な互換性と拡張性を提供できるこの驚くべきシステムがありますが、ユーザーがコンテンツを簡単に取得できるようにするにはどうすればよいですか？このブレインストーミングにより、PromCat.ioが作成されました。PromCat.ioは、エクスポーターの設定方法に関する段階的なガイダンス、ダッシュボード、アラートルールを提供する検索可能なリポジトリです。これらは、必要に応じてSysdigで、または完全に純粋なオープンソース形式で使用できます。お客様にとっては、これらもSysdigによってサポートされるため、助けが必要な場合や、この統合が失敗した場合に連絡できる担当者がいます。統合を最新の状態に保ち、テストハーネスを使用してさまざまなリリースをテストし、それらが期待どおりに機能することを確認します。
今後のロードマップでは、製品への非常にシームレスな統合が実現していきます。Sysdigは、Cassandraが実行されていることを検出したことを自動的に通知し、適切なダッシュボードとそれを構成するために必要な適切な手順を提供します。Prometheusカタログから直接シームレスにアイテムをインポートできます。
ジョージ： PromCat.ioの各統合は、エクスポーター、ダッシュボード、アラートとデプロイメントの指示のバンドルであり、Prometheusの記録ルールがいくつかある場合があります。そのため、これらの統合を維持する新しいサポートチームを構築しました。これにより、Sysdigのお客様は、面倒な作業のすべてについて心配する必要がなくなります。
たとえば、私たちが公開した最近の統合の1つはAWSサービスからメトリクスを収集することであり、そこには利用可能なエクスポーターがありましたが、それらは基本的にDIYプロジェクトとして愛好家によって行われました。AWSのメトリクスを取得するために誰かがそのエクスポーターをデプロイした瞬間、彼らはデフォルトで数千のメトリクスを生成し、高額な請求書を作成しました。したがって、私たちのチームは、そのエクスポーターをより大規模な環境で機能するように改善するために取り組みました。これは、このチームが舞台裏で行う作業のほんの一例です。次に、これらの変更はオープンソースコミュニティに戻されます。
Payal：一つ目は、このようなプラットフォームの変革では、既存の顧客だけでなく、導入したい新しい顧客についても考える必要があります。新規顧客の場合は、すぐに新しいプラットフォームを紹介できますが、この旅で既存の顧客ベースをどのように活用するかを考える必要があります。彼らは特定のものに慣れています。特定の形式で保存された履歴データがあります。それらをクラシックスタックから新しいスタックにどのように移行しますか？
それは私たちが理解している大きな課題であり、ここには良い計画がありますが、私たちはまだ毎日学習しています。それに加えて、SaaSとオンプレミスの両方のソリューションを使用する場合の多次元的な問題があります。それがSaaSであれば、すべてを自分で行い、会社内の問題を理解するのに苦労します。オンプレミスの場合、お客様は、あるスタックから別のスタックに移行するためのスムーズなパスを提供するアップグレードプロセスを理解する必要があります。それは、私にとって最も困難な挑戦でした。
もう1つの要因は、エコシステムが変化し続けることです。私たちが定義するディメンションは、取り込みたいkube Stateメトリクスの数でも、ホストで許可する必要のあるコンテナの数でも、3か月後に変更されてしまうような新しいエコシステムにいます。私たちが始めたとき、50で良いと思いましたが、75にプッシュしましょう。今は、200にプッシュしようとしています。スケールの目標は、ターゲットを動かしています。それらは修正されていません。すべてのお客様が独自の環境を持っているため、私たちはエコシステムとともに進化する必要があります。多くのノードと多くの時系列を持つノードもありますが、ノードあたりのコンテナ数は少なくなります。
これらのさまざまなカテゴリを理解して分類し、それらの各環境で機能するようにボトルネックを微調整する必要がある場所は、学習プロセスです。私たちはすべての問題を知っていて、すべての修正を終えているとは思えません。このような旅では、解決すべき最大の問題点を特定することにより、適切なものに優先順位を付けることについて細心の注意を払い、冷酷であることは非常に重要です。
ジョージ： Payalが言ったことすべてに同意します。私は、Kubernetesの新しいユーザーに意見の分かれるエクスペリエンスを提供することと、Prometheusのエキスパートであり、すでに知っているものに基づいて構築したいパワーユーザーに非常に詳細なエクスペリエンスを提供することの間のスイートスポットを見つけることが常に重要であることを付け加えます。これら2つの異なる世界を1つにして、両方を満たすことができる製品にする方法を理解する必要があります。彼らは話の反対側にいるように見えるかもしれませんが、実際には、多くのお客様はかなりのスキル要件を持っていると同時に、Kubernetesモニタリングに新しいチームをオンボーディングしています。みんなを幸せにする製品を作ることは、製品マネージャーとして毎日考慮する必要がある非常に難しいポジションです。これらのシナリオに役立つロードマップにいくつかの素晴らしいアイデアがあります。
Payal：現在、すべてのPrometheusメトリクスを取得してバックエンドに送信できるエージェントをノードにインストールしています。エージェントをインストールするだけで完了なので、ユーザーエクスペリエンスの観点からは非常にうまく機能します。ただし、スケーラビリティの観点から、またPaaSのようなエージェントや、サーバーレスアプリケーションをインストールできないプラットフォームの場合は、さらに困難になります。したがって、ここではリモートインジェストの方法を検討しています。つまり、エージェントを使用する代わりに、エージェントをインストールせずに、PrometheusサーバーからSysdigバックエンドに直接メトリクスをプッシュできます。
それに加えて、ノードごとではなく、時系列のボリュームに基づいて、より多くの支払いが行われる請求メカニズムの改善も検討しています。リモートインジェストでは、ノードの境界がないため、1,000万の時系列に支払う場合は、好きなように使用できます。 200万のメトリクスを生成する2つのホストがあり、残りはマイナーです。あなたはそれを行うことになり、あなたはまだあなたの時系列ボリュームにのみ請求されます。
ジョージ：ネタバレを多めにしたくないのですが、私のチームが取り組んでいることは3つのカテゴリに分類されます。Prometheus環境との統合を継続的に改善し、時系列指向の監視に移行し、複数のチームでPrometheusを使用する負担を軽減します。PromCat.ioの場合、サポートされているPrometheus統合を最も人気のあるクラウドネイティブスタックや主要なクラウドサービスプロバイダーが提供するサービスに追加することで、カバレッジの迅速な開発に取り組みます。
おそらくおわかりのように、発表した変更は多大な努力を要しました。私たちはお客様の声に耳を傾け、Sysdig Monitorの次のような拡張機能を開発しました。
私たちがリリースしたこれらの機能の詳細については、オンデマンドのウェビナーを視聴するか、トライアルまたはデモにサインアップしてください。
