クラウドネイティブアーキテクチャが従うべき7つの原則

クラウド ネイティブ アーキテクチャは、アーキテクチャ パターンとして、いくつかの原則を使用して、アプリケーション アーキテクチャに対する中核的な制御を実行します。これらの原則は、技術マネージャーやアーキテクトがテクノロジーを選択する際に、より効率的かつ正確に作業を行うのに役立ちます。以下で詳しく説明します。

1. サービス指向の原則

ソフトウェア開発プロセスにおいて、コード量や開発チームの規模がある程度まで拡大すると、アプリケーションをリファクタリングし、モジュール化やコンポーネント化によって懸念事項を分離し、アプリケーションの複雑さを軽減し、ソフトウェア開発の効率を向上させ、保守コストを削減する必要があります。

図 1 に示すように、ビジネスが発展し続けると、単一のアプリケーションが処理できる容量は徐々に上限に達します。アプリケーション変革により垂直拡張（スケールアップ）のボトルネックを打破し、水平拡張（スケールアウト）に対応できるようになったとしても、グローバル同時アクセスの場合、データ計算の複雑さやストレージ容量に課題が残ります。したがって、モノリシック アプリケーションをさらに分割し、ビジネスの境界に従って分散アプリケーションに再分割する必要があります。これにより、アプリケーションはデータを直接共有するのではなく、合意された契約を通じて通信し、スケーラビリティを向上させることができます。

図1 アプリケーションサービス拡張

サービス指向設計の原則とは、サービス指向アーキテクチャを通じてライフサイクルの異なるビジネスユニットを分割し、ビジネスユニットの独立した反復を実現することで、全体的な反復速度を加速し、反復の安定性を確保することを指します。同時に、サービス指向アーキテクチャはインターフェース指向プログラミング方式を採用しており、ソフトウェアの再利用度を高め、水平拡張能力を強化します。サービス指向設計の原則では、ビジネス モジュール間の関係をアーキテクチャ レベルで抽象化することにも重点が置かれており、これにより、ビジネス モジュールは、サービスが開発されるプログラミング言語に注意を払うことなく、サービス トラフィック (ネットワーク トラフィックではなく) に基づいてポリシー制御とガバナンスを実装できるようになります。

サービス指向設計原則の実践に関しては、業界内に多くの成功事例があります。その中でも、業界で最も影響力があり、最も賞賛されているのは、Netflix の生産システムにおける大規模なマイクロサービス実践です。この実践を通じて、Netflix は全世界で 1 億 6,700 万人の加入者と世界のインターネット帯域幅容量の 15% 以上を獲得しただけでなく、Eureka、Zuul、Hystrix などの優れたマイクロサービス コンポーネントをオープン ソース分野にも貢献しました。

海外企業が継続的にサービス指向の実践を行っているだけでなく、国内企業もサービス指向の実践に対する意識が高くなっています。近年のインターネットの発展により、新興のインターネット企業と伝統的な大企業の両方に、サービス指向の実践における優れた実践と成功事例があります。アリババのサービス指向の実践は、2008 年の五彩石プロジェクトから始まりました。10 年間の開発を経て、長年にわたり主要なプロモーション活動に安定したサポートを提供してきました。 2019年の「ダブル11」のデータを例にとると、アリババの分散システムは、ピーク値544,000トランザクション/秒、リアルタイムコンピューティング処理25.5億トランザクション/秒を達成しました。 Alibaba のサービス指向分野における実践は、Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade などのオープンソース プロジェクトを通じて業界と共有されてきました。同時に、これらのコンポーネントは Spring Cloud と統合されています。 Spring Cloud Alibaba は Spring Cloud Netflix の後継となりました。

クラウドネイティブの波の台頭により、サービス指向の原則は進化を続け、実際のビジネスに実装されてきましたが、企業は実際の実装プロセスで多くの課題にも直面することになります。たとえば、自社構築のデータセンターと比較すると、サービス指向のパブリッククラウドには巨大なリソースプールがあり、マシンエラー率が大幅に増加する可能性があります。従量課金制により、スケーリング操作の頻度が増加します。新しい環境では、アプリケーションの起動が高速化され、アプリケーション間に強い依存関係がなくなり、異なる仕様のノード間で自由にスケジュールできるようになるなど、考慮すべき多くの実際的な問題が求められます。しかし、クラウドネイティブ アーキテクチャが進化し続けるにつれて、これらの問題は 1 つずつ解決されることが予想されます。

2. 柔軟性

弾力性の原則とは、事前のキャパシティ プランニングに基づいて固定のハードウェアおよびソフトウェア リソースを準備する必要なく、ビジネス ボリュームの変化に応じてシステム展開の規模を自動的に調整できることを意味します。優れた弾力性により、企業の IT コスト モデルが変化するだけでなく、企業は追加のソフトウェアおよびハードウェア リソース コスト支出 (アイドル コスト) を考慮する必要がなくなり、ビジネス規模の爆発的な拡大をより適切にサポートし、ソフトウェアおよびハードウェア リソースの備蓄不足による後悔を残すことがなくなります。

クラウドネイティブ時代では、企業がITシステムを構築するためのハードルが大幅に下がり、企業がビジネスプランを製品やサービスに実装する際の効率が大幅に向上します。これはモバイル インターネットとゲーム業界で特に顕著です。アプリがヒットするとユーザー数が飛躍的に増加するケースは多くあります。ビジネスの急激な成長は、企業の IT システムのパフォーマンスに大きな課題をもたらします。このような課題に直面して、従来のアーキテクチャでは、開発者や運用・保守担当者は通常、システム パフォーマンスの最適化に忙しくしています。しかし、最善を尽くしても、システムのボトルネックの問題を完全に解決できない可能性があります。最終的には、システムが大量のユーザーの継続的な流入に対応できず、アプリケーションが麻痺してしまいます。

指数関数的なビジネス成長の試練に直面することに加えて、ビジネスのピーク特性はもう一つの重要な課題となるでしょう。例えば、映画チケット予約システムのトラフィック量は午後の方が早朝よりはるかに多く、週末のトラフィック量は平日より数倍も高くなります。テイクアウトの注文システムでは、ランチとディナーの前後に注文がピークになる時間帯があることが多いです。従来のアーキテクチャでは、ピーク特性が明らかなこのようなシナリオに対処するために、企業はピーク時のトラフィックに備えて事前に大量のコンピューティング、ストレージ、ネットワーク リソースを準備し、これらのリソースに対して料金を支払う必要がありますが、これらのリソースはほとんどの時間アイドル状態になっています。

したがって、クラウドネイティブ時代において、企業はITシステムを構築する際、急速に拡大するビジネス規模に直面してさまざまなシナリオ要件に柔軟に対応し、クラウドネイティブ技術とコストの利点を最大限に活用できるように、アプリケーションアーキテクチャを弾力化することをできるだけ早く検討する必要があります。

柔軟なシステム アーキテクチャを構築するには、次の 4 つの基本原則に従う必要があります。

（１）機能別アプリケーションセグメンテーション

大規模で複雑なシステムは、数百または数千のサービスから構成される場合があります。アーキテクチャを設計する際、アーキテクトは、関連するロジックをまとめ、関連のないロジックを独立したサービスに分解し、標準のサービス検出を通じてサービスが互いを見つけ、標準のインターフェースを使用して通信できるようにするという原則に従う必要があります。サービスは疎結合されているため、各サービスが独立して弾性スケーリングを完了でき、サービスの上流および下流に関連する障害の発生を回避できます。

（２）水平分割をサポート

アプリケーションを機能別に分割しても、回復力の問題は完全には解決されません。アプリケーションが多数のサービスに分割されると、ユーザー トラフィックが増加するにつれて、最終的には 1 つのサービスでシステムのボトルネックが発生します。したがって、設計上、各サービスを水平に分割して、サービスを異なる論理ユニットに分割し、各ユニットがユーザー トラフィックの一部を処理するようにすることで、サービス自体のスケーラビリティを向上できる必要があります。最大の課題はデータベースシステムにあります。データベース システム自体はステートフルであるため、データを合理的に分割し、正しいトランザクション メカニズムを提供するのは非常に複雑なプロジェクトになります。しかし、クラウドネイティブ時代においては、クラウドプラットフォームが提供するクラウドネイティブデータベースサービスによって、ほとんどの複雑な分散システムの問題を解決できます。したがって、企業がクラウド プラットフォームが提供する機能を通じて弾力性のあるシステムを構築すれば、データベース システムの弾力性のある機能も自然に得られることになります。

（３）自動展開

システム トラフィックのバーストは通常​​予測不可能であるため、一般的な解決策は、システムが大規模なユーザー アクセスをサポートできるようにシステム容量を手動で拡張することです。アーキテクチャが分割された後、弾性システムには、確立されたルールまたは外部トラフィックバースト信号に基づいてシステムの自動拡張機能をトリガーし、バーストトラフィックの影響期間を短縮するためのシステムの適時性要件を満たし、ピーク期間の終了後にシステムを自動的に縮小してシステム運用のリソース使用コストを削減できるように、自動展開機能も必要です。

（４）サポートサービスの低下

弾力性のあるシステムでは、例外対応計画を事前に設計する必要があります。たとえば、サービスは階層的に管理する必要があります。弾性メカニズムの障害、弾性リソースの不足、予想を超えるトラフィックピークなどの異常な状況では、システムアーキテクチャは、一部の重要でないサービスの品質を低下させたり、一部の拡張機能をシャットダウンしたりしてリソースを解放し、重要な機能に対応するサービス容量を拡張して、製品の主要機能に影響が及ばないようにすることで、サービスをダウングレードできる必要があります。

国内外で大規模な弾力システムの構築に成功した実例が数多くありますが、最も代表的なのはアリババの毎年恒例の「ダブル11」プロモーションです。アリババは、通常の数百倍に達するトラフィックピークに対処するため、毎年アリババクラウドから弾力性のあるリソースを購入して自社のアプリケーションを展開し、「ダブル11」イベント後にこれらのリソースをリリースしてオンデマンドで支払うことで、主要なプロモーション活動のリソースコストを大幅に削減しています。もう 1 つの例は、Sina Weibo の柔軟なアーキテクチャです。ソーシャル メディアで話題のイベントが発生すると、Sina Weibo は弾力性のあるシステムを使用してアプリケーション コンテナーを Alibaba Cloud に拡張し、話題のイベントによって発生する大量の検索および転送要求に対処します。このシステムは、数分以内にオンデマンド拡張応答機能を提供することで、ホット検索によって発生するリソース コストを大幅に削減します。

クラウドネイティブ技術の発展に伴い、FaaSやサーバーレスなどの技術エコシステムが徐々に成熟し、大規模な弾力性のあるシステムを構築する難易度が徐々に低下しています。企業が FaaS や Serverless などの技術的概念をシステム アーキテクチャの設計原則として使用すると、システムは弾力的に拡張できるようになり、企業は「弾力性のあるシステム自体の維持」に追加コストを支払う必要がなくなります。

3. 観測可能性の原則

監視、ビジネス検出、APM (アプリケーション パフォーマンス管理) などのシステムによって提供される受動的な機能とは異なり、可観測性ではプロアクティブ性が重視されます。クラウド コンピューティングなどの分散システムでは、1 回のアプリ クリックで生成された複数のサービス呼び出しの期間、戻り値、パラメーターが、ログ、リンク トラッキング、メトリックを通じて明確に表示され、各サードパーティ ソフトウェア呼び出し、SQL 要求、ノード トポロジ、ネットワーク応答などの情報にドリルダウンすることもできます。このような観察機能により、運用、開発、ビジネス担当者はソフトウェアの動作状況をリアルタイムで把握し、これまでにない相関分析機能を獲得して、ビジネスの健全性とユーザーエクスペリエンスを継続的に最適化することができます。

クラウド コンピューティングの包括的な発展により、企業のアプリケーション アーキテクチャは大きな変化を遂げ、従来のモノリシック アプリケーションからマイクロサービスへと徐々に移行しています。マイクロサービス アーキテクチャでは、サービス間の疎結合設計により、バージョンの反復が高速化され、サイクルが短くなります。 Kubernetes やインフラストラクチャ層のその他のプラットフォームは、コンテナのデフォルト プラットフォームになっています。サービスはパイプラインを通じて継続的な統合とデプロイメントを実現できます。これらの変更により、サービス変更のリスクを最小限に抑え、研究開発の効率を向上させることができます。

マイクロサービスアーキテクチャでは、システムの障害点はどこにでも発生する可能性があるため、MTTR（障害の平均修復時間）を短縮するために、可観測性に関する体系的な設計を行う必要があります。

可観測性システムを構築するには、次の 3 つの基本原則に従う必要があります。

（１）包括的なデータ収集

メトリクス、トレース、ログ記録は、完全な可観測性システムを構築するための 3 つの柱です。システムの可観測性には、これら 3 種類のデータを完全に収集、分析、表示することが必要です。

• 指標: 指標は、複数の連続した期間にわたって測定される KPI 値です。一般的に、指標はソフトウェア アーキテクチャに応じて階層化され、システム リソース指標 (CPU 使用率、ディスク使用率、ネットワーク帯域幅など)、アプリケーション指標 (エラー率、サービス レベル契約 SLA、サービス満足度 APDEX、平均レイテンシなど)、ビジネス指標 (ユーザー セッション数、注文数、売上高など) に分けられます。
• リンク トレース: リンク トレースは、ブラウザまたはモバイル端末からサーバーを経由して SQL を実行するかリモート呼び出しを開始するまでの全プロセスを実行する TraceId の一意の識別子を通じて、分散呼び出しの全プロセスを記録し、復元することを指します。
• ログ: ログは通常、アプリケーションの実行プロセス、コードのデバッグ、エラー例外、その他の情報を記録するために使用されます。たとえば、Nginx ログには、リモート IP、リクエスト時間、データ サイズなどの情報が記録されます。ログデータは集中的に保存され、検索可能である必要があります。

（２）データ相関分析

データ間の接続をさらに増やすことは、可観測性システムにとって特に重要です。障害が発生した場合、効果的な相関分析により、障害を迅速に特定して特定できるため、障害処理の効率が向上し、不必要な損失が削減されます。一般的には、アプリケーションのサーバー アドレス、サービス インターフェイスなどの情報を追加属性として使用し、それをインジケーター、呼び出しチェーン、ログなどの情報にバインドし、観測可能なシステムに特定のカスタマイズ機能を提供して、より複雑な運用および保守シナリオのニーズに柔軟に対応します。

（３）統合監視ビューと表示

さまざまな形式と次元でビューを監視することで、運用担当者と開発担当者はシステムのボトルネックを迅速に特定し、システムのリスクを排除できます。監視データの表示は、指標トレンド チャートや棒グラフなどの形式だけでなく、複雑な実際のアプリケーション シナリオのニーズと組み合わせる必要があり、ビューは、運用と保守の監視、バージョン リリースの管理、トラブルシューティングなどの複数のシナリオのニーズを満たすようにドリルダウンしてカスタマイズする機能を備えています。

クラウドネイティブ テクノロジーの発展に伴い、異種マイクロサービス アーキテクチャに基づくシナリオはますます増加し、複雑化しており、可観測性はすべての自動化機能を構築するための基盤となります。包括的な可観測性を実現することによってのみ、システムの安定性を真に向上させ、MTTR を削減することができます。したがって、システム リソース、コンテナ、ネットワーク、アプリケーション、ビジネスに対するフルスタックの可観測性システムをどのように構築するかは、すべての企業が検討する必要がある問題です。

4. 回復力の原則

レジリエンスとは、ソフトウェアが依存するハードウェアおよびソフトウェア コンポーネントに異常が発生した場合に、ソフトウェアが障害に抵抗する能力を指します。これらの異常には通常、ハードウェア障害、ハードウェア リソースのボトルネック (CPU またはネットワーク カードの帯域幅の枯渇など)、ソフトウェア設計容量を超えるビジネス トラフィック、コンピュータ ルームの通常の操作に影響する障害または災害、依存ソフトウェアの障害、およびビジネスの利用不能を引き起こす可能性のあるその他の要因が含まれます。

事業開始後、事業運営期間の大半において、さまざまな不確実な入力や不安定な依存関係に遭遇する可能性があります。このような異常なシナリオが発生した場合、企業はネットワーク サービスに代表される現在の「常時オンライン」の要件を満たすために、可能な限りサービス品質を確保する必要があります。したがって、レジリエンスの中核となる設計概念は、障害に備えた設計、つまり、さまざまな異常な依存状況下で、異常がシステムやサービス品質に与える影響を軽減し、できるだけ早く正常に戻す方法を考慮することです。

レジリエンス原則の実践と共通アーキテクチャには、主に、サービス非同期機能、再試行/電流制限/劣化/回路遮断/バックプレッシャー、マスタースレーブモード、クラスターモード、複数の AZ (可用性ゾーン) の高可用性、ユニット化、リージョン間の災害復旧、および異なる場所でのマルチアクティブ災害復旧が含まれます。

以下では、具体的なケースを挙げて大規模システムのレジリエンスを設計する方法を詳しく説明します。 「ダブル11」はアリババにとって負けられない戦いなので、そのシステムの設計は戦略面での回復力の原則に厳密に従う必要がある。たとえば、統合アクセス層では、トラフィックのクリーニングを通じてセキュリティ戦略が実装され、ブラックマーケット攻撃から防御します。洗練された電流制限戦略によりピーク時のトラフィック安定性が確保され、バックエンドの正常な動作が保証されます。アリババは、全体的な高可用性機能を向上させるために、ユニット化されたメカニズムを通じて地域間マルチアクティブ災害復旧を実施し、都市内災害復旧メカニズムを通じて都市内デュアルアクティブ災害復旧を実施し、IDC（インターネットデータセンター）のサービス品質を最大化しました。同じ IDC では、ステートレスなビジネス移行はマイクロサービスとコンテナ テクノロジーを通じて実現されています。マルチレプリカの展開により高可用性が向上します。マイクロサービス間の非同期分離はメッセージングを通じて完了し、サービスの依存性を減らし、システムのスループットを向上させます。各アプリケーションの観点から、それぞれの依存関係を整理し、ダウングレードスイッチを設定し、障害訓練を通じてシステムの堅牢性を継続的に強化し、アリババの「ダブル11」プロモーション活動が正常かつ安定的に進行することを確保しました。

デジタル化プロセスの加速に伴い、ますます多くのデジタルビジネスが社会経済全体の正常な運営のためのインフラストラクチャになっています。しかし、こうしたデジタルビジネスを支えるシステムがますます複雑化するにつれ、不確実なサービス品質に依存するリスクはますます高まっています。したがって、さまざまな不確実性にうまく対処できるように、十分な回復力を備えたシステムを設計する必要があります。レジリエンス設計は、コア産業のコアビジネスリンク（金融決済リンク、電子商取引トランザクションリンクなど）、ビジネストラフィックの入口、および依存する複雑なリンクに関しては特に重要です。

5. すべてのプロセス自動化の原則

テクノロジーは諸刃の剣です。コンテナ、マイクロサービス、DevOps、および多数のサードパーティ コンポーネントの使用により、分散の複雑さが軽減され、反復速度が向上しますが、ソフトウェア テクノロジ スタックの複雑さが増し、コンポーネントの規模も大きくなり、必然的にソフトウェア配信の複雑さが増します。適切に制御しないと、アプリケーションはクラウドネイティブ テクノロジのメリットを享受できなくなります。企業は、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインにおけるIaC、GitOps、OAM、Operator、および多数の自動デリバリーツールの実践を通じて、企業内のソフトウェアデリバリープロセスを標準化し、標準化に基づいた自動化を実現できます。つまり、構成データの自己記述と最終的な状態指向のデリバリープロセスを通じて、ソフトウェアデリバリーと運用保守全体の自動化を実現できます。

大規模な自動化を実現するには、4 つの基本原則に従う必要があります。

（１）標準化

自動化を実現するためには、まずコンテナ化、IaC、OAM などを通じて業務運用の基盤を標準化し、さらにアプリケーション定義や配信プロセスまでも標準化する必要があります。標準化を実現することでのみ、業務の特定の担当者やプラットフォームへの依存を排除​​し、業務の統一と大規模な自動化を実現できます。

（２）最終段階に向けて

エンドステート指向とは、インフラやアプリケーションの想定される構成を宣言的に記述し、アプリケーションの実際の動作状況を継続的に注視しながら、システム自体の変更や調整を繰り返してエンドステートに近づくという考え方を指します。最終状態指向の原則では、一連の手順コマンドを作業指示システムとワークフロー システムを通じて直接組み立てることによってアプリケーションの変更を回避する必要があることを強調しています。代わりに、終了状態を設定し、変更をどのように実行するかをシステムに決定させる必要があります。

（３）関心の分離

自動化の最終的な有効性は、ツールやシステムの機能だけでなく、システムの目標を設定する人にも左右されるため、目標を設定する適切な人を見つけるようにしてください。システムの最終状態を記述する際には、アプリケーション開発、アプリケーションの運用保守、インフラストラクチャの運用保守という主な役割に関わる構成を分離する必要があります。各ロールは、システムの最終状態が適切であることを保証するために、関心があり得意とするシステム構成を設定するだけで済みます。

（4）故障に備えた設計

完全なプロセス自動化を実現するには、自動化されたプロセスが制御可能であり、システムへの影響が予測可能であることを保証する必要があります。自動化されたシステムが間違いを起こさないことを期待することはできませんが、異常が発生した場合でも、エラーの影響が制御可能で許容範囲内であることを保証できます。したがって、変更を実行する場合、自動化システムは手動変更のベスト プラクティスにも従って、変更がグレースケールで実行できること、実行結果が観察可能であること、変更が迅速にロールバックできること、変更の影響が追跡可能であることを保証する必要があります。

ビジネス インスタンスの障害の自己修復は、典型的なプロセス自動化シナリオです。ビジネスがクラウドに移行した後、クラウド プラットフォームはさまざまな技術的手段を通じてサーバー障害の可能性を大幅に削減しますが、ビジネス自体のソフトウェア障害を排除することはできません。ソフトウェア障害には、アプリケーション ソフトウェア自体の欠陥によって発生するクラッシュ、リソース不足によって発生するメモリ不足 (OOM)、過度の負荷によって発生するクラッシュなどがあります。また、カーネルやデーモン プロセスなどのシステム ソフトウェアの問題や、コロケーション内の他のアプリケーションやジョブからの干渉も含まれます。ビジネスの規模が大きくなるにつれて、ソフトウェア障害のリスクはますます高くなります。従来の O&M トラブルシューティングでは、再起動や再配置などの修復操作を実行するために O&M 担当者が介入する必要がありました。しかし、大規模なシナリオでは、O&M 担当者はさまざまな障害に圧倒され、操作を実行するために夜通し残業しなければならない場合もあります。サービス品質の保証が難しく、顧客も開発者もO&M担当者も満足していません。

クラウドネイティブ アプリケーションでは、障害を自動的に修復するために、開発者が標準の宣言型構成を使用して、アプリケーションの正常性検出方法とアプリケーションの起動方法、アプリケーションの起動後にマウントおよび登録する必要があるサービス検出、および構成管理データベース (CMDB) 情報を記述する必要があります。これらの標準構成により、クラウド プラットフォームはアプリケーションを繰り返し検出し、障害が発生したときに自動修復操作を実行できます。さらに、障害検出自体の誤報を防ぐために、アプリケーションの運用保守担当者は、自分の能力に応じて利用できないサービスインスタンスの割合を設定することもできます。これにより、クラウドプラットフォームは、自動障害回復を実行しながらビジネスの可用性を確保できます。インスタンス障害の自己修復を実装すると、開発者や運用保守担当者が面倒な運用保守作業から解放されるだけでなく、さまざまな障害をタイムリーに処理して、ビジネスの継続性とサービスの高可用性を確保できます。

6. ゼロトラスト原則

境界モデルに基づく従来のセキュリティ アーキテクチャ設計では、信頼できるリソースと信頼できないリソースの間に壁を構築します。たとえば、会社のイントラネットは信頼されていますが、インターネットは信頼されていません。このセキュリティ アーキテクチャ設計モデルでは、侵入者が境界を突破すると、境界内のリソースに自由にアクセスできるようになります。クラウドネイティブアーキテクチャの適用、従業員のリモートワークモードの普及、携帯電話などのモバイルデバイスを使用して作業を処理する現在の状況により、従来のセキュリティアーキテクチャの物理的な境界は完全に打ち破られました。アプリケーションとデータはクラウド上でホストされるため、在宅勤務の従業員もパートナーとデータを共有できます。

今日では、境界は組織の物理的な場所によって定義されなくなり、組織のリソースやサービスへのアクセスが必要なすべての場所に拡大されています。従来のファイアウォールや仮想プライベート ネットワークでは、この新しい境界に確実かつ柔軟に対応できなくなりました。そのため、クラウドネイティブやモバイル時代の環境の特性に柔軟に適応できる新しいセキュリティアーキテクチャが必要です。従業員がどこで働いているか、デバイスが接続されている場所、アプリケーションが展開されている場所に関係なく、データ セキュリティを効果的に保護できます。この新しいセキュリティ アーキテクチャを実装する場合は、ゼロ トラスト モデルに依存する必要があります。

従来のセキュリティ アーキテクチャでは、ファイアウォール内のすべてが安全であると想定されていますが、ゼロ トラスト モデルでは、ファイアウォールの境界が破られ、すべての要求が信頼できないネットワークから送信されていると想定されるため、すべての要求を検証する必要があります。簡単に言えば、「決して信じず、常に検証する」ということです。ゼロ トラスト モデルでは、各リクエストはセキュリティ ポリシーに基づいて強力に認証、検証、承認される必要があります。リクエストに関連するユーザー ID、デバイス ID、アプリケーション ID などは、リクエストが安全かどうかを判断するための中核情報として使用されます。

境界に関するセキュリティ アーキテクチャについて議論する場合、従来のセキュリティ アーキテクチャの境界は物理ネットワークですが、ゼロ トラスト セキュリティ アーキテクチャの境界は ID であり、これには人、デバイス、アプリケーションなどの ID が含まれます。ゼロ トラスト セキュリティ アーキテクチャを実現するには、次の 3 つの基本原則に従う必要があります。

（１）明示的な検証

すべてのアクセス要求は認証され、承認されます。認証と承認は、ユーザー ID、場所、デバイス情報、サービスとワークロードの情報、およびデータ分類と異常検出に基づいて行う必要があります。たとえば、企業の内部アプリケーション間の通信の場合、送信元 IP が内部 IP であることを単純に判断して、直接アクセスを許可することはできません。代わりに、ソース アプリケーションの ID とデバイス情報を決定し、現在のポリシーと組み合わせて承認する必要があります。

（２）最小限の権限

各リクエストに対して、その時点で必要な権限のみが付与され、権限ポリシーは現在のリクエストのコンテキストに基づいて適応される必要があります。たとえば、人事部門の従業員は人事関連のアプリケーションにアクセスできる必要がありますが、財務部門のアプリケーションにはアクセスできません。

（３）攻撃が成功したと仮定する

物理的な境界が破られた場合を想定して、セキュリティ爆発半径を厳密に制御し、ネットワーク全体をユーザー、デバイス、アプリケーションを認識した複数の部分に分割する必要があります。すべての会話は暗号化され、データ分析技術を使用してセキュリティ ステータスの可視性が確保されます。

従来のセキュリティ アーキテクチャからゼロ トラスト アーキテクチャへの進化は、ソフトウェア アーキテクチャに大きな影響を与え、具体的には次の 3 つの側面に反映されます。

まず、セキュリティ ポリシーは IP に基づいて構成できません。クラウドネイティブ アーキテクチャでは、IP がサービスまたはアプリケーションにバインドされているとは想定できません。これは、自動弾力性などのテクノロジを適用すると、IP がいつでも変更される可能性があるためです。したがって、IP はアプリケーションの ID を表すことはできず、それに基づいてセキュリティ ポリシーを確立することはできません。

第二に、アイデンティティはインフラストラクチャになる必要があります。サービス間の通信とサービスへの人間によるアクセスを許可するには、訪問者の ID が明確にわかっていることが前提となります。企業では、人間の ID 管理は通常、セキュリティ インフラストラクチャの一部ですが、アプリケーション ID も管理する必要があります。

3 番目は、標準リリース パイプラインです。企業では、コードのバージョン管理、構築、テスト、オンライン プロセスなど、比較的独立している R&D 作業は通常分散されています。この分散型モデルでは、実際の運用環境で実行されるサービスのセキュリティが効果的に保証されなくなります。コードバージョンの管理、ビルド、および起動プロセスを標準化できれば、アプリケーションリリースのセキュリティを中央に強化できます。

一般的に、ゼロトラストモデル全体の構築には、アイデンティティ、デバイス、アプリケーション、インフラストラクチャ、ネットワーク、データなどのいくつかの部品が含まれます。 Zero Trustの実装は段階的なプロセスです。たとえば、組織内で送信されるすべてのトラフィックが暗号化されていない場合、最初のステップは、訪問者がアプリケーションにアクセスするために使用するトラフィックが暗号化され、すべてのトラフィックの暗号化を徐々に実装することを確認することです。クラウドネイティブアーキテクチャが採用されている場合、クラウドプラットフォームが提供するセキュリティインフラストラクチャとサービスを直接使用して、企業がゼロトラストアーキテクチャを迅速に実装できるようにすることができます。

7。継続的なアーキテクチャの進化の原則

今日、テクノロジーとビジネスは非常に速く発展しています。エンジニアリングの実践では、最初から明確に定義し、ソフトウェアライフサイクル全体に適用できるアーキテクチャパターンはほとんどありません。代わりに、変化するテクノロジーやビジネスニーズに適応するために、特定の範囲内で継続的に再構築する必要があります。同様に、クラウドネイティブアーキテクチャ自体は、変更されていないように設計された閉じたアーキテクチャではなく、継続的に進化する能力を持つ必要があります。したがって、設計中の増分反復や合理的なターゲット選択などの要因を考慮することに加えて、組織レベル（建築管理委員会など）での建築ガバナンスとリスク管理仕様を検討することも必要です。特に、高速ビジネスの反復の場合、建築の進化とビジネス開発のバランスを確保する方法にもっと重点を置くべきです。

（1）進化アーキテクチャの特性と価値

進化的アーキテクチャとは、ソフトウェア開発の初期段階では、スケーラブルでゆるく結合した設計により、その後の変更が容易になり、アップグレード再構成のコストが低くなることを意味します。開発の実践、リリースの実践、全体的な俊敏性など、ソフトウェアライフサイクルの任意の段階で発生する可能性があります。

進化的建築が産業実践において非常に重要であるという基本的な理由は、現代のソフトウェアエンジニアリングの分野のコンセンサスによれば、変化を予測するのが難しく、変革のコストが非常に高いことです。進化的アーキテクチャはリファクタリングを避けることはできませんが、アーキテクチャの進化性を強調しています。つまり、テクノロジー、組織、または外部環境の変化のためにアーキテクチャ全体が進化する必要がある場合、プロジェクト全体は、ドメイン駆動型の設計に記載されている論理的区分が物理的に分離されるように、強力な境界コンテキストの原則に従うことができます。進化的アーキテクチャは、標準化された高度にスケーラブルなインフラストラクチャシステムを採用し、標準化されたアプリケーションモデルやモジュール操作およびメンテナンス機能などの高度なクラウドネイティブアプリケーションアーキテクチャプラクティスを広範囲に採用しているため、システムアーキテクチャ全体の責任の物理的モジュール性、再利用性、分離を達成します。進化的アーキテクチャでは、システムの各サービスは構造レベルの他のサービスから切り離されており、サービスの交換はLEGOブロックを交換するのと同じくらい簡単です。

（2）進化的建築の適用

現代のソフトウェアエンジニアリングの実践では、進化的アーキテクチャには、システムのさまざまなレベルで異なる実践と症状があります。

ビジネス開発に向けたアプリケーションアーキテクチャでは、進化的アーキテクチャは通常、マイクロサービス設計と分離できません。たとえば、Alibabaのインターネットeコマースアプリケーション（おなじみのTaobaoやTmallなど）では、システムアーキテクチャ全体が、明確に定義された境界を持つ数千のコンポーネントに慎重に設計されています。目的は、非破壊的な変更を加えたい開発者に、不適切な結合のために予測不可能な方向に向けられた変更を避け、それによってアーキテクチャの進化を妨げる開発者により大きな利便性を提供することです。進化的アーキテクチャを備えたソフトウェアは、ある程度のモジュール性をサポートしていることがわかります。これは、通常、古典的な層状アーキテクチャとマイクロサービスのベストプラクティスに反映されています。

プラットフォーム開発レベルでは、進化アーキテクチャは、能力指向のアーキテクチャ（COA）としてより反映されています。 Kubernetesなどのクラウドネイティブテクノロジーがますます人気が高まるにつれて、標準に基づいたクラウドネイティブのインフラストラクチャは、プラットフォームアーキテクチャの能力プロバイダーになりつつあります。これに基づくオープンアプリケーションモデル（OAM）の概念は、アプリケーションアーキテクチャの観点から機能に応じて標準化されたインフラストラクチャをモジュール化するCOAプラクティスです。

（3）クラウドネイティブの下のアーキテクチャの進化

現在、進化的アーキテクチャはまだ急速な成長と普及の段階にあります。ただし、ソフトウェアエンジニアリング分野全体は、ソフトウェアの世界が絶えず変化しており、静的ではなく動的であるというコンセンサスに達しています。アーキテクチャも単純な方程式ではありません。これは、進行中のプロセスのスナップショットです。したがって、ビジネスアプリケーションであろうとプラットフォーム開発であろうと、進化的アーキテクチャは避けられない開発動向です。業界の建築更新のための多数のエンジニアリング慣行は、問題を示しています。アプリケーションを最新の状態に保つために必要な努力は、実装アーキテクチャを無視するために膨大です。ただし、優れたアーキテクチャ計画は、アプリケーションが新しいテクノロジーを導入するコストを削減するのに役立ちます。これには、アプリケーションとプラットフォームが次のアーキテクチャの要件を満たす必要があります：アーキテクチャの標準化、責任の分離、モジュール化。クラウドネイティブ時代において、オープンアプリケーションモデル（OAM）は、進化アーキテクチャの進歩の重要な原動力に急速になりつつあります。

結論

クラウドネイティブアーキテクチャの構築と進化は、クラウドコンピューティングのコア特性（弾力性、自動化、回復力など）に基づいており、ビジネスの目標と特性と組み合わさって、企業や技術者がクラウドコンピューティングの技術的配当を完全に解き放つのを支援することがわかります。クラウドネイティブの継続的な調査により、さまざまなテクノロジーが絶えず拡大し、さまざまなシナリオが絶えず濃縮されており、クラウドネイティブアーキテクチャは進化し続けます。しかし、これらの変更の過程で。典型的な建築設計の原則は常に非常に重要であり、建築設計と技術の実装を導きます。