Amazon Web Services ブログ
Aurora Serverless MySQL の一般利用が開始
クラウド向けに考案、構築され、MySQL や PostgreSQL と互換性のあるカスタムビルドのデータベース、Amazon Aurora については、すでにご存知の方も多かと思われます。また、インスタンスのことを考慮することなくアプリケーションおよびサービスを構築、実行できるサーバーレスをご存知の方も多いかと思われます。この 2 つのサービスは、成長を続ける AWS テクノロジーの一端を担うサービスであり、私たちはこのサービスに積極的に取り組んでいます。昨年の AWS re:Invent では、Aurora Serverless と呼ばれる Aurora の新機能のプレビューが発表されました。本日、Aurora MySQL 向け Aurora Serverless の一般利用が可能になったことをお知らせいたします。Aurora Serverless は自動スケーリングが可能な、オンデマンドベースのサーバーレスの Aurora とお考えください。インスタンスやスケーリングのことを考える必要はなく、従量制に基づいて支払うだけです。
この方式は、予期しない負荷が発生したり、需要が頻繁に発生しないアプリケーションに最適です。これから、Aurora Serverless どのように動作するか説明いたします。それでは、サーバーレスクラスターの起動方法から始めましょう。
Aurora Serverless クラスターの作成
まず、Amazon Relational Database Service (RDS) コンソールに移動し、[クラスター] サブコンソールを選択します。次に、右上隅の [データベースの作成] ボタンをクリックして以下の画面に移動します。
上の画面から、使用するエンジンタイプを選択し、[次へ] をクリックします。今は、Aurora MySQL 5.6 だけがサポートされています。
ここからがおもしろいところです。キャパシティータイプで [Serverless] を選択すると、インスタンスのすべての選択と設定オプションが非表示になります。やるべきことは、クラスターに名前を付け、マスターユーザーの名前とパスワードの組み合わせを入力し、[次へ] をクリックすることだけです。
ここから、多数のオプションを選択できます。使用される Aurora Compute Units (ACU) の上限および下限を指定できます。ACU に対する請求は秒単位で行われ、5 分から請求が開始されます。クラスターは、指定された ACU の下限と上限の間でオートスケールします。オートスケーリングのルールおよびメトリクスは Aurora Serverless によって自動作成され、CPU 使用率および接続数が考慮されます。Aurora Serverless がクラスターに追加キャパシティーが必要であることを認識すると、その必要性に応じてリソースのワームプールからキャパシティーを取得します。新たに追加されたキャパシティーはトラフィックのサービスを数秒で開始します。これは、Aurora の設計上、コンピューティングレイヤーとストレージレイヤーが分かれているためです。
クラスターでアクティビティがない場合は、クラスターは自動的にゼロにスケールダウンします。この挙動は、長期にわたってほとんど動かない、またはまったく動かないことがある開発データベースには最適です。クラスターが停止している間は、それを格納しているストレージに対して課金されるだけです。手動でスケールアップまたはスケールダウンしたり、トラフィックの急上昇に備えたりする場合は、1 回の API コールだけで済みます。
最後に、右下の [Create database] をクリックして、クラスターが使用可能になるのを待ちます。あっという間に終わります。サポートされているクラスターのパラメータ数は現時点では限られていますが、カスタマーフィードバックで繰り返し申し上げているとおり、今後さらにカスタマイズオプションを追加していく予定です。
これで、他の RDS データベースと同様に、コンソールでさまざまなデータが表示されるようになりました。
ここから、他の MySQL データベースと同様に、自分のクラスターに接続できます。また、 sysbench または mysqlslap のようなツールを実行して、負荷を生成したり、スケーリングイベントをトリガーしたりできます。または、このサービスがスケールダウンしたり、停止したりするのを待つこともできます。
下にスクロールするか、イベントサブコンソールを選択すると、ある時点でインスタンスの一時停止など、さまざまなオートスケーリングイベントが発生していることがわかります。
これにおける最も良いことは何でしょうか。それは、ブログ記事を書き終えた後、このサーバーをシャットダウンするのを忘れないようにする必要がないということです。また使いたくなったら、接続をリクエストするだけで、クラスターの起動が数秒で始まります。
Aurora Serverless の機能
この機能が有効になるその裏で、何が起こっているかもう少し掘り下げてみましょう。Aurora Serverless データベースをプロビジョニングするときに、このサービスは次のことを行います。
|
 |
クラスターがオートスケールアップまたはダウンする、再開または停止する必要がある場合は、Aurora は即時利用可能なノードプールからキャパシティー取得し、リクエストルーターに追加します。このプロセスには時間をほとんど要しません。ストレージはノード相互間で共有されるため、Aurora はほとんどの負荷に対して数秒でスケールアップまたはスケールダウンできます。本サービスのオートスケーリングのクールダウン期間は現在、スケールアップでは 1.5 分、スケールダウンでは 5 分となっています。スケーリング操作は既存の接続やセッションの状態が新しいノードに移行されるため、接続されたクライアントおよびアプリケーションに対しては透過的です。停止と再開の唯一の違いは、通常 25 秒前後という最初の接続の高いレイテンシーにあります。
今すぐ利用可能
Aurora MySQL 向け Aurora Serverless は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド) で利用可能です。Aurora エンジンについてもっと知りたい皆さんのために、設計文書が公開されています。Aurora Serverless の機能のすべてを詳しく知りたい場合は、記事の続報に期待してください。
Aurora Serverless は、データベースの進化における最も興味深いポイントであると私は信じています。お客様は Aurora Serverless 何を構築するでしょうか。それが楽しみでなりません。
– こちらです。
———————————-
みなさん、こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。提供が開始となったAurora Serverlessですが、すでに東京リージョンでも対応がされていますので是非皆さんお試しください。Aurora Serverlessはインスタンスやクラスターに従来と異なる考え方が導入されており、その後利用にはまずこちらのドキュメントをご確認ください。
ユースケースは主に、不定期使用のアプリケーション、新規アプリケーション、可変ワークロード、予測不能なワークロード、開発およびテスト用のデータベース、マルチテナントのアプリケーション、などそのパフォーマンスがあらかじめ予測がしづらい、かつ一定ではないワークロードを想定しています。
またサービス利用上の主な制限を以下にまとめます。
- MySQL 5.6 互換の Aurora のみ対応
- 接続ポートは3306で固定
- Aurora サーバーレス DB クラスターにパブリック IP アドレスを割り当てることはできず、VPC 内からのみアクセス
- クラスターのエンドポイントには、AWS VPN 接続やリージョン間 VPC ピアリング接続を介してはアクセスできない。リージョン間 VPC ピアリング接続を介したクラスターのエンドポイントへのアクセスには制限が存在。
- 以下のクラスターレベルのパラメータのみ変更可能。
- character_set_server
- collation_server
- lc_time_names
- lower_case_table_names
- time_zone
- Auroraに存在している以下の機能は未サポート
- Amazon S3 バケットからのデータの読み込み
- Aurora MySQL ネイティブ関数での AWS Lambda 関数の呼び出し
- 高度な監査
- Aurora レプリカ
- バックトラック
- データベースのクローン化
- IAM データベース認証
- クロスリージョンリードレプリカ
- MySQL DB インスタンスからのスナップショットの復元
- Amazon S3 からのバックアップファイルの移行
- Secure Sockets Layer (SSL) による DB クラスターへの接続
詳しくは、こちらのドキュメントをご参考ください。