クラウドネイティブ環境のアーキテクチャーを理解するのはとても大変だったりします。アプリケーション開発者や ソフトウェア／システムアーキテクトの理解を助ける為、これからクラウドネイティブ環境のアーキテクチャーを構成する個々の要素とそれらがどのように連携するかについて説明します。
より理解しやすくするには、アーキテクチャーを4階層に分けて考えるのが有効である事に気がつきました。4階層は、「アプリケーションソフトウェア開発」、「サービスのスケール」、「アプリケーションネットワーク」、「コンテナオーケストレーションプラットフォーム」から構成されます。
この記事では、最初の階層である「アプリケーションソフトウェア開発」について説明します。4階層の概念を視覚化しやすくする為、下記の図を描きました。
コンテナネイティブまたはクラウドネイティブなアプリケーション開発は一般的なグリーン・フィールドシステムと呼ばれ、アプリケーションはマイクロサービスに分割されます。各マイクロサービスの傾向として独自のデータソースがあり、他のマイクロサービスから独立しており、分散して配置されます。
このような実装の利点は、アプリケーションをよりアジャイルかつポリグロットにし、問題を切り分け、コードベースを小さくし、保守を容易にできることです。仮にこのような実装を選択することで今すぐあなたの人生が良くなると伝えたならば、私のメッセージはウソになります。
アジャイルで真にスケーラブルで自動化されたコンテナ/クラウドネイティブシステムのメリットを実現するには、アプリケーション、プラットフォーム、ペルソナといった要素を考慮する必要があります。以下の要素も含まれます:
- シナリオに適したテクノロジを使用する
- 複雑な解決策は過剰である場合があります
- 間違った解決策を間違った場所で使用すると、責務を見失う可能性があります
- 継続的インテグレーションをあわせたドメイン駆動設計
- 非同期のイベントか API
- 既存のブラウンフィールドアプリケーションといかにインテグレートするか
上の図は、コンテナ/クラウドネイティブ システムのさまざまな構成要素がどのように連携して機能するかの大まかな概要を示します。また、特定のテクノロジをいつ導入するか、または導入するかどうかを決めるのにも役立てばと願います。
アプリケーションソフトウェア開発レイヤー
アプリケーションソフトウェア開発レイヤーは、システムに適用されるソフトウェアパターンに関するレイヤーです。ドメインのモデリング、マイクロサービスの定義方法、デプロイ方法、疎結合で継続的に改善するシステムの開発に役立ちます。また、通信技術とアプリケーション間のパターンも含まれます。
サービス スケール - Knative
アプリケーションが使用されていないときにゼロへスケールインできると、リソースの最適化が可能になります。 このレイヤーは、クラウドコンピューティングの特性を最大限に活用しますが、すべてのサービスが必要とするわけではありません。
アプリケーションネットワーク - Service mesh
これは、分散マイクロサービス環境でとても一般的なアーキテクチャ機能です。 このレイヤーを使用すると、マイクロサービス間の通信をより良く、より均一に制御でき、観測性も向上します。 DevOps はこのレイヤーを使用して、一般的なセキュリティ、障害回復、ロールアウトポリシーなどを適用したり、カスタマイズされたポリシーを設定したりできます。 このレイヤーは、開発者の多くの冗長な作業を取り除きます。
コンテナ オーケストレーション プラットフォーム レイヤー - Red Hat OpenShift
クラウドネイティブ環境におけるアーキテクチャの基盤です。 コンテナオーケストレーション、サービスディスカバリ、CI/CD自動化、ロギングなどの基本的かつ不可欠な機能を提供します。
ドメイン駆動設計 と アジャイル インテグレーション
ドメイン駆動設計（domain-driven design: DDD）の原則は、ビジネスユーザーと開発者間のコミュニケーションを改善し、ドメインに従ってオブジェクトをモデル化し、境界を設定して複雑なビジネス要件をセグメント化することにより、クラウドネイティブの世界でアプリケーションを開発する方法に適用されます。 DDDの重要な側面は、継続的インテグレーションです。
アジャイル インテグレーションは、マイクロサービスとDDDの基本概念から発展しました。 ビジネスロジックのモデリングをのぞくソフトウェア開発では、他の多くの要素も考慮する必要があります。 DDDをベースとしたアジャイル インテグレーションにより、モデルと境界だけでなく、異なる機能に関する懸念に基きそれらをどのように分離すべきか、およびそれらを物理的にデプロイする方法を定義するのに役立ちます。 アジャイル インテグレーションには3つの主な責任があります。
- コア - ビジネスロジックまたはドメイン機能を実装するマイクロサービスの大部分は、このカテゴリに属します。 これらは、実行形態およびサービス間の連携方法の両方で軽量であり、典型的に小さくシンプルなマイクロサービスの良い例です
- コンポジット - ここでは、サービスの適切な粒度の設定、トランザクションの処理、さまざまな種類のイベントに対するオーケストレーション、データ変換がすべて処理されます。 このカテゴリでは、データとイベントの集約と分離が行われます。 これは、あるポイントから別のポイントにイベントを適切な形式で伝搬するシンプルでステートレスなパイプとして機能し、場合によっては外部のSaaS、ブラウンフィールドアプリケーション、または境界コンテキスト外のサービスへのゲートウェイである必要があります
- コントロール と ディスパッチ - システムが少数の外部システムとのみ連携する場合、このカテゴリは不要かもしれません。このカテゴリを使用すると、システムが提供するサービスについて、より多くの洞察と意味のあるビジネスコントロールが可能になります。これは、迅速でアドホックな変更を必要とする外部クライアントのリクエストから、常に面倒なカスタマイズを隠すカテゴリです。 ファサードパターンはこのカテゴリに適用されます
上記の原則を適用すると、次のことが可能になります:
- ビジネス要件からモデルとエンティティを抽出します
- ビジネスドメイン間の境界を設定します
- コードの性質を分類し、独立した個別のデプロイ可能なマイクロサービスインスタンスに分けます
別の重要で基本的な問題は、これらのマイクロサービス間の通信です。 これらのマイクロサービスの通信バックボーンには、主にイベント駆動型かつ非同期である必要があるはずです。データの配信を疎結合にでき、システムはリアクティブになります。 欠点は、このタイプの設計ではトランザクションがかなり複雑になる可能性があることですが、これはイベントソーシングなどの手法を実装することで克服できます。 境界または外部クライアント/パートナー間の通信には、以下の理由で APIを使用することを強くお勧めします:
- プロセスのほとんどはリクエスト/レスポンス形式を使用しており、 REST APIの生来の基本動作と合致します
- コントラクトの定義とリポジトリを管理する為の技術は、API分野でより成熟しています
次回は、イベント内に存在するさまざまなタイプのデータとその処理方法、およびクラウドネイティブなアプリケーション環境でデータの一貫性を実現する方法について説明します。 また、今回紹介していない他のレイヤー(サービススケーリング、アプリケーションネットワーク、コンテナーオーケストレーションプラットフォーム)についても説明します。
原文: Introduction to cloud-native application environment architecture By Christina Lin July 2, 2019
