Oracle racからaurora my sqlへの移行

© RecoChoku Co.,Ltd. Proprietary and Confidential
株式会社レコチョク
事業ｼｽﾃﾑ推進部システムアーキテクトグループ
酒井修平
2017/3/7
Oracle RACからAurora MySQLへの移行

アジェンダ
22017/3/7
クラブレコチョクという会員サービスを
Oracle RACからAurora MySQLへ移行したお話
1. レコチョクとクラブレコチョクについて
2. Auroraを選択した理由
3. どのようにAuroraへ移行したか
4. どのようにAuroraを運用しているか
5. Auroraに期待するところ

自己紹介
32017/3/7
● 名前
- 酒井修平 @darshuheider
● サーバサイドエンジニア
- クラブレコチョクシステム担当
● 好きなAWSサービス
- Aurora
- Lambda
● 好きなアーティスト
- レキシ
- 星野源
- Negicco
- アップアップガールズ(仮)
- チャオベッラチンクエッティ
● ポジション
- 2番セカンド

レコチョクとクラブレコチョクについて
42017/3/7
• レコチョクではどんなサービスを展開しているか？
従来の事業領域（デジタル音源配信）
自社（レコチョク）協業
従量課金制定額課金制従量課金制定額課金制
新事業領域（より幅広い音楽ソリューションサービスへ）

52017/3/7
• システム全体としてはどのような感じか？
– 機能やサービス毎にシステムを構築
• 楽曲検索、決済、会員(クラブレコチョク)、楽曲情報 etc..
– 全てをAWS上に構築
• EC2 ：約1000
• RDS ：約180
• 30以上のAWSサービスを利用

62017/3/7
• クラブレコチョクとはどのようなサービスか？
– レコチョクが展開するサービスへ会員機能を提供する
– 主な機能
• 会員登録・ログイン
• 会員の属性情報管理(Myアーティスト登録)
• セッション管理
• 端末管理

72017/3/7
• クラブレコチョクとはどのようなサービスか？
– 有効会員数は約1000万
• DB全体のレコード数としては数億レコード
– アクセス数は多いと秒間250リクエストは超える
– 各サービス横断で利用されるので高い可用性が必要

82017/3/7
• クラブレコチョクシステム構成図
バッチ
会員システム
分析系システム
東京リージョン
連携システム
APIWEB
ユーザ
Elastic Load Balancer Elastic Load Balancer Elastic Load Balancer
Amazon Route 53
Amazon EC2 Amazon EC2
Amazon EC2
Amazon S3 Amazon Aurora Amazon Aurora

Auroraを選択した理由
92017/3/7
• そもそも会社全体としてどのような課題があったか？
– データ総量の予測が困難になってきた
• 楽曲数の増加、動画やハイレゾ音源の対応
– コストの最適化
• 短期間でのサービス立ち上げ、急激なアクセス増に対応するため多めにイン
フラリソースを保持
– コストの明確化
• サービス、システム毎のインフラコストが把握できていない

102017/3/7
• クラブレコチョクはオンプレでどのように運用されていたか？
– DBはOracleでRAC構成
• 2ノード
– 2CPU 4コア
• エンタープライズ・ストレージ
• Oracle EE Partitioning + RAC オプション
• 全コンポーネントの冗長化
– DBAがインフラを運用
• 監視
– コネクション数、表領域、CPU etc..
• バックアップ

112017/3/7
• なぜAuroraを選択したのか？
– 高い可用性を担保するため
• 様々なサービスから利用される
• 求められる可用性については同じ
– 定期的にメンテがあるのでサービス調整はしました
– 運用工数を抑えたい
• 運用は開発チームに移管

どのようにAuroraへ移行したか
122017/3/7
• 大きく分けると4つの作業を実施しました
– テーブルを再作成
– SQLの修正
– データの移行
– 性能試験
• DMSなどの移行ツールが一般公開になる前だったので、全て自
前でスクリプト等を作成しました

132017/3/7
• テーブルを再作成
– DDLの作成
• データ型を変更していく。比較的機械的な作業
• アプリ側も適宜修正
– パラメータグループの作成
• DBAから基本的な設定内容について教えてもらう
• デフォルトのトランザクション分離レベルはOracleと違うので注意

142017/3/7
• SQLの修正
– 関数をMySQLで使えるものに変換していく
• MERGE 構文、DECODE 関数、TO_CHAR 関数 etc..
– コメントの修正
• “--” → “--(空白)” もしくは “#”
※基本的には公式ドキュメントとにらめっこしながら対応しました
https://dev.mysql.com/doc/refman/5.6/ja/compatibility.html

152017/3/7
• データの移行
– 更新日を見ながら、過去数年分を一気に移行
• データ量が多かったことと、性能試験を本番相当のデータで実施したかったの
で、1ヶ月前からデータ移行を開始
• DATEやDATETIMEは年を下2桁だけにしてしまうと、1900年代か2000年代を勝
手に変換するので注意(生年月日が未来日の人できてしまうかも。。)
– 移行が完了したら、切り替え当日まで差分を日次で更新

162017/3/7
• 性能試験
– 本番相当のデータを使って運用テスト、負荷テストを実施
• スロークエリをとって性能が出ていないものがないか監視
– 実行計画をとってフルスキャンしているものがないか確認
• 実際には全SQLの実行計画をとれなかったので全て見るべきだったと反省。。
⇒上記で問題のあるものに対し適宜対応を実施
・ SQLの最適化
・インデックス追加
・サブクエリをなくして2回SQLを投げるように修正
・検索専用のテーブルを追加(後方一致検索に10分以上かかってしまった)
※パラメータの修正は一切行わず

どのようにAuroraを運用しているか
• 最初は何を見ればいいかわからなかった。。
– 元々インフラを管理していた人とかに相談
• 標準的に見るべき項目や閾値を策定してもらう
– CPU、メモリ、クエリ数、コネクション数、スロークエリ、スループット
• ダッシュボードの作成
172017/3/7

• Auroraに合わせた監視内容に変更しました
– CPU使用率が比較的高め
• インスタンスリソースをフルに活用する
– CPU使用率が95%を超えたことがありましたが、正常に動き続けてました。。
– インスタンスリソースによる監視はやめる
• スループットやレイテンシーの監視のみ
182017/3/7

• 結果的にどうだったか？
– Auroraによる障害はこれまで0
• オンプレ時代同様の高い可用性を担保
• メンテナンスによる停止もこれまであったが、ゼロダウンタイムパッチのリリースによ
り解消
– DBサーバ運用に工数をほとんど割かなくてよい
• 本来の開発業務に集中
– 性能は問題なし
• 自分たちの場合は早くなりました！
– ライセンス費用が0
192017/3/7

Auroraに期待するところ
• PostgreSQL互換がほしい
– レコチョクではPostreSQLを使っているシステムも多い
• 移行がもう少し楽になっていた？
• 暗号化されたスナップショットの別リージョンへのコピー
202017/3/7

We’re hiring !
212017/3/7
エンジニアブログ公開中
https://recruit.recochoku.jp/ https://techblog.recochoku.jp/

Oracle racからaurora my sqlへの移行

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Oracle racからaurora my sqlへの移行

Similar a Oracle racからaurora my sqlへの移行 (20)

Más de recotech

Más de recotech (18)

Último

Último (9)

Oracle racからaurora my sqlへの移行