Azure Database for MySQL を Zabbix のバックエンドで使ってみる

# TL;DR
- Azure Database for MySQL サービスを作ってみた
- Zabbix のバックエンドで使ってみた
- Public Preview ということもありこれから感はあるものの、Managed度の高いRDBサービスなのでは

# Azure Database for MySQL って？
@myfinder さんのこちらをお読みください。
https://www.slideshare.net/decode2017/di15-build-2017-updates-azure-database-for-mysqlpostgresql
以上。

ではあんまりなので、↑のスライドを引用させて頂きつつサービスを作ってみます。
※追記:以下記載の内容はあくまで私の見解であり、スライド以外の内容について、myfinder さんの見解が含まれるものでない点ご承知ください。突っ込みありましたら是非コメント欄に頂ければと思います。

## 1. サービスを作る
新規作成の画面から、MySQL で検索すると出てくるのでそこから作っていきます。
サードパーティーのものも出てくるので注意です。

"Azure Database for MySQL" を選択します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/b117d90d-d80f-bc70-708e-584cab2c80bf.png)

パラメーターを埋めていきます。
- サーバー名は、Azure 内でユニークにする必要があります。
- バージョンは、5.6 か 5.7 を選択することができます。
- 価格レベルをワークロードに応じて選択します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/1d0ee0da-47a2-9676-0393-3d2ae4734fd0.png)

### 価格レベル/コンピューティング ユニットって？
AWS の RDS 等では出てこない概念だと思いますが、Azure の MySQL サービスは、**コンピューティング ユニット**を理解する必要があります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/63395313-6392-1cd7-efed-8872e679cd0c.png)

まず、Azure の MySQL サービスは、@myfinder さんのスライドにもありますが、仮想マシン(インスタンス) という概念を忘れる必要があります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/f91b638d-8b52-ab0d-8670-635b26a96ce3.png)

つまり、これまでもあったSQL Database でも同じなのですが、**仮想マシンのサイズを選んだり仮想マシンの可用性の設定を組んだりということをユーザー側でマネージする必要がない**ということになります。

この辺が Azure らしい点なのですが、ユーザーは余計なことを考えずに、プラットフォームに任せるところは任せてサービスを提供することに注力してくれという設計思想が色濃く出ている部分と思います。
ユーザー(ここでは特に開発者)としては、CPUとかメモリのスペックってどうでもよくて、想定したパフォーマンスが出せればなんでもいいですよね？ってことです。
(他のクラウドベンダーもそうして欲しいというは共通認識だと思いますが)

で、**このコンピューティング ユニット(CU)**ですが、**一つの単位**と理解します。
単純に、50 CU は 100 CU に比べると半分の性能、と考えます。
ただ、Basic と Standard の間は、メモリが2倍らしいので、SKU を超えて比較するものではなさそうです。
詳しくは↓にドキュメントがあります。
https://docs.microsoft.com/ja-jp/azure/mysql/concepts-compute-unit-and-storage#a-namewhat-are-compute-unitsaコンピューティング-ユニットとは

もう一点、これはこれまでの SQL Database との違いになりますが、DTU では、パフォーマンスの指標になっていた IO が、切り離されたという点があります。
こちらも @myfinder さんのスライドから。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/d6ed13de-cdeb-72cd-47f1-037ea0eb9da5.png)

確かに、SQL Database と Azure Database for MySQL のドキュメントを見比べると以下の様な違いがあります。
**SQL Database**
データベース トランザクション ユニット (DTU) とエラスティック データベース トランザクション ユニット (eDTU) の説明
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-what-is-a-dtu
> データベース トランザクション ユニット (DTU) として計算され、**CPU、メモリ、I/O (データおよびトランザクション ログ I/O) の組み合わせの測定値**です。


**Azure Database for MySQL**
コンピューティング ユニットとストレージ ユニットの説明
https://docs.microsoft.com/ja-jp/azure/mysql/concepts-compute-unit-and-storage#a-namewhat-are-compute-unitsaコンピューティング-ユニットとは
> コンピューティング ユニットは、単一の Azure Database for MySQL サーバーで使用できることが保証される CPU 処理スループットの測定値で、 **CPU とメモリ リソースを組み合わせた測定値**です。

この辺りの違いは、もう少し検証してみたいと思います。

前置きが長くなりましたが、ここでは、東日本リージョンで一番スモールな構成をしてみます。
お値段の感覚は↓の感じです。
※ドキュメント的には Standard も選べるようですがリージョンによって違うんですかね。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/140fdd71-2805-a224-0b2f-876701fee1a5.png)

## 2. 接続元の設定
続いて接続元の設定をします。既定では、誰からも接続ができません。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/67a8ea8f-cbd2-d4b7-c833-3ff4b09e6bdc.png)
※SSLの設定は、検証用&Azure内からのみということで一旦無効にしています。

## 3. サーバー パラメーターの設定
データベースの肝であるパラメーターです。設定できるパラメーターと既定値は今のところこんな感じです。
(バージョンは 5.7 です)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/95c93953-4c43-67f2-ccf4-f3b091682977.png)

# 使ってみる
サービスが出来てしまえば、あとは mysql コマンドや phpMyAdmin とかで管理ができます。

サーバー名やログイン名は概要ページで確認できます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/6faabf4c-8d6b-b778-9d63-3e106ee5248f.png)

## mysql コマンド

```
# mysql -h nomuprodb.mysql.database.azure.com -u tsubasa@nomuprodb -p
MySQL [(none)]> show variables like '%OS%';
+-------------------------------+--------+
| Variable_name                 | Value  |
+-------------------------------+--------+
| host_cache_size               | 188    |
| hostname                      | CLIENT |
| log_error_verbosity           | 3      |
| master_info_repository        | TABLE  |
| performance_schema_hosts_size | 0      |
| relay_log_info_repository     | TABLE  |
| report_host                   |        |
| version_compile_os            | Win64  |
+-------------------------------+--------+
8 rows in set (0.00 sec)

MySQL [(none)]> show variables like '%version%';
+-------------------------+------------------------------+
| Variable_name           | Value                        |
+-------------------------+------------------------------+
| innodb_version          | 5.7.17                       |
| protocol_version        | 10                           |
| slave_type_conversions  |                              |
| tls_version             | TLSv1,TLSv1.1                |
| version                 | 5.7.17-log                   |
| version_comment         | MySQL Community Server (GPL) |
| version_compile_machine | x86_64                       |
| version_compile_os      | Win64                        |
+-------------------------+------------------------------+
8 rows in set (0.01 sec)

MySQL [(none)]>
```

どうやら Windows で動いているようです。

## phpMyAdmin
さくっとコンテナで。

```
docker run -d --name phpmyadmin -h phpmyadmin -p 8081:80 --env=PMA_ARBITRARY=1 --env=PMA_HOST=nomuprodb.mysql.database.azure.com --env=PMA_USER=tsubasa@nomuprodb --env=PMA_PASSWORD=xxxxxxx phpmyadmin/phpmyadmin
```
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/50dbad71-a24e-9af2-0f5d-c88350d192ec.png)

## Zabbix
せっかくなのでアプリでも作ろうかと思いましたが、ちょうど自宅環境を監視している **Zabbix サーバー on Docker on Azure** をリプレイスしようと思っていたので、同時にバックエンドを Azure Database for MySQL にしてみました。

以下、あまり Azure Database for MySQL は関係ありません。

### 1. DB のアップグレード
リプレイス前は、Zabbix 2.4 を使っていましたが、最新の 3.2 にしてみます。
DBのスキーマが違うので、アップグレードが必要です。とは言っても、何もすることはなく、zabbix_server を start すると同時にアップグレードが走ります。

※ただ、Azure Database for MySQL に import したデータに対して、alter table でなぜかアップグレードが失敗したので、別にインスタンスを立ててDBのアップグレードをしました。

### 2. サーバーの起動
Zabbix もコンテナで。便利な世の中です。

```
docker run -d --name zabbix -h zabbix -p 8080:80 -p 10050:10050 -p 10051:10051 -v /etc/localtime:/etc/localtime:ro -v /mnt/alinsrv01-blob1:/mnt/blob1 --env=ZS_DBHost=nomuprodb.mysql.database.azure.com --env=ZS_DBUser=tsubasa@nomuprodb --env=ZS_DBPassword=xxxxxxx monitoringartist/zabbix-xxl:latest
```


# FAQ
## これまでは Azure に Managed な MySQL サービスは無かったの？
はい。これまで、Managed な MySQL サービスというのはサードパーティー製で、ClearDB が Marketplace には存在していましたが、Azure のサービスとしては存在していませんでした。
もちろん、SQL Server はだいぶ前からマネージドサービスとして存在しています。

## バックアップ機能はあるの？
5分に1回バックアップが自動的に取得されます。保存期間は SKU によって異なりますが、Basic では7日間保存されます。
バックアップからの復旧は、新しくデータベースサービスを作ります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/d21ff66f-cef0-b3dc-d6f1-8338523dc801.png)

## mysqldump は使えるの？
Azure Database for MySQL からの mysqldump、逆に、mysql コマンドを使用して SQL ファイルを流し込む、ということができるので、これまでのバックアップと同じ方法が使えます。

## Geoレプリケーションはできるの？
今後予定されているようです。

## VNET への統合はできるの？
こちらで UNDER REVIEW のステータスです。(6/27現在)
https://feedback.azure.com/forums/597982-azure-database-for-mysql/suggestions/19273909-vnet-integration

## MyISAM は使えるの？
(いるのかという議論は置いておいて)今のところ使えないようです。

Creating MyISAM Table in Azure database for MySQL is enable?
https://stackoverflow.com/questions/43973881/creating-myisam-table-in-azure-database-for-mysql-is-enable/

# まとめ
ざっと使ってみた感じ、とても簡単でした。
DBとなると、とりあえず使ってみるとは言え、バックアップは？可用性は？今のデータは使えるの？というところが気になりますが、とりあえず最低限のことをプラットフォームで勝手にやってくれて、mysqlコマンドも普通に使える(当たり前だけど)ので、今のところいい感じです。
今足りていない機能も、SQL Database と同じようなものが実装されていくんじゃないでしょうか。

あとは、パフォーマンスですが、これはもうちょっとシナリオをいくつか考えて検証してみたいところです。

総じて、Azure らしい、 PaaS 感のある(="Managed度が高い"と言い換えてみる)サービスと思います。