振り返りシリーズ
- セッション 01: エージェント向けアーキテクチャ設計への開発者ロードマップ
- セッション 02: Amazon Bedrock Data Automation
- セッション 03: AgentCore 上のマルチエージェント
- セッション 04: Nova Act と Strands Agents を実践で活用したエージェント型 AI の構築
- セッション 04: 仕様駆動開発と Kiro で移行プロジェクトを加速
- セッション 06: 「マッチング」から「理解」へ: AgentCore Memory が実現するパーソナライズド AI 検索の実践
- セッション 07: 観測から最適化へ – LLM オブザーバビリティから AIOps へ、リアルタイムの洞察をインテリジェントな自動化に変える
- セッション 08: TEAM の導入と最高のエンジニアリングチームの構築
- セッション 09: いわゆるサーバーレスデータベースの5年間から得た5つの厳しい教訓
- セッション 14: AI が私の仕事をしたらどうなるか Q Developer CLI と Kiro が私の日常業務をどう変えたか
- セッション 16: 警戒を保ちながら迅速に:Amazon Bedrock エージェント開発に不可欠なセキュリティ
- セッション 26: 1 台の H100 で OSS LLM をよりスマートに、低コストで、高速に実行
- セッション 28: 最新の統合メタデータアーキテクチャ:データサイロを解消する新たなアプローチ
- セッション 29: サーバーレス MediaOps:Amazon Web Services 上の AI による動画ワークフローの自動化
- セッション 30: 大規模パフォーマンステストによる効率性と信頼性を重視したアーキテクチャ設計
- セッション 31: オープンソースで世界をつなぐ: テクノロジー、コミュニティ、グローバルな開発者関係をめぐる実践の旅
- セッション 33: リアルタイム物流分析のためのストリーミング Iceberg テーブルの構築
- セッション 34: 大規模ロボット戦略トレーニングの高速化: Kiro、Trainium、EKS に基づく自動クローズドループアーキテクチャ
- セッション 35: 仕様駆動開発で「Vibe」から実用レベルへ
- セッション 36: クラウドコスト分析をよりスマートに: StrandsとAgentCoreによるFinOpsインテリジェントエージェントの構築
- セッション 37: CNCF Kagent、K8sGPT、Nova Sonicを使用したK8s向け対話型エージェントAIOpsの変革
セッションノート
いわゆるサーバーレスデータベースの5年間から得た5つの厳しい教訓
- サーバーレスはサーバーレスではない。あるいはその逆か? Amazon Web Services におけるサーバーレスデータベースの登場
- Aurora Serverless v1 GA (2018-08)
- DynamoDB On-Demand (2018-11)
- Amazon Timestream (2020-09)
- Aurora Serverless v2 Preview (2020-12)
- Aurora Serverless v2 GA (2022-04)
- Redshift Serverless (2022-07)
- Amazon Neptune Serverless (2022-10)
- ElastiCache Serverless (2023-11)
- Amazon DSQL (2025-05)
- DocumentDB Serverless (2025-07) では、これは...
- Amazon S3
- Amazon SQS
- Amazon Route 53?
ストレージは過小評価されている
- Aurora Serverless v2 は即座にスケールして、最も要求の厳しいアプリケーションにも対応し、ピークキャパシティに合わせてプロビジョニングする場合と比べて最大 90% のコスト削減を実現
- USD/月
- 2022: 3336 CPU (RI), 1960 ストレージ (GP), 2274 バックアップ
- 2023: 4682 CPU (RI), 2387 ストレージ (GP), 3300 バックアップ
- 2024: 6006 CPU (RI), 2994 ストレージ (GP), 5840 バックアップ
- 2025: 6350 CPU (RI), 3755 ストレージ (GP), 6952 バックアップ
- Aurora Serverless: 最小 0.5 ACU
- Aurora Provisioned: db.r8g.large
- RDS for MySQL: 400 GB + db.r8g.large どれくらいかかる?
- Aurora Serverless: 3-4 秒
- Aurora Provisioned: 2-3 秒
- RDS for MySQL: 4-5 分
コスト予測はより困難
- 「サーバーレス DB 上でワークロードがどのように動作するか分からないなら、プロビジョンドクラスターのベースラインを使って ACU を予測してもまったく役に立たない。」
- 「Aurora DSQL がついに一般提供になった。料金はいくらか?誰にも分からない。特に Amazon Web Services には。DPU 単位で課金されるが、ドキュメントの説明は『知るか。自分のワークロードでベンチマークして自分で確かめろ』というに等しい。選べるあらゆる料金戦略の中から、Amazon Web Services が『完全に諦める』を選ぶとは思わなかった。私の Aurora 顧客は... 不満を抱いている。」 Corey Quinn
互換性が課題になる可能性
- 互換性?
- ワイヤー(またはクライアントプロトコル)
- SQL / クエリ言語
- 機能 / 動作
- 運用 / エコシステム
- バージョン
- DSQL, Dynamo DB, Aurora Serverless (*)
- どちらも「サーバーレス」データベース
- 問題は水平か垂直か
- 弾力性はサーバーレスではない
- 「データベースが設定された最小キャパシティまで依然としてスケールダウンしない場合は、時間の経過とともに蓄積した可能性のあるメモリフラグメントを解放するため、データベースを停止して再起動してください。データベースを停止して起動するとダウンタイムが発生するため、これを行うのは最小限にすることをお勧めします。」(Amazon Web Services ドキュメント)
- サーバーレスデータベースを活用し、弾力性に取り組み、内部で何が動いているかを理解する
