移行に関する考慮事項

24 分

オンプレミスで実行されている業務システムのアーキテクチャは、同じ環境内で動作する他のサービスと結合されている可能性があります。移行するシステムと、組織が現在使用している他のアプリケーションやサービスとの関係を理解しておくことが重要です。

あなたが勤務するスタートアップテクノロジ企業では、コンポーネントの在庫を常に確保し、製造プロセスで使用するためにジャストインタイムで到着するように、サプライヤーデータベースを使用しています。在庫管理担当者は、委託販売品が到着すると、モバイルデバイスを使用してこのデータベースを更新します。購入担当者は Web サイトを使用して在庫レベルを監視し、注文するのに最適な時期を特定します。マネージャーは、一連のビジネスクリティカルなレポートを使用してプロセスを監視し、効率を高めています。これらのユーザーが、Azure への移行によって悪影響を受けないようにする必要があります。

ここでは、クラウドへのスムーズなデータベース移行を計画し、実行する方法について説明します。

依存関係を調査する

複雑なシステムでは、コンポーネントが完全に独立して機能することはほとんどありません。代わりに、他のプロセスやコンポーネントが呼び出されます。たとえば、データベースは、ユーザーアカウントをホストするディレクトリサービスに依存している場合があります。データベースをクラウドに移行した場合に、そのディレクトリサービスにアクセスできますか? できない場合、ユーザーはどのようにサインインするのでしょうか。このような依存関係を見落とすと、データベースの全体的な障害が発生する可能性があります。

リスクを軽減するには、データベースが次のようなサービスに依存しているかどうかを確認します。

ディレクトリサービス (Active Directory など)。
セキュリティプリンシパルの他のストア。
他のデータベース。
Web API または他のネットワークサービス。

また、他のコンポーネントがデータベースに依存している可能性があることにも注意してください。依存コンポーネントを再構成せずにデータベースを移行した場合、どのような影響があるのでしょうか。たとえば、製品カタログデータベースを移行し、一般向けの Web サイトがユーザーに提示する製品を決定するためにそれに依存している場合、この移行によってサービスの中断は発生しませんか?

これらの種類のコンポーネントがデータベースに依存しているかどうかを確認します。

Web サイトと Web API。
クライアントアプリ (モバイルアプリやデスクトップソフトウェアなど)。
他のデータベース。
レポート
データウェアハウス。

これらのチェックを行うには、各データベースやシステムコンポーネントにかかわる関係者、管理者、開発者と話をします。次に、ドキュメントを参照します。システムの動作を把握しているという自信がない場合は、動作を観察するためのネットワークキャプチャなど、テストを実行することを検討してください。

フォールバックの準備をする

どの移行プロジェクトでも、常に失敗に備える必要があります。クラウドへのデータベース移行プロジェクトでは、最悪の事態は、新しいデータベースが使用できなくなり、ユーザーが仕事をすることができなくなることです。オンプレミスの変更されていない元のデータベースへのロールバックを計画することによって、会社の収益性に大きな影響を与える可能性のあるこのリスクを軽減するのが一般的です。

フォールバック計画では、次の点を考慮してください。

失敗した移行の影響を受けていないデータベースにフォールバックできるようにするにはどうすればよいか。たとえば、移行を開始する直前に、データベースの完全バックアップを作成することを強くお勧めします。
フォールバックする必要がある場合、データベースがオフラインになる時間として許容できる時間はどのくらいか。
フォールバック計画の予算はどのくらいか。たとえば、データベースを専用のフォールバックサーバーにレプリケートする余裕はありますか? ある場合は、移行の直前にこのサーバーをオフに切り替えることができます。フォールバックするには、このサーバーを起動します。バックアップから復元しなくても、移行の影響を受けていないデータベースをすぐに使用できます。

オフライン移行とオンライン移行

データベースを移行するには、少なくとも 2 つの方法があります。

注意

現在、データ移行サービスの MySQL データベースには、オンライン オプションを使用できません。

システムを停止し、データベースを転送した後、新しいデータベースを使用するようにシステムを再構成して再起動します。これがオフライン移行です。
データベースを新しい場所に移動する間もシステムを実行し続け、移行の進行中に元のデータベースに対して実行されているトランザクションを新しいデータベースにロールフォワードしてから、新しいデータベースに接続するようにアプリケーションを切り替えます。これがオンライン移行です。

移行が行われている間、ユーザーがデータを変更できないオフライン移行を実行する方が簡単です。ただし、データベースがビジー状態の場合や組織の成功に不可欠な場合、これは不可能と考えられます。

オフライン移行

全員が通常の営業時間中の 1 つのタイムゾーンで仕事をしているアナリストのチームをデータベースがサポートしているとします。このチームは、通常、週末は仕事をしません。金曜日の午後 6 時から日曜日の午前 9 時までの間、データベースはあまり使用されません。

この状況では、これらの手順に従って、週末にオフライン移行を実行できます。

金曜日の夜にすべてのトランザクションが完了したら、データベースをオフラインにします。
データベースの完全バックアップまたはエクスポートを作成します。
フォールバックが必要な場合に備えて、オンプレミスサーバーをシャットダウンして保持します。
ターゲットクラウドシステムにデータベースを復元します。
ターゲットシステムをオンラインにします。
クラウドデータベースに接続するようにクライアントを再構成します。

この例では、サービスの中断がユーザーにほとんど影響を与えない期間が長いため、オフライン移行が可能です。この間、変更を見逃すことはないことがわかっているので、データベースの完全なバックアップと復元を実行できます。

オンライン移行

次に、販売アプリをサポートする別のデータベースについて考えてみましょう。販売スタッフは世界中に分散しており、週末も仕事をしています。アクティビティが少ない期間はなく、データベースは常にビジー状態です。データベースを長時間オフラインにすると、ユーザーに影響を及ぼします。販売活動はビジネスに不可欠であるため、サービスの中断は組織の最終的な収益に直接影響します。

このような場合は、オンライン移行を実行することを検討します。オンライン移行では、ダウンタイムは新しいデータベースへの切り替えにかかる時間に限られています。オンライン移行を実行するには、Azure Data Migration Service などのツールを使用します。オンライン移行は、オフライン移行と次の点が異なります。

バックアップまたはエクスポートを作成する前に、元のデータベースをオフラインにしません。
移行の進行中に、変更が古いデータベースに適用されます。
移行ツールにより、切り替え前に、これらの変更が新しいデータベースに確実にコピーされます。多くの場合、これは、変更を新しいデータベースにレプリケートするように古いデータベースを再構成することで実現されます。

アプリケーションの移行

データベースを移行した後、(いつ) どのように新しいシステムに切り替え、新しいデータベースを使用するようにアプリケーションを更新すればよいのでしょうか。次の方法があります。

アプリケーションを 1 つずつ新しいデータベースに移行する。
ユーザーのサブセットを移行する。
両方の方法の組み合わせを採用する。

目的は、問題が発生した場合に簡単にロールバックできる小さなステージでアプリケーションの移行を実行することです。データベースの移行にオフラインとオンラインのどちらのアプローチを採用したかに関係なく、動作する構成が元のソースに残されています。理論的には、元のソースにすぐに戻すことができます。しかし、データが常に変更されている場合、これらの変更が行われた場所を考慮する必要があります。

オフライン移行では、移行元と移行先が互いに独立しています。ユーザーとアプリケーションに、データの一貫性のあるビューが表示されなくなっている場合があります。トランザクションシステムでは、この状況は許容できない可能性があります。この場合、両方のシステムが稼働している間、データベース間でなんらかの形の双方向レプリケーションを維持する必要があります。一方、アプリケーションの目的が、月次または週次レポートの生成、売上予測の生成、または他の統計演算の実行である場合、この一貫性の欠如はそれほど気にならないかもしれません。このようなアプリケーションは、最新のデータに依存しているのではなく、データを "長期的な視点 " で捉えています。この場合、トランザクションアプリケーションでは新しいデータベースを使用し、レポートアプリケーションは少し時間を掛けて移行します。
オンライン移行では、通常はなんらかの形式のレプリケーションによって、新しいデータベースで古いデータベースとの同期が維持されます。レプリケーションプロセスは非同期の場合があるため、遅延が発生する可能性があります。新しいデータベースのデータに加えられた変更が古いデータベースに伝達されていない場合、競合が発生する可能性があります。古いデータベースに対して実行されているアプリケーションが、新しいデータベースで変更されたデータに対して競合する変更を加えることがあります。レプリケーションによって、新しいデータベースの変更が無条件に上書きされると、"更新が失われる" ことになります。

テストの方法

データベースがビジネスで重要な役割を果たしている場合、障害の影響が広範囲に及ぶ可能性があります。このようなことは起こらないという自信を高めるために、移行されたデータベースに対してパフォーマンステストを実行して、データベースがユーザーによる負荷に対処し、迅速に応答できることを確認することを検討します。需要が通常よりもはるかに高くなる、アクティビティのピーク期間が発生する可能性があることに注意してください。移行されたシステムで予想されるワークロードが処理されていることを確認する必要があります。

ユーザーにアクセスを許可する前に、新しいデータベースに対してある種の回帰テストを必ず実行します。これらのテストにより、システムの動作と機能が正しいことを確認できます。

さらに、"ソークテスト" を実行することを検討する必要があります。ソークテストとは、負荷の下でのシステム全体の動作を確認することを目的とした負荷テストです。ソークテストで新しいデータベースにストレスを掛け、高需要下で安定しているかどうかを判断します。ソークテストを長期間にわたって実行して、高い需要が続いたときにどうなるかを確認します。

新しいシステムが安定していることを確かめたら、ユーザーの移行を開始できます。ただし、ユーザーが新しいシステムを許容できるという保証も必要になる場合があります。この時点で、"カナリアテスト" を検討することをお勧めします。カナリアテストでは、ユーザーの小さなサブセットを新しいシステムに透過的に誘導しますが、ユーザーはそれにアクセスしていることに気付いていません。これは、新しいシステムの問題や課題を見つけられるようにすることを目的としたブラインドテストの一種です。これらのユーザーからの反応を監視し、必要な調整を行います。

並列システムの維持

古いオンプレミスデータベースを新しいクラウドデータベースと並列で実行することを選択する理由がいくつかあります。

テスト期間。前のトピックで説明したように、移行されたデータベースに対してカナリアテストを実行して、ユーザーのサポートに使用する前に、機能、安定性、容量を評価することをお勧めします。オンプレミスシステムを並列に維持することで、新しいシステムで問題が発生した場合に、ユーザーを古いシステムに速やかに戻すことができます。
段階的な移行。運用環境への予期しない障害の影響を軽減する 1 つの方法として、最初に少数のユーザーを新しいシステムに移行し、結果を監視します。すべてがスムーズに実行されていれば、新しいデータベースに自信が持てるので、他のユーザーグループを移行できます。すべてのユーザーを新しいデータベースに移行するまで、ユーザーをアルファベット順、部門別、拠点別、または役割別に移行できます。
段階的な部分移行。もう 1 つの方法は、ユーザーごとではなく、ワークロードごとに移行をセグメント化することです。たとえば、人事をサポートするデータベーステーブルを移行してから、販売をサポートするものを移行します。

どの場合も、古いオンプレミスデータベースを新しいクラウドデータベースと並列で実行する期間があります。古いデータベースに加えられた変更が新しいデータベースにも確実に適用されるようにする必要があります。逆方向のフローも同様です。この同期をスクリプト化することも、Azure Data Migration Service などのツールを使用することもできます。

並列データベースを維持し、変更を同期することにした場合は、次の質問を自問してください。

競合の解決。オンプレミスの行に対する変更が、クラウドの同じ行に対する別の変更とほぼ同時に発生する可能性はあるか。これにより、競合が発生し、どの変更を保持すればよいかが不明確になります。このような競合をどのように解決しますか?
ネットワークトラフィック。データベース間で変更が同期されている間に、どのくらいの量のネットワークトラフィックが生成されるか。このトラフィックに対応できるだけのネットワーク容量があるか。
待機時間。一方のデータベースで変更が発生した場合、その変更がもう一方のデータベースに届くまでに、どのくらいの遅延 (ある場合) を許容できるか。たとえば、製品カタログでは、すべてのユーザーに新しい製品が表示されるまで最大 1 日待つことができる場合があります。しかし、データベースに通貨為替レートなどの重要なトランザクション情報が含まれている場合は、瞬時ではないにしても、かなり頻繁にそのデータを同期する必要があります。

段階的な部分移行

段階的な部分移行では、システム全体をワークロードに分割し、ワークロードを 1 つずつ移行します。

複数のデータベース

複雑なシステムには、複数のワークロードをサポートする複数のデータベースが含まれている可能性があります。たとえば、人事部では StaffDB データベースを使用し、販売チームは ProductCatalogDB データベースと OrdersDB データベースの両方に対してクエリを実行するモバイルアプリを使用している場合があります。

もちろん、データベースシステム全体を一度にクラウドに移行することもできます。オンプレミスとクラウドの両方でデータベースを実行する必要がないため、この方が簡単です。移行中にこれらのデータベースが通信する方法を考慮する必要はありません。ただし、障害のリスクが高まります。 1 つの問題が、人事チームと販売チームの両方に影響する可能性があります。

中規模および大規模なデータベースシステムでは、ワークロードを 1 つずつ移行する段階的な部分移行を実行して、これらのリスクを軽減することを検討します。この例では、最初に StaffDB データベースを移行することを検討します。障害に関連する問題が人事チームに限定され、注文を妨げることはないためです。 StaffDB の移行で発生した問題を解決することで、他のワークロードの移行に適用できる教訓が得られます。

次に、"製品カタログ" ワークロードのクラウドへの移行について考えてみましょう。この場合、次のような質問について考えてみてください。

カタログに新しく追加された製品を確実に注文できるようにするにはどうすればよいか。
オンプレミスに残されている OrdersDB データベースとデータを同期する必要があるか。
新しい製品が製品カタログから OrdersDB データベースに到着するまでの許容できる待ち時間はどのくらいか。

単一のデータベースの段階的な部分移行

1 つのデータベースだけですべてのワークロードがサポートされている場合でも、段階的な部分移行を検討できます。たとえば、データベースをこのような部分に分割できます。

人事業務をサポートするテーブル。
販売をサポートするテーブル。
分析とレポートをサポートするテーブル。

最初に人事業務テーブルを移行すると、発生した問題は人事担当者にのみ影響します。販売部門とデータアナリストは、中断なしで古いデータベースを引き続き使用できます。

段階的な部分移行を実行する前に、データベースと、それらがアプリケーションでどのように使用されているのかについて十分に理解しておく必要があります。たとえば、データベースの一部のテーブルで、販売とレポートの両方がサポートされているとします。この場合、ワークロードをはっきりと分けることはできません。すべてのワークロードが移行されるまで、オンプレミスデータベースとクラウドデータベースの間でこれらのテーブルを同期する必要があります。

セキュリティに関する考慮事項

データベースには、製品の詳細、スタッフの個人情報、支払いの詳細などの機密データが含まれている場合があるため、セキュリティは常に最優先事項です。移行中および新しいデータベースでこのデータを保護する方法を決める必要があります。

ファイアウォールによる保護

インターネットに接続されたアプリケーションでは、通常、データベースサーバーは少なくとも 2 つのファイアウォールで保護されています。たとえば、フロントエンドサーバーが Web サイトまたは Web API をホストしている場合、1 つ目のファイアウォールで、インターネットをこれらのサーバーから分離します。外側のこのファイアウォールでは、TCP ポート 80 だけを開く必要がありますが、このポートは、ブロックされたアドレスを除くすべての送信元 IP アドレスに対して開いている必要があります。

2 つ目のファイアウォールでは、フロントエンドサーバーをデータベースサーバーから分離します。外部に知られていないプライベートポート番号でデータベースサービスを公開することをお勧めします。 2 つ目のファイアウォールでは、フロントエンドサーバーの IP アドレスに対してのみ、このポート番号を開きます。この配置により、悪意のあるインターネットユーザーからデータベースサーバーへの直接通信を防ぐことができます。

データベースサーバーを Azure 仮想マシンに移行する場合は、仮想ネットワークをネットワークセキュリティグループ (NSG) と共に使用して、ファイアウォール規則をレプリケートします。 Azure Database for MySQL、Azure Database for MariaDB、または Azure Database for PostgreSQL を使用する場合は、Azure portal でサーバーの [接続のセキュリティ] ページを使用して、データベースを保護するためのファイアウォール規則を作成できます。

認証と承認

ほとんどのデータベースでは、どのユーザーがどのデータにアクセスし、変更するのかを厳密に制御する必要があります。この制御では、ユーザーがデータベースに接続するときに、ユーザーを確実に識別する必要があります。このプロセスは認証と呼ばれ、通常はユーザー名とパスワードを使用して実行されます。 MySQL、MariaDB、PostgreSQL などのデータベースシステムは、独自の認証メカニズムを備えています。システムをクラウドに移行したときに、引き続きユーザーを安全に認証できるようにする必要があります。

注意

Azure Database for MySQL、Azure Database for MariaDB、Azure Database for PostgreSQL の各サービスでは、従来の MySQL、MariaDB、および PostgreSQL 認証をエミュレートします。

ユーザーがだれであるかがわかったら、業務の一部であるタスクを完了するためのアクセス許可を割り当てる必要があります。このプロセスは承認と呼ばれます。

データベース移行プロジェクトの場合、ユーザーがクラウドデータベースで正しく承認されていることを確認する必要があります。

オンプレミスシステムでユーザーアカウントが保存されている場所を確認します。 MySQL では、通常、ユーザーアカウントは mysql データベースの user テーブルに保存されていますが、たとえば、Active Directory に保存されているユーザーアカウントと統合することもできます。
すべてのユーザーアカウントのリストを取得します。たとえば、MySQL では、このコマンドを使用できます。
```
SELECT host, user FROM mysql.user;
```
ユーザーアカウントごとに、データベースに対するアクセス権を確認します。たとえば、MySQL では、dbadmin@on-premises-host ユーザーアカウントに対してこのコマンドを使用できます。
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
各ユーザーアカウントをクラウドデータベースに再作成します。たとえば、MySQL では、このコマンドを使用して新しいアカウントを作成できます。
```
CREATE USER 'dbadmin'@'cloud-host'
```
クラウドデータベースで適切なアクセスレベルに対して各ユーザーアカウントを承認します。たとえば、MySQL では、このコマンドを使用して、ユーザーにデータベース全体へのアクセスを許可することができます。
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

暗号化

データはネットワーク経由で送信されるため、いわゆる "中間者" 攻撃によって傍受される可能性があります。これを防ぐために、Azure Database for MySQL、Azure Database for MariaDB、Azure Database for PostgreSQL では、通信を暗号化するための Secure Sockets Layer (SSL) がサポートされています。 SSL は既定で適用されるので、この設定を変更しないことを強くお勧めします。

SSL 暗号化を使用するように、クライアントアプリケーションの接続設定を修正することが必要な場合があります。このトピックについて開発者と話し合い、必要な変更 (ある場合) を決定します。

監視と管理

データベースの移行計画の一環として、データベース管理者が移行後も引き続き業務を行う方法を検討します。

監視

オンプレミスのデータベース管理者は、ハードウェアのボトルネックやネットワークアクセスの競合などの問題を特定するために、定期的に監視することに慣れています。管理者は、生産性に影響する前に問題を修正できるように監視しています。定期的に監視されていないデータベースでは、遅かれ早かれ問題が発生し始めることが予想されます。

クラウドデータベースにもまったく同じアプローチを採用する必要があります。 Azure のような PaaS システムでは、ハードウェアを購入、セットアップ、構成しなくてもリソースを追加できるため、問題をより簡単に解決できます。ただし、開発時の問題を特定する必要があるため、日常業務の中で監視の優先度が高くなります。

データベースをクラウドに移行する前に、管理者が現在使用している監視ツールを確認します。これらのツールに提案されているクラウドベースのソリューションとの互換性があれば、移行されたデータベースにそれらを再接続するだけで済みます。そうでない場合は、代替ツールを調べる必要があります。

Azure には、一連のパフォーマンス監視ツールが含まれており、さまざまなパフォーマンスカウンターとログデータが収集されることに注意してください。 Azure Monitor を構成することにより、Azure portal のダッシュボードとグラフを使用してこのデータを表示します。管理者のニーズに合わせて特別に設計されたカスタムのグラフ、テーブル、レポートを作成します。

管理

データベース管理者は、推奨ツールを使用して、オンプレミスのデータベースのスキーマと内容を変更しています。管理者が移行後も同じツールを使用すると、その専門知識から引き続きメリットが得られます。まず、既存のツールセットが、提案されているクラウドホスト型データベースと互換性があるかどうかを評価します。多くのツールは SQL などの広く採用されている標準に基づいているため、互換性がありますが、その互換性を確認することが重要です。移行後に現在の管理ツールが機能しない場合は、管理者と一緒に代替ツールの特定に努めてください。

Azure には、MySQL、MariaDB、PostgreSQL の各データベースを管理するために使用できるツールがいくつかあります。

Azure portal。この Web サイトには、データベース、および Azure クラウドで作成する可能性のある他のすべてのリソースの構成、監視、管理に使用する強力な機能があります。
Azure PowerShell。これは、幅広いコマンドを備えたスクリプト実行環境およびスクリプト言語です。 Windows および Linux 環境で使用可能な PowerShell を使用して、複雑なデータベース管理タスクを自動化します。
Azure CLI。これは、Azure のコマンドラインインターフェイスです。これを使用して、Azure のサービスとリソースを管理します。 CLI は、Windows と Linux のシェル環境、および Bash スクリプト内から使用できます。

続行