クラウドネイティブ データ システムの設計上の考慮事項

クラウドネイティブ データ システムの設計に関しては、使用すべき特定のホスティング インフラストラクチャ、プログラミング言語、または設計パターンはありません。クラウド ネイティブ システムにはさまざまなサイズと形態があります。ただし、ほとんど同じクラウド ネイティブ設計原則に従うシステムもあります。クラウド ネイティブ アーキテクチャ、留意すべき設計原則、優れたクラウド ネイティブ プラットフォームを構成する特性について見てみましょう。

クラウド ネイティブ アーキテクチャ クラウド ネイティブ アーキテクチャは、本質的にはクラウド用に構築されたアプリケーションの設計パターンです。特定の実装や事前定義されたクラウド ネイティブ設計はありませんが、最も一般的なアプローチは、アプリケーションを複数のマイクロサービスに分割し、各マイクロサービスが異なる機能を処理することです。各マイクロサービスは小規模なチームによって保守され、通常はコンテナとしてデプロイされます。

マイクロサービスを採用するクラウド ネイティブの設計と開発は、アプリケーションのさまざまな部分が独立して開発、運用、およびデプロイされる、疎結合アーキテクチャに依存しています。これは通常、マイクロサービスの使用を通じて実現されます。

マイクロサービスはクラウドネイティブ システムの基盤であると言っても過言ではありません。コンテナを使用することで、ランタイム環境とそのライブラリ、バイナリ、依存関係を論理的で管理しやすい単位に凝縮することで、真のメリットを享受できます。したがって、アプリケーション サービスは必要に応じて保存、コピー、転送、および使用できます。

モノリシック アプリケーションとは異なり、マイクロサービスは小さな独立したサービスで構成されます。

マイクロサービス (ま​​たは疎結合アーキテクチャ) の使用は、さまざまな理由からクラウド コンピューティングにとって重要です。たとえば、シンプルさ、スケーラビリティ、弾力性を促進します。なぜそうなるのかを詳しく見てみましょう。

このアーキテクチャにより、複雑なアプリケーションをより小さな独立した部分に分割できるため、アプリケーション開発サイクルがシンプルで管理しやすくなります。言うまでもなく、アプリケーション構成を基盤となるコードから分離すると、アプリケーションの開発と保守もはるかに容易になります。同様に、コア アプリケーションをバックエンド サービスから分離することで、コードベースを独自のペースで進化させ、拡張できるようになります。

また、モノリシック アプリケーション全体をスケールアップまたはスケールダウンするよりも、アプリケーションの個々の部分をスケールアップまたはスケールダウンする方が簡単 (かつ高速) です。同様に、アプリケーション全体の新しい更新バージョンを再度デプロイするのではなく、変更が必要な部分 (またはマイクロサービス) のみを更新すればよいため、アプリケーションの更新が簡単になります。

マイクロサービスを採用すると回復力も向上し、アプリケーションの信頼性も高まります。マイクロサービス アーキテクチャ内の 1 つのコンポーネントに障害が発生しても、アプリケーション全体がクラッシュすることはありません。また、Infrastructure as Code も促進され、自動展開への道が開かれます。最後に、マイクロサービス アーキテクチャは、API を介してステートレス プロセスとコンポーネントを使用して各マイクロサービスを他のサービスから分離し、セキュリティと効率性を向上させます。

アプリケーションが疎結合アーキテクチャに従うようにするには、異なる部分間で密結合の依存関係が形成されないようにする必要があります。たとえば、2 つのマイクロサービスが同じデータベースに依存してはなりません。そうなってしまうと、独自に更新したり操作したりすることができなくなってしまいます。

すべてをコードとして 最新のアプリケーションの利点を活用するにはマイクロサービスを使用することが重要ですが、自動化のプラクティスを採用することも同様に重要です。その目的は、開発者とユーザーの両方に利益をもたらすようにアプリケーション開発プロセスを最適化することです。この目的を達成するために、最終的な目標は EaC (Everything as Code) を実現することです。 EaC は、アプリケーション コード ベース、インフラストラクチャ、プラットフォームを含む IaC のさらに進んだステップと考えてください。

このアプローチには多くの利点があります。たとえば、システムのスケーラビリティが向上し、障害の可能性が低減します。また、開発プロセスを高速化することで、開発コストの削減、開発エクスペリエンスの向上、市場投入までの時間の短縮も実現します。さらに、API を通じてユーザーとアプリケーション間の通信を容易にするだけでなく、内部プロセスの自動化と通信も容易にします。

クラウド ネイティブの設計原則 クラウド ネイティブ アプリケーションは通常、12 要素アプリケーション フレームワークで定義された原則に従い、セキュリティ、回復力 (および可用性)、弾力性、パフォーマンス (スケーラビリティを含む) を中心に構築されます。これらのクラウド ネイティブ設計の原則を詳しく見てみましょう。

スケーラビリティ スケーラビリティの考え方は、需要と負荷の増加に対応するために、アプリケーションと関連サービスに追加の容量を追加できるようにすることです。特にスケーラビリティを考慮して設計する場合は、各アプリケーション層、スケーリング方法、ボトルネックの回避方法を考慮する必要があります。

この文脈では、容量、負荷、データという 3 つの重要な側面を考慮する必要があります。

容量に関しては、各層を拡張する必要があるかどうか、またアプリケーションの可用性に影響を与えずに拡張できるかどうかを考慮する必要があります。また、サービスをどれだけ迅速にスケールアップできるか、また、業務に影響を与えずに業務時間外にアプリケーションをスケールダウンできるかどうかも考慮する必要があります。

データ側では、トランザクション スループットやデータベース サイズなどのサービスの制約を念頭に置いて、スケーリングできるかどうかを検討します。プラットフォームの制限内でスケーラビリティをさらに向上させるために、データをパーティション分割する方法を理解します。同様に、プラットフォーム リソースを効果的かつ効率的に使用する方法を検討する必要があります。

負荷側では、ボトルネックを回避するために設計を改善する方法と、ピーク時の負荷分散に役立つ非同期操作の使用方法を決定する必要があります。また、選択したプラットフォームが提供するさまざまなレート バランシング機能と負荷分散機能の使用方法についても検討する必要があります。

スケーラビリティを確保する 1 つの方法は、いつでも拡張、修復、展開できる自動化されたプロセスを作成することです。意味のあるログ (およびイベント) を生成するようにシステムを設定すると、それをフックとして使用してさまざまな自動化アクティビティを実行できます。結果として得られるシステムは、マシンインスタンスなどのインフラストラクチャを自動的にプロビジョニングし、CI/CD パイプラインのさまざまなステージを構築、テスト、デプロイし、動的スケーリング、ヘルスモニタリング、バックアップを処理できる必要があります。

クラウドネイティブ システムはステートレスであるべきだと多くの人が考えていますが、実際のアプリケーションではこれを実現するのは困難です。ただし、分散アプリケーションで状態を管理するのは難しいため、できるだけ多くの場合、ステートレス コンポーネントを使用するのが最適です。これは、ステートレス コンポーネントにより、読み込み、バランス調整、スケーリング、修復、ロールバックが容易になるためです。

可用性 可用性とは、基盤となるオペレーティング システム、ハードウェア、ネットワーク依存関係、またはアプリケーション自体に障害が発生した場合でも、システムがユーザーにとって有用な状態を維持する能力を指します。重要な原則には、パフォーマンス、稼働時間、災害復旧、レプリケーションが含まれます。

パフォーマンスに関しては、許容可能なパフォーマンス レベル、その測定方法、パフォーマンスが許容レベルを下回ったときにトリガーされるアクションまたはイベントを定義する必要があります。また、アプリケーションの中で問題が発生する可能性が最も高い部分を特定し、キュー中心の設計や自動スケーリングがそれらの問題の解決に役立つかどうかも特定する必要があります。また、クラウド ネイティブ システムの一部を非同期にするとパフォーマンスが向上するかどうかを判断する必要があります。

可用性の保証も考慮すべき重要な要素です。特に、製品が満たすべきサービス レベル アグリーメント (SLA) と、選択したクラウド サービスがそれらを満たすことができるかどうかを定義する必要があります。一方、災害復旧に関しては、システム障害が発生した場合にクラウドベースのシステムをどのように再構築するか、そのシナリオでどの程度のデータ損失を許容できるかを決定します。また、システム障害が発生した場合にバックアップ、転送キュー、およびメッセージをどのように処理するかを決定し、仮想マシン イメージをどこに保存するか、およびそれらをバックアップするかどうかを決定する必要があります。

最後に、レプリケーションに関しては、システムのどの部分が障害のリスクが高いか、またどの部分が障害の影響を最も受けるかを判断する必要があります。また、データのレプリケーションが必要かどうか、破損したデータのレプリケーションを防ぐ方法を決定します。

セキュリティ クラウドネイティブ データ システムのセキュリティは、多くの領域をカバーするかなり広範なトピックです。しかし、最も重要なのは、次の点を把握することです。

インデックスとフェイルオーバー データが保存されている国を含む、データの場所の法的管轄権と法的規定。ハイブリッド クラウド アプリケーションを使用する場合、クラウドと企業ネットワーク間のリンクをどのように保護しますか。フェデレーション セキュリティに関して満たすべき要件はありますか?クラウド プロバイダーの管理ポータルへのアクセスを制御し、パスワードの変更を処理し、データベースへのアクセスを制限する方法。ベンダーおよびオペレーティング システムのセキュリティ更新とパッチを処理する方法。管理性 管理性とは、システムのパフォーマンスと健全性を理解し、操作を管理する能力を指します。クラウドに関しては、導入と監視という 2 つの原則を考慮する必要があります。

展開に関しては、考慮する必要がある問題がいくつかあります。たとえば、デプロイメントを自動化する方法や、稼働中のシステムに影響を与えずにパッチを適用または再デプロイメントする方法を検討します。また、デプロイメントが成功したかどうかを確認する方法と、デプロイメントが失敗した場合にロールバックする方法も検討してください。同様に、展開には、必要な環境の数と、それらに必要なストレージ スペースと可用性を決定することが含まれます。

一方、監視側では、アプリケーションをどのように監視するか (既成のサービスを使用するか、独自のサービスを作成するか)、監視データを物理的にどこに保存するかを計画する必要があります。また、監視計画で生成されるデータの量と、メトリック ログにアクセスする方法を決定する必要があります。また、ログ データを失っても大丈夫かどうか、実行時に監視レベルを変更する必要があるかどうかも自問してください。

実現可能性最後に、実現可能性には、時間と予算の制約内でシステムを維持および提供する能力が含まれます。この原則については、次の点を考慮する必要があります。

サービスレベル契約を満たすことは可能ですか?たとえば、クラウド プロバイダーは顧客に提供する必要がある可用性を保証していますか?クラウド アプリケーションを社内で構築するために必要な経験とスキルをお持ちですか? それとも、サードパーティにアウトソーシングする必要がありますか?クラウド プロバイダーの価格設定の複雑さの中で、どのようなトレードオフを受け入れられるでしょうか。また、運用コストにいくら費やすことができますか。優れたクラウド ネイティブ データ プラットフォームの特徴 これで、クラウド ネイティブ プラットフォームを作成するときに留意すべき原則とアーキテクチャ上の考慮事項について理解できました。それでは、優れたプラットフォームが提供すべきその他の機能について見ていきましょう。適切に設計されたクラウドネイティブ プラットフォームの利点。

適切に設計されたクラウドネイティブ プラットフォームの利点 (出典)

コスト効率 完全に管理されたクラウド サービスと自己管理型のオンプレミス サービスの間には大きな違いがあることは間違いありません。ただし、前者の弾力性とほとんどのクラウド プラットフォームの従量課金モデルにより、リソース (およびコスト) の無駄を最小限に抑えながら適切なサイズのシステムを実行することが可能になります。

つまり、未使用のリソースに対して追加料金を支払う必要はなく、容量計画を立てる必要もありません。さらに、クラウド プラットフォームのマルチテナント性により、サービス プロバイダーは、サービスを自社で管理する場合よりも低コストでサービスの価格を設定できます。

使用した分だけ支払う 前述のように、ほとんどのクラウド プラットフォームは従量課金モデルを採用しており、事前に構成されたリソースに対して支払うのではなく、実際に使用したリソースに対してのみ支払います。これらのリソースは、高レベル（API リクエストやレスポンスなど）または低レベル（メモリや CPU 使用量など）のいずれかになります。したがって、オンプレミスのデータと比較して、使用しない可能性のあるライセンス コアに対して料金を支払う必要がありません。

弾力性と拡張性に優れたクラウドネイティブ プラットフォームには、簡単な API 呼び出しやクリックで自動的に拡張できるサービスも含まれます。定義されたポリシーに基づいてプラットフォームがサービスを自動的に拡張できれば、さらに良いでしょう。事前に管理された容量計画と柔軟なスケーリングにより、スケーラビリティの制限は極端な場合にのみ発生します。

可用性効率の高いクラウドネイティブ プラットフォームは可用性も高く、ほとんどの障害に対処できるように設計されています。ほとんどのプラットフォームは、少なくとも 99.95% のサービス レベル アグリーメントを提供しています。これは、1 年間のダウンタイムが 4.5 時間以下であることを意味しますが、実際には、はるかに高い可用性が期待できます。

マルチテナント マルチテナントには、管理性と規模の経済性の 2 つの利点があり、ほとんどのクラウド ネイティブ サービスがその恩恵を受けています。クエリやリクエストとしてサービスを提供する S3 のようなサービスを使用すると、最高のユーザー エクスペリエンスを提供できます。すべてのテナントは適切に分離されており、ユーザーは他のテナントも同じ物理システムを使用していることに気付きません。

はい、場合によっては、ユーザーはメモリや CPU などの専用のコンピューティング リソースを購入する必要があります (AWS Aurora の場合など)。ただし、ストレージやネットワークなどの基盤となるインフラストラクチャは、引き続き共有されます。

パフォーマンスの最適化 最後に、さまざまな種類の顧客ワークロードを処理できるようにするには、システムが複数の次元で拡張可能である必要があります。制約は、ハードウェア、オペレーティング システム、アプリケーションを含むインフラストラクチャ全体にわたって調整および最適化する必要があります。さらに、ホスト型システムの場合は、運用環境との緊密なフィードバック メカニズムが必要です。システムには、さまざまなスケーラビリティおよびパフォーマンス関連のイベントを分析して学習し、パフォーマンスを最適化するための改善を展開する機能も必要です。