ついに誰かがクラウドコンピューティングとデータベースの関係を明らかにした

[[433700]]

2006年、Google CEOのエリック・シュミット氏が初めてクラウドコンピューティングの概念を提案しました。 2011年にコロンビア大学のストルフォ教授がフォグコンピューティングを提唱し、後にシスコが理論化しました。クラウド コンピューティングは集中型コンピューティングです。 Accenture はクラウド コンピューティングを次のように定義しています。サードパーティ プロバイダーがインターネットを通じて IT 機能 (ハードウェア、ソフトウェア、またはサービス) を動的に提供および構成します。

フォグ コンピューティングは、クラウド コンピューティングの概念を拡張したもので、ローカル エリア ネットワーク向けの分散コンピューティング方法です。これは、インターネットの「分散化」の性質に準拠しています。低レイテンシ、位置認識、広範囲の地理的分散、モビリティ アプリケーションへの適応性により、このコンピューティング パラダイムはより多くのエッジ ノードをサポートできます。

2011 年にエッジ コンピューティングの概念が登場しました。 OpenStack コミュニティは、これを次のように定義しています。エッジ コンピューティングは、データ入力やユーザーの近くでコンピューティング、ストレージ、ネットワーク帯域幅を提供することを目的として、ネットワークのエッジでアプリケーション開発者やサービス プロバイダーにクラウド サービスと IT 環境サービスを提供します。

フォグ コンピューティングとエッジ コンピューティングの違いは、フォグ コンピューティングが階層型のメッシュのようなアーキテクチャを持つのに対し、エッジ コンピューティングはネットワークを形成しない個々のノードに依存することです。フォグ コンピューティングのさまざまなノードには広範なピアツーピア相互接続機能がありますが、エッジ コンピューティングは孤立した島で実行されるノードです。このようなノードは、トラフィックの伝送を実現するためにクラウドまたはフォグ ネットワークに収容されます。

クラウド コンピューティング、フォグ コンピューティング、エッジ コンピューティングは、3 つの異なるものの関連性のあるコンピューティング パラダイムです。各パラダイムでは、データベース システムに異なる要件が課される場合があります。現在、クラウド コンピューティングにおけるクラウド データベースの特性は基本的に調査されていますが、開発も行われています。フォグコンピューティングにおけるフォグデータベースの特性はまだ提案されておらず、エッジコンピューティングにおけるデータベースが従来のスタンドアロンデータベースシステムをわずかに進化させることで得られるかどうかについてもまだ言及も議論もされていません。

ただし、3 つの異なるコンピューティング方法は、異なるタイプのアプリケーションに適しているはずであり、データの保存、管理、コンピューティング、および交換の要件も必ず異なります。さまざまなアプリケーションのニーズと特性を徹底的に調査することで、さまざまな種類のデータベースが作成されます。将来、データベースの種類や形態は必然的に多様化します。

1. クラウドネイティブ

クラウド ネイティブの概念が登場するずっと前から、Cloud Foundry の概念が登場しており、その内容は 12-Factor App と呼ばれる方法論としてまとめることができます。これら 12 の要素に基づいて、データベースに対する次の具体的な要件が提唱され、データベースのアーキテクチャと機能が変更されました。

• 12 ファクター アプリの展開は、ローカルの MySQL データベースをサードパーティのサービス (Amazon RDS など) に置き換えることで、コードを変更せずに実行できるはずです。同様に、ローカル SMTP サービスもサードパーティの SMTP サービス (Postmark など) と交換可能である必要があります。これにより、クラウド アプリケーション開発のデータベース システムへの依存度が低下し、クラウド データベース間の機能差別化の競争が排除されます。
• 12 の要因は、会話への高い粘着性に反するものです。セッション内のデータは、Memcached や Redis などの有効期限付きのキャッシュに保存する必要があります。これには、クラウド データベース サービスで、さまざまな機能をサポートする複数の製品を用意するか、単一の製品内で有効期限付きのキャッシュを提供する必要があります。
• 12-factor アプリケーション自体は、独自の出力ストリームを保存することを考慮しません。つまり、ログ機能を提供することは推奨されません (ログ ファイルを書き込んだり管理したりしません) が、情報は標準出力 (stdout) イベント ストリームに直接出力されます。開発環境では、開発者はこれらのデータ ストリームを使用して、端末上でアプリケーションのアクティビティをリアルタイムで確認できます。アプリケーション側でログを提供して問題を確認できないと、サーバー側のデータベースに高い要求が課せられます。まず、データは保存されずに強力な一貫性が維持される必要があります。 2 番目に、データベース自体が等位置問題を分析する能力を持っている必要があります。ただし、すべてのタイプのアプリケーションがこの種の設計と実装に適しているわけではありません。大規模で複雑なアプリケーションや Web サイト アプリケーションの場所の問題は、主にログに依存します。

2017年、Matt Stine氏がテクノロジーカンファレンスでの講演で「Cloud Foundryとマイクロサービス：共生関係」というコンセプトを提唱し、クラウドネイティブの概念が正式に誕生しました。彼はクラウド ネイティブの 6 つの特性、つまりモジュール性、可観測性、展開可能性、テスト可能性、置き換え可能性、処理可能性をまとめました。

Matt Stine は、サービスの基本原則は、明確な焦点 (アプリケーションの機能分割の要件)、明確な契約 (アプリケーションとバックグラウンド サービス間のインターフェイス定義が明確であること)、および明確な API (アプリケーションとバックグラウンド サービス間のインターフェイスが明確で使いやすい形式であること) を持つことであると考えています。

クラウド ネイティブは、DevOps、継続的デリバリー、マイクロサービス、アジャイル インフラストラクチャ、コンウェイの法則など、さまざまな要素と、ビジネス機能に基づく企業の再編成を含むアイデアの集合体であると考えられることがよくあります。

これにより、クラウド ネイティブの概念は包括的かつ複雑になり、テクノロジ (マイクロサービス、アジャイル インフラストラクチャ) と管理 (DevOps、継続的デリバリー、コンウェイの法則、再編成などのレベルからのテクノロジの管理) の両方を含むテクノロジとエンタープライズ管理方法の集合体になります。

クラウドコンピューティングは従来のアプリケーション方法を変えており、その独自の特徴は次のとおりです。

1. スケール

IT 設備は、分散型から集中型、大規模型へと移行しています。社会全体に集中的なサービスを提供するためのインフラとして、大規模なデータセンターが数多く構築されています。

2. リソースのプール

IT 設備が拡張された後は、弾力性のあるサービスの要件に基づいてハードウェア リソースを統一的に管理する必要があります。ビジネス規模は動的かつ瞬時に拡大および縮小できる必要があるため、弾力性のあるサービスを提供するためにハードウェア リソースをプールする必要があります。

クラウド コンピューティングは、インターネットを通じてユーザーにオンデマンドの IT リソース サービスを提供する試みです。したがって、クラウド サービス プロバイダーは、ピーク時の同時業務時間中にユーザーのサービス要件を満たすことができるように、提供するハードウェア リソースに十分な容量を持つリソース プールを確保する必要があります。これはクラウド サービスのリソース プーリングです。

サービスとしては、クラウド データベースはクラウド コンピューティングに似ており、管理および使用できるリソースもプールする必要があります。このように、ユーザーはクラウド データベース サービスを使用する際に、クラウド データベースの実際のアーキテクチャや技術的な実装を理解する必要がありません。ユーザーが認識するのは、独立した完全なデータ管理サービスと、それに対応するコンピューティング リソースです。

ユーザーにとって、リソース管理は、マルチテナント機能の実現としてクラウド データベースに反映され、テナントがレンタルしたリソースに基づいてサービスが提供されます。データベースの内部リソースがプールされた後、ユーザー アプリケーションに弾力的なスケーリング サービスを提供できます。

3. サービス指向

クラウド コンピューティングにより、IT 業界がこれまで提供できたものが変わりました。

• 配信方法はソフトウェア配信からサービス配信に移行しました。ユーザーは 1 つのソフトウェアを使用しているように見えますが、実際には 1 つのソフトウェアだけではありません。一連のソフトウェアをサービスとして統合し、ユーザーに提供します。ユーザーにとっては、それぞれの具体的なサービスを直接体感することができます。
• 開発手法は、最下層（IaaS+PaaS）から最上層（SaaS）へと移行します。クラウドコンピューティングは、CPUやラックを提供するだけではなく、ユーザーが実感できるソフトウェアサービス（SaaS）を提供すること、あるいはソフトウェアは実感できず、直接感じられるのはサービス（サーバーレス）であることです。

4. 多様化

データ形式とアプリケーション シナリオは、単一から多様化へと移行しています。サービスやマイクロサービスはすでに形を整えており、FaaS（Function-as-a-Service）としてのサーバーレスは、世界の多様性と興奮に貢献し始めています。

2. クラウドデータベース

クラウド アプリケーションの研究開発ニーズを満たすために、クラウド上でサービスを提供するデータベース システムにもそれに応じた変更が加えられています。クラウドネイティブ データベースとは、クラウド プラットフォームを通じて構築、展開、配信され、自動的に運用されるデータベース サービスを指します。

このサービスは通常、DBaaS (Database-as-a-Service) の形式をとっており、データベースのアーキテクチャと実装の詳細を隠し、マルチテナントと効果的なリソース配分の形でクラウド リソースを自動的に管理し、ユーザーに弾力的なスケーリング、高可用性、高信頼性、高セキュリティ、強力な一貫性の要件を満たし、いつでもどこからでもアクセスできるデータベース サービスを提供します。

このサービスは、自動化された運用・保守機能（最小限の人員で対応可能）を備えており、自動バックアップ・リカバリ、自動パフォーマンスチューニング、大規模データベースクラスタのリソース自動調整など、従来のDBAの業務を超えた機能（インテリジェントデータベースの特徴）を提供できます。この機能により、クラウド データベース システムのホスティングと保守のコストが削減され、リソースの使用率が大規模に向上します。

一般的に、クラウド データベースの特徴は、ユーザーの解放とビジネスへの適応という 2 つのカテゴリにまとめることができます。具体的には、以下の 6 つの項目に変換できます。最初の 3 つはユーザーを解放するカテゴリに属し、最後の 3 つはビジネスに適応するカテゴリに属します。

1. インテリジェントな運用と保守（インテリジェントデータベース）

障害は、ダウンタイムの自動移行、障害の分離、異常なトラフィックの自動スケジュール、負荷分散、自動フロー制限と劣化など、自己修復できます。データベースは自動的に調整され、リソース使用量が自動的に調整され、アプリケーションの負荷に対処するための適応アルゴリズムを備えています。このような機能は、自己チューニング、自己適応、自律運転としてまとめることができます (業界では自律運転の基準を 6 つのレベルに分け、データベース業界ではこれらのレベルを借用してデータベース自律運転の概念を定義しています)。

2. 管理が簡単

インテリジェントな運用と保守の現れは、管理の容易さです。クラウド データベースは、異常を自動的に分析および診断する機能を備えており、運用および保守においてホワイト スクリーン、インテリジェント、スケーラブル、および無人運用を実現できます。

3. 究極の体験

ユーザーは、データベース内の障害を最も簡単な方法で申請、作成、監視、警告、特定することができ、非常に便利なエクスペリエンスをユーザーに提供します。

4. 弾性スケーリング

ビジネスのアプリケーション負荷に応じて自動的に拡張でき、数秒で容量を拡大縮小でき、リソースを柔軟かつ動的に割り当てたり解放したりすることができ、柔軟な課金戦略と組み合わせることで、ユーザーの使用コストを大幅に削減できます。この記事の内容は、インテリジェントな運用と保守と一部重複していますが、問題を説明する角度が異なります。この記事では、システムのスケーラビリティの観点からクラウド データベースの重要な機能について説明します。

ビジネスやシステムをクラウドに移行することは、将来に備える可能性を購入することです。事業展開中の商人にとって、データが蓄積するにつれて、クラウド上でいつでもストレージを拡張でき、コンピューティングノードを自由に拡張できます。これは、小規模から大規模に成長している商人にとって、リソースを最大限に活用し、コストを最も低く抑える方法です。

こうしたビジネス展開を支えるテクノロジーが、エラスティックスケーリングです。エラスティックスケーリングでは、トランザクションの実行順序を考慮する必要があります。データベース アーキテクチャの場合、この順序はストレージとコンピューティングの分離を意味します。

5. 従量課金制

トラフィック、ストレージ容量、通話回数、通話時間、コア数、メモリリソース使用量などの数量に基づいて複数の価格戦略を策定できるため、ユーザーはビジネス状況に応じて最適な計測モードを柔軟に組み合わせて、ユーザーコストを節約できます。

6. セキュリティとリソースの分離

クラウド データベースは共有プーリング テクノロジを使用して、コンピューティング、ストレージ、ネットワーク、およびその他のリソースの使用率を向上させ、リソースの同時競合からユーザーを分離します。さらに、安全な分離を実現し、情報漏洩や攻撃などを回避するためのマルチテナント方式も提供します。

上記の内容は、クラウド データベースの設計の方向性を示しています。

3. サーバーレスデータベース

サーバーレスはサーバーレスアーキテクチャです。これは特定のプログラミング フレームワークやツールではなく、ソフトウェア システム アーキテクチャのアイデアと方法です。その中心的なアイデアは、ユーザーがアプリケーション サービスの動作をサポートする基盤となるホストに注意を払う必要がないようにすることです。ユーザーは、アプリケーションのニーズに応じて基盤となるサーバー (ハードウェアおよびソフトウェア システム) をオンデマンドで使用し、使用量に応じて料金を支払うことができます。サーバーレス アプリケーションに必要なコンピューティング リソースは、基盤となるクラウド コンピューティング プラットフォームによって動的に提供されます。

クラウド ネイティブ データベースは、バックエンド サービスとして、ユーザーを接続するデータベース サービス/アクセス メソッド (サーバーレス方式) を提供します。ただし、Serverless はデータベースに接続するためのサービス メソッドであるだけでなく、他の種類のサービスに接続するためのサービス メソッドでもあります。サーバーレスとクラウド データベースはどちらもサービス機能です。クラウド データベースは、データの保存、管理、コンピューティング機能をユーザーに提供されるサービスに変換します。

サーバーレス機能を備えたデータベース システムは、ストレージ レベルで無制限のデータ ストレージ容量の問題を解決する必要があります。コンピューティングレベルでは、弾力性のあるコンピューティング機能を提供する必要があります。システムの内部アーキテクチャに関しては、リソースの割り当てを動的に行えるように監視およびスケジュール機能を提供する必要があります。データベースの各コンポーネントはプール可能、つまりリソー​​スを自動的に管理できる必要があります。ユーザー アクセス レベルでは、ユーザー アクセス イベント要求に応答でき、アクセス数に応じて、前述のストレージ、コンピューティング、管理基盤を使用して、アプリケーション レイヤーでのピークや谷に対応するために容量を弾力的に拡大または縮小し、使用量に応じて課金できる必要があります。

クラウド データベースがサーバーレス アーキテクチャの機能を備え、サーバーレス データベースに依存するアプリケーションをサポートできる場合、そのデータベースは ServerlessDB と呼ばれることがあります。サーバーレス機能を構築する場合、クラウド データベースには次の特性が必要です。

• 単一の責任: このクラウド データベースのビジネスは独立しており、担当チームは自律的です。クラウド データベースは単一のサービスを担当し、そのサービスはコア領域にあります。クラウド データベースは、凝集性が高く、結合度が低く、他のシステムやドメインとの境界が明確であるという特徴があります。
• 軽量通信: クラウド データ間の通信は、シンプルで軽量であり、言語やプラットフォームに依存しない必要があります。
• 独立性: クラウド データベースは独立して開発、テスト、展開される必要があります。

図 6-1 は、AWS Aurora のサーバーレス機能を示しています。

図6-1 Auroraデータベースにはサーバーレス機能がある

アプリケーション層では、Aurora は関数またはイベントを通じてサービス プラットフォームに接続できます。たとえば、AWS の API インターフェースは AWS の Lambda 関数またはサーバーレス関数をトリガーし、データベース テーブルからデータ ストリームを取得します。データがアプリケーションに返されるとき、形式は固定されます。クラウド コンピューティング ベンダーによって設計ソリューションは異なりますが、使用するアイデアは似ています。

著者について: Li Haixiang (ニックネーム: Na Hai Lan Lan)、Tencent Financial Cloud Database の主任研究員、Tencent T14 レベルの専門家、Tencent TDSQL 分散データベースの主任設計者。中国人民大学および北京林業大学の優秀な修士課程講師、CCFデータベース委員会メンバー、DTCC（中国データベース技術会議）専門委員会メンバー、北京科学技術進歩一等賞受賞者。 70件以上の特許を申請・取得し、VLDBなどのデータベースカンファレンスで数々の論文を発表し、国家863重点プロジェクト、国家重点研究開発計画、工業情報化部、科学技術部などの多くのプロジェクトに参加しています。

この記事は「分散データベースの原則、アーキテクチャ、および実践」から抜粋したもので、出版社によって承認されています。