クラウドアプリケーションアーキテクチャパターン

結論

本書では、クラウド上でうまく動作するアプリケーションをアーキテクトし設計する方法と、既存のアプリケーションをクラウドに移行する一環としてモダナイズする方法を紹介した。 本書のパターンを適用することで、ユニバーサルアクセス、共有リソース、分散コンピューティング、仮想化コンピューティング、エラスティック・コンピューティング、マルチテナンシー、セルフサービス、API駆動、マルチクラウドといったクラウド・コンピューティングの特質を活かしたアプリケーションを生み出すことができる。学んだこと、これらのパターンの適用方法、そして次に来ることを復習しよう。

我々が学んだこと

クラウド・コンピューティングは従来のITとは異なる。 クラウド向けのアプリケーションには、クラウド・コンピューティングにより適したアーキテクチャと設計が必要であり、アプリケーション開発者は新しい一連のプラクティスを体現する考え方を採用する必要がある。 我々のパターンは、これらのプラクティスを実証してきた。

これらのパターンを取り入れた利点は、クラウド・コンピューティングが体現する特性を補い、活用することである。これらの特性には、信頼性の低いインフラ、最終的な一貫性、汎用ハードウェア、アプリケーションの可動性、マルチテナンシー、水平スケーリング、ステートレス性、不変性、コンポーネント化、サービスカタログ、クラウドデータベース、セルフプロビジョニングなどが含まれる。 このような特徴を考えると、クラウドアプリケーションのアーキテクトに1つの正しい方法はない（第1章）。

このパターンは、クラウド上でアプリケーションをうまく動作させるための決断に役立つ。これらの決定には、以下のようなものがある：

モノリスか分散か

アプリケーションはどこまでモノリシックであるべきか、分散モノリスであるべきか？モノリスの方が簡単な場合はモノリスとしてスタートし、有利になった時点で分散型に変えることもできる。分散アーキテクチャがモノリシックアーキテクチャよりも有利になりつつあることを、どのようにして知ることができるのか？複数のチームがアプリケーションのさまざまな部分で作業する必要があるとき、そして、技術的負債を制限した保守可能なコードを作成することが、新しい機能をできるだけ早くハックすることよりも重要になるときだ。アプリケーションアーキテクチャ（第2章）を参照のこと。

クラウドネイティブ

クラウド・コンピューティング上でうまく動作させるためには、アプリケーションの設計にどのような品質を組み込むべきなのだろうか？アプリケーションはステートレスである必要も、複製可能である必要も、アプリケーション・パッケージにバンドルされている必要も、サービスAPIで公開されている必要もない。実際、伝統的なITアプリケーションのほとんどは、このような性質を持っていない。しかし、アプリケーションにこれらの性質があればあるほど、クラウドでの動作は向上する。Cloud-Nativeアプリケーション（第3章）を参照のこと。

マイクロサービス

分散アーキテクチャを開発する際、どのコンポーネントをマイクロサービスとして開発すべきか、またその理由は何か？マイクロサービスとして設計されたコンポーネントは、独立して開発・デプロイでき、独立して拡張・障害することができる。アプリケーションをいくつの異なるマイクロサービスに分解すべきか、また各マイクロサービスのスコープはどうあるべきかを知るにはどうすればよいか？ドメイン内のビジネス機能がどのように相互作用するかをモデル化する。そして、各ビジネス機能を ...