Azure でのミッション クリティカルなワークロードに関するアプリケーション プラットフォームの考慮事項

Azure には、高可用性アプリケーションをホストするためのコンピューティング サービスが数多く用意されています。 サービスは、機能面と複雑さで異なります。 次に基づいてサービスを選択することをお勧めします。

• 信頼性、可用性、パフォーマンス、およびセキュリティのためなど、機能以外の要件。
• スケーラビリティ、コスト、操作性、複雑さなどの決定要因。

アプリケーション ホスティング プラットフォームの選択は、他のすべての設計領域に影響を与える重要な決定です。 たとえば、レガシまたは独自の開発ソフトウェアは、PaaS サービスやコンテナー化されたアプリケーションでは実行されない場合があります。 この制限は、コンピューティング プラットフォームの選択に影響します。

ミッションクリティカルなアプリケーションでは、複数のコンピューティング サービスを使用して、それぞれが異なる要件を持つ複数の複合ワークロードとマイクロサービスをサポートできます。

この設計領域では、コンピューティングの選択、設計、および構成のオプションに関連する推奨事項が提供されます。 また、コンピューティング デシジョン ツリーについて理解することをお勧めします。

プラットフォーム リソースのグローバル分散

ミッション クリティカルなワークロードの一般的なパターンには、グローバル リソースとリージョン リソースが含まれます。

特定の Azure リージョンに制約されていない Azure サービスは、グローバル リソースとしてデプロイまたは構成されます。 一部のユース ケースには、複数のリージョンにトラフィックを分散する、アプリケーション全体の永続的な状態を格納する、またはグローバル静的データをキャッシュするなどがあります。 スケール ユニット アーキテクチャとグローバル分散の両方に対応する必要がある場合は、Azure リージョン間でリソースを最適に分散またはレプリケートする方法を検討してください。

その他のリソースは、リージョンにデプロイされます。 デプロイ スタンプの一部としてデプロイされるこれらのリソースは、通常、スケール ユニットに対応します。 ただし、リージョンには複数のスタンプを含めることができます。またスタンプには複数の単位を含めることができます。 リージョン リソースは主なワークロードの実行を担うため、その信頼性は非常に重要です。

次の図は、設計の概要を示します。 ユーザーは、中央のグローバル エントリ ポイントを介してアプリケーションにアクセスします。中央のグローバル エントリ ポイントは、要求を適切なリージョンのデプロイ スタンプにリダイレクトします。

ミッションクリティカルな設計手法には、複数リージョンのデプロイが必要です。 このモデルにより、リージョン全体がダウンした場合でもアプリケーションを使用できるように、リージョンのフォールト トレランスが保証されます。 マルチリージョン アプリケーションを設計する場合は、それぞれのアプローチで大きなトレードオフがあるため、アクティブ/アクティブ/アクティブ/パッシブなどのさまざまなデプロイ戦略とアプリケーション要件を考慮してください。 ミッションクリティカルなワークロードの場合は、アクティブ/アクティブ モデルを強くお勧めします。

すべてのワークロードが、複数のリージョンの同時実行をサポートまたは必要とするわけではありません。 最適な設計上の判断を決定するには、特定のアプリケーション要件とトレードオフを比較検討する必要があります。 信頼性ターゲットが低い特定のアプリケーション シナリオでは、アクティブ/パッシブまたはシャーディングが適切な代替手段となる場合があります。

可用性ゾーンは、リージョン内の異なるデータセンター間におて、高可用性のリージョン デプロイを提供できます。 ほぼすべての Azure サービスは、ゾーン構成またはゾーン冗長構成のいずれかで利用できます。ゾーン構成ではサービスが特定のゾーンに委任され、ゾーン冗長構成ではプラットフォームによってサービスがゾーン間で自動的に分散され、ゾーンの停止に耐えることができます。 これらの構成は、データセンター レベルまでのフォールト トレランスを提供します。

設計上の考慮事項

• リージョンとゾーンにおける機能。 すべての Azure リージョンですべてのサービスと機能を利用できるわけではありません。 この考慮事項は、選択したリージョンに影響する可能性があります。 また、可用性ゾーンはすべてのリージョンで使用できるわけではありません。

• リージョン ペア。 Azure リージョンは、1 つの地域の 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) アクセスのリスクは制限されます。

• 状態。 実行中のコンテナーのファイル システムにデータを格納することはできますが、コンテナーを再作成した場合にデータは保持されません。 代わりに、外部ストレージをマウントするか、外部データベースを使用してデータを保持します。

設計の推奨事項

• すべてのアプリケーション コンポーネントをコンテナー化します。 アプリケーション デプロイ パッケージのプライマリ モデルとしてコンテナー イメージを使用します。

• 可能であれば、Linux ベースのコンテナー ランタイムを優先します。 イメージはより軽量で、Linux ノード/コンテナーの新機能が頻繁にリリースされます。

• これは、短いライフサイクルでコンテナーを変更不可にし、置き換え可能にします。

• コンテナー、コンテナー ホスト、および基になるクラスターから、関連するすべてのログとメトリックを収集してください。 収集したログとメトリックを統合データ シンクに送信して、さらに処理と分析を行います。

• Azure Container Registry にコンテナー イメージを格納します。 geo レプリケーションを使用して、すべてのリージョンにコンテナー イメージをレプリケートします。 コンテナー レジストリ用 Microsoft Defender を有効にして、コンテナー イメージの脆弱性スキャンを備えます。 レジストリへのアクセスが Microsoft Entra ID によって管理されていることを確認します。

コンテナーのホスティングとオーケストレーション

複数の Azure アプリケーション プラットフォームで、コンテナーを効果的にホストできます。 これらの各プラットフォームには、長所と短所があります。 ビジネス要件と照らし合わせて、オプションを比較します。 ただし、信頼性、スケーラビリティ、パフォーマンスは常に最適化します。 詳細については、次の記事を参照してください。

• コンピューティング デシジョン ツリー
• コンテナー オプションの比較

Azure Kubernetes Service の設計に関する考慮事項と推奨事項

マネージド Kubernetes サービスである AKS は、複雑なクラスター管理作業を必要とせずに迅速なクラスター プロビジョニングを可能にし、高度なネットワーク機能と ID 機能を含む機能セットを提供します。 推奨事項の完全なセットについては、Azure Well-Architected Framework のレビュー - AKSについての記事を参照してください。

信頼性

AKS は、ネイティブの Kubernetes コントロール プレーンを管理します。 コントロール プレーンを使用できない場合、ワークロードでダウンタイムが発生します。 AKS が提供する次の信頼性機能を活用してください。

• 信頼性と可用性を最大化するために、異なる Azure リージョンをまたがる AKS クラスターをスケール ユニットとしてデプロイします。 AKS のコントロール プレーンとエージェント ノードを物理的に別々のデータセンターに分散させることにより、可用性ゾーンを使用してAzure リージョン内の回復力を最大限に高めます。 ただし、コロケーション待機時間に問題がある場合は、単一のゾーン内で AKS デプロイを行うか、近接配置グループを使用してノード間の待機時間を最小限に抑えることができます。

• Kubernetes API エンドポイントの可用性を最大化に保証するために、運用クラスターの AKS アップタイム SLA を使用します。

スケーラビリティ

ノード数、クラスターあたりのノード プール数、サブスクリプションあたりのクラスター数など、AKS のスケール上の制限を考慮します。

• スケール上の制限が制約となる場合は、スケール ユニット戦略を活用してクラスターでより多くのユニットをデプロイします。

• クラスター自動スケーラーを有効にし、リソースの制約に従ってエージェント ノード数を自動的に調整する。

• 水平ポッド自動スケーラーを使って、CPU 使用量やその他の選択されたメトリクスに基づくデプロイ内のポッド数を調整します。

• 大規模なシナリオやバースト シナリオでは、大規模で迅速なスケールのために、仮想ノードの使用を検討してください。

• アプリケーション デプロイ マニフェストで、ポッド リソース要求と制限を定義します。 そうしないと、パフォーマンスの問題が発生する可能性があります。

分離:

ワークロードとシステム ツールで使用される、インフラストラクチャ間の境界を維持します。 インフラストラクチャを共有すると、リソース使用率が高くなり、ノイズの多い近隣のシナリオが発生する可能性があります。

• システム サービスとワークロード サービスには、個別のノード プールを使用します。 ワークロード コンポーネント専用のノード プールは、高メモリ GPU VM などの特殊なインフラストラクチャ リソースの要件に基づいている必要があります。 一般的には、不要な管理オーバーヘッドを減らすために、多数のノード プールをデプロイしないようにします。

• テイントと容認を使用して専用ノードを提供し、リソースを大量に消費するアプリケーションを制限します。

• アプリケーション アフィニティとアンチアフィニティの要件を評価し、ノード上のコンテナーの適切なコロケーションを構成します。

セキュリティ

既定の vanilla Kubernetes では、ミッション クリティカルなシナリオに適したセキュリティ ポスチャを確保するために重大な構成が必要です。 AKS は、さまざまなセキュリティリスクにすぐに対応できます。 機能には、プライベート クラスター、Log Analytics への監査とログ記録、強化されたノード イメージ、マネージド ID が含まれます。

• AKS セキュリティ ベースラインに記載されている構成ガイダンスを適用します。

• AKS 機能を使用して、クラスター ID とアクセス管理を処理し、運用オーバーヘッドを削減し、一貫したアクセス管理を適用します。

• 資格情報の管理とローテーションを回避するには、サービス プリンシパルの代わりにマネージド ID を使用します。 クラスター レベルで、管理 ID を追加できます。 ポッド レベルでは、Microsoft Entra Workload ID を介してマネージド ID を使用できます。

• Microsoft Entra 統合 を使用して、アカウント管理とパスワードの一元化、アプリケーションのアクセス管理、および ID 保護の強化を実現します。 最小特権の Microsoft Entra ID で Kubernetes RBAC を使用し、管理者特権の付与を最小限に抑えることで、構成とシークレット アクセスを保護することができます。 また、Azure ロールベースのアクセス制御を使用して Kubernetes クラスター構成ファイルへのアクセスを制限します。 コンテナーが実行できるアクションへのアクセスを制限し、アクセス許可の最小数を指定し、ルート特権エスカレーションの使用を回避します。

アップグレード

クラスターとノードは定期的にアップグレードする必要があります。 AKS では、ネイティブ Kubernetes のリリース サイクルに合わせて、Kbernetes バージョンがサポートされます。

• GitHub で公開されている AKS ロードマップとリリース ノートを購読して、今後の変更、機能強化、そして最も重要な Kubernetes のバージョン リリースと廃止予定に関する最新情報を入手してください。

• ベスト プラクティスに確実に準拠するには、AKS チェックリストに記載されているガイダンスを適用します。

• ノードやクラスターを更新するために AKS でサポートされているさまざまな方法に注意してください。 これらの方法は、手動で、または自動で操作できます。 計画メンテナンスを使用して、これらの操作のメンテナンス期間を定義できます。 新しいイメージは毎週リリースされます。 AKS では、自動アップグレード チャネルもサポートされています。これは、AKS クラスターを新しいバージョンの Kubernetes や新しいノード イメージが使用可能になった際に自動的にアップグレードします。

ネットワーク

ユース ケースに最適なネットワーク プラグインを評価します。 ポッド間のトラフィックをきめ細かく制御する必要があるかどうかを判断します。 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 を使用して、ポッドに付与される機能とその実行が、ポリシーと矛盾するかどうかを制御します。 このアクセスは、AKS の Azure Policy アドオンによって提供される組み込みのポリシーを使用して定義されます。

• Azure Policy を使用して、AKS クラスターと pod 構成の一貫した信頼性とセキュリティ ベースラインを確立します。

• Azure Policy Add-on for AKS を使用して、ルート特権などのポッド機能を制御し、ポリシーに準拠していないポッドを禁止します。

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 プランから独立してスケーリングするために、App Serviceプランのレベルでアプリごとのスケーリングを有効にできることに注意してください。 アプリは、均等な分散のベスト エフォート アプローチを使用して、使用可能なノードに割り当てられます。 均等な分散は保証されませんが、プラットフォームでは、同じアプリの 2 つのインスタンスが同じインスタンスでホストされないことを保証します。

監視

アプリケーションの動作を監視し、関連するログとメトリックにアクセスして、アプリケーションが期待どおりに動作することを確認します。

• 診断ログを使用して、アプリケーション レベルおよびプラットフォーム レベルのログを、Azure Event Hubs を介して Log Analytics、Azure Storage、またはサードパーティ ツールに取り込むことができます。

• Application Insights で監視を行うことにより、アプリケーションのパフォーマンスを深く分析できます。

• ミッション クリティカルなアプリケーションには、障害が発生した場合に自動復旧する機能が必要です。 自動復旧を有効にして、異常なワーカーを自動的に再利用します。

• すべての重要なダウンストリーム依存関係を評価するには、適切な正常性チェックを使用する必要があります。これは、全体的な正常性を確保するのに役立ちます。 正常性チェックを有効にして、応答しないワーカーを特定することを強くお勧めします。

展開

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 Container Registry レベルがゾーン冗長をサポートし、ゾーン障害に対する保護を提供します。 Premium レベルでは、プライベート エンドポイントもサポートされています。これは、信頼性の問題を引き起こす可能性があるレジストリへの不正アクセスを防ぐのに役立ちます。

同じ Azure リージョン内で、使用しているコンピューティング リソースの近くでイメージをホストします。

イメージのロック

イメージは、たとえば手動エラーの結果として削除される可能性があります。 Container Registry では、変更や削除を防ぐためにイメージ バージョンまたはリポジトリのロックがサポートされています。 以前にデプロイされたイメージ バージョンが変更されると、同じバージョンのデプロイによって、変更の前後で異なる結果を生じることがあります。

削除から Container Registry インスタンスを保護する場合は、リソース ロックを使用します。

タグ付けされたイメージ

タグ付けされた 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 を自動的に分散することで、ネットワーク、ディスク、および電源障害から保護するのに役立ちます。

設計の推奨事項

• 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 ワークロードのセキュリティに関するベスト プラクティスを実装します。

次のステップ

データ プラットフォームの考慮事項を確認します。