oracle racからaurora my sqlへの移行

© RecoChoku Co.,Ltd. Proprietary and Confidential

株式会社レコチョク事業推進部　システムアーキテクトグループｼｽﾃﾑ

酒井　修平

05/03/2023

Oracle RAC から Aurora MySQL への移行


アジェンダ

205/03/2023

クラブレコチョクという会員サービスをOracle RAC から Aurora MySQL へ移行したお話

1. レコチョクとクラブレコチョクについて

2. Aurora を選択した理由

3. どのように Aurora へ移行したか

4. どのように Aurora を運用しているか

5. Aurora に期待するところ


自己紹介

305/03/2023

● 名前 - 酒井修平　 @darshuheider

● サーバサイドエンジニア - クラブレコチョク　システム担当

● 好きな AWS サービス - Aurora - Lambda

● 好きなアーティスト - レキシ - 星野源 - Negicco - アップアップガールズ ( 仮 ) - チャオベッラチンクエッティ

● ポジション - 2 番セカンド


レコチョクとクラブレコチョクについて

405/03/2023

• レコチョクではどんなサービスを展開しているか？

従来の事業領域（デジタル音源配信）

自社（レコチョク）協業

従量課金制定額課金制従量課金制定額課金制

新事業領域（より幅広い音楽ソリューションサービスへ）



505/03/2023

• システム全体としてはどのような感じか？

– 機能やサービス毎にシステムを構築

• 楽曲検索、決済、会員 ( クラブレコチョク ) 、楽曲情報　 etc..

– 全てを AWS 上に構築

• EC2 ：約 1000

• RDS ：約 180

• 30 以上の AWS サービスを利用



605/03/2023

• クラブレコチョクとはどのようなサービスか？

– レコチョクが展開するサービスへ会員機能を提供する

– 主な機能

• 会員登録・ログイン• 会員の属性情報管理 (My アーティスト登録 )• セッション管理• 端末管理



705/03/2023

• クラブレコチョクとはどのようなサービスか？

– 有効会員数は約 1000 万

• DB 全体のレコード数としては数億レコード

– アクセス数は多いと秒間 250 リクエストは超える

– 各サービス横断で利用されるので高い可用性が必要



805/03/2023

• クラブレコチョクシステム構成図

バッチ

会員システム

分析系システム

東京リージョン

連携システム

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 を選択した理由

905/03/2023

• そもそも会社全体としてどのような課題があったか？

– データ総量の予測が困難になってきた

• 楽曲数の増加、動画やハイレゾ音源の対応

– コストの最適化

• 短期間でのサービス立ち上げ、急激なアクセス増に対応するため多めにインフラリソースを保持

– コストの明確化

• サービス、システム毎のインフラコストが把握できていない



1005/03/2023

• クラブレコチョクはオンプレでどのように運用されていたか？

– DB は Oracle で RAC 構成

• 2 ノード– 2CPU 4 コア

• エンタープライズ・ストレージ

• Oracle EE Partitioning + RAC 　オプション

• 全コンポーネントの冗長化

– DBA がインフラを運用

• 監視– コネクション数、表領域、 CPU etc..

• バックアップ



1105/03/2023

• なぜ Aurora を選択したのか？

– 高い可用性を担保するため

• 様々なサービスから利用される

• 求められる可用性については同じ– 定期的にメンテがあるのでサービス調整はしました

– 運用工数を抑えたい

• 運用は開発チームに移管


どのように Aurora へ移行したか

1205/03/2023

• 大きく分けると 4 つの作業を実施しました

– テーブルを再作成

– SQL の修正

– データの移行

– 性能試験

• DMS などの移行ツールが一般公開になる前だったので、全て自前でスクリプト等を作成しました



1305/03/2023

• テーブルを再作成

– DDL の作成

• データ型を変更していく。比較的機械的な作業

• アプリ側も適宜修正

– パラメータグループの作成

• DBA から基本的な設定内容について教えてもらう

• デフォルトのトランザクション分離レベルは Oracle と違うので注意



1405/03/2023

• SQL の修正

– 関数を MySQL で使えるものに変換していく

• MERGE 構文、 DECODE 関数、 TO_CHAR 関数　 etc..

– コメントの修正

• “--” 　→　“ --(空白 )” もしくは “#”

※基本的には公式ドキュメントとにらめっこしながら対応しましたhttps://dev.mysql.com/doc/refman/5.6/ja/compatibility.html

https://dev.mysql.com/doc/refman/5.6/ja/compatibility.html

https://dev.mysql.com/doc/refman/5.6/ja/compatibility.html



1505/03/2023

• データの移行

– 更新日を見ながら、過去数年分を一気に移行

• データ量が多かったことと、性能試験を本番相当のデータで実施したかったので、 1ヶ月前からデータ移行を開始

• DATE や DATETIME は年を下 2桁だけにしてしまうと、 1900年代か2000年代を勝手に変換するので注意 (生年月日が未来日の人できてしまうかも。。 )

– 移行が完了したら、切り替え当日まで差分を日次で更新



1605/03/2023

• 性能試験

– 本番相当のデータを使って運用テスト、負荷テストを実施

• スロークエリをとって性能が出ていないものがないか監視

– 実行計画をとってフルスキャンしているものがないか確認

• 実際には全 SQL の実行計画をとれなかったので全て見るべきだったと反省。。

　⇒上記で問題のあるものに対し適宜対応を実施・ SQL の最適化・インデックス追加・サブクエリをなくして 2回 SQL を投げるように修正・検索専用のテーブルを追加 (後方一致検索に 10分以上かかってしまった )

※パラメータの修正は一切行わず


どのように Aurora を運用しているか

• 最初は何を見ればいいかわからなかった。。

– 元々インフラを管理していた人とかに相談

• 標準的に見るべき項目や閾値を策定してもらう– CPU 、メモリ、クエリ数、コネクション数、スロークエリ、スループット

• ダッシュボードの作成

1705/03/2023



• Aurora に合わせた監視内容に変更しました

– CPU使用率が比較的高め

• インスタンスリソースをフルに活用する– CPU使用率が 95% を超えたことがありましたが、正常に動き続けてまし

た。。

– インスタンスリソースによる監視はやめる

• スループットやレイテンシーの監視のみ

1805/03/2023



• 結果的にどうだったか？

– Aurora による障害はこれまで 0

• オンプレ時代同様の高い可用性を担保

• メンテナンスによる停止もこれまであったが、ゼロダウンタイムパッチのリリースにより解消

– DB サーバ運用に工数をほとんど割かなくてよい

• 本来の開発業務に集中

– 性能は問題なし

• 自分たちの場合は早くなりました！

– ライセンス費用が 0

1905/03/2023


Aurora に期待するところ

• PostgreSQL互換がほしい

– レコチョクでは PostreSQL を使っているシステムも多い• 移行がもう少し楽になっていた？

• 暗号化されたスナップショットの別リージョンへのコピー

2005/03/2023


We’re hiring !

2105/03/2023

エンジニアブログ公開中

https://recruit.recochoku.jp/ https://techblog.recochoku.jp/

https://recruit.recochoku.jp/

https://recruit.recochoku.jp/

https://techblog.recochoku.jp/

https://techblog.recochoku.jp/

oracle racからaurora my sqlへの移行

Technology