OracleからAurora(MySQL)への移行（その６）

2018年4月いっぱいで抜けたプロジェクトについて、DB技術者のオッサンが実際に現場で思ったことや感じたことを書き残すプロジェクトレポート的な社員ブログです。

リンク

OracleからAurora(MySQL)への移行（その１）

OracleからAurora(MySQL)への移行（その２）

OracleからAurora(MySQL)への移行（その３）

OracleからAurora(MySQL)への移行（その４）

OracleからAurora(MySQL)への移行（その５）

Agenda

プロジェクト概要
クラウド化のメリット／デメリット
技術的なハードル
サマリ　　　　　　　　　　　　　　　←イマココ

4.サマリ

2017年6月～2018年4月の間、Oracle → Aurora(MySQL)へのDB移行に携わりました。
プロジェクトに携わる中で痛感したことをサマリとして記述します。

4.1.実機検証が大事！

Oracleは高価かつ便利な機能が満載のDB、対してMySQLはもともとフリーかつシンプルに作られたDBです。
機能の有無の調査、機能があった場合でも挙動の差異はあるか？
機能が無い場合はどのように代替機能を実装するか？
実装出来たとして、処理性能はどうか？
できれば、諸々の品質の担保のために本番相当のスペック、データを積んだ環境で実機検証を行う事が望ましいです。

4.2.事前調査も大事！

今回のプロジェクトでは、技術検証自体が不足しているように感じました。
開発フェーズに入ってから発覚した技術的問題の多いことったらもうね。。。orz
恐らく、現行システムでどのような機能を使用しているか把握するための調査が不足していた事が原因と考えられます。
自身の名誉のために弁明しておくと、事前調査をしたのはワタシじゃ無いよん！☆（ゝω・）vｷｬﾋﾟ

4.3.スケジュールの余裕をどれだけ持てるかも大事！

どれだけ検証をしたとしても、想定外の事態は起こります。
想定外の機能の使われ方、想定以上に汚いSQL、RDBMSの特性を全く活用する気の感じられないデータ設計etc
こんなもの、一体どうやったら想定できるというのか。。。orz
現行システムのDB設計者は何を考えて作ったのか？そもそも有識者は居たのか？
これらの不測の事態に対応するためにも、時間的余裕が非常に重要になります。

以上を以て、Oracle→Aurora(MySQL)への移行プロジェクトレポートとします。