[S-15] Amazon.com における Oracle データベースの移行メモ

1 聞いた日
2 概要
3 スピーカー
4 内容
5 感想

聞いた日

2020/04/16

概要

[S-15] Amazon.com における Oracle データベースの移行

Amazon.com では、これまで Oracle Database を活用していたシステムを AWS へ移行しました。本移行では、これまで利用していた Oracle から Aurora with PostgreSQL Compatibility などの AWS データベースへの移行を実施しています。本セッションでは、この移行をどのように実現したか、Oracle からの PostgreSQL へ変更するにあたって実際したチャレンジ、データベース戦略についてお話したいと思います。

スピーカー

高橋敏行
アマゾンウェブサービスジャパン株式会社 / パートナーソリューションアーキテクト

内容

イントロ

ビジネス遷移でスケールしていった結果
手法：データベースシャーディング。シャード番号ごとに DB インスタンスを分ける。
2017 年時点
総データ量 75PB。
7500OLTP のデータベース。
チーム数 100 以上、数千以上のアプリケーションで利用されていた。
60 万分析ジョブ/日
etc…プライムデー、ブラックフライデー、サイバーマンデーなどで更なるスケーラビリティが必要となっていった。

課題

運用コスト、レイテンシー、ハードウェア・ソフトウェアのライセンスコスト、可用性などなど。

対策方針

可視性の向上
- DB 接続ログでネットワーク図のようなものを作り、誰が使うのかを可視化。
- スキーマの CRUD 収集、マテリアライズドビューを木構造で表現。
- アプリケーションと DB の可視化のため、SQL Tracker を開発（Java で作った）
FUD（Fear Uncertainly Doubt) と技術的課題
DBA からの支援を得る必要があり、キャリア・トレーニングの機会を提供。
フォースマルチプライヤー
移行のプロフェッショナルが必要。
設計パターン、リファレンス、Tips を共有

移行例

AWS Database Migration Service （DMS）を使用して、Data Validation により移行できたか確認。
移行が終わったサービス、移行が終わっていないサービスで呼び出しを分ける。
「切り戻し」のためにレプリケーション用の Amazon RDS Oracle に、DMS へ移行後のフェールバックを行う。
という戦略。

技術的課題

移行に関して、様々な技術的課題があった。
例えば PostgreSQL の空白文字と null の扱いの違い。
そのため移行前に null を埋めたりする必要があった。

Oracle:Empty string == null
PostgreSQL:Empty string != null

詳細はこちら。
AWS Blogs:How to solve some common challenges faced while migrating from Oracle to PostgreSQL

移行に関するツール

AWS Database Migration Service （DMS）
移行できるできないの対象はホワイトペーパー参照。
AWS:AWS Database Migration Service のリソース
AWS Schema Conversion Tool(SCT)
DB スキーマ、DML を対象とする DB のフォーマットに変換する。

移行の効果

結果、7,500 の Oracle を RDS/Aurora へ移行。

運用管理コストは 40-90%削減
パフォーマンスは処理量 2-4 倍でもレイテンシー 40%削減
スケーリング作業工数は 1/10
この規模の作業工数なので、尋常じゃない時間が削減される。

まとめ

従来の課題をクラウドで解決できた
DB が目的によって選択可能となった
トレーニング、キャリアパスの形成支援をおこなった
リファレンスとしてナレッジ共有した

成功のドキュメント化もしたそうです。
How Amazon is Achieving Database Freedom Using AWS

クイズ

Q:データベースの移行において、アプリケーション毎の段階的な移行は重要な要素になります。今回ご紹介した Amazon.com でも、ダウンタイムを減らして、段階移行ができるようにアーキテクチャーの工夫を行っています。具体的には、アプリケーション毎にデータベースエンジンを選んで接続できるようにしています。どのようなアーキテクチャーを採用しているでしょうか？
動画最後（29：10 ～）より引用。

A:アンケート回答後に表示されるそうです。（URL 載せていいか分からなかった）

感想

すさまじい規模感で、工数や管理コストがごりごり削れてて気持ちいい。
DB の移行はいずれ起こりえる内容なので、是非とも知っておいた方がいい内容だと考えました。

DBA との折衝案としてキャリア形成を仕組みとして設けたのは感心したし、上手だなーという思い。「効率化の観点で改善すべきことを、いざやってみたら他の誰かの面目がつぶれてしまった。」という理由で解雇された。人がいるなかで、こういうアプローチも必要なのかなーと感慨深い。
おことわりとして、解雇された人を否定したいつもりはなく、むしろ効率化改善は積極的にすべき考えです。
つい最近、みんなの Python 勉強会#56 でもお話があったとおり、「差別化に繋がらない重労働を」を「自分でやらない」というのは滅茶苦茶アグリーなので。