Amazon が AWS の活用でデータベースから解放された理由

Amazon の事例では、Oracle から離れるにあたって同社のデータベースの規模の大きさが障害となっていました。5,000 を越えるデータベースが標準化されていないさまざまなシステムに接続されており、所有権や依存関係が一元的に把握されていませんでした。人事面に関わるリスクもありました。多くの Amazon の従業員はOracle Database プラットフォームにかかわる業務を行っていました。そんな彼らが移行を全面的に支持するでしょうか。 辞めていく人もいるでしょう。

Oracle から AWS への切り替えを希望する他の多くの企業でも、似たような課題に直面しています。他の企業と同様に、Amazon にも移行を早く実現させたい理由がありました。Amazon エンジニアは、複雑でエラーが発生しやすいデータベースの管理、プロビジョニング、キャパシティープランニングに多くの時間を割いていました。同社の急激な成長軌道とスループットの急増により、より多くの Oracle Database シャードがますます必要となり、それに伴う運用やメンテナンス操作や管理オーバーヘッドが増大していました。コストの問題もありました。Oracle で従来どおりのビジネスを続けると、Amazon がライセンス料としてすでに支払っている数百万ドルが増額されます。年間 10% という信じられない数字です。

「多くの企業がそうであるように、当社も同じ状況でした」と語るのは、移行プロジェクトの主導を支援した Amazon.com のコンシューマービジネスデータテクノロジー部門、ソリューションアーキテクチャ担当シニアマネージャーである Thomas Park 氏です。「Oracle は AWS へ移行する最大の理由でしたが、最大の障害でもありました」

以上が当時の状況です。Amazon では現在、約 50 ペタバイトのデータの移行をほぼ完了し、5,000 の Oracle データベースのうち最後に残った部分をシャットダウンしようとしています。この大規模な移行を、Amazon はどのように成功させたのでしょうか?

Amazon は移行中に 2 つの重要な課題に直面しました。1 つは、グローバルに分散されたさまざまなチームに、このプロジェクトを受け入れてもらい、なおかつ進捗を追跡するモチベーションとなるようにするための大規模プログラム管理にどのように取り組むかということでした。もう 1 つは、移行の技術的な複雑さでした。プロジェクトを成功に導くために、同社のビジネスラインには、一元化されたコーディネーション、教育、テクニカルサポートが必要なことは明らかでした。

これらの課題を克服するために、Amazon はエンタープライズ向けのプログラムマネジメントオフィス (PMO) を作成することから始めました。PMO では、明確なパフォーマンス要件や、各サービスチームに週次、月次、四半期ごとのレビューが設定され、進捗状況とプログラムのステータスが追跡、レポートされます。

「プログラムを確立するうえで、『方法』に取り組む前に、実現を目指すものとその理由を明確に定義する必要がありました」とは語るのは、Amazon コンシューマービジネスデータテクノロジー担当ディレクター、Dave George 氏です。「『目標』と『理由』を明確にしたら、積極的に経営陣のスポンサーシップを得て、明確な目標を設定しました。このスポンサーシップにより、多くの分散されたテクニカルチームがはっきりとした明確な視点を持って、目標を実現できました。実現への絶え間ない注力により、コアシステムのアーキテクチャを大幅に更新しながら、その他のビジネスの優先事項の中断を最小限におさえることができました」

また、プロジェクトの成功の鍵となったのは、経験豊富なソリューションアーキテクトとデータベースエンジニアからなる AWS テクニカルコアチームでした。このチームは、Oracle から移行する Amazon データのカテゴリごとに、AWS のどのサービスが適しているかを提案しました。

• Amazon DynamoDB: 高可用性、ミューテーション型スキーマ、1 桁台のミリ秒レベルの安定したレイテンシーを大規模環境で必要とするクリティカルサービスに推奨。
• Amazon Aurora: 高可用性と強力な参照整合性を必要とする安定したスキーマを持つサービスに推奨。
• Amazon Simple Storage Service (Amazon S3): リレーショナルおよび非リレーショナルデータの低コストかつ長期間の保存に推奨。

• Amazon Relational Database Service (Amazon RDS) for PostgreSQL or MySQL: 非クリティカルサービス、およびセットアップ、オペレーション、スケーリングの簡便化に推奨。
• AWS Database Migration Service (AWS DMS): データベースを安全かつ短期間の AWS 移行を支援。移行中でもソースデータベースはフルオペレーションが可能な状態に保たれ、データベースを利用するアプリケーションのダウンタイムはミニマイズされます。DMS は、一般に普及しているほとんどの商用データベースとオープンソースデータベース間のデータ移行にご利用いただけます。
• AWS Schema Conversion Tool (AWS SCT): ソースデータベーススキーマやデータベスコードオブジェクト (ビュー、ストアドプロシージャ、関数など) の大部分を自動的にターゲットデータベース互換フォーマットに変換することにより、計画的に異種データベース間を移行。
  

テクニカルコアチームはさらに特定の課題に直面している Amazon ビジネス向けに、具体的な AWS のサービスについて正式な指示を出し、ハンズオンラボを実施し、AWS プロダクトチームによるマンツーマンのコンサルティングや直接支援の調整も行いました。

「経験豊富なソリューションアーキテクトとデータベースエンジニアで構成されたセントラルチームを構成することは、プロジェクトの成功に不可欠でした」と Park 氏は言います。「このチームは、Amazon ビジネスチームの教育を支援しただけでなく、フィードバックや機能のリクエストを出し、すべてのお客様のために AWS のサービスをさらに強力なものにしてくれました」

Amazon ではさらに、Oracle データベースの管理者に対して新たなキャリアパスに移行できるように最善の方法についても慎重に検討しました。彼らが AWS ソリューションアーキテクトになるために必要なスキルの習得を支援することが 1 つの選択肢でした。もう 1 つの選択肢としては、従来の Oracle ベース環境と AWS クラウド環境の橋渡しを行う際に、Oracle 経験が役に立つ管理職としての役割でした。

AWS への移行により、移行後に大容量のプロビジョニングを行ったにもかかわらず、Amazon のデータベース運用コストは半分以下に削減されました。データベース管理とハードウェア管理のオーバーヘッドが大幅に削減され、チーム間のコスト配分が以前よりもはるかにシンプルになりました。Amazon DynamoDB に再プラットフォーム化されたほとんどのサービス (通常は最高レベルのクリティカルサービスで、なおかつ大規模環境での高可用性と 1 桁台のミリ秒のレイテンシーが求められる) では、2 倍のトランザクション量を処理できるようになったにもかかわらず、レイテンシーを 40% 削減できました。サービスチームには移行中、サービスをさらに安定させ、技術的な負債を排除し、すべてのコードと依存関係を完全にドキュメント化することにも取り組みました。

プロジェクト範囲を振り返ると、この移行は 800 のサービス、数千のマイクロサービス、数万の従業員、数百万のお客様に影響を与え、Amazon の AWS データベースフットプリントは AWS の他のお客様の 90% が占めるフットプリントよりも大きくなりました。Amazon.com での取り組み事例は、同様の移行を検討している他のエンタープライズにとっても教訓となっています。

「この移行プロジェクトに関与した人は、シンプルだったとも、簡単だったとも、楽しかったとも言わないが、特殊な能力は必要なかったと言います。Amazon のような企業が、これほどまでにグローバルに分散した多くのチームが利用するデータベースを、Oracle から AWS に移行できるのであれば、ほぼすべての企業でも行こうができるといえるでしょう」