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

著者 |ガウラヴ・リシ

翻訳者 |張峰

レビュー |ノエ

アプリケーションのコンテナ化のペースが加速するにつれて、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

翻訳者について

51CTOコミュニティの編集者である張鋒氏は、運用保守/クラウドネイティブ分野を中心に長年技術コンサルタント業務に従事してきました。彼はネットワークのトラブルシューティングに精通しており、大手銀行向けの運用・保守ツールの構築において豊富な実務経験を持っています。