$30 off During Our Annual Pro Sale. View Details »

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

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

CARTA Engineering

December 17, 2021
Tweet

More Decks by CARTA Engineering

Other Decks in Technology

Transcript

  1. 株式会社 CARTA HOLDINGS

    浪川 大輔

    脱Oracle、MySQL一本化への道


    View Slide

  2. アジェンダ

    2
    ● 自己紹介

    ● ECナビとは

    ● ECナビのDBの歴史

    ● 脱Oracleの背景

    ● 脱Oracle、MySQL一本化

    (a.k.a引っ越し)の紹介


    View Slide

  3. 自己紹介

    3
    株式会社CARTA HOLDINGS/

    株式会社VOYAGE MARKETING 

    (改メ 株式会社 DIGITALIO 2022年1月より)

    メディア事業本部

    ポイントメディア事業部


    浪川 大輔

    ● 入社13年、ECナビに関わって約10年

    ● ここ数年はインフラを中心に改善を行うチームに所属

    ● 「浪川大輔」の ”声じゃない” 方担当


    View Slide

  4. ECナビとは?

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

    ECナビキャラクター 

    ナビック

    4
    毎日たまるポイントサイト

    https://ecnavi.jp


    View Slide

  5. まずは歴史を少し振り返ります

    ECナビ PCバナー広告

    5

    View Slide

  6. 2016年ごろのDB事情

    6
    ● オンプレ時代

    ● Oracle

    ○ ODA X4-2 ってアプライアンス製品






    ● MySQL

    ○ フロント向け、バックオフィス向けの大きく2つ

    ○ それぞれmaster1台, slave2台の構成

    構成


    View Slide

  7. 2016年ごろのDB事情

    7
    テーブル数

    インスタンス
 データベース数
 テーブル数

    Oracle
 1
 650

    MySQL

    (フロント向け)

    5
 797

    MySQL

    (バックオフィス向け)

    3
 235


    View Slide

  8. 現在のDB事情

    8
    ● AWS移転後

    ● Oracle

    ○ RDS Oracle Standard Edition Two(se2)

    ○ インスタンスタイプは r5.2xlarge

    ● MySQL

    ○ フロント向け、バックオフィス向けの大きく2つ

    ○ インスタンスタイプは 

    ■ フロント向け r5.2xlarge

    ■ バックオフィス向け r5.large

    ○ それぞれmaster1台

    構成


    View Slide

  9. 現在のDB事情

    9
    テーブル数

    インスタンス
 データベース数
 テーブル数

    Oracle
 1
 650 -> 180

    MySQL

    (フロント向け)

    5 -> 3
 797 -> 194

    MySQL

    (バックオフィス向け)

    3 -> 2
 235 -> 51

    MySQLはこの後、別の統廃合プロジェクトによって、フロントに1データベー
    ス、181テーブル、バックオフィスは廃止予定


    View Slide

  10. 現在のDB事情

    10

    ここまでの奮闘の歴史は


    Engineers in VOYAGE

    ~事業をエンジニアリングする技術者たち~ 


    第3章 

    VOYAGE MARKETING

    20年級大規模レガシーシステムとの戦い


    をお読みいただけると幸いです。

    まとめ


    View Slide

  11. 脱Oracleの背景

    ~ ECナビ Oracleやめるってよ ~

    ECナビ PCバナー広告

    11

    View Slide

  12. なんで?

    12
    ● 専用のミドルウェアやライブラリを別途導入する必要があ
    る。それがyumのリポジトリにないので別途導入する仕組
    みを用意する必要がある

    ● ネット上での事例などが少なく、スキルを持ったエンジニア
    が少ないので障害時の対応の時間がかかる

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

    技術面


    View Slide

  13. なんで?

    13
    ● OracleとMySQLを併用しているので、それぞれ概念や使い
    方、クライアントツールに差異があり開発時にどちらを使っ
    てるか意識しないといけない。

    ● クライアントツールは使い勝手が悪いため開発効率が悪
    い。

    ● ローカル開発環境構築、外部CIサービス利用のハードルに
    なっている。

    ● OracleとMySQLを併用しているが、明確な使い分けもな
    い。

    開発面


    View Slide

  14. なんで?

    14
    ● 導入当時はOSSのDBの信頼性は低く、ビジネス用途の場
    合はOracleが選択されることが多かった。現在、OSSも
    Oracleと比較して遜色ない機能を提供できるようになってき
    ている。

    ● 不要機能削除や統廃合によってOracle、MySQL共に200
    テーブル弱になり現実的に移行可能な規模になった。

    環境面


    View Slide

  15. なんで?

    15
    Oracleシンドイっす。。。

    まとめ


    View Slide

  16. 前置きが長くなりましたが

    ここからが本題

    ECナビ PCバナー広告

    16

    View Slide

  17. 脱Oracle、MySQL一本化

    (a.k.a 引っ越し)の紹介

    ECナビ PCバナー広告

    17

    View Slide

  18. 引っ越し先は?

    18
    ● 既存 or 新DB

    ● v5.7 or v8.0

    ● MySQL or Aurora


    View Slide

  19. 引っ越し先は?

    19
    ● Oracle -> MySQLへの単純移行なら思い切って
    最新技術にチャレンジしてた

    ● でも、既存との兼ね合いはある程度考慮しない
    といけない

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


    View Slide

  20. 引っ越し先は?

    20
    ● 既存 or 新DB

    ● v5.7 or v8.0

    ● MySQL or Aurora


    View Slide

  21. 引っ越し方法は?

    21
    サービスメンテナンスで一括移行 

    or 

    部分メンテナンスで分割移行


    View Slide

  22. 引っ越し方法は?

    22
    ● 既存の開発や別に大規模な統廃合プロジェクト
    が並行で動いてる

    ● そもそも一括でやるにはデカすぎる

    ● 複数DBで運用してきたためトランザクション制
    御などアプリの実装もそれなりに実績がある

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


    View Slide

  23. 引っ越し方法は?

    23
    サービスメンテナンスで一括移行 

    or 

    部分メンテナンスで分割移行


    View Slide

  24. まずは調査

    24
    ● Oracle独自のものがないか?

    ○ トリガー

    ○ プロシージャ

    ○ シーケンス(特殊ケース)

    ● データの規模

    ● データ型


    View Slide

  25. まずは調査

    25
    ● トリガー -> なし

    ● プロシージャ -> なし

    ● シーケンス(特殊ケース)-> あり

    ○ シーケンス:1-テーブル:n で使ってるところ
    が1箇所

    Oracle独自のもがないか?


    View Slide

  26. まずは調査

    26
    データの規模


    View Slide

  27. まずは調査

    27
    データの規模

    ● 10万レコード以下が半分くらい

    ○ 短時間でのテーブル移行ができそう

    ● 最大レコード数は2億4700万が10テーブル

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


    View Slide

  28. まずは調査

    28
    ● VARCHAR2, CHAR, NUMBER, DATE

    ○ ベーシックな型で置き換えができるものば
    かり

    ● BLOB

    ○ 一箇所

    データ型


    View Slide

  29. 引っ越し

    29
    ● どこから手を付ける?

    ● どう進める?


    View Slide

  30. 引っ越し

    30
    ● 機能毎にテーブルを仕分け

    ● テーブル数、ユーザーの利用頻度、メンテナ
    ンスの入れやすさを軸に難易度を「低・中・
    高・鬼」に設定

    ● 難易度の低い方から手を付ける

    どこから手を付ける?


    View Slide

  31. 引っ越し

    31
    ● 低

    ○ マスターデータ系

    ○ まとメール

    ● 中

    ○ パスワードリマインダー

    ○ アドレス変更

    ○ CSRF対策

    ○ ポイント失効

    ○ ナビック新着

    ○ カードプラス

    ○ 友達紹介

    ○ 会員退会

    ○ 会員停止

    ○ キャンペーン

    難易度

    ● 高

    ○ まいにち動画

    ○ ガラポン

    ○ 誕生日

    ○ 募金

    ○ ハッピーアンケート

    ○ 珍コレ

    ○ 宝くじ

    ○ 連携用ユーザID

    ○ 会員登録

    ○ ポイント付与API

    ○ ポイント付与申請

    ○ タップインセ

    ○ キャンペーンシステム

    ○ BID関連

    ○ MFA系

    ○ PeX交換

    ○ アプリ

    ● 鬼

    ○ ポイント

    ○ 成果案件 + 成果通知

    ○ ユーザー


    View Slide

  32. 引っ越し

    32
    ● 以下を1セットとして

    ○ アプリの調査、データ移行、メンテナンスの入れ方決
    定

    ○ DDLの用意

    ○ アプリ改修

    ○ データ移行準備

    ○ 動作、パフォーマンス検証

    ○ メンテナンス日調整

    ○ 切り替え作業

    どう進める


    View Slide

  33. 引っ越し開始!

    ECナビ PCバナー広告

    33

    View Slide

  34. データ型どうする?

    34
    ● VARCHAR2, CHAR, NUMBER, DATE

    ○ 既存のMySQLにあるテーブルの型と乖離
    しないように変換ルールを策定

    ● BLOB

    ○ 中身はJSONなのでMySQLではTEXTにし
    た

    変換ルール


    View Slide

  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)

    View Slide

  36. DDLは?

    36
    ● データ型は原則変換ルールに則る

    ● シーケンスを利用している列はauto_incrementに
    する

    ● インデックスは基本そのまま

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

    方針


    View Slide

  37. DDLは?

    37
    ● AWS Schema Conversion Tool は使わなかった

    ○ databaseに直接繋ぐ必要がある

    ○ NUMBERが軒並みDECIMALになったり、細かく
    マッピングの設定をしないといけなかった

    ○ DDLの管理はflywayで管理してるのでリリース
    の兼ね合い

    変換ツール


    View Slide

  38. DDLは?

    38
    ● どうしたか?

    ○ 結局調査段階で、各テーブルのカラム、データ
    型、インデックスなど調査していたので、それら
    をインプットにDDL出力するスクリプトを書いた

    変換ツール


    View Slide

  39. DDLの罠

    39
    ● DECIMAL型はauto_incrementが付けれない

    ○ NUMBER(n, 0): 20 <= n に該当した数ケース

    ○ 自動変換でNUMBER -> DECIMALにしていたら
    軒並みハマってた

    ○ 実データみると、データの増加量みても20桁以
    上行きそうにないものばかり

    ○ 実データと増加量から適切な桁を調べてINT,
    BIGINTにして対応


    View Slide

  40. DDLの罠

    40

    ● 予約語

    ○ カラム名にOracleで使えてMySQLでは予約語で
    使えないものがある

    ○ うちでは “CONDITION” で引っかかりました


    View Slide

  41. アプリ改修

    41
    SQLの関数周り

    Oracle MySQL
    sysdate now()
    rownum limit, offset
    to_date (date型との比較) なし
    to_char (日付の変換で利用) なし
    nextval last_insert_id()

    View Slide

  42. アプリ改修

    42
    rownum

    ● 管理画面のページャーで主に利用

    ● rownumは、開始行数と終了行数を指定

    ● limit, offsetは件数と開始位置を指定


    View Slide

  43. アプリ改修

    43
    rownum

    例: 15〜20行目を取る場合(rownum版)


    SELECT

    ID,

    NAME,

    ROWNUM

    FROM

    USERS

    WHERE

    ROWNUM BETWEEN 15 AND 20


    View Slide

  44. アプリ改修

    44
    rownum

    例: 15〜20行目を取る場合(limit, offset版)


    SELECT

    ID,

    NAME

    FROM

    USERS

    LIMIT 5

    OFFSET 14




    View Slide

  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]);

    }



    View Slide

  46. アプリ改修

    46
    トランザクション

    ● OracleとMySQLの両テーブルを更新する場合

    ● 例えば: クイズに答えてポイントを取得

    ○ Oracleのポイントログに追加(ポイントを付与)

    ○ MySQLのクイズの回答のログに追加

    ● Oracleにポイント情報、MySQLにコンテンツ系の
    情報を持ってるパターンが結構ある


    View Slide

  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();

    }

    }



    View Slide

  48. アプリ改修

    48
    トランザクション

    ● こんなコードが結構ある

    ● 歴史のある大規模アプリなので、コードの作りに
    グラデーションがある

    ○ こんなコードがControllerにあったり、ビジネスロ
    ジッククラスにあったりいろいろパターンがあっ
    て苦労する

    ● 引っ越しの過渡期にはOracleにあったコンテンツ
    をMySQLに移すので、こんなコードを追加する必
    要もある


    View Slide

  49. データ移行

    49

    ● データ移行は以下ツールを利用

    ○ Embulk

    ■ 現在Oracle、MySQLからRedshiftへ日次デー
    タ移行に利用

    ○ AWS Database Migration Service(DMS)

    ■ 複数テーブルの移行

    ■ CDC(差分更新)


    View Slide

  50. IOPS

    50
    ● データ移行に際して事前にIOPSの確認は重要

    ● データ移行先(今回だとMySQL)の書き込みのIOPS
    がかなり上がる

    ● RDSのストレージタイプ(とストレージサイズ)によっ
    て上限がありそれを超えてI/Oクレジットバランス使
    い切ると極端に性能悪化

    ● 移行先はサービスですでに利用しているためデータ
    移行によってI/Oクレジットバランス使い切るとサー
    ビスにも影響が出る

    ○ この辺は本番と同様のデータの検証環境を使って
    事前に確認をとりつつ進めました


    View Slide

  51. IOPS

    51
    ● プロビジョンドIOPS SSDストレージを利用していてIOPS
    は2000で設定していた

    ● 5400万件のデータを移行するタイミングでIOPSが7000
    強まで上がり、今は1万までIOPSを上げてます

    MySQLのIOPS


    View Slide

  52. 文字化け問題

    52
    ● Oracle、MySQL共に文字コードはEUC-JPを利用
    してDMSを使ってデータ移行をした際に以下が文
    字化け

    ○ ローマ数字、略式文字など

    ○ 旧漢字(はしご高 など)

    ○ 全角チルダ

    ○ 全角バックスラッシュ


    View Slide

  53. 文字化け問題

    53
    ● 全角バックスラッシュはあまり聞いたことがなかっ
    たので??となった

    ● それも結構な件数できて、利用用途も???


    View Slide

  54. 文字化け問題

    54
    答え:



    \\回答者限定!!// のXXXXXに関するアンケート




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


    View Slide

  55. 文字化け問題

    55
    ● 今回のケースではDMSのCDCを使いたかったの
    で、DMS上で変換をかけたり、元データを代替え
    文字に変換して回避した

    ● ユーザーデータは特に旧漢字があるケースも多
    いと思うのでその辺は手動でEUC-JPとしてファイ
    ル出力して移す必要がありそう


    View Slide

  56. いろいろありながら

    ECナビ PCバナー広告

    56

    View Slide

  57. 現在の状況

    57
    ● 引っ越し過程のMySQLのメトリクス

    ● 億単位のテーブルも移行してたりするが比較的大きな変化も
    なく動いている

    ● コネクションが伸びてるのは別のトラブルによるもの

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


    View Slide

  58. 現在の状況

    58
    ● IOPSもじわじわ上がってきてはいるが平時は上限に迫
    るような大きな変化はない


    View Slide

  59. 現在の状況

    59
    ● 引っ越しは道半ば

    ● 180テーブル中 110テーブルほど引っ越しが完了

    ● 難易度を鬼に設定したサービスのコアとなるユー
    ザー系や2億4700万レコード x 10テーブルを擁す
    るポイント系はこれから


    View Slide

  60. この先順調に進むのか?

    本当に引っ越ししきれるのか?

    ECナビ PCバナー広告

    60

    View Slide

  61. この続きは

    またいずれ何かの機会に

    ECナビ PCバナー広告

    61

    View Slide

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

    ECナビ PCバナー広告

    62

    View Slide