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

本文書はシステムをガバメントクラウドに構築・移行する際に必要となるプロセスにおいて、データベース移行を検討する際の考慮事項を整理した文書である。

マネージドサービスへの移行

データベース機能をマネージドサービスに置き換える場合のノウハウを下記に記載する。
データベースのマネージドサービス化は、必須で検討し、阻害要因が無い限り適用を推奨すること。

サービス選択

データベースの変更はアプリケーションへの影響が大きいため、以下のノウハウを参考に可能な限り実現すること。
AWSでは複数のマネージドデータベースサービスを提供しており、データベースに格納するデータの保管形態に合わせて選択することが可能である。
下記のフローチャートに沿って利用するデータベースのサービスを選択する。

図:1 データベースサービスの選択フロー

EC2への導入を含め、多くの選択肢から最適なデータベースサービスを選ぶことになるが、移行元システムと同一のデータベースの利用と言った現行踏襲を大前提にするのではなく、運用要件、コスト、メンテナンス性を考慮したうえで選択することが望ましい。
特にこれまでのリレーショナルデータベースのみを選択するのではなく、業務およびデータの特性に応じて非リレーショナル型のデータベースを選択することで、性能面でのメリットやリレーショナルデータベースの制約にとらわれない利用が可能となる。

データベース製品固有機能の扱い

データベースは製品ごとに固有の機能を提供しており、RDS等のマネージドサービスに移行する際に考慮が必要となる。この場合、移行時の選択肢としては3つとなるため、利用機能を事前に整理し、移行方針を定義することでスムーズな移行が期待できる。

表:1 データベース製品固有機能の移行方針

データベースの「代替機能利用」を検討する場合、以下のマネージドサービスに切り替えることでカバーすることが可能となるため、代替可能かを検討する。

表:2 データベースの主な管理・運用項目

可用性

データベース可用性に関するノウハウを下記に記載する。

可用性を向上させる手段はいくつか存在するが、AWSではシステム要件に合わせ、大きく3つの手段で可用性を高めることを推奨している。
① Single-AZ構成 - 1つのアベイラビリティゾーン（データセンタ）にてシステムを構成し、主にハードウェア部品レベルの冗長化による可用性を実装する構成
② Multi-AZ構成 - 2つ以上のアベイラビリティゾーンにてシステムを構成し、データセンタレベルでの障害に備える構成
③ Multi-Region構成 - 2つ以上のリージョンにてシステムを構成し、リージョンレベルでの障害に備える構成

図:2 可用性の確保方法

リージョン内の可用性

マルチAZ構成

可用性を向上させる場合、AWSではマルチAZ構成をとることでデータベースインスタンス、およびアベイラビリティーゾーンレベルの障害発生時でも稼働を継続させることが可能となる。可用性の向上のための構成は以下の2つの方式から選択する。

• アベイラビリティーゾーン間でActive-Standby構成を組む
  • この構成の場合、2つのデータベースインスタンスを用意し、片方をスタンバイインスタンスとすることで変更のレプリケーションを行い、アクティブインスタンスの障害発生時にスタンバイ側に切り替えを行う。
  • RDSではすべてのデータベースエンジンで構成が可能となる。
• Multi-AZ DB Cluster構成を組む
  • この構成の場合、ライターインスタンスとは別に、2つのリードレプリカに対してレプリケーションを行い、ライターインスタンスの障害発生時にはいずれかのリードレプリカをライターインスタンスに昇格させることで切り替える。
  • RDSではMySQLおよびPostgreSQLにて構成が可能となる。
  • なお、Amazon Auroraも同様の挙動となる。

　
RDS以外のデータベースサービスの可用性に関してはマネージドサービスとしてマルチAZ構成となっているサービス、もしくはRDSと同様にクラスタ構成を組むことが可能なサービスに分かれる。

表:3 RDS以外のデータベースサービスの可用性

複数リージョンの可用性

マルチリージョン構成

例として、東京および大阪の2つのリージョンを用いた可用性を確保する場合は以下となる。

Amazon Auroraをデータベースエンジンとして利用する場合、Global Database機能によるマルチリージョン構成が可能となる。
これは一時点ではどちらかのリージョン内のデータベースインスタンスがライターインスタンスとなり、他リージョンのデータベースインスタンスに対してレプリケーションを行うことで実現する。
ライターインスタンスに障害が発生した場合、他方のリージョンに対してフェイルオーバーを行うことで、短いRTOを実現することが可能であるが、データベース以外についても合わせてリージョン間でフェイルオーバーする仕組みを考慮する必要がある。
また、Global Database機能を利用する場合、Aurora MySQLが提供するマルチマスターや、Aurora PostgreSQLが提供するクラスターキャッシュが利用できなくなる等、制約が存在するため、機能・非機能要件に照らし合わせて構成を検討する必要がある。
同様にAmazon RDSでもクロスリージョンリードレプリカ機能により、複数のリージョンにリードレプリカを配置し、複数リージョン構成をすることが可能であるが、RDS for SQL Serverのみ、本機能が提供されていない。

Amazon DynamoDBの場合はGlobal Tables機能にて複数リージョンにて読み込み・書き込みが可能な構成をとることが可能である。

マルチリージョン構成を取ることが可能なデータベースサービスは以下となる。
なお、すべてのリージョンですべてのデータベースサービスが提供されていない可能性があるため、下記のURLからサービス提供状況を確認のうえ、構成を検討する。
https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/open_in_newOpens in new tab

表:4 マルチリージョン構成が可能なデータベースサービス

災害対策

データベースの災害対策を検討する場合、RPO/RTOから構成を検討する必要がある。
大きくは下記の4つのレベルのうちどれに該当するかで災害対策構成が変わる。

図:3 災害対策の構成例

表:5 災害対策レベルと必要なサービス例

拡張性

AWSでは要求する性能・容量に合わせて順次リソースを拡張することが可能となる。
リソースの拡張は手動・自動の二種類があるが、より柔軟かつ負荷の低い運用を行うため、できるだけ自動的なリソース調整機能やサーバレスサービスを利用することを検討する。
また、1つのデータベースにすべてのデータを集約するのではなく、機能要件や処理形態に合わせて最適なデータベースを利用するため、機能の分割を検討する。

スケーリング

リソースを拡張・縮小する場合、以下について検討する。

表:6 リソーススケーリング時の考慮事項

Auroraを利用する場合、リードレプリカを利用したオートスケーリング以外に、Aurora Serverless (V2）を用いた垂直スケーリングを行う方法もある。これは、ワークロードの負荷に法則性がなく、急激な負荷の増減がある場合にAuroraインスタンスに必要なリソースをユーザが気にすることなく、自動的に配分してくれる機能となる。一方で、コストに関しては通常のAuroraインスタンスに比べ、約5倍となるため、24時間一定以上のトランザクションが発生するシステムには向かず、日中帯は一定の負荷はあるものの、それ以外の時間の負荷は高くないが、24時間利用可能なシステムの場合に利用を検討する。
それ以外にも、平常時は利用されないが、例えば災害発生時にのみ利用されるシステムのような、停止は出来ず、かつ急激な負荷が発生するような使われ方、決まったアクセス元がなく、不特定多数のアプリケーションから処理要求が来るような使われ方の場合にコスト、運用面でのメリットを享受すること可能となる。
また、リードレプリカのみ等、クラスタ全体のうち一部のみをAurora Serverlessで構成することも可能となるため、読み取り処理のみ急激な負荷の変動があるようなケースでも適用は可能である。

機能分割

1つの大きなSQL処理がリソースを占有している、処理遅延が継続的に発生している等、データベースエンジンに過度な負荷がかかっている場合、リソースを拡張するのではなく、以下を検討する。

• データベース分割
  • 例えば１つのデータベースエンジンでOLTP処理とOLAP処理を行っている場合、処理形態ごとにデータベースを分割することでそれぞれの性能が向上し、かつ個々に必要なリソースが最適化されることでコストダウンを図ることが可能となる。
  • OLTP処理はRDSを始めとするデータベースサービスを用いることがほとんどであるが、リレーショナルデータベースとしての機能が必要なデータと、それ以外のデータの格納先を分けることで機能を分割することが可能である。
  • また、OLAP処理はRedshiftやLakeFormation等、BIを得意とするサービスに切り替えることでより大規模な処理に合わせた利用が可能となる。
• キャッシュの追加
  • データベースの読み込みに処理待ちが見られる場合、データベースエンジンの前にElastiCacheやMemoryDB等のインメモリキャッシュを置き、読み込み処理を分散させることでデータベース全体の負荷を下げることが可能となる。
  • 特にマスタデータ等、多数の読み込み処理要求があるテーブルに対しては有効である。
• キューイング処理の追加
  • 書き込み処理に処理待ちが見られる場合、処理形態に依存はするが、SQS等のキューイング処理を追加することでデータベースに対する書き込み処理を非同期化し、負荷を平準化させることが可能となる。
  • 利用者に対して即時で処理結果を返す必要がないものや、バッチ処理についてはキューを用いた順次処理を行うことで、不必要にインスタンスタイプ、サイズを大きなものにすることを避けることが可能となる。

運用

データベース運用に関するノウハウを下記に記載する。

定期運用処理

マネージドサービスとして稼働するデータベースを運用する場合、以下の運用形態の変更に注意したうえで運用設計・実装を行う。

運用スクリプトの扱い

マネージドサービスでは一部のデータベースエンジンが提供するオプション(※1/※2)を除き、データベースインスタンスローカルでのスクリプトの実行、DBAタスクの実行およびOS領域へのアクセスはできない。
ただし、スクリプト等で作り込まれている多くの機能はマネージドサービスに置き換えることが可能となるため、上述の「データベース製品固有機能の扱い」に記載に準じた置き換えを行い、それ以外の機能について切り替え方針を個別で検討する。
RDS Custom for Oracle等の利用であればOS領域へのアクセスが可能となり、ローカルへのスクリプト配置および実行が可能となるが、ライセンスの持ち込み（BYOL）が必要となるため、コスト面および必要性に関する検討が必要となる。

※1: https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Misc.htmlopen_in_newOpens in new tab
※2: https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.htmlopen_in_newOpens in new tab

表:7 個別検討が必要な例

メンテナンス

メンテナンス・アップデートに関する考え方

マネージドサービスでは一部のパッチ適用操作を除き、アップデートのリリース後、順次最新機能や不具合修正が反映される。
従来のパッチ適用やバージョンアップの凍結は基本できなくなるため、メンテナンスウィンドウの確保やアップデート適用時のテストの効率化について合わせて検討をする。

• メンテナンスウィンドウの確保について
  • RDSを含むいくつかのマネージドサービスでは、パッチ適用のためのメンテナンスウィンドウの時間帯を設定する機能が提供されている。時間帯を設定することで、システムの開放時間帯以外でパッチが適用され、業務影響を極小化することが可能となる。
• テストの効率化について
  • データベースのパッチ適用等の変更に伴い、利用者への開放前に動作確認を含むテストを行うケースが多々あるが、これらも1) ステージング環境で入念な動作確認を行い、本番環境へのパッチ適用時には接続確認に留める、2) 本番データベースの複製をRDSのクローニング機能で作成し、複製に対する動作確認にで代用する、等の対応を行うことで利用者への開放時間を短縮することが可能となる。

表:8 主要サービスのアップデート・バージョンアップ適用の挙動

データ移行

データベース内で保管しているデータの移行に関するノウハウを下記に記載する。
データ移行を検討する際には、切替時の停止許容時間、および移行対象データ量から方式を検討することで最適化を図ることが可能となる。

切替時の停止許容時間

多くのシステムは新システムに切り替えるタイミングでのダウンタイム（停止時間）を極小化する必要がある。
そのため、ダウンタイムを考慮したデータの移行が必要となる。移行ツールの使い方にてデータの移行時に利用可能なツールについて記載しているが、AWSが提供するツール以外の機能を用いた方法を停止許容時間から選択することで、コスト面や手順の簡素化などに効果を出すことが可能となる。

表:9 停止許容時間と利用可能なツール例

データ転送方式

移行対象となるデータ量から適切なデータ転送方式を選択することで、移行時間の短縮や、コストの最適化が可能となる。
また、伝送でデータ移行を行う場合は利用可能なネットワークの帯域によっても移行にかかる時間が変動するため、事前の性能試験が重要となる。

表:10 移行対象データ量と利用可能なデータ転送方式

停止許容時間およびデータ転送方式を組み合わせた場合に利用可能なAWSサービスとしては下記となる。

図:4 データベース移行ツールの選択フロー

移行ツールの使い方

AWSでは既存のデータベースからガバメントクラウド上に構築するデータベースへの移行のためのツールが複数用意されている。
以下にツールの特徴および活用可能なケースを記載する。
なお、いずれのツールの場合も移行元環境および移行先環境をネットワークで接続する必要があるため、システムの制約等によりネットワーク経路の確保が難しい場合は、データベースエンジンが提供するダンプツールやCSV出力を含む広い方式から検討を行い、ネットワークが分離された状態でのデータ移行が可能な方式を選定する。

Database Migration Service

Database Migration Service（以下「DMS」）は移行元のデータベースからデータを抽出し、移行先のデータベースにデータを登録するためのサービスとなる。
Oracle、Microsoft SQL Server、IBM DB2等の商用データベースおよびPostgreSQL、MySQL等のオープンソースデータベースを移行元のデータベースに指定することが可能となっており、移行先のデータベースはAWSのRDSで提供するデータベースが中心となる。（サポートする製品およびバージョンについては
DMSを利用する場合には以下の要件を満たすことが可能かを確認のうえ、適用する。）
また、後述するSchema Conversion ToolをDMSに統合した、DMS Schema Conversion機能を用いてDMS内でオブジェクトの変換およびデータの移行を行うことも可能となるが、現時点では移行元データベースエンジンがSQL ServerおよびOracleの一部のバージョンに制限される。

• ネットワーク
  • ネットワーク経路
    • 移行元から移行先へのネットワーク経路が確保されていること。
  • ネットワーク帯域
    • 移行元に格納されているデータが基本すべて転送されることになるため、移行時に利用可能な帯域が確保できていること。
    • DMSは処理性能の向上（＝移行時間の短縮）のため、8並列を基本としてデータ移行が行われる。十分な帯域が確保できない場合は並列度を減らすことが必要となり、その分移行時間が長くなる。
  • 通信制御
    • DMSは移行元データベースおよびDMSインスタンスにアクセスするため、ファイアウォール等で通信対象となるポートが開放されている、もしくは開放可能なこと。
• DMS稼働環境
  • 動作環境
    • DMSはAWS上にあるDMSインスタンス、および移行元データベースが設置されているネットワーク内にDMSエージェントが導入されたサーバが必要となる。そのため、DMSエージェントおよびデータベース接続用のクライアントドライバが導入可能なLinuxサーバを用意可能なこと。
  • データベースアクセス
    • DMSエージェントから移行元データベースに、対象データベースのアクセス方式に基づいた通信が可能なこと。

サポートするデータベース製品およびバージョンに関しては下記URLを参照とする。
移行元データベース：https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.htmlopen_in_newOpens in new tab
移行先データベース：https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.htmlopen_in_newOpens in new tab

Schema Conversion Tool

Schema Conversion Tool（以下「SCT」）はデータベース移行の際にデータベースオブジェクトの定義変換を行うためのツールである。
SCTを利用することで、移行元のデータベースに作成されているDDLを抽出し、移行先のデータベースに変換したうえでオブジェクトを作成することが可能となる。
上述のDMSと組み合わせることで、DMSで抽出したデータをSCTで型変換を行ったうえで移行先データベースにデータを登録することが可能となる。
データベースオブジェクトの変換が必要な場合には、以下の要件を満たすことが可能かを確認のうえ、適用する。

• ネットワーク
  • ネットワーク経路
    • 移行元から移行先へのネットワーク経路が確保されていること。
  • 通信制御
    • SCTは移行元データベースおよびDMSインスタンスにアクセスするため、ファイアウォール等で通信対象となるポートが開放されている、もしくは開放可能なこと。
• SCT稼働環境
  • 動作環境
    • SCTは移行元データベースが設置されているネットワーク内にツールを導入するためのサーバが必要となる。そのため、SCTおよびデータベース接続用のクライアントドライバが導入可能なLinuxサーバを用意可能なこと。
  • データベースアクセス
    • SCTから移行元データベースに、対象データベースのアクセス方式に基づいた通信が可能なこと。

AWS Glue

SCTは単純な1対1の型変換を行うためのツールであるが、特定のデータに対する計算処理を行った結果を移行先のデータベースに登録する必要がある場合はAWS Glue（以下「Glue」）を利用する。GlueはAWSが提供するETLツールであり、データを様々な形に変換したうえで移行先のデータベースに登録することが可能となる。GlueもDMSと同様に複数のオンプレミスデータベースエンジンをサポートしているため、データベースのリファクタリング等で大幅にテーブルレイアウトが変わる場合や、テーブル統合による集約を行う際の移行ツールとして用いることが可能となる。
Glueは以下の要件を満たす場合に適用することが可能となる。

• ネットワーク
  • ネットワーク経路
    • 移行元から移行先へのネットワーク経路が確保されていること。
  • 通信制御
    • Glueは移行元データベースおよび移行先のデータベースにアクセスするため、ファイアウォール等で通信対象となるポートが開放されている、もしくは開放可能なこと。

データ転送の経路

移行ツールを用いてデータ転送を行う場合、以下が主な通信経路となる。

Amazon Snowball は、専用デバイスの破損の可能性を考慮した場合、予備機を一緒にオーダーすることが望ましい。予備機を一緒にオーダーする場合は、Amazon Snowball のデバイス台数の上限緩和申請(デフォルトでは、上限は 1 台)が必要となる。

表:11 データ転送経路

第1期政府共通プラットフォーム（第1期PF）からのデータ移行の注意点

第1期 PF からデータ移行を実施する場合、第1期PFのDBセグメントは外部につながるサーバを設置するのが、ポリシー上不可である場合があり、データの移行元となる DB サーバがある NW セグメントから、ガバメントクラウド上の移行先 DB への通信が可能であるかは確認が必要である。特に、データ移行ツールとして、DMS を利用する場合には、DMS を介した移行元 DB と移行先 DB の通信が必要となるため、注意が必要である。
また、第1期 PF の NW セグメントからの通信が難しい場合は、第1期PF の DMZ セグメントにデータ移行用のサーバを構築する代替案が考えられるが、サーバ用のリソースの確保など第1期 PF との調整に必要な準備期間を想定しておく必要がある。

データ転送経路として Amazon Snowball を 選択した場合、移行対象データを取得するために第1期 PF のデータセンタへの立ち入り作業が必要である。第1期 PF のデータセンタへ立ち入り可能な時間には制約があり、その制約を考慮した上で、早めにスケジュールの調整を行う必要がある。

改訂履歴