SQL Database アクティブ geo レプリケーションを使用してクラウド アプリケーションのローリング アップグレードを管理する

適用対象:Azure SQL Database

Azure SQL Database でアクティブ geo レプリケーションを使用してクラウド アプリケーションのローリング アップグレードを有効にする方法について説明します。 アップグレードは中断を伴う作業であるため、ビジネス継続性の計画と設計の一部として組み込む必要があります。 この記事では、アップグレード処理を編成する 2 種類の方法を確認し、方法ごとにメリットとトレードオフを説明します。 この記事では、データ層として単一のデータベースに接続されている Web サイトで構成されるアプリケーションを参照します。 ここでの目的は、ユーザー エクスペリエンスに大幅な影響を及ぼさずにアプリケーションをバージョン 1 (V1) からバージョン 2 (V2) にアップグレードすることです。

アップグレード オプションを評価するときは、以下の要因を考慮します。

• アプリケーションの機能が制限されたり低下したりする期間の長さなど、アップグレード中のアプリケーションの可用性への影響。
• アップグレードが失敗した場合にロールバックする機能。
• アップグレード中に関係のない致命的なエラーが発生した場合のアプリケーションの脆弱性。
• 合計コスト。 この要因には、アップグレード処理で使用される一時的なコンポーネントによるデータベース冗長性の補強とコストの増加が含まれます。

ディザスター リカバリーをデータベースのバックアップに依存するアプリケーションをアップグレードする

ディザスター リカバリーをデータベースの自動バックアップに依存し、geo リストアを使用しているアプリケーションは、単一の Azure リージョンにデプロイします。 ユーザーの中断を最小限に抑えるには、アップグレードに関連するすべてのアプリケーション コンポーネントで、そのリージョンにステージング環境を作成します。 最初の図は、アップグレード処理の前の運用環境を示しています。 エンドポイント contoso.azurewebsites.net は、Web アプリの運用環境を表します。 アップグレードのロールバックを可能にするには、完全に同期されたデータベースのコピーを使用してステージング環境を作成する必要があります。 次の手順に従って、アップグレード用のステージング環境を作成します。

1. 同じ Azure リージョンにセカンダリ データベースを作成します。 セカンダリ データベースを監視して、シード処理が完了したかどうかを確認します (1)。
2. Web アプリの新しい環境を作成して "Staging" という名前を付けます。 これは、contoso-staging.azurewebsites.net の URL で Azure DNS に登録されます (2)。

Note

これらの準備手順は運用環境に影響を与えず、環境はフル アクセス モードで動作できます。

準備の手順が完了すると、アプリケーションを実際にアップグレードできるようになります。 次の図は、アップグレード処理で必要な手順を示しています。

1. プライマリ データベースを読み取り専用モードに設定します (3)。 このモードでは、アップグレード中は Web アプリ (V1) の運用環境が必ず読み取り専用のままになり、V1 と V2 のデータベース インスタンス間のデータ不整合を防ぎます。
2. 計画終了モードを使用して、セカンダリ データベースを切断します (4)。 これにより、完全に同期された、プライマリ データベースの独立したコピーが作成されます。 このデータベースがアップグレードされます。
3. セカンダリ データベースで読み取り/書き込みモードを有効にして、アップグレード スクリプトを実行します (5)。

アップグレードが正常に終了すると、アプリケーションのアップグレードされたコピーにユーザーを切り替える準備が整い、これが運用環境になります。 この切り替えには、次の図に示すように、いくつかの手順がさらに必要になります。

1. Web アプリの運用環境とステージング環境のスワップ操作をアクティブにします (6)。 この操作は 2 つの環境の URL を切り替えます。 これで、contoso.azurewebsites.net が Web サイトとデータベース (運用環境) の V2 バージョンをポイントします。
2. V1 バージョンがスワップ後にステージング コピーになり、不要になった場合は、ステージング環境の使用を停止できます (7)。

(アップグレード スクリプトのエラーなどにより) アップグレード処理が失敗した場合は、ステージング環境が侵害されたと見なします。 アプリケーションをアップグレード前の状態にロールバックするには、運用環境のアプリケーションをフル アクセスに戻します。 次の図はバージョン再設定の手順を示しています。

1. データベースのコピーを読み取り/書き込みモードに設定します (8)。 この操作により、運用環境のコピーの V1 の機能が完全に復元されます。
2. 根本原因分析を実行し、ステージング環境の使用を停止します (9)。

この時点で、アプリケーションが完全に動作可能になり、アップグレードの手順を繰り返すことができます。

Note

まだスワップ操作を実行していないため、ロールバックに DNS の変更は必要ありません。

この方法の主なメリットは、一連の簡単な手順に従うことによって単一のリージョンでアプリケーションをアップグレードできる点です。 アップグレードのコストは比較的安価になります。

主なトレードオフ は、アップグレード中に致命的なエラーが発生した場合、アップグレード前の状態に回復するには、別のリージョンでアプリケーションを再度デプロイし、geo リストアを使用してバックアップからデータベースを復元する必要がある点です。 この処理により、大幅なダウンタイムが生じます。

ディザスター リカバリーをデータベースの geo レプリケーションに依存するアプリケーションをアップグレードする

アプリケーションでビジネス継続性のためにアクティブ geo レプリケーションまたはフェールオーバー グループを使用する場合、少なくとも 2 つの異なるリージョンにデプロイされます。 プライマリ リージョンにはアクティブなプライマリ データベースがあり、バックアップ リージョンには読み取り専用のセカンダリ データベースがあります。 この記事の冒頭で説明した要因に加えて、アップグレード処理では以下のことも保証する必要があります。

• アップグレード処理中は常に、致命的な障害からアプリケーションを保護する。
• アプリケーションの geo 冗長コンポーネントを、アクティブ コンポーネントと同時にアップグレードする。

これらの目標を達成するには、Web Apps 環境を使用するだけでなく、1 つのアクティブ エンドポイントと 1 つのバックアップ エンドポイントを備えたフェールオーバー プロファイルを使用することによって Azure Traffic Manager を利用します。 次の図は、アップグレード処理の前の運用環境を示しています。 Web サイトの contoso-1.azurewebsites.net と contoso-dr.azurewebsites.net は、完全な geo 冗長性を備えたアプリケーションの運用環境を表します。 運用環境に含まれるコンポーネントを次に示します。

• プライマリ リージョンの Web アプリ contoso-1.azurewebsites.net の運用環境 (1)
• プライマリ リージョンのプライマリ データベース (2)
• バックアップ リージョンの Web アプリのスタンバイ インスタンス (3)
• バックアップ リージョンの geo レプリケートされたセカンダリ データベース (4)
• contoso-1.azurewebsites.net という名前のオンライン エンドポイントと contoso-dr.azurewebsites.net という名前のオフライン エンドポイントがある Traffic Manager パフォーマンス プロファイル

アップグレードのロールバックを可能にするには、完全に同期されたアプリケーションのコピーを使用してステージング環境を作成する必要があります。 アップグレード処理中に致命的な障害が発生した場合、アプリケーションを必ず迅速に回復できる必要があるため、ステージング環境は geo 冗長性も必要とします。 次の手順は、アップグレード用のステージング環境の作成で必要になります。

1. プライマリ リージョンに Web アプリのステージング環境をデプロイします (6)。
2. プライマリ Azure リージョンにセカンダリ データベースを作成します (7)。 Web アプリのステージング環境を、これに接続するように構成します。
3. セカンダリ データベースをプライマリ リージョンにレプリケートすることで、バックアップ リージョンにもう 1 つの geo 冗長セカンダリ データベースを作成します (この方法を geo レプリケーションの連鎖と呼びます) (8)。
4. Web アプリ インスタンスのステージング環境をバックアップ リージョンにデプロイし (9)、(8) で作成した geo 冗長セカンダリ データベースに接続するように構成します。

Note

これらの準備手順は運用環境のアプリケーションに影響を与えません。 読み取り/書き込みモードで完全に機能する状態のままです。

準備の手順が完了すると、ステージング環境をアップグレードできるようになります。 次の図は、これらのアップグレードの手順を示します。

1. 運用環境のプライマリ データベースを読み取り専用モードに設定します (10)。 このモードでは、アップグレード中は運用データベース (V1) が変更されないことが保証されるため、V1 と V2 のデータベース インスタンスのデータの不整合を防ぎます。

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. セカンダリを切断して geo レプリケーション を終了します (11)。 この操作により、独立していても完全に同期された運用データベースのコピーが作成されます。 このデータベースがアップグレードされます。 次の例では Transact-SQL を使用していますが、PowerShell も使用できます。

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. contoso-1-staging.azurewebsites.net、contoso-dr-staging.azurewebsites.net、およびステージングのプライマリ データベースに対してアップグレード スクリプトを実行します (12)。 データベースの変更は、ステージングのセカンダリに自動的にレプリケートされます。

アップグレードが正常に終了すると、ユーザーを V2 バージョンのアプリケーションに切り替えられるようになります。 次の図に、必要な手順を示します。

1. プライマリ リージョン (13) とバックアップ リージョン (14) の Web アプリの運用環境とステージング 環境のスワップ操作をアクティブにします。 これで、アプリケーションの V2 が、バックアップ リージョンに冗長コピーのある運用環境になります。
2. V1 アプリケーションが不要になった場合 (15 および 16)、ステージング環境の使用を停止できます。

(アップグレード スクリプトのエラーなどにより) アップグレード処理が失敗した場合は、ステージング環境が不整合状態であると見なします。 アプリケーションをアップグレード前の状態にロールバックするには、運用環境で V1 のアプリケーションを使用するように戻します。 必要な手順は、次の図に示すとおりです。

1. 運用環境のプライマリ データベースのコピーを読み取り/書き込みモードに設定します (17)。 この操作により、運用環境の V1 の機能が完全に復元されます。
2. 根本原因分析を実行し、ステージング環境を修復するか削除します (18 および 19)。

この時点で、アプリケーションが完全に動作可能になり、アップグレードの手順を繰り返すことができます。

Note

スワップ操作を実行していないため、ロールバックに DNS の変更は必要ありません。

この方法の主なメリットは、アップグレード中にビジネス継続性を損なうことなく、アプリケーションと geo 冗長性を持つコピーの両方を並行してアップグレードできる点です。

主なトレードオフは、各アプリケーション コンポーネントが 2 倍の冗長性を必要とするため、コストが増加する点です。 また、より複雑なワークフローが必要になります。

まとめ

この記事で説明している 2 種類のアップグレード方法の違いは、複雑さとコストです。ただし、両方とも、ユーザーの操作が読み取り専用に制限される時間を最小限に抑えることに焦点を合わせています。 この時間は、直接的にはアップグレード スクリプトの時間で決まります。 データベースのサイズ、選択したサービス レベル、Web サイトの構成、または制御が容易でないその他の要因には左右されません。 すべての準備の手順は、アップグレードの手順から切り離されていて、運用アプリケーションに影響を与えません。 アップグレード スクリプトの効率性は、アップグレード中のユーザー エクスペリエンスを決定する重要な要素です。 そのエクスペリエンスを改善する最適な方法は、アップグレード スクリプトをできる限り効率的にすることに集中して取り組むことです。

関連するコンテンツ

• ビジネス継続性の概要
• アクティブ geo レプリケーションを使用して、読み取り可能なセカンダリ データベースを作成する
• フェールオーバー グループを使用して、複数のデータベースの透過的な調整されたフェールオーバーを有効にする
• Azure App Service でステージング環境を設定する。
• Azure Traffic Manager プロファイルの管理