Amazon Aurora serverless を知らなかった人が 2019/07 現在の Aurora serverless の最新状況を分かる範囲でまとめた

これの続編

blog.kasei-san.com

Amazon Aurora serverless って何?

インスタンスの管理が不要な Amazon Aurora

決して、serverless 専用の Aurora ではない

サポートしているエンジンは?

  • MySQL 5.6 互換の Amazon Aurora
  • PostgreSQL 10.7+ 互換の Amazon Aurora

Aurora と何が違うの?

  • シンプル
  • スケーラブル
  • 高コスト効率

シンプル

インスタンスの管理が不要なため、Auroraよりも更に運用コストが低下している

スケーラブル

  • 負荷に応じて、自動スケール & (設定によっては)自動停止する
  • Aurora Capacity Unit (ACU) という単位で課金される
    • 最低2、最大384
    • 0.1$/1ACU時間

高コスト効率

上記のスケーラブルのために、負荷が不安定だったり、決められた時間にしか使用しないサーバなどはAmazon Aurora serverlessでコストダウンできる

Amazon Aurora serverless が向いているサービス

  • 社内用のシステムなど、8-17以外の時間は停止しているサービス
  • バッチシステムのように、決められた時間以外は停止しているサービス
  • 開発/ステージング環境

Amazon Aurora serverless で注意すべきこと

  • 停止状態から再開するまでは1分程度掛かる
  • スケール時にはバッファプールがリセットされるため、再応答まで30秒程度掛かる
    • そのため、本番運用中にスケールするのはあまりよろしくない
  • Auroraの一部機能がサポートされていない
    • Amazon S3 バケットからのデータの読み込み
    • Aurora MySQL ネイティブ関数での AWS Lambda 関数の呼び出し
    • 高度な監査
    • Aurora レプリカ
    • バックトラック
    • データベースのクローン化
    • IAM データベース認証
    • クロスリージョンリードレプリカ
    • MySQL DB インスタンスからのスナップショットの復元
    • Amazon S3 からのバックアップファイルの移行
    • Amazon RDS パフォーマンスインサイト
  • リードレプリカが無いので、readだけやたら多いサービスの場合、むしろコスト効率が悪くなる?(要調査

参考リンク

dev.classmethod.jp

👆初回接続に22秒かかることを確認している

dev.classmethod.jp

👆ACU毎の最大コネクション数の調査

www.publickey1.jp

👆「スケールアップまたはスケールダウンは数秒で行われる一方、最初のインスタンスへの接続は25秒前後のレイテンシがあると説明されています」

qiita.com

👆一時停止→復帰、スケールが生じるとバッファプール(バッファキャッシュ)が初期化されるとのこと

感想

24/365で高負荷なサービスで運用するのには難しそう

ユースケースにあるとおり、低頻度利用環境向けのサービスと見るのが良さそう