クラウドネイティブアーキテクチャの7つの原則についての簡単な説明

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

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

最終段階に向けて

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

関心の分離

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

失敗を考慮した設計

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

ビジネス インスタンスの障害の自己修復は、典型的なプロセス自動化シナリオです。ビジネスがクラウドに移行した後、クラウド プラットフォームはさまざまな技術的手段を通じてサーバー障害の可能性を大幅に削減しますが、ビジネス自体のソフトウェア障害を排除することはできません。ソフトウェア障害には、アプリケーション ソフトウェア自体の欠陥によって発生するクラッシュ、リソース不足によって発生するメモリ不足 (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 作業は通常分散されています。この分散型モデルでは、実際の運用環境で実行されるサービスのセキュリティが効果的に保証されなくなります。コードのバージョン管理、ビルド、および起動プロセスを標準化できれば、アプリケーション リリースのセキュリティを一元的に強化できます。

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

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

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

進化型アーキテクチャの特徴と価値

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

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

進化型アーキテクチャの応用

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

ビジネス開発向けのアプリケーション アーキテクチャでは、進化型アーキテクチャは通常、マイクロサービス設計と切り離せません。たとえば、Alibaba のインターネット電子商取引アプリケーション (おなじみの Taobao や Tmall など) では、システム アーキテクチャ全体が、境界が明確に定義された何千ものコンポーネントに注意深く設計されています。その目的は、非破壊的な変更を行いたい開発者にとってより大きな利便性を提供し、不適切な結合によって予測できない方向に向けられ、アーキテクチャの進化を妨げる変更を回避することです。進化型アーキテクチャを備えたソフトウェアは、ある程度のモジュール性をサポートしており、これは通常、従来の階層化アーキテクチャとマイクロサービスのベスト プラクティスに反映されています。

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

クラウドネイティブにおけるアーキテクチャの進化

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

結論

クラウドネイティブ アーキテクチャの構築と進化は、クラウド コンピューティングの中核特性 (弾力性、自動化、回復力など) に基づいており、ビジネス目標や特性と組み合わされているため、企業や技術者がクラウド コンピューティングの技術的利益を十分に発揮できることがわかります。クラウド ネイティブの継続的な探求により、さまざまなテクノロジが絶えず拡大し、さまざまなシナリオが絶えず充実し、クラウド ネイティブ アーキテクチャは進化し続けます。しかし、こうした変化の過程において。典型的な建築設計の原則は常に非常に重要であり、建築設計とテクノロジーの実装を導きます。