Aurora Serverlessが一般利用可能になったので試してみた
大栗です。
AWS re:Invent 2017で発表されていたAmazon Aurora Serverlessが一般利用可能になったので、早速試してみました。
Aurora Serverless MySQL Generally Available
Aurora Serverless
概要
AWS re:Invent 2017で発表されていたAuroraの新しい形態の動作モードです。
AuroraはSQL処理を行うDBインスタンス部分と高可用性な分散ストレージ部分が分離している構成をとっています。Aurora Serverlessでは通常DBインスタンス部分が起動しておらずストレージ部分だけがあります。そして一旦リクエストが来るとオンデマンドでDBインスタンス部分のコンテナが起動してSQLを処理します。負荷に応じて自動でスケールします。
特徴
Aurora Serverlessの特徴としては、以下のようなものがあります。
- シンプル
- インスタンスとキャパシティの管理が不要になります。
- スケーラブル
- クライアントとの接続を中断せずにコンピューティングとメモリを拡張します。
- コスト効率が良い
- 消費するコンピューティングリソースに対して1秒ごとの料金が発生します。
- 高い可用性
- 通常のAuroraと同様の6重化された自己修復を備えたストレージを基盤として構築されています。
ユースケース
Aurora Serverlessのユースケースとしては以下のようなものが想定されています。
- あまり使用されないアプリケーション
- 新規アプリケーション
- 可変ワークロード
- 予測不可能なワークロード
- 開発/テストデータベース
- マルチテナントアプリケーション
なお、Serverless Architecture専用のRDBMSではありませんのでご注意ください。
リージョン
利用可能なリージョンは以下の5リージョンです。東京もファーストリリースに入ってました。
- 米国東部 (バージニア北部)
- 米国東部 (オハイオ)
- 米国西部 (オレゴン)
- アジアパシフィック (東京)
- EU (アイルランド)
料金
Aurora Serverlessではコンピューティングリソースが動的に変動するのでAurora Capacity Unit (ACU)という単位で料金が設定されています。1 ACUは2GBのメモリをそれに対応するCPUとネットワークを備えています。ACUのリソースは通常のAuroraと同等のものです。1ACUから最大256ACUまでスケールできます。
米国東部 (バージニア北部) |
米国東部 (オハイオ) |
米国西部 (オレゴン) |
アジアパシフィック (東京) |
EU (アイルランド) |
|
---|---|---|---|---|---|
1 Aurora Capacity Unit (ACU) | $0.06 | $0.06 | $0.06 | $0.10 | $0.07 |
ストレージ料金(GB-月) | $0.10 | $0.10 | $0.10 | $0.12 | $0.11 |
I/O 料金(100 万リクエスト) | $0.20 | $0.20 | $0.20 | $0.24 | $0.22 |
注意
2018年8月10日現在では、
- Aurora ServerlessはMySQL 5.6互換でのみ利用可能です。
- 接続ポートは3306です。
- Aurora ServerlessにPublic IPを設定することはできません。Aurora Serverlessに接続するにはVPC内からでなければなりません。
- Aurora ServerlessはVPN接続やVPC Peeringを介してアクセスできません。ただしAWS Direct Connect経由では接続可能です。
- 以下のクラスタレベルのパラメータのみ設定可能です。
- character_set_server
- collation_server
- lc_time_names
- lower_case_table_names
- time_zone
- Aurora Serverlessでは以下の機能をサポートしていません。
- S3バケットからのデータロード
- Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し
- 高度な監査の使用
- Auroraレプリカ
- Backtrack
- Databaseクローン
- IAM データベース認証
- クロスリージョンリードレプリカ
- MySQLのDBスナップショットからのリストア
- Amazon S3からのバックアップファイルの移行
- Secure Socket Layer(SSL)によるDBクラスタへの接続
やってみた
以下の環境を前提としています。
- リージョン: 東京
- クライアントOS: Amazon Linux 2
- Aurora Serverless (MySQL 5.6互換)
RDSのManagement Consoleのインスタンスかクラスタの画面からデータベースの作成
をクリックします。
Aurora ServerlessはMySQL5.6互換のAuroraが対象なので選択します。MySQL5.6互換の箇所にも"Aurora Serverless capacity is only available with this edition."との記載があります。
DB詳細の指定を行います。
Capacity type
という項目が増えています。ここでServerless
を選択します。ちなみに既存のAuroraはProvisioned
のようです。
[詳細設定] の設定を行います。
まずはキャパシティーの設定です。ここでは、最小を2 ACU(4GB RAM)、最大を64 ACU(122GB RAM)を設定しました。64 ACU以上はメモリが正確に2GB単位でないようです。64 ACUは122GB、128 ACUは244GB、256 ACUは488GBとなっている模様です。
また、スケーリングの追加設定
でアイドル状態に一時停止するかを設定できます。ここではデフォルトのまま5分で停止する設定にしています。
セットワーク & セキュリティ
は既存のAuroraと同様です。
追加設定
を確認するとEncryptionが有効になっています。少なくともManagement Console上では暗号化が必須のようです。
上記設定でDBクラスタを作成します。
しばらくするとクラスタが作成されます。
アクセスしてみる
EC2のログインして、MySQLクライアント(実態はMariaDB)をインストールします。
1 | $ sudo yum install -y mysql |
CloudWatch上でServerlessDatabaseCapacity
が0で落ち着いていることを確認してから、初回の起動速度を確認してみます。
すると、今回の環境では22秒ほどかかりました。一旦起動すると0.1秒以下となりました。
1 2 3 4 5 | $ time echo '' | mysql -u awsuser -pmypassword -h serverless.cluster-a1b2c3d4e5f6.ap-northeast-1.rds.amazonaws.com real 0m22.089s user 0m0.005s sys 0m0.000s |
1 2 3 4 5 | $ time echo '' | mysql -u awsuser -pmypassword -h serverless.cluster-a1b2c3d4e5f6.ap-northeast-1.rds.amazonaws.com real 0m0.022s user 0m0.005s sys 0m0.000s |
次にデータベースとテーブルを作成してみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | MySQL [(none)]> CREATE DATABASE ServerlessDB; Query OK, 1 row affected (0.01 sec) MySQL [(none)]> use ServerlessDB; Database changed MySQL [ServerlessDB]> CREATE TABLE sample_table -> (col1 int , -> col2 varchar (20), -> col3 datetime); Query OK, 0 rows affected (0.03 sec) MySQL [ServerlessDB]> SHOW TABLES; + ------------------------+ | Tables_in_ServerlessDB | + ------------------------+ | sample_table | + ------------------------+ 1 row in set (0.00 sec) MySQL [ServerlessDB]> SHOW CREATE TABLE sample_table; + --------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | + --------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | sample_table | CREATE TABLE `sample_table` ( `col1` int (11) DEFAULT NULL , `col2` varchar (20) DEFAULT NULL , `col3` datetime DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | + --------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) |
普通にデータの挿入も出来ます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | MySQL [ServerlessDB]> INSERT INTO sample_table -> (col1, -> col2, -> col3 -> ) VALUES -> (1, -> 'Aurora Serverless' , -> now() -> ); Query OK, 1 row affected (0.03 sec) MySQL [ServerlessDB]> commit ; Query OK, 0 rows affected (0.01 sec) MySQL [ServerlessDB]> SELECT * FROM sample_table ; + ------+-------------------+---------------------+ | col1 | col2 | col3 | + ------+-------------------+---------------------+ | 1 | Aurora Serverless | 2018-08-10 03:09:54 | + ------+-------------------+---------------------+ 1 row in set (0.00 sec) |
ログインして使用する限りは普通のMySQLとして使用できます。
さいごに
コンピュートリソースを常時起動せずにオンデマンドで起動するというのはLambdaと同様の考え方で動いているので、極めてコスト効率が良いと思われます。初回の起動に少し時間がかかる点もLambdaににています。しかし初回起動時間がLambdaと比較すると現状では少し大きいのでユースケースを考えながら利用すると良いのではないでしょうか。