【レポート】担当者だったら心をかなり強く持つ必要がある…世界最大規模のECサイト移行ミッション!Amazon.com におけるデータベース移行事例 #AWSSummit

2020.09.09

ご機嫌いかがでしょうか、豊崎です。2020年9月8日から30日まで開催されるAWS Summit Onlineを自宅から拝聴しています。

本記事で取りあげるセッションは、「Amazon.com におけるデータベース移行事例」です。

セッション情報

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 北澤 英崇

概要

Amazon.com では、オンプレミスで稼働していたシステムを AWS へ移行しました。この移行では、これまで利用していた商用データベースから Aurora with PostgreSQL Compatibility などの AWS データベースへの移行を実施しています。本セッションでは、このデータベース移行をどのように実現したか、移行プロジェクトを推進するにあたって実際に行ったチャレンジ、データベース戦略についてお話ししたいと思います。

レポート

Amazon.comのレガシーデータベース基盤

当初(1995年)のAmazon.comは以下のようなUIサイトでした。

  • 見た目はシンプルですが、バックエンドのアーキテクチャは当時最も革新的なシステムの一つだった
    • WEBアプリケーションサーバからの注文
    • 注文データをOracleDBに格納
    • 商品が発送後、トランザクション完了前に銀行とお客様のクレジットカード会社の支払い処理を実行

  • しかしビジネスが大きくなり、より多くの注文が発生すると様々な様々な問題が発生する
    • 中心となるDBがダウンしたら
      • オンライン注文に影響が出るだけではない
      • 注文済み商品の発送や支払い処理も停止していた
  • モノリシックから複数のへ分割
    • 注文サービスやクレジットカード決済サービスなどサービスごとに分割したアーキテクチャへ
    • 各サービスごとに拡張が可能
    • SOAの考えを実装

  • しかしRDBのスケーラビリティ部分に課題は残った
    • キャパシティオーバーに対しては垂直なスケールで対策
    • スケールアップにはダウンタイムが発生する
    • また垂直スケールにはハードウェア限界がある

  • スケールアウトによる負荷分散を検討
    • データベース シャーディングで対応
    • データベースはキャパシティオーバーになるとデータを分割配置することで分散をはかる
    • どのデータがどのデータベースに格納されているかはシャードトラッカーで管理
    • データはシャードキーによって格納されるデータベースが決まります。
    • アプリはシャードトラッカーで処理したいデータがどのデータベースにあるか判断して適切なデータベースに接続する
    • データモデルや基盤となるデータベースアーキテクチャを変更することなくシステム全体の処理量が増加

  • Amazonのビジネスがさらに拡大
    • データベース及びデータ量が膨大に
    • 2017年時点で
      • データベース数:7000
      • 総データ量:70PB
      • 世界中で数百万の受発注、決済、処理
      • 分析対象データ
        • データ量:50PB
        • テーブル数:75000

データベースを移行した理由

  • 決断に至った課題
    • スケーリングの問題
      • プライムデーなどの大規模イベントの拡張作業に60週間もかかるチームがあった
      • ベンダーからのサポートを受けていてもスケール時の障害リスクが高かった
      • 夏のプライムデー、冬のブラックフライデー&サイバーマンデーで年2回のピークが発生
        • スケーラビリティは重要な課題に
    • レイテンシー問題
      • Amazon,comにとってレイテンシーの改善は非常に重要なファクター
      • データ量、ユーザ数が増えていく中で改善をするためには2-4倍の改善が必要だった
      • データは70PBかつ指数関数的に成長
        • 運用管理のコストが膨大
    • ハードウェア、ソフトウェアに関する問題
      • システム規模が大きくなるにつれてコストが過剰にかかっていた
      • ハードウェアについては納品設置までのタイムラグ
        • 納品タイミングとビジネス的に必要な時期を合わせることが困難
      • ソフトウェアについてはベンダー側のライセンス変更によってコストが上がってしまう
    • 拡張性、可用性と運用のリスク
      • スケールアップとスケールダウンの両方が必要だった
        • ピークイベントに伴う必要キャパシティの山がくる
        • それ以外についてはスケールダウンを求められた
      • データに関する一貫性
        • Amazon.comの規模では非常に難しい問題
  • これらの問題によってAmazon.comはクラウドを決断する

移行戦略と学んだ教訓

  • Amazon.comはOracleを停止して約7500のデータベースの移行が完了したことを2019/10に発表
  • 移行元のOracleはRDBだが移行先は目的別に作られたデータベースをコンセプトとした
    • 適材適所のデータベースを利用する
    • より高いパフォーマンス、可用性が求められる場合はDynamoDB
    • DWH用途の場合は、Redshift
    • RDBを使う場合でもAmazon AuroraやAmazon RDS

データベースの移行

  • AWS Database Migration Serviceや、AWS Schema Conversion Toolを活用
  • AWS DMSはデータベースのデータを移行するためのサービス
    • OracleからPostgreSQLなど異なるデータベースエンジン間での移行が可能
  • AWS SCTは異なるデータベース間でのテーブル定義、スキーマ、ストアドプロシージャを変換

具体的な移行戦略

#1:可視性の向上
  • データベースの全体像が把握できていなかった
    • データベースのメタデータを取得し、接続ログを分析し関連性を可視化
    • また新たなデータベースや移行完了したデータベースの情報も付与
    • それにより移行のオーナーの明確化、影響範囲、移行進捗状況が可視化された
  • テーブルの使用状況やスキーマに関する詳細情報が必要となった
    • CRUD(Create/Read/Update/Delete)の情報収集を開始
    • マテリアライズドビューによる相関が追跡可能に
  • アプリケーションが利用しているテーブルの可視化
    • Java ClassのWrapperを作成してAppが実行するSQLを分析
    • AppのSQLレベルで収集分析することで可視化が可能に
  • 可視化によって綿密な移行計画の実行が可能になった

#2:経営陣からのサポートを加速
  • 当初経営陣が移行計画の状況を把握できていなかった
    • 複数のダッシュボードを作成
    • データベース移行の進捗を可視化したグラフ
    • 進捗を把握し説明責任を果たすためのレポート体制

#3:社内のOracleDBAからの支援を得る
  • 当初OracleDBAからの反発があった
    • 反発の原因は移行に対する疑念や恐れ
    • 実際の技術的課題とは違った
    • FUD:Fear Uncertainly Doubt(恐れ、不確実性、疑念)
  • 移行によるメリットを考える
  • OracleDBAへのキャリアパスとトレーニング機会を提供
    • DB移行スペシャリスト
    • データベースエンジニア
    • システム開発エンジニア
    • ソリューションアーキテクト
    • AWS認定資格者
    • などなど

#4:移行エンジニアの増強
  • 各チームのDB移行のプロフェッショナルを作ろうと考えていた
    • 当初、プロフェッショナルの育成がうまくいかなかった
    • 情報のシェアをすることで育成が加速
      • 定期的な勉強会
      • リファレンスアーキテクチャ
      • ベストプラクティス
      • デザインパターン
      • Tipsのシェア
      • など

デザインパターンの例
  • OracleからAuroraへ移行する際の段階的な移行を想定したリファレンスアーキテクチャ
  • 以下例ではオンプレミスにOracleがありAWS DMSを使用してAmazon Aurora PostgreSQLへデータ移行している
  • 移行データについては継続的に検証する

  • 左側のアプリケーションは2つに分かれている
    • 1つは移行前のOracleDBに対するサービスコール
    • もう1つは移行済みのDBに対するサービスコール
  • DBはスキーマ単位で移行を行うなど、全体が移行完了していない場合も想定
    • APIを複数用意し段階的にアプリケーションを移行する

  • 移行先に予期しない問題が発生した際のOracleへの切り戻しも検討する
  • 切り戻しを想定し、Aurora PostgreSQLからRDS OracleへAWS DMSでデータを複製
  • 予期しない問題で切り戻しが必要な場合でも、オンプレではなくAWS上での切り戻しが行える

移行の効果

  • 約7500のデータベースをOracleからAuroraもしくはRDSに移行
  • 303以上のビジネスクリティカルなサービスをDynamoDBに移行
    • 商用のデータベースからの脱却し、ビジネス観点でのデータベースの選択が可能に
  • 運用管理コストの削減
    • 40-90%削減
  • レイテンシーの改善とイノベーションを実現
    • 処理量が2-4倍になるもレイテンシーは40%削減
  • プライムデーの様なイベント時のシステム拡張作業個数鵜の削減
    • 1/10に削減

Amazon.com 事例コンテンツは以下からご参照いただけます。

感想

クラウドへの移行を検討した時に多くのシステムではデータ移行について検討を行う必要が出てきます。巨大ECサイトであるAmazon.comの移行での成功例、大変参考になりました。