STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

Cloud SQL Enterprise Plus エディションにおけるマイナーバージョンアップ時のダウンタイムについて

はじめに

テクノロジー部門プロダクト基盤本部の石坂です。

この記事は STORES Advent Calendar 2023の11日目となります。

2023年7月13日に Cloud SQL の Enterprise Plus のエディション (以下、Enterprise Plusと記載) が一般公開となりました。ドキュメントを見る限り、Enterprise Plusでは Enterprise エディション (以下、Enterpriseと記載) に比べメンテナンスダウンタイムの大幅な短縮が見込めそうです(*1)。

Enterprise、Enterprise Plusの両エディションでマイナーバージョンアップ作業を実施する際、実際のダウンタイムがどの程度となるか計測を行いました。

*1 : Cloud SQL editions features に10秒未満との記載があります。

計測時のシステム構成

Enterprise、Enterprise Plusのそれぞれについて下記のような環境を用意しました。

計測時のシステム構成

踏み台を経由し pg_isready コマンドによるデータベースへアクセスするルート(図中オレンジのライン)、アプリケーションのヘルスチェック用API経由でデータベースへアクセスするルート(図中グリーンのライン)の2つの計測ルートを用意しバージョンアップ作業中にそれぞれのルートのリーチャビリティを確認するスクリプトを実行することで計測を行いました。

なお、計測においてはインスタンススペックを可能な限り揃えるようにすることが望ましいのですが、今回は都合によりEnterpriseに関してはスペックを抑えた構成となっています(Enterprise Plusはdb-perf-optimized-N-2 (vCPU:2, memory:16GB)、Enterpriseはdb-custom-1-3840 (vCPU:1, memory:3.75GB))。

事前準備 (計測用スクリプトの作成)

ダウンタイムの計測にあたり図中のPCから実行する2種類のスクリプトを用意しました。

インスタンスの接続回避確認用スクリプト

ローカルのマシンからpg_isreadyコマンドを用いて、SQLインスタンスレベルのダウンタイムを計測するためのスクリプトです。

#!/bin/bash

while true; do
  pg_isready -h localhost -p 5432 -U dba
  date
  sleep 1
done

アプリケーションのヘルスチェックコール用スクリプト

ローカルのマシンからサービスのヘルスチェック用APIを呼び出し、サービスレベルのダウンタイムを計測するためのスクリプトです。

#!/bin/bash

if [ -z "$1" ]; then
    echo "[Error] Set service name as first argument" >&2
    exit 1
fi

SERVICE_NAME="$1"
REGION="asia-northeast1"

echo "SERVICE_NAME $SERVICE_NAME"
echo "REGION $REGION"

INVOKE_URL=$(gcloud run services describe $SERVICE_NAME --platform managed --region $REGION --format 'value(status.url)')

if [ -z "$INVOKE_URL" ]; then
    echo "[Error] Can't get invoke url" >&2
    exit 1
fi

echo "INVOKE_URL ${INVOKE_URL}"

ID_TOKEN=$(gcloud auth print-identity-token)

if [ -z "$ID_TOKEN" ]; then
    echo "[Error] Can't get id token" >&2
    exit 1
fi

while true; do
  RESPONSE=$(curl -X GET -s -w "\n%{http_code}" -H "Authorization: Bearer ${ID_TOKEN}" "${INVOKE_URL}/<HEALTH_CHECK_PATH>")
  echo "RESPONSE\n $RESPONSE"
  date
  sleep 1
done

計測結果

バージョンアップ所要時間はEnterpriseの方が短く、ダウンタイムはEnterprise Plusの方が短いという結果となりました。

Cloud SQL エディション バージョンアップ所要時間 ダウンタイム 更新作業時のCPU使用率の増加(ピーク時) インスタンスタイプ
Enterprise 約5分 約29秒 8% db-custom-1-3840 (vCPU:1, memory:3.75GB)
Enterprise Plus 約9分 約2秒 6% db-perf-optimized-N-2 (vCPU:2, memory:16GB)

まとめ

今回は、Cloud SQL Enterprise Plus エディションにおけるマイナーバージョンアップ時のダウンタイムについて調査を実施しました。

すべてのケースで同様の結果となることは保証できませんが、Enterprise、Enterprise Plusともにドキュメントに記載されているダウンタイムを下回る結果となりました。 特にEnterprise Plusのダウンタイムは約2秒という短いものとなっており、データベースに関する構成を複雑にすることなく高い可用性が見込めます。

ダウンタイムを極力短くしたいというサービスの要件を満たすためには、Cloud SQL Enterprise Plus エディションの採用は有効な選択肢となると考えらるのではないでしょうか。

本記事がどなたかの参考となれば幸いです。