【DXを推進するためのデータ基盤とは】第2回「DXを加速するデータベースのクラウド移行と運用の最適化」

「DXを推進するためのデータ基盤とは」シリーズ　第１回「DXに求められるデータ基盤と構築工程」では、「データを集めて、活かすDX」を実現するために不可欠な『データ基盤』が満たすべき３つの特性と、DXに適した開発工程について解説し、その中でDXの推進、データの有効活用にはクラウドサービスの利用が有効であることをお伝えしました。

一方で、データ活用の肝となる「データベース（DB）のクラウド移行」は、その難易度の高さから、「なかなか着手できない」、「なにから始めていいかわからない」という声が多く聞かれます。

DBのクラウド移行は事前に調査、検討、また検証すべきことが多く、また移行に伴うリスクも存在するため、決して容易ではありません。

しかしながら、実現したい要件に合わせて移行方針を定め、利用するサービスを適切に選定すること、さらに事前検証で移行時のリスクを把握し、対処方法を検討してリスクを最小化することで、DBのクラウド移行を実現することができます。

今回は、「DXを加速するデータベースのクラウド移行と運用の最適化」と題して、DXを加速させるデータ基盤実現のための、 DBのクラウド移行の具体的な流れと留意点、クラウドでのDB運用のポイントについて解説します。

DXを推進するためのデータ基盤であるデータベース(DB)には、社会情勢や顧客ニーズの変化に対応するスピードや柔軟性が求められ、その導入の速さ、拡張・縮小の柔軟性、変更の容易さといった特長をもつクラウドの利用は、データベースでも非常に有効です。
新規システムはもちろん、既存のオンプレミス環境のデータベースもクラウドへの移行の対象となりますが、 DBのクラウド移行には既存システムの改修のみならず、運用手順の変更、データ移行といった解決すべき課題、リスクが存在します。
クラウドのメリットを引き出し、かつリスクを管理してDBの移行を成功させるために、何を優先しどうリスクを回避するかを含まえた移行構想、移行計画の考え方、設計変更や運用変更のポイントについて紹介します。

１. DBのクラウド移行実現までの流れ

DBのクラウド移行を実現する流れは、以下の流れで進めるとよいでしょう。
いきなり移行計画から始めるのではなく、移行構想を検討し、机上検証とPoC(概念検証)を行った上で、移行判定を行い、移行計画～移行実施へと進めます。

Step１．移行構想の検討
Step２．机上検証による移行判定
Step３．PoCによる移行リスクの検証
Step４．移行計画の作成および最終移行判定
Step５．移行の実施

上述のステップに沿って、クラウドのメリットを引き出しつつ、適切にリスク管理しながらDBの移行を成功させるために考えるべきポイントについて説明します。

■Step１．移行構想の検討

DBのクラウド移行を考える上でまず初めに行うべきは、自社のDX 推進する上で実現したい要件の明確化と、要件に合わせた環境やDBの選定などについての検討です。
また検討する上で必要な情報収集なども併せて行う必要があります。

既存のDB、特に商用DBにおいては、ビジネスの成長に伴う容量や数の拡大により、ライセンスや保守費用などのコストも増大し、システムの維持が大きな負担となっており、クラウドへの移行とあわせて、商用DBからオープンソース(OSS)のDBに移行するニーズが増加しています。

OSS DBの機能・性能は向上もあって、その結果、OSS DBをサービス化したマネージドサービスが既存のDBをクラウドに移行する際の現実的な選択肢となってきています。

一方でDBシステムのクラウド移行にはアプリケーションの改修以外にも、クラウドに適した運用手順の変更、そしてデータの移行といった特有の難しさや解決すべき課題も多く存在します。

そこで移行構想での移行パス検討の一例として、オンプレミスの商用DBからクラウドのOSS DBに移行するケースについて考えてみましょう。

既存のシステムについて（大幅な改修はせずに）あるがままに近い形でクラウドへ移行する縦方向の動きである「リフト」、クラウドでのメリットをより生かせるようにマネージドサービスなどのクラウドに最適化されたサービスに移行する横方向の動きである「シフト」という2つのアクションが存在します。

「リフト」については既存システムをできる限りそのままクラウドに移行するものであり、その作業は比較的容易です。

「シフト」についてはDBMS（データベース管理システム）の変更に伴うアプリケーションの修正や、クラウドのメリットを生かすための運用面での変更など、リフトに比べ難易度は高くなります。
一方で「シフト」にはクラウドネーティブなPaaS（プラットフォーム・アズ・ア・サービス）に移行することでクラウドのならではのスピードや柔軟性を得やすいという大きな利点があります。

オンプレミスのDBをクラウドのOSS DBに移行する場合は、この「リフト」と「シフト」をどう組み合わせるかを検討します。

具体的な移行の方針としては以下の3つの方移行方式で検討することになります。

①オンプレミスの商用DBをクラウドにリフト（Lift）してからOSS DBにシフト（Shift）する（リフト＆シフト）
②オンプレミスの商用DBから直接クラウドのOSS DBに移行する（リフト＋シフト）
③オンプレミスの商用DBをOSS DBに移行（シフト*）してからクラウドにリフト（Lift）する

クラウドへの移行を最優先に行う場合は①を、OSS DBへの移行が優先される場合は②を選択します。
③については②とコストや対応期間が大きくは変わらないためほとんど選択されることはありません。

DX推進のための手段として、DBのクラウド移行でむやみに「リフト」するいうのはあまり得策とは言えません。移行構想の検討の段階では企業内のDB層を全体的に見て、機能・非機能でのギャップとクラウド化への影響を事前に評価したうえで、適切なクラウドサービスへの「シフト」を選択するといった、適材適所の考え方が重要なのです。

■Step２．机上検証の実施

DBの移行は一般的には①移行計画の立案、②移行作業、③運用（システム切り替え）の流れで行います。どのようにクラウド移行を計画し、実行に移すと、適材適所を実現できるでしょうか。クラウド移行を成功させるには、移行作業を難しくしているところや問題が起こりやすい箇所といった、リスクの高い部分から段階的に検証を進めるのがよいでしょう。
ポイントは、まずは「机上から」検証を始めることです。

クラウド移行、特に異なるDBMS間の移行を難しくしているのは機能面でのギャップだけではありません。性能や運用管理などの非機能面でのギャップが多く、それらの解決には専門的な知識や経験が必要となってきます。

移行計画を立てる際は初めに移行元システムの構成や使用しているリソース、トランザクション量などの性能情報を収集します。そして移行先システムで移行元のシステムと同じ機能を提供できるか、性能目標について達成が可能かを「机上で」検証し、移行の可否や難易度について評価します。

「すぐに始められること」はクラウドのメリットですが、机上検証なしでPoC（概念実証）を網羅的に始めてしまうと、いたずらにコストを費やすだけになります。最初は移行先のデータベースがクリアしなければならない必須の要件、いわゆる「ノックアウトファクター」をメインに段階的に移行性の机上評価による移行判定をするのがよいでしょう。

利用する機能、可用性、性能、運用での必須要件で必ずクリアしなければならないものについて評価します。またノックアウトファクターで達成できないものが出た場合は、要件を満たすための代替案を検討したうえで、次の工程となるPoCで実現可能かどうかを検証します。

■Step３．PoCによる移行リスクの検証

机上検証を行った結果、実環境での検証が必要と判断された要素、ノックアウトファクター以外で移行リスクになると考えられる要素を、PoCで検証します。この工程ではスキーマやアプリケーションの一部についてサンプルを抽出し変換を行うことで、システム全体を変換するコストを算出するための基礎値（単位あたり変換工数）を算出します。

■Step４．移行計画の立案

機能・非機能でのギャップを解消できることが確認されて、コストも問題ないと判断できれば、移行計画を立てて、移行プロジェクトを実行するかどうかの最終的な判断を行います。

検証の結果次第で、移行先のDBとしては、マネージドサービス（PaaS、プラットフォーム・アズ・ア・サービス）ではなく、仮想サーバー（IaaS、インフラストラクチャー・アズ・ア・サービス）にOSS DBを導入することを選択するケース、あるいはオンプレミスに残すことが最適解となる場合もあります。個々のDBではなく企業内のDB全体として、コストも含めた最適化を図ることが重要です。

こういった考え方で移行計画を立てることで、移行実行時でのリスクを最小化し、実現性の高い移行プロジェクトを始めることができるようになります。

■Step５．移行の実施

DB移行の作業には主に(1)システム構成移行 (2)DB定義移行 (3)データ移行 (4)アプリ移行 (5)運用移行 (6)テストの６つの工程があります。
実際の移行実施時の流れに沿って、必要な工程や検討ポイントについて説明します。Step４の移行計画を考える上でも、移行作業時の流れや具体的な工程、注意点をおさえておきましょう。

(1)システム構成の移行
システム構成の移行では、クラスターや認証サーバー、バックアップ運用、レプリケーションなど、移行元DBで求められている要件をクラウド上でも満たすよう、システム構成を設計します。
クラウド上ではオンプレミスと同様の実装や運用ができないものがあります。例えばDBサーバー上でシェルスクリプトを利用した運用や、オペレーティングシステム上のファイルの入出力によって他システムと連携する、といったものは、PaaS環境では利用できないため、代替方式を検討したうえで詳細設計を行います。
(2)DB定義移行
DB定義の移行では、移行元システムに存在するテーブルやビュー、インデックス、ストアドプロシージャなどのスキーマオブジェクトを、移行先のDBがサポートする定義へ変換します。移行支援ツールを活用して効率化できる部分もありますが、単純に移行できないところは代替方式を検討し変換を行うことになります。

この場合、移行支援ツールのアウトプットをそのまま受け入れるのではなく、パフォーマンスを考慮した上で適切なデータ型にマッピングされていか、システム全体で同じ属性（ドメイン）のデータは同じデータ型にマッピングされているか、なども確認します。そうなっていない場合は適切なデータ型に定義を修正します。DX推進において他システムとの連携や全社的なデータ基盤を構築するうえでも適切にDB定義を移行することは重要です。
(3)データ移行
移行元DBに格納されているデータを抽出し、移行先のDB定義に合わせて必要な変換をしたうえでデータを投入しデータ移行を行います。データ変換と移行先へのロードの処理については、本番環境を想定したデータ量でテストしてシステム切り替え時の所要時間の見積もりを行い、オブジェクトの依存関係などを考慮した移行手順を確認します。システム切り替え時のサービス停止時間を短縮する必要が出てきた場合、クラウドベンダーが提供するツールやサードパーティー製品を含めたDBのレプリケーションツールの使用を検討します。
(4)アプリケーション移行
DB定義移行およびデータ移行と並行してアプリケーションの移行作業を行います。アプリケーションから実行されているSQL文やAPI（アプリケーション・プログラミング・インターフェース）、SQL文で使用されている組み込み関数などを移行先DBで実行できるように修正します。変換ツールの利用は可能ですが、あくまで補助的なものと考えたほうがよいでしょう。

また、移行前後でのSQLの処理結果が等価であるかどうかのチェックに加えて、SQLのパフォーマンスについても注意を払う必要があります。複雑なSQLほどパフォーマンス問題への対策が必要になる傾向があり、また移行プロジェクトが進むにつれて対策コストも高くなります。そのため移行前後での性能の変化を確認し、必要に応じてチューニングを実施します。

そしてDXを推進する観点からは、他システムと連携する処理については、直接更新するような処理からAPIやメッセージキューの送信などに置き換えるといったことも検討します。システムの結びつきを”密”から”疎”にすることで変化に強くします。ただしこの変更は現行システムをできる限りそのままクラウドに持ってくる「リフト」の段階では難しいかもしれません。その場合はよりクラウドに適したシステムに移行する「シフト」の段階での課題として認識しておいてください。
(5)運用移行
運用移行ではDBの起動・停止処理、パフォーマンスやエラーなどの各種監視、バックアップ・リカバリーなどのDBMSの運用をクラウドで実行するための仕組みを設計・実装します。

クラウド側で用意している自動運用の機能やサービスをできる限り利用することがコスト削減につながります。システム運用の要件を踏まえてた上でできるだけ新たな作り込みをしない方向で再設計することを推奨します。
(6)テスト
最後に行うテストは移行後のシステム全体での正常動作の確認がメインとなります。トランザクション処理やエラー処理、リソース使用量の傾向などについては、DBMSの変更による特性の違いが表れやすい部分であり、特に詳細なテスト項目を設定して確認します。そしてパフォーマンスについても総合的な性能テストを行って、必要な場合はパラメーターやSQL文をチューニングします。

このようにして、リスクを抑えながらDBのクラウド移行を成功に導くことを目指しますが、DBのクラウド移行自体が目標ではありません。その先のDXでのデータ利活用を見据え、他のシステムも含めた企業内のDB領域での全体的な最適化を意識することを忘れないでください。

ここまで、DXでのデータ利活用に向けたDBのクラウドへの移行の流れやポイントについて解説してきました。次にDBのクラウド移行後の運用についてもご紹介します。

２. クラウド移行後のDB運用

DBをクラウドに移行した後、その運用においても、クラウドの特性を意識しより効率的な運用を行うことが必要となります。クラウドでのDB運用における、(1) オンプレミスとの相違点、特性 (2) クラウドDB運用時の注意点の２つのポイントについて説明します。

(1) オンプレミスとの相違点、特性

DBをクラウド上に構築して運用する際は、まずはクラウド側で用意している運用機能の利用を検討します。

クラウドではDB運用タスクの一部を自動化しています。障害に備えた冗長化構成をコンソール画面の設定だけで実装できる上、フェールオーバーも自動で実行されます。
DB全体の物理バックアップの自動化やバックアップの世代管理、任意の時刻の状態に戻すポイントインタイムリカバリーを可能にするサービスといったものもあります。クラウドサービスが自動化し提供している運用タスクを、独自に実装するとそれだけで時間もコストもかかります。

またオンプレミスからクラウドに移行すると不要になる運用作業があります。ディスクの負荷分散はその一つです。
オンプレミスの場合、一部の物理ストレージだけが忙しく読み書きしていると帯域の上限に達してしまうため、アクセス頻度が多いデータを1カ所に集中させないように、物理ストレージ間でアクセスを分散するようにデータを配置するというものです。しかし、クラウドでは物理ストレージ間のデータ分散はクラウドサービス側が担うため、利用者側は考慮する必要がありません。

クラウドの機能を有効に活用することに加え、さらに独自に品質を高める工夫も重要です。クラウドでも広範囲にわたる障害が発生すると、冗長化しているにもかかわらずシステムが利用できない状態に陥る場合があります。

データセンター2カ所使って冗長化するところを、あえて3カ所使って冗長化し、広範囲な障害から回復できた例があります。それ以来、可用性を高めたい場合はデータセンターを3カ所使って冗長化する設計パターンが定着しました。
クラウドの場合でも、こういった独自の工夫で運用品質を高める余地は多くあります。データベースだけでなく、クラウドに精通したエンジニアの確保が運用の高度化につながるといえるでしょう。

(2) クラウドDB運用時の注意点

クラウドDBはバージョンアップを前提とした運用となることに注意します。
DBエンジンはバージョン毎に販売元のDBベンダーが定めたサポート期限が存在します。クラウドでもDBエンジンが組み込まれているDBサービスにはサポート期限が定められ、期限を過ぎたバージョンのDBサービスは新規利用できないだけでなく、物理バックアップのリストアもできません。さらにサポート期限が過ぎたDBエンジンは、利用中であっても一定期間が過ぎると強制アップグレードされます。

強制アップグレードされた新バージョンのDBでは、稼働中のアプリケーションが正しく動作しないケースがあります。強制アップグレードの日程はクラウド事業者から事前告知されますので、それまでに無理のない計画を立て、強制アップグレードされる前に手動で更新するという運用をお勧めします。

本記事では、DBのクラウド移行を実施する上での具体的な作業工程をご紹介し、DXの推進を目的とした移行構想の検討や、実現性が高くリスクを最小化した移行計画を立てるためのポイント、そして移行後のクラウドでのDB運用の留意点について解説しました。

DBのクラウド移行は、それ自体が目的ではなく、将来的なビジネスの拡大や業務内容、データの多様化に迅速にかつ柔軟に対応しDXを推進することを目的に見据えたものであることを重ねて強調しておきます。