約50ペタバイト、7500のデータベースをほぼダウンタイムゼロで移行――「Amazon.com」のデータベース移行事例に学ぶ、現実的なマイグレ／モダナイ推進法：「2025年以降の成長」を支えるマイグレ／モダナイジャーニー「最終解」

ビジネス展開のスピードと変化対応力を高めるために、既存システムをクラウドに移行する企業が増えている。だが、大規模データベースの移行となると容易ではない。「Amazon.com」におけるデータベース移行事例を基に、移行を成功させるための現実的なポイントを聞いた。

PR／ITmedia

PR

本記事は、アマゾン ウェブ サービス ジャパン合同会社の依頼を受けて、同社の広告として掲載しています。

　アプリケーションやサービスの構築、提供の在り方が、ビジネスの展開スピードと品質に直結する今、クラウド利用は当たり前の選択肢となり、クラウドネイティブを実践する企業は増え続けている。そうした中、データベース管理システム（DBMS）などのミドルウェアもクラウドサービスに移行し、運用の合理性を追求しようという機運が高まっている。

　背景にあるのは、オンプレミスシステムのライセンスやハードウェアコストの増加、休日・深夜対応のようなデータベース運用負荷などの課題だ。だがビジネスを長年支えてきた大規模データベースの移行は容易ではない。移行先の選定から移行作業まで困難が続く上、もし移行に失敗すればシステム障害によるサービス停止のリスクがあり、ビジネスへの影響も計り知れない。

　とはいえ、ビジネスニーズに応えるスピードと変化対応力、コスト効率は差別化の一大要件となっており、既存の仕組みを現在の経営環境と目的に最適化することは急務といえる。データベースのマイグレーション／モダナイゼーションを成功させるポイントとは何か。

　本稿では、Amazon Web Services（AWS）のVice PresidentであるJeff Carter（ジェフ・カーター）氏にインタビュー。同氏は、ECサイト「Amazon.com」の基盤としてオンプレミスで運用していた約50PB（ペタバイト）規模の「Oracle Database」を、AWSのクラウドインフラにほぼダウンタイムゼロで移行するプロジェクトを指揮した経験を持つ。併せて、アマゾン ウェブ サービス ジャパン（以下、AWS Japan）で企業のデータベース移行を支援している内山義夫氏に成功のポイントを聞いた。

2016年時点で100％オンプレミス　Amazon.com社がデータベースの移行を決断した理由

AWSのJeff Carter氏（Relational Databases Vice President）

　「私が入社した2016年当時、Amazon.comのITインフラは100％オンプレミスで稼働していました。Amazon.com社（以降、企業名の場合は社を付けて表記）は1994年からOracle Databaseを使い続けており、当時使用していたOLTP（オンライントランザクション処理）用のデータベースは約7500、データベースに基づいたDWH（データウェアハウス）用テーブルは約7万5000、DWH用データの総容量は約50PBに達している状況でした」――カーター氏は、Amazon.comが置かれていた当時の状況をこう話す。

　課題は大きく分けて2つあった。一つはコストの問題だ。ビジネス拡大に伴いデータ量が増大する中、肥大化するコストを食い止める必要があった。「データクエリの件数が指数関数的に増えており、『コスト面でサステナブルではない』と判断していました」とカーター氏は語る。大型セールなどのピーク時に合わせてデータベースサーバの性能や容量を決めていたため、コストは増える一方だった。

　もう一つは運用管理面の問題だ。データベースを急速に拡張する中で、パッチ適用などの管理作業が徐々に追い付かなくなっていった。

　「Amazon.com社には業界でも屈指の技術者が集まっていました。それでも、技術面の問題でサービス障害が発生することもあり、限界を迎えつつありました」

大規模データベースを「ほぼダウンタイムなし」で移行　どう進めたのか

　これを受けてAmazon.com社はオンプレミスで運用していた全てのデータベースサーバをAWSにマイグレーションすることを決断。ビジネスへの影響を最小限に抑えるべく、ダウンタイムなしの移行を条件とした。

　プロジェクトのポイントは2つある。「移行先データベースの選択」「ロールバック体制の確保」だ。移行先データベースとして「Amazon DynamoDB」（キーバリュー型のNoSQLデータベースサービス）と、「Amazon Aurora」のPostgreSQL（リレーショナル型でPostgreSQL互換のデータベースサービス）を中心に選択した。

　「フロント系の機能は、Webサイトへのアクセス数に応じて柔軟にスケールさせる必要があるため、リレーショナル型は選べませんでした。そこで、フロント系にはAmazon DynamoDBを使いました。一方で、Webページにひも付いていないバックエンド系機能ではスケーラビリティを考慮しなくてよいため、Oracle Databaseとの互換性を重視して、Amazon Aurora PostgreSQLを選びました」

　ゼロダウンタイムを実現するために、アプリケーションは1本ずつ移行することとし、障害が発生した場合にはいつでもロールバックできる体制を整えた。具体的な手順は次の通りだ。

1. データをオンプレミスからAWSにレプリケート（複製）し、オンプレミス側からAWS側に常時同期させる
2. データベース参照系アプリケーションを1本ずつ移行し、障害があったらロールバックする
3. データベース更新系アプリケーションを1本ずつ移行し、障害があったらロールバックする
4. データベース更新系のアプリケーションを移行できたら、それに関連するテーブルの常時同期の方向をAWS側からオンプレミス側へと逆転させる
5. データベース参照系とデータベース更新系アプリケーションの全てを移行完了後、システムの他の部分をAWSに複製する

　このように慎重な手順を踏むことによって、大規模データベースのマイグレーションを4年間で完了させた。2016〜2018年はアナリティクスとデータレイクに関係するDWHシステムを、2017〜2019年はOLTPシステムのマイグレーションをしたという。

　「この移行によって、コストと運用負担という2つの課題を解決できました。特に商用DBMSのライセンス費用が不要になったことは大きいです。コンピュートやストレージなどインフラの価格を抑えられた点もコスト低減につながりました」

　Amazon Aurora PostgreSQLへのマイグレーションで、障害からの回復やパッチ適用など運用管理作業の自動化を果たしたことも大きなポイントだ。

　「取り組み当時、運用現場はデータベース移行に否定的でした。もし失敗すれば、『Amazon.comをつぶしたのは彼ら（移行担当者）だ』と非難されるリスクがあったためです。しかしダウンタイムなしで移行できただけでなく、オンプレミスでの運用工数が削減されて時間の余裕を確保できるようになりました。その結果DBA（データベース管理者）などの運用管理担当者が、事業部門のチームやアプリケーション開発チームが稼働している営業時間内に、適切に連携できるようになったのです。皆さんご存じのように、Amazon.comは今もビジネスを成長させています。移行に否定的だった現場の全員が『移行して正解だった』と意見を改めました」

企業の課題、ニーズに応じた多様なデータベースを提供

AWS Japanの内山義夫氏（JAPAN GTM Data and AI　Worldwide Specialist and Partner Organization）

　こうしたAmazon.comの事例のように、コスト増や運用負担に悩む企業は多い。加えて、データ量やデータの種類など各社各様の課題がある。そこでAWSは多くの企業の課題解決に向けて、多様なデータベースサービスをラインアップしている。下記はその一例だ。

• リレーショナル型：Amazon Aurora、「Amazon Relational Database Service」（Amazon RDS）、「Amazon RDS for Oracle」、「Amazon RDS Custom for Oracle」
• キーバリュー型：Amazon DynamoDB
• ドキュメント型：「Amazon DocumentDB」
• インメモリ型：「Amazon ElastiCache」「Amazon MemoryDB for Redis」
• グラフ型：「Amazon Neptune」
• 時系列型：「Amazon Timestream」
• ワイドカラム型：「Amazon Keyspaces」

　さらに2025年には、「Oracle Database＠AWS」（AWSのデータセンターに「Oracle Exadata Database Machine」を持ち込んだ新サービス）を米国東部（バージニア北部）リージョンで正式にサービスを開始する予定だ。Oracle Databaseのクラスタリング機能である「Oracle RAC」（Oracle Real Application Clusters）を、AWSで展開できるようになる見込みだ。

　AWSは、これらの多様なデータベースサービスを検討する際の指針として、次の3種類のプレイブック（戦略のシナリオ）を提示している。

• マネージドデータベースへの移行（自己管理→AWS側の管理）
• レガシーデータベースからの脱却（商用データベース→オープンソースのデータベース）
• AWSのデータベースでモダナイズ（モノリシック→マイクロサービス）

　「まずAWSのサービスに移行することで運用負荷をオフロードする」「オープンソースソフトウェアを選択することでライセンスコストを低減させる」「さらに変化対応力を高めるべくアプリケーションの設計をモダナイズする」といった具合に、無理のないマイグレーション／モダナイゼーションパスを整理しているわけだ。内山氏は、「移行の判断に迷う場合は、こうしたプレイブックを参照し、各社の目的やフェーズに合わせて適切な戦略を選んでほしい」と話す。

AWS Japanが提案する、モダナイゼーションのプレイブック例（提供：AWS Japan）《クリックで拡大》

　データベース移行の際には、データの移行と、データベーススキーマ、データオブジェクト、ビュー、ストアドプロシージャなどのオブジェクトの移行がある。これらに対して、AWSは「AWS Database Migration Service」（AWS DMS）と「AWS Schema Conversion Tool」（AWS SCT）を提供する。

　AWSへのマイグレーションの工程は、AWS社の「Solution Architect」（SA）や「Professional Services」（ProServe）などのサポートエンジニアが支援する。SAはマイグレーション戦略の基礎検討から、アーキテクチャ設計、実装、運用までの工程を長期的にカバーする。ProServeはアセスメント、設計、実装に関するプロジェクト単位の技術コンサルティングを担う。

　移行を決断する以前に、既存データベースの課題分析、移行後のアプリ改修の必要性など、さまざまな懸念事項が生じることも多い。これを解決するのが「Database Freedom Workshop」だ。

Database Freedom Workshopのサービス概要（提供：AWS Japan）《クリックで拡大》

　「Database Freedom Workshopは、データベース移行計画やアセスメントからのPoC（概念実証）工程に対応しています。データベース移行の有用性、実現性を判断するところから伴走型で支援します」と内山氏は説明する。

　このように、「移行前の課題」から「実際の移行」に至るまで、AWS Japanは各社各様の課題に対し、多様な解決策を用意している。こうした支援を受けてオンプレミスのデータベースのマイグレーション／モダナイゼーションを果たした事例は多数あり、AWS JapanのWebサイトでも公開されている。ポイントは、小さな成功を体験するところから取り組み始めることだ。カーター氏と内山氏は、データベースのマイグレーション／モダナイゼーションに挑戦する企業に向けて、次のように語る。

　「Amazon.comがロールバックできる体制を整えつつマイグレーションを進めたように、私たちは多様なデータベースサービスとAWS DMS、各種支援サービスだけでなく、移行リスクを低減させながら問題が発生しても戻れるような“一方通行ではない”移行を実現するための支援もお客さまに提供します。その過程で『筋肉』を付け、新しいテクノロジーを学んでいけば、大規模なデータベース移行でもきっと乗り越えられるはずです」（カーター氏）

　「生成AI（人工知能）によってAWS DMSの機能面を強化し、移行の精度を高める取り組みも進めています。各社各様の目的、状況に即したデータベースのマイグレーション／モダナイゼーションを戦略、技術の両面から包括的に支援することを通じて、お客さまのビジネス差別化に貢献します」（内山氏）

Amazonギフトカードが当たる！アンケート実施中　＜本アンケートは終了しました＞

本記事に関連して「クラウドサービス」についてのアンケートを実施しています。回答された方から抽選で15名様にAmazonギフトカード3000円分をプレゼントいたします。ぜひ下記アンケートフォームよりご回答ください。当選発表は発送をもって代えさせていただきます。

ログイン または 会員登録（無料）いただくとアンケートフォームが表示されます。オレンジ色の「アンケートに回答する」ボタンからアンケート回答をお願いいたします。