本文書はシステムをガバメントクラウドに構築・移行する際に必要となるプロセスにおいて、データベース移行を検討する際の考慮事項を整理した文書である。 # マネージドサービスへの移行データベース機能をマネージドサービスに置き換える場合のノウハウを下記に記載する。データベースのマネージドサービス化は、必須で検討し、阻害要因が無い限り適用を推奨すること。 ## サービス選択データベースの変更はアプリケーションへの影響が大きいため、以下のノウハウを参考に可能な限り実現すること。 Azureでは複数のマネージドデータベースサービスを提供しており、データベースに格納するデータの保管形態に合わせて選択することが可能である。利用するデータベースは以下を参考に選択する。 **表01: マネージドデータベースサービスの選択** | Azure サービス | サポートされるDBタイプ | 拡張性 | | --- | --- | --- | | Azure SQL Database | SQL Server | 自動スケーリング、動的スケーリング
レプリケーションの作成 | | Azure Database for PostgreSQL - フレキシブルサーバー | PostgreSQL | コンピューティングレベル、IOPSの手動スケールアップ/スケールダウン
ストレージの自動拡張
レプリケーションの作成 | | Azure Database for MySQL - フレキシブルサーバー | MySQL | コンピューティングレベルの手動スケールアップ/スケールダウン
IOPS の自動スケーリング
ストレージの自動拡張
レプリケーションの作成| | Azure Cosmos DB | NoSQL、PostgreSQL、
MongoDB、Apache Cassandra、
Apache Gremlin、Table | 自動スケーリング | 多くの選択肢から最適なデータベースサービスを選ぶことになるが、移行元システムと同一のデータベースの利用と言った現行踏襲を大前提にするのではなく、運用要件、コスト、メンテナンス性を考慮したうえで選択することが望ましい。特にこれまでのリレーショナルデータベースのみを選択するのではなく、業務およびデータの特性に応じて非リレーショナル型のデータベースを選択することで、性能面でのメリットやリレーショナルデータベースの制約にとらわれない利用が可能となる。 ## データベース製品固有機能の扱いデータベースは製品ごとに固有の機能を提供しており、Azure Database等のマネージドサービスに移行する際に考慮が必要となる。この場合、移行時の選択肢としては3つとなるため、利用機能を事前に整理し、移行方針を定義することでスムーズな移行が期待できる。 **表:02 データベース製品固有機能の移行方針** | 移行方針 | 概要 | 固有機能の検討例 | | --- | --- | --- | | 同等機能利用 | 移行先データベースでも同等の機能が提供されており、それを利用する | 監査機能（移行先データベースの監査機能を利用） | | 代替機能利用| 移行先データベースに同等の機能はないが、類似した機能で代替する | バックアップ（データベース製品固有機能からマネージドサービス利用に変更） | | 廃止 | 移行先データベースに機能提供がないため、利用を取りやめる | 結果キャッシュ（バッファキャッシュがあるため、結果キャッシュ自体は廃止する） | データベースの「代替機能利⽤」を検討する場合、以下のマネージドサービスに切り替えることでカバーすることが可能となるため、代替可能かを検討する。 **表:03 データベースの主な管理・運用項目** | 管理・運用機能 | 従来の利用機能例 | マネージドサービスでの利用例 | | --- | --- | --- | | バックアップ | DBMSが提供するネイティブ機能 | 各Azureサービスのバックアップ機能 / Azure Backup | | 障害監視 | エージェントベースの障害監視製品 | Azure Monitor 製品群 | | 性能監視 | エージェントベースの性能監視製品 | Azure Monitor 製品群 / 各Azure サービスの性能監視機能 | | アクセス監査 | DBMSが提供する監査機能 | Azure Monitor 製品群 | | イベント監視 | エージェントベースの障害監視製品 | Azure Monitor 製品群 | | キャパシティ管理 | エージェントベースの性能監視製品 | Azure Monitor 製品群 | | メンテナンス | 手動パッチ適用、もしくは適用凍結 | メンテナンスウィンドウによる自動適用 | # 可用性データベース可用性に関するノウハウを下記に記載する。可用性を向上させる手段はいくつか存在するが、Azureではシステム要件に合わせ、大きく3つの手段で可用性を高めることを推奨している。 - ローカル冗長構成同一可用性ゾーン内でシステムを構成し、主にハードウェア部品レベルの冗長化による可用性を実装する構成 - マルチゾーン構成同一リージョン内の複数の可用性ゾーンでシステムを構成し、可用性ゾーンレベルでの障害に備える構成 - マルチリージョン構成 2つ以上のリージョンでシステムを構成し、リージョンレベルでの障害に備える構成 ## リージョン内の可用性 ### マルチゾーン構成リージョン内で可用性を向上させる場合、高可用性構成を取ることで単一障害点を防ぎ、データベースインスタンスや可用性ゾーンにおける障害発生時にリソースの使用を継続することが可能となる。可用性向上のための構成には高可用性オプションの有効化を検討する。高可用性オプションを有効にするとリージョン内の複数の可用性ゾーンでプライマリサーバーとスタンバイサーバーが構成される。各可用性ゾーン間は同期レプリケーションにより同期され、プライマリゾーンで障害発生した場合にはスタンバイサーバーが新しいプライマリサーバーとして昇格する。 ## 複数リージョンの可用性 ### マルチリージョン構成リージョンの停止など前節の可用性対策では対応できないケースに備えて、複数のリージョン間で冗長するシステム構成も検討する。リージョン間でデータの複製やアーカイブを実施することで、リージョンの停止やデータ損失が発生した場合に障害復旧を可能にする。レプリケーションを使用すると、レプリケーションの遅延で少量のデータ損失が発生する可能性があるが、レプリケーションされたリージョンのストレージシステムに最新のデータが保存されているため、復旧時間を短縮できる。マルチリージョン構成のデメリットとして、読み込みレイテンシーは低くなるが書き込みレイテンシーは高くなる、コストが高い、ということが挙げられるため、要件の中でトレードオフをとり必要な構成を検討する。 **表:04 マルチリージョン構成が可能なデータベースサービス** | サービス名 | 構成方法 | 主な制約事項 | | --- | --- | --- | | Azure SQL database | Geo レプリケーションもしくは
自動フェールオーバーグループを構成することで実現 | 特になし | | Azure Database for PostgreSQL - フレキシブルサーバー | Geo レプリケーションを構成することで実現 | [考慮事項](https://learn.microsoft.com/ja-jp/azure/postgresql/flexible-server/concepts-read-replicas#considerations) | | Azure Database for MYSQL | Geo レプリケーションを構成することで実現 | [考慮事項と制限事項](https://learn.microsoft.com/ja-jp/azure/mysql/flexible-server/concepts-read-replicas#considerations-and-limitations) | | Azure Cosmos DB | データをグローバルにレプリケートすることで実現
(複数の書き込みリージョンの構成も可能) | 特になし | | Azure Cache for Redis | Geo レプリケーションを構成することで実現 |[geo レプリケーションの前提条件](https://learn.microsoft.com/ja-jp/azure/azure-cache-for-redis/cache-how-to-geo-replication#geo-replication-prerequisites)| ### 災害対策データベースの災害対策を検討する場合、RPO/RTOから構成を検討する必要がある。 **表:05 各DBサービスのRPO/RTO** | サービス | 公式ドキュメント | | --- | --- | | Azure SQL Database | [Azure SQL Database によるビジネス継続性の概要](https://learn.microsoft.com/ja-jp/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview?view=azuresql) | | Azure Database for PostgreSQL - フレキシブルサーバー | [Azure Database for PostgreSQL - フレキシブルサーバーでのビジネス継続性の概要](https://learn.microsoft.com/ja-jp/azure/postgresql/flexible-server/concepts-business-continuity) | | Azure Database for MySQL - フレキシブルサーバー | [Azure Database for MySQL - フレキシブルサーバーでのビジネス継続性の概要](https://learn.microsoft.com/ja-jp/azure/mysql/flexible-server/concepts-business-continuity) | | Azure Cosmos DB | [Azure Cosmos DB を使用して高可用性を実現する](https://learn.microsoft.com/ja-jp/azure/cosmos-db/high-availability) | # 拡張性 Azureでは要求する性能・容量に合わせて順次リソースを拡張することが可能となる。リソースの拡張は手動・自動の二種類があるが、より柔軟かつ負荷の低い運用を行うため、できるだけ自動的なリソース調整機能やサーバレスサービスを利用することを検討する。また、1つのデータベースにすべてのデータを集約するのではなく、機能要件や処理形態に合わせて最適なデータベースを利用するため、機能の分割を検討する。 ## スケーリングリソースを拡張・縮⼩する場合、以下について検討する。 **表:06 リソーススケーリング時の考慮事項** | 考慮項目 | 考慮事項 | 対象サービス | | --- | --- | --- | | インスタンスタイプ・サイズ | インスタンスタイプやサイズを変更することで、データベースインスタンスのCPU、
メモリおよびネットワーク帯域を変更することが可能となる。
インスタンスタイプやサイズの変更は手動操作が必要となり、負荷状況による自動的な変更はできない。 | Azure SQL Database
Azure Database for PostgreSQL - フレキシブルサーバー
Azure Database for MySQL - フレキシブルサーバー
Azure Cache for Redis| | ストレージサイズ | データを保管するストレージサイズは自動スケーリング機能を有効にすることで、必要な領域を自動的に拡張し、
利用分だけのコスト発生に抑えることが可能となる。自動スケールアップされたストレージは、スケールダウンできない。 | Azure SQL Database
Azure Database for PostgreSQL - フレキシブルサーバー
Azure Database for MySQL - フレキシブルサーバー| | 要求ユニット | データベースまたはコンテナーのスループット (RU/秒) を自動的にスケーリングできる。 | Azure Cosmos DB
Azure SQL Database | | I/O性能(キャパシティ) | データの読み書きの性能に対し、最大となる値を増やすことでI/O性能を増加させることが可能となる。 | Azure SQL Database
Azure Database for PostgreSQL - フレキシブルサーバー
Azure Database for MySQL - フレキシブルサーバー| ## 機能分割 1つの大きなSQL処理がリソースを占有している、処理遅延が継続的に発生している等、データベースエンジンに過度な負荷がかかっている場合、リソースを拡張するのではなく、以下を検討する。 - データベース分割 - 例えば１つのデータベースエンジンでOLTP処理とOLAP処理を行っている場合、処理形態ごとにデータベースを分割することでそれぞれの性能が向上し、かつ個々に必要なリソースが最適化されることでコストダウンを図ることが可能となる。 - OLTP処理はデータベースサービスを用いることがほとんどであるが、リレーショナルデータベースとしての機能が必要なデータと、それ以外のデータの格納先を分けることで機能を分割することが可能である。 - また、OLAP処理はAzure Analysis Services等、BIを得意とするサービスに切り替えることでより大規模な処理に合わせた利用が可能となる。 - OLTPとOLAPを分割するパターンはイベントソーシングモデルを用いることで小さな遅延で同期を図ることができる。詳細は下記URLを参照とする。 [CQRS パターン](https://learn.microsoft.com/ja-jp/azure/architecture/patterns/cqrs) - キャッシュの追加 - データベースの読み込みに処理待ちが見られる場合、データベースエンジンの前にAzure Cache for Redis等のインメモリキャッシュを置き、読み込み処理を分散させることでデータベース全体の負荷を下げることが可能となる。 - 特にマスタデータ等、多数の読み込み処理要求があるテーブルに対しては有効である。 - キューイング処理の追加 - 書き込み処理に処理待ちが見られる場合、処理形態に依存はするが、Azure Service Bus等のキューイング処理を追加することでデータベースに対する書き込み処理を非同期化し、負荷を平準化させることが可能となる。 - 利用者に対して即時で処理結果を返す必要がないものや、バッチ処理についてはキューを用いた順次処理を行うことで、不必要にインスタンスタイプ、サイズを大きなものにすることを避けることが可能となる。 - リードレプリカの活用 - 読み取り専用のレプリカであるリードレプリカサーバーを追加し、読み取りのみで完結するリクエストについてはレプリカを参照させることでプライマリのデータベースのリソースを拡張することなく読み取り性能をスケールアウトさせることが可能となる。 # 運用データベース運用に関するノウハウを下記に記載する。 ## 定期運用処理マネージドサービスとして稼働するデータベースを運用する場合、以下の運用形態の変更に注意したうえで運用設計・実装を行う。 ### 運用スクリプトの扱いマネージドサービスでは一部のデータベースエンジンが提供するオプションを除き、データベースインスタンスローカルでのスクリプトの実行、DBAタスクの実行およびOS領域へのアクセスはできない。ただし、スクリプト等で作り込まれている多くの機能はマネージドサービスに置き換えることが可能となるため、上述の「データベース製品固有機能の扱い」の記載に準じた置き換えを行い、それ以外の機能について切り替え方針を個別で検討する。 **表:07 個別検討が必要な例** | 検討例 | 対応の一例 | | --- | --- | | データ抽出機能 | 他システムに対する連携や、DWHへのデータ登録等に関連するデータ抽出機能についてはData FactoryのようなETLサービスを用いた抽出を行い、連携する。
運用担当者が利用するために定期的に出力が必要なデータについてはEvent GridからAzure Functions等の関数を定期的に呼び出し、Blob Storageに保管するような作りに変更する。 | | ユーザーが起動するオンラインバッチ機能 | ユーザーが業務目的で実行する業務中の個別バッチ機能に関しては、スクリプトではなくアプリケーション化し、アプリケーションからの実行方式に切り替える。 | ## メンテナンス ### メンテナンス・アップデートに関する考え方マネージドサービスでは一部のパッチ適用操作を除き、アップデートのリリース後、順次最新機能や不具合修正が反映される。従来のパッチ適用やバージョンアップの凍結は基本できなくなるため、メンテナンスウィンドウの確保やアップデート適用時のテストの効率化について併せて検討をする。 - メンテナンスウィンドウの確保について - いくつかのマネージドサービスでは、パッチ適用のためのメンテナンスウィンドウの時間帯を設定する機能が提供されている。時間帯を設定することで、システムの開放時間帯以外でパッチが適用され、業務影響を極小化することが可能となる。 - テストの効率化について - データベースのパッチ適用等の変更に伴い、利用者への開放前に動作確認を含むテストを行うケースが多々あるが、これらも1)ステージング環境で入念な動作確認を行い、本番環境へのパッチ適用時には接続確認に留める、2) 本番データベースの複製をクローニング機能で作成し、複製に対する動作確認で代用する、等の対応を行うことで利用者への開放時間を短縮することが可能となる。 **表:08 主要サービスのアップデート・バージョンアップ適用の挙動** | サービス | アップデート種別| 業務影響への低減策例 | | --- | --- | ---| | Azure SQL Database | メンテナンス | 可⽤性 SLA 内で短時間の再構成が⾏われる可能性がある、互換性バージョンを指定しての接続 | | Azure Database for PostgreSQL - フレキシブルサーバー | メジャーバージョンアップ | 検証環境でのダウンタイム時間確認、テストによる不具合回避、Active-Standby構成によるダウンタイム低減 | || マイナーアップデート | 自動的にアップデートされるため、考慮点は特になし | || メンテナンス | 検証環境でのダウンタイム時間確認、テストによる不具合回避、Active-Standby構成によるダウンタイム低減 | | Azure Database for MySQL | メジャーバージョンアップ | 検証環境でのダウンタイム時間確認、テストによる不具合回避、Active-Standby構成によるダウンタイム低減 | || マイナーアップデート | 自動的にアップデートされるため、考慮点は特になし | || メンテナンス | 検証環境でのダウンタイム時間確認、テストによる不具合回避、Active-Standby構成によるダウンタイム低減 | | Azure Cache for Redis | 全てのアップデート | テストによる不具合回避、クラスタ構成によるダウンタイム低減 | | Azure CosmosDB | レプリカのメンテナンス | 自動的にアップデートされるため、考慮点は特になし | # データ移行データベース内で保管しているデータの移行に関するノウハウを下記に記載する。データ移行を検討する際には、切替時の停止許容時間、および移行対象データ量から方式を検討することで最適化を図ることが可能となる。 ## 切替時の停止許容時間多くのシステムは新システムに切り替えるタイミングでのダウンタイム（停止時間）を極小化する必要がある。そのため、ダウンタイムを考慮したデータの移行が必要となる。移行ツールの使い方にてデータの移行時に利用可能なツールについて記載しているが、Azureが提供するツール以外の機能を用いた方法を停止許容時間から選択することで、コスト面や手順の簡素化などに効果を出すことが可能となる。ダウンタイムをゼロにすることは非現実的であるが、ダウンタイムを最小化してほぼゼロにすることはできる。 ## データ転送方式移行対象となるデータ量から適切なデータ転送方式を選択することで、移行時間の短縮や、コストの最適化が可能となる。また、伝送でデータ移行を行う場合は利用可能なネットワークの帯域によっても移行にかかる時間が変動するため、事前の性能試験が重要となる。 ## 移行ツールの使い方 Azureでは既存のデータベースからガバメントクラウド上に構築するデータベースへの移行のためのツールが複数用意されている。以下にツールの特徴および活用可能なケースを記載する。なお、いずれのツールの場合も移行元環境および移行先環境をネットワークで接続する必要があるため、システムの制約等によりネットワーク経路の確保が難しい場合は、データベースエンジンが提供するダンプツールやCSV出力を含む広い方式から検討を行い、ネットワークが分離された状態でのデータ移行が可能な方式を選定する。 ### Azure Database Migration Service Azure Database Migration Service（以下「DMS」）は移行元のデータベースからデータを抽出し、移行先のデータベースにデータを登録するためのサービスとなる。 Microsoft SQL Server等の商用データベースおよびPostgreSQL、MySQL等のオープンソースデータベースを移行元のデータベースに指定することが可能となる。サポートするデータベース製品およびに関しては下記URLを参照とする。 [サポートされる移行シナリオ](https://learn.microsoft.com/ja-jp/azure/dms/resource-scenario-status#supported-migration-scenarios) 各データベース毎のDMSの利用方法に関しては下記URLを参照とする。 [Azure Database Migration Service のドキュメント](https://learn.microsoft.com/ja-jp/azure/dms/) ### Azure Data Factory Azure Data Factory はAzureが提供するETLツールであり、データを様々な形に変換したうえで移行先のデータベースに登録することが可能となる。Azure Data Factory もDMSと同様に複数のオンプレミスデータベースエンジンをサポートしているため、データベースのリファクタリング等で大幅にテーブルレイアウトが変わる場合や、テーブル統合による集約を行う際の移行ツールとして用いることが可能となる。 Azure Data Factoryによるデータベース（Azure SQL Server）の移行例に関しては下記URLを参照とする。 [Azure Data Factory を使用して SQL Server データベースから SQL Database にデータを移動する](https://learn.microsoft.com/ja-jp/azure/architecture/data-science-process/move-sql-azure-adf) ### レプリケーション機能を使う DB移行前と移行後において、DBのスキーマ・データ値が同じであり直接マッピングされる場合はレプリケーション機能の使用を検討する。この場合、データベース管理システム内の機能を使用し、データベースを別のデータベースに複製できる。レプリケーションでは完全なコピーのみが作成されるため、データの変更は行われない。データの変更が必要な場合や直接マッピングではないデータ移行の場合は上述のDMSを利用する。 ### カスタムデータベース移行機能を構築するデータベース移行システムやデータベース管理システムの機能を使用する代わりに、データベース移行機能を構築する理由には以下が挙げられる。 - あらゆる個所を完全に制御する必要がある場合 - 機能を再利用したい場合 - コストの削減や、技術的なフットプリントの簡素化を行いたい場合移行機能を構築する構成要素として、以下を検討する。 - エクスポート / インポート同種のDBスキーマでデータベース移行を実施しダウンタイムが問題にならない場合は、データベースのエクスポート / インポートを使用してデータ移行ができる。ただし、エクスポート / インポートでは、データをエクスポートする前に移行元データベースを停止して更新を止める必要がある。これを実施しない場合、変更がエクスポートに反映される、移行先データベースが移行元の完全なコピーにならない場合がある。 - バックアップ / 復元エクスポート / インポートの場合と同様に、バックアップに全データの最新の変更を含めるために移行元データベースを停止する必要があるため、バックアップ / 復元ではダウンタイムが発生する。このダウンタイムは、移行先データベースで復元が正常に完了するまで続く。 - 差分クエリデータベーススキーマを変更できる場合に、スキーマを拡張して、クエリインターフェースでデータベースの変更を照会できるようにすることができる。この場合、最後の変更時刻を示す追加のタイムスタンプ属性が付与される。追加の削除フラグを加えて、データ項目が削除されたかどうかを表すことも可能となる。これら2つの変更を加えることで、一定間隔で実行されるポーラーで、最後にポーラーが実行された時点以降のすべての変更をクエリできる。これらの変更はすべて移行先データベースに適用される。 ## データ転送の経路移行対象となるデータ量・移行時間(停止時間)コストを考慮し、適切なデータ転送方式を選択する。移行ツールを用いてデータ転送を行う場合、以下が主な通信経路となる。 **表:09 データ転送経路** | 転送種別 | 利用するネットワーク | 概要 | 利用可能なAzure提供サービス | | --- | --- | --- | --- | | 伝送 | Express Route（専用線） | 政府ネットワーク等、内部ネットワークからAzureに対して接続されている
専用線サービスを用いたネットワーク経由による伝送方式 | Azure Database Migration Service
Azure Data Studio
Azure Data Factory | | 伝送 | VPN等、インターネット回線 | VPN等の技術によりセキュアな状態を確保したインターネット回線からAzureに対してデータの転送を行う方式 | Azure Database Migration Service
Azure Data Studio
Azure Data Factory | | 物理搬送 | なし | データ搬送のための専用デバイスを用いて、輸送によりデータ物理的に配送する方式 | Azure Data Box
Azure Data Box Heavy
Azure Data Box Disk | ## 第1期政府共通プラットフォーム（第1期PF）からのデータ移行の注意点第1期 PF からデータ移行を実施する場合、第1期PFのDBセグメントは外部につながるサーバを設置するのが、ポリシー上不可である場合があり、データの移行元となる DB サーバがある NW セグメントから、ガバメントクラウド上の移行先 DB への通信が可能であるかは確認が必要である。特に、データ移行ツールとして、DMS を利用する場合には、DMS を介した移行元 DB と移行先 DB の通信が必要となるため、注意が必要である。また、第1期 PF の NW セグメントからの通信が難しい場合は、第1期PF の DMZ セグメントにデータ移行用のサーバを構築する代替案が考えられるが、サーバ用のリソースの確保など第1期 PF との調整に必要な準備期間を想定しておく必要がある。データ転送経路として Azure Data Box を選択した場合、移行対象データを取得するために第1期 PF のデータセンタへの立ち入り作業が必要である。第1期 PF のデータセンタへ立ち入り可能な時間には制約があり、その制約を考慮した上で、早めにスケジュールの調整を行う必要がある。 ## 改訂履歴 | 改訂年月日 | 改訂理由 | | ------------------- | -------- | | 2023 年 12 月 22 日 | 新規作成 | | 2024 年 03 月 29 日 | 表記揺れの修正 | | 2024 年 10月 31 日 | 表記揺れの修正 |

Replatformシステム移行ノウハウ（RDBのマネージドサービス化）(Azure編)