GitOpsで数千のエッジKubernetesクラスターを管理

F5

VolterraのSREチームは、グローバルなSaaSベースのエッジプラットフォームを運用しています。オンライン、オフライン、管理者による停止など、さまざまな状態にある多数のアプリケーションクラスターを管理するうえでの多様な課題に対し、Kubernetesのエコシステムとツールを活用し、GitOpsによる宣言型のプルベースモデルを用いて対応しています。

このブログでは、以下について説明します。

GitOpsを使用して、大規模なインフラストラクチャ群（物理ホストまたはクラウドホスト）とK8sクラスターを効率的に管理・監視する方法

1. CI/CDに関する課題を解決するために構築したツール
2. オブジェクトのオーケストレーションと構成管理
3. InfraおよびK8sクラスター群全体のオブザーバビリティ

大規模環境（3,000のエッジサイト）で得られた教訓について、さらに掘り下げます。この内容は、先日サンディエゴで開催されたCloud Native Rejektsでの講演でも取り上げました。

要約

1. パブリッククラウド、オンプレミス、または移動型の拠点にまたがる数千（将来的には数百万）のアプリケーションクラスターとインフラストラクチャクラスターをデプロイし、運用できる、シンプルですぐに使えるソリューションは見つかりませんでした。
   
2. このソリューションには、ホスト（物理またはクラウド）、Kubernetesコントロールプレーン、アプリケーションワークロードのライフサイクル管理に加え、各種サービスの継続的な構成管理を行う機能が必要でした。また、宣言的定義、イミュータブルなライフサイクル、GitOps、クラスターへの直接アクセスの禁止という、F5のSRE設計要件を満たす必要もありました。
   
3. Kubespray+Ansible（Kubernetesのデプロイ向け）やHelm/Spinnaker（ワークロード管理向け）など、さまざまなオープンソースプロジェクトを評価した結果、いずれのソリューションも、各エッジサイトでソフトウェアが大幅に肥大化することなく、前述の要件を満たすことはできないと判断しました。そこで、ホスト（物理またはクラウド）、Kubernetesコントロールプレーン、アプリケーションワークロードのライフサイクル管理を行う、Golangベースの独自ソフトウェアデーモンを構築することにしました。
   
4. 単一テナント内でシステムを3,000クラスター以上に拡張するにつれ、パブリッククラウドプロバイダー、ソフトウェアデーモンのスケーラビリティ、運用ツール、オブザーバビリティインフラストラクチャに関する前提が次々と成り立たなくなりました。これらの課題を克服するには、それぞれについて一部のソフトウェアコンポーネントを再設計する必要がありました。

エッジの定義

• Customer Edge（CE）— クラウド（AWS、Azure、GCP、プライベートクラウドなど）上のお客さま拠点、オンプレミス拠点（工場の製造現場、石油・ガス施設など）、または移動型拠点（自動車、ロボティクスなど）を指します。CEはVolterra SREチームが管理しますが、お客さまが選択した場所にオンデマンドで導入することもできます。
• Regional Edges（RE） — 主要都市圏のコロケーション施設に設置されたVolterraのポイントオブプレゼンス（PoP）であり、高度にメッシュ化された独自のプライベートバックボーンで相互接続されています。これらのリージョナルエッジサイトは、Customer Edge（CE）ロケーション間のセキュアな相互接続や、アプリケーションサービスのパブリックインターネットへの公開にも使用されます。REサイトは、Volterraのインフラストラクチャ運用（Infra SRE）チームが全面的に管理・所有しています。

図1：システム概要

上のアーキテクチャ図（図1）は、REとCE間の論理接続を示しています。各CEは、最も近いREへの冗長接続（IPSecまたはSSL VPN）を確立します。

エッジ管理の要件

約2年前にプラットフォームの設計を開始した際、製品チームから次の課題への対応を求められました。

1. システムのスケーラビリティ — お客さまからは、数千、将来的には数百万に及ぶカスタマーエッジサイトへの対応が求められていました。これは、クラウドリージョンで少数のKubernetesクラスターを運用する場合とは大きく異なります。たとえば、あるお客さまは約17,000店舗のコンビニエンスストアを展開し、別のお客さまは20,000か所を超える充電ステーションを運営しています。この規模に対応するには、少数のクラスターを扱う場合とはまったく異なる方法でツールを構築する必要がありました。
2. ゼロタッチデプロイ — ハードウェア、ソフトウェア、Kubernetesに関する詳しい知識がなくても、誰でも新しいサイトをデプロイできる必要があったためです。エッジサイトには、電源を入れると管理システムに接続し、オンラインになるブラックボックスのような動作が求められました。
3. フリート管理 — 数千のサイトとワークロードを個別に扱うことなく、管理を簡素化します。変更やアップグレードを要求した時点で、サイトがオフラインまたは利用できない状態になっている可能性があります。そのため、サイトはオンラインになった時点で更新を取得する必要があります。
4. 耐障害性 — エッジサイトは、いずれかのコンポーネントに障害が発生した後も稼働を継続する必要があります。すべてをリモートで管理でき、障害発生時には工場出荷時設定へのリセットやサイトの再構築などの機能を利用できる必要があります。また、サイトには物理的にアクセスできないことを前提とする必要がありました。

設計原則（Kubectl不要！Ansible不要！パッケージ不要！）

要件と高度に分散したシステムの運用上の課題を踏まえ、後工程での問題を減らすためにSREチームが従うべき原則をいくつか定めました。

1. 宣言的な定義 — システム全体を宣言的に記述する必要があります。これにより、シンプルな抽象化モデルを作成し、そのモデルに照らして検証できます。
   
2. イミュータブルなライフサイクル管理 — 以前は、Ansible、Salt、Puppetなどの変更可能なLCMツールを使用して、大規模なプライベートクラウド環境の構築に取り組んでいました。今回は、ベースOSを極力シンプルに保ち、パッケージ管理や構成管理ツールを必要とせず、すべてをコンテナとして提供することを目指しました。
   
3. GitOps — Kubernetesクラスターを管理するための標準的な運用モデルを提供します。また、追加のワークフロー管理システムを構築することなく、変更の承認、監査、ワークフローをすぐに利用できるようになります。そのため、すべての変更をgit経由で行うことにしました。
   
4. kubectlの使用禁止 — アプリケーションクラスターへの直接アクセスは誰にも許可されていないため、これは最も重要な原則の1つでした。そのため、個々のエッジクラスター内でkubectlを実行する機能や、集中型CDシステムを含む中央環境からスクリプトを実行する機能を廃止しました。プッシュ方式の集中型CDシステムは数十のクラスターには適していますが、ネットワークの可用性が100%保証されない限り、数千のクラスターには明らかに適していません。
   
5. 話題先行のテクノロジー（またはツール）は使わない — これまでの経験から、人気のあるオープンソースツールの多くは、評判ほどの成果を上げられないことが分かっています。インフラストラクチャ、K8s、アプリケーションワークロードのデリバリーに向けて、Helm、Spinnaker、Terraformなど複数のコミュニティプロジェクトを評価しましたが、最終的に仮想インフラストラクチャ部分にはTerraformのみを使用し、カスタムコードを開発しました。このコードについては、本ブログの後続記事で説明します。

サイトのライフサイクル管理

エッジサイトのライフサイクル管理では、ホストOSのプロビジョニング、基本設定（ユーザー管理、認証局、HugePagesなど）、K8sの起動、ワークロードのデプロイ、継続的な設定変更の管理をどのように行うかという課題を解決する必要がありました。

検討したものの最終的に採用を見送った選択肢の1つが、OSの管理とK8sのデプロイにKubeSpray+Ansibleを、ワークロードのデプロイにHelm/Spinnakerを使用する方法でした。採用を見送った理由は、2～3個のオープンソースツールを管理したうえで、要件を満たすために大幅な変更を加える必要があったためです。さらに、エッジクラスターの自動スケーリング、セキュアTPMモジュールのサポート、差分アップグレードなどの機能を追加するにつれて、要件は増え続けていました。

シンプルな構成を維持し、OS上（Kubernetes外）で直接実行するコンポーネントの数を最小限に抑えるため、Volterra Platform Manager（VPM）という軽量なGolangデーモンを開発することにしました。これはOS内で唯一のsystemd Dockerコンテナであり、多くの機能を担う万能ツールとして動作します。

ホストのライフサイクル

VPMは、インストール、アップグレード、パッチ適用、構成など、ホストオペレーティングシステムのライフサイクル管理を担います。hugepagesの割り当てや/etc/hostsなど、構成が必要な項目は多岐にわたります。

1. OSアップグレード管理 — 残念ながら、エッジで管理すべき対象はKubernetesだけではありません。カーネルやOS全般のバージョンも管理する必要があります。F5のエッジは、アクティブパーティションとパッシブパーティションを備えたCoreOS（お客さまのニーズに応じてCentOS）をベースとしています。アップグレードがスケジュールされると、更新は必ずパッシブパーティションにダウンロードされます。更新の最終ステップで再起動し、アクティブパーティションとパッシブパーティションを入れ替えます。注意が必要なのは、すべてのノードを同時に再起動できないため、マルチノードクラスターの再起動方法です。そこでVPMに独自のetcd再起動ロックを実装し、クラスター内のノードを1台ずつ再起動するようにしました。
2. OSへのユーザーアクセス管理 — ユーザーを制限し、sshおよびコンソールへのリモートアクセスを制御する必要があります。VPMは、ssh CAのローテーションなど、これらの操作をすべて実行します。
3. 独自のL3-L7データパスを開発したため、ハードウェア（またはクラウドVM）の種類に応じて、ホストOSで2Mまたは1GのHuge Pageを構成する必要があります

Kubernetesのライフサイクル

Kubernetesマニフェストのライフサイクルを管理します。Helmの代わりにK8s client-goライブラリを採用し、VPMに統合して、同ライブラリの複数の機能を使用しました。

1. 楽観的デプロイと悲観的デプロイ — この機能を使用すると、正常な状態になるまで待機する必要があるアプリケーションを分類できます。K8sマニフェスト内の次のアノテーションを監視するだけです： ves.io/deploy: optimistic。楽観的 = リソースを作成し、ステータスを待機しません。これは、 kubernetes apply コマンドとよく似ており、実際のPodが正常に起動したかどうかは確認できません。悲観的 = Kubernetesリソースの状態を待機します。たとえば、デプロイでは、すべてのPodが準備完了になるまで待機します。これは、新しい kubectl wait コマンドと同様です。
2. 事前プルなどの更新前アクション — 特にネットワークデータプレーンをデプロイする場合、K8sのローリングアップデートに依存できないことがあります。これは、古いPodが破棄された後に、新しいPodのイメージがプルされるためです。しかし、データプレーンの場合はネットワーク接続が失われます。そのため、新しいコンテナイメージをプルできず、Podが起動しません。イメージのリストを指定したメタデータアノテーションves.io/prepullにより、K8sマニフェストが適用される前にプルアクションが実行されます。
3. 再試行とロールバック：適用に失敗した場合に実行します。K8s APIサーバーで断続的な停止が発生している場合によく見られる状況です。

継続的な構成管理

K8sマニフェストに関連する設定に加えて、各種VolterraサービスもAPI経由で設定する必要があります。たとえばIPsec/SSL VPNの設定では、VPMがグローバルコントロールプレーンから設定を受信し、個々のノードに適用します。

工場出荷時設定へのリセット

この機能を使用すると、ボックスをリモートで工場出荷時の状態にリセットし、インストールと登録のプロセス全体を再実行できます。コンソールまたは物理的なアクセスが必要なサイトを復旧するうえで、極めて重要な機能です。

K8sのライフサイクル管理は多くの方にとって大きな議論のテーマに見えるかもしれませんが、私たちのチームでは、作業量全体の40～50%程度にすぎないと考えられます。

ゼロタッチプロビジョニング

あらゆる場所（クラウド、オンプレミス、移動型エッジ）にあるエッジサイトをゼロタッチでプロビジョニングできることは、極めて重要です。個々のサイトにアクセスできるとは限らず、各サイトのインストールと管理のために多数のKubernetesエキスパートを配置することも現実的ではありません。この方法では、数千規模のサイトに対応できません。

次の図（図2）は、新しいサイトの登録プロセスにVPMがどのように関与するかを示しています。

図2 — ゼロタッチプロビジョニングのフロー

1. 電源を投入すると、CE上で稼働するVPM（緑色のボックスで表示）がグローバルコントロールプレーン（GC）に登録トークンを提示し、新規登録を作成します。登録トークンはクラウドVMのcloud-initの一部として提供され、起動プロセス中に人が入力するキー、またはエッジハードウェアのTPMにプログラムされたキーを使用できます。
2. GCはトークンを含むリクエストを受信し、そのトークンにエンコードされたテナントの下に新しい登録を作成します。お客さまのオペレーターは、新しいエッジサイトをすぐにマップ上で確認し、名前やその他の構成パラメーターを入力して承認できます。
3. GC内のVP-Controllerは、構成（K8sのマスターやミニオンなどの決定）と、etcd、K8s、VPM用の証明書を生成します。
4. VPMは、Dockerイメージのダウンロード、HugePagesの構成、K8sクラスターのインストール、Volterraコントロールプレーンサービスの起動など、サイトのブートストラップを開始します。
5. VPMは、最寄りの2つのRegional Edgeサイトへの冗長トンネル（IPSec/SSL VPN）を構成します。これらのトンネルは、データトラフィック、およびサイト間やパブリックネットワークとの相互接続に使用されます。

このように、プロセス全体が完全に自動化されているため、ユーザーは詳細な設定を把握したり、手動で操作したりする必要はありません。デバイス全体がオンラインになり、お客さまのアプリケーションとリクエストを処理できる状態になるまで、約5分です。

インフラストラクチャソフトウェアのアップグレード

アップグレードは、解決すべき最も複雑な課題の1つでした。ここでは、エッジサイトで何がアップグレードされるのかを定義します。

• オペレーティングシステムのアップグレード— カーネルとすべてのシステムパッケージが対象です。標準的なLinux OSディストリビューションを運用した経験があれば、マイナーバージョン間のアップグレード（Ubuntu 16.04.xから16.04.yへの移行など）がいかに大変か、またメジャーバージョン間のアップグレード（Ubuntu 16.04から18.04への移行など）がそれ以上に困難であることをご存じでしょう。数千のサイトを運用する場合、アップグレードは決定論的でなければならず、サイトごとに異なる動作をしてはなりません。そのため、2つのパーティションと各パスの読み取り専用ファイルシステムを使用したA/Bアップグレードに対応するCoreOSとCentOS Atomicを採用しました。これにより、パーティションの起動順序を切り替えて即座に元の状態へ戻せるほか、OSパッケージを個別に管理することなくOSの一貫性を維持できます。ただし、opensshサーバーなど、システム内の個々のコンポーネントを新しいパッケージのインストールだけでアップグレードすることはできなくなります。個々のコンポーネントへの変更は、新しいイミュータブルOSバージョンとしてリリースする必要があります。
  
• ソフトウェアのアップグレード — 対象となるのは、VPM、etcd、Kubernetes、およびK8sワークロードとして実行されるVolterra制御サービスです。前述のとおり、K8s内のすべてをsystemdコンテナとして実行することが目標です。幸い、VPM、etcd、kubeletの3つのサービスを除き、すべてをK8sワークロードに移行できました。

エッジサイトにアップデートを配信する方法として、次の2つが知られています。

1. プッシュベース — プッシュ方式は通常、Spinnaker、Jenkins、AnsibleベースのCMなど、一元管理されたCD（継続的デリバリー）ツールを使用して実行します。この場合、中央のツールが対象のサイトまたはクラスターにアクセスでき、処理を実行できる状態である必要があります。
2. プルベース — プルベース方式では、一元化されたデリバリーメカニズムを使用せず、アップグレード情報を個別に取得します。スケーラビリティに優れ、すべてのサイトの認証情報を1か所に保存する必要もありません。

アップグレードでは、一般的な携帯電話のアップグレードと同様に、シンプルさと信頼性を最大限に高めることを目指しました。さらに、アップグレード戦略では、アップグレードを実行できるのがサイトのオペレーターに限られる場合や、接続の問題によりデバイスが一定期間オフラインまたは利用できなくなる場合なども考慮する必要がありました。こうした要件にはプル方式の方が容易に対応できるため、ニーズに合った方式として採用しました。

GitOps

さらに、SREチームがKubernetesクラスターやワークフローを管理し、変更を監査するための標準的な運用モデルを導入しやすくなることから、GitOpsを採用しました。

数千のサイトに伴うスケーリングの課題を解決するため、図3に示すSRE向けアーキテクチャを考案しました。

図3 — GitOpsフロー

まず強調したいのは、Gitを単に状態やマニフェストの保存に使用しているわけではないという点です。これは、当社のプラットフォームがK8sマニフェストだけでなく、継続的に更新されるAPI設定やK8sのバージョンなども扱う必要があるためです。当社の場合、K8sマニフェストが宣言型設定全体に占める割合は約60%です。そのため、その上位レイヤーに独自のDSL抽象化を構築し、gitに保存する必要がありました。また、gitにはAPIもパラメーターをマージする機能もないため、SRE向けにConfig API、Executor、VP ControllerというGolangデーモンを追加で開発する必要がありました。

SaaSプラットフォームを使用して、カスタマーエッジに新しいソフトウェアバージョンをリリースするワークフローを見ていきましょう。

1. オペレーターは新バージョンのリリースを決定し、gitモデルに対するマージリクエスト（MR）を作成します
   
2. このMRが承認されてマージされると、CIによってgitモデルの設定をSRE Config-APIデーモンに読み込む処理がトリガーされます。このデーモンには、パラメーターのマージや内部DNSの設定などを行う複数のAPIがあります。
   
3. Config-APIはExecutorデーモンによって監視されており、gitの変更が読み込まれるとすぐに、アノテーションにバージョンを含む最終的なK8sマニフェストのレンダリングを開始します。これらのマニフェストはその後、次のパスでArtifactストレージ（S3相当）にアップロードされます。ce01-site//.yml
   
4. 新しいバージョンのレンダリングが完了し、アーティファクトストレージにアップロードされると、Executorは利用可能なバージョンを示す新しいステータスをカスタマーAPIに出力します。これは、携帯電話で新しいバージョンが利用可能になったときの状態とよく似ています。
   
5. お客さま（またはオペレーター）は、サイトを最新バージョンに更新するスケジュールを設定できます。この情報はVP-Controllerに渡されます。VP-Controllerは、プロビジョニング、廃止、別の場所への移行など、サイト管理を担うデーモンです。これについてはゼロタッチプロビジョニングですでに一部説明しており、mTLS APIを介したエッジサイトの更新を担います。
   
6. 図の最後のステップはエッジサイトで実行されます。IPSec/SSL VPN接続が確立されると、VP-ControllerはエッジのVPMに通知し、新しいバージョンのアップデートをダウンロードさせます。ただし、接続が切断されている場合や断続的に問題が発生している場合、VPMは5分ごとにアップデートの有無をポーリングします。
   
7. 新しいK8sマニフェストと構成が取得され、K8sにデプロイされます。前のセクションで説明した悲観的デプロイ機能を使用し、VPMはすべてのPodが準備完了になるまで待機します
   
8. 最後のステップとして、VPMはアップグレードのステータスをVP Controllerに返し、そのステータスがカスタマーAPIにプッシュされます。

ワークフロー全体のデモはこちらでご覧いただけます：

3,000のエッジサイトでのテストから得られた知見

前のセクションでは、エッジサイトのデプロイとライフサイクル管理にツールをどのように使用するかを説明しました。設計を検証するため、3,000か所のお客さまのエッジサイトで構成される大規模環境を構築しました（図4を参照）。

図4 — 3,000のカスタマーエッジサイト

大規模環境をシミュレートするため、Terraformを使用して、AWS、Azure、Google、および自社のオンプレミスベアメタルクラウド全体に3,000台のVMをプロビジョニングしました。これらのVMはすべて独立したCE（カスタマーエッジサイト）として、F5のリージョナルエッジサイト（別名PoP）への冗長トンネルを確立しました。

以下のスクリーンショットはSREダッシュボードのもので、各ロケーションのエッジサイト数を円の大きさで示しています。スクリーンショットの撮影時点では、正常なエッジサイトが約2,711か所、異常なエッジサイトが356か所ありました。

図5：3,000のカスタマーエッジサイトの展開

主な調査結果：運用

スケーリングを進める中で、構成面と運用面にいくつかの問題が見つかり、ソフトウェアデーモンの修正が必要になりました。また、クラウドプロバイダーに関して、APIの応答遅延や単一リージョンで500台を超えるVMを確保できないことなど、多くの問題が発生し、複数のサポートチケットを起票しました。

1. VP-Controllerの最適化 — 当初は登録を逐次処理しており、etcd、kubernetes、VPM用の各種証明書を発行する必要があったため、1件あたり約2分かかっていました。そこで、より高いエントロピーを使用して鍵を事前生成し、ワーカー数を増やして並列処理することで、処理時間を短縮しました。その結果、100サイトの登録を20秒未満で処理できるようになりました。また、VP-Controllerでは、約1 vCPUと2 GBのRAMを使用するだけで、3,000のエッジサイトすべてに対応できました。
   
2. Dockerイメージ配信の最適化 — スケーリングを開始した際、エッジサイト向けのデータ転送量が膨大になることが判明しました。各エッジで約600 MBをダウンロードするため、3,000拠点では合計1.8 TBのデータが転送されます。また、テスト中にエッジサイトを数回再構築していたため、実際の転送量はさらに多くなります。そのため、Dockerイメージのサイズを最適化し、ダウンロード量を削減するために、Dockerイメージを事前にプルしたクラウドイメージとISOイメージを作成する必要がありました。現在もパブリッククラウドのコンテナレジストリサービスを使用していますが、RE（PoP）を介してコンテナレジストリを分散し、増分（バイナリ差分）アップグレードを実行するための設計に積極的に取り組んでいます。
   
3. グローバル制御データベースの運用を最適化 — Volterraのすべての制御サービスは、ETCDをデータベースとして使用するGolangサービスフレームワークを基盤としています。各サイトは構成オブジェクトとして表されます。各サイト構成オブジェクトには、software-upgrade、hardware-info、ipsec-statusなど、複数のStatusObjectsがあります。これらのStatusObjectsはさまざまなプラットフォームコンポーネントによって生成され、すべてグローバル構成APIから参照されます。サイト数が3,000に達した時点で、オブジェクトスキーマにいくつかの最適化を施す必要がありました。たとえば、グローバル構成APIが受け付けるStatusObjectsのタイプ数を制限したほか、構成オブジェクトDBの過負荷リスクを軽減するため、StatusObjectsを専用のETCDインスタンスに移行することにしました。これにより、構成データベースの可用性と応答時間を改善できるほか、障害発生時にはステータスDBを再構築できます。ほかにも、全テナントを対象とする不要なサイトオブジェクトの一覧取得処理を廃止したり、データベースの負荷を軽減するためにセカンダリインデックスを導入したりしました。

主な調査結果：オブザーバビリティ

システムの規模を拡大するにつれ、分散システム全体のオブザーバビリティに関する課題は大幅に増えました。

当初、メトリクスにはPrometheusフェデレーションを採用しました。グローバルコントロールの中央Prometheusが、リージョナルエッジ（RE）の各Prometheusをフェデレーションする構成です。各REのPrometheusは、自身のサービスメトリクスをスクレイピングするとともに、接続されたCEからメトリクスをフェデレーションします。最上位のPrometheusはアラートを評価し、詳細な分析に使用するメトリクスのデータソースとして機能していました。しかし、このアプローチはすぐに限界に達したため（CE約1,000台）、増え続けるCEの影響を最小限に抑えることにしました。そこで、ヒストグラムなどのカーディナリティが高いメトリクスについて、事前計算済みの時系列データを生成し始めました。これで1～2日はしのげましたが、その後はメトリクスにホワイトリストを適用せざるを得ませんでした。最終的には、CEサイトごとの時系列メトリクス数を約60,000から2,000に削減できました。

最終的に、3,000を超えるCEサイトまで継続的に拡張し、本番環境で数日間稼働させた結果、この構成ではスケールできないことが明らかになり、監視インフラを見直す必要が生じました。そこで、最上位のPrometheus（グローバルコントロール内）を廃止し、各REのPrometheusを2つの独立したインスタンスに分割しました。一方はローカルサービスのメトリクスのスクレイピングを担当し、もう一方はCEメトリクスのフェデレーションを担当します。どちらもアラートを生成し、メトリクスをCortexの中央ストレージにプッシュします。Cortexは分析および可視化のデータソースとして使用され、監視における中核的なアラート処理フローには含まれません。ThanosやM3dbなど、複数の集中型メトリクスソリューションをテストした結果、Cortexがニーズに最も適していることが分かりました。

図6 — メトリクス収集アーキテクチャ

次のスクリーンショット（図7）は、3,000個のエンドポイントを対象にprometheus-cefをスクレイピングした際のメモリ消費量を示しています。RAM使用量は29.7 GBですが、システムの規模を考慮すると、実際にはそれほど多くありません。スクレイピングを複数に分割するか、Cortexへのリモート書き込みをエッジ自体に直接移すことで、さらに最適化できます。

図7 — REサイトのリソース使用状況

次のスクリーンショット（図8）は、この規模でCortexのingestor（RAMは最大19 GB）とdistributorに必要だったメモリおよびCPUリソースを示しています。Cortexの最大の利点は水平スケーリングです。垂直スケーリングが必要なPrometheusとは異なり、レプリカを追加できます。

図8 — Global Controlにおけるリソース使用状況

CEおよびREのログインフラストラクチャでは、ノードごとにFluentbitサービスを使用しています。このサービスは、サービスおよびシステムのログイベントを収集し、接続先のREにあるFluentdへ転送します。Fluentdは、そのデータをRE内のElasticSearchへ転送します。ElasticSearchのデータはElastalertによって評価され、Alertmanagerアラートを生成するためのルールが設定されます。ElastalertからAlertmanangerへのカスタムインテグレーションを使用し、Prometheusが生成するものと同じラベルを持つアラートを生成しています。

モニタリングの取り組みにおける主なポイント：

• 新しいPrometheusフェデレーションフィルターを使用して、未使用のメトリクスとラベルを除外— 当初はCEあたり約50,000の時系列があり、平均15個のラベルが付いていましたが、メトリクス名のシンプルなホワイトリストとラベル名のブラックリストを使用して、CEあたり平均2,000まで最適化しました
• グローバルなPrometheusフェデレーションからCortexクラスターへの移行- 集約型Prometheusが、すべてのREとCEのPrometheusからメトリクスを収集 - CEが1,000台に達すると、膨大なメトリクスの管理が困難に - 現在は各REにPrometheusを配置し、接続先CEのPrometheusとフェデレーションを構成して、RWでCortexに送信
• Elasticsearchクラスターとログ- 分散型ロギングアーキテクチャ - 各ノードのコレクターであるFluentbitが、RE内のFluentd（アグリゲーター）にログを転送 - 各REにElasticSearchをデプロイし、リモートクラスター検索を使用して単一のKibanaインスタンスからログを照会

概要

このブログが、世界各地に展開された数千ものエッジサイトとクラスターを管理するうえで考慮すべき事項を理解する一助となれば幸いです。当初の設計要件の大半は満たし、検証することができましたが、今後も多くの改善に取り組む必要があります……

著者について

F5

F5のその他のブログ記事