【ITニュース解説】Is Cloud SQL Enterprise Plus Worth It? Evaluating the MySQL upgrade at SpareRoom

システムエンジニアを目指す初心者の皆さんにとって、企業が日々のサービスを支えるデータベースをどのように選び、改善しているのかは、非常に興味深いテーマだろう。今回解説する記事は、まさにその実践的な例を紹介している。Google Cloud SQLというクラウド上でデータベースを提供するサービスで、MySQLという人気のあるデータベースを、古いバージョンから新しいバージョンへ、そして利用するサーバーのタイプもアップグレードした際の実体験が書かれている。

この企業「SpareRoom」では、約5年間Google Cloud SQL上でMySQLを基盤として利用してきた。これは、Webサイトやアプリケーションのデータを保存し、ユーザーからの問い合わせに応答するための、まさに心臓部ともいえるシステムだ。彼らは今年に入り、MySQL 5.7からMySQL 8という新しいバージョンへのアップグレードに直面した。データベースのバージョンアップは、新しい機能や性能改善の恩恵を受けられる一方で、互換性の問題や予期せぬ挙動のリスクも伴うため、慎重な計画が必要だ。

このバージョンアップの機会に、SpareRoomは、利用していたデータベースインスタンスの種類も検討することになった。これまでの「Enterprise」インスタンス（古い世代のN1マシンファミリーが使われている）から、新たに提供された「Enterprise Plus」インスタンス（より新しいN2マシンファミリーが使われている）への切り替えが可能になったのだ。新しいEnterprise Plusインスタンスは、高性能なN2マシンファミリーを採用していることから、理論上は性能向上が期待できる。しかし、コストが高い上に、vCPU（仮想CPU）の数が2のべき乗（2, 4, 8, 16...）に限定され、RAM（メモリ）もvCPUあたり8GBと固定されるなど、構成の自由度が低いという特徴があった。さらに、具体的な性能向上の数値が明確ではなかったため、単にコストが増えるだけで、本当に費用対効果があるのかが不明瞭だった。

そこで、SpareRoomのエンジニアは、自分たちのシステムに本当にEnterprise Plusが必要なのか、最適なインスタンスサイズはどれくらいなのかを判断するために、自分たちで性能を測定する「ベンチマーク」を実施することにした。ベンチマークとは、特定の条件下でシステムの性能を評価するためのテストのことだ。単にスペックシートの数字だけを見るのではなく、実際の使い方に合わせたテストを行うことで、より現実に即した判断ができる。

ベンチマークの設定にあたり、彼らは普段から課題となっている、実環境での代表的な処理に焦点を当てた。具体的には、以下の3種類のワークロード（処理のパターン）を選んだ。 一つ目は「トップクエリ」だ。これは、ユーザーがWebサイトを検索したり、ページを閲覧したりする際に発生する、高速かつ大量のデータ読み出し（SELECT）処理を指す。これらの処理はピーク時のシステム負荷を大きく左右するため、非常に重要だ。テーブルのデータがメモリに収まるような、高速性が求められるクエリが対象となった。 二つ目は「バッチ削除」だ。これは、古いログデータなどを大量にまとめて削除する処理を意味する。このような処理は、夜間の限られた時間帯に完了させる必要があるため、処理速度が重要となる。 三つ目は「スキーマ変更」だ。これは、データベースの構造（テーブルの定義など）を変更する処理で、通常、この処理が完了するまでシステム全体のデプロイ（新しいバージョンのプログラムを公開する作業）がブロックされてしまうため、できるだけ短時間で終わらせる必要がある。

これらのワークロードを評価するため、SpareRoomの既存のデータベースインスタンス、つまりベースラインとして「Enterprise 24vCPU / 90GB RAM」を設定した。そして、このベースラインと、様々な構成のEnterprise Plusインスタンスや、既存のEnterpriseインスタンスを比較した。比較対象には、コストがほぼ同じになるように調整したインスタンスや、コア数が直接比較できるインスタンスなどが含まれた。例えば、新しいEnterprise Plusでは「16vCPU / 128GB RAM」が最も現実的な候補とされ、これに加えてより小さい「8vCPU / 64GB RAM」や、既存のEnterpriseでコストを合わせた「28vCPU / 90GB RAM」、直接比較するための「16vCPU / 64GB RAM」といったインスタンスが用意された。

インスタンスの比較表では、vCPU（仮想CPUの数）、マシンタイプ（N1かN2か）、RAM（メモリ容量）、ストレージ容量、IOPS（1秒あたりの入出力操作数）、そして時間あたりの価格といった詳細な情報が並べられている。この中には「Data Cache（データキャッシュ）」というオプションも含まれている。これは、データベースの読み取り性能を向上させるために、ローカルに接続されたSSDストレージを利用する機能だ。

ベンチマークは、データベースサーバーと同じリージョン（地域）とゾーン（データセンター内の区画）にある高速な仮想マシンから実行された。これは、ネットワークの遅延といった外部要因を最小限に抑え、純粋なデータベースの性能を測定するためだ。

まず、「トップクエリ」の性能評価からだ。これは、SpareRoomで最も頻繁に実行される上位5つのクエリを選び出し、それぞれのクエリが実行される頻度に合わせて重み付けをしてテストが行われた。テストは複数のスレッド（同時に処理を行う単位）で実行され、データベースに様々な負荷をかけた状況をシミュレートした。 テストの結果、中程度の負荷（12スレッド）の場合、Enterprise Plusの16vCPUインスタンスは、既存のEnterprise 24vCPUや28vCPUインスタンスと比較して、約45%も高速であることが判明した。さらに、Enterprise Plusの8vCPUインスタンスでも、既存の大きなEnterpriseインスタンスに十分に匹敵する性能を見せた。 高負荷時（32スレッド）のテストでは、コア数が75%も多いEnterprise 28vCPUインスタンスが、ようやくEnterprise Plus 16vCPUインスタンスに追いつくレベルだった。つまり、Enterprise Plusは、より少ないリソースでも同等以上の性能を発揮できる可能性を示唆していた。特に注目すべきは、Enterprise Plusの8vCPUインスタンスが、Enterpriseの16vCPUインスタンスと同等の性能を発揮しつつ、コストは約17%も安かったという点だ。この結果から、Data Cacheはインメモリのデータ読み出しには効果がないと判断され、その後の分析からは除外された。

次に「バッチ削除」と「スキーマ変更」の性能評価だ。これらは、数百万行のデータを削除したり、データベースの列の定義を変更したり、新しいインデックスを追加したりといった処理だ。これらの処理では、CPUコア数自体はそれほど重要ではなく、CPUの世代やストレージの性能が大きく影響することがわかった。 具体的には、数百万行のデータを削除する処理は、Enterprise Plusインスタンスで25%から40%も高速化した。これは、Data Cacheが有効になっているかどうかで差が出ることもあった。スキーマ変更については、Enterprise Plusインスタンスで5%から15%という、より控えめながらも確実に性能向上が見られた。

これらのベンチマーク結果に確信を得て、SpareRoomは実際に多くのデータベースを、より小さいサイズのEnterprise Plusインスタンスに切り替えることを決定した。これまでのEnterprise 24vCPUインスタンスは、Enterprise Plus 16vCPUインスタンスへと変更された。そして、実際に運用を開始した後も、Cloud SQLの「Query Insights」というツールを使って、切り替え前と後の性能を比較した。この比較は、ほぼ同程度のトラフィックがあった2週間分のデータ（約3億6千万件のクエリ実行）に基づいている。 その結果、実際の運用環境において、平均で約35%の性能向上が確認された。これは、ベンチマークで得られた45%という数値よりもやや低いが、その差はネットワークの遅延などが影響している可能性が指摘されている。しかし、それでも大幅な性能向上であり、システム全体の応答性改善に貢献していることが示された。

総合的な判断として、Enterprise Plusへの移行により、SpareRoomのコストは約20%増加した。これは、Enterprise Plusの構成オプションが限定的であるため、既存のインスタンスと同じような構成にしようとすると、どうしても高価になってしまうためだ。しかし、今回のベンチマークで確認された大幅な性能向上に加えて、Enterprise Plusが提供する追加のメリットも評価された。例えば、より高いSLA（サービス品質保証）、ほぼゼロダウンタイムでメンテナンスが実施されること、35日間のPoint-in-Timeリカバリ（特定の時点にデータベースを復元できる機能）、インデックスアドバイザーといった運用面や信頼性に関わる機能群だ。これらのメリットを総合的に考慮した結果、Enterprise Plusへの移行は「明確な勝者」であると結論付けられた。

この記事から、システムエンジニアを目指す初心者の皆さんが学べることは多い。まず、新しい技術やサービスを導入する際には、ベンチマークという具体的なデータに基づいた検証が非常に重要だということだ。ベンダーが提示するスペックだけでなく、自分たちのシステムにおける実際の利用状況に合わせて性能を測定することで、本当に必要なものを見極められる。 そして、単純に「新しいものが良い」とか「コア数が多い方が速い」とは限らないという事実だ。今回のケースでは、Enterprise Plusは少ないコア数でも既存のEnterpriseより高性能であり、アップグレード時には既存のインスタンスと同じか、あるいはそれ以上のコア数を選ぶ必要はないという教訓が得られた。むしろ、ダウンサイジング（より小さいインスタンスへの変更）がコスト削減と性能向上を両立させる可能性もある。 さらに、性能だけではなく、システムの信頼性や運用効率を高めるための機能も、長期的な視点で見れば非常に価値があるということも理解しておきたい。データベースの選択一つをとっても、技術的な知識だけでなく、コスト、運用、信頼性といった多角的な視点から総合的に判断することが、システムエンジニアには求められるのだ。