こんにちは！ BFT名古屋支店の佐野です。
今回はAWSが提供するリレーショナルデータベースであるAmazon Auroraのうち、Aurora Serverlessというタイプについてお話していきます。
はじめに：AWSでのサーバーレスの定義
Aurora ServerlessはAWSが掲げるサーバーレスサービスのひとつとして挙げているもののひとつです。
Aurora Serverless以外のサーバーレスサービスでは、LambdaやStepFunctions、API Gateway、DynamoDBなどがあります。
これらの共通点であり、サーバーレスの根幹とも言える要素として「サーバーを管理することなく運用できる」という点があります。
サーバーレスと言っても、そのサービスを動かしているのはやはり物理的なコンピューターであり、AWSのサーバーです。
しかしサーバーレスサービスではEC2やRDSなどのようにインスタンスレベルで仮想マシンを“個別に確保”して運用することはありません。
ユーザーがそのサービスを利用する時にAWSが内々で状況に適したサーバーリソースを用意・割り振るため、その管理をユーザーが意識することがないのです。
つまりサーバーレスとは細かく言えば「サーバー“管理”レス」となります。
例えば今回紹介するAurora Serverlessの場合であれば、作成時にクラスターこそ構成しますが、そのクラスターを構成しているDBインスタンスについてはユーザーが割り当てることなく、AWSが割り当て・管理することになるため、まさしくサーバーレスであると言えます。
サーバーレスなAurora Serverlessが持つ良いところ
サーバーレスなリレーショナルデータベースであるAurora Serverlessの一番の長所は、前項でも述べたサーバーレスの長所でもあるサーバーの管理が不要であるに尽きます。
Aurora Serverlessはリクエストなどによる負荷（CPU使用率と接続数）に応じて自動でスケーリングが行われるため、性能が必要な時とそうでない時に生じるコンピューティングリソースの無駄を省くことができます。
また常時的に高い性能を維持しておく必要がないため、最大の負荷を想定して高い性能のデータベースを常に置いておくよりもコストがずっと安くなるということにもなります。
加えて使用されていない時間はデータベースを自動的に停止させることもAurora Serverlessでは可能です。
その場合は停止している時間分、ストレージの使用量以外の料金がかからなくなるため、ここでも低コストになりやすいと言えるでしょう。
総じて、管理面および実費面においてコストの無駄を省き、結果的にコスト低減につなげることができる……というのがAurora Serverlessの良いところとなります。
Aurora Serverlessで注意すべき点
コスト面では概ね既存の非サーバーレスなデータベース系AWSサービスよりも優れていると言えるAurora Serverlessですが、運用時において注意すべき、そして受容すべき点がいくつかあります。
まずAurora Serverlessの長所としても挙げた自動スケーリングについては、それができない場合がいくつかあります。
例えば、クエリの処理中やトランザクションの進行中、一時テーブルまたはテーブルがロックされている状況の場合は、スケーリングが行われません。
これはスケーリングを行なうためのタイミングである“スケーリングポイント”を挟むことができないためで、特に高負荷かつ長いクエリを処理している時は、たとえその時点での性能が不足であってもスケーリングによって性能を合わせることができないのです。
この点については以下の公式ドキュメントにも注意点として記載があります。
また自動停止を有効化している場合、停止している状態から復帰する場合に概ね1分くらいの時間がかかることも注意点として挙げられます。
停止しているAurora Serverless クラスターにアクセスした場合、すぐに応答は返ってきません。この仕様を知らない場合、アクセスしたユーザーは戸惑うだろうと考えられるレベルです。
この点から、常に即応性を求められるシステムには、Aurora Serverlessは不向きと言えます。
また自動停止こそできますが、RDSやAuroraと違って能動的な再起動を行なうことができないのも特徴です。
調子の悪いデータベースは、とりあえず再起動してどうにかならないか確認する……といった文化があれば、それには合わない仕様と言えます。
加えてこの点があるため、強制的にフェイルオーバーを行なわせるといったこともできません。
さらにAurora ServerlessはAuroraと比べて機能の制約が多いとも言われます。
例えばデータベースエンジンについては、MySQLなら5.6系と5.7系、PostgreSQLなら10系しか使用できません。
加えて、Auroraでは使用可能な以下の機能については、Aurora Serverlessでは使用することができません。
- Aurora Global Database
- Aurora マルチマスタークラスター
- Aurora レプリカ
- IAM データベース認証
- DB クラスターのバックトラック
- データベースアクティビティストリーミングの使用
- Performance Insights
またAurora Serverlessは利用できるリージョンとそうでないリージョンがあります。
そのリージョンでどのデータベースエンジンバージョンが使用できるかの詳細は、以下の公式ドキュメントを参照ください。
そして何より、サーバーレスアーキテクチャとしてAurora Serverlessを利用する場合は特に注意すべき点として、パブリックIPアドレスを持たない為にVPC外からのアクセスが行なえないという点があります。
何故それが重大かと言うと、サーバーレスアーキテクチャのひとつLambdaは、デフォルトの場合はVPC外に配置して使用するものであるからです。
つまりそのままの状態だと、LambdaはAurora Serverlessにアクセスができないということになります。サーバーレス環境を構築する上では、引っかかりやすいポイントのひとつです。
このためAurora Serverlessを使う場合は、以下の図のようにLambda側をVPC内に配置するように設定する必要があります。
これらの特徴から、Aurora Serverlessはリクエストやクエリの発生が断続的となるアプリケーションや、開発環境において試験用として配置するといった用途に向いています。
逆に応答速度の要求がシビアであったり、ピーク時のワークロードが強烈であるといったシステムには不向きであると言わざるを得ません。
さいごに
サーバーレスの名が付いているAurora Serverlessですが、AWSのサーバーレスアーキテクチャと必ずしも相性が良いとは言えません。
サーバーレス環境だからAurora Serverlessを使うのがよい！というのは過去筆者も勘違いしていた点ですが、ユースケースに合わせて通常のAuroraを使うかAurora Serverlessとするかはよく検討すべきでしょう。
というわけで、今回はここまで。
また別の記事でお会いしましょう！
