この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ご機嫌いかがでしょうか、豊崎です。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がダウンしたら
- オンライン注文に影響が出るだけではない
- 注文済み商品の発送や支払い処理も停止していた
- 中心となるDBがダウンしたら
- モノリシックから複数のへ分割
- 注文サービスやクレジットカード決済サービスなどサービスごとに分割したアーキテクチャへ
- 各サービスごとに拡張が可能
- SOAの考えを実装
- しかしRDBのスケーラビリティ部分に課題は残った
- キャパシティオーバーに対しては垂直なスケールで対策
- スケールアップにはダウンタイムが発生する
- また垂直スケールにはハードウェア限界がある
- スケールアウトによる負荷分散を検討
- データベース シャーディングで対応
- データベースはキャパシティオーバーになるとデータを分割配置することで分散をはかる
- どのデータがどのデータベースに格納されているかはシャードトラッカーで管理
- データはシャードキーによって格納されるデータベースが決まります。
- アプリはシャードトラッカーで処理したいデータがどのデータベースにあるか判断して適切なデータベースに接続する
- データモデルや基盤となるデータベースアーキテクチャを変更することなくシステム全体の処理量が増加
- Amazonのビジネスがさらに拡大
- データベース及びデータ量が膨大に
- 2017年時点で
- データベース数：7000
- 総データ量：70PB
- 世界中で数百万の受発注、決済、処理
- 分析対象データ
- データ量：50PB
- テーブル数：75000
データベースを移行した理由
- 決断に至った課題
- スケーリングの問題
- プライムデーなどの大規模イベントの拡張作業に60週間もかかるチームがあった
- ベンダーからのサポートを受けていてもスケール時の障害リスクが高かった
- 夏のプライムデー、冬のブラックフライデー&サイバーマンデーで年２回のピークが発生
- スケーラビリティは重要な課題に
- レイテンシー問題
- 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の移行での成功例、大変参考になりました。
7
