クラウドネイティブアーキテクチャ実装ロードマップの分析

クラウドネイティブアーキテクチャシステムには多くのコンテンツが含まれています。マイクロサービス、コンテナ、DevOps、サービスメッシュ ServiceMesh、セルフサービスアジャイルインフラストラクチャ、カオスエンジニアリング、セキュリティなどのコンテンツを詳しく調べると、やるべき作業がたくさんあります。たとえば、マイクロサービス。 SpringCloud 開発フレームワークのセットには多くの学習コストが必要であり、マイクロサービス分割のドメイン駆動設計 (DDD) 方式など、他の多くのフレームワーク、メソッド、アイデアがあることは言うまでもありません。

クラウドネイティブコンテンツは 1 つのステップでは実現できないほど多く、コンテンツ間にはシーケンス相関関係があります。クラウドネイティブの統合アーキテクチャを実現するには、関連する機能を継続的に完了するための一連のプロジェクトが必要です。クラウドネイティブアーキテクチャシステムは多くのコンテンツを含んでいるため、それについて比較的深い理解を持ち、企業の実際の状況に基づいてトップレベルの実装計画を立てることができる必要があります。そして、システム全体の構築が持続可能となるよう、構築しながら価値を提供する段階的な実装アプローチを採用します。

図 1: クラウドネイティブ統合アーキテクチャの実装手順

クラウドネイティブアーキテクチャシステムの技術と実際の経験との関係に基づき、「トップレベルの計画+段階的な実装」の原則に基づいて、クラウドネイティブアーキテクチャ実装ロードマップを5つのステップとして定義します。

マイクロサービスは、運用環境としてコンテナクラウドプラットフォーム上に採用され、構築されます。
サービス管理とガバナンス。
継続的な配信とセキュリティ。
インフラ構築に向けたセルフサービス型の俊敏性。
生産環境の回復力とセキュリティを強化します。

各実装ステップは、実際の建設ニーズに応じて複数のサブプロジェクトに分割され、複数回の反復が必要になる場合があります。例えば、ステップ 1 では、マイクロサービスの導入と運用環境の構築、コンテナクラウドプラットフォームの構築とシステムマイクロサービスアーキテクチャの導入をそれぞれ別のプロジェクトとして確立する必要がある場合があります。コンテナクラウドプラットフォームは、インフラプラットフォームとして、サーバー、ストレージ、ネットワーク機器などの購入を計画する必要があり、マイクロサービスシステム変革の進捗に応じて継続的に購入する必要がある場合もあります。マイクロサービスの設計と開発は、さまざまなシステムの構築や変換、再構築を伴う継続的なプロセスです。同時に、事前の協議、計画の指導、トレーニングも必要になる場合があります。部隊によって実際の状況は異なるため、取る手順や方法も異なります。

1. ステップ1：マイクロサービスの導入と運用環境の構築

クラウドネイティブアーキテクチャシステムでは、アプリケーションはビジネス価値を提供するためのキャリアであり、マイクロサービスはビジネスアプリケーションを構築するためのテクノロジーです。マイクロサービスアーキテクチャによって分解されたアプリケーションサービスは、コンテナー内で実行されます。そのため、マイクロサービスを導入する際には、まずはマイクロサービスの運用をサポートするコンテナ環境を構築することが第一歩となります。

Kubernetesなどのコンテナ技術とコンテナスケジューリングおよび管理技術に基づいて、企業内にプライベートコンテナクラウドプラットフォームを構築し、マイクロサービスアプリケーションシステムの展開、運用、管理をサポートし、マイクロサービスランタイム環境のサポートを実現します。コンテナクラウドプラットフォームに基づいて、弾力的な拡張、サービスルーティング、配布フロー制御、ヘルスチェック、エラー分離、障害回復、リソーススケジューリングなどの関連するセルフサービスアジャイル機能を実現できます。

クラウドアプリケーションの 12 または 15 の要素をガイドとして使用してマイクロサービスを設計します。マイクロサービスを分解する現在の方法は、通常、ドメイン駆動設計 (DDD) アプローチに基づいています。しかし、DDD のビジネスドメインの分割により、ドメインの境界を明確に定義することが困難になることがよくあります。不合理なドメイン分割や、異なるドメインにデータが同時に存在するなどの問題があります。各サービスに対して適切な責任レベルと範囲を選択することは困難であり、ビジネスに対する非常に深い経験と理解が必要です。

そのため、Martin Flowler 氏は、まず従来の統合システムを構築し、ドメイン知識をより深く理解した後、再構築を通じてそれをマイクロサービスに変換できると提案しました。著者は、DDD はドメイン分割によってビジネス関係をある程度簡素化し、それによってマイクロサービス設計を簡素化できると考えています。しかし、ドメイン分割によって各ドメインの全体的な理解が欠如するため、DDD は分類と簡素化された設計方法に近くなり、複数の反復が発生して無駄が生じます。 Martin Flowler の提案により、DDD はグローバルな視点を獲得し、ドメイン分割と設計を上から下まで全体的に把握できるようになりますが、この統一されたシステムを構築するのは簡単ではありません。

著者は実践に基づいて、「マスターデータ駆動型設計」と呼ばれるマイクロサービス設計手法を提案しました。マスターデータは、本来、システム間で共有される価値の高いデータです。エンタープライズマスターデータに基づいて設計されたマイクロサービスは、システム間で自然に再利用できます。さらに、業界共通データモデル (Comm on Data Model、CDM) に基づいて、マスターデータマイクロサービスを簡単に定義および改善できるため、反復的な設計と実装が削減されます。

2. ステップ2: サービス管理とガバナンス

マイクロサービスアーキテクチャはアプリケーションを分解しますが、マイクロサービスの数が急増し、サービスを手動で管理および制御することが困難になります。マイクロサービスの数が増えるにつれて、サービスの管理およびガバナンス機能を向上させる必要があります。コンテナクラウドプラットフォームのランタイムサポートの構築が完了すると、API ベースのコラボレーションを実現しながら、効率的な管理とアジャイルなサービスオーケストレーション応答をサポートするためのサービスガバナンスと API 定義の実装に注力できるようになります。

マイクロサービスガバナンスを実装する方法は多数あります。コンテナクラウドプラットフォームをベースとして、k8s の機能を直接使用して、サービス登録の検出、構成、ルーティングの分散、負荷分散、柔軟な拡張などを実装できます。ただし、コンテナクラウドプラットフォームをエンタープライズレベルのアプリケーションサポートプラットフォームとして使用する場合は、Kubernetes 上でサービス管理およびガバナンス機能を拡張する必要があります。 CNCF は、東西トラフィックをプロキシし、言語間をサポートするために ServiceMesh を使用することを推奨しています。 Porvital の SpringCloud フレームワークは、サービス登録の検出、構成、サーキットブレーキング、クライアント負荷分散などの比較的完全なサービスガバナンス実装を提供しますが、Java のみをサポートしています。フレームワークやテクノロジーは数多く存在します。

マイクロサービスアーキテクチャの主な目的の 1 つは、API を通じて開発言語を保護することです。どのような開発言語を使用しても、同じ API に従っていればコラボレーションを実現できます。実際、これは地球上の異なる国々の間でのコミュニケーションに似ており、お互いに理解できる共通の言語を通じてコミュニケーションをとることができます。したがって、サービスガバナンスを実装する際には、クロスプラットフォーム機能だけでなく、内部および外部の API サービス機能も考慮する必要があります。ここでは、マイクロサービス API と外部 OpenAPI を区別する必要があります。これらは 2 つのレベルとして考えることができます。 OpenAPI は通常、クロスプラットフォームおよびクロスエンタープライズであり、エコシステムの構築に使用されますが、企業内で内部エコシステムの構築に使用することもできます。考え方は同じです。

クラウドネイティブでは、API を連携手段として活用することで、コンテナクラウドプラットフォームと API ゲートウェイの 2 層のサービスガバナンス機能を社内で実現できます。同じマイクロサービスを API ゲートウェイを通じて異なる API として公開することも、複数のマイクロサービスを 1 つの API として公開することもできます。 API は、企業内と外部のエコシステムパートナーの両方で使用できます。

3. ステップ3: 継続的デリバリーとセキュリティ

最初の 2 つのステップでは、マイクロサービスの運用と操作の基本的な機能が完了し、マイクロサービスの弾力的な拡張と共同の相互作用をサポートする機能を備えています。展開および運用・保守プラットフォームとサービス管理およびガバナンス機能により、R&D 側の継続的デリバリー機能の向上に注力できます。こうすることで、マイクロサービスがいくつ開発されても、サービスの管理やガバナンスについて心配する必要がなくなります。 DevOps 理論に基づいて、継続的インテグレーション、継続的デプロイメント、継続的デリバリー、継続的モニタリング、継続的フィードバックのクローズドループプロセスを構築します。

コンテナクラウドプラットフォームとサービス管理およびガバナンス機能を最初に構築する必要がある理由は、アプリケーションマイクロサービスと分散マイクロサービスの爆発的な成長に事前に備え、弾力的なスケーリング、可視化、可観測性、障害分離、フォールトトレランス、自己回復をサポートする機能を備えるためです。これは、各チームの継続的な配信要件をサポートする唯一の方法です。これは、私たちが常にマイクロサービス運用サポート環境の構築にまず注力することを提唱してきた重要な理由でもあります。

DevOps は、共同フィードバックを中核とする考え方と方法論です。タイムリーなフィードバックだけが反省と改善につながります。 DevOps の考え方を用いて継続的デリバリー機能を構築するプロセスには、組織構造の最適化が含まれており、これが難しい点となる場合があります。まず、組織のリーダーは DevOps のアイデアと概念を理解し、組織の弱点を認識し、それを改善しようとする意欲を持たなければなりません。 2 つ目は、DevOps システム (DevOps システムは単なるプラットフォームではない可能性があります) には多数のコンポーネントとツールが含まれる場合があり、統合された設計と開発が必要になるため、それぞれに多くの人的リソースと時間がかかります。

たとえば、オープンソースツールを使用する場合、継続的インテグレーションと継続的デリバリーのプロセスには、開発、ソースコード管理、ソースコード検査、ユニットテスト、ユースケース管理、構築、セキュリティテスト、デリバリー管理などの多くのツールが関係します。これらのツールの認証と権限管理を考えるだけでも簡単な作業ではありません。そのため、DevOps ベンダーの中には、継続的インテグレーション、継続的デリバリー、その他のパイプラインを独自に直接開発しているところもあります。そのような研究開発能力をお持ちであれば、可能な限り独自の研究や共同研究を行うことをお勧めします。これにより、システム統合の優れた基盤も構築され、効果的な統合が難しい多数のオープンソースのサードパーティツールによって引き起こされる多数の統合の問題を回避できます。

認証と権限は、DevOps システムにおける基本的なセキュリティ対策です。クラウドネイティブの全体的なセキュリティを強化するには、DevOps ツールチェーンとパイプラインの実装と使用中に、コードセキュリティチェック、イメージセキュリティチェック、システムセキュリティ、アプリケーションセキュリティ、インターフェイスセキュリティ、コンテナセキュリティなどを徐々に改善する必要があります。

4. ステップ4: セルフサービス型のアジャイル対応インフラストラクチャ

このインフラストラクチャは、コンテナクラウドプラットフォームとマイクロサービスを構築する最初のステップで使用されますが、この段階ではマイクロサービスの数が比較的少なく、セルフサービスのアジャイル対応インフラストラクチャが緊急に必要というわけではありません。継続的デリバリー機能の向上とマイクロサービスの成長に伴い、運用・保守機能は量的変化から質的変化へと進化する必要があります。自動化、セルフサービス、俊敏な対応機能が議題に上がっています。

インフラストラクチャは、インフラストラクチャリソース、サポートプラットフォーム、純粋な技術ツールの 3 つの部分に大まかに分けられます。インフラストラクチャリソースには、さまざまな種類の異種リソースとクラウドプラットフォームが含まれる場合があります。これらは、統合されたインフラストラクチャリソースサービスを提供して、基盤となる異種リソースの詳細を分離し、アプリケーションリソースのスケジュールを簡素化するために、統合レイヤー (マルチクラウド管理プラットフォームなど) を通じてカプセル化する必要があります。サポートプラットフォームは、継続的デリバリープラットフォームやコンテナクラウドプラットフォームなど、主にマイクロサービスの開発、運用、保守のためのプラットフォームです。純粋なテクニカルツールとは、メッセージングプラットフォーム（RabbitMQ、Kafka）、監視プラットフォーム、権限管理プラットフォーム、認証プラットフォーム、顔認識プラットフォームなど、業務とは関係のない、サポートプラットフォームを中心としたツールを指します。これらのプラットフォームは、テクニカルミドルプラットフォームを構築するための機能を抽出でき、さまざまな業務アプリケーションでこれらの機能を再利用できます。

継続的デリバリーを実装する一方で、継続的インテグレーションや継続的デリバリーパイプラインなどのセルフサービスのアジャイル対応インフラストラクチャ機能も部分的に構築しています。このステップでは、統合 ID 認証および許可サービス、ログサービス、構成サービス、監視サービス、アラームサービス、セキュリティサービス、AI サービス (顔認識、テキスト認識、画像認識、音声認識、自然言語処理、ナレッジグラフ、アルゴリズムなど)、メッセージサービス、スケジュールサービスなどの基本サービスと CICD R&D プロセスサービスを含む、自動化されたセルフサービスインフラストラクチャ機能の構築と改善に重点を置く必要があります。これらのサービスに対してセルフサービス機能を有効にすることは、俊敏性と応答性に優れたアプリケーションを構築するための鍵となります。

インフラストラクチャリソースのセルフサービスによるアジャイルな対応は、これらすべてのサービスがアジャイルな対応を実現するための前提条件です。インフラストラクチャリソースは多様であり、さまざまなメーカー、ブランド、モデル、アーキテクチャ、プロトコル、クラウドプラットフォームなどから提供される可能性があるため、インフラストラクチャリソースの統合管理と俊敏な対応に課題が生じます。統合インフラストラクチャリソースサービスの提供、基盤となるリソースの詳細のカプセル化、リソース配信の効率化を実現するために、統合インフラストラクチャリソース管理プラットフォームまたはマルチクラウド管理プラットフォームの構築を検討する必要があります。

このプロセス中に、組織構造を同期的に調整できます。たとえば、インフラストラクチャリソースチームは、インフラストラクチャリソースを運用および保守し、プラットフォームとツールのリソースサービスを提供します。プラットフォームチームはプラットフォームの運用と保守を行い、ツールチームはアプリケーション管理中心のアーキテクチャをサポートするためのツールと技術的なミドルオフィスサービスを継続的に開発します。アプリケーション研究開発チームは、ビジネスアプリケーションマイクロサービスの研究開発に重点を置き、セルフサービスリソース、プラットフォーム、ツールを使用して、サービスの研究開発、テスト、展開、運用、保守のライフサイクル全体の管理を実現します。

5. ステップ5: 運用環境の回復力とセキュリティを強化する

脆弱性の反対は、堅牢性、回復力です。アンチフラジリティの目的は、定期的または不定期に運用環境に障害を注入することで積極的に弱点を見つけ、これらの弱点を強制的に修復し、環境の堅牢性と回復力を向上させることです。人間の免疫システムを例に挙げてみましょう。ウイルスに攻撃されると、人間の免疫システムは自動的に反応し、強化されます。しかし、人が孤立すると免疫システムは弱くなります。人間の免疫システムの概念を利用して、さまざまなシナリオでの障害に耐えるクラウドネイティブアーキテクチャの回復力を構築します。

Netflix Simian Army プロジェクトには、「Chaos Monkey」と呼ばれる有名なサブモジュールがあります。これは、アーキテクチャの弱点を特定して排除することを目的として、製品コンポーネントにランダムな障害を注入します。アプリケーションアーキテクチャの弱点を明示的に検出し、障害を注入して修復を実施することで、アーキテクチャは時間の経過とともに自然にセキュリティのレベルが高まります。したがって、前の手順を完了した後、または条件が許せば、前の手順中に脆弱性テストを実施することで、環境の回復力を継続的に強化できます。

セキュリティ対策は防御的ですが、システムは常に変化しており、予測できない脆弱性がいつでも発生する可能性があります。そのため、開発・設計段階でセキュリティリスクを可能な限り排除することに加え、実行時のセキュリティ対策も必要かつ継続的に行う必要があります。そのため、セキュリティ対策を継続的に改善し、脆弱性攻撃への対策を継続的に強化する必要があります。セキュリティ機能の構築もシステムの脆弱性対策の一部です。