Amazon Aurora Serverless v1 の使用 - Amazon Aurora
Aurora Serverless v1 の利点Aurora Serverless v1 のユースケースAurora Serverless v1 の制約事項Aurora Serverless v1 での設定の要件Aurora Serverless v1 での TLS/SSL の使用

Amazon Aurora Serverless v1 の使用

Amazon Aurora Serverless v1 (Amazon Aurora のサーバーレスバージョン 1) は、Auto Scaling を Amazon Aurora 用としてオンデマンド化したサービスです。Aurora Serverless DB クラスターでは、クラスターのコンピューティングキャパシティーを、アプリケーションのニーズに対応して増減ささせられます。これは、ユーザーによりキャパシティーが手動で管理される、プロビジョニングされた DB クラスターの Aurora とは対照的です。Aurora Serverless v1 では、頻度が低く、断続的、または予測が困難なワークロードを処理するための、比較的シンプルかつコスト効率の高いオプションが用意されています。このコスト効率が良いのは、アプリケーションの使用状況に合わせて自動的に起動してコンピューティング性能をスケールし、不使用時にはシャットダウンするためです。

料金の詳細については、Amazon Aurora pricing ページで、「MySQL 互換エディション」または「PostgreSQL 互換エディション」の「Serverless の料金」を参照してください。

Aurora Serverless v1 クラスターには、プロビジョンド DB クラスターで使用されているのと同じタイプの、大容量かつ分散型で可用性の高いストレージボリュームが備わっています。Aurora Serverless v1 クラスターでは、クラスターボリュームは常に暗号化されます。暗号化キーは選択できますが、暗号化を無効にすることはできません。つまり、暗号化されたスナップショットに対して実行できる操作と同じ操作を、Aurora Serverless v1 でも実行できるということです。詳細については、Aurora Serverless v1 とスナップショット を参照してください。

トピック

Aurora Serverless v1 の利点

Aurora Serverless v1 では、次のような利点が得られます。

  • プロビジョニングよりもシンプル – Aurora Serverless v1 では、DB インスタンスや容量を管理する上での複雑さがなくなります。

  • スケーラブル – Aurora Serverless v1 は、必要に応じてシームレスにコンピューティング性能とメモリ容量をスケールします。これに伴うクライアント接続の中断はありません。

  • 高いコスト効率 – Aurora Serverless v1 の使用料金は、データベースリソースの秒単位の消費分に対してのみ発生します。

  • 可用性の高いストレージ – Aurora Serverless v1 では、Aurora と同じ 6 ウェイレプリケーションを使用した耐障害性の高い分散型ストレージシステムを使用することで、データを損失から守っています。

Aurora Serverless v1 のユースケース

Aurora Serverless v1 は、以下のユースケース用に設計されています。

  • 利用頻度の低いアプリケーション – 1 日または週に数回、それぞれ数分のみ使用される (低ボリュームのブログサイトなどの) アプリケーション。Aurora Serverless v1 では、消費したデータベースリソース分のみの料金を、秒単位でお支払いいただきます。

  • 新しいアプリケーション – 現在デプロイ中で、必要とされるインスタンスサイズが明確でない、新しいアプリケーション。Aurora Serverless v1 を使用することで、データベースのエンドポイントが作成できます。データベースのキャパシティーは、アプリケーションの要件に応じて自動的にスケーリングされます。

  • 変動するワークロード – 使用時間のピークが 30 分～数時間ほどで、それが 1 日もしくは 1 年に数回発生するような、負荷が重くないアプリケーション。人事管理、予算作成、運営報告用のアプリケーションなどが該当します。Aurora Serverless v1 を導入することで、ピークキャパシティーや平均キャパシティーに合わせてプロビジョニングする必要はなくなります。

  • 予測が困難なワークロード – 毎日実行され、突然、想定し得ないアクティビティの増加が発生するようなワークロード。雨が降り出したときにアクティビティが急増 (サージ) するトラフィックサイトなどが該当します。Aurora Serverless v1 では、アプリケーションのピーク時の負荷要件に合わせて、データベースのキャパシティーが自動スケーリングされ、アクティビティのサージが終了した時点でスケールバックされます。

  • 開発およびテスト中のデータベース – 勤務時間中にデベロッパーにより使用されるものの、夜間や週末には必要とされないデータベース。Aurora Serverless v1 では、使用されていないデータベースは、自動的にシャットダウンされます。

  • マルチテナントアプリケーション – Aurora Serverless v1 を使用することで、フリート内のアプリケーションごとのデータベースキャパシティーを、ユーザーが個別に管理する必要はなくなります。個々のデータベースキャパシティーは、Aurora Serverless v1 により自動的に管理されます。

Aurora Serverless v1 の制約事項

Aurora Serverless v1 には以下の制限が適用されます。

  • Aurora Serverless v1は、特定の AWS リージョン、および Aurora MySQL と Aurora PostgreSQL の特定のバージョンでのみご利用いただけます。詳細については、Aurora Serverless v1 を参照してください。

  • Aurora Serverless v1 では、以下の機能はサポートされていません。

    • Aurora クローン作成

    • Aurora グローバルデータベース

    • Aurora マルチマスタークラスター

    • Aurora レプリカ

    • AWS Identity and Access Management (IAM) データベース認証

    • Aurora でのバックトラック

    • データベースアクティビティストリーム

    • パフォーマンスインサイト

  • 1 日以上開かれたままにされた Aurora Serverless v1 DB クラスターへの接続は、自動的に閉じられます。

  • すべての Aurora Serverless v1 DB クラスターには、次の制限があります。

    • Aurora Serverless v1 スナップショットを Amazon S3 バケットにエクスポートすることはできません。

    • データを Amazon S3 に置かれたテキストファイルに保存することはできません。

    • Aurora Serverless DB クラスターでは、AWS Database Migration Service および変更データキャプチャ (CDC) を使用することはできません。プロビジョニングされた Aurora DB クラスターのみがソースとしての AWS DMS と CDC をサポートします。

    • テキストファイルデータを、Aurora MySQL Serverless から Amazon S3 にロードすることはできません。ただし、aws_s3.table_import_from_s3 関数で credentials パラメータを指定しながら aws_s3 拡張機能を使用すれば、Aurora PostgreSQL Serverless から Amazon S3 へのデータのロードが可能です。詳細については、「Amazon S3 データを Aurora PostgreSQL DB クラスターにインポートする」を参照してください。

  • Aurora Serverless v1 が実行されている Aurora MySQL– ベースの DB クラスターでは、以下はサポートされません。

    • Aurora MySQL DB クラスター内からの AWS Lambda 関数の呼び出し。ただし、AWS Lambda 関数は Aurora MySQL Serverless DB クラスターを呼び出すことができます。

    • Aurora MySQL もしくは RDS for MySQL ではない DB インスタンスからのスナップショットの復元。

    • バイナリログ (binlog) に基づくレプリケーションを使用したデータのレプリケート。この制限は、Aurora MySQL ベースの Aurora Serverless v1 DB クラスター が、レプリケーションのソースであるか、ターゲットであるかに関係なく当てはまります。Amazon EC2 で実行されているインスタンスなど、Aurora の外部の MySQL DB インスタンスから Aurora Serverless v1 DB クラスターにデータをレプリケートする場合は、AWS Database Migration Service が使用できます。詳細については、「AWS Database Migration Service ユーザーガイド」を参照してください。

  • Aurora Serverless v1 を実行している Aurora PostgreSQL– ベースの DBクラスターには、次の制限があります。

    • Aurora PostgreSQL クエリプラン管理 (apg_plan_management 拡張機能) はサポートされていません。

    • Amazon RDS PostgreSQL と Aurora PostgreSQL で使用できる論理レプリケーション機能は、サポートされていません。

    • PostgreSQL 拡張機能で、Amazon RDS により使用が可能となっているタイプのアウトバウンド通信は、サポートされていません。たとえば、postgres_fdw/dblink 拡張機能を使用して外部データにアクセスすることはできません。RDS PostgreSQL 拡張機能の詳細については、RDS ユーザーガイドの、「Amazon RDS 上の PostgreSQL」を参照してください。

    • 現在、一部の SQL クエリとコマンドの使用が推奨されていません。これには、セッションレベルのアドバイザリロック、テンポラリリレーション、非同期通知 (LISTEN)、および WITH HOLD (DECLARE name ... CURSOR WITH HOLD FOR query) が指定されたカーソルが含まれます。また、NOTIFY コマンドはスケーリングを阻害するため、推奨されません。

      詳細については、「Aurora Serverless v1 の自動スケーリング」を参照してください。

  • Aurora Serverless v1 DB クラスターの優先バックアップウィンドウを設定することはできません。

Aurora Serverless v1 での設定の要件

Aurora Serverless v1 DB クラスターを作成する際には、次の要件に注意してください。

  • DB エンジンごとに、次に挙げる特定のポート番号を使用します。

    • Aurora MySQL – 3306

    • Aurora PostgreSQL – 5432

  • Virtual Private Cloud (VPC) に置かれる Aurora Serverless v1 DB クラスターは、Amazon VPC サービスに基づいて作成します。VPC で Aurora Serverless v1 DB クラスターを作成すると、50 個のインターフェイスエンドポイントとゲートウェイロードバランサーエンドポイントの 2 つを VPC に割り当て、その 2 つを使用します。これらのエンドポイントは自動的に作成されます。クォータを増やすには、AWS Support にご連絡ください。詳細については、Amazon VPC クォータを参照してください。

  • Aurora Serverless v1 DB クラスターにパブリック IP アドレスを割り当てることはできません。VPC 内からのみ、Aurora Serverless v1DB クラスターへのアクセスが可能です。

  • Aurora Serverless v1 DB クラスターで使用する DB サブネットグループでは、異なるアベイラビリティーゾーンごとにサブネットを作成します。つまり、同じアベイラビリティーゾーンに複数のサブネットを持つことはできません。

  • Aurora Serverless v1 DB クラスターで使用されるサブネットグループに対する変更は、クラスターには適用されません。

  • Aurora Serverless v1 DB クラスターには AWS Lambda からアクセスできます。このアクセスのためには、Aurora Serverless v1 DB クラスターと同じ VPC で実行されるように、Lambda 関数を設定する必要があります。AWS Lambda の使用の詳細については、AWS Lambda デベロッパーガイドの「VPC 内のリソースにアクセスするための Lambda 関数の設定」を参照してください。

Aurora Serverless v1 での TLS/SSL の使用

Aurora Serverless v1 では、クライアントと Aurora Serverless v1 DB クラスター間の通信に対し、トランスポート層セキュリティ/セキュアソケットレイヤー (TLS/SSL) プロトコルを使用した暗号化が、デフォルトで使用されます。サポートされる TLS/SSL バージョンは、1.0、1.1、および 1.2 です。TLS/SSL を使用するために、Aurora Serverless v1 DB クラスターを設定する必要はありません。

ただし、次のような制限があります。

  • Aurora Serverless v1 DB クラスターに対する TLS/SSL サポートは、現在、中国 (北京) の AWS リージョンではご利用いただけません。

  • Aurora MySQL– ベースの Aurora Serverless v1 DB クラスターのデータベースでユーザーを作成する際は、SSL アクセス許可に REQUIRE 句を使用しないでください。これを使用すると、ユーザーが Aurora DB インスタンスに接続できなくなります。

  • MySQL クライアントと PostgreSQL クライアントのユーティリティの両方に関して (クライアントと Aurora Serverless v1 の間で TLS/SSL を使用している場合に)、他の環境では使用できるセッション変数の中で機能しないものが存在します。

  • 現在、MySQL クライアントが TLS/SSL の VERIFY_IDENTITY モードを使用して接続する場合は、MySQL 8.0 互換の mysql コマンドを使用する必要があります。詳細については、「MySQL データベースエンジンを実行している DB インスタンスへの接続」を参照してください。

Aurora Serverless v1 DB クラスターに接続するクライアントによっては、暗号化された接続を確立するために、TLS/SSL を指定する必要がない場合があります。たとえば、PostgreSQL クライアントを使用して、Aurora PostgreSQL-Compatible Edition を実行中の Aurora Serverless v1 DB クラスターに接続する際は、通常どおりの接続が可能です。 

psql -h endpoint -U user

パスワードを入力すると、PostgreSQL クライアントにより、TLS/SSL のバージョンと暗号を含む接続の詳細が表示されます。

psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help.
重要

Aurora Serverless v1 は、クライアントアプリケーションによって SSL/TLS が無効になっていない限り、デフォルトで Transport Layer Security/Secure Sockets Layer (TLS/SSL) プロトコルを使用して接続を暗号化します。TLS/SSL 接続はルーターフリートで終了します。ルーターフリートと Aurora Serverless v1 DB クラスター間の通信は、サービスの内部ネットワーク境界内で行われます。

クライアント接続のステータスを確認して、Aurora Serverless v1 への接続が TLS/SSL 暗号化されているかどうかを調べることができます。PostgreSQL pg_stat_ssl と pg_stat_activity テーブル、およびその ssl_is_used 関数は、クライアントアプリケーションと Aurora Serverless v1 間の通信の TLS/SSL 状態を表示しません。同様に、TLS/SSL 状態は MySQL status ステートメントから派生できません。

PostgreSQL の Aurora クラスターパラメータ force_ssl および MySQL の require_secure_transport は Aurora Serverless v1 ではサポートされていません。Aurora Serverless v1 でサポートされているパラメータの完全なリストについては、DescribeEngineDefaultClusterParameters API を呼び出してください。パラメータグループと Aurora Serverless v1 の詳細については、パラメータグループと Aurora Serverless v1 を参照してください。

MySQL クライアントを使用して Aurora MySQL-Compatible Edition を実行中の Aurora Serverless v1 DB クラスターに接続するには、リクエスト内で TLS/SSL を指定します。次の例には、Amazon Trust Services からダウンロードされた Amazon ルート CA 1 信頼ストアが含まれています。この信頼ストアは、この接続を正常に実行するために必要です。 

mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED

プロンプトが表示されたら、パスワードを入力します。すぐに MySQL モニタが開きます。status コマンドを使用すると、セッションが暗号化されていることを確認できます。 

mysql> status -------------- mysql Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1 Connection id: 19 Current database: Current user: ***@******* SSL: Cipher in use is ECDHE-RSA-AES256-SHA ...

MySQL クライアントを使用しての Aurora MySQL データベースへの接続の詳細については、「MySQL データベースエンジンを実行している DB インスタンスへの接続」を参照してください。

Aurora Serverless v1 では、MySQL クライアント (mysql) および PostgreSQL クライアント (psql) で使用できるすべての TLS/SSL モードがサポートされます。これらには、次の表に示すものも含まれます。

TLS/SSL モードの説明 mysql psql

TLS/SSL を使用せずに接続します。

DISABLED

無効化

最初に TLS/SSL を使用して接続を試みますが、必要に応じて非 SSL にフォールバックします。

PREFERRED

優先 (デフォルト)

強制的に TLS/SSL を使用します。

REQUIRED

require

TLS/SSL を強制的に使用し CA を確認します。

VERIFY_CA

verify-ca

TLS/SSL を強制的に使用し CA を確認し、また CA ホスト名を確認します。

VERIFY_IDENTITY

verify-full

Aurora Serverless v1 は、ワイルドカード証明書を使用します。TLS/SSL を使用するときに "verify CA" または "verify CA and CA hostname" オプションを指定した場合は、まず Amazon ルート CA 1 信頼ストアを Amazon Trust Services からダウンロードしてください。ダウンロードした、この PEM 形式のファイルは、クライアントコマンドにより識別できます。PostgreSQL クライアントを使用してこれを行う場合:

Linux、macOS、Unix の場合:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Postgres クライアントを使用した Aurora PostgreSQL データベースの操作の詳細については、「PostgreSQL データベースエンジンを実行する DB インスタンスへの接続」を参照してください。

Aurora DB クラスターへの接続全般の詳細については、「Amazon Aurora DB クラスターへの接続」を参照してください。