ゲオを支える DB 基盤の歴史と未来 ~Oracle から Aurora へ ~ 2017/05/31 株式会社ゲオホールディングス業務システム部ゼネラルマネージャー神野旬 1
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 2
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 3
会社紹介 自己紹介 社名 株式会社ゲオホールディングス 会社設立 1989年1月 本社 愛知県名古屋市 売上高 2,680億円 (2017年3月期) 店舗数 1,805店 (グループ全体) メディアショップGEO 2nd STREET JUMBLE STORE ウェアハウス 神野 旬 かんの じゅん 業務システム部 ゼネラルマネージャー 4
自社プリペイドカード セルフレジ 自社プリペイドカード ルエカ ゲオグループで利用できるオリジナルプリペイドカードチャージ方法は現金 or 買取を選択可買取チャージの場合 10% の割増あり セルフレジ 751 店舗 合計 1,521 台導入済店別利用率は最大 92% 平均 46% レンタル利用でポイント付与 5
2nd STREET USA ロサンゼルスのメルローズに この夏 オープン予定 6
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 7
使用AWSサービス Direct Connect VPC VPC peering EC2 S3 EBS RDS Redshift DMS Cloud Watch Cloud Trail Config Trusted Advisor IAM Auto Elastic Load Lambda Scaling Balancing SNS Work Spaces Cloud Front Athena Certificate Manager 8
インフラ概要 Azure 事務所 Production 店舗 Confidential ＤＣ キャリア網 Internet VPN UTM Proxy SSUSA Development 1,800 Internet 9
AWS 使用例 2nd STREET USA 東京 オレゴン Work Spaces その他システム USA 店舗 Internet Internet HTTPS WEB WEB PC タブレット POS 管理業務 接客業務 10
AWS 使用例 AmazonRedshift 全店のレンタル実績に応じて 新作 旧作等の区分を集計 変更するシステム 月間レンタル件数 :5,000 万件 RDS For MySQL 1 必要なデータの転送 3 集計データの書き戻し 2 集計 Redshift 処理時のみ起動でコスト節約 OracleExadata: 10 時間 AmazonRedshift: 2.5 時間 (+ 転送 書き戻しの時間 ) 同じロジックのままでも高速化ただしExadataは他処理もあるため 平等な比較ではない 11
AWS使用例 監視 運用系 サーバの死活監視 Zabbix Agent 障害 検知 緊急性 低 Slack 緊急性 高 Twilio 検証中 リソース運用 ON OFF Job Arranger for Zabbix AWS CLI EC2 RDS等の ON OFFを行う 12
AWS 使用例監視 運用系 バックアップ CPU クレジット監視 EBS スナップショットの取得タグ設定通りの世代 時間 エラー CloudWatch Events Lambda T2 インスタンス CPU クレジット枯渇監視 閾値超え SNS 通知 ログ保管 検索 Slack Lambda S3 Athena 13
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 14
DB の歴史と遷移 店舗 DC 店舗 DBLink Oracle DBLink Oracle DBLink Oracle DBLink 店舗 DBLink Oracle Oracle 15
DB の歴史と遷移 店舗 DC 店舗 Oracle Oracle Oracle 店舗 Oracle Oracle 16
DB の歴史と遷移 店舗 DC DR Oracle バッチ系 店舗 転送 店舗 Oracle RAC 会員 DB オンライン系 DataGuard Oracle 17
DB の歴史と遷移 店舗 DC DR OracleExadata V2 (RAC) OracleExadata X2 ActiveDataGuard 店舗 DR & DWH 店舗 Oracle RAC 会員 DB オンライン系 DataGuard Oracle 18
DB の歴史と遷移 店舗 DC ここの移行 DR OracleExadata V2 (RAC) OracleExadata X2 ActiveDataGuard 店舗 DR & DWH Oracle RAC 会員 DB オンライン系 Oracle 店舗 DataGuard 19
DB の歴史と遷移 店舗 DR OracleEE on EC2 OracleExadata X2 ActiveDataGuard 店舗 Aurora Mysql 互換 DR & DWH アプリ OracleEE on EC2 会員 DB DataGuard Oracle 20
DB の歴史と遷移 店舗 DR OracleEE on EC2 OracleExadata X2 ActiveDataGuard 店舗 Aurora Mysql 互換 DR & DWH アプリ OracleEE on EC2 会員 DB DataGuard Oracle ここの移行 21
ＤＢの歴史と遷移 Azure 店舗 OracleEE on EC2 Data Guard Oracle DR用途 店舗 Aurora Mysql互換 アプリ AuroraPostgreSQL互換 会員DB Azure SQL DataWarehouse 22
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 23
Exadata から OracleEE on EC2 への移行 目的 Exadata 保守切れのタイミングでコスト DOWN と可用性 UP のため 別 DB へ移行する 移行スケジュール 2015/04 移行先決定 (AWS 上の OracleEE) 2015/05 プロジェクト開始 2015/09 移行完了 24
移行前構成 店舗実績データ DC DR DR & DWH その他システム処理 ActiveDataGuard リクエスト Oracle Exadata V2 (RAC) Oracle Exadata X2 25
移行後構成 店舗実績データ DR OracleEE on EC2 DR & DWH その他システム処理 ActiveDataGuard リクエスト 部分一致検索 インメモリ DB 高負荷バッチ処理 Redshift Oracle Exadata X2 26
移行のポイント Full アクセスをやめてディスク IO を減らし CPU を使用するインデックスチューニングを実施 普通の Oracle で Exadata に劣る部分は別の仕組みへオフロード ( インメモリ DB Redshift) EBS は複数の汎用 SSD を並べることで コストを抑えつつ スループット IOPS を確保 停止できないシステムは 移行前にデータを差分転送し 停止時間を極力短くして移行 27
EBS 構成 Oracle on EC2 PIOPS 3.4TB 2 本 汎用 SSD 3.4TB 11 本 汎用 SSD 3.4TB 2 本 UNDO TEMP 用 データ領域用 REDO 用 合計約 50TB / 実容量 11TB OracleASM でボリュームを分散 UNDO TEMP はスループット確保のために PIOPS を選択 28
移行でつまずいたところ EBSのIOPS/スループット上限 汎用SSD 10,000 IOPS スループット160MB/s PIOPS 20,000 IOPS スループット320MB/s EC2のスループット上限 r3.8xlarge 10Gbit 350 スループット(MB/s) 300 320MB/s 150 100 50 0 IOPS 12000 10000 250 200 14000 160MB/s 平均 最大 8000 6000 4000 2000 平均 最大 0 29
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 30
OracleEE から AuroraPostgreSQL 互換への移行 目的脱 Oracle を行いコスト DOWN を行うマネージドな DB を採用し 運用コストを下げる 移行スケジュール 2016/09 移行先 DB 検討 2016/12 移行先決定 プロジェクト開始 2017/06 移行完了予定 (GA 待ち ) 31
移行対象システム構成 Confidential Production HTTPS HTTPS 踏み台 WEB WEB 操作は全て録画 CloudTrail CloudWatch Events SNS AWSの操作は IAMで制限 特権ユーザが 使用されたら通知 会員DB Oracle on EC2 32
移行対象システム構成 Confidential Production HTTPS HTTPS 踏み台 WEB WEB 操作は全て録画 CloudTrail CloudWatch Events SNS AWSの操作は IAMで制限 特権ユーザが 使用されたら通知 会員DB ここの移行 Oracle on EC2 33
ワークロード 小さめの SQL が多く 並列度が高い稀にバッチ系の大きめな SQL メインテーブルのレコード件数は 4,000 万件超通常時 5,000~6,000 件 / 分のリクエストアプリプッシュ時 最大 17,000 件 / 分 400 件 / 秒リクエスト 34
移行候補 DB の比較 EDB Postgres RDS PostgreSQL AuroraMysql 互換 AuroraPostg resql 互換 移行し易さ 可用性 運用 EC2 ストレージが自前管理 フルマネージド フルマネージド コスト 小さい SQL 大きい SQL JOIN 少サブクエリ苦手 パラレルクエリ 9.6 から 9.6 から 9.6 互換 35
移行候補DBの比較 EDB Postgres RDS PostgreSQL AuroraMysql AuroraPostg 互換 resql互換 移行し易さ 可用性 運用 EC2 ストレー ジが自前管理 コスト 小さいSQL 大きいSQL パラレルクエリ 9.6から 9.6から フルマネージド フルマネージド JOIN少 サブクエリ苦手 9.6互換 36
Oracle と PostgreSQL の違い Oracle PostgreSQL DBLink FDW で実装 ( 速度はあまりでない ) パーティション テーブルの継承 CHECK 制約 トリガーで実装 シノニム 監査ログ log_statement ストアド PL/SQL PL/pgSQL データ取込 SQLLoader COPY コマンド 空文字の扱い 前方一致検索での索引 NULL と同等空文字と同等 無しビューや検索パスで一部代用可能 ロケール次第で使用されない CREATE INDEX index_name ON table_name (column_name text_pattern_ops) 37
Oracle と PostgreSQL の違い ヒント句 トランザクション中の DDL トランザクション中のエラー発生後 Merge 文 サブクエリの別名 ROWID Oracle 暗黙のコミット 以降も継続可能 不要 PostgreSQL 無し pg_hint_plan 拡張で実現可能 コミットされない DDL もロールバック可能 以降は SQL を受け付けず ロールバックしかできない INSERT INTO ~ ON CONFLICT ~ DO UPDATE 必要 SELECT * FROM (SELECT ~) T 無し oid ctid が似ているが違う 38
Oracle と PostgreSQL の違い Oracle PostgreSQL DUAL 表必要不要 SELECT test FROM DUAL 表の外部結合 Oracle 結合 (+) LEFT JOIN, RIGHT JOIN NULL 値変換 NVL NVL2 COALESCE CASE 指定レコード抽出 ROWNUM OFFSET LIMIT 日時取得 日付取得 SYSDATE TRUNC(SYSDAT E) date_trunc('second', clock_timestamp()) select date_trunc('day', clock_timestamp()) 日付変換 TO_DATE to_timestamp 同じ名前の関数が存在しても意味が違う 引数が違う等 様々 39
移行先データベース作成 AWS Schema Conversion Tool (SCT) 異なる DB 間でオブジェクトの移行を補助してくれるツール ソース DB スキーマ情報の読み込み SCT 拡張パックスキーマ作成変換後定義を適用 ターゲット DB SQL ファイルに出力可能 SCT で出力したファイルがそのまま使用できなかったため 一部修正し 各スキーマを作成 SCT はスキーマ単位のため GRANT は自前で実行するシノニムが存在しないため 検索パスを設定 40
本番データ転送 AWS Database Migration Service (DMS) RDB 間でデータ移行支援をしてくれるサービス フルロード 差分転送 ソース DB DMS ターゲット DB 容量 200GBのデータをDMSで転送テーブル数 :131 合計レコード数 :6.4 億件転送時間 :3 日 11 時間 10 時間並列度 CommitRate インスタンスタイプ変更で速度改善 41
テスト 新旧比較テスト : 両 DB に同じリクエストで同じ結果か総合テスト : POS やアプリから正しく動作するか負荷テスト : 本番と同等以上の負荷で動作するか 本番 移行先 AP 本番同等以上のリクエスト WEB WEB リクエスト log レスポンス log WEB WEB 42
移行手順 1. DMSでデータを同期 2. 既存アプリケーションの停止 3. DMSの同期が完了したことを確認 4. 新アプリケーションのリリース 数分の停止で移行できるのは DMS のおかげ! 43
アジェンダ 1. 会社紹介 2. インフラ概要 3.DBの歴史と遷移 4.ExadataからOracleEE on EC2への移行 5.OracleからAuroraPostgreSQL 互換への移行 6.AWS 移行後 44
AWS を 2 年間使ってみて 良かったこと 開発エンジニアがインフラに興味を持つようになった ハードにかかるコスト意識増 サイジング不要 構築しながら調整ができる インフラを用意する時間の短縮 待ち時間減 エンジニアのモチベーションUP 本番同等の環境が構築できるため テスト品質 効率 UP オンプレに比べ 故障の頻度が少ない( 当社比 ) 45
AWS を 2 年間使ってみて 気をつけたほうが良いこと 簡単に何でも作れてしまうため ルールが無いと無法地帯に最低限のルールは作り クラウドの自由度は残す 何でもタグ付けをしておかないと 後から分からなくなるサービスによってはタグをつけれないものも リザーブドインスタンスの購入がドキドキするこのインスタンスを買う ではなく このプラットフォーム このタイプを なので 実際に買わないと適用されたかが分からない AWS 側都合の EC2 再起動依頼は少し手間 46
AWS を 2 年間使ってみて 気をつけたほうが良いこと 落ちる前提で作る 必要に応じて冗長化 EC2 の R4 系等 新しいタイプは稀に起動できないことがある平日日中しか使用しないサーバは ジョブで 9 時 ON-18 時 OFF をしていたが その AZ に確保できるリソースが無いというエラー発生 AWS 側の障害が発生した際 待つことしかできない Oracle が動いている EC2 の EBS で 読み取り遅延発生復旧が遅い時があった ( 発生 2 時 復旧 12 時 ) 47
DB を移行して Exadata OracleEE on EC2 可用性シングル構成のため RAC より可用性は下がっているが 実際の停止時間は減った コスト新たに Exadata を購入するよりは少し安い位レスポンス UP のための EBS が想定よりコストがかかった 性能 CPU は 5 年前の Exadata より速い純粋な IO 速度は負けるが チューニングや他サービスとの組合せで 同等以上の速度をだせる 48
DB を移行して OracleEE AuroraPostgreSQL 互換 可用性 :UP コスト :DOWN 性能: 同等以上 ( と思われる ) その他: Auroraは良いところがかなり多い運用に手がかからなくなるため DBAが不要 49
まとめ レガシーな基幹系でも やり方次第でコストを抑えて AWS に移行できる 基幹系で使用する大規模な Oracle を PostgreSQL や Aurora に移行することは十分可能 データベース移行時 DMS SCT はかなり効果的 AWS やマネージドなデータベースを活用することで リソースをビジネス側に集中できる 50
最後に 一緒に働く仲間を募集しています! ご清聴ありがとうございました 51