Freigeben über

新しいリージョンへの Azure サービスの移行

  • Artikel

このポストは、6 月 30 日に投稿した Migrating Azure services to new regions の翻訳です。

最近、お客様のご依頼により、米国中南部リージョンから米国東部リージョンのデータ センターへとお客様のサービスを移行しました。移行作業には、適切なサイズの Premium (プレミアム) SKU のキャパシティ プランニングと、高可用性およびロールバック用のアクティブ Geo レプリケーションの活用が含まれていました。

お客様のご要望は、米国中南部リージョンの Azure サービスを米国東部リージョンに移行することでした。主にマイクロソフトの支援を必要としたのはデータベース関連で、ダウンタイムが発生する場合にはそれを的確に予測する必要がありました。またダウンタイムをできるだけ短く抑え、最長でも 6 時間以内としなくてはいけませんでした。

お客様の概要

お客様は、ジオソーシャル モバイル ゲームを開発する企業です。アフリカの 2 か国を除く全世界に展開されているこのゲームは、世界中の都市や町を認識し、プレーヤーは主に現実世界の地理的な場所に基づいてゲームに参加します。

計画

計画に関しては、複数のオプションを検討しました。検討には特に長い議論を要するわけではありませんが、これらのオプションはこのような移行計画には付き物であり、留意に値する点です。

  • データベースのサイズ
  • 現在データベースに使用されている SKU
  • 許容できるダウンタイムの長さ
  • 移行中の許容できるデータ損失の量 (万一、データ損失が発生した場合)
  • 移行作業の予算
  • 最近公開されたサービスや、プレビュー段階にあるサービスの使用の可否
  • データの移行に関する現時点での懸念事項
  • 懸念していない事項

 

このお客様の場合は、とにかく移行を実施することが最優先でした。そのため、移行の方法については、かなり自由にさまざまな提案を行うことができました。

データベースのサイズは約 35 GB でした。5 GB のデータはオンラインで利用できる必要がありましたが、残りは基本的にはオフラインで使用し、後から追加すればよいデータでした。

データベースは Business Edition の SKU で、Federations などの特定の Azure の機能は利用していませんでした。

最長 8 時間のダウンタイムを許容できるものの、2 時間以内に抑えることができれば、業務およびユーザーの期待に沿うことが格段に簡単になるとのことでした。また、特定の曜日および時間帯であればダウンタイムが発生しても許容可能なため、ダウンタイムのコントロールは必須の要件でした。

お客様はコストも重視されていましたが、提案したすべてのアイデアについて、そのコストに関する考慮事項も含めて受け入れていただきました。

お客様が特に慎重だったのは、データベースのコピー処理でした。大容量のデータの移行に伴うエクスポートおよびインポート作業に 10 時間以上かかると、業務に重大な影響が出るとお考えでした。

一方で、計算ノードの移行に関する懸念はなく、当面は既存の BLOB ストレージ データを移行する必要もありませんでした。ソリューションは、既存の BLOB へのアクセスにデータ センター間のロジックが必要ないように設計されました。

選択肢として、以下が挙げられました。

  1. アクティブ Geo レプリケーション機能を利用する
  2. すべての接続を停止し、データをエクスポートして、ファイルをコピーし、米国東部リージョンにインポートする
  3. データベースのコピーを作成し、データをエクスポートして、ファイルをコピーし、米国東部リージョンに復元する

結果、アクティブ Geo レプリケーションのオプションが選択されました。その理由は次のとおりです。

  • ダウンタイムが最短である
  • 計画された移行中にデータ損失が発生しない
  • ロールバックのオプションを利用できる
    • 実行に失敗した場合は、簡単な手順で米国中南部リージョンのデータ センターのリソースを再度有効化できる
  • TCO が最少である
  • Premium (プレミアム) SKU にアップグレードするという将来的な計画に対応している

お客様の唯一の懸念はサービスがプレビュー段階にあることでしたが、許容できるリスクだと見なされました。お客様のこれまでのパフォーマンスを調査した結果、お客様のニーズには P1 で十分に対応できると判断しました。マイクロソフトの懸念は、レプリケーションのリソース消費量が多い可能性があるということでした。しかし、ピークは 1 回限りのイベントであり、予測可能なリソース要件が高くないことから、引き続き P1 を使用し、すぐに P2 にアップグレードできるように準備しておくことになりました。

キャパシティ プランニング作業の一環として、お客様には「Azure SQL データベースの Basic (基本)、Standard (標準)、および Premium (プレミアム) プレビュー (https://msdn.microsoft.com/ja-jp/library/azure/dn369873.aspx)」の記事の参照をお願いしました。

実行

お客様側で、Premium (プレミアム) SKU プレビューにサインアップしていただく必要がありました。サインアップはポータルを利用して行い、数分で処理は完了します。

サインアップが完了したら、データベースを Premium (プレミアム) にアップグレードすることができます。計画に使用した計算の詳細については、「データベースのサービス階層とパフォーマンス レベルの変更 (https://msdn.microsoft.com/ja-jp/library/dn369872.aspx)」を参照してください。次の式を使用して、アップグレードの所要時間 (約 12 時間) をかなり正確に予測することができました。

3 * (5 分 + データベースのサイズ / 150 MB/分)

アップグレードはスムーズに実行されました。ある時点では複数の接続に失敗しましたが、MSDN の記事でも言及されているように、これは一時的かつ予測されたものでした。

次に、目的のリージョン (ここでは、米国東部) にレプリカを作成しました。当初、レプリカ作成の所要時間やレプリケーションを実行するために必要なリソースは不透明でした。この手順については、「アクティブな Geo レプリケーション設定でのフェールオーバー (https://msdn.microsoft.com/ja-jp/library/azure/dn741331.aspx)」にまとめられています。初回のレプリカの同期処理に要した時間についての質問には、お客様が的確に回答しています。

「(初回の同期処理には) 40 分もかかりませんでした*。実際のコピー処理の所要時間はわかりませんが、このデータベースのローカル bacpac ファイルを作成するのに 4 時間はかかることを考えれば、この数字は驚くべきものです」

*完全にオンラインでの処理

注目すべきは、この実行計画がコードのデプロイの合間に実施されたということです。単に技術的なプロセスの場合、大半は 24 時間以内に実施することができました。しかし、お客様は実行計画の次のアクションを開始するまでに数日置くことを選択しました。その理由は、大量のコード修正を新しいデータ センターではなく既存のトポロジで行ったためです。お客様は、DDL に対する修正のレプリケーションが行われるかどうかを懸念していました。実際には、マスター データベースの更新に依存する変更 (ログインなど) 以外はすべてレプリケーションが行われました。ユーザーの作成はレプリケーション元で実行できますが、マスター データベースの更新に依存する変更は各環境で行う必要があります。ログインに関しては、「アクティブな Geo レプリケーションのセキュリティ構成 (https://msdn.microsoft.com/ja-jp/library/azure/dn741335.aspx)」を参照してください。

最後に新しいリージョンへの切り替えを行いました。次の手順は、同様のタスクを他のケースでも実施できるように、お客様が公開されたものです。アクティブ Geo レプリケーション トポロジを終了する手順については、「連続コピーの関係の終了 (https://msdn.microsoft.com/ja-jp/library/azure/dn741323.aspx)」を参照してください。

  1. 1 週間前に、データベースの Premium (プレミアム) へのアップグレードと、米国東部のデータ センターへの Geo レプリケーションの設定を行います。この 2 つの作業は同じ日に実行しても構いません。米国中南部から東部に 32 GB のデータベースの完全なレプリケーションを行うために要する時間は 40 分未満です。
  2. [移行日] 東部に BLOB コンテナーを作成し、中南部のコンテナーと同じ名前を付けます (今回は BLOB データの移行は実施しませんでしたが、実施する場合はこの段階で行います)。
  3. 新しい Web ロールおよび Worker ロールを東部にデプロイします。東部のデータベースおよび BLOB ストレージの新しいデプロイメントを指定します。
  4. 必要に応じて、新しい環境 (米国東部) で SSL 証明書をセットアップします。
  5. であると
  6. (ダウンタイムの開始) 古い Web サイトと新しい Web サイトをオフラインにします。今回は、アプリケーションの構成スイッチを使用し、サイトがメンテナンス中という旨のわかりやすいメッセージを表示するようにしました。管理者のみが通常どおりにサイト/API にアクセスできます。
  7. DNS を変更して新しい Web ロールの IP アドレスを指定します。
  8. データベースおよび BLOB への接続文字列に米国東部を指定して、新しいコードを古いデータ センター (米国中南部) にデプロイします。
  9. 米国中南部の IP アドレスからの接続を許可するように東部のデータベースを構成します (不要な場合もあります)。
  10. 米国中南部の新しいデプロイメント (ステージング環境) をオフライン モードに設定し、本番環境とスワップします。
  11. データベースのアクティブ Geo レプリケーションを停止します (連続コピーの関係の計画終了)。
    • ポータルを使用して実行する手順
  12. 米国中南部のデータベースを読み取り専用モードに設定します。
  13. レプリケーションの完了後、米国東部リージョンのデータベースを読み取り/書き込みモードに設定します (不要な場合もあります)。
  14. (ダウンタイムの終了) 米国中南部および米国東部リージョンの両方のデータ センターの Web サイト/API を再度有効にします。
  15. 新しいデータベースで Azure DB の自動バックアップを設定します。
    • 管理ポータルのデータベースの [configure] セクションにある自動エクスポートを使用
  16. DNS レプリケーションが世界中で完全に反映されたら、米国中南部のアプリケーション サーバーを削除します。

次のお客様のご意見は、今回の移行作業を非常にわかりやすく表しています。

「移行は非常にスムーズに行われました。ダウンタイムは約 1 時間ほどでしたが、その大半は新しいコードのデプロイ、構成の更新、本番環境とステージング環境のスワップにかかった時間でした。Azure DB のレプリケーションをシャットダウンし、読み取り/書き込みモードに変更するという実際の処理はシンプルでした」