Azure Kubernetes Service (AKS) と MySQL フレキシブル サーバーのワークロードを可用性ゾーンをサポートするよう移行する
このガイドでは、Azure Kubernetes Service と MySQL フレキシブル サーバーのワークロードを移行して、依存するすべてのサービス間で可用性ゾーンを完全にサポートする方法について説明します。 すべてのワークロードの依存関係の完全なリストについては、「ワークロード サービスの依存関係」を参照してください。
このワークロードの可用性ゾーンのサポートは、AKS クラスターまたは MySQL フレキシブル サーバーの作成時に有効にする必要があります。 既存の AKS クラスターと MySQL フレキシブル サーバーで可用性ゾーンをサポートしたい場合は、それらのリソースを再デプロイする必要があります。
この移行ガイダンスは、主に以下のアーキテクチャを Azure 上で実行する際のインフラストラクチャと可用性に関する考慮事項に焦点を当てています。
ワークロード サービスの依存関係
可用性ゾーンで完全なワークロード サポートを提供するには、ワークロード内の各サービス依存関係が可用性ゾーンをサポートしている必要があります。
可用性ゾーンをサポートするサービスには、ゾーンとゾーン冗長という 2 つのアプローチがあります。 ほとんどのサービスは、どちらか一方をサポートしています。 しかし、場合によっては、そのサービスに対して、ゾーンまたはゾーン冗長のリソースを選択するオプションが用意されています。 以下の推奨事項に、どのサービスがゾーンおよびゾーン冗長リソースをサポートしているかを示します。 また、どのサービスがグローバルであり、どのサービスがリージョナルであるかを示します。
AKS と MySQL のワークロード アーキテクチャは、次のコンポーネントの依存関係で構成されます。
Azure Kubernetes Service (AKS)
"ゾーン" : システム ノード プールおよびユーザー ノード プールは、作成時にノードプールをデプロイするゾーンを事前に選択すると、ゾーンになります。 回復性を高めるために、3 つのゾーンすべてを事前に選択することをお勧めします。 可用性ゾーンをサポートするユーザー ノード プールは、
zonesパラメーターに値を指定することで、既存の AKS クラスターにさらに追加することができます。ゾーン冗長: etcd、"API サーバー"、Scheduler、Controller Manager などの Kubernetes コントロール プレーン コンポーネントは、自動的にゾーン間でレプリケートまたは分散されます。
Note
AKS クラスター コントロール プレーン コンポーネントのゾーン冗長性を有効にするには、AKS クラスターを作成するときに、ゾーンを含む既定のシステム ノード プールを定義する必要があります。 既存のゾーン以外の AKS クラスターにゾーン ノード プールを追加しても、AKS クラスターのゾーン冗長化は行われません。これは、そのアクションでは、コントロール プレーン コンポーネントが事後的にゾーンに分散されないためです。
Azure Database for MySQL フレキシブル サーバー
ゾーン: ゾーン可用性モードは、スタンバイ サーバーがプライマリ サーバーと同じゾーン内で常に使用可能であることを意味します。 このオプションを使用すると、フェールオーバー時間とネットワーク待機時間が短縮されますが、1 つのゾーンが停止するとプライマリ サーバーとスタンバイ サーバーの両方に影響が及ぶため、回復性が低くなります。
ゾーン冗長: ゾーン冗長可用性モードは、スタンバイ サーバーがプライマリ サーバーと同じリージョン内にある別のゾーン内で常に使用可能であることを意味します。 プライマリ サーバーとスタンバイ サーバーのゾーン冗長化のために、2 つのゾーンが有効化されます。 回復性を高めるために、こちらの構成をお勧めします。
Azure Standard Load Balancer または Azure Application Gateway
Standard Load Balancer
Standard Load Balancer リソースに関連する考慮事項については、「ロード バランサーと可用性ゾーン」を参照してください。
ゾーン冗長: 既存の Load Balancer でフロントエンド IP を構成するには、ゾーン冗長を選択することをお勧めします。 ゾーン冗長フロントエンドは、複数のゾーンに分散される AKS クラスター バックエンド プールに対応します。
ゾーン: ノード プールをゾーン 1 や 2 などの特定のゾーンにピン留めしている場合は、既存の Load Balancer でフロントエンド IP のゾーン 1 と 2 を事前に選択できます。 ノード プールを特定のゾーンにピン留めする理由は、M シリーズなどの特殊な VM SKU シリーズを利用できるためなどが考えられます。
Azure Application Gateway
AKS クラスターでの Application Gateway イングレス コントローラー アドオンの使用は、Application Gateway v2 SKU (Standard および WAF) でのみサポートされています。 Azure Application Gateway に関連するその他の考慮事項については、「Application Gateway v2 と WAF v2 のスケーリング」を参照してください。
ゾーン: 可用性ゾーンの利点を使用するには、Application Gateway リソースを複数のゾーン (ゾーン 1、2、3 など) に作成することをお勧めします。 リージョン内の回復性を高める戦略を取るには、3 つのゾーンをすべて選択します。 ただし、バックエンド ノード プールに対応するために、App Gateway リソースの作成時にゾーン 1 と 2 を事前に選択することで、ノード プールを特定のゾーンにピン留めできます。 ノード プールを特定のゾーンにピン留めする理由は、M-series などの特殊な VM SKU シリーズを利用できるためなどが考えられます。
ゾーン冗長ストレージ (ZRS)
AKS クラスターはゾーン冗長リソースであるため、マネージド ZRS ディスクで構成することをお勧めします。 ボリュームは、すべてのゾーンでスケジュールできます。
Kubernetes では、バージョン 1.12 以降で、Azure 可用性ゾーンが認識されています。 ユーザーは、複数ゾーンの AKS クラスターで Azure マネージド ディスクを参照して
PersistentVolumeClaimオブジェクトをデプロイすることができます。 適切な可用性ゾーン内にこの PVC を要求するあらゆるポッドのスケジュール設定は、Kubernetes によって管理されます。Azure Database for SQL の場合は、データ ファイルとログ ファイルをゾーン冗長ストレージ (ZRS) でホストすることをお勧めします。 これらのファイルは、ZRS で利用可能なストレージ レベルのレプリケーションを介して、スタンバイ サーバーにレプリケートされます。
Azure Firewall
ゾーン: 可用性ゾーンの利点を使用するには、Azure Firewall リソースを複数のゾーン (ゾーン 1、2、3 など) に作成することをお勧めします。 リージョン内の回復性を高める戦略を取るために、3 つのゾーンをすべて選択することをお勧めします。
Azure Bastion
リージョン: Azure Bastion は、VNet またはピアリングされた VNet 内にデプロイされて、Azure リージョンに関連付けられます。 詳細については、「Azure Bastion の信頼性」を参照してください。
Azure Container Registry (ACR)
ゾーン冗長: Premium サービス レベルにゾーン冗長レジストリを作成することをお勧めします。 また、レプリカの zoneRedundancy プロパティを設定することで、ゾーン冗長レジストリ レプリカを作成することもできます。 ACR のゾーン冗長を有効にする方法については、「回復性と高可用性のために Azure Container Registry でゾーン冗長を有効にする」を参照してください。
Azure Cache for Redis
ゾーン冗長: Azure Cache for Redis によって、Premium レベルと Enterprise レベルでのゾーン冗長構成がサポートされます。 ゾーン冗長キャッシュを使用すると、同じリージョン内の異なる可用性ゾーンにわたってノードを配置できます。
Microsoft Entra ID
グローバル: Microsoft Entra ID は、複数レベルの内部冗長性と自動回復性を備えたグローバル サービスです。 Microsoft Entra ID は、世界中の 30 以上のデータセンターにデプロイされ、利用可能な場合は可用性ゾーンを提供しています。 この数は、より多くのリージョンがデプロイされるにつれて急速に増加しています。
Azure Key Vault
リージョン: Azure Key Vault はリージョンにデプロイされます。 キーとシークレットの高い持続性を維持するために、キー コンテナーの内容は、リージョン内と、同じ地域内のセカンダリ リージョンにレプリケートされます。
ゾーン冗長: 可用性ゾーンはあるが、リージョン ペアを持たない Azure リージョンの場合、Key Vault はゾーン冗長ストレージ (ZRS) を使用して、単一の場所またはリージョン内で 3 回、キー コンテナーの内容を複製します。
ワークロードに関する考慮事項
Azure Kubernetes Service (AKS)
ポッドは、ノード上にポッドが配置されているノードや可用性ゾーンに関係なく、他のポッドと通信できます。 ポッドが異なる可用性ゾーンに配置されている場合、アプリケーションの応答時間が長くなる可能性があります。 ポッド間の余分なラウンドトリップの待機時間は、ほとんどのアプリケーションで許容範囲内に収まると予想されますが、特にポッド間のチャット型の通信方式など、低待機時間を必要とするアプリケーション シナリオも存在します。
アプリケーションをテストして、可用性ゾーン間で適切に動作することを確認することをお勧めします。
低待機時間などのパフォーマンス上の理由がある場合は、ポッドを同じ可用性ゾーン内の同じデータ センターに併置できます。 同じ可用性ゾーン内の同じデータ センター内にポッドを併置するには、一意のゾーンと近接配置グループを持つユーザー ノード プールを作成します。 新しいエージェント ノード プールを作成して PPG を指定することで、既存の AKS クラスターに近接配置グループ (PPG) を追加できます。 ポッド トポロジの分散制約を使用して、可用性ゾーン、ノード、およびリージョンにわたってポッドを AKS クラスタ内で分散する方法を制御します。
待機時間の短い通信を必要とするポッドが同じ可用性ゾーンに併置されると、ポッド間の通信は直接行われなくなります。 代わりに、ポッド通信は、AKS クラスター内のポッドの論理セットを定義するサービスを介してチャネル化されます。 ポッドは AKS と通信するように構成でき、サービスへの通信は、サービスのメンバーであるすべてのポッドに自動的に負荷分散されます。
可用性ゾーンを利用するために、ノード プールにはゾーン リソースである基礎的な VM が含まれています。 コンピューティングまたはストレージの要求が異なるアプリケーションをサポートするには、ユーザー ノード プールを作成するときに、特定の VM サイズでユーザー ノード プールを作成できます。
たとえば、アプリケーションのマイクロサービスには、高いスループット、低待機時間、および高い vCPU 数と大容量のメモリを提供するメモリ最適化された VM サイズが必要であるため、ユーザー ノードに
M-seriesのStandard_M32msを使用するなどです。 デプロイ リージョンによっては、Azure portal で VM サイズを選択したときに、この VM サイズはゾーン 1 と 2 でのみサポートされていると表示されることがあります。 この回復性の構成は、ハイ パフォーマンスのトレードオフとして受け入れることが可能です。VM を作成した後にノード プールの VM サイズを変更することはできません。 ノード プールの制限の詳細については、「制限事項」を参照してください。
Azure Database for MySQL フレキシブル サーバー
ノード プールをゾーン 1 や 2 などの特定のゾーンにデプロイすると、AKS クラスターのすべてのサービス依存関係もゾーン 1 と 2 をサポートする必要があります。 このワークロード アーキテクチャでは、AKS クラスターは、ゾーンの回復性を備えた Azure Database for MySQL フレキシブル サーバーに対するサービスの依存関係を持ちます。 プライマリ サーバーにはゾーン 1 を選択し、スタンバイ サーバーにはゾーン 2 を選択して、AKS ユーザー ノード プールと併置することになります。
Azure Cache for Redis
Azure Cache for Redis によって、ゾーン冗長キャッシュ内のノードが、選択された可用性ゾーンにラウンドロビン方式で分散されます。
ゾーン冗長性を使用するように既存の Premium キャッシュを更新することはできません。 ゾーン冗長を使用するには、Azure Cache for Redis を再作成する必要があります。
最適な回復性を実現するには、レプリカを 3 つの可用性ゾーンに分散できるように、3 つ以上のレプリカを含む Azure Cache for Redis を作成することをお勧めします。
ディザスター リカバリーの考慮事項
"可用性ゾーン" は、デプロイのプライマリ リージョン内でワークロードの高可用性を実現するための回復性を向上させるために使用されます。
"ディザスター リカバリー" は、復旧作業と、事業継続性計画で定義されているプラクティスで構成されます。 ビジネス継続性計画では、中断を伴うイベント発生時にどのようにワークロードを回復するか、またイベント発生後にどのように完全に回復するかの両方に対処します。 デプロイを別のリージョンに拡張することを検討してください。
アプリケーション層については、この記事の AKS の事業継続とディザスター リカバリーに関する考慮事項を確認してください。
代替のリージョンで複数の AKS クラスターを実行することを検討してください。 代替リージョンでは、セカンダリ ペア リージョンを使用できます。 または、プライマリ リージョンにリージョンのペアリングがない場合は、使用可能なサービス、キャパシティ、地理的な距離、データ主権に関する考慮事項に基づいて代替リージョンを選択できます。 詳しくは、「Azure リージョンの決定ガイド」を確認してください。 また、「デプロイ スタンプ パターン」も参照してください。
AKS クラスターには、アクティブ/アクティブ、アクティブ/スタンバイ、アクティブ/パッシブを構成するオプションがあります。
データベース層については、geo リストアを開始し、別のリージョンに読み取りレプリカをデプロイする機能を備えた geo 冗長バックアップを含む、ディザスター リカバリー機能が提供されています。
障害発生時には、復旧を開始するかどうかの意思決定を行う必要があります。 障害がワークロードの目標復旧時間 (RTO) よりも長く続きそうな場合にのみ、復旧作業を開始する必要があります。 それ以外の場合は、Azure Service Health Dashboard でサービスのステータスを確認しながら、サービスの回復を待ちます。 Azure portal の [Service Health] ブレードでは、サブスクリプションに関連するすべての通知を確認できます。
Azure Database for MySQL の geo リストア機能を使用して復旧を開始すると、別のリージョンからレプリケートされたバックアップ データを使用して新しいデータベース サーバーが作成されます。
次のステップ
各項目の詳細情報