ByteDoc 3.0: MongoDB クラウドネイティブプラクティス

著者: 李嘉軍

背景

この記事では、Bytedoc 3.0 のクラスター配信に関するコンテンツと、クラウドネイティブのプラクティスの一部を紹介します。Bytedoc 3.0 とクラウドネイティブの機能を組み合わせて、ソフトウェアレイヤーの機能と一致し、Bytedoc 3.0 の「弾力性」機能を最大限に活用する、すぐに使用できるクラスターをユーザーに提供する方法について説明します。

問題点

データベースサービスを使用するのは、ユーザー (ビジネス) と DBA (運用と保守) の 2 者です。運用・保守能力を継続的に強化することによってのみ、ユーザーにより良いサービス体験を提供することができます。

ユーザーのニーズ

運用および保守要件

目標とアイデア

ターゲット

上記の問題を解決するために、Bytedoc 3.0 ソフトウェアレイヤーには関連機能が実装されています。全体的な「弾力性」機能と一致するように、配信層で同様の機能を提供する必要があります。

目標 1:データベースはスレーブを迅速に拡張/回復し、データベースの読み取り機能を数秒で拡張できます。スレーブインスタンスの拡張は、高度に自動化され、可能な限り高速に行われる必要があります。

目標 2:コンピューティングリソースをオンデマンドで拡張できます。コンピューティング集約型のビジネスでは、コンピューティングリソースを迅速に拡張し、実際の負荷に合わせてユーザーにさらに多くのリソースを割り当てることができます。

目標 3:コンピューティング/ストレージリソースの使用率を改善し、ビジネス使用コストを削減します。

目標 4:より標準化された配信機能とより高い配信品質により、ユーザーに優れたデータベースサービスを提供します。

実装のアイデア

私たちは、Kubernetes をクラウドネイティブにすることで目標を達成します。

Kubernetes は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するための、業界全体にわたるオープンソースのオーケストレーションシステムです。簡単に言えば、サービス（この場合は Bytedoc データベースサービス）を体系的にパッケージ化し、実行し、管理することができます。これにより、既存の運用および保守の経験を業界全体のサービス配信/管理ソリューションと組み合わせて、より優れた高品質のデータベースサービスを提供できるようになり、Bytedoc 3.0 の「弾力性」を最大限に活用できるようになります。

ByteDoc 1.0 の時代では、ほとんどのデータベースサービスインスタンスは仮想マシンに直接デプロイされていました。仮想マシン仕様の分割によりリソース割り当てが制限され、マシンリソースをオンデマンドで柔軟に割り当てることができず、ほとんどのマシンリソースがアイドル状態となり、有効活用できない状況となっていました。同時に、コンピューティングとストレージのリソースが制限されていたため、1.0 の自社開発デプロイメントプラットフォームでコンテナ化されたデプロイメントを実装することは非常に困難であり、仮想マシンデプロイメントソリューションが保持されました。

ByteDoc 3.0 が登場するまでは、データはストレージ層に移動され、サービスを提供する際にはコンピューティング層でのリソース割り当てに重点が置かれ、コンテナ化された展開モデルが実現可能になりました。 Kubernetes のコンテナ展開および管理ソリューションと組み合わせて、コンテナの自動管理操作の大部分を Kubernetes コントローラーに引き渡し、クラスター展開、スレーブ拡張などの ByteDoc 3.0 サービスオーケストレーションプロセスに重点を置き、3.0 の「弾力性」機能を十分に発揮できるようにしました。

クラウドネイティブ実践

サービスをクラウドネイティブにすることは、実際には「移行」プロセスであり、既存のサービスをパッケージ化、実行、管理し、Kubernetes によって提供されるソリューションに基づいてそれらを再現することが含まれます。

Kubernetes では、ByteDoc 3.0 クラスターをカスタムリソース (CustomResource) として定義します。データベースサービスを提供すると、実際にリソースが作成されます。 K8s の組み込みワークロードリソースと同様に、カスタムリソースも管理するためのコントローラーが必要です。このタイプのコントローラーは通常、オペレーターと呼ばれます。

したがって、ByteDoc 3.0 クラウドネイティブ実践の鍵は、ByteDoc Operator を構築することです。

Kubernetes の基本概念

コンテナ化された展開

前述のように、Kubernetes はコンテナのライフサイクル管理を主な役割とするコンテナオーケストレーションシステムであるため、実際のアプリケーションは事前にコンテナイメージにパッケージ化して、K8s に配信して使用できるようにする必要があります。

ポッド

https://kubernetes.io/zh/docs/concepts/workloads/pods/

パッケージ化されたコンテナは最終的に Pod 内で実行され、Pod によって管理されます。

Pod は、K8s に組み込まれている最も基本的なリソースの 1 つであり、デプロイメントのための最小のコンピューティングユニットです。これは、マシンリソースを共有するコンテナーのグループに例えることができます。

例外により Pod (内部のコンテナ) が終了した場合、通常、Pod は削除され、破棄され、高度なワークロードは Pod を「再起動」するのではなく、新しい Pod を作成して置き換えます。

高度なワークロード

通常、構築する Operator は Pod を直接作成しません。代わりに、K8s によって提供される高度なワークロードリソースを使用します。これにより、ポッドを作成し、基本的なリソース管理機能を提供できるようになります。

展開:

通常はステートレスサービス用に、指定された数の同一 Pod を維持します。

ステートフルセット:

ポッドのグループも維持されます。特別なのは、各ポッドに安定したネットワーク識別子があることです。このシナリオでは、Pod が破棄されて再構築されると、外部ユーザーには Pod が「再起動」されたように見えるため、通常はステートフルサービスに使用されます。

K8sとのやり取り方法

Kubernetes コントロールプレーンの中核は API サーバーです。 API サーバーは、ユーザー、クラスターのさまざまな部分、およびクラスター外部のコンポーネントが相互に通信するための HTTP API を提供する役割を担います。

一般的に言えば、K8s とのやり取りは命令型ではなく宣言型で行われます。

 # サンプル. ヤム
apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: nginx - デプロイメント
仕様:
 セレクター:
 マッチラベル:
 アプリ: nginx
 最小準備秒数: 6
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: nginx
 仕様:
 コンテナ:
 - 名前: nginx
 イメージ: nginx : 1.14.2
 ポート:
 - コンテナポート: 80

Kubernetes 上の ByteDoc 3.0 アーキテクチャ

(ByteDoc クラシックアーキテクチャ、3 つの部分から構成)

モンゴス:

プロキシ層は、ユーザー要求の転送と単純な処理を担当します。
Config Server を認識し、そこからシャードトポロジを取得する必要があります。

設定サーバー:

マスターとスレーブを区別するレプリカセットモード。
各シャード内のインスタンスのアドレスを含むクラスターのメタデータを保存します。

シャード:

マスターとスレーブを区別するレプリカセットモード。
サーバー層はユーザー要求を処理します。

mongos - ステートレスサービスに対応するデプロイメント
config server/shard - ステートフルセット、ステートフルサービスに対応

mongo のレプリカセットの場合、レプリカセットメンバーは、他のレプリカセットメンバーと通信するために、ネットワーク識別子 (ホスト、DNS、サービス検出、ヘッドレスサービスなど) を使用して構成に登録する必要があります。そのため、ここでは、StatefulSet によって提供される安定したネットワーク識別子をメンバー名として使用し、データベースインスタンス (対応するポッド) に障害が発生した後、同じ ID でレプリカセットに追加され、正常にサービスが提供されるようにします。

連邦モデル

複数のコンピュータルームのシナリオにおけるアーキテクチャ

実際、上記の ByteDoc 3.0 クラスターは、単一のコンピュータルーム内のアーキテクチャです。オンライン本番環境では、複数のコンピュータルームの災害復旧シナリオも考慮する必要があります。複数のコンピュータルームのシナリオでは、3 つのレプリカを持つクラスターが必要であり、各コンピューティングインスタンスは異なるコンピュータルームに展開されます。ただし、これらのレプリカは同じレプリケーションセット内にある必要があります。いくつかのクロス K8s ソリューションを参照した後、次のマルチコンピュータルームアーキテクチャを採用しました。

候補となるクロス K8s ソリューションは何ですか?

1. コミュニティによって提供される Federation V1 ソリューション (非推奨、後に V2 ソリューションに改善)

複数のクラスタの管理をサポートするために、主にクラスタ間リソース同期とクラスタ間サービス検出という2つの主要な機能を提供します。

2. クラウドネイティブSREチームが提供する一般的なオペレータソリューション

 ...
 仕様:
 チャート:
 - 名前: nginx
 チャート: チャート/ nginx
 値: '"replicaCount": "{{ .replica_count | デフォルト 1 }}"'
 クラスター:
 - 配置:
 - 名前:
 - クラスター- サンプル
実行ジョブ:
 - 名前: ls
 指示：
 -ls
 - 「-l」
 必須:
 - チャート。 nginx
 変数:
 レプリカ数: '2'

一連のチャート、K8s クラスター、実行タスク、変数を定義する
ユニバーサルオペレーターを介して複数のK8sクラスター上でリソースの展開とタスクの実行を完了します。

3. MongoDBが提供するCross-K8sソリューション

MongoDB の追加の k8s-agent を使用して、クロス K8s クラスターシナリオでレプリカセットとクラスターの構築を完了します。
コードはオープンソースではない

なぜ今このオプションを選んだのですか?

私たちの現在のソリューションは、実際にはコミュニティの Federation ソリューションに似ています。私たちは以下の機能を通じて完全な ByteDoc 3.0 クラスターを構築します。

リソースの複製:オペレーターはワーカーK8に接続し、基本的に同じリソースを作成します。
サービス検出:特定のネットワークシナリオに応じて、オーバーレイネットワークを使用する場合は、コミュニティでサポートされているヘッドレスサービスを使用できます。アンダーレイネットワークを使用する場合は、追加のサービス検出機能が必要になります。
ByteDoc クラスターの構築:インスタンスのクラスターを構築するコアロジックは比較的複雑であり、タスクの形式で実装するのは簡単ではありません。

そのため、この Meta Operator ソリューションを選択し、ワーカー K8s を通じてリソースを作成し、Operator がクラスター構築作業を完了します。

望ましい状態を達成する

 仕様:
 グローバル:
 チャートバージョン: "1.0.0.0"
 バイトドキュメントバージョン: "3.0"
 画像： 「example_image」
 モンゴス:
 レプリカ数: 2
 リソース：
 制限:
 CPU : "4"
 メモリ: 2Gi
 リクエスト:
 CPU : "1"
 メモリ: 1 Gi
 シャード:
 破片数: 1
 レプリカ数: 4
 ...
 設定:
 レプリカ数: 3
 ...
 配置:
 - 名前: vdc1
 vdc : "vdc1"

では、ByteDoc 演算子は実際にどのようなロジックを実行するのでしょうか? Operator は実際に K8s コントローラーの設計コンセプトを満たしています。つまり、各リソースオブジェクトには予想される状態があり、Operator はリソースオブジェクトを予想される状態に調整する必要があります。この調整プロセスは「調整」と呼ばれます。

詳しく見てみると、ByteDoc クラスターは 3 つのコンポーネントに分かれていることがわかります。 Mongos、構成サーバー、およびシャードコンポーネントがすべて目的の状態に到達し、最終的にコンポーネントが「接続」されれば、クラスター全体も目的の状態に到達します。

したがって、クラスター全体の調整を複数のモジュールの調整に分解できます。それぞれの小さなモジュールが期待される状態に達すると、クラスター全体も期待される状態に達します。 bytedoc 演算子は、おおよそこの設計概念に基づいています。

したがって、当社のオペレーターの一般的なプロセスは次のとおりです。

ステータス管理

https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status

名前が示すように、Status はリソースオブジェクトの現在のステータスを保存するために使用されます。ステートマシンや小さなストレージとして使用できます。以下を達成するために使用できます:

1回限りの操作の完了ステータス: 初期化が完了したかどうかなど
イメージ/サービスバージョン
コンポーネントのステータス
クラスタのアップグレード進行状況の制御
バックアップ進捗管理
リソースの変更は完了しましたか?

通常、観察されたフィールドで記録される世代
クラスター CR に変更を加えると、メタデータの世代数は +1 になります。オペレーターは、この変更の予想される状態に達したときに、CR 変更が完了したかどうかを照会できるように、等しい observedGeneration カウントを設定する必要があります。

 状態：
 レプリカセット:
 ll2022 - シャード- 0 :
 列をなして：
 シャードとして追加: true
 初期化済み: true
 読み取り専用: true
 準備完了: 3
 サイズ: 3
 ステータス: 準備完了
配置:
 vdc1 :
 準備完了: 3
 サイズ: 3
 ステータス: 準備完了
vdc : vdc1
 ...

リソーステンプレート管理 - Helm

前述のように、各 ByteDoc コンポーネントは実際には K8s 組み込みリソースによって管理されます。通常、CR yaml ファイル全体を最初から書き直す必要はありません。 mongos インスタンスの数、CPU、メモリリソースの制限など、固定テンプレート内の動的パラメータを調整できます。

この時点から、エンジニアリング実装には 2 つの方向があります。

YAML テンプレートをコードにハードコードし、変数の置換を通じてターゲットリソースファイルを生成します。
yaml テンプレートをファイルの形式で保存し、文字を置き換えることで対象のリソースファイルを生成します。

テンプレートのレンダリングとリソースの公開

私たちは、Helm (コード) を使用して組み込みリソースファイルのレンダリングを管理し、オペレーターイメージで公開するという、2 番目の方法のよりエレガントなバージョンを採用しました。私たちは、Helm 標準に従って一連のチャートファイルを維持しました。

リソースを作成するときは、helm sdk を使用してパラメーターをチャートテンプレートにレンダリングし、実際のリソース yaml を生成して、ワーカー K8s クラスターに公開します。オペレーターは、変更の実行を続行する前に、リソースが完全に準備されるまで待つだけです。

テンプレートのバージョン管理

このソリューションのもう 1 つの優れた機能は、さまざまなバージョンのチャートテンプレートを、バージョンに応じて異なるディレクトリに分けて保存できることです。

チャートテンプレートの新しいバージョンをリリースする必要がある場合でも、サービスの古いバージョンは影響を受けません。新しく作成されたサービスでは、新しいバージョンのチャートテンプレートを使用できます。

誤操作の防止

K8s の導入により、多くの利便性を備えたクラスターの提供/管理が可能になりますが、実際には諸刃の剣でもあります。ほとんどのクラスターは不注意により誤操作される可能性があり、その結果、データベースサービスの可用性が低下します。

考えられるシナリオは次のとおりです。

クラスターリソースオブジェクトを誤って削除すると、サービスのダウンタイムが発生します。
インスタンスが誤って 0 にスケールダウンされる -> サービスを提供できるインスタンスがない
誤って CRD を削除すると、対応するすべてのリソースオブジェクトが削除され、すべてのサービスがオフラインになります。

ファイナライザー

https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/finalizers/

これは、誤って削除されるのを防ぐための K8s のネイティブソリューションです。それはマーカーです。削除を伴うすべての操作では、ファイナライザーがあるかどうかを確認する必要があります。

ファイナライザーが存在する場合、API サーバー経由のすべてのリソース削除リクエストは、ファイナライザーがクリアされるまでブロックされます。
通常、ファイナライザタグは対応するオペレータによって管理され、変更が発生するたびにファイナライザタグがチェックされ、追加されます。
削除要求を受信すると、削除条件が満たされているかどうかが判断されます。私たちのシナリオでは、通常、7 日間の削除クーリングオフ期間を待つ必要があるため、誤って削除操作を行った場合は、7 日以内に復元する必要があります。