クラウドネイティブデータベース成熟モデルの分析

現在、多くの企業が Kubernetes と関連テクノロジーを使用してワークロードをクラウドに移行しています。しかし、クラウド移行には、データとアプリケーションをクラウドに移行する方法、クラウドにデータを保存する方法、関係するコアテクノロジーなど、いくつかの重要な課題があります。率直に言えば、クラウド上のすべての問題はデータベースと密接に関連しています。

実際、クラウド ネイティブの概念が登場する以前から、企業はさまざまなデータの問題を処理するために従来のデータベースを使用していました。クラウド ネイティブ コンセプトの出現により、企業はより柔軟なオプションを利用でき、より最新のアプリケーションを使用して、データベース アプリケーションのスケーラビリティと弾力性を高め、自動化と視覚化のニーズをより適切に満たすことができます。

問題は、クラウドネイティブ データベースとはどのようなアーキテクチャなのかということです。なぜこれほど多くの企業がクラウドネイティブのルートを選択するのでしょうか?この記事では、クラウド ネイティブ データベースの成熟モデルをいくつか推奨します。企業は実際のクラウド アーキテクチャに基づいて評価し、どのテクノロジ スタックまたはアプリケーション モデルがより適しているかを確認できます。

クラウド アプリケーション モデルの進化

従来のクラウド サービス モデルでは、ユーザーは主に API サービスの形式でサービスを取得します。これは、インフラストラクチャ アズ ア サービス (IaaS)、プラットフォーム アズ ア サービス (PaaS)、ソフトウェア アズ ア サービス (SaaS) と呼ばれることが多いものです。

クラウドネイティブテクノロジーの出現により、ユーザーに新しい体験がもたらされました。 PaaS モデルに類似した「バリアント」、つまり Container as a Service (CaaS) と Function as a Service (FaaS) を通じて、企業はより優れたクラウド セルフサービス機能を取得し、クラウド サービスを最適な方法で調整し、権利と責任の分配をより明確にすることができます。

クラウドネイティブパノラマの詳細な説明（金色の部分はクラウドベンダーの責任、青い部分はユーザーの責任）

上の図には多くの重要な情報ポイントがありますが、それらを一つずつ分解してみましょう。

• IaaS: IaaS では、クラウド プロバイダーは企業に必要なサーバーを構成するだけでよく、ユーザーはアカウントを構成し、ミドルウェアを含むアプリケーションに必要なすべてのコンポーネントをインストールする必要があります。
• PaaS: PaaS を使用すると、ユーザーの作業負荷が大幅に軽減されます。すべてのコンポーネントは、面倒な構成を経ることなく、既存のアプリケーションに展開できます。サーバーは、ユーザーが独自のアプリケーションを開発、実行、管理できるクラウド形式のサービスを提供するプラットフォームとしても使用できます。
• SaaS: マネージド サービスとも呼ばれる SaaS では、より強力で高レベルかつ抽象的なビジネス機能を提供する API を通じてユーザーがソフトウェアを使用できます。
• CaaS: CaaS は、アプリケーション コンテナのアップロード、実行、スケーリング、および管理の方法を提供します。 PaaS と同様に、開発者がアプリケーションを展開および実行するのに役立ちます。ただし、PaaS では一部のコンテナ化タスクが隠されており、やや恣意的です。 CaaS を使用すると、コンテナ管理に Kubernetes を使用する機能など、マルチクラウド ホスティング機能を簡単に使用できるようになります。
• FaaS: FaaS は「サーバーレス」とも呼ばれ、PaaS のより抽象的なバージョンです。ユーザーは、サーバー リソースに注意を払うことなく、ビジネス コード ロジックに集中するだけで済みます。 FaaS は、より細分化された抽象的なサービス機能を提供すると言えます。

上記のすべてのサービス モデルを組み合わせて使用​​できることにも注目してください。たとえば、企業は、IaaS ベースの仮想マシン (VM) にビジネス システムを展開したり、CaaS ベースのコンテナーに複数のマイクロサービスを展開したり、完全にサードパーティ サービスから提供される SaaS を使用したり、FaaS を使用してさまざまなサービス間のワークフローとデータ フローを調整したりできます。

クラウドネイティブデータベース成熟モデル

さまざまなクラウド アプリケーション モデルにより、クラウド ネイティブ アーキテクチャの誕生に向けた強固な技術基盤が築かれました。前述のクラウドネイティブ データベースとデータ サービス成熟モデルの問題に戻ると、まずクラウドネイティブの概念を明確にする必要があります。

ビル・ワイルダーの 2012 年の著書『Cloud Architecture Patterns』によると、クラウド ネイティブは「クラウド プラットフォームを最大限に活用できるアプリケーション」と定義されています。

この定義によれば、IaaS と PaaS は、企業が調整を加えることなく、必要なアプリケーションをアドホックにそのままインストールできるため、「クラウド対応」と言えます。ただし、これは真のクラウドネイティブ ソリューションが提供する柔軟性を犠牲にすることになります。 CaaS、SaaS、FaaS だけが、真にクラウド アーキテクチャのために生まれたものと言えます。したがって、クラウド ネイティブは、クラウド ネイティブ アーキテクチャのさまざまな成熟度レベルを表すものと考えることができます。

成熟度モデル

このモデルでは、CaaS を「Kubernetes ネイティブ」、SaaS を「マネージド サービス」、FaaS を「サーバーレス」として表します。 IaaS/PaaS の「クラウド対応」成熟度レベルをベースラインとして表現すると、次のような成熟度モデルが得られます。

クラウドネイティブの成熟度レベル

成熟度の最も低いものから最も高いものまで、これらの成熟度レベルを 1 つずつ見ていきましょう。

成熟度レベル 0: クラウドデータ対応

最初の成熟レベルに到達するのは簡単です。これは典型的なリフト アンド シフト パラダイムです。 IaaS に導入できるシステムはすべてクラウド対応とみなされます。よく見られるパターンは、データベースが組み込まれた VM にデプロイされたモノリシック アプリケーションです。アプリケーションを VM (または複数の VM) にパッケージ化し、必要なネットワークに接続すれば、クラウドで実行できます。これは完全に有効な展開オプションであり、組織のクラウド導入における重要な移行フェーズとなることがよくありますが、完全にクラウドネイティブであるとは言えません。

成熟度レベル 1: Kubernetes 上に構築された運用モデル

このレベルは通常、企業がモノリシック アプリケーションを、コンテナーにデプロイして個別にスケーリングできる小さなマイクロサービスに分割した状態を表します。これは重要なステップですが、Docker などのコンテナ テクノロジだけでは、アプリケーションのライフサイクルを管理し、高可用性とスケーラビリティを確保するために必要なものがすべて提供されるわけではありません。

Docker ランタイムと Docker-compose は開発環境やテスト環境に最適です。しかし、実稼働環境での使用においては、企業は何が起こっているかを監視し、サービスレベルを維持するための措置を講じる必要があるため、Kubernetes などに代表されるコンテナ オーケストレーションがこの目的のために作成されました。

ご存知のとおり、Kubernetes は急速に発展しています。 2020 年の Cloud Native Computing Foundation (CNCF) の調査によると、調査対象となった企業の 92% がコンテナを本番環境で実行しており、そのうち 83% が Kubernetes を導入して使用していました。

興味深いことに、Kubernetes はマイクロサービスやアプリケーションのデプロイに非常に人気がありますが、Kubernetes 上にデータベースがデプロイされることはほとんどありません。その理由は何でしょうか?

Kubernetes はもともとステートレス ワークロード用に設計されていましたが、最新の改良によりステートフル アプリケーションの導入も可能になりました。たとえば、Cassandra を使用すると、データベースをコンテナに効率的にデプロイできます。

しかし、現実には、仮想マシンやベアメタル上で実行される自己管理型データベースなど、Kubernetes の外部で実行されるコンポーネントにストレージの責任を委任するコンテナ化されたアプリケーションがよく見られます。このアプローチにより、ネットワークとセキュリティの複雑さが増し、監視などの機能が重複することになります。このストレージ容量の変化により、クラウドネイティブ データベースは次の成熟モデルに移行します。

成熟度レベル 2: マネージド データ サービス

Kubernetes などのコンテナ化された環境にデータベースを単にデプロイするだけでは、スケーラビリティ、弾力性、視覚化、自動化など、クラウドネイティブ データベースに必要な機能を提供するには不十分です。

マネージド サービスまたは「Database as a Service」(DBaaS) のレベルに到達するには、企業は、スケールアップ/スケールダウン、バックアップ/復元、ソフトウェアの更新とトラブルシューティング、メトリック、ログ記録、トレースなどの監視と観測性を含むメンテナンス操作などの追加の運用ロジックを必要とします。

たとえば、cass-operator は、上記のメンテナンス タスクを処理する Cassandra 用のオープン ソース Kubernetes オペレーターです。 K8ssandra は、cass-operator をベースにした別のオープンソース プロジェクトであり、Kubernetes 上で Cassandra をデプロイおよび実行するための完全なエコシステムを提供します。このアプローチにより、企業はサードパーティの DBaaS の機能に近い独自のカスタマイズされた管理アプリケーションを柔軟に作成できるようになります。

しかし、企業が必要としているのは、単なる「サービスとしてのデータベース」ではなく、「サービスとしてのデータ」です。したがって、データ プラットフォームで成熟した SaaS ソリューションを提供するには、企業は CQL や SQL などのデータベース クエリ言語をサポートするエンドポイント以上のものを必要とします。開発者はまた、使い慣れた言語やフレームワークを使用して簡単にアクセスできる API を切望しています。これが、別のオープンソース プロジェクトである Stargate と呼ばれるデータ ゲートウェイを立ち上げた根本的な理由です。

Stargate は、開発者が使い慣れている一般的な HTTP アクセス パターンをサポートする RESTful API と、Web およびモバイル アプリケーションやスキーマレスのドキュメント指向 API に特に役立つ新しい GraphQL API を提供します。

成熟度レベル 3: データ用サーバーレス モデル

企業が独自の管理プラットフォームを所有している場合や、サードパーティからマネージド サービスを購入している場合でも、考慮すべきコストは依然として存在します。

どちらの場合も、典型的な質問は、「無駄を最小限に抑えるために、ワークロードの実際のニーズに基づいて展開されるリソースの量を調整するにはどうすればよいか」です。 Cassandra のような高度にスケーラブルで弾力性のあるシステムであっても、コンピューティング リソースとストレージ リソースを個別に拡張することは困難です。企業がデータベースの必要な部分だけを拡張できるとしたらどうなるでしょうか?

ここで、FaaS またはサーバーレス アプローチが登場します。Cassandra などのクラウドネイティブ データベースをより小さな機能に分割することで、コンピューティングとストレージの使用を切り離し、より効率的に管理できます。インターフェース、ルーター、読み取りおよび書き込み機能など、すべてがスケーラブルな独立した機能になります。このモデルの最大の利点は、リソース使用率を大幅に向上させ、マルチテナントをサポートできることです。

サーバーレス アーキテクチャ パターンにより、多くの人々の視点が変わり、「データベースを Kubernetes で実行できるか」といったトピックを考慮する必要がなくなり、「特定のデータベース ワークロードに対して最も低コストのソリューションを得るにはどうすればよいか」というトピックにシフトしました。

まとめ

クラウド コンピューティングの実践が成熟するにつれて、クラウド ネイティブ アーキテクチャの概念と設計手法をスタックのすべてのレベルに適用するようになりました。これは、クラウド ネイティブ データベースを実装するための最も効果的な方法です。著者は、コンテナ化 (CaaS)、マネージド サービス (SaaS)、サーバーレス (FaaS) などのベスト プラクティスに基づくクラウド ネイティブ データベース成熟モデルが、クラウドでデータを効果的に使用するための最良の方法であると考えています。 K8ssandra や Stargate などのオープンソース プロジェクトの出現により、クラウド ネイティブ データベースがさらに発展する絶好の機会が提供され、より多くの企業がデータ アーキテクチャの成熟度を急速に高めることができます。

最後に、クラウドネイティブ データベースの大規模なテクノロジー エコシステムにさらに多くの企業が参加し、成熟モデルや関連する問題についてより多くの意見を表明することを期待しています。