ゲオを支える db 基盤の歴史と未来～oracle から amazon aurora … · data guard api...

1 GEO HOLDINGS CORPORATION

ゲオを支えるDB基盤の歴史と未来～OracleからAuroraへ～

株式会社ゲオホールディングス

業務システム部ゼネラルマネージャー

神野旬

2017/05/31


アジェンダ

１．会社紹介

２．インフラ概要

３．ＤＢの歴史と遷移

４．ExadataからOracleEE on EC2への移行

５．OracleからAuroraPostgreSQL互換への移行

６．AWS移行後


アジェンダ

１．会社紹介





６．AWS移行後


会社紹介＆自己紹介

• 社名：株式会社ゲオホールディングス • 会社設立：1989年1月 • 本社：愛知県名古屋市 • 売上高：2,680億円 (2017年3月期) • 店舗数：1,805店 (グループ全体)

メディアショップGEO 2nd STREET JUMBLE STORE ウェアハウス

神野旬（かんのじゅん）業務システム部ゼネラルマネージャー

自社プリペイドカード「ルエカ」ゲオグループで利用できるオリジナルプリペイドカードチャージ方法は現金 or 買取を選択可買取チャージの場合10％の割増あり


自社プリペイドカード・セルフレジ

セルフレジ 751店舗、合計1,521台導入済店別利用率は最大92％、平均46％レンタル利用でポイント付与


2nd STREET USA

ロサンゼルスのメルローズに

この夏オープン予定！！


アジェンダ

１．会社紹介





６．AWS移行後


使用AWSサービス

EC2 Auto Scaling

VPC VPC peering

Lambda Elastic Load Balancing

S3 EBS RDS Redshift DMS

Cloud Front

Direct Connect

Cloud Watch

Cloud Trail

Config Trusted Advisor

Certificate Manager

IAM

Athena SNS Work Spaces


インフラ概要

ＤＣ

店舗

×1,800

Internet VPN

Internet

UTM・Proxy

キャリア網

SSUSA

Azure

事務所

Development

Production

Confidential

Internet

Work Spaces


AWS使用例 2nd STREET USA

オレゴン

USA店舗

Internet

WEB WEB

東京

PC タブレット POS

HTTPS

その他システム

接客業務管理業務

①必要なデータの転送


AWS使用例 AmazonRedshift

全店のレンタル実績に応じて、新作・旧作等の区分を集計、変更するシステム

OracleExadata： 10時間 AmazonRedshift： 2.5時間同じロジックのままでも高速化ただしExadataは他処理もあるため、平等な比較ではない

RDS For MySQL

Redshift ③集計データの書き戻し ②集計

処理時のみ起動でコスト節約

月間レンタル件数：5,000万件

(＋転送、書き戻しの時間)


AWS使用例監視・運用系

サーバの死活監視

Zabbix Agent

Slack

Twilio（検証中）

障害検知

緊急性

高

緊急性

低

リソース運用

AWS CLI

ON

OFF

EC2、RDS等の ON・OFFを行う

Job Arranger for Zabbix


AWS使用例監視・運用系

バックアップ、CPUクレジット監視

EBSスナップショットの取得タグ設定通りの世代、時間

T2インスタンス CPUクレジット枯渇監視 CloudWatch

Events Lambda 閾値超え

SNS 通知

エラー

Slack Lambda S3 Athena

ログ保管、検索


アジェンダ

１．会社紹介





６．AWS移行後


ＤＢの歴史と遷移

店舗

店舗

店舗

ＤＣ

Oracle

Oracle

Oracle

Oracle

Oracle

DBLink DBLink

DBLink DBLink

DBLink



店舗

店舗

店舗

ＤＣ

Oracle

Oracle

Oracle

Oracle

Oracle



店舗

店舗

店舗

ＤＣ

Oracle バッチ系

ＤＲ

転送

DataGuard

API

API

API Oracle RAC 会員DB オンライン系 Oracle



店舗

店舗

店舗

ＤＣＤＲ

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用途

アプリ


アジェンダ

１．会社紹介





６．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


アジェンダ

１．会社紹介





６．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互換

AuroraPostgreSQL互換

移行し易さ ◎ ○ △ ○

可用性 ○ ○ ◎ ◎

運用 △ 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)



ヒント句 ○ 無し pg_hint_plan拡張で実現可能

トランザクション中のDDL

暗黙のコミットコミットされない DDLもロールバック可能

トランザクション中のエラー発生後

以降も継続可能以降はSQLを受け付けず、ロールバックしかできない

Merge文 ○ INSERT INTO ～ ON CONFLICT ～ DO UPDATE

サブクエリの別名不要必要 SELECT * FROM (SELECT ～) T

ROWID ○ 無し oid、ctidが似ているが違う



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

移行先

本番同等以上のリクエスト

AP


移行手順

数分の停止で移行できるのは DMSのおかげ！

1. DMSでデータを同期

2. 既存アプリケーションの停止

3. DMSの同期が完了したことを確認

4. 新アプリケーションのリリース


アジェンダ

１．会社紹介





６．AWS移行後

良かったこと


AWSを２年間使ってみて

・オンプレに比べ、故障の頻度が少ない（当社比）

・本番同等の環境が構築できるため、テスト品質、効率ＵＰ

・エンジニアのモチベーションUＰ

・インフラを用意する時間の短縮、待ち時間減

・サイジング不要、構築しながら調整ができる

・ハードにかかるコスト意識増

・開発エンジニアがインフラに興味を持つようになった



気をつけたほうが良いこと

・AWS側都合のEC2再起動依頼は少し手間

・リザーブドインスタンスの購入がドキドキするこのインスタンスを買う、ではなく、このプラットフォーム、このタイプを、なので、実際に買わないと適用されたかが分からない

・何でもタグ付けをしておかないと、後から分からなくなるサービスによってはタグをつけれないものも

・簡単に何でも作れてしまうため、ルールが無いと無法地帯に最低限のルールは作り、クラウドの自由度は残す



気をつけたほうが良いこと

・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速度は負けるが、チューニングや他サービスとの組合せで、同等以上の速度をだせる


DBを移行して

OracleEE → AuroraPostgreSQL互換・可用性：UP

・コスト：DOWN

・性能：同等以上（と思われる）

Auroraは良いところがかなり多い運用に手がかからなくなるため、DBAが不要

・その他：

・レガシーな基幹系でも、やり方次第でコストを抑えてAWSに移行できる


まとめ

・データベース移行時、DMS、SCTはかなり効果的

・基幹系で使用する大規模なOracleを、 PostgreSQLやAuroraに移行することは十分可能

・AWSやマネージドなデータベースを活用することで、リソースをビジネス側に集中できる


最後に

一緒に働く仲間を募集しています！

ご清聴ありがとうございました

ゲオを支える db 基盤の歴史と未来 ～oracle から amazon aurora … · data guard api...

Documents

ゲオを支える db 基盤の歴史と未来～oracle から amazon aurora … · data guard api...