【レポート】AWS Summit Tokyo 2017：ゲオを支える DB 基盤の歴史と未来　～Oracle から Amazon Aurora へ～ #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『ゲオを支える DB 基盤の歴史と未来　～Oracle から Amazon Aurora へ～』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

以下、セッションレポートです。

会社紹介

• DVDやゲーム、リユースの為の店舗、アミューズメント店舗も
• 内製でアプリ開発
  • 自社プリペイドカード「ルエカ」
  • セルフレジも開発
• 2nd STREET USAをLAに店舗オープン予定！！！

インフラ概要

• 比較的オーソドックスな使い方だが、多数のAWSサービスを使っている
• EC2は全部で150インスタンスくらい
• ネットワーク
  • 小さい店舗はインターネットVPN
  • 大きな拠点はキャリア網
  • USAはインターネット経由で
• Azureも利用してマルチクラウドで運用
• AWSアカウントは4つ
  • 本番
  • 本番セキュア
  • 2nd STREET USA
  • 開発
• 集計システム
  • レンタル実績に応じて、新作・旧作の区分を集計、変更
  • Oracle Exadata: 10h -> Redshift: 2.5h(転送、書き戻しは含まない)
• 監視運用
  • 死活
    • Zabbix
    • Slack
    • Twilio
  • リソース
    • スケジューラで自動起動/停止
  • バックアップ、CPUクレジット監視
    • タグ活用
    • Lambda活用
  • ログ保管、検索
    • Slack
    • Lambda -> S3 -> Athena

DBの歴史と遷移

• OracleおよびMS SQL Server複数台をDB Linkで構成していた
  • ネットワーク断で同期ができなくなる
  • DB連携はテキストを利用するように変更
• 分散しているDBをOracleバッチ系と、Oracle RACオンライン系に集約した
  • 集約しすぎてリソース枯渇
  • Exadataにして解決
  • それでもOLTPもDWHの併用はきつかった

ExadataからOracleEE on EC2への移行

• 目的
  • Oracle保守切れ
  • Exadata側の不具合にも何度か当たった
  • スケジュールとしては4〜5ヵ月で移行
• ポイント
  • FullアクセスをやめてディスクIOを減らしCPUを使用するインデックスチューニングを実施
  • 苦手なところは他にオフロード
    • 高負荷バッチ処理をRedshiftに
    • インメモリDBも利用
  • EBSは複数の汎用SSDを並べてコストを抑えつつ、スループットを確保
  • 今ならDMSも利用可能
• EBS構成
  • 合計50TB/実容量11TB
    • PIOPSを確保する為に実利用量より多くEBSを用意した
  • Oracle ASMでボリュームを分散
  • UNDO、TEMPはPIOPSでスループット確保
• 移行でつまづいたところ
  • AWSの各種上限に引っかかった

OracleからAuroraPostgreSQL互換への移行

• 目的
  • 脱Oracle、コストDOWN
  • ライセンスも運用コストも
• 移行スケジュール
  • 概ねテストは終わっているが、PostgreSQL互換AuroraはまだGAになっていない
  • 来年夏を目処に現在移行中
• 移行対象は会員情報が格納されたDB
  • セキュリティ
    • 操作は全て録画
    • AWS側のIAMで制限
    • MFA
• ワークロード
  • 小さめのSQLが多く、並列度が高い
  • 稀にバッチ系の大きめのSQL
  • 4000万件超のデータ
• 移行候補
  • これらを比較検討した
    • EDB Postgres
    • RDS PostgreSQL
    • Aurora MySQL
    • AUrora PostgreSQL
• Oracle PostgreSQLの違い
  • DB LInk(FDW)は速度があまり出ない
  • パーティションはちょっと使いづらい
  • PL/SQLの移行が一番大変
  • DDLもロールバックできる
  • 表現や関数の違い、同じ名前でも意味が違う場合もある
• SCT
  • DB移行を補助してくれるツール
  • スキーマ単位でのSQLで出力して微調整
  • シノニムが存在しないため、検索パス指定をしたりした
• DMS
  • フルーロード、差分転送ができる
  • 200GB、テーブル13、データ6.4億件
  • 並列度、CommitRate、インスタンスタイプをチューニングして、4日->10hに短縮成功
  • インデックスは別で作った方が早いかも
• テスト
  • テスト環境を作るのが楽
  • 本番同等のリクエスト
• 移行手順
  • DMSでダウンタイムを小さくすることができた

AWS移行後

• 良かったこと
  • 開発エンジニアがインフラに興味を持つようになった
  • ハードにかかるコストを意識増
  • サイジング不要、構築しながら調整
  • インフラのリードタイム減
  • エンジニアのモチベーションUP
  • 本番同等のテストが簡単にできる
  • オンプレに比べ、故障頻度が下がった(たまたまかも？)
• 気をつけた方が良いこと
  • 最低限のルールは作らないと無法地帯に
  • クラウドのメリットは残しつつ
  • 何でもタグをつけておく
  • RI購入がドキドキする、ちょっとわかりづらい
  • AWS都合のEC2再起動が少し手間
  • 落ちる前提で作る、必要に応じて冗長化
  • 稀にリソース枯渇で起動できないインスタンスタイプがある
  • AWS側の障害の場合、待つことしかできない
• Exadata->OracleEEonEC2
  • シングル構成のため、RACより可用性は下がっているが、実際は停止時間は減っている
  • EBS性能を確保する為にコストが想定よりもコストがかかっている
  • IOは負けるが、チューニングや他サービスとの組み合わせで改善
• OracleEE->AuroraPostgreSQL互換
  • Auroraはとにかくメリットが多い
  • DBA不要

まとめ

• レガシーな基幹系でもやり方次第でコストを抑えてAWSに移行できる
• 基幹系で使用している大規模なOracleでも、PostgreSQLやAuroraに移行することが十分可能
• DMS/SCT非常に便利なので活用必須

感想など

実体験に基づいたノウハウの詰まったセッションでした。まだGAとはなっていませんが、PostgreSQL互換Auroraへの移行の先駆けとしての貴重な事例になりそうです。資料が公開されれば、更新したいと思います。