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