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

Engineers in CARTA vol.2 #MySQL
https://cartaholdings.connpass.com/event/231708/

記事
https://codezine.jp/article/detail/14062

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はこの後、別の統廃合プロジェクトによって、フロントに１データベー ス、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