社内でAuroraのサーバーレスというのが出たらしいというので触ってみました。
Auroraのサーバーレス?
ん？Auroraのサーバーレス？どういうことだ？ よくわからなかったので、読んでみました。
これがAWSのニュース記事はこれ。
Aurora Serverless MySQL Generally Available | AWS News Blog
最初の方の文を抜き出してみると、インスタンスを意識しないで良いということだそうです。
You may have also heard of serverless, which allows you to build and run applications and services without thinking about instances.
簡単な構成図も説明と一緒に記載されています。
It creates an Aurora storage volume replicated across multiple AZs.
It creates an endpoint in your VPC for the application to connect to.
It configures a network load balancer (invisible to the customer) behind that endpoint.
It configures multi-tenant request routers to route database traffic to the underlying instances.
It provisions the initial minimum instance capacity.
日本語の方が理解しやすかった
でも、結局日本人なので日本語が一番理解できました。 インスタンスが自動でスケール・縮退・停止することから、
- ACU(Aurora Capacity Unit)というパラメータの増減でシステムリソースが自動調整される(インスタンス数は意識しない）
- 増減以外にもResume/Pauseも行われるので、使った分だけの従量課金に限りなく近くなる
と理解しました。
Amazon Aurora – 自動スケーリングサーバーレスデータベースサービス – AWS
Aurora Serverless は、 Aurora のオンデマンド自動スケーリング構成です。データベースのキャパシティーがアプリケーションのニーズに基づいて自動的に起動、シャットダウン、スケールアップまたはスケールダウンされます。Aurora Serverless を使用すれば、データベースインスタンスやクラスターを管理せずにクラウド内でデータベースを実行できます。Aurora Serverless は、自動的に起動し、アプリケーションの使用状況に合わせて容量を調整し、使用していないときはシャットダウンするため、まれにしか発生しない、断続的な、または予測不可能なワークロードに対するシンプルで費用対効果の高いオプションです。
検証機のDBを切り替えてみた
早速適用してみることになりました。
当初東京リージョンはもう少し先かと思ったのですが、既に来ているようでした。
常にアクセスがあるわけでない検証機は考えるまでもなく、費用削減効果が高そうなので、前提条件もクリアしてそうだったので、早速切り替えてみることにしました。
クラメソさんの記事には、本当にいつもお世話になっております。
手順
普通のRDSのバックアップリストアとほどんど変わりません。難しい手順は無いのですが、以下の通りやりました。
スナップショット取得
通常どおりスナップショットを取得。
インスタンス復元
インスタンス復元時にServerlessが指定できます。
起動を待つ
タイプがサーバーレスと表示されて少し楽しみです。ちなみに従来のAuroraのタイプは Provisioned になっています。
DBのサイズにもよるのかもしれませんが、クラスタ作成に20分ほどかかりました。
接続確認
作成後、mysqlコマンドで繋ぎにいったところ数十秒応答が無かったので、少し焦りましたが、上記のクラメソさんの記事でも最初は時間かかるとあったので、待ったら普通につながりました。
$ mysql -hmy-serverless-db.cluster.ap-northeast-1.rds.amazonaws.com -umyuser -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 4 Server version: 5.6.10 MySQL Community Server (GPL) Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql>
アプリ側はSpring Bootで動いているのですが、当然ながら接続設定変更して普通に動きました。
設定を確認してみる
クラスタ作成後に設定を変更できる点は以下の通りです。
特徴となるのがACU(Aurora キャパシティーユニット)で、2から64で何段階かに調整でき、即時反映されます。
- 最小ACU
- 最大ACU
アイドル時の自動停止までの時間も、最小5分から最大24時間で、秒単位指定できました。
気づいたこと
スケーリングの情報はログに出力されて管理画面で確認できる
拡張・縮退のタイミングはログに出力されているので、後からACUが変更されたタイミングを確認できます。
現時点の仕様だと、2ACU単位で縮小、拡大できるようです。下のログにもあるように結構細かく調整される印象です。（詳細な検証してないので、急なスパイク等にどこまで耐えられるかなどは、わかってないです）
PauseやResumeのタイミングも確認できます。
アプリケーション側から少しでもアクセスあるとAuroraは停止しない
当然といえば当然なのですが、常時DB接続があるタイプのアプリケーションでは、たとえアプリケーションそのものにアクセスが無くともAurora Serverlessは停止しません。監視等でちょっとした情報を定期的にDBに問い合わせる処理があっても同様です。この場合、Aurora Serverlessは最低限の2ACUで動き続けます。
DBからの接続の有無は、CloudWatchのDB接続のメトリクスなどがわかりやすいと思います。(Auroraの管理画面からも確認可能)
Aurora Provisionedの東京の料金は以下の通りです。
| タイプ | 料金 |
|---|---|
| db.t2.smal | 0.063USD |
| db.t2.medium | 0.125USD |
現時点のAurora Serverlessの最低料金は2ACUで0.2USDです。
つまり、もともと大きなインスタンスを割り当てている場合はAurora Serverlessは安くつきますが、db.t2.smallで事足りる環境ならProvisionedより高くついてしまうことになります。そんな環境でも、アプリケーション側を停止可能な場合は、開発環境などはアプリケーション側も停止してあげればAurora Serverlessで費用的なメリットを見込めます。
再起動時に数十秒、場合によっては１分以上も繋がらないのは辛い
Resumeについて、クラメソさんのブログで数20秒と書かれていましたが、それくらいで繋がる時もあれば、１分以上繋がらないことがありました。 作りによっては自動起動したアプリケーション側がタイムアウトとかして死んでしまう場合もあるかと思います。
自動停止した開発機、朝来てみたけど繋がらない。実は自動起動時にタイムアウトしていてアプリケーション落ちてました。そこから起動かけて・・・となると大変。何かしらケアしてあげる必要がありそうです。
この記事書き始めた時点では、「PauseとResume！PCみたいじゃん、検証機の費用安くなるかも！」と思ってましたが、そんな単純な話では無かったようです。
2018/08/15 追記
日本語版のブログも出ました。最後に東京リージョンでもリリースされている件と一緒に制限等も書かれています。利用する場合は一読することをオススメします。
