ビッグローブ、オンプレミスのOracle DatabaseからAmazon RDS for Oracleへ移行

今回は「ビッグローブ、オンプレミスのOracle DatabaseからAmazon RDS for Oracleへ移行」についてご紹介します。

関連ワード （クラウド等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　ビッグローブが会員・契約情報などを管理する基幹システムなど3つのシステムについて、オンプレミスの「Oracle Database」をAmazon Web Services（AWS）の「Amazon RDS for Oracle」に移行した。この移行を支援したシステムサポートが発表した。

　ビッグローブは、事業環境の変化に合わせてITリソースを最適化し、いかに価値を産むビジネスに集中するかが経営の課題となり、AWSへの移行を決定したという。なお、対象システムでOracle Databaseを利用していることから、AWSのみならず、Oracle Databaseに関する豊富な知識と移行実績を持つシステムサポートが移行支援を担当したという。

　移行では、「AWS Database Migration Service」（AWS DMS）を使用し、各システムの検証を経て3月より順次実施し、9月に完了している。AWS DMSは、ダウンタイムゼロ、データ損失を最小限に抑えた上で、AWSへの移行を支援するマネージド移行およびレプリケーションサービスになる。これによりビッグローブのインフラのコストは2018年度と2024年度の比較で13％削減される見込み。インフラコストが固定費中心から変動費中心に変化した。

　移行前の検証では、（1）AWS DMSの対象となるテーブルやデータ量が多く移行時間を決められない、（2）マルチバイト文字のテーブル内のデータが文字化けする――などの課題があった。

　（1）については、テーブルおよびデータ量が多いため、移行のためのフルロード（AWS DMSを使用した初回ロード）が1週間かかっても完了できず中断することとなり、移行日や作業時間の見込みを立てることが困難となっていた。これに対してシステムサポートは、既存環境への負荷を考慮したAWS DMSタスクの多重度の検証を繰り返し実施し、また、煩雑化していたテーブルマッピングを効率化するスクリプトを作成した。これにより準備とフルロードを合わせ1週間程度で完了できるようになった。

　（2）では、Oracle Databaseで特定の文字コードを利用している場合、AWS DMSのフルロード時に一部の表データで文字化けが発生していた。複合的な要因が関係していたため回避策がなく、AWS DMSではデータ移行の完了確認ができない状況に陥っていたという。そこで、文字化けが生じた一部のテーブルについては、AWS DMSのタスクから対象外とし「expdp/impdp」(エクスポート／インポート)で移行した。

　このほかにも、AWS DMSでのフルロード後に、既存システムのテーブルに対して短時間で大量更新するバッチ処理が実行されると、AWS DMSのデータ移行が中断し、再度フルロードをしなくてはならない状況に陥っていたという。

　これに対してシステムサポートは、ビッグローブの協力により、短時間で大量更新するバッチ処理が発生するテーブルを洗い出し、バッチ処理が終わるタイミングを待ってAWS DMSのフルロードを実施し、データ移行が中断されることを回避した。また、バッチ処理が発生するテーブルをまとめたAWS DMSタスクを別途作成することで関係のないテーブルに対するAWS DMSへ影響がないようにした。