クラウドネイティブデータベースの探索

翻訳者 |李睿

校正 |梁策と孫淑娟

現在、「クラウド ネイティブ」という概念は、主にアプリケーション ロジックとインフラストラクチャ (データベースを含む) のベスト プラクティスの集合を指すために使用されます。ただし、アプリケーション操作をサポートするデータベースは、クラウド コンピューティングやクラウド ネイティブの概念が登場する何十年も前から存在していましたが、これらの従来のソリューションのデータ重力により、アプリケーションやワークロードを移動する能力が制限されていました。企業がビジネスをクラウドに移行するにつれて、データ保存方法はどのように進化するべきでしょうか?クラウドネイティブデータベースは必要ですか?クラウドネイティブデータベースとは何ですか?一つずつ答えていきましょう。

クラウドネイティブとは何ですか?

「クラウド ネイティブ」を定義するには、まず「ネイティブ」とは何かを理解する必要があります。個人にとって、「ネイティブ」という言葉は、母国語、国や地域、あるいは自然界における野生動物の本来の生息地（それぞれの種が環境に適応する方法を含む）などの概念を思い起こさせるかもしれません。そのため、クラウドネイティブの意味を理解するためにも、ここから始めます。

Cloud Native Computing Foundation (CNCF) では、この用語を次のように定義しています。「クラウド ネイティブ テクノロジーにより、企業はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの最新の動的環境でスケーラブルなアプリケーションを構築および実行できます。コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などが代表的な例です。これらのテクノロジーにより、疎結合システムの回復力、管理性、監視性が高まり、強力な自動化と組み合わせることで、エンジニアは最小限の労力で高頻度かつ予測的な変更を加えることができます。」

この定義はかなり広範囲ですが、CNCF ランドスケープ マップのデータベース セクションに示されているように、クラウド ネイティブ データベースを定義するのはまだ少し難しいです。

データベースは、広大なクラウドコンピューティング環境のほんの一部に過ぎません。

詳しく調べてみると、従来のリレーショナル データベースや、キー/値、ドキュメント、グラフなど、さまざまなデータ モデルをサポートする NoSQL データベースなど、多種多様な製品があることがわかります。また、既存のデータベース上での階層的クラスタリング、クエリ、またはパターン管理テクニックも含まれます。これには、データ移動のためのストリーミングやメッセージング、永続性のためのクラウドネイティブ ストレージなど、CNCF の世界の他の関連カテゴリは含まれません。

これらのデータベースのうち、クラウド ネイティブなものはどれですか?クラウド専用に設計されたデータベースに加えて、クラウドでの作業に適応できるデータベースもありますか? Bill Wilder 氏は 2012 年に出版した著書「Cloud Architecture Patterns」で、「クラウド ネイティブ」を「クラウド プラットフォームを最大限に活用するように設計されたアプリケーション」と定義するという興味深い点を提唱しています。

この定義によれば、クラウド ネイティブ データベースとは、基盤となるクラウド インフラストラクチャを最大限に活用するように設計されたデータベースです。しかし、この定義も議論の余地があるかもしれません。

データベースがクラウドネイティブであるかどうかを気にする必要があるのはなぜですか?

あるいは別の言い方をすると、クラウドネイティブ データベースの利点は何でしょうか?その中でも、クラウド コンピューティングの人気を牽引する 2 つの主な要因は、コストと市場投入までの時間です。

• コスト– 従量制支払い機能は、クラウドの導入を増やす上で重要です (ただし、クラウド コンピューティングが安価である、またはコスト管理が容易であることを意味するものではありません)。
• 市場投入までの時間- 新しいアプリケーションや機能のプロトタイプ作成、開発、テスト、提供のためにインフラストラクチャを迅速に立ち上げる能力 (ただし、クラウドの開発や運用が容易になることを意味するものではありません)。

スタック選択における他の要素と同様に、これらの目標はデータベース選択にも適用されます。

クラウドネイティブデータベースの特徴は何ですか?

ここで、CNCF の定義を再検討し、コストと市場投入までの時間の目標達成に役立つ方法でクラウド ネイティブ データベースの特性をまとめてみましょう。

• スケーラビリティ- システムは、追加のワークロードを吸収するために容量を動的に増加できる必要があります。
• 弾力性- ユーザーが必要なリソースに対してのみ料金を支払うようにスケールダウンできる必要があります。
• 回復力- システムはデータを失うことなく障害に耐える必要があります。
• 可観測性– アクティビティを追跡する機能、ヘルスチェック、フェイルオーバーを処理する機能。
• 自動化- 運用タスクを繰り返し可能なロジックに変換して、エラーの可能性を減らします。この機能は実装するのが最も難しいですが、大規模な配信速度の向上を実現するために不可欠です。

クラウド ネイティブ データベースはこれらの要件を実装するように設計されており、いくつかの調整を加えることでクラウドに展開できるデータベース (「クラウド対応」データベース) とは区別されます。

クラウドネイティブ データベースを最もよく表すものは何ですか?

この記事では、Apache Cassandra™ を例にして、クラウド ネイティブ データベースの定義について説明します。 Cassandra が開発された当時、「クラウド ネイティブ」という用語はまだ一般的ではありませんでしたが、パブリック クラウド インフラストラクチャ (Amazon AWS の Dynamo 論文や Google の BigTable など) からインスピレーションを得たため、アーキテクチャの影響において多くの類似点があります。この関係により、Cassandra は次の原則を体現します。

• Cassandra はノードを追加することで水平方向のスケーラビリティを実現し、ピーク負荷期間外にはリソースを解放するために弾力的にスケールダウンできます。
• デフォルトでは、Cassandra は AP システムです。つまり、CAP 定理で説明されているように、一貫性よりも可用性とパーティション耐性を優先します。 Cassandra の組み込みレプリケーション、シェアードナッシング アーキテクチャ、および自己修復機能は、回復力の確保に役立ちます。
• Cassandra ノードは、ログ、メトリック、クエリ トレースを公開し、可観測性を実現します。
• 自動化は Cassandra の最も難しい側面であり、データベースによくある問題です。

Cassandra クラスターの初期展開を自動化するのは比較的簡単ですが、スケーリングやアップグレードなどの他のタスクは時間がかかり、自動化が難しい場合があります。結局のところ、多くのデータベース管理者が同意するように、単一ノードのデータベース操作でさえ困難です。幸いなことに、K8ssandra プロジェクトは、Kubernetes に Cassandra をデプロイするためのベスト プラクティスを提供しており、配信後の操作の自動化 (「2 日目」) における大きな進歩も含まれています。

クラウドネイティブデータベースは Kubernetes 上で実行する必要がありますか?

Kubernetes に関して言えば、クラウド内のデータベースについて話すとき、実際には何らかのストレージを必要とするステートフル ワークロードについて話していることになります。しかし、クラウド コンピューティングの世界では、状態は厄介なものです。データの重力は非常に扱いにくいものです。規制や法律上の制限によりデータの移動が困難になり、コストが法外に高くなる可能性があります。

Kubernetes はもともとステートフル ワークロード向けに設計されていなかったため、Kubernetes を使用してコンテナ化されたアプリケーションをデプロイする際の課題は増え続けています。スタック全体を単一のプラットフォームで実行することで開発と運用の効率を最大化するために、Kubernetes 上で実行されるデータベースの展開を推進する新しいトレンドがあります。 Kubernetes ではクラウドネイティブ データベースにどのような追加要件が課されますか?

（１）コンテナ化

まず、データベースはコンテナ内で実行されている必要があります。これは当たり前のことのように聞こえますが、多少の作業が必要です。ストレージを外部化し、メモリやその他のコンピューティング リソースのサイズを適切に設定し、アプリケーション ログとメトリックをインフラストラクチャで監視およびログ集約のために利用できるようにする必要があります。

（２）保管

次に、データベースのストレージ要件を Kubernetes アーキテクチャにマッピングする必要があります。少なくとも、各データベース ノードは永続ボリューム要求を行う必要があり、Kubernetes はこれを使用して適切な容量と入出力 (I/O) 特性を持つストレージ ボリュームを割り当てることができます。データベースは多くの場合、Kubernetes StatefulSets を使用してデプロイされます。これは、ストレージ ボリュームのポッドへのマッピングを管理し、一貫性のある予測可能な ID を維持するのに役立ちます。

（３）自動運転

最後に、インストールやメンテナンスなどのデータベース操作を管理および自動化するためのツールが必要です。通常、これは Kubernetes Operator パターンによって実装されます。オペレーター モード自体は、Kubernetes リソースの状態を監視し、その状態を達成するためのアクションを実行する制御ループです。このように、これらは Kubernetes の組み込みコントローラーに似ていますが、主な違いは、特定のドメインの状態を理解し、Kubernetes がより良い決定を下せるように支援することです。

たとえば、K8ssandra プロジェクトでは、cass-operator を使用します。これは、Cassandra クラスターの各最上位障害ドメインの望ましい状態を記述する「Cassandra Datacenter」と呼ばれる Kubernetes カスタム リソース (CRD) を定義します。これは、ステートフル セットや個々のポッドを扱うよりも高いレベルの抽象化です。

Kubernetes データベース オペレーターは、次のような質問に答えるのに役立ちます。

• フェイルオーバー中に何が起こりますか? (ポッド、ディスク、ネットワーク)
• スケールアウトすると何が起こりますか? (ポッドの再スケジュール)
• バックアップを実行するにはどうすればいいですか?
• 障害を効果的に検出し、防止するにはどうすればよいでしょうか?
• ソフトウェアをアップグレードするにはどうすればいいですか? （ローリングリスタート）

結論は

クラウド ネイティブ データベースは、スケーラビリティ、弾力性、復元力、可観測性、自動化などのクラウド ネイティブの原則に従って設計されたデータベースです。 Cassandra が示すように、自動化は多くの場合最後のハードルですが、Kubernetes でデータベースを実行すると、組織はその目標に近づくことができます。

原題: クラウドネイティブデータベースの探求 (Pieter Humphrey 著)