これの続編
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だけやたら多いサービスの場合、むしろコスト効率が悪くなる?(要調査
参考リンク
👆初回接続に22秒かかることを確認している
👆ACU毎の最大コネクション数の調査
👆「スケールアップまたはスケールダウンは数秒で行われる一方、最初のインスタンスへの接続は25秒前後のレイテンシがあると説明されています」
👆一時停止→復帰、スケールが生じるとバッファプール（バッファキャッシュ）が初期化されるとのこと
感想
24/365で高負荷なサービスで運用するのには難しそう
ユースケースにあるとおり、低頻度利用環境向けのサービスと見るのが良さそう
