左葉坊サービス監視システムの構築と実践

近年、「可観測性」が話題になっています。マイクロサービス アーキテクチャを積極的に採用している企業として、Zuoyebang チームは急速な事業拡大の中で次々と技術的な課題を解決してきました。

最近、51CTOが主催したWOTグローバルテクノロジーイノベーションカンファレンスで、Zuoyebangインフラ部門のシニアアーキテクトであるMo Renpeng氏が「Zuoyebangサービス監視システムの構築と実践」と題する基調講演を行いました。彼は、長年にわたるZuoyebangのクラウドネイティブ構築の実践経験と成果に基づいて、サービス監視システムの構築プロセスにおけるZuoyebangチームの革新的な考え方を共有しました。

この記事では、素晴らしいコンテンツのいくつかを選択し、統一された方法で整理して、皆さんにインスピレーションを与えたいと思います。

サービス監視のトラフィックの課題

ご存知のとおり、サービス監視は近年非常に人気が高まっている「可観測性」という言葉に由来しており、これはサービスの内部状態を外部出力からどの程度推測できるかを指します。

具体的には、「観測可能」は 3 つの部分に分かれています。 1 つ目はログで、主に単一の個別のイベントに関係します。 2 つ目は監視です。これは、時間の経過とともに変化する集約可能な状態です。 3 つ目は Tracing で、これは単一のリクエストの範囲内の情報です。

サービス監視における最大の課題はトラフィックの課題です。現在、Zuoyebang のログデータ量はピーク時に数百 GB/s に達し、毎日のログサイズは約 PB レベル、全体の監視データ量は数千万/s、追跡データ量も数千万程度です。

そのため、高可用性、高拡張性、低コストのサービス監視システムを構築することが不可欠です。

ログシステム

観測システムにおいて、ログ部分は最も接触が多く、最も重要な部分です。目標は4つあります。

• まず、高可用性です。これは、ビジネス サービスの監視、ビジネス データ レポート、ビッグ データ モデルのトレーニングなど、多くの下流ビジネスでは、ログの可用性に対する要件が非常に高く、データが 1 つも失われないことが求められるためです。
• 2番目は、高いスループットです。特に、Zuoyebang の内部シナリオでは、ピーク トラフィックが低ピーク トラフィックの 10 倍以上になる場合があり、十分に高いスループット パフォーマンスが求められます。
• 3番目は、低遅延です。一部のダウンストリーム ログ消費サービスも、レイテンシ要件に敏感です。
• 4番目は、低コストです。ログの数は膨大であり、長期間保存したい場合は、十分に低コストの保存方法を使用する必要があります。

下の図は、Zuoyebang のログ システム全体のアーキテクチャを示しています。

まずはログ出力部分です。 K8s で実行されるサービスはすべてコンテナです。コンテナはまずログをコンテナのログ ファイルに入力し、次に各マシンとノードにログ収集サービスが展開され、各コンテナのログを収集する役割を担います。収集が完了すると、すべてのログが Kafka にアップロードされ、ログの送信は Kafka を介して完了します。

次はログの処理と消費です。これには主に、ログの保存と取得、ログの監視、ログの追跡、ビッグデータが含まれます。

最後に、ストレージ部分では、Zuoyebang は最終的にオブジェクト ストレージ方式を採用しました。

次に、ログの出力、収集、処理、消費、保存の構築プロセスの分析に焦点を当てます。

ログ出力に関しては、Zuoyebang のすべてのサービスは標準出力モードを採用してログを印刷します。古いサービスでは、標準出力の変換を完了するためにログ サイドカー モードが導入されています。主なプロセスはパイプライン ファイルを通じて行われます。サービス コンテナーがパイプライン ファイルにログを書き込み、次にログ サイドカーがパイプライン ファイルからログを読み取って標準出力に出力します。標準出力の利点には、ログ出力方法が統一されていること、サービスがログのライフサイクルを管理する必要がないこと、収集が簡単であること、ログ出力時間がわかっていることなどがあります。

ログ収集に関しては、Zuoyebang は当初 Filebeat を使用していましたが、使いやすさ、安定性、パフォーマンスなどいくつかの問題に遭遇しました。そのため、JSON 解析ロジックの最適化、コンテナ メタデータの取得のオーバーヘッドの削減、コレクション ロジックの軽量化、コレクションの分離の改善など、最適化のために独自に開発したアプローチを採用しました。最終的なパフォーマンスは、シングルコア 75B/S 取得レートをサポートすることです。これにより、単一マシンの取得パフォーマンスが 3 倍になり、全体的な CPU 使用率が 70% 削減されます。

伝送面では、Zuoyebang はメッセージのパッケージ形式を再設計しました。 Kafka に依存するヘッダー モードでは、各種ログのメタデータが Kafka メッセージのヘッダーに配置され、元のログ テキストが本文に保存されます。この方法では、ダウンストリームはログのパッケージ形式を気にする必要がないため、シリアル化とデシリアル化のコストが節約されます。ヘッダーにさまざまなデータ情報を保存すると、下流の各ログが必要なログ情報を抽出するのに役立ちます。

ログ取得に関して、Mo Renpeng は、構造化データの必要性、書き込みパフォーマンスの低さ、運用コストの高さ、ストレージ コストの高さなど、ELK ソリューションがログ取得で頻繁に遭遇するいくつかの問題を紹介することに重点を置きました。次に、非構造化データ、読み取りよりも書き込みが多いシナリオ、クエリのレイテンシの影響を受けないシナリオ、比較的大規模なデータ規模など、ログ取得シナリオの特性を再検討しました。

ここで注目すべきは、ログ取得のための理想的なソリューションには次の特性が備わっている必要があるということです。

• 構造化ストレージのためにログをインデックス化したり、さまざまなログをデシリアル化したりする必要はありません。クエリ操作は全文検索ですが、分散・並列処理により、検索速度はニーズを満たすことができます。
• ログはブロックに保存されます。各ログ ブロックは、ログの種類の集約です。たとえば、一定期間内のポッドのログはログ ブロックに書き込まれます。
• 並列検索により、サービス名、時間、マシン名などのラベルに従ってインデックスが確立されます。クエリ条件を選択することで、第 1 レベルのインデックスは必要なログ ブロックをすばやく表示できます。

これを基に、Zuoyebang は、マイクロサービス シナリオでのログ取得ニーズをより適切に満たすことを目指して、実践可能な新しいソリューションを提案しました。新しいソリューションには次のコンポーネントが含まれています。

• Ingester コンポーネント: 各ログ ブロックの書き込みと、インデックス情報のデータベースへの書き込みを担当します。
• クエリ コンポーネント (クエリ プロキシ コンポーネント): ユーザーのクエリ コマンドを受信し、それをさまざまなクエリ コンポーネントに配布し、最終結果をユーザーに返す役割を担います。
• クエリ コンポーネント: ローカル ストレージ内の各取得コマンドを完了し、結果をプロキシ コンポーネントに返します。
• マネージャー コンポーネント: ローカルに保存されたログ ブロックをオブジェクト ストレージにアップロードしたり、オブジェクト ストレージからローカル ストレージにログ ブロックをダウンロードしたり、期限切れのログ ブロックを削除したりするなど、マシン上のログ ブロックのライフ サイクルを管理します。

ログの保存に関しては、Zuoyebang は階層型保存方式を採用しています。まず、ログ ブロックがローカル ストレージに書き込まれます。一定時間が経過すると、これらのチャンクはポリシーに従ってオブジェクト ストレージにアップロードされ、圧縮された状態で保存されます。オブジェクトストレージは主に長期保存に使用されます。一定期間より古いログ ブロックはアーカイブ ストレージにアーカイブされます。

回収効率を向上させるために、ログ堆積の概念が取り入れられています。過去数時間のログのみを取得する必要がある場合は、ローカル ストレージで直接実行できます。以前のログを照会する必要がある場合は、オブジェクト ストレージまたはアーカイブ ストレージからアーカイブされたログを取得する必要があります。

コスト面では、ローカル ストレージが最も高価ですが、オブジェクト ストレージはローカル ストレージの約 1/3、アーカイブ ストレージはローカル ストレージの 1/10 のコストがかかります。さらに、オブジェクト ストレージとアーカイブ ストレージ内の重要なログは zstd 圧縮モードで保存されるため、ストレージ コストがさらに削減されます。

一般に、ログ取得ソリューションには次のような利点とパフォーマンスがあります。

• 簡単なアクセス: ログ形式に要件はなく、すべてのクラウドネイティブ サービスにデフォルトでアクセスできます。シェル クエリ コマンドをサポートしており、顧客は追加の学習コストを支払う必要がありません。
• 高スループット: ログはデシリアライズも完全なインデックス作成も行われないため、1 つのコアで 50M/s のログ書き込みをサポートできます。
• 低コスト: 階層型ストレージ方式を採用し、zstd 圧縮によりログを保存するため、従来のストレージ方式に比べて 1 ～ 2 桁のコスト削減が可能です。
• 高速: 分散並列検索を使用し、水平拡張をサポートします。 1TB のログを 30 秒以内に取得できます。

監視システム

ここでは、監視を 3 つの主要な部分に分けます。

1 つ目はクラスター監視です。主な内容は次のとおりです。まず、システム監視。主に K8S イベント、K8S コンポーネント、APIServer、Etcd のさまざまな指標が含まれます。 2 番目は、主にポッドとノードのさまざまなリソースの使用を伴うリソース監視です。 3 番目はネットワーク監視で、主にノードとさまざまなネットワーク遅延が関係します。 4 番目は、さまざまな登録検出およびサービス監視コンポーネントを含む基本コンポーネント監視です。 5番目はミドルウェアの監視です。

2つ目はサービス監視です。主に 2 つの部分に分かれたサービス ポッド上のさまざまな指標を監視することが主な目的です。 1 つ目はランタイム監視です。主にさまざまなランタイムとさまざまな言語のインジケーターが含まれます。 2つ目はカスタム監視です。私たちは、企業が Prometheus のメトリック インターフェースを公開し、ビジネス用のカスタム指標を収集および実装できるようにサポートできます。

3つ目はトラフィック監視です。ビジネストラフィックはレイテンシの影響を受けやすく、追跡ポイントを直接設定するのは不便であるため、Zuoyebang は消費ログを通じてトラフィックの方向を均一に監視します。関係する主な指標には、まず、受信トラフィック、つまりリクエスト QPS、リクエストのレイテンシ、成功率、エラー コードの数、その他の指標が含まれます。 2 番目は、送信トラフィックです。主に、データベース、キャッシュ、依存サービス、その他のトラフィックに関するサービスの全体的な監視指標を監視します。 3 番目はゲートウェイ監視で、QPS レイテンシやリクエスト コードの数などの関連監視が含まれます。 4 番目は非同期トラフィック、つまりメッセージ キューです。これには主に、生成/消費 QPS、生成/消費時間、消費遅延などの指標が含まれます。

上記の指標を通じて、リソース層、サービス層だけでなく、プラットフォーム側のさまざまな監視指標を観測し、すべてのサービスの稼働状況を把握することができます。

監視収集に関しては、Prometheus は現在、クラウド ネイティブ監視の分野で事実上の標準となっています。効率的な時系列データストレージを備えており、一度に大量のデータを処理できます。ここでも問題があります。単一のマシンにデプロイされ、クラスター化されたデプロイはサポートされません。データの永続性、あるいは大量の監視データの永続性に関しては、要件を満たさない可能性があります。時系列データベースを導入することでこの問題を解決します。

Prometheus は、リモート書き込みを通じて監視データを時系列データベースに書き込みます。監視データに対するその後のすべての読み取り操作は時系列データベースで実行され、主に Grafana でのさまざまなデータ表示とアラーム、および監視データ用のいくつかの API へのアクセスが含まれます。

監視ストレージに関しては、主に以下の考慮事項に基づいて、時系列データベース ストレージとして Prometheus と Metrics を使用することを選択しました。まず、Prometheus と互換性があります。 Prometheus のさまざまなクエリステートメントをサポートでき、ダウンストリームでも Prometheus として使用できます。第二に、そのアーキテクチャは比較的シンプルなので、さまざまな水平拡張が容易になります。 3 つ目は、データ圧縮率が比較的高く、各ポイントが平均で約 32B を占めることです。 4 番目に、高スループットをサポートし、単一のコアで 6W/S 監視データの書き込みをサポートできます。

VM を使用する場合は、データ容量の問題に注意する必要があります。監視データの保持期間要件は比較的長いため、ストレージ全体がボトルネックになります。これは準備金比率を下げることで解決できます。

実際、ホット監視シナリオとコールド監視シナリオには明確な違いがあります。 R&D 担当者は、1 か月以内に監視データにアクセスすることが最も多く、1 か月を超えて監視データにアクセスすることはほとんどありません。この考え方に基づいて、監視データは標準と準備率削減の間で区別することができます。準備率の引き下げは、もともと10秒ごとに更新されていた監視データポイントが、100秒ごとに1ポイントに変更されることを意味します。

具体的な実装としては、まずPrometheusを介して書き込みが完了します。書き込む前に、プロキシを使用してプロキシを完了します。同時に、プロキシ上で準備率削減操作を実行し、すべての書き込みポイントを比例してサンプリングすることができます。サンプリング前のデータとサンプリング後のデータはそれぞれ異なる VM ストレージに書き込まれます。最後に、Select コンポーネントは、さまざまなリクエストを時間に応じて分割し、異なる VM クラスターに送信し、最終的にそれらを集約してフロントエンド ユーザーに返します。このようにして、1 か月前のデータを標準的な方法で保存し、1 か月後のデータを準備金要件を減らした方法で保存することができます。

このアプローチを実装した後、全体的なストレージ コストが約 80% 削減されたことは特筆に値します。

追跡システム

マイクロサービスの台頭により、単一のリクエストが複数のシステムやサービスにまたがる必要が生じる場合があります。サービスまたはネットワークに遅延が発生すると、リクエスト全体が失敗する可能性があります。そのため、リクエストリンク全体の実行を観察・追跡する方法が必要となり、それがトレースシステムの役割となります。

追跡システムは、主に収集、処理、分析の 3 つの部分に分かれています。

収集部分は、サイドカー、サービス、ログを通じて追跡データを取得します。サイドカーとサービスのデータはエージェントとコレーターを介して Kafka に報告され、ログ データは直接 Kafka に配信されます。処理部分では、Clickhouse をストレージとして使用し、書き込みとクエリ操作をサポートするために Ingester および Query コンポーネントを導入します。分析部分には、サービス トポロジ分析とリクエスト リンク分析が含まれており、追跡データを統計的に集計して集計可能な指標を形成し、Prometheus を使用して時系列データを収集および保存します。

具体的な収集方法は 2 つあります。

サイドカー レポート:サイドカーにポイントを配置して、さまざまなサービスの RPC トラフィックを監視し、エージェントを通じてレポートします。この方法では、サービス境界上のトラフィックしか観察できず、サービス内のトラフィックを深く理解することはできません。この問題を解決するために、サービスレポート方式が導入されました。

サービス レポート: SDK に接続することでサービスをレポートできます。一部のトラフィックやサービスにアクセスしにくい場合は、各種 DB アクセス トラフィック、キャッシュ アクセス トラフィック、非同期トラフィック (メッセージ キュー、生成、消費など) などのログを通じてレポートできます。

データストレージには当初 ElasticSearch を使用していましたが、書き込みパフォーマンスが不十分、データ圧縮率が不十分などの問題が発生し、クラスター全体のコストが高くなっていました。 Clickhouse に切り替えた後、ストレージのパフォーマンスと効率が大幅に向上しました。 1 つのコアで 1.5W/s のディスク書き込みをサポートでき、ストレージ クラスター全体の書き込みパフォーマンスが 40% 向上し、CPU 使用率が 80% 減少し、ディスク使用率が約 50% 減少しました。これにより、全体的なストレージ コストが約 80% 削減され、これは以前のコストの 1/5 になります。

最後に、サービスの追跡と分析について説明します。サービス要求を追跡することで、サービス間の依存関係を取得し、サービス トポロジ マップを構築できます。サービス ディメンションからのこれらの追跡データの統計分析により、リアルタイムのサービス トポロジの表示と要求リンク分析をサポートできます。リクエスト リンク分析では、コア リンク サービスへの呼び出し回数、依存関係の追加、リクエスト リンクに閉じたループがあるかどうかを表示できます。これらの機能により、開発者はサービスの動作状況や潜在的な問題をよりよく理解できるようになります。

要約すると、トレース システムは、収集、処理、分析という 3 つの主要部分を通じて、マイクロサービスにおける問題の特定やボトルネックの検出などの課題を解決します。効率的なストレージとデータ分析方法を導入し、豊富なサービス追跡および分析機能を提供することで、R＆D担当者がサービスの運用状況とパフォーマンスをよりよく理解し、問題をタイムリーに発見して解決するのに役立ちます。

サーバーレス可観測性に関する将来的な考察

サーバーレス サービスの監視の実践において、Zuoyebang は高いスケーラビリティの問題に直面しています。ピーク時のトラフィック量は、閑散期の 10 倍以上になります。運用コストを削減するために、サービスを統合し、サーバーレスで運用することを決定しました。ただし、観測コンポーネントを Serverless 上に直接デプロイするのは簡単ではありません。クラウドベンダーはこの目的のために観測ソリューションを提供していますが、まだいくつかの問題が残っています。

まず、ログに関しては、通常はクラウドベンダーのログコレクターを使用して収集を完了し、Kafka に配信します。さまざまなクラウドベンダーが提供するコレクターの機能は一貫性がなく、十分に包括的ではありません。配信方法とデータのパッケージ化方法を十分にカスタマイズできず、収集のニーズを満たすことができません。

監視するには、CPU やメモリの使用量など、Serverless ポッドのリソース インジケーターに注目する必要があります。これらのリソースは仮想ノード上で公開され、これらのメトリック インターフェースは Prometheus を通じて収集できます。

最後に、追跡に関しては、現在のクラウドベンダーは収集のサポートを提供していないため、サービスとアーキテクチャを適応させる必要があります。

これらの問題を解決するために、Zuoyebang チームはコンテナ インジェクション方式を採用し、Serverless 上のサービス監視問題を統一的に解決しました。 DS オーケストレーションを宣言することにより、クラウド ベンダーは、ログ コンポーネント、ログ監視コンポーネント、トレース収集コンポーネントなどのさまざまな DS オーケストレーションを、Serverless 上で実行されるポッドのコンテナーに挿入します。このアプローチはサイドカー アプローチに似ていますが、オーケストレーションで追加の宣言は必要なく、サービス オーケストレーションはシームレスです。さらに、Zuoyebang チームは独自のコレクション コンポーネントを注入し、独立したアーキテクチャをコンポーネント レベルで複数のクラウド ベンダーに適合させました。また、カスタマイズされた収集戦略をサポートし、エージェントを通じて収集を完了することで、最下層での収集リンクの統一を実現しました。

最後に、パノラマ観測データを取得した後、統一された基準でサービスの品質を評価するサービス評価システムを確立することも必要です。

観測データを用いて統一基準でサービス品質を評価するサービス評価システムを構築し、

開発者はマイクロサービスの「見えない部分」を発見し、管理します。

現在、Homework Helper チームでは、主に次のようなサービス観察指標に基づいてサービス品質指標を確立しています。

• サービス インターフェースの品質には、インターフェースの成功率とインターフェースの応答遅延に注意する必要があります。
• サービス依存関係のステータス。主にリソース要求の成功率、クラウド間の依存関係や循環依存関係があるかどうかなどが含まれます。
• サービス リソースの使用は、主に CPU とメモリの使用率に焦点を当てています。ボトルネックが近づいているか、ボトルネックに到達している場合は、タイムリーな拡張と最適化が必要です。
• パニックの数、パニック/エラー ログの数、さまざまな 5XX ステータス コードの数を含むサービス エラーの数。

これらの指標に基づいてサービス評価レポートを作成し、定期的に研究開発担当者に送信することで、サービスの運用状況や品質を把握するのに役立ちます。その後、問題を最適化し、サービスの安定性とパフォーマンスを向上させることができます。

観察方法は独立していない

最後に、この写真でまとめてみましょう。

ログ記録、監視、トレースはサービスを監視する 3 つの方法ですが、これらは完全に独立しているわけではなく、重複していることに注意することが重要です。データはさまざまな形式とさまざまな観察レベルで整理されています。現時点では、これら 3 つを組み合わせることによってのみ、サービスをより良く、より包括的に、より深く観察することができます。