Azure Kubernetes Service (AKS) での事業継続とディザスター リカバリーに関するベスト プラクティスBest practices for business continuity and disaster recovery in Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) でクラスターを管理するにあたっては、アプリケーションのアップタイムが重要になります。As you manage clusters in Azure Kubernetes Service (AKS), application uptime becomes important. AKS では、可用性セット内で複数のノードを使用することにより、高可用性が提供されます。AKS provides high availability by using multiple nodes in an availability set. しかし、これらの複数のノードでは、お使いのシステムはリージョン障害から保護されません。But these multiple nodes don’t protect your system from a region failure. アップタイムを最大化するには、ビジネス継続性の維持とディザスター リカバリーの準備について事前に計画を立てておきます。To maximize your uptime, plan ahead to maintain business continuity and prepare for disaster recovery.

この記事では、AKS でのビジネス継続性とディザスター リカバリーに関する計画を立てる方法に重点を置いて説明します。This article focuses on how to plan for business continuity and disaster recovery in AKS. 学習内容は次のとおりです。You learn how to:

  • 複数リージョン内の AKS クラスターに関する計画を立てる。Plan for AKS clusters in multiple regions.
  • Azure Traffic Manager を使用して、複数のクラスター間でトラフィックをルーティングする。Route traffic across multiple clusters by using Azure Traffic Manager.
  • コンテナー イメージのレジストリに geo レプリケーションを使用する。Use geo-replication for your container image registries.
  • 複数のクラスター間でのアプリケーション状態に関する計画を立てる。Plan for application state across multiple clusters.
  • 複数のリージョン間でストレージをレプリケートする。Replicate storage across multiple regions.

複数リージョンのデプロイに関する計画を立てるPlan for multiregion deployment

ベスト プラクティス: 複数の AKS クラスターをデプロイするときは、AKS が利用可能なリージョンを選択し、ペアになっているリージョンを使用します。Best practice: When you deploy multiple AKS clusters, choose regions where AKS is available, and use paired regions.

AKS クラスターは、1 つのリージョンにデプロイされます。An AKS cluster is deployed into a single region. リージョンの障害からシステムを保護するには、複数のリージョンにまたがる複数の AKS クラスターにアプリケーションをデプロイします。To protect your system from region failure, deploy your application into multiple AKS clusters across different regions. AKS クラスターをデプロイする場所を計画するときには、次の点を考慮してください。When you plan where to deploy your AKS cluster, consider:

  • AKS リージョンの可能性:ユーザーに近いリージョンを選択しましょう。AKS region availability: Choose regions close to your users. AKS では、継続的に新しいリージョンを展開しています。AKS continually expands into new regions.
  • Azure のペアになっているリージョン:利用する地域に対して、相互にペアになった 2 つのリージョンを選択しましょう。Azure paired regions: For your geographic area, choose two regions that are paired with each other. ペアになったリージョンでは、プラットフォームの更新が調整され、必要に応じて復旧作業の優先順位が付けられます。Paired regions coordinate platform updates and prioritize recovery efforts where needed.
  • サービスの可用性:ペアになったリージョンを、ホット/ホット、ホット/ウォーム、またはホット/コールドのいずれにするかを決定します。Service availability: Decide whether your paired regions should be hot/hot, hot/warm, or hot/cold. 両方のリージョンを同時に実行する場合、一方のリージョンをトラフィックの提供を開始する "準備ができた" 状態にするのか、Do you want to run both regions at the same time, with one region ready to start serving traffic? それとも一方のリージョンはトラフィックの提供を準備する時間が必要な状態にするのかを検討しましょう。Or do you want one region to have time to get ready to serve traffic?

AKS リージョンの可用性と、ペアになったリージョンは、複合的に考慮する必要があります。AKS region availability and paired regions are a joint consideration. AKS クラスターは、リージョンのディザスター リカバリーを連携的に管理するよう設計された、ペアのリージョンにデプロイするようにしましょう。Deploy your AKS clusters into paired regions that are designed to manage region disaster recovery together. たとえば、AKS は "米国東部" と "米国西部" で利用できます。For example, AKS is available in East US and West US. これらのリージョンはペアになっています。These regions are paired. AKS の BC/DR 戦略を作成するときは、これらの 2 つのリージョンを選択します。Choose these two regions when you're creating an AKS BC/DR strategy.

アプリケーションをデプロイするときは、これらの複数の AKS クラスターにデプロイするためのもう 1 つのステップを CI/CD パイプラインに追加します。When you deploy your application, add another step to your CI/CD pipeline to deploy to these multiple AKS clusters. デプロイ パイプラインを更新しないと、アプリケーションが 1 つのリージョンや AKS クラスターのみにデプロイされる可能性があります。If you don't update your deployment pipelines, applications might be deployed into only one of your regions and AKS clusters. セカンダリ リージョンに送信されるカスタマー トラフィックは、最新のコード更新を受け取りません。Customer traffic that's directed to a secondary region won't receive the latest code updates.

Azure Traffic Manager を使用してトラフィックをルーティングするUse Azure Traffic Manager to route traffic

ベスト プラクティス: Azure Traffic Manager は、お客様を最も近い AKS クラスターおよびアプリケーション インスタンスに送ることができます。Best practice: Azure Traffic Manager can direct customers to their closest AKS cluster and application instance. パフォーマンスと冗長性を最大限に高めるため、すべてのアプリケーション トラフィックは、Traffic Manager を介して AKS クラスターへ送るようにします。For the best performance and redundancy, direct all application traffic through Traffic Manager before it goes to your AKS cluster.

複数のリージョンに複数の AKS クラスターがある場合は、Traffic Manager を使用して、各クラスターで実行されているアプリケーションにトラフィックをどのように送信するかを制御します。If you have multiple AKS clusters in different regions, use Traffic Manager to control how traffic flows to the applications that run in each cluster. Azure Traffic Manager は、ネットワーク トラフィックをリージョン間で分散することができる、DNS ベースのトラフィック ロード バランサーです。Azure Traffic Manager is a DNS-based traffic load balancer that can distribute network traffic across regions. Traffic Manager を使用して、クラスターの応答時間、または地理的な場所に基づいてユーザーをルーティングします。Use Traffic Manager to route users based on cluster response time or based on geography.

Traffic Manager を使用する AKS

1 つだけの AKS クラスターを持つお客様は、通常、特定のアプリケーションのサービス IP または DNS 名に接続します。Customers who have a single AKS cluster typically connect to the service IP or DNS name of a given application. 複数クラスター デプロイでは、お客様は、各 AKS クラスター上のサービスを指す、Traffic Manager の DNS 名に接続する必要があります。In a multicluster deployment, customers should connect to a Traffic Manager DNS name that points to the services on each AKS cluster. これらのサービスは、Traffic Manager エンドポイントを使用して定義します。Define these services by using Traffic Manager endpoints. 各エンドポイントは、"サービス ロード バランサー IP" です。Each endpoint is the service load balancer IP. この構成を使用して、あるリージョンの Traffic Manager エンドポイントから別のリージョンのエンドポイントにネットワーク トラフィックを送信します。Use this configuration to direct network traffic from the Traffic Manager endpoint in one region to the endpoint in a different region.

Traffic Manager を使用した地理的ルーティング

Traffic Manager は DNS 参照を実行して、ユーザーの最も適切なエンドポイントを返します。Traffic Manager performs DNS lookups and returns a user's most appropriate endpoint. 入れ子になったプロファイルは、プライマリの場所の優先順位を付けることができます。Nested profiles can prioritize a primary location. たとえば、ユーザーは通常、地理的に最も近いリージョンに接続します。For example, users should generally connect to their closest geographic region. そのリージョンに問題がある場合、Traffic Manager は代わりにユーザーをセカンダリ リージョンに送ります。If that region has a problem, Traffic Manager instead directs the users to a secondary region. この方法により、地理的に最も近いリージョンが利用できなくても、お客様はアプリケーション インスタンスに確実に接続することができます。This approach ensures that customers can connect to an application instance even if their closest geographic region is unavailable.

エンドポイントとルーティングを設定する方法については、Traffic Manager を使用した地理的トラフィック ルーティング方法の構成に関する記事をご覧ください。For information on how to set up endpoints and routing, see Configure the geographic traffic routing method by using Traffic Manager.

Azure Front Door Service を使用したレイヤー 7 のアプリケーション ルーティングLayer 7 application routing with Azure Front Door Service

Traffic Manager は、DNS (レイヤー 3) を使ってトラフィックのシェーピングを行います。Traffic Manager uses DNS (layer 3) to shape traffic. Azure Front Door Service には、HTTP/HTTPS (レイヤー 7) のルーティング オプションが用意されています。Azure Front Door Service provides an HTTP/HTTPS (layer 7) routing option. Azure Front Door Service の追加機能としては、SSL 終了、カスタム ドメイン、Web アプリケーション ファイアウォール、URL の書き換え、セッション アフィニティがあります。Additional features of Azure Front Door Service include SSL termination, custom domain, web application firewall, URL Rewrite, and session affinity. アプリケーション トラフィックのニーズを確認して、どのソリューションが最も適切かを検討してください。Review the needs of your application traffic to understand which solution is the most suitable.

コンテナー イメージの geo レプリケーションを有効にするEnable geo-replication for container images

ベスト プラクティス: コンテナー イメージを Azure Container Registry に格納し、レジストリを各 AKS リージョンに geo レプリケーションします。Best practice: Store your container images in Azure Container Registry and geo-replicate the registry to each AKS region.

AKS でアプリケーションをデプロイして実行するには、コンテナー イメージを格納してプルするための手段が必要です。To deploy and run your applications in AKS, you need a way to store and pull the container images. Container Registry は AKS と統合することで、コンテナー イメージや Helm チャートを安全に格納することができます。Container Registry integrates with AKS, so it can securely store your container images or Helm charts. Container Registry は、マルチマスターの geo レプリケーションをサポートして、世界各地の Azure リージョンにイメージを自動的にレプリケートします。Container Registry supports multimaster geo-replication to automatically replicate your images to Azure regions around the world.

パフォーマンスと可用性を改善するには、Container Registry の geo レプリケーションを使用して、AKS クラスターが置かれている各リージョンにレジストリを作成します。To improve performance and availability, use Container Registry geo-replication to create a registry in each region where you have an AKS cluster. これにより、各 AKS クラスターは、同じリージョン内のローカル コンテナー レジストリからコンテナー イメージをプルします。Each AKS cluster then pulls container images from the local container registry in the same region:

コンテナー イメージに対する Container Registry の geo レプリケーション

Container Registry の geo レプリケーションを使用して同じリージョンからイメージをプルすると、次のような結果になります。When you use Container Registry geo-replication to pull images from the same region, the results are:

  • より高速:同じ Azure リージョン内で、高速かつ低待機時間のネットワーク接続からイメージをプルします。Faster: You pull images from high-speed, low-latency network connections within the same Azure region.
  • 信頼性の向上:リージョンが利用できない場合、AKS クラスターは、使用可能なコンテナー レジストリからイメージをプルします。More reliable: If a region is unavailable, your AKS cluster pulls the images from an available container registry.
  • 低コスト:データセンター間のネットワーク エグレス料金が発生しません。Cheaper: There's no network egress charge between datacenters.

geo レプリケーションは、Premium SKU コンテナー レジストリの機能です。Geo-replication is a feature of Premium SKU container registries. geo レプリケーションを構成する方法については、Container Registry の geo レプリケーションに関する記事をご覧くださいFor information on how to configure geo-replication, see Container Registry geo-replication.

サービスの状態をコンテナー内から削除するRemove service state from inside containers

ベスト プラクティス: 可能な場合、サービスの状態をコンテナー内に格納しないでください。Best practice: Where possible, don't store service state inside the container. 代わりに、マルチリージョン レプリケーションをサポートする Azure のサービスとしてのプラットフォーム (PaaS) を使用します。Instead, use an Azure platform as a service (PaaS) that supports multiregion replication.

サービスの状態とは、サービスが機能するために必要な、メモリ内またはディスク上のデータのことです。Service state refers to the in-memory or on-disk data that a service requires to function. これには、サービスによって読み書きされるデータ構造やメンバー変数が含まれます。State includes the data structures and member variables that the service reads and writes. サービスの設計方法に応じて、状態には、ディスクに格納されているファイルやその他のリソースも含まれることがあります。Depending on how the service is architected, the state might also include files or other resources that are stored on the disk. たとえば、状態には、データとトランザクション ログを格納するためにデータベースで使用されるファイルが含まれる場合があります。For example, the state might include the files a database uses to store data and transaction logs.

状態は、外部化することも、状態を操作するコードと同じ場所に配置することもできます。State can be either externalized or colocated with the code that manipulates the state. 通常、状態の外部化は、ネットワーク上のさまざまなコンピューターで実行されている、または同一コンピューター上でアウト オブ プロセスを実行しているデータベースやその他のデータ ストアを使用して行います。Typically, you externalize state by using a database or other data store that runs on different machines over the network or that runs out of process on the same machine.

コンテナーとマイクロサービスは、それらの内部で実行されているプロセスが状態を保持していないときに、回復性が最も高くなります。Containers and microservices are most resilient when the processes that run inside them don't retain state. アプリケーションにはほぼ常に何らかの状態が含まれるので、Azure Database for MySQL、Azure Database for PostgreSQL、または Azure SQL Database などの PaaS ソリューションを使用してください。Because applications almost always contain some state, use a PaaS solution such as Azure Database for MySQL, Azure Database for PostgreSQL, or Azure SQL Database.

ポータブル アプリケーションをビルドするには、次のガイドラインを参照してください。To build portable applications, see the following guidelines:

ストレージ移行プランの作成Create a storage migration plan

ベスト プラクティス: Azure Storage を使用する場合は、ストレージをプライマリ リージョンからバックアップ リージョンに移行する方法を準備してテストします。Best practice: If you use Azure Storage, prepare and test how to migrate your storage from the primary region to the backup region.

お使いのアプリケーションで、Azure Storage がデータに使用される場合があります。Your applications might use Azure Storage for their data. アプリケーションは複数のリージョン内の複数の AKS クラスターに分散されるので、ストレージを同期しておく必要があります。Because your applications are spread across multiple AKS clusters in different regions, you need to keep the storage synchronized. ストレージをレプリケートする 2 つの一般的な方法は次のとおりです。Here are two common ways to replicate storage:

  • インフラストラクチャベースの非同期レプリケーションInfrastructure-based asynchronous replication
  • アプリケーションベースの非同期レプリケーションApplication-based asynchronous replication

インフラストラクチャベースの非同期レプリケーションInfrastructure-based asynchronous replication

アプリケーションには、ポッドが削除された後も、永続的ストレージが必要な場合があります。Your applications might require persistent storage even after a pod is deleted. Kubernetes では、永続ボリュームを使用してデータ ストレージを保持することができます。In Kubernetes, you can use persistent volumes to persist data storage. 永続ボリュームはノード VM にマウントされてから、ポッドに公開されます。Persistent volumes are mounted to a node VM and then exposed to the pods. 永続ボリュームは、ポッドが同じクラスター内の別のノードに移動されても、ポッドに従います。Persistent volumes follow pods even if the pods are moved to a different node inside the same cluster.

使用するレプリケーションの方法は、お使いのストレージ ソリューションによって決まります。The replication strategy you use depends on your storage solution. GlusterCephRookPortworx などの一般的なストレージ ソリューションには、ディザスター リカバリーとレプリケーションに関する独自のガイダンスがあります。Common storage solutions such as Gluster, Ceph, Rook, and Portworx provide their own guidance about disaster recovery and replication.

一般的な方法は、アプリケーションがデータを書き込める共通のストレージ ポイントを提供するというものです。The typical strategy is to provide a common storage point where applications can write their data. これらのデータは、その後リージョン間でレプリケートされ、ローカルにアクセスされます。This data is then replicated across regions and then accessed locally.

インフラストラクチャベースの非同期レプリケーション

Azure Managed Disks を使用している場合は、次のようなレプリケーションと DR ソリューションを選択することができます。If you use Azure Managed Disks, you can choose replication and DR solutions such as these:

アプリケーションベースの非同期レプリケーションApplication-based asynchronous replication

現在のところ、Kubernetes では、アプリケーションベースの非同期レプリケーションに対応したネイティブ実装は提供されていません。Kubernetes currently provides no native implementation for application-based asynchronous replication. コンテナーと Kubernetes は疎結合されているので、従来型のアプリケーションや言語アプローチが機能するはずです。Because containers and Kubernetes are loosely coupled, any traditional application or language approach should work. 通常は、アプリケーション自体がストレージ要求をレプリケートし、次にそれらが、各クラスターの基盤となるデータ ストレージに書き込まれます。Typically, the applications themselves replicate the storage requests, which are then written to each cluster's underlying data storage.

アプリケーションベースの非同期レプリケーション

次の手順Next steps

この記事では、AKS クラスターでのビジネス継続性とディザスター リカバリーに関する考慮事項に重点を置いて説明しました。This article focuses on business continuity and disaster recovery considerations for AKS clusters. AKS でのクラスター操作の詳細については、ベスト プラクティスに関する次の記事を参照してください。For more information about cluster operations in AKS, see these articles about best practices: