クラウドネイティブ環境におけるデータベースサービスガバナンスについて考える

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​

サービスガバナンスからデータベースサービスガバナンスへ

マイクロサービスガバナンス

サービス ガバナンスからデータベース サービス ガバナンスに移行する場合、やはりマイクロサービス ガバナンスから始める必要があります。モノリシックからマイクロサービスへと移行し、ビジネスがより複雑かつ多様化し、インフラストラクチャが大規模化するにつれて、サービス間の呼び出し関係は非常に複雑になります。マイクロサービスのガバナンスは、依然としてトラフィック制御、可観測性、安全なアクセス、構成管理、高可用性に限定されています。マイクロサービス アーキテクチャをオンラインにしてより速く展開するには、自動化されたフレームワークが必要です。運用・保守についても、できる限り標準化していきたいと考えています。

この頃、Kubernetes などのコンテナ オーケストレーション フレームワークが登場しました。 Kubernetes は Google 内の Borg から生まれたもので、Google の大企業特有の特性を多く備えています。大企業であるかどうかは、その技術がどれだけ進んでいるかではなく、その規模の大きさによって決まります。特に大規模な場合のみ、運用と保守の複雑さが反映され、自動化機能を向上させるためのプラットフォームやツールへの依存度が高まります。

私たちはこの自動化機能のインフラストラクチャをコードと呼んでいます。 SRE の学生がこのような構成ファイルを作成し、そのファイルを Kubernetes に送信すると、Kubernetes はそこに記述された動作に基づいて対応する指示に従います。ただし、指示は宣言型 API であり、このプロセスでアプリケーションが自動的に起動されます。

Kubernetes に関して言えば、数万のノードと、場合によっては数十万のポッドがある場合、そのサービスをどのように管理するのでしょうか?以前のサービス検出フレームワークを引き続き使用する場合、Kubernetes との互換性に関していくつかの非互換性の問題が発生します。 Kubernetes 上でサービスガバナンスを実行するネイティブな方法はありますか?これがサービスメッシュです。

サービスメッシュ

サービス メッシュは、2016 年に Linkerd プロジェクトによって初めて提案されました。サービス メッシュは、サービス ガバナンスの動作または機能をインフラストラクチャに組み込みます。サービス メッシュは、サービス ガバナンス動作のオーケストレーション フレームワークとして考えることができます。いくつかの宣言的な構成を通じて、Service Mesh が基本的なフレームワークとインフラストラクチャに配信され、私たちに代わって関連タスクを実行できるようになります。

サービス メッシュの特に典型的な図を以下に示します。青い部分がビジネス アプリケーションであり、黄色い部分がサービス メッシュ プロキシであると想定できます。サービス メッシュは、このような透過的なプロキシを使用して、すべてのアプリケーション トラフィックを引き継ぎ、管理します。このテイクオーバー方式により、サービス検出などのさまざまなサービス ガバナンス機能が実現されます。

Istio の紹介

Service Mesh について話すとき、Istio プロジェクトについて言及する必要があります。 2016 年当時、Linkerd の Service Mesh に対する理解はまだそれほど成熟していなかったため、私たちはその時代を Service Mesh の第一世代と呼んでいました。サービス メッシュ アーキテクチャが今日のような形で本格的に開発されたのは、Istio が登場してからのことでした。私たちは Istio を第 2 世代のサービス メッシュと呼んでいます。

下の図は、Istio の主なアーキテクチャとその下のコントロール パネルを示しています。コントロール パネルはコントロール プレーンと呼ばれ、Istiod が含まれています。初期の 1.0 では、Istiod は Pilot、Galley、Citadel などの複数の独立したコンポーネントで構成されており、これらは可観測性の集約などの一部の証明書を担当していました。元々はミキサーや、パイロット関連のさまざまな設定などがありました。

マイクロサービスガバナンスとデータベースサービスガバナンスの類似点と相違点

「Istio はアプリケーション トラフィックをプロキシできるのに、なぜデータベース サービスのガバナンスについて話す必要があるのか​​」と疑問に思う人もいるかもしれません。ガバナンス効果を実現するために、Istio にデータベース プロトコルを完全にハイジャックさせたり、すべてのデータベース トラフィックをプロキシさせたりすることができます。

データベースをマイクロサービスの中でも特別なマイクロサービスと見なすと、サービス チェーンの最後のリンクになると考えられます。実際、サービス検出機能を含むサービス メッシュを通じてデータベースへのアクセスを管理できます。ただし、データベースには特別なガバナンス プロパティまたは要件もあります。たとえば、MySQL プロトコル、PG プロトコル、Redis プロトコルなどのデータベース プロトコルには、独自の特殊性があります。たとえば、MySQL プロトコルを使用して接続を確立すると、サーバーは最初にパッケージを送信します。また、リソース管理に関しては、マイクロサービスの業務アプリケーション間の運用時に消費されるリソースについてはあまり気にする必要はないかもしれません。これはサービス全体のパフォーマンス指標となるはずです。

しかし、データベースの場合は、いくつかの違いがある可能性があります。データベース インジケーターなどの可観測性に反映されると、SQL の速度低下や SQL のレイテンシが発生する可能性があります。

トラフィック管理に関しては、データベースにも独自の特徴があります。 Redis、MongoDB、MySQL のいずれの場合でも、シャーディングを行う場合、分散をトラフィック自体のみに依存することは困難です。該当するリクエストを勝手に転送すると、間違った回答が返ってくる可能性があります。

さらに、シャーディングなどのシナリオでは、いわゆる負荷分散はデータ属性の判断に基づいており、背後にある異なるデータソースに単純にランダムに送信することはできません。

最後に、アクセス制御があります。一般的に、ビジネス アプリケーションでは、グローバル認証または ID 承認に関連するマイクロサービス レベルのアクセス制御が行われます。多くの場合、テーブルレベルまたは列レベルのアクセス制御が必要になります。このような特別なガバナンス効果は、特別なガバナンス措置を通じてのみ達成できます。

メッシュモデルの設計方法

サービスメッシュから学んだ教訓

先ほど説明したサービス メッシュに戻りましょう。サービスメッシュから何を学べるでしょうか?

まず、サービス メッシュは、コントロール プレーンとデータ プレーンを分離するデプロイメント構造です。

第二に、コントロールプレーンとデータプレーンのプロトコルを標準化すると、データプレーンにさらに多くのオプションを提供できるようになります。

3 番目に、Kubernetes メカニズムを使用して、インフラストラクチャをコード構成機能として実装できます。

4 番目に、プラグインを使用してさまざまなプロトコル拡張をサポートできます。

このとき、データベースのデータベース メッシュとサービス メッシュの間に包含関係があるかどうかが疑問になります。それとも、これらは全く異なるシナリオなのでしょうか?

データベースメッシュの概念

2018 年、ShardingSphere の創設者である Zhang Liang 氏は、著書「Future Architecture」の中で、サービス メッシュ ガバナンスの考え方をデータベース ガバナンスに適用するとどのような効果が得られるかを実際に想像しました。

ShardingSphere プロジェクトは主に、ライブラリとテーブルのシャーディング、データの暗号化、データのスケーリングなど、データベース トラフィックの管理に使用されます。次の図に示すように、ShardingSphere Sidecar をビジネス アプリケーションと一緒にデプロイすることは可能ですか?通常のビジネス リクエストはサービス メッシュを通過し、マイクロサービスとビジネス間のサービス検出と関連呼び出しを実行します。データベース トラフィックの場合、Sharding Sidecar を使用してデータベースにプロキシされ、Sharding Sidecar 全体も、関連する登録と検出を実行するためにコントロール プレーンに依存します。

Sharding Sidecar と ShardingSphere の既存のプロキシおよび JDBC 機能は同じである必要があります。このようにして、JDBC と Proxy の欠点を完全にカバーできます。 Sharding Sidecar は、Sidecar モードでビジネス アプリケーションの隣にデプロイされます。ビジネス アプリケーションが分散または多重複製されている場合は、複数のコピーが存在します。ビジネス アプリケーションとそれらの間の通信も、特定の言語スタックに制限されることなく、このような言語分離を実現できます。このアーキテクチャは、弾力的にスケーラブルで、侵入がなく、分散化されたクラウド インフラストラクチャですか?

これは 2018 年の Database Mesh に関するアイデアでした。

データベースメッシュの現状

2018 年から現在までのわずか 4 年間で、データベース メッシュの概念は実際に多くの企業で十分に検討され、実践されてきました。一般的に、典型的な解決策は 3 つあります。

1 つ目は ShardingSphere Sidecar 形式です。 Sidecar の形式でビジネス ポッドにデータベース ガバナンス機能を提供します。

2 番目のタイプは、一部の大企業でより一般的である可能性がある統合メッシュ管理です。

3 番目のタイプは分散データベースと呼ばれます。

これら 3 つの方法には共通点が 1 つあります。それは、いずれもデータベース サービス管理のトラフィック管理部分に重点を置いていることです。このステージを 1.0 ステージと呼ぶとしたら、これを 2.0 にアップグレードするとしたら、どのような機能が必要でしょうか?

データベース メッシュ 1.0 と 2.0

慎重に検討した結果、スケーラビリティとユーザー エクスペリエンスの向上が必要であると感じ、Database Mesh 2.0 のコンセプトを提案しました。この度、「クラウドデータベースのガバナンス課題に対応するため、プログラマビリティによる高性能拡張を実現する」をスローガンとした特設サイトを開設いたしました。

私たちは、この構成可能、プラグ可能、またはプログラム可能なアプローチを通じて、データベース トラフィック、ランタイム リソース、および安定性の保証をカバーするガバナンス フレームワークを実装できることを期待しています。どのようなタイプのデータベースであっても、それを管理するための標準インターフェースを持つことが望まれます。これは、Database Mesh 2.0 の望ましい機能です。

Database Mesh 2.0 に関して特に強調したい点は、設計時に Mesh が実際に何を意味するかを常に考えていたということです。実際、当初私たちは Sidecar が Mesh だと思っていました。 Sidecar を通じて他のものとやりとりするとメッシュが形成され、このメッシュが Mesh でした。しかし、後になってそうではないことが分かりました。 Mesh の核は Sidecar ではなく、Mesh は Sidecar の表現形式にすぎません。

次に、Database Mesh 2.0 の全体像を見てみましょう。このパノラマ写真の左半分は、実はユーザーごとに分割されています。一番上は「開発者」で、開発者が Database Mesh についてどう感じているかを示しています。右側では、SRE または DBA の学生は、アクセス制御、監査、リスク制御、可観測性、イベントなど、さらに多くのことを知りたいと思っています。右側では、SRE または DBA の学生は、アクセス制御、監査、リスク制御、可観測性、イベントなど、さらに多くのことを知りたいと思っています。

要約すると:

まず、Database Mesh 2.0 では、データベースを第一級オブジェクトと見なし、これらすべての抽象化は、VirtualDatabase と呼ばれるデータベースに基づいています。

2 番目に、開発者、SRE、DBA など、データベースの実際の場所だけを気にするエンジニア向けのエクスペリエンスを実現したいと考えています。

3 番目に、クラウド ネイティブは自然にクラウド指向の環境であるべきであり、ユーザーはベンダーによってロックインされることを心配する必要がありません。

Kubernetesを使用してデータベースメッシュを実装する方法

この最後の部分では、Kubernetes を使用してこのようなモデルを実装する方法を紹介します。

Kubernetes スケーリング パターン

Kubernetes はプラットフォームのためのプラットフォームとして知られています。 Kubernetes 上にさまざまな機能を構築するために登場したスタートアップ企業や PaaS サービス プロバイダーは数多くあります。

Kubernetes の拡張性こそがその活力の鍵です。最初の拡張モードは Sidecar と呼ばれます。 2 番目の拡張モードは AdmissionWebhook です。 3 番目の拡張モードは、ユーザー定義のリソース定義であり、これも特に強力な機能です。

Pisanix の設計と実装

Kubernetes を紹介した後、Pisanix プロジェクトを見てみましょう。 Pisanix は、SphereEx チームが提供するデータベース メッシュ向けソリューションです。 PisanixはGoとRustで書かれています。これを Kubernetes 環境に適応させ、現在は MySQL プロトコルをサポートしています。

主なコンポーネントは 3 つあります。

• Pisa-Controller: Pisanix プロジェクトのコア コンポーネント。 Pisa-Controller はコントロール プレーンを担当します。これは Golang で実装されており、必須のコンポーネントです。
• Pisa-Proxy: Pisa-Proxy は、プロキシ トラフィックのデータ プレーンを担当します。 Pisa-Proxy はサイドカーとしてポッドにデプロイされます。これは Rust で実装されており、必須コンポーネントでもあります。
• Pisa-Daemon (近日リリース予定): リソースの最適化を担当するデータ プレーンです。 DaemonSet です。 Kubernetes クラスター内の各ノードにはデーモンが存在します。オプションのコンポーネントです。

3 つのコンポーネントが連携して、次の効果を実現します。

まず、SQL 対応のトラフィック管理が実装されます。

第二に、ランタイム指向のリソースはプログラム可能です。

3 番目は、データベース信頼性エンジニアリング (DRE とも呼ばれます) です。

Pisa-Proxyに焦点を当てます。 Pisa-Proxy は、当社の最も重要なコア コンポーネントの 1 つです。私たちの能力はすべて、実際にこれに依存しています。これを実装するために Rust を選択した主な理由の 1 つは、Rust が非常に粘り強いためです。

Pisa-Proxy は、データベース トラフィックのロード バランサーとして考えることができます。主なワークフローは次のとおりです。

現在、Pisa-Proxy は MySQL プロトコルをサポートしており、データベース サーバーとして偽装しています。接続構成を適用するには、アクセス アドレスを変更して接続を確立するだけです。

1. Pisa-Proxy は、アプリケーションから送信されたハンドシェイク要求とデータ パケットを読み取ることで、アプリケーションが実行する SQL を取得します。
2. SQL に対して語彙および文法の解析を実行した後、対応する AST が取得されます。
3. AST に基づく高度なアクセス制御と SQL ファイアウォール機能を実装します。
4. アクセス制御とファイアウォールは、SQL 送信後に強制されます。
5. SQL 実行フェーズのメトリックは、Prometheus メトリックとして収集されます。
6. 負荷分散戦略に基づいてステートメントを実行するためのバックエンド データベース接続を取得します。
7. 接続プールが空の場合、構成に従ってバックエンド データベースへの接続が確立されます。
8. この接続からバックエンド データベースに SQL が送信され、対応する返された結果が読み取られます。
9. SQL 実行結果が組み立てられ、ビジネス アプリケーションに返されます。

最後に、Pisa-Daemonについてお話しましょう。 Pisa-Daemon は eBPF テクノロジーと切り離せません。 eBPF は現在かなり人気があります。コンテナと同様に、eBPF テクノロジー自体は特に新しいものではありません。

eBPF は Extended BPF の略称で、Linux カーネル内にサンドボックスを構築し、さまざまなプログラムを実行できます。 eBPF は、次のような用途によく使用される、安全で効率的なカーネル拡張メカニズムです。

• 可観測性: eBPF はカーネル状態のさまざまな観測可能な指標を収集し、さまざまなチャートを生成できます。
• システム セキュリティ: eBPF はすべてのシステム コールを監視でき、ネットワーク パケットまたはソケットの管理とプロセス コンテキスト追跡機能により、よりきめ細かいセキュリティ制御を実現できます。
• ネットワーク: eBPF のプログラム拡張性は、カーネルのネットワーク処理コンテキストを離れることなく、ネットワーク トラフィック パケットを処理するのに自然に適しています。
• 追跡とチューニング: ユーザー モード プロセスとシステム コールを検出することで、ゼロ侵入型の相関追跡とパフォーマンス分析エクスペリエンスが実現されます。

Pisa-Daemon はリソースのプログラミング可能性で知られています。カーネル メカニズムを使用してリソース管理機能を提供します。これらのリソースはランタイム リソースです。 Pisa-Daemon および Pisa-Proxy と連携することで、異なる優先度のサービスからのデータベース トラフィックを識別できます。

将来的には、プラグ可能またはプログラム可能な方法で、より多くの種類のランタイム リソース管理をサポートする拡張メカニズムを作成したいと考えています。

Kubernetes で Pisanix を使用する方法

最後に、Kubernetes で Pisanix プロジェクトを使用する方法を見てみましょう。

Pisanix は Database Mesh の実装であるため、その仕様にも従います。まず、VirtualDatabase、TrafficStrategy、DatabaseEndpoint という 3 つの CRD を使用します。

VirtualDatabase は、先ほど Database Mesh を紹介したときに説明した集約ルートです。データベース メッシュ ガバナンスのすべての機能は VirtualDatabase に反映されます。

VirtualDatabase には TrafficStrategy というフィールドがあり、このデータベースへのアクセスを管理するために使用する戦略を識別します。

誰にランダム化されますか? TrafficStrategyにセレクターがあります。セレクターはラベルを使用してバックエンドの DatabaseEndpoint を選択します。

これら 3 つの CRD は、バックエンド データ ソースと MySQL プロキシに関するこのビジネス アプリケーションの関連構成情報をカバーできます。次のステップでは、Pisa-Controller が CRD を取得し、構成コンテンツに基づいてそれを Pisa-Proxy 構成に変換し、対応する Sidecar にプッシュします。 Pisa-Proxy はこの構成を取得し、コンテンツに基づいてバックエンドの実際のデータベースへの接続を確立し、同時にフロントエンドはポートをリッスンしてリクエストを受信します。最後に、アプリケーションの場合は、構成されたポートにアクセスするだけで実装できます。

実は、Pisa-Proxy を単独で使うことも考えています。一部の Kubernetes は、すべての企業やすべてのビジネスに適しているわけではありません。この種のデータベース ガバナンスも必要な場合、特にトラフィックの統合アクセス ガバナンスが必要な場合は、Pisa-Proxy を個別に導入できます。このときの使用方法は、Nginx を使用してクラスターを形成する場合と同じです。 RDS、TiDB、ShardingSphere など、使用するデータベースの種類に関係なく、Pisa-Proxy をデータベースの統合アクセス レイヤーとして使用してプロキシとして機能させ、シームレスな高可用性切り替え、SQL 指向の可観測性などを実現できます。

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

​​https://ost..com​​.