![[re:Invent2019] [レポート] DAT359 – Amazon.com がどの様にしてOracle DatabaseからAWSのデータベースに移行したのか #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2019/12/reinvent2019_report_eyecatch.jpg)
[re:Invent2019] [レポート] DAT359 – Amazon.com がどの様にしてOracle DatabaseからAWSのデータベースに移行したのか #reinvent
しばたです。
今年の8月にAWSがAmazon.comのデータベースをOracle DatabaseからAWSの各種データベースに完全移行したとアナウンスし話題となりましたが、その詳細を聞けるセッションがあったので大喜びで参加してきました。
セッション情報
DAT359 - How Amazon.com migrated its applications from Oracle to AWS databases
Amazon.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
配信動画
Database Freedom
最初はこちらのビデオ紹介から。
このビデオを含めて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に移行する際のあるあるをまとめた以下のブログ記事が紹介されました。
戦略5. Work with AWS team
最後の戦略としてAWS Teamとの協力が挙げられましたが、ここは割とふわっとした内容でした。
移行の結果
データベース移行の結果、
- 約7500のOracle DatabaseがRDS、またはAuroraへ
- 303のクリティカルなサービスがDynamoDBへ
移行され、
- 40%~90%の運用コストが浮いた
- 2倍~4倍の負荷に対して40%のレイテンシーが改善された
- (Prime Dayなどの)ピーク時への準備に対するオーバーヘッドが10倍改善された
といった成果が上がったそうです。
そして、この成功の要因として
- データベースは目的に応じたものを使う、マネージドなサービスを使う
- リーダーシップ
- 教育
- AWSとの協力
- 変わることへの情熱をもったコミュニティ
- ドキュメント化と啓蒙
といった点を挙げ、ケーススタディとして以下のページが紹介されました。
最後に
非常に多くの要素からなる面白いセッションでした。
レポートとしてこの記事をまとめてみましたが、まとめきれない部分も沢山ありそういった部分も面白かったのでできれば動画を直接見ていただきたいです。
![[アップデート] RDS for OracleがOracle Multitenantのマルチテナント構成をサポートしました](https://devio2023-media.developers.io/wp-content/uploads/2023/08/amazon-rds.png)
