Upgrade to Pro — share decks privately, control downloads, hide ads and more …

脱Oracle、MySQL一本化への道 / Engineers-in-CARTA-vol-2

脱Oracle、MySQL一本化への道 / Engineers-in-CARTA-vol-2

2537ce662eb08182e617ec7944981437?s=128

CARTA Engineering

December 17, 2021
Tweet

More Decks by CARTA Engineering

Other Decks in Technology

Transcript

  1. 株式会社 CARTA HOLDINGS
 浪川 大輔
 脱Oracle、MySQL一本化への道


  2. アジェンダ
 2 • 自己紹介
 • ECナビとは
 • ECナビのDBの歴史
 • 脱Oracleの背景


    • 脱Oracle、MySQL一本化
 (a.k.a引っ越し)の紹介

  3. 自己紹介
 3 株式会社CARTA HOLDINGS/
 株式会社VOYAGE MARKETING 
 (改メ 株式会社 DIGITALIO

    2022年1月より)
 メディア事業本部
 ポイントメディア事業部
 
 浪川 大輔
 • 入社13年、ECナビに関わって約10年
 • ここ数年はインフラを中心に改善を行うチームに所属
 • 「浪川大輔」の ”声じゃない” 方担当

  4. ECナビとは?
 「ECナビ」は、約760万人の会員に利用されている日本最大級のポイントサ イトです。ショッピングや会員登録、アンケートなど、毎日参加することので きるポイントコンテンツを多数取り揃え、会員が毎日訪れ、サイト上で積極 的に行動することを支援しています。会員にとって、満足度の高いサイト作 りを目指しています。
 ECナビキャラクター 
 ナビック
 4

    毎日たまるポイントサイト
 https://ecnavi.jp

  5. まずは歴史を少し振り返ります
 ECナビ PCバナー広告
 5

  6. 2016年ごろのDB事情
 6 • オンプレ時代
 • Oracle
 ◦ ODA X4-2 ってアプライアンス製品


    
 
 
 
 
 • MySQL
 ◦ フロント向け、バックオフィス向けの大きく2つ
 ◦ それぞれmaster1台, slave2台の構成
 構成

  7. 2016年ごろのDB事情
 7 テーブル数
 インスタンス
 データベース数
 テーブル数
 Oracle
 1
 650
 MySQL


    (フロント向け)
 5
 797
 MySQL
 (バックオフィス向け)
 3
 235

  8. 現在のDB事情
 8 • AWS移転後
 • Oracle
 ◦ RDS Oracle Standard

    Edition Two(se2)
 ◦ インスタンスタイプは r5.2xlarge
 • MySQL
 ◦ フロント向け、バックオフィス向けの大きく2つ
 ◦ インスタンスタイプは 
 ▪ フロント向け r5.2xlarge
 ▪ バックオフィス向け r5.large
 ◦ それぞれmaster1台
 構成

  9. 現在のDB事情
 9 テーブル数
 インスタンス
 データベース数
 テーブル数
 Oracle
 1
 650 ->

    180
 MySQL
 (フロント向け)
 5 -> 3
 797 -> 194
 MySQL
 (バックオフィス向け)
 3 -> 2
 235 -> 51
 MySQLはこの後、別の統廃合プロジェクトによって、フロントに1データベー ス、181テーブル、バックオフィスは廃止予定

  10. 現在のDB事情
 10 
 ここまでの奮闘の歴史は
 
 Engineers in VOYAGE
 ~事業をエンジニアリングする技術者たち~ 


    
 第3章 
 VOYAGE MARKETING
 20年級大規模レガシーシステムとの戦い
 
 をお読みいただけると幸いです。
 まとめ

  11. 脱Oracleの背景
 ~ ECナビ Oracleやめるってよ ~
 ECナビ PCバナー広告
 11

  12. なんで?
 12 • 専用のミドルウェアやライブラリを別途導入する必要があ る。それがyumのリポジトリにないので別途導入する仕組 みを用意する必要がある
 • ネット上での事例などが少なく、スキルを持ったエンジニア が少ないので障害時の対応の時間がかかる
 •

    Oracleでないとできないような機能を利用するシーンがな い
 技術面

  13. なんで?
 13 • OracleとMySQLを併用しているので、それぞれ概念や使い 方、クライアントツールに差異があり開発時にどちらを使っ てるか意識しないといけない。
 • クライアントツールは使い勝手が悪いため開発効率が悪 い。
 •

    ローカル開発環境構築、外部CIサービス利用のハードルに なっている。
 • OracleとMySQLを併用しているが、明確な使い分けもな い。
 開発面

  14. なんで?
 14 • 導入当時はOSSのDBの信頼性は低く、ビジネス用途の場 合はOracleが選択されることが多かった。現在、OSSも Oracleと比較して遜色ない機能を提供できるようになってき ている。
 • 不要機能削除や統廃合によってOracle、MySQL共に200 テーブル弱になり現実的に移行可能な規模になった。


    環境面

  15. なんで?
 15 Oracleシンドイっす。。。
 まとめ


  16. 前置きが長くなりましたが
 ここからが本題
 ECナビ PCバナー広告
 16

  17. 脱Oracle、MySQL一本化
 (a.k.a 引っ越し)の紹介
 ECナビ PCバナー広告
 17

  18. 引っ越し先は?
 18 • 既存 or 新DB
 • v5.7 or v8.0


    • MySQL or Aurora

  19. 引っ越し先は?
 19 • Oracle -> MySQLへの単純移行なら思い切って 最新技術にチャレンジしてた
 • でも、既存との兼ね合いはある程度考慮しない といけない


    • 規模や使い方的にも1データベースにまとめて しまってその後の方がチャレンジはしやすい

  20. 引っ越し先は?
 20 • 既存 or 新DB
 • v5.7 or v8.0


    • MySQL or Aurora

  21. 引っ越し方法は?
 21 サービスメンテナンスで一括移行 
 or 
 部分メンテナンスで分割移行


  22. 引っ越し方法は?
 22 • 既存の開発や別に大規模な統廃合プロジェクト が並行で動いてる
 • そもそも一括でやるにはデカすぎる
 • 複数DBで運用してきたためトランザクション制 御などアプリの実装もそれなりに実績がある


    • ユーザーには不便をかけるものの数時間のメ ンテによる事業インパクトは小さい

  23. 引っ越し方法は?
 23 サービスメンテナンスで一括移行 
 or 
 部分メンテナンスで分割移行


  24. まずは調査
 24 • Oracle独自のものがないか?
 ◦ トリガー
 ◦ プロシージャ
 ◦ シーケンス(特殊ケース)


    • データの規模
 • データ型

  25. まずは調査
 25 • トリガー -> なし
 • プロシージャ -> なし


    • シーケンス(特殊ケース)-> あり
 ◦ シーケンス:1-テーブル:n で使ってるところ が1箇所
 Oracle独自のもがないか?

  26. まずは調査
 26 データの規模


  27. まずは調査
 27 データの規模
 • 10万レコード以下が半分くらい
 ◦ 短時間でのテーブル移行ができそう
 • 最大レコード数は2億4700万が10テーブル
 ◦

    ポイントのログを10テーブルにシャーディ ング

  28. まずは調査
 28 • VARCHAR2, CHAR, NUMBER, DATE
 ◦ ベーシックな型で置き換えができるものば かり


    • BLOB
 ◦ 一箇所
 データ型

  29. 引っ越し
 29 • どこから手を付ける?
 • どう進める?


  30. 引っ越し
 30 • 機能毎にテーブルを仕分け
 • テーブル数、ユーザーの利用頻度、メンテナ ンスの入れやすさを軸に難易度を「低・中・ 高・鬼」に設定
 • 難易度の低い方から手を付ける


    どこから手を付ける?

  31. 引っ越し
 31 • 低
 ◦ マスターデータ系
 ◦ まとメール
 • 中


    ◦ パスワードリマインダー
 ◦ アドレス変更
 ◦ CSRF対策
 ◦ ポイント失効
 ◦ ナビック新着
 ◦ カードプラス
 ◦ 友達紹介
 ◦ 会員退会
 ◦ 会員停止
 ◦ キャンペーン
 難易度
 • 高
 ◦ まいにち動画
 ◦ ガラポン
 ◦ 誕生日
 ◦ 募金
 ◦ ハッピーアンケート
 ◦ 珍コレ
 ◦ 宝くじ
 ◦ 連携用ユーザID
 ◦ 会員登録
 ◦ ポイント付与API
 ◦ ポイント付与申請
 ◦ タップインセ
 ◦ キャンペーンシステム
 ◦ BID関連
 ◦ MFA系
 ◦ PeX交換
 ◦ アプリ
 • 鬼
 ◦ ポイント
 ◦ 成果案件 + 成果通知
 ◦ ユーザー

  32. 引っ越し
 32 • 以下を1セットとして
 ◦ アプリの調査、データ移行、メンテナンスの入れ方決 定
 ◦ DDLの用意
 ◦

    アプリ改修
 ◦ データ移行準備
 ◦ 動作、パフォーマンス検証
 ◦ メンテナンス日調整
 ◦ 切り替え作業
 どう進める

  33. 引っ越し開始!
 ECナビ PCバナー広告
 33

  34. データ型どうする?
 34 • VARCHAR2, CHAR, NUMBER, DATE
 ◦ 既存のMySQLにあるテーブルの型と乖離 しないように変換ルールを策定


    • BLOB
 ◦ 中身はJSONなのでMySQLではTEXTにし た
 変換ルール

  35. データ型どうする?
 35 変換ルール
 Oracle MySQL DATE DATETIME NUMBER(n, 0): n

    < 3 TINYINT(n) NUMBER(n, 0): 3 <= n < 10 INT(n) NUMBER(n, 0): 10 <= n < 19 BIGINT(n) NUMBER(n, 0): 20 <= n DECIMAL(n, 0) NUMBER(n, s) DECIMAL(n,s) VARCHAR2(n) VARCHAR(n) CHAR(n) VARCHAR(n)
  36. DDLは?
 36 • データ型は原則変換ルールに則る
 • シーケンスを利用している列はauto_incrementに する
 • インデックスは基本そのまま
 ◦

    explainして想定したインデックスが効いていな ければ調整
 方針

  37. DDLは?
 37 • AWS Schema Conversion Tool は使わなかった
 ◦ databaseに直接繋ぐ必要がある


    ◦ NUMBERが軒並みDECIMALになったり、細かく マッピングの設定をしないといけなかった
 ◦ DDLの管理はflywayで管理してるのでリリース の兼ね合い
 変換ツール

  38. DDLは?
 38 • どうしたか?
 ◦ 結局調査段階で、各テーブルのカラム、データ 型、インデックスなど調査していたので、それら をインプットにDDL出力するスクリプトを書いた
 変換ツール


  39. DDLの罠
 39 • DECIMAL型はauto_incrementが付けれない
 ◦ NUMBER(n, 0): 20 <= n

    に該当した数ケース
 ◦ 自動変換でNUMBER -> DECIMALにしていたら 軒並みハマってた
 ◦ 実データみると、データの増加量みても20桁以 上行きそうにないものばかり
 ◦ 実データと増加量から適切な桁を調べてINT, BIGINTにして対応
 

  40. DDLの罠
 40 
 • 予約語
 ◦ カラム名にOracleで使えてMySQLでは予約語で 使えないものがある
 ◦ うちでは

    “CONDITION” で引っかかりました

  41. アプリ改修
 41 SQLの関数周り
 Oracle MySQL sysdate now() rownum limit, offset

    to_date (date型との比較) なし to_char (日付の変換で利用) なし nextval last_insert_id()
  42. アプリ改修
 42 rownum
 • 管理画面のページャーで主に利用
 • rownumは、開始行数と終了行数を指定
 • limit, offsetは件数と開始位置を指定


  43. アプリ改修
 43 rownum
 例: 15〜20行目を取る場合(rownum版)
 
 SELECT
 ID,
 NAME,
 ROWNUM


    FROM
 USERS
 WHERE
 ROWNUM BETWEEN 15 AND 20
 

  44. アプリ改修
 44 rownum
 例: 15〜20行目を取る場合(limit, offset版)
 
 SELECT
 ID,
 NAME


    FROM
 USERS
 LIMIT 5
 OFFSET 14
 
 
 

  45. アプリ改修
 45 rownum
 こんな実装があると地味にダメージありますw
 
 function find($start, $end, $con) //

    <- 開始行、終了行が引数になってるやつ
 {
 $sql = "SELECT
 ID,
 NAME,
 ROWNUM
 FROM
 USERS
 WHERE
 ROWNUM BETWEEN :start AND :end";
 
 return $con->execute($sql, ['start' => $start, 'end' => $end]);
 }
 
 

  46. アプリ改修
 46 トランザクション
 • OracleとMySQLの両テーブルを更新する場合
 • 例えば: クイズに答えてポイントを取得
 ◦ Oracleのポイントログに追加(ポイントを付与)


    ◦ MySQLのクイズの回答のログに追加
 • Oracleにポイント情報、MySQLにコンテンツ系の 情報を持ってるパターンが結構ある

  47. アプリ改修
 47 トランザクション
 try {
 $oracleCon = Database::getConnection('ORACLE_ECNAVI);
 $mysqlCon =

    Database::getConnection('MYSQL_ECNAVI');
 
 $pointLogDao = Dao::get('POINT_LOG');
 $quizAnswerDao = Dao::get('QUIZ_ANSWER');
 // トランザクション開始
 $oracleCon->begin();
 $mysqlCon->begin();
 // それぞれのテーブルへ追加
 $pointLogDao->insert($userId, $pointValue, $oracleCon); // Oracleのテーブルへの追加
 $quizAnswerDao->insert($userId, $answer, $mysqlCon); // MySQLのテーブルへの追加
 // コミット
 $oracleCon->commit();
 $mysqlCon->commit();
 } catch (Exception $e) {
 if (isset($oracleCon) && $oracleCon->isTransaction()) {
 $oracleCon->rollback();
 }
 if (isset($mysqlCon) && $mysqlCon->isTransaction()) {
 $mysqlCon->rollback();
 }
 }
 
 

  48. アプリ改修
 48 トランザクション
 • こんなコードが結構ある
 • 歴史のある大規模アプリなので、コードの作りに グラデーションがある
 ◦ こんなコードがControllerにあったり、ビジネスロ

    ジッククラスにあったりいろいろパターンがあっ て苦労する
 • 引っ越しの過渡期にはOracleにあったコンテンツ をMySQLに移すので、こんなコードを追加する必 要もある

  49. データ移行
 49 
 • データ移行は以下ツールを利用
 ◦ Embulk
 ▪ 現在Oracle、MySQLからRedshiftへ日次デー タ移行に利用


    ◦ AWS Database Migration Service(DMS)
 ▪ 複数テーブルの移行
 ▪ CDC(差分更新)

  50. IOPS
 50 • データ移行に際して事前にIOPSの確認は重要
 • データ移行先(今回だとMySQL)の書き込みのIOPS がかなり上がる
 • RDSのストレージタイプ(とストレージサイズ)によっ て上限がありそれを超えてI/Oクレジットバランス使

    い切ると極端に性能悪化
 • 移行先はサービスですでに利用しているためデータ 移行によってI/Oクレジットバランス使い切るとサー ビスにも影響が出る
 ◦ この辺は本番と同様のデータの検証環境を使って 事前に確認をとりつつ進めました

  51. IOPS
 51 • プロビジョンドIOPS SSDストレージを利用していてIOPS は2000で設定していた
 • 5400万件のデータを移行するタイミングでIOPSが7000 強まで上がり、今は1万までIOPSを上げてます
 MySQLのIOPS


  52. 文字化け問題
 52 • Oracle、MySQL共に文字コードはEUC-JPを利用 してDMSを使ってデータ移行をした際に以下が文 字化け
 ◦ ローマ数字、略式文字など
 ◦ 旧漢字(はしご高

    など)
 ◦ 全角チルダ
 ◦ 全角バックスラッシュ

  53. 文字化け問題
 53 • 全角バックスラッシュはあまり聞いたことがなかっ たので??となった
 • それも結構な件数できて、利用用途も???


  54. 文字化け問題
 54 答え:
 
 
 \\回答者限定!!// のXXXXXに関するアンケート
 
 
 


    こういうのだった。。。。
 

  55. 文字化け問題
 55 • 今回のケースではDMSのCDCを使いたかったの で、DMS上で変換をかけたり、元データを代替え 文字に変換して回避した
 • ユーザーデータは特に旧漢字があるケースも多 いと思うのでその辺は手動でEUC-JPとしてファイ ル出力して移す必要がありそう


  56. いろいろありながら
 ECナビ PCバナー広告
 56

  57. 現在の状況
 57 • 引っ越し過程のMySQLのメトリクス
 • 億単位のテーブルも移行してたりするが比較的大きな変化も なく動いている
 • コネクションが伸びてるのは別のトラブルによるもの
 •

    ディスクは途中で増やしてるのでグラフは大きく変化しています

  58. 現在の状況
 58 • IOPSもじわじわ上がってきてはいるが平時は上限に迫 るような大きな変化はない


  59. 現在の状況
 59 • 引っ越しは道半ば
 • 180テーブル中 110テーブルほど引っ越しが完了
 • 難易度を鬼に設定したサービスのコアとなるユー ザー系や2億4700万レコード

    x 10テーブルを擁す るポイント系はこれから

  60. この先順調に進むのか?
 本当に引っ越ししきれるのか?
 ECナビ PCバナー広告
 60

  61. この続きは
 またいずれ何かの機会に
 ECナビ PCバナー広告
 61

  62. ご清聴ありがとうございました
 ECナビ PCバナー広告
 62