[re:Invent2019] [レポート] DAT359 – Amazon.com がどの様にしてOracle DatabaseからAWSのデータベースに移行したのか #reinvent

AWS re:Invent 2019

#Oracle

#AWS

Takuya Shibata

2019.12.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。
今年の8月にAWSがAmazon.comのデータベースをOracle DatabaseからAWSの各種データベースに完全移行したとアナウンスし話題となりましたが、その詳細を聞けるセッションがあったので大喜びで参加してきました。
 セッション情報
 DAT359 - How Amazon.com migrated its applications from Oracle to AWS databasesAmazon.com recently completed its enterprise database migration to AWS. In this session, Amazon.com leaders relay how they achieved database freedom with AWS. They discuss the enterprise program they built, and they share the lessons they learned and the benefits they realized. They also share how they reduced third-party and scaling risks to deliver peak retail events, such as Amazon Prime Day, Amazon Black Friday, and Cyber Monday.
Doug Booth - Principal Business Development Manager, Amazon Web Services
Thomas Park - Sr. Manager, Software Development
 配信動画https://www.youtube.com/watch?v=vPF9l9OmiXE
 Database Freedom最初はこちらのビデオ紹介から。
https://www.youtube.com/watch?v=9yBP5gnnZi4
このビデオを含めてAWSのデータベース移行に関するナレッジがDatabase Freedomというサイトにまとめられています。
Database Freedom : https://aws.amazon.com/databases/freedom
 Amazon's Legacy Database Infrastructure続けてAWSサービスに移行する前のアーキテクチャの変遷が紹介されました。
最初はシングル構成からはじまり、
サービス毎にデータベースを分割、
データベース内でもシャーディングを実施
年々規模が増していき、2017年には
635ノード、27クラスターのRAC、ディスクの本数は100000超え
DWHデータベース
50PBのデータサイズ
75000のデータウェアハウステーブル
600000を超える分析ジョブが毎日実行される

OLTPデータベース
75PBのデータサイズ
データベース数は約7500
世界中の何百万もの注文や支払い、フルフィルメントと取り扱う

の様な規模感にまでなったとの事でした。
 移行の要件ここからがデータベース移行のはなしになるのですが、まずは移行に求められる3つの要件について触れられました。
Service availability
Data availability
Migration time
ほぼ100%のサービス可用性、データの一貫性、ダウンタイム無しが求められる厳しい要件です。
 移行の理由以下の5点が移行の理由に挙げられました。
グローバルに増え続けるデータ量のスケーラビリティに対するリスク
データ量、トランザクション量が増えることによるレイテンシーのリスク
ハードウェア/ソフトウェアコストのリスク
レガシーなアーキテクチャ・コードであることによる可用性のリスク
ハードウェアをプロビジョニング、管理することの運用リスク
Black Fliday、Cyber Monday、Amazon Prime Dayといったピークの発生するイベントに対する準備が特に問題となっていた様で、幾つかのチームではPrime Dayといったイベントのためのスケールに60週もかかる問題に直面していたそうです。

特にPrime Dayに関しては年々規模が大きくなる上に、(Cyber Mondayも含めると？)半年ごとにピークイベントが発生するため喫緊の問題となっていたそうです。
 移行戦略と学びここからは実際のデータベース移行での学びについて触れられました。
 戦略1. Increase your visiblity移行前のデータベースは数多くのチームにより利用されているものの利用状況をトラッキングできるシステムが無かったため作り上げる必要があったそうです。
一つのデータベースにも多くのテーブルがありそれを様々なチームが更新を掛けていく状況にあり、オーナーは誰なのか？
テーブルレベルでの各種利用状況(依存関係/CRUD/オブジェクトオーナー/接続状況など)の可視化
移行のバーンダウンチャート
プロジェクトステータス
移行ステータス
といった様々な情報を可視化しトラッキングしたとの事です。
 戦略2. Accelerate executive supportここで触れているexecutiveが具体的にどの層を指すのかいまいち聞き取れなかったのですが、どうもAmazon側各チームの幹部クラスを指している様で、データベース移行状況を可視化しCEOとのレビューを可能にするダッシュボード作成することで彼ら・彼女らのモチベーションと移行の優先度を上げさせ実績を上げたそうです。
 戦略3. Address FUD and real technical issues次に技術的な問題とFUD(Fear Uncertainty Doubt)への対策について触れられ、FUDについては特に移行前Oracle DatabaseのDBAからの懐疑や反発が強かったそうです。

データベース移行にはOracle DBAの協力が不可欠なためデータベース移行後のキャリアパスの提示やAWSデータベースサービスに対する教育を行うことで対策したとの事です。
 戦略4. Create force multipliersデータベース移行の初期段階で多くのチームが同じ様な失敗を経験していることを把握したため、リファレンスとなるアーキテクチャやベストプラクティスをまとめ共有することで各チームの底上げをしたそうです。
セッションでは一例としてOracle DatabaseをAurora PostgreSQLに移行する際のパターンとして、移行先のAWS環境にフェイルバック用のOracle RDSを用意し切り戻しに備えるというものと、
また、Oracle DatabaseをPostgreSQLに移行する際のあるあるをまとめた以下のブログ記事が紹介されました。
How to solve some common challenges faced while migrating from Oracle to PostgreSQL
 戦略5. Work with AWS team最後の戦略としてAWS Teamとの協力が挙げられましたが、ここは割とふわっとした内容でした。
 移行の結果データベース移行の結果、
約7500のOracle DatabaseがRDS、またはAuroraへ
303のクリティカルなサービスがDynamoDBへ
移行され、
40%~90%の運用コストが浮いた
2倍~4倍の負荷に対して40%のレイテンシーが改善された
(Prime Dayなどの)ピーク時への準備に対するオーバーヘッドが10倍改善された
といった成果が上がったそうです。
そして、この成功の要因として
データベースは目的に応じたものを使う、マネージドなサービスを使う
リーダーシップ
教育
AWSとの協力
変わることへの情熱をもったコミュニティ
ドキュメント化と啓蒙
といった点を挙げ、ケーススタディとして以下のページが紹介されました。
https://pages.awscloud.com/AWS-Innovators-Amazon.html
 最後に非常に多くの要素からなる面白いセッションでした。
レポートとしてこの記事をまとめてみましたが、まとめきれない部分も沢山ありそういった部分も面白かったのでできれば動画を直接見ていただきたいです。