クラウドネイティブデータ管理の謎を解く: 運用レイヤー

著者 |ガウラヴ・リシ

翻訳者 |張峰

レビュー |ノエ

アプリケーションのコンテナ化のペースが加速するにつれて、Day 2 サービスが差し迫った問題になっています。これらの Day 2 サービスには、バックアップ、災害復旧、アプリケーション移行などのデータ管理機能が含まれます。クラウドネイティブアプリケーションコンテナ化のこの新しい世界では、マイクロサービスは複数の場所 (リージョン、クラウド、オンプレミス) にデプロイされることが多く、複数のデータサービス (MongoDB、Redis、Kafka など) とストレージテクノロジを使用してこれらのアプリケーションの状態が保存されます。

このような環境では、従来のインフラストラクチャやハイパーバイザーベースのソリューションは機能しにくくなります。では、クラウドネイティブアプリケーション向けにこれらのデータ管理機能を設計および実装するための適切なアーキテクチャは何でしょうか?ストレージベンダー、データサービスプロバイダー、クラウドプロバイダーが提供するさまざまなデータ管理オプションを分析して、環境とニーズに適したアプローチを決定するにはどうすればよいでしょうか。この記事では、一貫性、ストレージ要件、パフォーマンスなど、複数の属性にわたるさまざまなデータ管理アプローチの長所と短所について詳しく説明します。

用語の定義

まず、テクノロジースタックを分解して簡素化し、クラウドネイティブアプリケーション内でデータがどこに存在するかを示します。

データ管理について考える場合、上の図に示すレイヤーの 1 つ (または複数) を操作できます。これらのレイヤーを列挙してみましょう。

1. 物理的なストレージ

このレイヤーには、不揮発性メモリに状態を保存し、NVMe や SSD デバイスから回転ディスク、さらにはテープまで、物理メディアを選択できるさまざまなストレージハードウェアオプションが含まれています。アレイやスタンドアロンラックサーバーなど、さまざまなフォームファクターがあります。

物理ストレージは次の場所に配置できます。

オンプレミスでは、Seagate、Western Digital、Micron などのベンダーのストレージハードウェアに遭遇する可能性があります。
ホスティングクラウドプロバイダーのデータセンター内。物理デバイスに触れることはなくても、それがクラウドインフラストラクチャの一部であることはご存知でしょう。

2. ファイルとブロックのストレージ

このソフトウェアレイヤーは、基盤となる物理ストレージからの効率的な読み取りおよび書き込み操作を可能にするファイルまたはブロックレベルの構造を提供します。ファイルとブロックの両方のケースで、基盤となるストレージはスタンドアロン (ローカルディスク) または共有ネットワークリソース (NAS または SAN) にすることができます。

ブロックストレージを使用すると、低レイテンシで、iSCSI や FiberChannel などのプロトコルを介してアクセスできるローカルディスクまたはリモートディスクから生のストレージボリュームを作成できます。クラウドプロバイダー上のブロックストレージ実装には、Amazon EBS や GCE Persistent Disk などがあります。
ファイルストレージは、NFS や SMB などのプロトコルを使用して、ファイルのセマンティクスと操作のための共有ストレージを提供します。一般的なオンプレミスのファイルストレージ実装には、NetApp や Dell EMC の製品が含まれます。クラウドプロバイダー上のファイルストレージ実装には、Amazon EFS、Google Cloud Filestore、Azure Files などがあります。

このレイヤーは通常、保護のためにボリュームの特定時点のコピーを作成するスナップショット機能を提供します。さらに、Kubernetes 環境では、このレイヤーはコンテナストレージインターフェイス (CSI) ドライバーを提供して API を標準化し、上位レイヤーがこれらの API を使用してスナップショット機能を呼び出すことができるようにします。すべての CSI 実装がサポートされる機能に関して同等であるとは限らないことに注意してください。

3. データサービス

このレイヤーは、ファイル/ブロックストレージ実装の上に配置されます。さまざまなデータベース実装と、ますます人気が高まっているストレージタイプであるオブジェクト (別名 BLOB) ストレージを提供します。このレイヤーは通常、アプリケーションと対話し、基盤となるデータベース実装はワークロードとビジネスロジックに基づいて選択されます。マイクロサービスベースのアプリケーションでは、各マイクロサービスが現在のジョブに最も適したデータサービスを選択するため、多言語の永続性が標準となります。

一部のデータベースタイプと実装例のサブセットには次のものが含まれます。

SQL データベース: MySQL、PostgreSQL、SQL Server
NoSQL データベース:
キーバリューストレージ: Redis、BerkeleyDB
時系列データベース: InfluxDB、Prometheus
グラフデータベース: Neo4j、GraphDB
ワイドカラムストレージ: Cassandra、Azure Cosmos
ドキュメントストレージ: MongoDB、CouchDB
メッセージキュー: Kafka、RabbitMQ、Amazon SQS
オブジェクトストレージ 1: Amazon S3、Google Cloud Storage、Minio

これらのデータベースには、Database as a Service (DBaaS) システムと呼ばれるホストされたインスタンスもいくつかあります。これらには通常、上記のデータベースカテゴリのいずれかが含まれ、サービスとしての (-aaS) ビジネスの消費経済性を満たしながら自動スケーリングを提供できる場合もあります。 DBaaS システムの例としては、Amazon RDS、MongoDB Atlas、Azure SQL などがあります。

データ保護の観点から、各データベース実装では、データをバックアップおよび復元するための特定のユーティリティセット (PostgreSQL の場合は pg_dump または WAL-E、MongoDB の場合は mongodump など) が提供されます。多くのユーティリティは、一貫性、回復の粒度、速度の点で異なる機能を備えていることに注意してください。スタンドアロンユーティリティとして提供されるか、サービスとして提供されるかにかかわらず、通常は特定のデータベース実装、または最大 1 つのデータベースタイプに制限されます。

4. ステートフルアプリケーション

アプリケーション層はビジネスロジックが存在する場所であり、クラウドネイティブの世界では、アプリケーションは最新のアジャイルに基づいて開発され、分散マイクロサービスとして実装されることがよくあります。ほとんどすべてのアプリケーションには、永続化する必要がある状態があります。アプリケーションの状態を保存するパターンは複数ありますが、ステートフル Kubernetes アプリケーションのコンテキストでは、次の情報をアトミックユニットとして永続化して保護する必要があります。

アプリケーションデータ: さまざまなデータサービス、ブロック、ファイルストレージ実装にわたる複数のコンテナーに分散されます。
アプリケーションの定義と構成: アプリケーションイメージと関連する環境構成は、ConfigMap、Secret などのさまざまな Kubernetes オブジェクトに分散されます。
その他の構成ステータス: CI/CD パイプラインのステータス、リリース情報、関連する Helm デプロイメントメタデータなど。

上の図はステートフルアプリケーションの例であり、保護する必要があるコンポーネントと関連する状態の一部が強調表示されています。実際の展開では、アプリケーションは数百のこのような基礎コンポーネントで構成されていることに注意することが重要です。さらに、クラウドネイティブアーキテクチャでは、保護の最小単位はアプリケーションと、その基盤となるデータサービスまたはストレージインフラストラクチャ層である必要があります。前述したように、アプリケーションの状態は、複数の物理ノードまたは仮想ノードとデータサービスに分散されたアプリケーションデータ、定義、および構成で構成されているためです。

結論は

バックアップ/復元とアプリケーションの移植性の観点から、優れたデータ管理ソリューションではアプリケーション全体をアトミックユニットとして扱う必要があり、従来のハイパーバイザー中心のソリューションはもはや適切ではありません。また、オンプレミスとクラウド実装全体のさまざまなデータサービス、ブロックストレージとファイルストレージ、物理ストレージの観点から、アプリケーションの状態が実際にどこに存在するかを示すシンプルなテクノロジスタック図も示します。これにより、クラウドデータ管理の運用レベルまで掘り下げることができる基本的な範囲が定義されます。

注記

オブジェクトストレージはファイル/ブロックと同じ層に属するべきだと主張する人もいるかもしれません。この記事では、オブジェクトストレージは、必要に応じて Kubernetes で実行できるキー値インターフェイスを備えた単なる別のデータサービスとして扱われます。

オリジナルリンク: https://dzone.com/articles/demystifying-cloud-native-data-management-layers-of-operation