Azure でのミッション クリティカルなワークロードに関するアプリケーション プラットフォームの考慮事項
Azure には、高可用性アプリケーションをホストするためのコンピューティング サービスが数多く用意されています。 サービスは、機能面と複雑さで異なります。 次に基づいてサービスを選択することをお勧めします。
- 信頼性、可用性、パフォーマンス、およびセキュリティのためなど、機能以外の要件。
- スケーラビリティ、コスト、操作性、複雑さなどの決定要因。
アプリケーション ホスティング プラットフォームの選択は、他のすべての設計領域に影響を与える重要な決定です。 たとえば、レガシまたは独自の開発ソフトウェアは、PaaS サービスやコンテナー化されたアプリケーションでは実行されない場合があります。 この制限は、コンピューティング プラットフォームの選択に影響します。
ミッションクリティカルなアプリケーションでは、複数のコンピューティング サービスを使用して、それぞれが異なる要件を持つ複数の複合ワークロードとマイクロサービスをサポートできます。
この設計領域では、コンピューティングの選択、設計、および構成のオプションに関連する推奨事項が提供されます。 コンピューティング ディシジョン ツリーについて理解を深めることもお勧めします。
重要
この記事は、Azure Well-Architected フレームワークのミッション クリティカルワークロードのシリーズの一部です。 このシリーズをよく知らない場合は、「ミッション クリティカルなワークロードとは」から始めることをお勧めします。
プラットフォーム リソースのグローバル分散
ミッション クリティカルなワークロードの一般的なパターンには、グローバル リソースとリージョン リソースが含まれます。
特定の Azure リージョンに制約されていない Azure サービスは、グローバル リソースとしてデプロイまたは構成されます。 一部のユース ケースには、複数のリージョンにトラフィックを分散する、アプリケーション全体の永続的な状態を格納する、またはグローバル静的データをキャッシュするなどがあります。 スケール ユニット アーキテクチャとグローバル分散の両方に対応する必要がある場合は、Azure リージョン間でリソースを最適に分散またはレプリケートする方法を検討してください。
その他のリソースは、リージョンにデプロイされます。 デプロイ スタンプの一部としてデプロイされるこれらのリソースは、通常、スケール ユニットに対応します。 ただし、リージョンには複数のスタンプを含めることができます。またスタンプには複数の単位を含めることができます。 リージョン リソースは主なワークロードの実行を担うため、その信頼性は非常に重要です。
次の図は、設計の概要を示します。 ユーザーは、中央のグローバル エントリ ポイントを介してアプリケーションにアクセスします。中央のグローバル エントリ ポイントは、要求を適切なリージョンのデプロイ スタンプにリダイレクトします。
ミッション・クリティカルなアーキテクチャを示している図です。
ミッションクリティカルな設計手法には、複数リージョンのデプロイが必要です。 このモデルは、リージョン全体がダウンした場合でもアプリケーションの可用性を維持するために、地域のフォールト トレランスを保証します。 マルチリージョン アプリケーションを設計する場合は、それぞれのアプローチで大きなトレードオフがあるため、アクティブ/アクティブ/アクティブ/パッシブなどのさまざまなデプロイ戦略とアプリケーション要件を考慮してください。 ミッションクリティカルなワークロードの場合は、アクティブ/アクティブ モデルを強くお勧めします。
すべてのワークロードが、複数のリージョンの同時実行をサポートまたは必要とするわけではありません。 最適な設計上の判断を決定するには、特定のアプリケーション要件とトレードオフを比較検討する必要があります。 信頼性ターゲットが低い特定のアプリケーション シナリオでは、アクティブ/パッシブまたはシャーディングが適切な代替手段となる場合があります。
可用性ゾーンを使用すると、リージョン内の複数のデータ センターにまたがる可用性の高いリージョン デプロイを提供できます。 ほぼすべての Azure サービスは、ゾーン構成またはゾーン冗長構成のいずれかで利用できます。ゾーン構成ではサービスが特定のゾーンに委任され、ゾーン冗長構成ではプラットフォームによってサービスがゾーン間で自動的に分散され、ゾーンの停止に耐えることができます。 これらの構成は、データセンター レベルまでのフォールト トレランスを提供します。
設計上の考慮事項
リージョン内およびゾーン内の機能. すべての Azure リージョンですべてのサービスと機能を利用できるわけではありません。 この考慮事項は、選択したリージョンに影響する可能性があります。 また、可用性ゾーンはすべてのリージョンで提供されているわけではありません。
リージョン ペア. Azure のリージョンは、単一の地理的場所にある 2 つのリージョンで構成されるリージョン ペアにグループ化されます。 一部の Azure サービスでは、ペア リージョンを使用してビジネス継続性を確保し、データ損失に対する保護レベルを提供します。 たとえば、Azure Geo 冗長ストレージ (GRS) では、データがセカンダリのぺア リージョンに自動的にレプリケートされるため、プライマリ リージョンが復旧できない場合でもデータの持続性を保つことができます。 停止によって複数の Azure リージョンに影響がある場合、各ペアの少なくとも 1 つのリージョンが優先的に復旧されます。
データ整合性。 整合性の課題については、グローバル分散データ ストア、スタンプ付きリージョン アーキテクチャ、アクティブ/アクティブなデプロイの部分的な使用を検討してください。 部分的なデプロイでは、一部のコンポーネントはすべてのリージョンでアクティブであり、他のコンポーネントはプライマリ リージョン内で一元的に配置されます。
安全な展開。 Azure の安全なデプロイ プラクティス (SDP) フレームワークは、Azure プラットフォームに対するすべてのコードと構成の変更 (計画メンテナンス) を段階的にロールアウトされるようにします。 健康状態は、放出の過程での劣化について分析されます。 カナリア フェーズとパイロット フェーズが正常に完了すると、プラットフォームの更新はリージョン ペア間でシリアル化されるため、各ペアの 1 つのリージョンのみが特定の時点で更新されます。
プラットフォームの容量。 他のクラウド プロバイダーと同様に、Azure のリソースは有限です。 使用できない場合は、リージョンの容量制限の結果である可能性があります。 リージョンの停止が発生した場合、ワークロードがペアリージョン内で復旧しようとするため、リソースの需要が増加します。 停止した場合、供給が一時的に需要を満たさない容量の問題が発生する可能性があります。
設計の推奨事項
リージョンの障害から保護するために、少なくとも 2 つの Azure リージョンにソリューションをデプロイします。 ワークロードに必要な機能と特性を持つリージョンにデプロイします。 この機能は、データの保存場所と保持の要件を満たしながら、パフォーマンスと可用性の目標を満たす必要があります。
たとえば、一部のデータ コンプライアンス要件では、使用可能なリージョンの数が制限され、設計の妥協を余儀なくされる可能性があります。 このような場合は、障害を予測、検出、対応するために、運用ラッパーへ追加投資することを強くお勧めします。 2 つのリージョンがあり、そのうちの 1 つのリージョンだけが可用性ゾーンをサポートしている (3 + 1 データセンター モデル)、地理的な制約があるとします。 障害ドメインの分離を使用してセカンダリ デプロイ パターンを作成し、両方のリージョンをアクティブな構成でデプロイできるようにします。またプライマリ リージョンに複数のデプロイ スタンプが格納されるようにします。
適切な Azure リージョンで必要なすべての機能が提供されていない場合は、地理的な分散に優先し、信頼性を最大限に高めるために、リージョンのデプロイ スタンプの一貫性については妥協する覚悟が必要です。 単一の Azure リージョンのみが適している場合は、選択したリージョンに複数のデプロイ スタンプ (リージョン スケール ユニット) をデプロイしてリスクを軽減し、可用性ゾーンを使用してデータセンター レベルのフォールト トレランスを提供します。 ただし、地理的な分布におけるこのような重大な侵害により、達成可能な複合 SLO と全体的な信頼性が大幅に制約されます。
重要
99.99%以上の SLO を対象とするシナリオでは、少なくとも 3 つのデプロイ リージョンをお勧めします。 すべてのユーザー フローの 複合 SLO を計算します。 これらのターゲットがビジネス ターゲットと一致していることを確認します。
大量のトラフィックを含む大規模なアプリケーション シナリオの場合は、単一のリージョン内で潜在的な容量の制約をナビゲートするために、複数のリージョン間でスケーリングするソリューションを設計します。 追加のリージョンデプロイ スタンプは、より高い複合 SLO を実現できます。 詳細については、マルチリージョン ターゲットを実装する方法を参照してください。
回復ポイントの目標 (RPO) と目標復旧時間 (RTO) を定義して検証します。
単一の地域内で、リージョン ペアを優先的に使用することで、計画的メンテナンスのための SDP シリアル化されたロールアウト、および計画外メンテナンスの地域的優先順位付けを活用できます。
ネットワーク待機時間を最小限に抑え、エンドツーエンドのパフォーマンスを最大化するために、Azure リソースをユーザーと地理上に対して併置します。
- また、コンテンツ配信ネットワーク (CDN) やエッジ キャッシュなどのソリューションを使用して、分散ユーザー ベースの最適なネットワーク待ち時間を実現することもできます。 詳細については、グローバル トラフィック ルーティング、アプリケーション配信サービス、キャッシュと静的コンテンツ配信を参照してください。
デプロイ リージョンを選択する場合は、現在のサービスの可用性を製品ロードマップに合わせます。 一部のサービスは、すべてのリージョンですぐに利用できない場合があります。
コンテナー詰め
コンテナーには、アプリケーション コードと、アプリケーションの実行に必要な関連する構成ファイル、ライブラリ、依存関係が含まれます。 コンテナー化は、アプリケーション コードとその依存関係のアブストラクション レイヤーを提供し、基になるホスティング プラットフォームからの分離を作成します。 単一のソフトウェア パッケージは非常に移植性が高く、さまざまなインフラストラクチャ プラットフォームとクラウド プロバイダー間で一貫して実行できます。 開発者はコードを書き換える必要がなく、アプリケーションをより迅速かつ確実にデプロイできます。
重要
ミッションクリティカルなアプリケーション パッケージにはコンテナーを使用することをお勧めします。 これは、同じ仮想化インフラストラクチャで複数のコンテナーをホストできるため、インフラストラクチャの使用率が向上します。 また、すべてのソフトウェアがコンテナーに含まれているため、ランタイムやライブラリのバージョンに関係なく、さまざまなオペレーティング システム間でアプリケーションを移動できます。 従来の仮想化ホスティングと比較して、コンテナーの管理も簡単です。
ミッションクリティカルなアプリケーションでは、パフォーマンス上のボトルネックを回避するために、迅速にスケーリングする必要があります。 コンテナー イメージは事前に構築されています。これにより、アプリケーションのブートストラップ中にのみ起動するように制限することができ、迅速なスケーラビリティが実現します。
設計上の考慮事項
監視. コンテナー内のアプリケーションにアクセスするために、サービスを監視するのは困難な場合があります。 通常、CPU や RAM の使用状況などのコンテナー状態インジケーターを収集して格納する場合は、サードパーティ製のソフトウェアが必要です。
セキュリティ。 ホスティング プラットフォーム OS カーネルは、複数のコンテナー間で共有され、単一の攻撃点が作成されます。 ただし、コンテナーは基になるオペレーティング システムから分離されているため、ホスト仮想マシン (VM) アクセスのリスクは制限されます。
State。 実行中のコンテナーのファイル システムにデータを格納することはできますが、コンテナーを再作成した場合にデータは保持されません。 代わりに、外部ストレージをマウントするか、外部データベースを使用してデータを保持します。
設計の推奨事項
すべてのアプリケーション コンポーネントをコンテナー化します。 アプリケーション デプロイ パッケージのプライマリ モデルとしてコンテナー イメージを使用します。
可能であれば、Linux ベースのコンテナー ランタイムを優先します。 イメージはより軽量で、Linux ノード/コンテナーの新機能が頻繁にリリースされます。
これは、短いライフサイクルでコンテナーを変更不可にし、置き換え可能にします。
コンテナー、コンテナー ホスト、および基になるクラスターから、関連するすべてのログとメトリックを収集してください。 収集したログとメトリックを統合データ シンクに送信して、さらに処理と分析を行います。
Azure Container Registry にコンテナー イメージを保存します。 geoレプリケーションを使用してすべてのリージョンにコンテナーイメージをレプリケートします。 コンテナー レジストリ用 Microsoft Defender を有効にして、コンテナー イメージ用に脆弱性スキャンを提供します。 レジストリへのアクセスが Microsoft Entra ID によって管理されていることを確認します。
コンテナーのホスティングとオーケストレーション
複数の Azure アプリケーション プラットフォームで、コンテナーを効果的にホストできます。 これらの各プラットフォームには、長所と短所があります。 ビジネス要件と照らし合わせて、オプションを比較します。 ただし、信頼性、スケーラビリティ、パフォーマンスは常に最適化します。 詳細については、次の記事を参照してください。
重要
Azure Kubernetes Service (AKS) と Azure Container Apps は、お客様の要件に応じて、コンテナー管理の最初の選択肢となります。 Azure App Service はオーケストレーターではありませんが、問題の少ないコンテナー プラットフォームとして、AKS の代替手段として使用できます。
Azure Kubernetes Service の設計に関する考慮事項と推奨事項
マネージド Kubernetes サービスである AKS は、複雑なクラスター管理作業を必要とせずに迅速なクラスター プロビジョニングを可能にし、高度なネットワーク機能と ID 機能を含む機能セットを提供します。 推奨事項の全容については、「Azure Well-Architected Framework レビュー - AKS」を参照してください。
重要
基本的な構成上の決定事項には、AKS クラスターを再デプロイしないかぎり変更できないものがいくつかあります。 たとえば、パブリック AKS クラスターとプライベート AKS クラスターの選択、Azure ネットワーク ポリシーの有効化、Microsoft Entra 統合、サービス プリンシパルの代替としての AKS 用マネージド ID の使用などがあります。
信頼性
AKS は、ネイティブの Kubernetes コントロール プレーンを管理します。 コントロール プレーンを使用できない場合、ワークロードでダウンタイムが発生します。 AKS が提供する次の信頼性機能を活用してください。
信頼性と可用性を最大化するために、異なる Azure リージョンにわたって AKS クラスターをスケール ユニットとしてデプロイします。 物理的に離れたデータセンターにAKSのコントロールプレーンとエージェントノードを分散することで、Azure地域全体の可用性ゾーンを活用して回復力を最大化します。 ただし、コロケーションの遅延が問題となっている場合は、単一ゾーン内で AKS のデプロイを実施するか、近接配置グループを使用してノード間の待機時間を最小限に抑えることができます。
運用環境のクラスターでは、AKS アップタイム SLA を使用して、Kubernetes API エンドポイントの可用性保証を最大にします。
スケーラビリティ
考慮する事項には、ノード数、クラスターあたりのノードプール数、サブスクリプションごとのクラスター数といった AKS のスケーリング制限が含まれます。この情報は、このリンクで参照できます。
スケール制限が制約となる場合は、スケール ユニット戦略を活用し、クラスター内にデプロイするユニットを増やします。
クラスターオートスケーラーを有効にし、リソースの制約に応じてエージェントノードの数を自動的に調整します。
水平ポッド自動スケーラーを使って、CPU 使用量やその他のメトリクスに基づいてデプロイメント内のポッド数を調整します。
大規模な利用やバースト利用のシナリオでは、迅速かつ大規模なスケーリングを実現するために、仮想ノードを使用することを検討してください。
アプリケーション デプロイ マニフェストで、ポッドのリソース要求と制限を定義します。 そうしないと、パフォーマンスの問題が発生する可能性があります。
分離
ワークロードとシステム ツールで使用される、インフラストラクチャ間の境界を維持します。 インフラストラクチャを共有すると、リソース使用率が高くなり、ノイズの多い近隣のシナリオが発生する可能性があります。
システム サービスとワークロード サービスには、個別のノード プールを使用します。 ワークロード コンポーネント専用のノード プールは、高メモリ GPU VM などの特殊なインフラストラクチャ リソースの要件に基づいている必要があります。 一般的には、不要な管理オーバーヘッドを減らすために、多数のノード プールをデプロイしないようにします。
テイントとトレラレーションを使用して専用ノードを提供し、リソース集約型のアプリケーションを制限します。
アプリケーション アフィニティとアンチアフィニティの要件を評価し、ノード上のコンテナーの適切なコロケーションを構成します。
セキュリティ
既定のバニラ Kubernetes では、ミッションクリティカルなシナリオ向けに適切なセキュリティ態勢を確保するために、膨大な構成が必要です。 AKS は、さまざまなセキュリティリスクにすぐに対応できます。 機能には、プライベート クラスター、Log Analytics への監査とログ記録、強化されたノード イメージ、マネージド ID が含まれます。
「AKS セキュリティ ベースライン」に記載されている構成ガイダンスを適用します。
AKS 機能を使用して、クラスター ID とアクセス管理を処理し、運用オーバーヘッドを削減し、一貫したアクセス管理を適用します。
資格情報の管理とローテーションを回避するには、サービス プリンシパルの代わりにマネージド ID を使用します。 クラスター レベルで、管理対象のIDを追加できます。 ポッド レベルでは、Microsoft Entra Workload ID を介してマネージド ID を使用できます。
Microsoft Entra 統合を使用して、アカウントとパスワードの一元管理、アプリケーションのアクセス管理、およびアイデンティティ保護の強化を実現します。 KubernetesのRBACを使用する際には、Microsoft Entra IDを活用して最小特権を実現し、構成やシークレットへのアクセスを保護するために、管理者特権の付与を最小限に抑えることができます。 また、Azure ロールベースのアクセス制御を使用して、Kubernetes クラスター構成ファイルへのアクセスを制限します。 コンテナーが実行できるアクションへのアクセスを制限し、最低限のアクセス許可を指定し、ルート権限の昇格を避けます。
アップグレード
クラスターとノードは定期的にアップグレードする必要があります。 AKS は、ネイティブの Kubernetes のリリース サイクルに合わせて、複数の Kubernetes バージョンをサポートします。
GitHub で公開されている AKS ロードマップとリリース ノートを購読して、今後の変更、機能強化、そして最も重要な Kubernetes のバージョン リリースと廃止予定に関する最新情報を入手してください。
ベストプラクティスと一致させるために、AKS チェックリストに記載されているガイダンスを適用します。
AKS がサポートするノードおよびクラスターの更新方法を理解しておいてください。 これらの方法は、手動で、または自動で操作できます。 これらの操作のメンテナンス時間枠を定義するために、計画メンテナンスを使用できます。 新しいイメージは毎週リリースされます。 AKS は、自動アップグレード チャネルもサポートしており、新しいバージョンの Kubernetes や新しいノード イメージが利用可能になると、AKS クラスターを自動的にアップグレードします。
ネットワーク
ユース ケースに最適なネットワーク プラグインを評価します。 ポッド間のトラフィックをきめ細かく制御する必要があるかどうかを判断します。 Azure は、特定のユース ケースに応じて、kubenet、Azure CNI、独自の CNI をサポートします。
ネットワーク要件とクラスターのサイズを評価した後、Azure CNI の使用を優先します。 Azure CNI は、クラスター内のトラフィック制御のために、Azure または Calico のネットワーク ポリシーの使用を有効にります。
監視
監視ツールは、実行中のポッドからログとメトリックをキャプチャできる必要があります。 また、実行中のリソースとワークロードの正常性を監視するために、Kubernetes Metrics API から情報を収集する必要があります。
Azure Monitor と Application Insights を使用して、トラブルシューティング用に AKS リソースからメトリック、ログ、診断を収集します。
Kubernetes リソース ログを有効にして確認します。
Azure Monitor で Prometheus メトリックを構成します。 Monitor の Container Insights は導入を簡素化し、すぐに利用可能な監視機能を提供し、組み込みの Prometheus サポートを通じて、より高度な機能を実現します。
ガバナンス
ポリシーを使用して、一貫した方法で一元的なセーフガードを AKS クラスターに適用します。 サブスクリプション スコープ以上でポリシー割り当てを適用して、開発チーム間の一貫性を促進します。
Azure Policy を使用して、ポッドに付与される機能とその実行が、ポリシーと矛盾するかどうかを制御します。 このアクセスは、Azure Policy Add-on for AKSが提供する組み込みポリシーを使用して定義されます。
Azure Policy を使用して、AKS クラスターと ポッド 構成の信頼性とセキュリティの一貫したベースラインを確立します。
Azure Policy Add-on for AKS を使用して、ルート特権などのポッド機能を制御し、ポリシーに準拠しないポッドの作成を許可しないようにします。
Note
Azure ランディング ゾーンにデプロイする場合、ランディング ゾーンの実装において一貫した信頼性とセキュリティを確保するための Azure ポリシーを提供する必要があります。
重要なリファレンス実装は、推奨される信頼性とセキュリティ構成を促進するための一連の基本方針を提供します。
Azure App Service の設計に関する考慮事項と推奨事項
Web ベースおよび API ベースのワークロードの場合、App Service を AKS の代替手段として使用できる場合があります。 Kubernetes のような複雑さを伴わずに、低摩擦のコンテナー プラットフォームを提供します。 推奨事項の全容については、App Service の信頼性に関する考慮事項および App Service のオペレーショナル エクセレンスに関する記事を参照してください。
信頼性
TCP ポートと SNAT ポートの使用状況を調べる。 TCP 接続は、すべての送信接続に使用されます。 SNAT ポートは、パブリック IP アドレスへの送信接続に使用されます。 SNAT ポートの枯渇は、一般的な障害のシナリオです。 Azure Diagnostics を使用してポートを監視する際に、ロード テストによってこの問題を予測的に検出する必要があります。 SNAT エラーが発生した場合は、複数または大規模なワーカー間でスケーリングするか、SNAT ポートの保持と再利用に役立つコーディング プラクティスを実装する必要があります。 使用できるコーディング プラクティスの例としては、接続プールやリソースの遅延読み込みなどがあります。
TCP ポートの枯渇は、もう 1 つの障害のシナリオです。 これは、特定のワーカーからの送信接続の合計が容量を超えたときに発生します。 利用できる TCP ポートの数は、ワーカーのサイズによって異なります。 推奨事項については、TCP ポートと SNAT ポートに関する記事を参照してください。
スケーラビリティ
最初から適切な推奨事項を適用できるように、将来のスケーラビリティ要件とアプリケーションの拡大を計画します。 そうすることで、ソリューションの拡大に伴う技術的な移行上の負債を回避できます。
オートスケールを有効にして、サービス要求を処理するのに十分なリソースを確保します。 App Service で高密度ホスティングを行うため、アプリ別のスケーリングを計算します。
App Service プランあたりのインスタンスには既定のソフト制限があることにご注意ください。
オートスケール ルールを適用します。 App Service プランでは、プロファイル内のいずれかのルールが満たされている場合はスケールアウトしますが、そのプロファイル内のすべてのルールが満たされている場合にのみスケールインします。 スケールアウトとスケールインの両方のルールの組み合わせを使用して、オートスケールでスケールアウトとスケールインの両方に対してアクションを実行できるようにします。 単一のプロファイル内の複数のスケーリング ルールの動作を理解します。
アプリケーションをホストする App Service プランから独立してスケーリングするために、App Serviceプランのレベルでアプリごとのスケーリングを有効にできることに注意してください。 アプリは、均等な分散のベスト エフォート アプローチを使用して、使用可能なノードに割り当てられます。 均等な分散は保証されませんが、プラットフォームでは、同じアプリの 2 つのインスタンスが同じインスタンスでホストされないことを保証します。
監視
アプリケーションの動作を監視し、関連するログとメトリックにアクセスして、アプリケーションが期待どおりに動作することを確認します。
診断ログを使用して、アプリケーション レベルおよびプラットフォーム レベルのログを、Azure Event Hubs を介して Log Analytics、Azure Storage、またはサードパーティ ツールに取り込むことができます。
Application Insights で監視を行うことにより、アプリケーションのパフォーマンスを深く分析できます。
ミッション クリティカルなアプリケーションには、障害が発生した場合に自動復旧する機能が必要です。 Auto Healを有効にして、異常状態のワーカーを自動で再起動します。
すべての重要なダウンストリーム依存関係を評価するには、適切な正常性チェックを使用する必要があります。これは、全体的な正常性を確保するのに役立ちます。 正常性チェックを有効にして、応答しないワーカーを特定することを強くお勧めします。
配置
App Service プランごとのインスタンスの既定の制限を回避するには、単一のリージョンに複数のスケール ユニットで App Service プランをデプロイします。 App Service プランを可用性ゾーンの構成にデプロイして、リージョン内の複数のゾーンにわたってワーカー ノードが分散されるようにします。 サポート チケットを開き、ワーカーの最大数を、通常のピーク負荷に対応するために必要なインスタンス数の 2 倍に増やすことを検討してください。
コンテナー レジストリ
コンテナー レジストリは、AKS などのコンテナー ランタイム環境にデプロイされるイメージをホストします。 ミッションクリティカルなワークロード用にコンテナー レジストリを慎重に構成する必要があります。 イメージをプルする際、特にスケーリング操作中は、停止によって遅延が発生しないようにする必要があります。 次の考慮事項と推奨事項では、Azure Container Registry に焦点を当て、集中型デプロイ モデルとフェデレーション デプロイ モデルに関連するトレードオフについて説明します。
設計上の考慮事項
形式。 プッシュ操作とプル操作の両方に対して、Docker で提供される形式と標準に依存するコンテナー レジストリの使用を検討してください。 これらのソリューションは互換性があり、ほとんどが交換可能です。
デプロイ モデル。 コンテナー レジストリは、組織内の複数のアプリケーションによって使用される一元化されたサービスとしてデプロイできます。 または、特定のアプリケーション ワークロード専用のコンポーネントとしてデプロイすることもできます。
パブリック レジストリ。 コンテナー イメージは、Azure や特定の仮想ネットワークの外部に存在する Docker Hub またはその他のパブリック レジストリに格納されます。 これは必ずしも問題ではありませんが、サービスの可用性、調整、データ流出に関連するさまざまな問題につながる可能性があります。 一部のアプリケーション シナリオでは、エグレス トラフィックを制限する、可用性を高める、または調整の可能性を回避するために、プライベート コンテナー レジストリ内のパブリック コンテナー イメージをレプリケートする必要があります。
設計の推奨事項
アプリケーション ワークロード専用のコンテナー レジストリ インスタンスを使用します。 組織の可用性と信頼性の要件がアプリケーションと完全に一致しない限り、一元化されたサービスへの依存関係を作成しないでください。
推奨される コア アーキテクチャ パターンでは、コンテナー レジストリは有効期間が長いグローバル リソースです。 環境ごとに単一の、グローバル コンテナー レジストリの使用を検討してください。 たとえば、グローバル運用レジストリを使用します。
パブリック レジストリの SLA が、信頼性とセキュリティ目標と一致していることを確認します。 Docker Hub に依存するユース ケースの調整上の制限には、特に注意してください。
コンテナー イメージをホストするために、Azure Container Registry の優先順位を設定します。
Azure Container Registry の設計に関する考慮事項と推奨事項
このネイティブ サービスには、geo レプリケーション、Microsoft Entra 認証、コンテナーの自動ビルド、Container Registry タスクによる修正プログラムの適用など、さまざまな機能が用意されています。
信頼性
リージョンの依存関係を削除し、待機時間を最適化するために、すべてのデプロイ リージョンへの geo レプリケーションを構成します。 Container Registry は、複数の構成済みリージョンに対する geo レプリケーションによって高可用性をサポートし、リージョンの停止に対する回復性を提供します。 リージョンが使用できなくなった場合でも、他のリージョンは引き続きイメージ要求を処理します。 リージョンがオンラインに戻ると、Container Registry は復旧し、そのリージョンに対する変更をレプリケートします。 この機能により、構成された各リージョン内のレジストリ コロケーションも提供され、ネットワークの待機時間とリージョン間のデータ転送コストが削減されます。
可用性ゾーンのサポートを提供する Azure リージョンでは、Premium コンテナー レジストリのサービス レベルでゾーン冗長性がサポートされており、ゾーンの障害に対する保護が提供されます。 プレミアムのサービス レベルではプライベート エンドポイントもサポートされており、信頼性の問題につながる可能性のあるレジストリへの不正アクセスを防止するのに役立ちます。
同じ Azure リージョン内で、使用しているコンピューティング リソースの近くでイメージをホストします。
イメージのロック
イメージは、たとえば手動エラーの結果として削除される可能性があります。 Container Registry では、変更や削除を防ぐためにイメージ バージョンやリポジトリをロックすることがサポートされています。 以前にデプロイされたイメージ バージョンがその場で変更されると、変更前後で同じバージョンのデプロイ結果が異なることがあります。
削除からコンテナ レジストリ インスタンスを保護する場合は、リソース ロックを使用します。
タグ付けされたイメージ
Tagged Container Registry イメージはデフォルトで変更が可能です。つまり、レジストリにプッシュされた複数のイメージにおいて同じタグを使用することができます。 運用環境のシナリオでは、アプリケーションのアップタイムに影響を及ぼす恐れのある予期せぬ動作につながる可能性があります。
ID 管理とアクセス管理
Microsoft Entra 統合認証を使用して、アクセス キーに依存するのではなく、イメージをプッシュおよびプルします。 セキュリティを強化するには、管理者アクセス キーの使用を完全に無効にします。
サーバーレス コンピューティング
サーバーレス コンピューティングは、必要に応じてリソースを提供し、インフラストラクチャを管理する必要がなくなります。 クラウド プロバイダーは、デプロイされたアプリケーション コードの実行に必要なリソースを自動的にプロビジョニング、スケーリング、管理します。 Azure には、いくつかのサーバーレス コンピューティング プラットフォームが用意されています。
Azure Functions。 Azure Functions を使用すると、アプリケーション ロジックは、HTTP 要求やキュー メッセージなどのイベントに応答して実行される、個別のコード ブロックまたは、関数として実装されます。 各関数は、需要を満たすために必要に応じてスケーリングされます。
Azure Logic Apps。 Logic Apps は、さまざまなアプリ、データ ソース、サービス、システムを統合する自動化されたワークフローの作成と実行に最適です。 Azure Functions と同様に、Logic Apps では、イベント駆動処理に組み込みのトリガーが使用されます。 ただし、アプリケーション コードをデプロイする代わりに、条件分岐やループなどのコード ブロックをサポートするグラフィカル ユーザー インターフェイスを使用してロジック アプリを作成できます。
Azure API Management。 API Management を使用すると、従量課金レベルを使用して、セキュリティ強化 API の発行、変換、メンテナンス、監視を行うことができます。
Power Apps と Power Automate。 これらのツールは、ロー コードまたはノー コードの開発エクスペリエンスを提供します。これは、単純なワークフロー ロジックと、ユーザー インターフェイスに接続することで設定可能な統合機能を備えています。
ミッションクリティカルなアプリケーションの場合、サーバーレス テクノロジは、単純な開発と運用を提供します。これは、単純なビジネス ユース ケースにとって価値があります。 ただし、この単純さは、スケーラビリティ、信頼性、パフォーマンスの点で柔軟性を犠牲にしており、ほとんどのミッションクリティカルなアプリケーション シナリオでは実現できません。
次のセクションでは、クリティカルでないワークフロー シナリオの代替プラットフォームとして Azure Functions と Logic Apps を使用するための設計上の考慮事項と推奨事項について説明します。
Azure Functions の設計に関する考慮事項と推奨事項
ミッションクリティカルなワークロードには、クリティカルなシステム フローとクリティカルでないシステム フローがあります。 Azure Functions は、クリティカルなシステム フローほど厳しいビジネス要件のないフローに対して有効な選択肢です。 関数は可能な限り高速に実行される明確な処理を実行するため、これは短命なプロセスを持つイベント駆動型のフローに適しています。
アプリケーションの信頼性レベルに適した Azure Functions ホスティング オプションを選択します。 Premium プランをお勧めします。このプランでは、コンピューティング インスタンスのサイズを構成できます。 専用プランは、最小のサーバーレス オプションです。 オートスケールが提供されますが、これらのスケール操作は他のプランの操作よりも遅くなります。 Premium プランを使用して、信頼性とパフォーマンスを最大化することをお勧めします。
これには、セキュリティに関する考慮事項がいくつかあります。 HTTP トリガーを使用して外部エンドポイントを公開する場合は、Web アプリケーション ファイアウォール (WAF) を使用して、一般的な外部攻撃ベクトルから HTTP エンドポイントを保護します。
プライベート仮想ネットワークへのアクセスを制限するには、プライベート エンドポイントの使用をお勧めします。 また、悪意のある管理者シナリオなどのデータ流出リスクを軽減することもできます。
Azure Functions コードでコード スキャン ツールを使用し、これらのツールを CI/CD パイプラインと統合する必要があります。
Azure Logic Apps の設計に関する考慮事項と推奨事項
Azure Functions と同様に、Logic Apps では、イベント駆動処理に組み込みのトリガーが使用されます。 また、アプリケーション コードをデプロイする代わりに、条件分岐、ループ、その他のコンストラクトなどのブロックをサポートするグラフィカル ユーザー インターフェイスを使用してロジック アプリを作成できます。
複数の展開モードが使用できます。 シングルテナントのデプロイを確実に行い、ノイズの多い近隣シナリオを軽減するには、Standard モードをお勧めします。 このモードでは、Azure Functions に基づくコンテナー化されたシングルテナント Logic Apps ランタイムが使用されます。 このモードでは、ロジック アプリに複数のステートフルとステートレスのワークフローを含めることができます。 構成上の制限に注意する必要があります。
IaaS を介した制約付き移行
既存のオンプレミス デプロイを持つ多くのアプリケーションは、仮想化テクノロジと冗長ハードウェアを使用して、ミッション クリティカルなレベルの信頼性を提供します。 最新化は、ミッション クリティカルなワークロードに推奨されるクラウドネイティブ ベースライン (North Star) アーキテクチャ パターンとの完全な整合を阻むビジネス上の制約によって妨げられることがよくあります。 そのため、多くのアプリケーションでは、仮想化と Azure Virtual Machines をプライマリ アプリケーション ホスティング モデルとして使用する初期のクラウド デプロイを使用した段階的なアプローチを採用しています。 次の特定のシナリオでは、サービスとしてのインフラストラクチャ (IaaS) VM の使用が必要になる場合があります。
- 使用可能な PaaS サービスでは、必要なパフォーマンスや制御レベルが提供されない。
- ワークロードには、オペレーティング システムへのアクセス、特定のドライバー、またはネットワークとシステムの構成が必要。
- ワークロードは、コンテナーでの実行をサポートしていない。
- サード パーティのワークロードに対するベンダーサポートがない。
このセクションでは、Virtual Machines と関連するサービスを使用して、アプリケーション プラットフォームの信頼性を最大限に高める最適な方法について説明します。 また、クラウドネイティブおよび IaaS 移行シナリオを入れ替えるミッション クリティカルな設計手法の重要な側面について説明します。
設計上の考慮事項
IaaS VM を使用する運用コストは、VM とオペレーティング システムに管理要件があるため、PaaS サービスを使用するコストよりも大幅に高くなります。 VM を管理するには、ソフトウェア パッケージと更新プログラムを頻繁にロールアウトする必要があります。
Azure には、VM の可用性を向上させる次の機能が用意されています。
- 可用性ゾーンは、リージョン内で物理的に分離されたデータ センター間で VM を分散することによって、信頼性レベルをさらに高めるのに役立ちます。
- Azure 仮想マシン スケール セットは、グループ内の VM 数を自動的にスケールする機能を提供します。 インスタンスの正常性を監視し、異常なインスタンスを自動的に修復する機能も提供します。
- フレキシブル オーケストレーションによるスケール セットは、障害ドメインにわたって VM を自動的に分散することによって、ネットワーク、ディスク、電源の障害からの保護に役立ちます。
設計の推奨事項
重要
PaaS サービスとコンテナーを可能な限り使用して、運用の複雑さとコストを低減します。 IaaS VM は、必要な場合にのみ使用してください。
VM SKU のサイズを適切に調整して、リソースを効率的に活用します。
データ センター レベルのフォールト トレランスを達成するには、複数の可用性ゾーンにわたって 3 つ以上の VM をデプロイします。
- 市販のソフトウェアをデプロイする場合は、ソフトウェア ベンダーに問い合わせ、ソフトウェアを運用環境にデプロイする前に十分にテストしてください。
デプロイできないワークロードの場合、複数の可用性ゾーンで、3 台以上の VM を含む柔軟な仮想マシン スケール セットを使用してください。 適切な数の障害ドメインを構成する方法の詳細については、スケール セットでの障害ドメインの管理に関する記事を参照してください。
スケーラビリティとゾーン冗長性のために、Microsoft Azure Virtual Machine Scale Sets を優先して使用します。 この点は、負荷が異なるワークロードでは特に重要です。 たとえば、アクティブなユーザー数または 1 秒あたりの要求数がさまざまな負荷である場合などです。
個々の VM に直接アクセスしないでください。 可能であれば、その前にロード バランサーを使用してください。
リージョンの停止から保護するには、複数の Azure リージョンにアプリケーション VM をデプロイします。
- アクティブなデプロイ リージョン間でトラフィックの最適なルートを指定する方法の詳細については、ネットワークと接続の設計領域に関する記事を参照してください。
複数リージョンのアクティブ/アクティブデプロイをサポートしていないワークロードの場合は、リージョン フェールオーバーにホット/ウォーム スタンバイ VM を使用し、アクティブ/パッシブ デプロイを実装することを検討してください。
維持しなければならないカスタム イメージではなく、Azure Marketplace の標準イメージを使用します。
VM に変更をデプロイしてロールアウトする自動化されたプロセスを実装し、手動による介入を回避します。 詳細については、運用手順の設計領域にある IaaS の考慮事項を参照してください。
カオス実験を実装して、アプリケーションの障害を VM コンポーネントに挿入し、障害の軽減策を観察します。 詳細については、継続的な検証とテストを参照してください。
VM を監視し、診断ログとメトリクスが統合データシンクに取り込まれるようにします。
ミッションクリティカルなアプリケーションに関するセキュリティ プラクティスを実装し、該当する場合は、Azure における IaaS ワークロードのセキュリティに関するベスト プラクティスを実装します。
次のステップ
データ プラットフォームの考慮事項を確認します。