このソリューションでは、ハイブリッド インフラストラクチャにデプロイされたワークロードのクラスター間スケーリングを実現する方法を示します。 このソリューションは、Azure Arc 対応サービスのスケーラビリティと管理機能を Azure Stack HCI クラスターに適用することで実現されます。
アーキテクチャ
このアーキテクチャは、Azure Stack HCI 上の Azure Arc 対応サービス、Azure Pipelines、およびグローバル ロード バランサーと Azure Function アプリの統合を使用して行われるハイブリッド ソリューションのデプロイを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このアーキテクチャは、次のステップで構成されています。
2 つの Azure Stack HCI クラスターが 2 つの異なる場所にセットアップされます。Azure Stack HCI (HCI1) はプライマリ オンプレミス インフラストラクチャとして機能し、Azure Stack HCI (HCI2) はセカンダリ オンプレミス インフラストラクチャとして機能して、それぞれワークロードを実行します。
Azure Stack HCI クラスターは、SD-WAN 経由で Azure に接続し、Azure Arc と Windows Admin Center を介して管理されます。 その結果、Azure の機能をオンプレミス インフラストラクチャに拡張し、Azure 管理ツールとサービスを使用して、オンプレミスのインフラストラクチャとワークロードを管理および監視することができます。
Azure Stack HCI にデプロイされた Azure Kubernetes Service (AKS) は、管理クラスター (AKS ホスト) と、コンテナー化されたアプリケーションがデプロイされるワークロード クラスター (ターゲット クラスターとも呼ばれます) で構成されます。 AKS on Azure Stack HCI の Azure Kubernetes Service (AKS) ベースライン アーキテクチャを参照してください。
Azure Stack HCI 上の Azure Kubernetes Service ホストとワークロード クラスターは、AksHci PowerShell モジュールを使用してデプロイされます。 PowerShell を使用して Azure Stack HCI および Windows Server クラスターに Kubernetes をセットアップするを参照してください。
ネットワーク リソースの仮想化は、Azure Stack HCI クラスターの SDN 機能を適用することによって実装されます。 これにより、 ソフトウェア ロード バランサー Mux VM、RAS ゲートウェイ VM、ネットワーク コントローラーなどの必要な SDN ネットワーク インフラストラクチャ リソースをデプロイしてネットワークの可用性を高めます。 Azure Stack HCI および Windows Server でのソフトウェア定義ネットワーキング (SDN) を参照してください。
AKS インフラストラクチャとワークロード VM は、SDN ソフトウェア ロード バランサー (SLB) を介して実現されるハイブリッド負荷分散を使用して SDN 仮想ネットワークにデプロイされます。 AKS on Azure Stack HCI を使用して Microsoft ソフトウェア定義ネットワーキング (SDN) をデプロイするを参照してください。
Azure Pipelines は、両方の Azure Stack HCI オンプレミス環境にデプロイされているコンテナー化されたアプリケーションの同じバージョンを使用してフロントエンド アプリケーションをデプロイします。
データベースは、AKS ハイブリッドにデプロイされた Arc 対応 SQL マネージド インスタンスでホストされます。
開発者は、Kubernetes マニフェストと AksHci PowerShell モジュールを使用して、両方の AKS ハイブリッド クラスターにデプロイされるコンテナーとしてアプリケーションをパッケージ化し、Azure Pipelines を通じてデプロイメント タスクを自動化します。
アプリケーションへのクライアント要求は、Azure Front Door や Azure Traffic Manager などのグローバル ロード バランサー サービスによって転送されます。ロード バランサー サービスは重み付けトラフィック ルーティング方法を使用して適切なサービス エンドポイントに要求をルーティングします。 割り当てられた重み付けパーセンテージに基づいて、Stack HCI 上の 2 つの AKS ハイブリッド クラスター全体にデプロイされたサービスにトラフィックが分散されます。
複数のリージョンにまたがってクラスターが存在するため、Traffic Manager と Azure Front Door は、どちらもグローバルな負荷分散機能に対処するための実行可能なオプションです。 Azure Front Door と Traffic Manager のどちらを選択するかはさまざまな要因に依存するため、どちらを推奨するかの決定にあたっては慎重な検討が必要です。 さまざまな負荷分散サービスを検討する必要がある理由を次に示します。
- インターネットに接続するアプリケーションで HTTPS を使用する場合は、Azure Front Door が望ましいオプションです。 一般に、このような場合、Traffic Manager は主な選択肢ではありません。 例外はあるかもしれませんが、個別のシナリオはこの説明の範囲外です。
- 主な目標が効率的なグローバル負荷分散であれば、Traffic Manager で十分でしょう。 コンテンツ配信の最適化、アプリケーション層のセキュリティ、高度なルーティング機能も必要な場合は、Azure Front Door の方が適しているかもしれません。
- Traffic Manager はセットアップが簡単で、主に負荷分散に重点を置いています。 Azure Front Door はより多くの機能を備えていますが、学習曲線が Traffic Manager より急になる可能性があります。
- アプリケーションの種類を検討しましょう。 Web 中心の傾向が強く、キャッシュや SSL 終了などの最適化が必要な場合は、Azure Front Door が役に立つ可能性があります。
- DNS ベースのルーティングでは、アプリケーション レベルで負荷分散を処理するときの複雑さが軽減されます。 ただし、DNS ベースのルーティングのみに依存すると、障害発生時のダウンタイムが増加し、アプリケーションのサービス レベル アグリーメント (SLA) に悪影響が及ぶ可能性がある点に注意することが非常に重要です。 Azure Front Door と Traffic Manager のどちらを選ぶかの決定にあたっては、DNS ソリューションの SLA と、2 つのオプション間の異なるフェールオーバー時間にアプリケーションが対応できるかどうかを考慮する必要があります。
デプロイされたワークロード アプリケーションの負荷は、Azure Arc 対応サービス、Azure Monitor、Log Analytic Workspace を使用して監視されます。
通常の負荷条件では、クライアント要求は、Azure Stack HCI-1 環境 (プライマリ クラスター環境) でオンプレミスでホストされているアプリのインスタンスにルーティングされます。
Arc 対応の AKS クラスター ワークロードは、組み込みの自動スケーラーを使用して複数のインスタンスに水平にスケーリングするように設計されています。自動スケーラーは、デプロイされた AKS クラスター内のノード数をオンデマンドで自動的にスケールアップまたはスケールダウンします。
Container 分析情報を有効にして、Azure Stack HPI でホストされている Kubernetes クラスターで診断をキャプチャし、ワークロードのパフォーマンスを監視します。
トラフィックが増加し、ポッド スケーリングのオプションがそれ以上ない状態で Azure Stack HCI-1 上のワークロード クラスターが最大ノード数に達すると、Azure Function アプリをトリガーするアラートが生成されます。
アラート ルールはカスタム Kusto クエリの結果を監視するように構成されており、KubeNodeInventory Azure Monitor テーブルと KubePodInventory Azure Monitor テーブルから最大ノード数とポッドの準備状況のパーセンテージを取得し、チェックします。 Container 分析情報からログ アラートを作成するを参照してください。
Kubernetes Container 分析情報からの事前に構成されたアラート ルールを使用して Kubernetes モニタリングを実行することもできます。 Container 分析情報からの KubePodNotReady メトリック ルールまたは KubeHpaMaxedOut メトリック ルールを適用してアラート ルールの条件を構成することもできます。 Container 分析情報のメトリック アラート ルール (プレビュー) を参照して、アラートのアクション グループを通じて Azure Function アプリを呼び出します。
Azure Function アプリは、プライマリ クラスターの状態に基づいて重み付けトラフィック ルーティング規則を動的に管理し、Azure Stack HCI-2 クラスターにトラフィックをリダイレクトします。
- Azure Function を使用して、クラスターの準備状況とトラフィックの状況の事前定義されたしきい値制限に基づいて、リダイレクトする必要があるトラフィックの割合を計算することができます。 そうすることで、変化に迅速に適応し、タスクを自動化し、リソースを効率的にスケーリングし、コストを節約することができます。
- Azure Function は、トラフィック ルーティング ルールの動的な管理に役立ちます。 この機能により、高可用性、スケーラビリティ、パフォーマンスが確保され、ピーク トラフィックやフェールオーバーのシナリオでもシームレスなユーザー エクスペリエンスを提供できます。 たとえば、プライマリ クラスターが良好なパフォーマンスを示しており、負荷を処理できるときにトラフィックの 100% をプライマリ クラスターに振り向けることから最初のトラフィック分散が始まります。 プライマリ クラスターの容量が満杯に近づいた場合やプライマリ クラスターのパフォーマンスが低下した場合は、Azure Function 内のトラフィック ルーティング規則を調整することができます。 そうすることで、読み取り専用トラフィックの一部がセカンダリ クラスターにリダイレクトされます。
両方のクラスター環境で実行されているアプリ インスタンスは、Arc 対応 SQL マネージド インスタンスなどのデータ サービスにそれぞれのクラスター内でローカルに接続します。
Arc SQL マネージド インスタンスのクラスター間のデータ同期は、Azure フェールオーバー グループによって管理され、Azure フェールオーバー グループは分散可用性グループを使用します。 クラスター間の同期は、同期または非同期にすることができます。 Azure Arc 対応 SQL マネージド インスタンスを参照してください。
全体として、このワークフローには、アプリケーションの構築とデプロイ、負荷分散、トラフィック管理、自動スケーリング、複数のクラスター環境間のデータ同期が含まれます。 このセットアップにより、2 つの異なるデータ センターまたは場所にあるクラスター間でインフラストラクチャを水平にスケーリングして、セキュリティ、冗長性、柔軟性、効率的なリソース利用を提供することができます。
コンポーネント
Azure Front Door はレイヤー 7 のロード バランサーです。 このアーキテクチャでは、Stack HCI クラスターにデプロイされた Web アプリケーションに HTTP 要求がルーティングされます。 また、一般的な悪用や脆弱性からアプリケーションを保護する Azure Front Door と共に Web アプリケーション ファイアウォール (WAF) を使用することもできます。また、この設計のコンテンツ配信ネットワーク (CDN) ソリューションを使用して、エッジ ロケーションでコンテンツをキャッシュすることで待機時間を短縮し、コンテンツの読み込み時間を改善することもできます。
Traffic Manager は、DNS ベースのトラフィック ロード バランサーであり、実行可能な負荷分散オプションです。 Traffic Manager を使用して、さまざまなデータ センター内のサービス エンドポイントへのアプリケーション トラフィックの分散を制御します。 Traffic Manager の構成がどのように機能するかを次に示します。
- Azure のグローバル負荷分散ソリューションである Traffic Manager をセットアップして、受信トラフィックを Azure Stack HCI クラスター全体に分散します。 Traffic Manager は、パフォーマンス、フェールオーバー、加重ラウンドロビンなど、要件に応じて、さまざまな負荷分散方法を使用するように構成できます。
- Azure Stack HCI クラスターにデプロイされたワークロードのエンドポイントに対応する Traffic Manager エンドポイントを作成します。 そうすることで、Traffic Manager はトラフィックを適切なエンドポイントに転送できます。 このシナリオでは、重み付けルーティングによる負荷分散方法に基づいてトラフィックを転送します。
- Traffic Manager は、Azure 関数を使用して計算されたスケーリング ポリシーに基づいて、追加の容量または高可用性が必要になったときに、ルーティング規則と重み付けパーセンテージに基づいてトラフィックを他のインスタンスに動的にルーティングすることができます。
Application Insights は、このハイブリッド ソリューションにデプロイされたさまざまなコンポーネントからテレメトリ データを収集します。 Application Insightsは、問題の特定、パフォーマンスの最適化、ユーザー エクスペリエンスの向上に使用できるインサイトと分析を提供します。
Azure Functions は、トラフィック分散のオーケストレーターとして機能します。 各クラスターの準備状況を監視し、リソース使用率、待機時間、正常性などの要因を評価します。 この評価に基づいて、Function アプリは受信トラフィックをどこに転送するかを決定します。
Azure Stack HCI は、仮想化された Windows および Linux のワークロードとそのストレージを、オンプレミス インフラストラクチャを Azure サービスと組み合わせたハイブリッド環境でホストするハイパーコンバージド インフラストラクチャ (HCI) クラスター ソリューションです。
- このソリューションでは、Azure Stack HCI (AKS-HCI) 上の Arc 対応 Azure Kubernetes Service を使用して、両方の環境で Web アプリまたは API、Arc 対応 Azure サーバー、およびArc 対応 Data Servicesをホストします。
Azure DevOps Services は、このハイブリッド ソリューション デプロイ戦略のバックボーンとして機能し、ソフトウェア配信ライフサイクル全体の合理化に必要な自動化とオーケストレーションを提供します。 これにより、開発チームは、パイプラインがアプリケーションの構築、テスト、デプロイに対処している間、高品質のコードの提供に集中できるようになります。
Azure Stack HCI に AKS クラスターをデプロイするには、Azure Pipelines 内にビルド サーバーをセットアップします。 ビルド サーバーは、デプロイ プロセスの実行を担います。
a. Azure 内で仮想マシン (VM) を作成するか、Stack HCI 環境から VM を作成します。 あるいは、ハイブリッド インフラストラクチャへのネットワーク接続がある場合は、既存のオンプレミス VM をビルド サーバーとして使用します。
b. Git、Azure CLI、Azure PowerShell モジュールなど、必要なツールをビルド サーバーにインストールします。
c. サービス プリンシパルを設定するか、マネージド ID を使用して、Azure への認証を構成します。
Azure Pipelines は、CI/CD を提供するサービスです。 これを使用して、ホスト ビルド エージェントとリリース エージェントおよび定義を管理できます。 GitHub、Bitbucket、Dropbox、OneDrive、Azure Repos など、さまざまなコード リポジトリを開発パイプラインで使用できます。
Azure Monitor は、テレメトリ データを収集し、クラスターとワークロードのパフォーマンスを監視します。 また、クラスターが異常になった場合や事前定義されたしきい値を超えた場合に、Azure Function をトリガーしたり、管理者に通知したりするアラートを構成することもできます。 Azure Automation または Azure Logic Apps を使用して、監視データに基づいてスケーリング アクションを自動化できます。
Azure Policy はガバナンスとコンプライアンスのエンフォーサーとして機能し、Stack HCI クラスターおよび関連する SDN リソースが定義済みのガイドラインと標準の範囲内で動作することを保証します。 Azure Policy を使用して環境のセキュリティを強化する例をいくつか次に示します。
- Container Insight アドオンを適用する
- Stack HCI クラスター内に必須の拡張機能をインストールする
- リソースのタグ付けを適用する
- ポリシー ベースのアクセス制御
- ネットワークと監視に関連するポリシー
Azure Container Registry は、Azure 上の管理されたプライベートな Docker レジストリ サービスです。 Container Registry を使用して、クラスターにデプロイされているプライベート Docker イメージを格納します。
Azure Arc は、Azure サービスをオンプレミス環境に拡張することで、組織が機密データを自社のインフラストラクチャ内に保持しながらクラウド機能のメリットを享受できるようにします。
Container Insights は、Azure Monitor によって提供される監視と可観測性のソリューションです。これを使用して、AKS クラスターで実行されているコンテナーのパフォーマンスと正常性についてのインサイトを得ることができます。 AKS で Azure Arc を有効にすると、Container Insights の機能を拡張して、オンプレミス環境やマルチクラウド環境など、Azure の外部で実行されている AKS クラスターを監視および管理できます。
Azure Arc 対応 SQL Managed Instance は、Stack HCI インフラストラクチャ上に作成して、Azure Arc を使用して管理できる Azure SQL データ サービスです。
Azure Key Vault を使用すると、暗号化キー、シークレット、証明書を安全に格納および管理できます。 Azure Key Vault は主にクラウド サービスですが、Azure Stack HCI デプロイと共に使用して、機密情報をオンプレミスに安全に格納および管理することもできます。
SDN インフラストラクチャ。 Azure Stack HCI 上の AKS ハイブリッド デプロイでは、負荷分散はソフトウェア ロード バランサー (SLB) SDN によって実現されます。 SLB は、Mux ロード バランサー VM、ゲートウェイ VM、ネットワーク コントローラーなどの必要な SDN ネットワーク インフラストラクチャ リソースを含む、SDN (ソフトウェア定義ネットワーク) 仮想ネットワーク内の AKS-HCI インフラストラクチャとアプリケーションを管理します。
関連するコンポーネントの内訳は次のとおりです。
- ソフトウェア ロード バランサー (SLB): SLB は、ネットワーク トラフィックをクラスターで実行されているアプリケーションに分散するための負荷分散機能を提供する AKS-HCI インフラストラクチャの主要なコンポーネントです。 SLB はトランスポート層 (レイヤー 4) で動作し、構成されたルールに基づいてトラフィックを転送します。
- Mux ロード バランサー VM: Mux ロード バランサー VM は、外部ソースからの受信ネットワーク トラフィックを処理し、それを AKS-HCI クラスター内の適切なバックエンド ポッドまたはサービスに分散する仮想マシンです。 Mux ロード バランサー VM は SLB と連携して負荷分散を実行します。
- ゲートウェイ VM: ゲートウェイ VM は、AKS-HCI クラスターと外部ネットワーク間の接続を提供します。 ゲートウェイ VM は、内部 SDN 仮想ネットワークと外部ネットワークの間のブリッジとして機能し、イングレス トラフィックとエグレス トラフィックが安全に流れるようにします。
- ネットワーク コントローラー: ネットワーク コントローラーは、AKS-HCI クラスター内の SDN インフラストラクチャを管理する役割を担います。 ネットワーク コントローラーは、ネットワーク ポリシーの適用、ネットワークの構成、ロード バランサーの構成などのタスクを処理します。
SLB、Mux ロード バランサー VM、ゲートウェイ VM、ネットワーク コントローラーを使用することで、AKS-HCI はハイブリッド デプロイの負荷分散を実現します。 これにより、受信ネットワーク トラフィックがクラスター内で実行されているアプリケーション全体に効率的に分散され、高可用性とスケーラビリティが実現します。
Note
これらのコンポーネントは AKS-HCI によって管理および構成されるため、管理者はプラットフォームの組み込みの負荷分散機能を使用しながら、アプリケーションのデプロイと管理に集中することができます。
代替
Web アプリケーションとイベント ベースのサービスについては、Azure Stack HCI でホストされている Azure Arc 対応 Kubernetes クラスターで App Service、Functions、Logic Apps を実行することができます。 データベースについては、Azure Arc 対応 PostgreSQL サーバーなどの別のストレージ オプションを使用できます。
Web アプリケーションの場合は、Azure Front Door を使用できます。 Azure Front Door は、レイヤー 7 (HTTP/HTTPS レイヤー) で動作します。 スプリット TCP を利用したエニーキャスト プロトコルと Microsoft のグローバル ネットワークを使用して、グローバル接続を向上させます。 使用するルーティング方法によって、Azure Front Door が最も高速かつ可用性の高いアプリケーション バックエンドにクライアント要求を確実にルーティングするようにできます。
Azure ExpressRoute を使用すれば、専用のプライベート ネットワーク接続を使用することで、ローカル ネットワークを Azure のリソースに直接接続できます。
リポジトリが GitHub にある場合は、Azure Pipelines の代わりに GitHub Actions を使用できます。
シナリオの詳細
主な目的は、2 つの異なるデータ センターまたは場所に存在するクラスター間でワークロードを効果的に分散することにより、クラスター間のスケーリングを促進することです。 このアプローチにより、単一クラスターのオーバーロードを防止し、すべてのクラスターでリソース使用率を最適化します。 Azure Function App は、クラスターの準備状況に基づいてトラフィックをインテリジェントに分散するうえで非常に重要な役割を果たし、それによって効率、スケーラビリティ、可用性、パフォーマンスを向上させます。
このシナリオは、厳密な制約、データ主権規制、または重要な回復性とビジネス継続性のニーズに対処する組織、あるいは銀行、金融、防衛、政府などの厳しく制限され、規制された環境できわめて重要なワークロードを処理する組織に適用できます。 組織の規制およびコンプライアンス ポリシーにより、パブリック クラウドで機密データが公開されないように、アプリケーションとデータベースはオンプレミスで実行されます。 このソリューションは次の場合に役立ちます。
オンプレミス アプリはピーク シーズン中に使用量が急増し、クラスター内で自動スケールが行われますが、プライマリ クラスターの容量が 100% に達するため、サービスの実行を中断することなく、オーバーフローしたトラフィックを他のデータセンター クラスターに転送したいという要望があります。
アプリや API のトラフィックを最も近い利用可能なオンプレミス環境に自動的に再ルーティングすることで問題を解決する必要があります。
オンプレミスのセットアップのガバナンスと管理を簡素化し、Azure Stack HCI にデプロイされた Azure Arc 対応サービスを通じて、ファイアウォールやプロキシ サーバーでフィルタリングされた関連するクラウド サービスに一貫した安全な方法でアクセスする必要があります。
考えられるユース ケース
- 可用性が高く、スケーラブルで、セキュアな制限されたワークロードをオンプレミスの Azure Stack HCI クラスター環境に実装する必要があります。
- オンプレミス アプリの使用量が急増するたびに、データセンター間で実行されているアプリケーションを動的にスケーリングする必要があります。
- 一元的な管理、ガバナンス、監視を通じてクラウドベースの自動化を適用する必要があります。
- オンプレミスのコンポーネントがあるため、別のオンプレミスのセットアップを使用してそれらをスケーリングする必要があります。
- ワークロードのスケーリングをクラウド インスタンスに拡張できるようになるまでは、アプリをオンプレミスで実行するためのクラスター間の動的なスケーラビリティが必要です。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
企業は、規制やパフォーマンス上の理由から、アプリとリソースをオンプレミスに保持するハイブリッド アプローチを採用してシステムを維持することがあります。 Azure クラウド機能を適用する場合は、Azure HCI クラスターでホストされている同じバージョンのアプリケーションを複数のリージョンにデプロイできます。 そうすることで、高可用性とスケーラブルなサービスのコンプライアンスを実現できます。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
AKS-HCI をデプロイするときは、アプリケーションとインフラストラクチャの保護に役立つセキュリティ プラクティスを検討することが不可欠です。 AKS-HCI のセキュリティに関する重要な考慮事項をいくつか次に示します。
クラスター アクセスのセキュリティ保護
- 最小特権の原則に従って、AKS-HCI クラスターへのアクセスを制限します。 ユーザー、グループ、またはサービス アカウントには必要なアクセス許可のみを付与します。
- Microsoft Entra 統合、Microsoft Entra ポッド ID、Kubernetes ロールベースのアクセス制御 (Kubernetes RBAC) などの強力な認証メカニズムを使用して、クラスターとそのリソースへのアクセスを制御します。
- セキュリティを強化するために、クラスター アクセスに対する多要素認証 (MFA) を実装することを検討します。
ネットワークのセキュリティ
- Kubernetes ネットワーク ポリシーまたは Azure ネットワーク セキュリティ グループを使用して、AKS-HCI クラスター内にネットワークのセグメント化と分離を実装します。
- Azure Firewall などのネットワーク レベルのファイアウォールで受信トラフィックと送信トラフィックを制御し、IP 許可リストまたは仮想ネットワーク ピアリングに基づいてアクセスを制限します。
- トランスポート層セキュリティ (TLS) 認証または相互 TLS (mTLS) 認証を使用して、サービス間のネットワーク トラフィックを暗号化します。
コンテナー イメージのセキュリティ
- 信頼できるソースからのセキュリティで保護されたコンテナー イメージを使用して、最新のセキュリティ パッチと脆弱性修正プログラムでそれらを定期的に更新します。
- イメージ スキャンと脆弱性評価ツールを実装して、コンテナー イメージ内のセキュリティの問題を特定および修復します。
- コンテナー イメージの署名と検証メカニズムを使用して、イメージの整合性と信頼性を確保します。
シークレットの管理
- アプリケーション コードまたは構成ファイルに機密情報 (パスワード、API キー、接続文字列など) をハードコーディングしないようにします。
- Azure Key Vault またはセキュアなシークレット管理ソリューションを使用して、機密情報を安全に保存および取得します。
- Kubernetes シークレットまたは Azure Key Vault 統合を使用して、アプリケーション コンテナーにシークレットを安全に挿入します。
ログ記録と監視
- Azure Monitor またはサード パーティのソリューションを使用して、AKS-HCI クラスターの一元的なログ記録と監視を実装します。
- 重要なセキュリティ イベントをキャプチャするように監査ログ、コンテナー ログ、システム ログを構成します。
- アラートと通知メカニズムを設定して、セキュリティ インシデントや異常をプロアクティブに検出して対応します。
定期的なアップデートとパッチ
- 最新のセキュリティ パッチと更新プログラムを使用して、AKS-HCI クラスター ノードおよび基盤となるインフラストラクチャを最新の状態に保ちます。
- パッチ管理プロセスを確立して、セキュリティ修正プログラムをタイムリーに適用します。
コンプライアンスと規制に関する考慮事項
- 組織の要件に基づいて、関連する業界固有のセキュリティとコンプライアンス規制 (HIPAA や PCI DSS など) を理解し、遵守します。
- 業界に適用されるコンプライアンス基準を満たすために、セキュリティ コントロールとセキュリティ プラクティスを実装します。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
Arc 対応サービスを Azure Stack HCI にデプロイする際の最適化に関する考慮事項:
- 実際のワークロード要件に基づいて AKS-HCI クラスター ノードのサイズを正しく設定することで、オーバープロビジョニングや過小使用を回避します。
- AKS-HCI での自動スケーリングは、リソースの割り当てを最適化し、需要が低い期間中にコストを削減するのに役立ちます。 需要パターンとワークロード パターンに基づいてポッドの水平自動スケーリング (HPA) を構成して、AKS-HCI クラスター内のポッドの数を自動的にスケーリングします。
- ストレージの最適化:
- ワークロードの要件とパフォーマンスのニーズに基づいて、適切なストレージ オプションを選択します。
- 永続ボリュームには Azure Disk Storage を使用し、共有ファイル ストレージには Azure Files を使用することを検討します。
- ワークロードの需要に基づいてディスクのサイズと種類を調整するなどして、ストレージ構成を最適化します。
- タグ付けとリソース グループ管理:
- 一貫したリソース タグ付けを実装して、リソースを追跡および分類します。
- リソース グループを使用してリソースを論理的に整理し、コストの管理と追跡を容易にします。
- 継続的なコスト監視と最適化:
- Microsoft Cost Management が提供するコスト レポートとダッシュボードを定期的に確認して、コスト削減の機会を特定し、支出を最適化します。
- Azure Advisor などのツールを使用して、リソース使用率の最適化、セキュリティの向上、コスト削減に関する推奨事項を受け取ります。
- Azure DevOps Services を使用してデプロイとメンテナンスの負担を軽減します。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
クラスター間スケーリングの主な利点は、オンプレミス環境でオンデマンド スケーリングを提供して、セキュリティで保護された組織のネットワーク内のセットアップを完全に制御できることです。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
Mayuri Bhavsar | シニア クラウド ソリューション アーキテクト
Vidya Narasimhan | プリンシパル クラウド ソリューション アーキテクト
その他の共同作成者:
Himanshu Amodwala | シニア クラウド ソリューション アーキテクト
Nakul Joshi | プリンシパル ソフトウェア エンジニアリング マネージャー
Vineeth Marar | シニア クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- 高可用性 Kubernetes クラスターを Azure Stack Hub でデプロイする
- Azure と Azure Stack Hub を使用した高可用性 Kubernetes パターン
- Azure Kubernetes Service (AKS) のドキュメント