データベースのクラウド移行で発生するギャップ、インフラ構成要素別の注意点 - ITpro

全4430文字

　データベースをクラウドに移行する際、アーキテクチャーを新しくしてシステム開発のスピードや柔軟性を上げることを期待する場合があります。アーキテクチャーを新しくすることをモダナイズ、またはモダナイゼーションといいます。クラウド移行の目的にモダナイゼーションが含まれる場合は、データベースのアーキテクチャーにも変更が生じます。

単純移行か、モダナイズか

　例えばアプリケーションをマイクロサービスアーキテクチャーにするのに合わせてデータベースのアーキテクチャーも変える、あるいはデータレイクを介してデータ連係を実行するアーキテクチャーを採用してシステム間の関係を疎結合にするのに合わせてデータベースリンク（DBLINK、他のデータベース上のオブジェクトにアクセスするオブジェクト）を廃止する、といった具合です。

　クラウド移行と同時にモダナイゼーションができれば、テストが1回で済むなどのメリットがあり効率は良くなりますが、いくつか実現の障害となり得ることがあります。移行担当者が、モダナイゼーションをするために必要な新しいスキルを習得する期間が必要です。モダナイゼーションの際は新規性のある技術やノウハウを使う可能性が高く、エンジニアの確保やスキル習得が課題になりやすいこともあります。システム規模が大きくなるほど、一気にアーキテクチャーを変更するのは困難になります。

「リフト＆シフト」で移行

　アーキテクチャーを変えずにクラウドへ単純移行して、クラウド移行後にアーキテクチャーを変える移行パターンを「リフト（Lift）＆シフト（Shift）」と呼びます。

図　クラウド移行の「リフト＆シフト」

[画像のクリックで拡大表示]

　リフトはオンプレミス環境のシステムをそのままの形でクラウドに移行すること、シフトは移行後のクラウド上で新しいアーキテクチャーに変えることです。リフト＆シフトはクラウド移行のメリットを早期に得ながら、期間をかけて段階的にアーキテクチャーを変える手法であり、リスクを抑えた移行方式といえます。

　リフトで単純移行する際は、手間を少なくできるクラウドへの最適化のみを実施します。リフトでクラウドに移行した後は、アーキテクチャー変更の障害となるようなギャップを小さくして、取り組みやすい状態にしてからアーキテクチャーを変えるなど、いくつかのステップに分けて移行します。

　DBLINKを廃止する場合で例えると、DBLINKを使っているビューを順次減らしていってからDBLINKを廃止するといったやり方が考えられます。アプリケーションを順次API（アプリケーション・プログラミング・インターフェース）化して時間をかけてマイクロサービスにする際、データも順次新しいアーキテクチャーのデータベースに移行するという例もあります。

　データベース移行では、オンプレミス環境のハードウエアの保守が切れるタイミングでDBMSを変えずクラウドに移行し、その後DBMSをそのクラウド環境独自のDBMSに移行する、という手法を採るケースがよくあります。移行の目的や実現可能性によって、どのような移行パターンにするかを決めるとよいでしょう。

Adblock test (Why?)