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

リンク

OracleからAurora(MySQL)への移行(その1)

OracleからAurora(MySQL)への移行(その2)

OracleからAurora(MySQL)への移行(その3)

OracleからAurora(MySQL)への移行(その4)

OracleからAurora(MySQL)への移行(その5)

Agenda

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

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)への移行プロジェクトレポートとします。