[レポート]Amazon.com: 大規模なエンタープライズデータベースの移行 #AMZ301 #reinvent

はじめに

こんにちは、崔です。

セッション：AMZ301 - Amazon.com: Enterprise database migration at scale に参加しましたので、そのレポートをお届けします。

こちらのセッションは、Amazon.comがOracleデータベースの移行を完了した、という次のブログの詳細になります。

• 移行が完了– Amazon のコンシューマー向けビジネスが最後の Oracle データベースを停止

セッション概要

Amazon.com has a long history in data. To reduce scaling risks and third-party dependencies it chose AWS database services like Amazon DynamoDB, Amazon Aurora, Amazon Relational Database Service (Amazon RDS), and AWS Database Migration Service (AWS DMS). In this session, you learn how it focused on critical, customer-facing services that include the Amazon consumer and digital businesses’ largest database workloads. Learn how Amazon.com achieved database freedom with AWS. Additional topics include lessons learned, benefits realized, and how Amazon.com delivers the biggest peak retail events such as Prime Day, Black Friday, and Cyber Monday.

Amazon.comにはデータの長い歴史があります。スケーリングのリスクとサードパーティの依存関係を減らすために、Amazon DynamoDB、Amazon Aurora、Amazon Relational Database Service（Amazon RDS）、AWS Database Migration Service（AWS DMS）などのAWSデータベースサービスを選択しました。このセッションでは、Amazonコンシューマーおよびデジタルビジネスの最大のデータベースワークロードを含む重要な顧客対応サービスにどのように焦点を当てたかを学びます。 Amazon.comがAWSでどのようにデータベースの自由を実現したかをご覧ください。その他のトピックには、学んだ教訓、実現した利点、およびプライムデイ、ブラックフライデー、サイバーマンデーなどの最大のピーク小売イベントをAmazon.comが配信する方法が含まれます。

スピーカー

• Doug Booth - Principal Business Development Manager, Amazon Web Services
• Thomas Park - Sr. Manager, Software Development

セッションメモ

アジェンダ

• Amazon's legacy database infrastructure
• Reasons to migrate databases
• Migration Strategy and lessons learned
• Benefits realized
• Review of Documented Cased Studies

Amazon's Legacy Databse Infrastructure

In the beginning

• Amazon.comは最初はこんな1ページからスタートした
• その後、各サブシステム毎にOracle データベースを持つようになり
• 一つのデータベース内に収まらなくなったものは、シャーディングで対応した

Legacy database infrastructure in 2017

• 2017年の段階で、OLTPデータベースはおよそ7,500のデータベース、合計75PB
• 75,000のDWHのテーブル、50PBのデータ
• Oracle RACは27クラスター、635ノード

Reasons to migrate databses

移行要件

• サービス稼働
  • ほぼ100%使用可能でフルスケールすること
• データの可用性
  • 全てのデータはいつでも利用可能で整合性が取れいていること
• 移行時間
  • ダウンタイムが全くない、もしくは僅かな時間で移行を完了すること

Reasons to migrate

• データ量の増加とグローバル市場の拡大によるスケーラビリティのリスク
• データ量とトランザクション率の増加によるレイテンシーリスク
• ハードウェア/ソフトウェアコストの増加によるコストリスク
• レガシーなコード/アーキテクチャによる可用性リスク
• ハードウェア層のプロビジョニング/運用時間/リソースによる運用リスク

Managing scaling issues

• 一部のチームは、プライムデーなどのピークイベントに合わせて60週にも及ぶスケールの問題に直面していた
  • （1年以上かかるのか。。)
• サードパーティの最高のサポートがある場合でも、スケールのリスクが高い

Improve latency and reduce operations costs

• Amazonとその顧客（特にリテール、Prime Video、Alexa）はレイテンシーに非常に敏感で、2倍から4倍の負荷増大において、40%の改善を見せた
• 指数関数的に増加する75PBのデータを管理するには費用と時間がかかる
• 一部のチームは、マネージドサービスを利用することで運用コストを90%削減できた

Availability and operations risks

• データベースをスケールアップ／ダウンすることが必要だった
• 数百人の担当者がレガシーシステムを管理／スケールしていた
• オペレーションは信頼、予測、計測できないといけない
• データは100%の可用性が必要だった
• データは100%の整合性が必要だった

PRIMEDAY drives need for massive scalability

• プライムデーを追加すると、ピークを計画するための1年がなくなった
• 現在、6ヶ月毎にピークイベントが発生しているため、計画とスケールに半分の時間しかない
• 2015年には、34.4百万の商品が9カ国で注文されていた
• 2019年には、175百万の商品が18カ国で注文された。Amazon.comの歴史の中で最も大きなショッピングイベントだった。

Migration Strategy & Lessons Learned

当時、Oracleデータベースの空き領域がすぐになくなるので、データベースの追加を実施していた。

Database Migration

2019/10にAmazon.comの75PBのOLTPデータベースの巨大な移行を完了した。
どのようにダウンタイムなしで移行したのか共有したい

Strategy #1: Increase your visibility

• 良く定義されたKPIと成功のメトリクスが移行の進捗をトラッキング可能にする
  • どれだけの数のOracleデータベースを所持していますか？
  • どれだけの新しいOracleデータベースをローンチしましたか？
  • どれだけのOracleデータベースを移行/廃止しましたか？
  • 誰がデータベースの所有者ですか？

• OracleデータベースのInventory収集
• データベースのモジュールの依存性
• データベースのCRUD情報
• データベースオブジェクトのオーナー／タイプ情報
• DWHのジョブとDBコネクションの情報
• DBのバーンダウンチャート
• プロジェクトのステータス
• DBの移行ステータス

• SQL実行を1箇所でまとめて分析するためのjavaアプリケーション、SQLトラッカーを作成
• Amazon KinesisとElasticsearch Serviceを利用

Accelerate executive support

• 移行したデータベースの数（1ヶ月単位）

Address FUD and real technical issues

• Fear/Uncertainty/Doubt
• why not の多くの理由
• この調査の別の側面について考える
• 20年間移行しなかったことや適応するのに時間が必要なことを理解する

Get Oracle DBAs support

• DBAのサポートはDB移行のリスクを緩和したり、依存関係を特定するのに必要
• DBAにキャリアパスを与えたり、トレーニング機会を与える

Oracle to Amazon RDS/Aurora PostgreSQL

• AWS DMSを利用してOracleデータベースをAurora PostgreSQLへ移行
• 移行したアプリケーションは、Aurora PostgreSQLにデータを格納
• まだ移行していないアプリケーションは、Oracleデータベースを利用
• OracleデータベースとAurora PostgreSQLでデータバリデーションチェックを実施
• Aurora PostgreSQLからRDS Oracleへ、AWS DMSを利用してCDC移行を実施
• RDS Oracleは、Aurora PostgreSQLからフェイルバックする際に利用する想定

AWS Blog:"How to solve some common challenges faced while migrating from Oracle to PostgreSQL"

• OracleからAurora PostgreSQLへ移行した際の問題をどう解決したか
  • ソースからデータを抽出しているときに発生するORA-01555
  • データ型変換の問題
  • PostgreSQLの空白文字とnull
  • 複合一意インデックスのnull動作
  • PostgreSQLのnumericデータ型の選択(numericとBIGINTの比較)
  • PostgreSQLのSEQUENCEキャッシュ動作
  • PostgreSQLでのプレーンテキスト検索のパフォーマンス上の問題
• Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法
  （注）こちらのブログに詳しい説明があります。

Dynamic Connection

• DynamoDBのテーブル内で、各アプリケーションがOracleデータベースかAurora PostgreSQLのどちらを利用するかを管理していた
• Oracleデータベース側のテーブルBを更新する場合、AWS DMSでAurora PostgreSQL側へCDC移行して反映
• Aurora PostgreSQLの変更もAWS DMSを利用して、RDS Oracleへ反映

Benefits realized

Outcome

• Amazonは7,500のデータベースをOracleからRDS/Auroraへ移行した
• Amazonは303のビジネスクリティカルサービスをDyanamoDBへ移行した
• オペレーションコストを削減した
• レイテンシーを改善し、イノベーションを増加した

Benefits realized

• コスト削減
  • オペレーションコストが40%~90%削減
• パフォーマンス改善
  • 2~4倍のワークロードで40%のレイテンシー改善
• 管理コスト
  • マネージドデータベースサービスを利用することで管理コストを削減

まとめ

冒頭のブログ記事を読んだ時に、実際どのようにしてAmazon.comがOracleデータベースを全て移行したのか非常に気になっていました。
Amazon.comのシステム自体、非常に大きくなっており、オンプレミスのままでは管理が大変になってきたところで、AWSが提供するマネージドサービスに移行することで、コスト面やパフォーマンス面で非常に大きな改善があったようです。
毎月、数百単位のデータベース移行を完了させていくのは、正直非常に気の遠くなるような移行プロジェクトだと思いますが、フェイルバック用のRDS Oracleを準備したり、データのバリデーションを行ったり、メトリクスをしっかり監視することで、大きな障害なく完了したようです。
OracleからPostgreSQLへの移行時に苦労したところなど、公式ブログにもまとまっているのでしっかり理解しておきたいです。