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

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

リンク

Agenda

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

2.クラウド化のメリット／デメリット

クラウド化のメリット／デメリットについては、あらためて書かなくてもアチコチにドキュメントがあるので、ググってください（笑）
「DB屋のオッサンの観点から」ということで、今回のプロジェクトで使用した「Auroraを使うことのメリット／デメリット」について書いてみようかと思います。

2.1.メリット

DBサーバを持たなくて良い
スケールアップ／ダウンが容易に行える
環境のレプリケーションが容易に行える

2.2.デメリット

DBサーバがない
DBパラメータの変更に制限がある
DBパラメータを変更した場合、同じパラメータグループを使用している環境全てに影響がある

メリットについては、クラウドベンダーが魅力的な文言を載せているページがあるのでそちらを参照いただければと思います。（笑）

今回は魅力的な文言たちの奥に押しやられがちなデメリットに重点を置いて細かく記述したいと思います。

2.2.1.DBサーバがない

メリットにも同じようなことを書いています。
要はクラウドの大きな特徴だと私は捉えています。
ポジティブに捉えると「実機を購入しなくて良い」、「H/Wのメンテナンスが不要」といった点が挙げられます。
ネガティブに捉えると「突き詰めた調査が出来ない」という点が大きいです。
OS（ホスト／ゲスト）のログに閲覧制限がかかり、サポートに問い合せざるを得ない。
サポートに問い合わせる＝いつ返事が返ってくるか分からない。
→調査がいつ終わるか分からない。
現場的には仕事のスピード感が損なわれるので、大きなデメリットと考えています。

2.2.2.DBパラメータの変更に制限がある

まぁこれは、クラウドDBの商売という観点からすると、仕方がないのかも知れません。
私が確認した中では、CPUに関するパラメータ、メモリのサイズや配分設定に関わるような部分は悉く変更できませんでした。
そもそも、上記のような部分を変えてしまうと、DBインスタンスのサイズが変わってしまうことになりかねないので、想定していたインスタンスサイズでパフォーマンスが出ない場合は、もっと大きなサイズのDBを使いなさいという事なのでしょう。
（※当然、大きくした分お金がかかります。）

2.2.3.DBパラメータを変更した場合、同じパラメータグループを使用している環境全てに影響がある

これは個人的に現場で失敗しただけ（笑）なのですが、DBパラメータ検証用環境に開発環境と同じパラメータグループを使用したがために、パラメータを変更した際に開発環境に影響が出たことがありました。
（開発メンバーに気づかれないうちにコッソリ直したのは言うまでもないw）
自分が環境の管理者でなかったために苦労した＆自分の失敗談ということでデメリットのように書きましたが、ちゃんと管理して利用すれば非常に便利な機能なので、計画的なご利用をオススメします。

デメリットとして書いてみましたが、「特徴」として捉えられる点が2つと商売的に仕方ない点が1つでした。
たぶん、経営層（カネ勘定しかしないヒト）にはメリットしか見えず、私のような現場組に対しては不都合があるといった程度の感じですね。

今回はここまで。