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

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

Clock Icon2017.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

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

(2017/06/16追記:)イベント公式の関連資料及び動画が公開されましたので展開します。

セッション概要

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

スピーカー:
神野 旬 様
株式会社ゲオホールディングス 業務システム部 ゼネラルマネージャー

セッション概要:
ゲオホールディングスでは、ゲオ、セカンドストリート、ウェアハウス、ゲオモバイル等、約 1700 店舗を運営しています。 その事業を支えている DB はどのようになっているのか、今後どうしていくのか、移行時につまずいたところも交えてご紹介します。

セッションレポート

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

会社紹介

  • 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への移行の先駆けとしての貴重な事例になりそうです。資料が公開されれば、更新したいと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.