フォーム読み込み中
2025年1月16日掲載
クラウドサービスのデータベースといえばPaaS型フルマネージド型リレーショナルデータベースですが、一方でIaaS型リレーショナルデータベースもあります。今回はIaaS型リレーショナルデータベースのAlibaba Cloud ApsaraDB for MyBaseをご紹介します。
以前のtech blogにてAlibabaCloud、Azureの IaaS型リレーショナルデータベースを紹介しました。今回はこのIaaS型リレーショナルデータベースについて触れようと思います。
<参考>
リレーショナルデータベースってなに?Alibaba Cloud, AWS, Azure, Google Cloud のPaaS/IaaS型リレーショナルデータベースを比べてみました
現在、Alibaba Cloud、 Amazon Web Services、Micosoft Azure、Google Cloudなど主要クラウドサービスのデータベースは主にPaaS型リレーショナルデータベースが主流です。ただし、これらは全てPaaS型フルマネージドサービスとしてデプロイなので、クラウド上でMySQLの特定パラメータチューニングやOS/ソフトウェアの変更、PostgreSQLのpg拡張プラグイン導入などが困難な場面が多々とあります。
それだけでなく、クラウドサービスは限られたリソースグループの中で、多くのユーザーが物理サーバを共有し合いながらインスタンスをそれぞれ作成し利用するため、リソースグループ配下の物理サーバの利用効率が悪いので、パフォーマンスが安定しない時があります。
元々データベースはオンプレミス・クラウドを通じて『オンプレミスで自前で構築するデータベース』、『クラウド上で自前で構築するデータベース』、『クラウドサービスによるPaaS型データベース』の3種類があります。先述、『クラウドサービスによるPaaS型データベース』はPaaS型フルマネージドデータベースなので、ユーザーによる細かい操作運用はクラウドへ任してくれる分、作業労力から解放される代わりにデータベースの細かい設定やOS変更、拡張機能などの自由自在な変更がしにくくなります。
これらを解決するクラウドベースのデータベースが、『クラウド上で自前で構築するデータベース』こと、IaaS型リレーショナルデータベースです。IaaS型リレーショナルデータベースはクラウド上に自己管理・制御することが可能なIDCを構築するコンセプトを持ちます。今回はそのIaaS型リレーショナルデータベースであるAlibaba Cloud ApsaraDB for MyBaseを紹介します。
Alibaba Cloud ApsaraDB for MyBaseを紹介する前に、IaaS型リレーショナルデータベースが登場した背景を少し説明します。
先述通り、元々データベースはオンプレミス・クラウドを通じて『オンプレミスで自前で構築するデータベース』、『クラウドサービスによるPaaS型データベース』、『クラウド上で自前で構築するデータベース』の3種類があります。これは一長一短です。
『オンプレミスで自前で構築するデータベース』はユーザーがデータセンターやHW調達から始まり、OSインストール、RDBMSのインストール、パラメータ設定、運用監視などを全て自ら行います。その場合、全てのリソースは他のユーザーへ共有することなく独立した運用ができることや、自己管理でカスタマイズ設定ができるため、総じてデータセキュリティを強化することができます。一方で、運用コストが高いことや、維持管理における負荷が高く、またストレージの拡張も柔軟ではないためスケーラビリティが弱いなどの課題があります。
『クラウドサービスによるPaaS型データベース』はAlibaba Cloud、 Amazon Web Services、Micosoft Azure、Google Cloudなど主要クラウドサービスがデータベースをクラウド上のサービスとして展開したフルマネージド型データベースです。そのため、ユーザーはブラウザ上のコンソール画面にて数回ボタンをクリックするだけで、データベースを構築、運用することができます。スケーリングもクラウド側に任せられるため非常に便利です。高いSLAを保証してくれることも大きいです。ただし、このPaaS型データベースは先述通り共有リソースで構築するため、リソースが足り無くなった場合パフォーマンスが安定しないことや、データのセキュリティや拡張機能などDBMSのマニュアル操作面に触れることができないので、運用方法にも限りがあります。
『クラウド上で自前で構築するデータベース』は、上述、『オンプレミスで自前で構築するデータベース』と『クラウドサービスによるPaaS型データベース』の良いところを汲み取ったアプローチであり、ユーザーはクラウド上で物理サーバーを購入するだけで、クラウドサービス側がHWの調達、OSインストールを行い、データベースによるサービスを素早く展開することができます。スケーリングについても、手持ちの物理サーバーのリソース範囲内であれば、柔軟にスケーリングすることも出来ます。ただし、SLAは無く、DBMSをマニュアル操作するための学習コストも発生します。
上記の問題に対応して、Alibaba Cloudは『クラウド上のIDCデータベース』というコンセプトのもと、ApsaraDB for MyBaseサービスを展開しています。
ApsaraDB for MyBase
What is ApsaraDB MyBase?
ApsaraDB for MyBaseは、専用の物理サーバでありながら複数のHostで構成されたクラスタで、クラウド上の専用データベースクラスターとして提供しています。ユーザーはMyBaseリソースを購入すると、物理サーバともいえる専用ホスト上の複数のインスタンス・クラスタを利用することができます。
ユーザーは他のユーザーとリソース奪い合いをすることなく、専用ホストをベースとしたクラウドデータベースサービスが利用できます。現在専用ホストにはMySQL、SQL Serverのデータベースをホストの形でクラウドデータベースサービスとして購入することができます。それだけでなく、物理サーバのリソースが許される限り、様々な種類のデータベースを1つの物理マシンに混合導入することもできます。リソーススケジューリングには、MyBase専用のカスタマイズスケジューリングモードが付帯されており、これもPaaS型リレーショナルデータベースと同じくユーザーワークロードに応じてスケーリング処理を提供できます。
MyBaseで使う物理サーバはユーザーがマニュアル設定や拡張機能、独自ソフトウェアをインストールできるよう、OSレベルで権限をユーザー側へ提供しています。もちろんログと関連ディレクトリも閲覧することが出来ます。これにより、PaaS型データベースでは実現できなかったデータ暗号化等セキュリティの強化、ヘルスチェック等独自の監視基盤導入、2つのデータベースによるクロスレプリケーション運用などが行えます。
ApsaraDB for MyBaseは先述通り物理リソースレベルで操作するため、PaaS型フルマネージド型リレーショナルデータベースと少し異なる部分があります。
ApsaraDB for MyBaseは先述通り専用ホストレイヤーで購入するため、ホスト配下に複数ユーザーによるリソース競合によるサービスのパフォーマンス不安定さを回避することが出来ます。それだけでなく、専用ホスト配下リソースを効率よく配分するため、CPU、メモリ、ストレージ容量、IOPS、ネットワークトラフィックなどのリソースを最大限に活用することができます。
専用ホストはApsaraDB for MyBaseを司るうえで必要となるコア基盤であり、専用ホストの管理はホストの追加、ホストの切り替え、ホストの接続、ホストの配分状態の設定などを含みます。
Primary、Stand-by、Read-Only、Loggingインスタンスを含む四つのタイプのデータベースサービスインスタンスを専用ホスト上で構築したうえで管理します。
ApsaraDB MyBaseはPaaS型フルマネージド型リレーショナルデータベースと異なり、ユーザーはデータベースインスタンスに対して必要なリソース(CPU、メモリ、ストレージ等)を自由に選択することができます。PaaS型フルマネージド型リレーショナルデータベースの方でも垂直スケーリング(Spec変更)をする手もありますが、その場合インスタンスをスライドするため約3-5分程の長時間ダウンタイムが生じます。一方、MyBaseは専用ホスト配下のインスタンスベースなので、一切ダウンタイムすることなくスケーリングできます。これは11.11 独身の日でも実証されています。
<参考>
Configure elastic scaling for instances to handle traffic spikes
Upgrade the specifications of an instance for short-term use
ApsaraDB MyBaseはデータの耐久性と信頼性を確保するために、自動バックアップとリカバリ機能を提供しています。
ApsaraDB for MyBaseは、専用ホスト配下であれば、同時に異なるデータベースを配置もしくは異なるリソース利用特性を利用することもできます。また専用ホストによる特権として、上述通り物理レイヤーレベルでリソースを配分するため、より高いリソース利用率を実現し、合理的なリソースのオーバーアロケーションによりPaaS型データベースよりコストを削減できます。
ApsaraDB MyBaseは様々なリレーショナルデータベース(MySQL、SQL Server等)をサポートしています。仕様の性質上、HW・NWスペックに依存するSQL ServerもIaaS型リレーショナルデータベースサービスとしてサポートしているのは大きいです。
ユーザーワークロードに応じて、専用ホストのリソースが許容されている限り、リソースをスケールアップまたはスケールダウンすることが可能です。
ApsaraDB MyBaseはPaaS型フルマネージド型リレーショナルデータベースと同じく、データベースのパフォーマンスを監視し、問題が発生した際にはアラートを発信することができます。
ApsaraDB for MyBaseはIaaS型データベースでありながらも、操作内容や運用内容はPaaS型データベースとほぼ変わりないです。そのため、PaaS型データベースではなかなか解決できなかった次のいくつかの課題を解決することが出来ます。
Case1: フルマネージド型サービスなのか、リソースが低いのにCPU等使用率が高い
ApsaraDB for RDSやAmazon RDS、Google Cloud SQL、Azure DatabaseなどのPaaS型リレーショナルデータベースだと、スペックをいくら変えてもインスタンスリソースの使用率が低い割に高負荷状態である問題が時々発生します。24時間365日間CPU使用率を記録しても、常時統一した記録を取るのはクラウドの性質上困難だと思います。これはクラウドサービスとして共有リソース配下でクラスターを作成しているため、同リソース配下に他ユーザーのクラスター使用率が高い場合に、こういった事象が発生します。
この課題の解決策の1つとして、ApsaraDB for MyBaseへスライドする方法があります。ApsaraDB for MyBaseはリソースのハイパーアロケーション(割り当てや配分)をユーザー側で設定できるため、ホストのCPU使用率が向上し、クラスター使用率を抑制することができます。こちらは後述しますが、結果としてPaaS型リレーショナルデータベースより倍のパフォーマンスを発揮することができます。
Case2: ダウンタイムなしに垂直スケーリングしたい
ユーザワークロード増加に伴い、処理パフォーマンスを上げるためにデータベースとしてreplicaやRead Nodeを増やすといった水平スケーリングすることはありますが、垂直スケーリングだとスペックを物理的に変更するので瞬断が発生してしまうため、垂直スケーリングを見送っています。
これをApsaraDB for MyBaseだと、リソースプール配下でスペックを自由自在に変更できるため、ユーザワークロード増加に応じてインスタンスの使用(メモリ、CPU)を瞬断することなく一時的に増加させパフォーマンス向上が見込めます。また、予め指定した時間になるとインスタンス仕様のスペックを自動で戻すことも出来ます。
Case3: データベースのインスタンスの管理数が多くなると一元管理出来ず、運用コストや工数が増加してしまう
PaaS型リレーショナルデータベースの場合、コンソール上の管理画面だとそれぞれのデータベースインスタンス画面へ遷移しながらデータベースの設定や管理をする必要があります。それだとデータベースインスタンスが5個、10個、20個と持っている場合、一元管理が出来ず、運用コストや工数が発生してしまいます。
一方、MyBaseだと、OS権限を持つHostへのログオンをサポートしているため、Gatekeeperを使用してデータベースインスタンスが存在するホストにログインして管理し、カスタマイズされたスクリプトをHostにインストールしてシステム情報を収集し、カスタマイズ要件を実装することが出来ます。
本サービスは2023/05/28時点で中国本土、東南アジアおよび欧米で利用することができます。日本リージョンはまだ対応していません。
ApsaraDB for MyBaseは専用ホスト自体のみ課金されます。専用ホスト上にて構築している関連機能(クラスタ、インスタンス、メモリ、ローカルディスクなど)の料金は不要ですが、この関連機能のインスタンスにて、クラウドストレージを使用する場合はクラウドストレージの料金が別途発生します。
ApsaraDB for MyBaseの専用ホストはデータベースとしてプライマリ/セカンダリアーキテクチャを維持するために少なくとも二台必要で、いずれもSubscriptionで課金されます。クラウドストレージは使用量に応じたPAYG(従量課金)です。
課金項目 | ホストとストレージに基づいて課金 |
|---|---|
課金方法 | ホスト:Subscription ストレージ:PAYG(従量課金)とストレージパッケージ |
ApsaraDB for MyBaseの課金請求例:
例えば、シンガポールリージョンにて、ApsaraDB for MyBase およびMyBase上のMySQLサービス、DBストレージは100GBのESSDを一ヶ月間利用したとします。その場合、次の計算表から 月間で$720USDかかります。
プロダクト名称 | スペック | 課金数量 | 説明 | 単価(ドル) | 小計(ドル) |
|---|---|---|---|---|---|
MyBase MySQL 専用ホスト:2個 ●課金方法:Subscription | rds.g6.2xlarge 8Core 32GB イメージ:AliLinux | 2 | MyBaseのホストは少なくとも二個の購入が必要 | $342USD/月 | $684 |
ストレージ ●課金方法: PAYG(従量課金) | ESSD | 100GB | ストレージ使用量に従って課金 | $0.0005 USD/時間 | $36 |
$720ドル/月 | |||||
※ストレージ従量課金:100 × 0.0005 USD /時 × 24 × 30= 36 USD
ApsaraDB for MyBaseはPaaS型リレーショナルデータベースと異なるため、導入方法も違ってきます。ApsaraDB for MyBaseの利用イメージとしては、次のStep-by-stepになります。
STEP1. ApsaraDB for MyBaseサービスの有効化、クラスター作成
Alibaba Cloudアカウントを使用して、ApsaraDB for MyBaseサービスを有効化、専用クラスター(Dedicated Clusters)を作成します。
MyBaseを初回使用する際には `AliyunRDSDedicatedHostGroupRole` の権限を与える必要があります。
データベースエンジンやVPCなどを選定します。今回はMySQLを例に作成します。
MyBaseクラスターができました。コンソールからボタンを数回クリックするだけで物理サーバを持つようになりました。
STEP2. Hostおよびインスタンス作成
MyBaseクラスターから「Add Host」ボタンをクリックすることでHostを作成します。
ホストにて、インスタンスを作成します。今回は8vCPU 32GiBのデータベースを選定します。
STEP3. MySQLインスタンスの作成
Hostおよびインスタンスが作成し終えたら、今度はコンソール画面にてインスタンスタブからMySQLインスタンスを作成します。
ApsaraDB for MyBaseはPrimary/Standbyインスタンスがそれぞれあります。
これはメインとなるprimary のデータベースは全てStandby(secondary instances)へ保持する構造です。なお自動バックアップはスナップショット、全量データバックアップ、増分バックアップなど基本的なバックアップをサポートしています。
<参考>
STEP4. アカウント作成、ホワイトリスト追加、エンドポイント設定
ここまできたら、後は通常のPaaS型リレーショナルデータベースと同じように、アカウント作成、ホワイトリスト追加、エンドポイント設定、接続が行えます。
データベースアカウントを設定します。
MyBaseへアクセスするためのホワイトリストを追加します。
エンドポイントを設定します。
これで、ECSインスタンスなどからCLI操作でMyBaseへアクセスすることができます。
STEP5. MySQLパラメータの設定
今回はデータベースをMySQLにしてクラスタを立ち上げていますが、MySQLで操作できるパラメータはオリジナルと謙遜ありません。
ApsaraDB forRDB MySQLでは変更操作できなかったパラメータも変更が可能です。
百聞は一見に如かず、実際にパフォーマンスがPaaS型リレーショナルデータベースと比べて改善しているか、Sysbenchによるベンチマーク比較をしてみます。
1. 測定用のECSインスタンスを準備します。今回はCentOSを選定しています。
2. 測定用のECSインスタンスにて、Sysbenchをインストールします。
sudo yum -y install sysbench
sysbench --version
3. MyBaseクラスターおよびMyBase上のMySQLインスタンスを準備します。
専用クラスターの作成およびMyBase上のMySQLインスタンス作成は先述通りにあるため、ここでの説明は省きます。
4. MyBase上のMySQLインスタンスにて、アカウントおよびデータベース、ホワイトリストを作成し、エンドポイントを設定します。
ここも先述通りにあるため割愛。
5.測定用のECSインスタンスにてSysbenchによるベンチマークスクリプトを4つ準備します。
sysbenchprepareとsysbenchrunフォルダを作成し、sysbenchprepareにはprepare.sh、sysbench.sh、sysbenchrunにはsysbench.sh、test.shを格納しています。ディレクトリ配下構成は次の通りになります。
├─sysbenchprepare
│ prepare.sh
│ sysbench.sh
│
└─sysbenchrun
sysbench.sh
test.sh
それぞれのスクリプト内容は次の通りです。
./sysbenchprepare/prepare.sh
#!/bin/sh
mkdir -p logs
thread=100
echo "prepare data using default settings, ref sysbench SIZE" >> logs/sysbench_read_write_0_prepare.log
./sysbench.sh prepare ${thread} >> logs/sysbench_read_write_0_prepare.log
echo "data had been successfully initialized." >> logs/sysbench_read_write_0_prepare.log
./sysbenchprepare/sysbench.sh
#!/bin/sh
LUA=/usr/share/sysbench/oltp_read_write.lua
SIZE=50000
DB=mysql
HOST=rm-gs51k83m21ievm452eo.mysql.singapore.rds.aliyuncs.com
PORT=3306
USER=sbtest
PASSWORD=Test1234
DBNAME=sbdb
usage()
{
echo "Usage: ./sysbench.sh <prepare|run|cleanup> <num of threads>"
exit "${1}"
}
#chack argumets
if [ "${1}" = "" -o $# -gt 3 ]; then
usage 1
elif [ "${2}" = "" ]; then
THREADS=1
else
THREADS=${2}
fi
echo "Running command: sysbench ${LUA} --db-driver=${DB} --mysql-host=${HOST} --mysql-port=${PORT} --mysql-user=${USER} --mysql-password=${PASSWORD} --mysql-db=${DBNAME} --table-size=${SIZE} --tables=100 --events=0 --time=120 --db-ps-mode=disable --percentile=95 --report-interval=1 --threads=${THREADS} ${1}"
sysbench ${LUA} --db-driver=${DB} --mysql-host=${HOST} --mysql-port=${PORT} --mysql-user=${USER} --mysql-password=${PASSWORD} --mysql-db=${DBNAME} --table-size=${SIZE} --tables=100 --events=0 --time=120 --db-ps-mode=disable --percentile=95 --report-interval=1 --threads=${THREADS} ${1}
./sysbenchrun/test.sh
#!/bin/sh
DATE=`date '+%Y%m%d%H%M'`
mkdir $DATE
# thread=1000
# echo "prepare data using default settings, ref sysbench SIZE" >> ${DATE}/sysbench_read_write_main.log
# ./sysbench.sh prepare ${thread} >> ${DATE}/sysbench_read_write_main.log
for thread in 1000
do
echo "Time: $(date +"%Y%m%d%H%M%S"), now running sysbench with thread of: " + ${thread} >> ${DATE}/sysbench_read_write_${thread}.log
./sysbench.sh run ${thread} >> ${DATE}/sysbench_read_write_${thread}.log
done
# echo "cleaning data up." >> ${DATE}/sysbench_read_write_main.log
# ./sysbench.sh cleanup ${thread} >> ${DATE}/sysbench_read_write_main.log
./sysbenchrun/sysbench.sh
#!/bin/sh
LUA=/usr/share/sysbench/oltp_read_write.lua
SIZE=50000
DB=mysql
HOST=rm-gs51k83m21ievm452eo.mysql.singapore.rds.aliyuncs.com
PORT=3306
USER=sbtest
PASSWORD=Test1234
DBNAME=sbdb
usage()
{
echo "Usage: ./sysbench.sh <prepare|run|cleanup> <num of threads>"
exit "${1}"
}
#chack argumets
if [ "${1}" = "" -o $# -gt 3 ]; then
usage 1
elif [ "${2}" = "" ]; then
THREADS=1
else
THREADS=${2}
fi
echo "Running command: sysbench ${LUA} --db-driver=${DB} --mysql-host=${HOST} --mysql-port=${PORT} --mysql-user=${USER} --mysql-password=${PASSWORD} --mysql-db=${DBNAME} --table-size=${SIZE} --tables=100 --events=0 --time=120 --mysql-ignore-errors=1062 --db-ps-mode=disable --percentile=95 --report-interval=1 --threads=${THREADS} ${1}"
sysbench ${LUA} --db-driver=${DB} --mysql-host=${HOST} --mysql-port=${PORT} --mysql-user=${USER} --mysql-password=${PASSWORD} --mysql-db=${DBNAME} --table-size=${SIZE} --tables=100 --events=0 --time=120 --mysql-ignore-errors=1062 --db-ps-mode=disable --percentile=95 --report-interval=1 --threads=${THREADS} ${1}
スクリプト配置が完了したら、全てのスクリプトに対しchmodコマンドで実行権限を付与します。
chmod u+x *.sh
6. SysbenchによるベンチマークのためのSysbenchデータを準備します。
sh prepare.sh
7. Sysbenchによるベンチマークを実行します。
sh test.sh
sysbenchによる結果はそれぞれの日付付きディレクトリ配下にて、`cat sysbench_read_write_1000.log ` で確認できます。
cat sysbench_read_write_1000.log
ベンチマーク結果から、Read,write,queries,Latency:min,avg,maxそれぞれのデータを取得します。
8. 同じアプローチで、ApsaraDB for MySQLもベンチマークを実施します。
MyBase上のMySQLインスタンスと同じスペックの8vCPU 32GiBを使用します。
9. 5回ベンチマーク実行し、その平均をまとめたところ、比較結果としては次の通りです。
ApsaraDB for MyBaseの方がApsaraDB for MySQLより上回るベンチマークを記録しています。
特に興味深いのがLatencyです。IaaS型データベースの方が、物理サーバら専用リソースを担保している関係なのか原因は直接確認できないため不明ですが、IaaS型のLatencyはPaaS型より2倍以上の改善差が出ています。
「クラウドベースのIaaSリレーショナルデータベース」と聞いたら、普段は仮想コンピューティング上で構築したリレーショナルデータベースなどが浮かび上がると思います。しかし、本記事通りAlibaba Cloudが提供するApsaraDB for MyBaseは、クラウドサービスとしたIaaS型リレーショナルデータベースでありながら、設計思想が非常に優れていると感じます。
特に、PaaS型リレーショナルデータベースでは操作や制御できなかったパラメータ設定やネットワーク設定などが出来ること、必要なHW物理リソースを直接管理・運用することなくクラウドベースで専用ホストベースでリソース管理できるのはかなり魅力的だと思います。中でも、PaaS型リレーショナルデータベースと同じ金額レベルでありながら、パフォーマンス観点としてベンチマークも良いスコアを出していることも魅力です。
ただし、PaaS型リレーショナルデータベースはフルマネージド型サービスとしてデータベースソフトウェア自体を管理する必要がないことは、IaaS型リレーショナルデータベースのApsaraDB for MyBaseには物足りない部分とも言えます。こういった観点から、IaaS型とPaaS型リレーショナルデータベースはシナリオやニーズがかなり異なるとも考えられます。
Alibaba Cloudは中国国内でのクラウド利用はもちろん、日本-中国間のネットワークの不安定さの解消、中国サイバーセキュリティ法への対策など、中国進出に際する課題を解消できるパブリッククラウドサービスです。
MSP(Managed Service Provider)サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。
条件に該当するページがございません