22日目の担当はDBAのsuzukitoです。
アイスタイルでは、現在「システム Reborn プロジェクト」を絶賛実行中です。
このプロジェクトを一言でまとめると「クラウド化と開発手法の見直し」になります。
この中で私は、RDBMSのクラウド化を担当しています。
DBMSのクラウド化手法は一般的には次の3つに分類されます。
- Re-Host
- DBエンジンは変えずにそのままクラウド化する
- Re-Architecture
- クラウド化と同時にDBエンジンも変更する
- 移行工数は多いが、移行が一回で済む
- Re-Host & Re-Architecture
- ひとまずそのままクラウド化だけを行う
- 将来的にクラウドの最適なDBエンジンへ移行する
最初に一番確実なRe-Hostで行う方法を調査したのですが、簡単にいきそうにありませんでした。
なぜならアイスタイルはSQL Serverも使っているのです。
しかも移行先はAzureではなくAWSです。
MySQLの移行先は簡単に決まります。そうです、RDS Aurora MySQLですよね。
しかし、SQL Serverは？
いままで検討していなかったので調査を開始しました。
まず困った事
- RDS for SQL Serverはレプリケーションをサポートしない
- RDS for SQL Serverの価格がとってもお高い
まずはRDSの採用を検討しました。
RDS for SQL Serverはレプリケーションをサポートしない
リードレプリカは作れます。でも、必要な機能はそれじゃ無いんです。
SQL Serverのレプリケーションは、かなり独特で高機能です。
単純な複製を作るリードレプリカと異なり、サーバー間、データベース間で、自由にテーブルの複製が作れます。
うちのアプリケーションは、広範囲でこの機能を使っているので、この機能が無いと大幅なアプリケーション修正が必要になります。
RDS for SQL Serverの価格がとってもお高い
同じインスタンスクラスでも、AuroraとSQL Serverとで1時間当たりの単価に数倍の価格差があるとは。。。
また、リザーブドインスタンスの割引率も大違いでした。
Pricing Calculatorで試算すると、1年間の運用費用がオンプレサーバーのハードウェア＆ソフトウェアの購入金額の2倍になってしまいました。
Re-Hostにこれだけの金額をつかうのなら、アプリケーションを修正して、、、
Re-Architectureした方がよいのでは？
と、頭によぎりました。
次に困った事
- ライセンス持ち込みするとクラウド上にオンプレができてしまう
- ライセンス付き Amazon Machine Image の価格もお高い
RDSの価格に打ちのめされて、EC2にサーバーを立てることを検討しました。
ライセンス持ち込みするとクラウド上にオンプレができてしまう
我々はオンプレにWindowsとSQL Serverのライセンスを所有しています。
が、マイクロソフトのライセンスポリシーに違反せずに、これをAWSに持ち込んで使う場合は、Amazon EC2 Dedicated Hostsというサービスを使うことになります。
ライセンスを守るため、1つのハードウェアで稼働させることになりますし、サーバーの追加もオンプレ時代と変わらず、ライセンスの見積・購入が必要です。
クラウド化で手に入れたい俊敏さが無くなってしまいます。
Amazon EC2 Dedicated Hosts | AWS
ライセンス付き Amazon Machine Imageの価格もお高い
ライセンス持ち込みはデメリットの方が大きそうなので、ライセンス付き Amazon Machine Imageの料金を調べました。
すると当然ですが、WindowsとSQL Serverのライセンス料が乗っかっているため、Linuxサーバーと比べて高額なのです。
仮想マシンを使ったRe-Hostではクラウド化されたオンプレ爆誕で終わってしまいそうです。
マネージドサービスでもないのに、RDS Auroraより高額になるんなら、、、
Re-Architectureした方がよいのでは？
と、頭によぎりました。
次に考えたこと
- 複数サーバーを1つのRDS for SQL Serverに統合したらどうか
またRDSに戻ります。
どうにかしてRDSに移行する事はできないのか。
複数サーバーを1つのRDS for SQL Serverに統合したらどうか
レプリケーションできない欠点を補うには、レプリケーション不要な状態を作れば良いのでは？
と考えました。
サーバーのCPU数、メモリ数で試算した場合、db.r5b.12xlargeで全てがおさまりそうです。
でも、スケールアップの上限はdb.r5b.24xlarge。あと2つしかスケールアップできません。
リードレプリカ作成数も最大8レプリカです。
いままでは複数のサーバーで分散して実行されていたバッチ処理が集中して処理できるのか不安です。
移行は出来るかも知れません。今は良いでしょう。
でも、それって負債を未来に先送りしていることになりかねません。
Re-Hostできない事はないが、負債を未来に先送りしているだけなのではないのか、、、
Re-Architectureした方がよいのでは？
と、頭によぎりました。
困って考えて次にやったこと
- Re-ArchitectureしやすいRDBMSを検討してみる
- TiDBを移行先候補に挙げる
視野を広げてみました。
Re-ArchitectureしやすいRDBMSを検討してみる
Aurora MySQLでは残念ながらSQL Serverから移行するのに機能が足りていません。
マイクロサービス化の道のりは長く遠く、現時点での我々のアプリケーションはデータベースを共有利用しているのです。
全てのデータベースを1つのサーバーのようにアクセスできなくては移行できません。
スケールアップにはもう限界が見えています。
移行完了して、スケールアップの上限があと2つなんて時限爆弾のようです。
レプリケーション不要な状態を実現でき、スケールアウトができる分散RDBMSが必要なのです。
SQL Server互換では見つかりませんでしたが、MySQL互換の分散RDBMSならアテがありました。
TiDBを移行先候補に挙げる
TiDBはReadもWriteもスケールアウト可能な分散RDBMSです。
MySQL互換なのも我々の要件に合致していました。
TiDBであれば、1つのクラスターの内に全てのデータベースを移設し、最小限のアプリケーション修正でRe-Architecture可能です。
そして今やっていること
- Aurora MySQL, TiDB, SQL Serverで比較検討する
やっと検討できる段階になりました。
豊富な実績のあるAurora MySQLか。
ポテンシャルが高いニューフェイスのTiDBか。
Re-Host & Re-Architecture戦略でSQL Serverにするか。
来年のアドカレでは、実際にどれが選ばれて、どのように移行を実施しているか報告しますね！
次は無限列車編！
乞うご期待！
