SRE Capacity Building for Tens of Thousand Node Scale Cloud Services

背景と現状

システムアーキテクチャーの概要

上記の図は、Alibaba Cloud が実際に使用しているシステムアーキテクチャーを示しています。このシステムの主な目的は、リアルタイムデータストリームを計算および保存することです。Alibaba Cloud のコンテナサービス ACK をシステムの基盤として使用し、コンテナのデプロイ、リリース、管理はすべて K8s 標準に準拠しています。独自開発の Gateway サービスをシステムのトラフィックエントリーポイントとして使用し、LoadBalancer タイプの Service に基づいてデプロイしています。

このアーキテクチャーは、K8s をシステムとして活用する一般的な方法でもあります。ACK が提供する CCM コンポーネントを通じて、Service は自動的に基盤となる SLB インスタンスにバインドされ、このインスタンス経由で外部トラフィックを受け持ちます。Gateway は報告されたデータストリームを受信すると、データを Kafka に投入し、Topic 内にデータをバッファリングします。コンシューマーはデータフローの報告を感知すると、Kafka の対応する Topic からデータをさらに計算・処理し、最終結果をストレージメディアに書き込みます。

ストレージメディアには 2 種類あります。Alibaba Cloud ブロックストレージ ESSD は比較的高速ですが、コストが高くなります。File Storage NAS は主にパフォーマンス要件の低いデータを保存するために使用されます。メタデータは ACM によって管理されています。独自開発のコンポーネントである Consumer と Center は、ストレージメディアから計算結果をクエリしてユーザーに返す役割を担っています。

システムステータス

現在、このシステムはグローバルにサービスを提供しており、世界中の約 20 のリージョンにデプロイされています。図からも分かるように、データの読み書きリンクは長く、複数のコンポーネントによる処理が必要です。モニタリング対象も複雑で、インフラストラクチャ (スケジューリング、ストレージ、ネットワークなど)、ミドルウェア (Kafka)、およびビジネスコンポーネント (Gateway、Center、Consumer) が含まれます。

業務内容

・観測可能データの収集

可観測性は主に Metrics、Tracing、Logging の 3 つで構成されます。これら 3 種類のデータはそれぞれ役割を果たしつつ、互いに補完し合っています。

Metrics はシステムに問題があるかどうかを判断する役割を担います。システムのセルフモニタリングシステムの入口でもあります。Metrics の異常アラームや問題トラブルシューティングにより、システムに問題があるかどうか、人の介入が必要かどうかを迅速に判断できます。

Tracing はシステムの問題がどこで発生しているかを特定する役割を担います。コンポーネント間の呼び出し関係、各リクエストの詳細、呼び出しプロセスで問題が発生したコンポーネントなど、具体的な詳細情報を提供できます。

問題のあるコンポーネントを特定した後、最も詳細な問題ログ、すなわち Logging を通じて問題の根本原因を特定する必要があります。

・データの可視化とトラブルシューティング

3 種類のデータを収集した後、次のステップは大画面を通じてデータを視覚的に表示し、一目で問題を判断してトラブルシューティングをより効率的にすることです。

・アラームと緊急対応

問題が確認された後、アラームと緊急処理プロセスを通じて解決する必要があります。

緊急対応プロセスには主に以下のポイントが含まれます。

第一に、階層型のアラーム通知とエスカレーション戦略が必要です。対応担当者に迅速にアラームを処理させる必要があります。同時に、何らかの理由で元の担当者が速やかに対応できない場合は、他の担当者にアラームをエスカレーションして適時に処理する必要もあります。

第二に、問題の認識と処理プロセスを標準化する必要があります。

第三に、事後の統計とレビューです。システム障害が解決された後、事後統計を取り、レビューを実施して、今後同じ問題を回避し、システムをより安定させる必要があります。

第四に、運用処理をツール化し、ホワイトスクリーン化する必要があります。コマンドの手動入力を最小限に抑え、標準処理アクションの一式をツールで固定化する必要があります。

実践経験の共有

観測可能データの収集とアクセス

・Metrics データ

モニタリングの最初のステップは観測可能データを収集することで、システム内で 3 つのレベルに分類できます。

最上位層はアプリケーション層で、主にコアビジネスインターフェイスの健全性に関心を持ち、RED (Rate、Error、Duration) の 3 つのゴールデン指標で測定します。Rate はインターフェイスの QPS または TPS を指し、Error はエラー率またはエラー数を指し、Duration はインターフェイスの応答時間を指します。ゴールデン指標を通じて SLO を定義し、エラーバジェットを割り当てることができます。エラーバジェットがすぐに消費される場合は、システムが十分に最適化されるまで SLO を適時に調整し、その後引き上げる必要があります。Apdex Score を使用してサービスの健全性を測定することもできます。計算式は上図の通りです。さらに、アプリケーション層では、収益、ユーザー数、UV、PV など、ビジネスと強く関連する指標にも注目します。

中間層はミドルウェアとストレージで、主に Kafka クライアントのコンシュームサイト提出状況、プロデューサーバッファーの占有率、バッファーが事前にいっぱいになって新しいメッセージが受信できなくなるリスク、コンシュームの遅延、平均メッセージサイズなどに関心を持ちます。Kafka ブローカー側では、水位、読み書きトラフィック、ディスク使用率などがあり、クラウドディスク ESSD では、マウント成功率、IOPS、ディスク空き領域などがあります。

最下層はインフラストラクチャ層で、注目する指標は複雑です。ECS (K8s ノード) の CPU やメモリレベル、再起動回数、計画内メンテナンスイベント、K8s コアコンポーネントの API Server、etcd、スケジューリング関連の指標、ビジネス Pod の pending 状態、十分なスケジューリング用リソースの有無、OOMKilled イベント、Error イベントなどがあり、VPC/SLB 関連の送信帯域幅や切断数なども含まれます。

ECS ノードをモニタリングするには、node-exporter DaemonSet のデプロイが必要です。K8s クラウドネイティブのコアコンポーネントは、Metrics インターフェイスを通じて指標を公開し、Prometheus が取得できます。Kafka やストレージコンポーネントは Alibaba Cloud のクラウド製品を使用しているため、基本的なモニタリング指標が提供されており、直接アクセスできます。ACK は CSI ストレージプラグインに対しても、マウント成功率、IOPS、スペース使用率など、非常に重要な指標を提供しており、これらもアクセスが必要です。アプリケーション層には Java アプリケーションと Go アプリケーションが含まれます。Java は Micrometer または Spring Boot Actuator を使用してモニタリングを行います。Go アプリケーションは Prometheus の公式 SDK を直接使用して計装を行います。

ACK と K8s のシステムに基づく場合、Metrics プロトコルの最適な選択肢は Prometheus です。オープンソースのセルフビルド Prometheus もクラウドホスティングと同様にアクセスが難しいですが、信頼性と運用コストの面では、クラウドホスティング Prometheus の方がセルフビルド Prometheus よりも優れています。たとえば、ARMS システムを使用すると、クラスター内に非常に軽量なエージェントを直接インストールし、データをフルマネージドのストレージコンポーネントに保存して、それを中心にモニタリング、アラーム、可視化などを行うことができます。プロセス全体が非常に便利で、オープンソースコンポーネントを自ら構築する必要がありません。クラウドホスティングは収集とストレージの能力においても優れています。

Prometheus は ECS ノード、K8s コアコンポーネント、Kafka、ストレージコンポーネントに対してワンクリックアクセスを提供します。

K8s の基本モニタリングとノードステータスへのアクセスは、主に ACK コンポーネント管理センターを通じて行います。関連コンポーネントを簡単にインストールするだけで利用できます。

Kafka のアクセスは主に Prometheus クラウドサービスインスタンスを通じて行います。このインスタンスは Alibaba Cloud の非常に完全な PaaS 階層型クラウド製品と既に接続されています。Kafka にアクセスする際に入力する指標は一般的な指標であり、追加の学習コストは不要です。

クラウドディスク ESSD モニタリングのアクセスは、主に CSI ストレージプラグインを通じて行います。ACK 内の csi-provisioner コンポーネントは非常に有用な可観測性機能を提供します。その情報を使用して、どのディスクがアタッチされていないか、どのディスクがアタッチされているか、アタッチ後に IOPS が要件を満たしていないかを確認し、アラームを設定して、クラウドディスクの異常状況を適時に発見できます。

ARMS Prometheus 経由でアクセスすると、K8s クラスターレベルやノードレベルなどのプリセット収集ジョブの PV ステータスを簡単にモニタリングできます。

アプリケーション層にはワンクリックアクセスの便利な方法はありません。アプリケーションの計装とサービス検出を通じてアプリケーション全体の Metrics インターフェイスを公開し、ARMS Prometheus のプローブ取得を提供する必要があります。

Java アプリケーションでは Micrometer または Spring Boot Actuator を使用して計装を行う必要があります。

たとえば、上図のコードに示すように、Micrometer の多くの JVM 関連情報は数行のコードで簡単に公開でき、プロセスレベルのメモリやスレッド、システム情報など、他の有用な情報にも非常に簡単な方法でアクセスできます。計装ポイントを設定した後、サーバーを内部で起動し、HTTP インターフェイスを通じて Metrics 情報を公開し、最後に指定されたポートをバインドします。これで計装プロセスは完了です。

さらに、ビジネス指標がある場合は、グローバル Prometheus Registry に独自の指標を登録するだけです。

ARMS エージェントは公開されたエンドポイントを抓取し、ServiceMonitor を追加するだけで、コンソールのホワイトスクリーン方式で数行の YAML 定義を簡単に記述するだけで、モニタリング全体の収集、ストレージ、可視化を完了できます。

Go アプリケーションも Java アプリケーションとほぼ同じですが、計装方法が異なり、主に Prometheus の公式 SDK を使用します。

上図は例です。たとえば、システム内に各クエリの時間分布に関心を持つクエリコンポーネントがあるとします。Prometheus のヒストグラム型指標を使用して各リクエストの時間分布を記録し、計装時に一般的に使用される統計を指定できます。その後、ServiceMonitor が Go アプリケーションのエンドポイントを記述し、最後にコンソール上でアプリケーション全体のアクセスを完了します。

ARMS は eBPF に基づく非侵入型の可観測性実装スキームも提供しており、主にコードを変更したくないシナリオに適しています。非侵入型でシステムインターフェイスの RED をモニタリングし、ARMS Cmonitor エージェントと eBPF を通じて情報の取得と保存を実現し、システムカーネルのフィルターを通じて処理します。

上記の方法を使用するには、クラスター内に Cmonitor App をインストールする必要があります。インストール後、Daemonset 内の Cmonitor Agent を確認できます。各ノードで Cmonitor Agent を起動する必要があり、eBPF を通じてシステムカーネルに登録し、マシン全体のネットワークトラフィックを取得してから、必要なサービスネットワークのトポロジーやその他の情報をフィルタリングします。上図に示すように、システム全体の QPS、応答時間分布などの情報をモニタリングできます。

・Trace および Log データ

Trace も Cmonitor を使用して関連機能を実装します。ログに関しては、システムコンポーネント、K8s コントロールプレーン、JVM DCLog のログは、主に ARMS Promtail (アプリケーションログ収集用プローブ) を通じて Loki に長期保存されます。

K8s システムイベントのログは、主に ARMS イベントセンターの機能に基づいて、K8s の重要イベント、Pod スケジューリング上の OOM、Error などのイベントをモニタリングします。

・読み書きリンクのモニタリングと問題の特定

たとえば、Trace 関連のコンソールでは、各リクエストが通過するコンポーネント、受信時間、処理時間、応答時間などの標準情報を確認できます。

・コンポーネント運用ログの収集と保存

ログ収集に関しては、Grafana で Loki のデータソースを設定することで、キーワードや Pod タグに基づいて Pod やサービスにアタッチされた Pod ログを簡単に迅速に取得でき、トラブルシューティングに大きな利便性を提供します。

・K8s 運用イベントの収集とモニタリング

上図は ARMS が提供するイベントセンターワークベンチのスクリーンショットです。このワークベンチは重要イベントのリストを提供し、より高いレベルのイベントをサブスクライブできます。サブスクリプションは簡単なステップだけで完了します。基本ルールを入力し、イベントにマッチするモードを選択し、アラーム送信対象を選択するだけで、重要イベントをモニタリングし、即時対応の目的を達成できます。

データの可視化とトラブルシューティング

・Grafana 大画面設定の実践

データ収集後、次のステップは効率的で利用しやすいデータの可視化とトラブルシューティングツールを構築することです。

Prometheus と Grafana はゴールデンパートナーであるため、データ可視化のツールとして Grafana を選択しました。上図は大画面設定プロセスにおけるポイントを列挙しています。

・大画面をロードする際は、各パネルのクエリタイムラインを制御し、フロントエンドにタイムラインを多く表示しすぎてブラウザのレンダリング負荷が高くなるのを避ける必要があります。さらに、トラブルシューティングにおいて、一度に多数のタイムラインを表示することは有用ではありません。

・大画面には多くの柔軟な変数が設定されており、1 つの大画面上でさまざまなデータソースやクエリ条件を自由に切り替えることができます。

・Transform を使用して Table Panel で統計を柔軟に表示します。

・Range と Instant のクエリスイッチを区別し、不要な範囲クエリで大画面の表示速度が低下するのを避けます。

K8s クラスターの概要

上図は K8s クラスターのモニタリングノード情報と Pod 情報を示しています。全体的なレイアウトは一目で明確です。重要な情報は異なる色でマークされ、Grafana の動的しきい値機能を通じて数値が異なる形式で表示され、トラブルシューティングの効率を向上させます。

ノード水位

上図はノード水位チャートで、ディスク IOPS、読み書き時間、ネットワークトラフィック、メモリ使用量、CPU 使用率などの重要情報を示しています。

グローバル SLO

上図はグローバル SLO ダッシュボードを示しています。Grafana ホスティングサービスを通じてカスタマイズされた大画面を設定します。これは ARMS の最新のオンライン機能でもあります。クラウド上で Grafana インスタンスをホスティングし、クラウドアカウントを通じて Grafana インターフェイスに直接ログインでき、Alibaba Cloud によるカスタマイズ機能が組み込まれています。

このダッシュボードには、グローバルなレイテンシ、QPS、成功率、エラーコード分布、QPS 変化傾向、および単一シャーディング、負荷分散、Gateway コンポーネント、Center コンポーネントなどの細かい情報が含まれます。リリース時には、バージョン番号を付与することで前のバージョンとの差分を確認できます。データソースを変数形式で Panel に表示でき、世界中の異なるリージョンを選択して切り替えて表示することもできます。

Kafka クライアントとサーバーのモニタリング

クラスターは Kafka クライアントとサーバーに依存しており、そのモニタリングはクラウドモニタリング統合に由来します。

内部コンポーネントは Kafka に強く依存しています。指標を通じて Kafka との間の接続数、ブローカーとの接続数、平均メッセージ長、サイト提出率、コンシュームのフローをモニタリングします。プロデューサー側はバッファー占有率やアクティブなプロデューサー数などの情報を提供します。

Java アプリケーション運用モニタリング

コンポーネントが Java で記述されている場合、JVM 関連の GC 状況もモニタリングする必要があります。大画面は JVM メモリ、GC 関連の状況、CPU 使用率、スレッド数、スレッドステータスなどを提供できます。さらに、リリースまたは動的にロードされるクラスについては、ロードされたクラスの統計に継続的な上昇状態がないかを確認できます。

表形式のエラータイプ重複統計

スプレッドシートを使用してクラスター内のコンポーネントのインストール状況や重要顧客の状況を追跡する場合は、Grafana の Transform 機能を使用してダッシュボード全体をスプレッドシート形式の体験に構築できます。Transform を使用してフィールドをスプレッドシートにマップできます。フィルターを有効にした後、さまざまなフィールドをフィルタリングしてクエリ結果を取得することもできます。

・トラブルシューティング事例の共有

ログ情報の表示には、Grafana で Loki のデータをクエリする必要があります。たとえば、Center にクエリログがあり、このクエリの時刻や UID など、多くの元の情報が含まれています。後処理を通じて、まず行単位で目的のログをフィルタリングし、次にパターンマッチングで情報を抽出し、PromQL に基づいて一部のフィールドの大小関係をマッチングし、最後にマッチしたログ形式に二次処理を施します。

アラームと階層型対応メカニズム

上図はアラームと階層型対応メカニズムのフローを示しています。このフローにはアラーム設定、人員配置、アラームトリガー、緊急対応、事後レビュー、メカニズムの最適化が順に含まれています。最後に、メカニズムの最適化はアラーム設定に反映され、完全なクローズドループを形成します。

上記のプロセスは独自構築のアラームシステムです。独自システムに依存して定期的にタスクを実行し指標をチェックし、DingTalk の Webhook や他の運用システムの Webhook を呼び出してアラームを送信しますが、このプロセスにはいくつかの不足点があります。

1. 独自システムの安定性は自ら責任を持つ必要があります。アラームシステムの安定性が運用対象システムの安定性よりも低い場合、アラームシステムの存在意義がなくなります。次に、クラスター全体のリージョン数が増加するにつれて、設定はますます複雑になります。設定を維持し、グローバルに設定が有効であることを保証することは困難です。

2. 手動スケジューリングに依存しているため、スケジュール漏れやバックアップ不足が発生しやすくなります。

3. アラームトリガー段階のトリガー条件は非常に単純で、アラームトリガーリンクに動的しきい値や動的タグ付けなどの追加ビジネスロジックを追加することは困難です。

4. 緊急処理段階では、情報が非常に頻繁に送信され、対応表明やアクティブなクローズができません。システムに問題が発生した際、同じ種類のアラームがグループ内に高密度で送信され、アラームをアクティブに抑制できないことも欠点の一つです。

5. 事後回復最適化中にデータサポートがなく、既存のアラーム統計に基づいてプロセス全体を最適化できません。

したがって、ARMS をベースにしたアラームシステムを構築することを選択しました。ARMS の強力なアラームと階層型対応メカニズムにより、多くの利便性がもたらされました。

1. アラームテンプレートのグローバル検証機能：一度アラームルールを設定するだけで、異なるクラスターでアラームルールを有効化できます。たとえば、アラームテンプレートがない場合、各クラスターの指標に対して個別にアラームを設定する必要があります。テンプレートがあれば、アラームの PromQL または AlertRule をアラームルールテンプレートを通じて世界中の各リージョンクラスターに適用でき、非常に便利です。

2. アラームスケジューリングと動的な通知：システムはシフト勤務を動的に実現でき、手動スケジューリングよりも信頼性が高くなります。

3. イベント処理フローとアラームエンリッチメント：ARMS のイベント処理フロー、アラームセンターのイベント処理フロー、アラームエンリッチメント機能を使用して、アラームトリガー後に動的にタグ付けし、階層別処理を行うことができます。上図に示すように、アラームに優先度ラベルを付け、優先度の高いアラームを P1 にエスカレーションし、アラーム受信者を動的に変更できます。

上記の機能を実現するには、タグ付けの根拠を提供するデータソースが必要です。アラーム運用センターのコンソールにはデータソース機能があります。アラームがトリガーされると、HTTP リクエストまたは RPC リクエストを通じてデータソースを呼び出し、HTTP URL からタグ付け結果を取得できます。このインターフェイスの実装は主に IFC ライトウェイトツールを通じてコードをオンラインで記述します。コードは主に ACM 設定センターの情報設定項目を読み取り、設定項目を読み取って HTTP インターフェイスを外部に公開し、アラーム運用センターに動的呼び出しを提供します。

上記の手順を完了した後、イベント処理フローを設定し、マッチング更新モードを通じて必要な情報を上記のインターフェイスに転送し、優先度を返し、最後にアラームを出力する必要があります。

4. アラームの対応表明、クローズ、抑制：ARMS は対応表明、クローズ、フォーカス、抑制などの実用的な機能を提供し、アラームの品質を大幅に向上させます。

5. アラーム対応表明と対応率の統計：アラームが回復した際、各人が処理したアラーム数、処理時間、アラームの平均回復時間などを知る必要があります。対応表明、クローズ、回復、抑制のメカニズムを導入した後、ARMS アラームセンターはバックグラウンドでイベントログを記録し、ログの分析を通じて有用な回復情報を提供できます。

アラーム情報を取得した後、ユーザーはホワイトスクリーンインターフェース上で問題に対処したいと考えるため、Grafana ベースのホワイトスクリーン運用ツールチェーンを導入しました。その原理は、大画面設定時に動的情報を導入し、リンク形式で大画面に結合することです。

さまざまな内部システムがあります。公式なリンク結合がない場合、まず URL を組み立てるか手動で検索する必要があり、非常に非効率的です。Grafana にリンクを埋め込むことで、運用アクションはリンク間の遷移として固定化され、効率の向上に非常に役立ちます。Grafana の一連のツールを通じてすべての作業を完了でき、運用アクションを標準化・固定化し、人的ミスの可能性を低減できます。

まとめと今後の課題

第一に、アラーム精度と対応率の最適化です。現在、アラームの重複情報を有効に活用する良い方法がありません。今後はアラーム精度と対応率の情報を通じて不適切なアラームしきい値を適時に調整し、多段階アラームも試みる予定です。たとえば、A から B の範囲では何レベル、B 以上では何レベルといった具合です。

第二に、マルチタイプデータ連携です。たとえば、問題のトラブルシューティング時に、Metrics、Trace、Log のほか、Profiler、CPU のフレームチャートなどの情報もあります。現在、これらの情報と観測可能データとの連携は低くなっています。データ連携の向上はトラブルシューティングの効率を改善できます。

第三に、計装ポイントのコスト管理です。外部顧客にとって、計装コストは Alibaba Cloud の利用コストに直接関係します。自己監視指標や拡散ディメンションなどの観点から定期的かつ重点的なガバナンスを実施し、不要なディメンションをクリーンアップすることで、計装コストを低いレベルに抑えます。