クラウド ネイティブなアプリケーションについて

クラウドネイティブ アプリケーションは、このガイドの主目的ではありませんが、この最新化成熟度レベルを理解し、クラウド最適化アプリケーションと区別することは有用です。

図 4-3 では、クラウドネイティブ アプリをアプリケーションの最新化成熟度レベルに位置付けています。

クラウドネイティブ アプリケーションの位置付けを示す図。

図 4-3 クラウドネイティブ アプリケーションの位置付け

クラウドネイティブの最新化成熟度レベルでは、通常、新しい開発投資が必要です。 クラウドネイティブ レベルへの移行は、一般的に、アプリケーションを可能な限り最新化して、大規模アプリケーションのスケールを大幅に向上させるというビジネス ニーズによって推進されます。自律したサブシステム (マイクロサービス) を作成することで、アプリケーションの他の領域から独立してデプロイおよびスケーリングでき、長期的にコストを削減し、自律したアプリの部品の進化のアジリティを高めて、競争上の大きな利点が得られます。

クラウドネイティブ アプリケーションの大きな柱はマイクロサービス アーキテクチャ アプローチを基盤としています。これは、アジリティを伴って進化し、オンプレミスまたはクラウドのいずれかの環境にデプロイされたモノリシック アーキテクチャでは実現が困難な制限に合わせてスケーリングすることができます。

図 4-4 は、クラウドネイティブ モデルの主な特性を示しています。

クラウドネイティブの主要な特性を示す図

図 4-4 クラウドネイティブの特性

さらに、人工知能 (AI)、機械学習 (ML)、IoT などの他のサービスを追加することで、基本となる最新の Web アプリとクラウドネイティブ アプリを拡張できます。 これらのサービスを使用して、クラウド最適化の任意のアプローチを拡張することができます。

クラウドネイティブ レベルのアプリケーションの基本的な違いは、アプリケーション アーキテクチャにあります。 クラウドネイティブ アプリケーションとは、定義上、マイクロサービスに基づくアプリです。 クラウドネイティブ アプリには、モノリシック Web アプリケーションや従来の n 層アプリケーションと比較して、特別なアーキテクチャ、テクノロジ、およびプラットフォームが必要です。

クラウドネイティブ アプリケーションの詳細

クラウドネイティブとは、大規模でミッション クリティカルなアプリケーションに対する、より高度な、または成熟した状態です。 通常、クラウドネイティブ アプリケーションでは、既存のアプリケーションを最新化するのではなく、アーキテクチャと設計をゼロから作成する必要があります。 クラウドネイティブ アプリケーションと、より単純なクラウド最適化 Web アプリの主な違いは、クラウドネイティブ アプローチのレコメンデーションではマイクロサービス アーキテクチャを使用することです。 また、クラウド最適化アプリは、モノリシック Web アプリまたは n 層アプリも可能です。

Twelve-Factor App (マイクロサービス アプローチに密接に関連するパターンのコレクション) は、クラウドネイティブ アプリケーション アーキテクチャの要件とも見なされます。

Cloud native Computing Foundation (CNCF) は、クラウドネイティブの原則を推進する主要な団体です。 Microsoft は、CNCF のメンバーです。

クラウドネイティブ アプリケーションを設計および開発する方法の詳しいガイダンスについては、次の無料の電子ブックを参照してください。

アプリケーションをクラウドネイティブ モデルに完全移行する場合に考慮すべき最も重要な要素は、マイクロサービスベースのアーキテクチャに再設計する必要があることです。 この方法は、関係するリファクタリング プロセスが大きいため、開発に多大な投資が必要なことは明らかです。 このオプションは、通常、新しいレベルのスケーラビリティと長期的なアジリティを必要とするミッション クリティカルなアプリケーションに対して選択されます。 しかしながら、ほんのいくつかの新しいシナリオに対してマイクロサービスを追加して、クラウドネイティブへの移行を開始し、最終的にはアプリケーションをマイクロサービスとして完全にリファクタリングすることができます。 この手順は、一部のシナリオで最適なオプションとなる増分アプローチです。

マイクロサービスについて

組織のクラウドネイティブ アプリケーションを検討する際は、マイクロサービスとそのしくみについて理解していることが重要です。

マイクロサービス アーキテクチャは、ゼロから作成するアプリケーションや既存のアプリケーションをクラウドネイティブ アプリケーションに進化させるときに使用できる高度なアプローチです。 新しいマイクロサービス パラダイムについて学習するには、まず、既存のアプリケーションにいくつかのマイクロサービスを追加します。 ただし、この種類のアーキテクチャ アプローチには特に、設計とコーディングが必要なことは明らかです。

ところが、マイクロサービスは、新規または最新のどのアプリケーションでも必須ではありません。 マイクロサービスは "特効薬" ではなく、すべてのアプリケーションを作成するための唯一の最善の方法でもありません。 マイクロサービスを使用する方法とタイミングは、ビルドが必要なアプリケーションの種類によって異なります。

マイクロサービス アーキテクチャは、自律型サービス形式の複数の独立したサブシステムを基にした分散型の大規模または複雑なミッション クリティカルなアプリケーションに対して推奨されるアプローチになりつつあります。 マイクロサービスベースのアーキテクチャでは、アプリケーションは、開発、テスト、バージョン管理、デプロイ、およびスケールを個別に行うことができるサービスのコレクションとして構築されます。 この方法には、関連する自律型データベースをマイクロサービスごとに含めることができます。

.NET を使用して実装できるマイクロサービス アーキテクチャの詳細については、ダウンロード可能な PDF 形式の電子書籍「.NET マイクロサービス: コンテナー化された .NET アプリケーションのアーキテクチャ」を参照してください。 このガイドは、オンラインでも入手できます。

しかし、強力な機能非依存のデプロイ、強力なサブシステムの境界、テクノロジ多様性がマイクロサービスによって提供されるシナリオでも、多くの新しい課題が発生します。 これらの課題は、断片化された独立したデータ モデル、マイクロサービス間の回復力のある通信の実現、最終的な整合性の必要、運用上の複雑さなど、分散型アプリケーションの開発に関連しています。 マイクロサービスは、従来のモノリシック アプリケーションと比較して、より高いレベルの複雑さをもたらします。

マイクロサービス アーキテクチャの複雑さにより、マイクロサービスベースのアプリケーションに適しているのは、特定のシナリオやと一定のアプリケーションの種類に限られます。 たとえば、複数の進化するサブシステムを持つ大規模で複雑なアプリケーションなどです。 このようなケースでは、長期的なアジリティを高め、アプリケーションのより効率的なメンテナンスを実現するため、より複雑なソフトウェア アーキテクチャに投資する価値があります。 ただし、それほど複雑ではないシナリオでは、モノリシック アプリケーションアプローチや、より単純な n 層アプローチを継続する方がよい場合があります。

最後に、この概念について繰り返しが発生するリスクがある場合でも、アプリケーションのマイクロサービスの使用を "全部かゼロか" と見るべきではありません。 マイクロサービスに基づいた新しい小規模なシナリオを追加することで、既存のモノリシック アプリケーションを拡張して進化させることができます。 マイクロサービス アーキテクチャ アプローチの使用を開始するために、ゼロから始める必要はありません。 むしろ、既存のモノリシックまたは n 層アプリケーションを使用し、新しいシナリオを追加することにより進化させていくことをお勧めします。 最終的に、アプリケーションを自律コンポーネントまたはマイクロサービスに分割することができます。 モノリシック アプリケーションからマイクロサービスの方向に段階的に進化を開始することができます。

いずれにしても、このガイダンスの残りの部分では何よりも "マイクロサービスベースのアプリなし" に焦点を当てます。これは、このガイダンスの主な対象が、通常はモノリシックまたは n 層アーキテクチャを持つ既存のアプリの最新化にあるためです。