[レポート] スケーラブルでコスト効率が良いAurora Serverlessをデプロイする #reinvent [DAT382]

本記事は現地時間2019/12/2-6で行われてたre:Invent 2019のセッション「Aurora Serverless: Scalable, cost-effective application deployment」のレポートとなります。

セッション情報

概要

Amazon Aurora Serverless is an on-demand, automatic scaling configuration for Aurora where the database automatically starts up, shuts down, and scales capacity up or down based on your application’s needs. It enables you to run your database in the cloud without managing any database instances. Aurora Serverless is a simple, cost-effective option for infrequent, intermittent, or unpredictable workloads. In this session, we explore these use cases, take a look under the hood, and delve into the future of serverless databases.

Amazon Aurora Serverlessは、データベースが自動的に起動、シャットダウン、およびアプリケーションのニーズに基づいて容量を増減する、Auroraのオンデマンドの自動スケーリング設定です。データベースインスタンスを管理せずに、クラウドでデータベースを実行できます。 Aurora Serverlessは、まれな、断続的な、または予測不可能なワークロード向けのシンプルで費用対効果の高いオプションです。このセッションでは、これらのユースケースを調査し、内部を見て、サーバーレスデータベースの将来を掘り下げます。 ※Google Translateの日本語訳

動画

本レポートは冒頭の約20分をカバーし、後半のデモや Q&A はスキップしています。

また、本レポートの画像はすべて YouTube からの加工です。

スピーカー

• Sandor Maurice - Senior Engineering Manager, Amazon Web Services
• Kathy Gibbs - Sr Specialist Solution Architect, Databases, Amazon Web Services

アジェンダ

• Amazon RDS とAmazon Auroraの基本
• Amazon Aurora Serverless について
• 動作原理
• その他
• デモ

Amazon RDS について

• 管理が容易
• パフォーマンスやスケーラビリティに優れている
• 可用性・対障害性
• セキュリティ・コンプライアンス準拠

といったことを DBA なしに実現するために、 Amazon RDS を開発した。

その後、Amazon 謹製でクラウドネイティヴなデータベースを作りたくなり、Amazon Aurora を開発。

Amazon Aurora は 商用データベースと同等の機能を備えながら、価格体系が明瞭で安い

Amazon Aurora の革新的なストレージについて

Aurora の革新的なことの一つはストレージレイヤーをデータベース・サーバーから分離したこと

• 分散・マルチテナントなストレージレイヤーが備わっている
• ストレージのプロビジョニングや冗長化は不要
• 10 GB ごとに大量のストレージノードにストライプさせる
• 各書き込みは6個のストレージノードに並行して書き込まれ、4/6に書き込まれれば、成功とみなされる
• ストレージはイラスティックで、いくらでもスケールする

Aurora のストレージレイヤーはどのように動作するのか

• 書き込みには 4/6 クォーラム
• 読み取りには 3/6 クォーラム

Aurora は 3 AZ を利用し、各AZには2ノードある。1 AZ(=2ノード) で障害が起こり、更に1ノードで障害があっても、3ノードは生きているため、読み取りできる。

Aurora Serverless がどうして必要なのか?

Auroraのストレージレイヤーはイラスティックなのに、コンピューティング性能はイラスティックではない。 そのため、性能不足に陥る事がある。

ストレージだけでなく、コンピューティングもイラスティックにしたのが Aurora Serverless

Aurora Serverless では ワークロードに応じたスケールアップ・ダウン、利用していないときはスリープ、利用を再開するとインスタンスを起動といったことが自動で行われる。

データベースのワークロードは一定ではない

開発環境ではアイドル状態となっている時間が多かったり、本番環境では時間帯によってワークロードが大きく変動したりと、ワークロードは一定ではない。

データベース・サーバーのサイジングは難しい

• ピークにあわせると、リソースの無駄が多く、サーバー費が高価になる
• ピークより低い性能にあわせると、ピーク時に容量不足に陥る
• メトリクスに連動して容量をスケーリングさせるのは、運用が難しい

Aurora の 容量を管理するシナリオ

Amazon Aurora を運用しているとします。

高負荷時にサーバーをスケールアップしたい場合、ナイーブな実装としては、次のようにできます。

1. 高負荷時により容量の大きいレプリカを追加
2. 切替

ただし、この方式は以下のような課題があります。

• 切り替え時にダウンタイムが発生
• 切り替え直後の新しいインスタンスはバッファープール・キャッシュがコールド状態

Aurora の 容量を管理するシナリオ(プロキシ版)

カットオーバー時のダウンタイムを軽減するために、DBリクエストの処理にプロキシサーバーを導入すると、カットオーバー時のルーティングは確かにスムーズになります。

ただし、切り替え先の新しいインスタンスのバッファープール・キャッシュがコールド状態という課題は依然として解決されず、プロキシサーバーが SPOF という新しい課題も発生します。

Aurora Serverless の登場

これらの課題を解決するために生まれたのが Aurora Serverless です。

以下のような特徴があります。

• プロキシレイヤー
  • リクエストをルーティング
  • 高分散、マルチテナントのため SPOF とならない
• データベースインスタンスのプールがある
  • インスタンスはウォーム状態
  • 必要なタイミングですぐに利用できる

Aurora Serverless はどのように動作?

3システムで構成されます。

• プロキシレイヤー
  • 複数のノードで構成
  • クライアントは接続先ノードを意識しない
  • ノード障害が起こると、クライアントの接続は切られるが、すぐに別ノードに再接続される
• 監視サービス
  • CPU・メモリ・ストレージを定期監視
• Aurora インスタンスのプール
  • 各インスタンスはウォーム状態
  • すぐに利用できる

オートスケールの流れ

Aurora Serverless のオートスケールの流れを追います

1. 監視サービスが利用状況(CPU、メモリー、ストレージ)を監視
2. しきい値を超えてスケールアップ・ダウンが必要と判断

1. ウォームプールからレプリケーションサーバーを調達
2. インスタンスをウォームアップ
3. バッファープール、キャッシュをセカンダリー(新)データベース・サーバーにコピー
4. アクティブなトランザクションがないSafe Scale Pointを待つ

重い処理が走っていると、Safe Scale Point を見つけられずにスケールアウトできないごとにご注意ください。

1. ワークロードをフリーズ(数秒以下で、多くの場合は１秒以下)
2. セッション状態をセカンダリー(新)データベース・サーバーにコピー

1. リクエストをセカンダリーに切り替え
2. ワークロードの処理を再開

Aurora Serverless スケーリングの影響

• クライアントサイドでは、データベースとの接続障害はない
• データベース・サーバーでレイテンシーの小さなスパイクがあるだけ

よりシンプルなサーバー管理

• 接続先データベース・サーバー
• インスタンスのサイズ
• CPUクレジット
• データベース・サーバーが動作してるAZ

といったことを意識しない。

Aurora Serverless の実際のオートスケーリングを確認

青色のワークロード(tps)と黄色の容量(ACU)のグラフ

tps(transaction per second)) に応じて ACU も増えるため、より大きな tps に対応できる

青色のレイテンシーと黄色のサーバー容量（ACU)のグラフ

容量不足でレイテンシーが一時的に増えても、ACU のスケールアップによって、レイテンシーは安定する

青色のワークロード(tps)と黄色のレイテンシーのグラフ

サーバー容量を固定すると、ワークロードの増加でレイテンシーも増える

Aurora Serverlessを利用すると、ワークロードに応じてサーバー容量がスケーリングするため、レイテンシーが安定

RDS と サーバーレスアプリケーションは相性が悪い

• コネクションの管理
• ネットワーク設定
• 認証管理
• 重厚な JDBC/ODBC は嫌

Amazon RDS Data APIの登場

Amazon RDS Data API を利用すると、これらの課題が解決される

• クライアントはエンドポイントに IAM で認証して HTTP 通信するだけ
• エンドポイントとデータベース間では、Secrets Manager を利用したDB認証やコネクションプールが裏で行われる

補足

Aurora Serverless の Data API に相当する機能は、従来の Provisioned Aurora 向けには Amazon RDS Proxy として提供されています。

本セッションと同じ re:invent 2019 中に発表され、現在はプレビューです。

まとめ

Amazon RDS を出発点に、ストレージとコンピューティングの分離、ストレージのelasticity(Aurora)、コンピューティングのelasticity(Aurora Serverless)、DB リクエストの分離(Data API)と、マイクロサービス化の流れがよく分かるセッションでした。