SQL Server on EC2からAmazon Aurora PostgreSQLへのデータベース更改
今回は「SQL Server on EC2からAmazon Aurora PostgreSQLへのデータベース更改」というテーマで、弊社の実際の移行事例に沿って、選定から移行までのプロセス、データベース移行の手法や移行して大変だったこと・良かったことなどについてお話ししたいと思います。
データベース移行の背景
今回の事象紹介の対象となるキャリタスUCは2009年に稼働を開始し、当初はオンプレ環境にてSQL Server 2005を使用していました。2015年にAWSに移行し、SQL Server 2012をEC2上で運用していました。
そもそもなぜSQL Serverを使っていたのかを振り返りますと、社内の他サービスでもSQL Serverを使用していたため、データ連携の観点からSQL Serverを選定しました。また、社内にSQL Serverの専門知識を持つスタッフが多く、保守・運用面でも安心して利用できる環境が整っていました。
しかし、SQL Server 2012のサポート終了と、データベース間のレプリケーションがDMSに切り替わったことから、ゼロベースで新しいデータベースを選定することになりました。
新データベース選定のポイント
新しいデータベースを選定する際の主なポイントは以下の通りです：
管理および運用の負担軽減を図るためのマネージドサービス。
全体的なコスト削減。
この観点から、「Amazon RDS for SQL Server」と「Amazon Aurora PostgreSQL」の2つが候補に挙がりました。
コスト比較を行った結果、Amazon Aurora PostgreSQLの方が長期的に見てコストパフォーマンスに優れていることが判明しました。
プラットフォームを変更することにより当然アプリケーション改修が多く入るため初期費用は高くなりますが、ランニングコストの低減が長期的には大きなメリットと考えられ、Aurora PostgreSQLへの移行を決定しました。
以下、コスト比較のポイントとコストの累積の比較です。アプリケーションの規模にもよるものですが、今回の事例であれば、４年目でコスト逆転。
また、事前にAmazon Auroraのセミナーにも参加したり情報収集したりで、色々な観点の機能性、高可用性についても選定理由となり、Auroraが望ましいということになりました。
それにプラスして、まだまだ管理面などで便利な機能が増えるんじゃないかな〜、機能拡張されるんじゃないかな～、というAWSさんへの期待、というのも選定した理由の一つになります。
データベース更改プロジェクトの主なプロセスは以下の通りです。
Aurora PostgreSQL用のテスト環境およびテーブル設計
データ移行準備およびアプリケーション改修
負荷試験と脆弱性診断、アプリケーション動作確認
データ移行を行い、新環境でサービス稼働
新データベースへのデータ移行
移行先をAmazon Aurora PostgreSQLにするということに決めまして、ここから先は実際の移行について
まずSQL ServerからAurora PostgreSQLへのデータ移行の方式についてですが、データベース移行を検討している段階から、AWS様にAuroraの勉強会を開いていただく機会がありまして、勉強会のメインはAuroraについての仕様や独自機能についてのお話だったのですが、図のような移行方式の選定フローをご助言いただきました。
図の左上から
・停止時間が十分にとれて、DBエンジンを変えないのであればダンプツール
・停止時間が十分にとれて、DBエンジンが別なのであればCSVファイルアンロード
・停止時間があまりとれず、DBエンジンを変えない、且つレプリケーション機能が使えるのであればレプリケーション、レプリケーション機能がなければDatabase Migration Service（以下DMS）
・停止時間があまりとれず、DBエンジンが別であればDMS
となります。（AWSのセミナーなどでこの図を見たことがあるという人もいるかと）
因みにCSVファイルアンロードとは、DBからファイルをエクスポートして移行先DBにインポートするというやり方です。
改めて整理しますと、
SQL ServerからAurora PostgreSQLですので、ソースとターゲットは別DBエンジン
「キャリタスUC」は、24時間365日稼働のサービスではありますが、サービス特性上、夜間/休日であれば、ある程度のサービス停止は許容されるものと考えておりまして、仮に土曜日も停止時間に含めますと、金曜の夜から月曜早朝までであれば、約50時間は確保できます。
また、DMSについては、機能の利用実績はあったのですが、SQL Server同士であって、SQL ServerからAurora PostgreSQLですと、実績がないので、若干の不安があります。
もう一度、選定フローに戻りますと
・十分な停止時間をとれる → ＜はい＞
・ソースとターゲットが同一DBエンジン → ＜いいえ＞
ということで移行方式には選定フロー通りで「CSVアンロード」を採用することにしました。
サービス停止時間がある程度確保できるとはいえ、データ移行については時間内に収めるためにスムーズに実施する必要があります。そこで、データ移行対象を以下のように分類しました。
■移行不要なテーブル
＝別サービスのAPIやレプリケーションからデータ取得するもの、一時保存用のテーブルなど
■ラージオブジェクト
＝かなりの大容量のため、専用の移行用バッチを作成し、サービス停止より前から移行を行い、サービス停止後に差分を移行する
■サービス停止前に移行可能なテーブル
＝マスタ系や過去年度用のものでデータ更新が入らないテーブル
■サービス停止後に移行するテーブル
=上記以外のテーブル
この「サービス停止後に移行するテーブル」に対して、CSVアンロード方式でデータ移行スクリプトを用意します。
アンロード方式のデータ移行スクリプトは以下の図のような動きになります。
データ移行スクリプトを実行するためのEC2インスタンスを用意し、ソースDBであるSQLServerからSqlBulkCopyでファイルエクスポート、エクスポートされたファイルを必要に応じて正常にインポートできる形式に加工して、移行先となるターゲットDBのAurora PostgreSQLにcopyコマンドでインポートします。これで約300のテーブルを一括でデータ移行します。
さらにファイル加工スクリプトを分析し高速化を図ります
・移行用EC2のインスタンスタイプを高性能なものに
・移行元DBに負荷がかかりすぎない程度に処理を多重化
・改行文字の変換を省くため、改行含むテーブルと含まないテーブルを分類
・明示的なメモリ解放
など
→本番環境DBで複数回リハーサルを行い、確保できるサービス停止時間内で十分にデータ移行が完了できることが確認できました。（安堵）
新データベースへのアプリケーション対応
つづきまして、新データベースへのアプリケーション対応についてですが、事前準備の段階で、AWSから提供されているSchema Conersion Toolを使用しました。
Schema Conersion Toolを使用して、変換元DBと変換先DBを指定することで移行評価レポートと変換されたDDLを生成することができます。
移行評価レポートは以下の図のようなものが出力されます。データベース内の各オブジェクトごとのコンバージョンの統計情報が確認できます。
Schema Conversion Tool からのレポート ①
Schema Conversion Tool からのレポート ②
元々想定はしていましたが、プロシージャーは全面的に書き換えが必要そうで、対応にかなりの工数を要するだろうということがわかります。
次にSchema Conversion Toolから生成されたDDLですが、テーブル、ビュー、ファンクション、プロシージャのDDLを生成することができます。DDLについてはコンバージョンされた箇所の指摘付きです。
アプリケーション対応のとっかかりとしては、とりあえず生成されたDDLを新しいデータベースに流し込んでしまう。
そこからスキーマコンバージョンツールによる指摘が入っている箇所に対して修正を入れるというやり方で進めました。
実際、このDDLがあるとないとでは、かなりアプリケーション対応工数に違いがあったのかなと思います。
DB更改完了！
本番DB更改は厳密なタイムスケジュールに基づいて実施しました。サービス一時停止→データ移行スクリプト実行→各種動作確認を経て本番環境サービスを再開しました。半年以上に渡るプロジェクトでしたがこれをもって無事に完了です。
今現在もAmazon Aurora PostgreSQLは安定して稼働しております。
移行で大変だったこと
主にSQL Serverからの移行に特化した細かい話ではありますが、SQL Server上のテーブル定義では、視認性がよいこともあり大文字と小文字を混在して各種テーブル名、カラム名等を命名していたのですが、これがPostgreSQLの場合は全て小文字になります。
例えばですが、StudentNameというカラム名であれば、StudentのSとNameのNを大文字にするというようにしていました。こういった物理名が全て小文字になるので、残念なことに非常に読みづらくなりました。
もう一点が、SQL Serverの照合順序の設定でして、SQL Server側では英字の大文字/小文字、全角文字/半角文字、平仮名/カタカナを区別しない設定にしていまして、サービス内の部分一致検索の機能ではこれを有効活用していたので、同様の機能を持っていないPostgreSQLではアプリケーション側で対応することになりました。
あとは、負荷試験実施のときについては非常に苦労しました。SQLServerのときのインデックスが効果的でない場合があるので、負荷対策には十分な時間、リソースを確保しておくべきだったなと感じました。
移行してよかったこと
やはりマネージドサービスということで管理・運用面は非常に楽になりました。
一つがストレージ容量についてでして、「キャリタスUC」はストレージの拡張を随時行っておりまして、利用者増に伴い容量増加のペースも早まっていたのですが、Aurora PostgreSQLは、自動スケールアップとなるので、残容量についての心配はなくなりました。
もう一つがこちらもRDSならどのDBでもそうだと思いますが、データベースの復元が楽です。今まではEC2インスタンスにデータベースがありましたが、容量が大きいことから、
同一環境に復元することができず、復元先の”箱”を準備するところからしなければならなかったのですが、今は、コンソール上から2,3画面操作するだけで復元ができるので、かなり手間が省けます。
最後に
今回、事例紹介の対象として紹介させていただいたのは「キャリタスUC」というサービスになります。キャリタスUCは、企業が学校に送る求人票・インターンシップ情報をオンライン化し、学生はその情報を学校経由で閲覧し、直接応募が可能です。
就活サイトや自社サイトからのエントリーへの誘導も可能で、学校を中心とした新しい採用活動が実現できます。全国約700の学校様、約67,000の企業様にご利用いただいておりまして、まだまだ広がりを見せているサービスとなっています。
一部機能は有料になりますが、基本利用料は無料となりますので、人事採用担当の方などにご紹介いただき、是非、採用活動にキャリタスUCをご利用いただければと思います。
以上になりまーす
最後まで読んで頂きありがとうございます！
今後も定期的に投稿しますので是非また読んで頂ければうれしいです！
我々は新卒、中途採用を実施しています。ご興味のある方は下記リンクよりご応募お願いします！
この記事が気に入ったらサポートをしてみませんか？