今こそ押さえておきたい アマゾンウェブサービス（AWS）の データベースの基礎 おもクラ #6版

Transcript

1. 今こそ押さえておきたい アマゾンウェブサービス（AWS）の データベースの基礎 2026.03.26 SATOSHI KANEYASU
2. 2 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス部 ※課長になりました 在住：広島（フルリモート） 担当：DevOps、技術支援、PM、SM SNS(X)：@satoshi256kbyte • 2025 AWS Community Builders • 2025 Japan AWS Top Engineers (AI/ML Data Engineer) • 2025 Japan AWS All Certifications Engineers • 認定スクラムマスター • PMP Speaker Introduction
3. 1. Database Savings Plansとは 2. AWSのデータベースの種類 3. データベースの使い分け 4. オンプレミスのデータベースをAWSに移行した場合の注意点 5. 直近で発表されたデータベース系のアップデートについて 目次
4. Database Savings Plansとは このページ以降、Database SPと記載します
5. 5 DBサービス群を対象とした柔軟な料金プラン ⚫ Database Savings Plansはデータベースサービス群を対象とした料金プラン ⚫ 1年期間で一定の使用量にコミットする場合に、最大35%の削減が適用 ⚫ アマゾンウェブサービス（AWS）のデータベースの費用を抑える方法として、 Reserved Instance（RI）がありますが、それとの違いは「柔軟性」 ⚫ ＜特徴＞  リージョンを跨いでも適用される  データベースエンジンを変更しても適用される  データベースサービス（Amazon RDSからAmazon DynamoDBなど）を変更しても適用される  割引率は、RIには劣る
6. 6 対象となるデータベースサービス ⚫ Amazon RDS/Aurora/Aurora Serverless v2 ⚫ Amazon Aurora DSQL ⚫ Amazon DynamoDB ⚫ Amazon ElastiCache for Valkey（インスタンス、Serverless） ⚫ Amazon DocumentDB（インスタンス、Serverless） ⚫ Amazon Neptune（インスタンス、Serverless） ⚫ Amazon Keyspaces ⚫ Amazon Timestream ⚫ Amazon OpenSearch Service ⚫ AWS Database Migration Service （インスタンス、Serverless）
7. 7 Savings Plan 購入アナライザー ⚫ AWSマネジメントコンソール  Billing and Cost Management（請求とコスト管理）
8. 8 一定の使用量にコミットするとは？ 購入アナライザーの画面 Saving Plansの購入画面 ⚫ 入力したコミットメントにより割引率が決定 ⚫ コミットメントを超える使用量については、オンデマンド料金となる ➢ 参考：Database Savings Plans 次頁から次の章に移ります
9. AWSのデータベースの種類
10. 10 AWSのデータベースの種類 ➢ 参考：AWS クラウドのデータベース 種類 使用例 データベースサービス Database SP対象 リレーショナル 基幹システム、ECサイト（頻繁な書き込み・読み込み） Amazon Aurora ◦ Amazon RDS ◦ データウェアハウス 大規模分析、BIツール連携（数億件の集計処理） Amazon Redshift Key-Value 高トラフィックのWEBアプリケーション Amazon DynamoDB ◦ インメモリ キャッシュ、セッション管理 Amazon ElastiCache ◦ Amazon MemoryDB ドキュメント コンテンツ管理、カタログ、ユーザープロファイル Amazon DocumentDB （MongoDB互換） ◦ グラフ 不正検出、ソーシャルネットワーキング、レコメンデーションエンジン Amazon Neptune ◦ ワイドカラム 高スケールの業界アプリケーション、設備のメンテナンス Amazon Keyspaces ◦ 時系列 (IoT) アプリケーション、産業用テレメトリ Amazon Timestream ◦ 検索・分析 全文検索、ログ分析、ベクトル検索（AI連携） Amazon OpenSearch Service ◦ 分散データベース グローバルかつ高可用性を要するアプリケーション Amazon Aurora DSQL ◦
11. 11 リレーショナル - Amazon AuroraとAmazon RDS ⚫ オンプレミスで構築したDBに使用感が近いのはAmazon RDS ⚫ Amazon AuroraはAmazon RDSに比べてスループットと可用性に優れる ⚫ スループットに優れるというのは、同じ性能なら捌けるリクエスト量がAuroraの方が 多いという意味 ⚫ 高いスループットはストレージを分散させているからであり、 可用性に優れる理由でもある ➢ 参考：サーバーワークスエンジニアブログ – Amazon Aurora の料金
12. 12 データウェアハウス（DWH） - Amazon Redshift ⚫ Database SPの対象外です ⚫ データウェアハウスは分析・意思決定に活用するためのデータの倉庫 ⚫ 「列（カラム）指向ストレージ」を採用した大規模データ分析に特化 ⚫ 数億件〜数千億件といった、通常のDBではタイムアウトしてしまうような大規模クエリを 高速に処理できる ＜類似・関連＞ ⚫ Amazon S3などにあるデータをAmazon RedshiftからクエリできるRedshift Spectrum ⚫ Amazon S3で分析クエリを実行できるAmazon Athena
13. 13 Key-Value – Amazon DynamoDB ⚫ サーバーの管理が不要なフルマネージドNoSQL ⚫ データ量が数TBに増えても、アクセスが秒間数万件に達しても、応答速度（1桁 ミリ秒）が変化しないのが最大の特徴 ⚫ サーバーの「大きさ」を上げるのではなく、分散することで「横に」無限に拡張できる ⚫ AWS Lambdaとの相性が良い ⚫ SQLは使用不可（NoSQL）なので、集計・分析に向かない  SQLライクなデータ操作は可能ではあるが（筆者が知る限り）テーブル結合が不可能だったりと一般的な SQLとは使用感がかなり異なる ⚫ テーブルの設計と維持の作法が浸透していない
14. 14 インメモリ – Amazon ElastiCache、Amazon MemoryDB ⚫ インメモリDBに分類 ⚫ データの読み書きをすべてメモリ内で行うため、ディスクI/Oが発生せず、極めて低い レイテンシ（遅延）を実現する ⚫ 低いレイテンシを活かして、キャッシュ、セッション管理に用いられる ⚫ MemoryDBは、インメモリDBの低レイテンシに加えマルチAZにまたがるデータの 「永続性」を持つ
15. 15 ドキュメント – Amazon DocumentDB（MongoDB互換） ⚫ データはJSON形式（BSON） ⚫ データ構造を柔軟に変更可能 ⚫ MongoDBのアプリケーション、ドライバ、ツールをそのまま、あるいは最小限の変更 で利用可能
16. 16 強力な検索機能- Amazon OpenSearch Service ⚫ 全文検索などの強力な検索機能を提供するサービス ⚫ ベクトルデータベースとしても使用可能で、Amazon Bedrockと連携して生成AI の精度を向上に役立てることが可能 ⚫ 使い方の選択肢が多すぎて非常に難解なサービス ⚫ 単独でデータベース兼検索サービスとして使用可能だが、 データそのものはAmazon DynamoDB、Amazon DocumentDB、 Amazon S3などに置くことも可能（ゼロETL） ⚫ データを外部に置く場合、OpenSearch Serviceは索引（インデックス）部分と 検索機能の部分を提供するイメージとなる 次頁から次の章に移ります
17. データベースの使い分け
18. 18 Amazon AuroraとAmazon RDSとマルチAZ Oracle・Microsoft SQL Server などを使用していない 割高であるAuroraのコストを 許容できるか？ ⚫ AuroraとRDSをどちらを選択するか RDS Aurora Yes Yes No No ⚫ マルチAZにするかどうか AZ障害時の ダウンを許容できるか？ 自動アップデート時の ダウンを許容できるか？ シングルAZ Yes Yes No No マルチAZ 自動アップデートをしない場合、手動アップデートによる管理が必要になります
19. 19 PostgreSQL互換とMySQL互換 ⚫ 2026年現在、最も勢いのあるデータベースはPostgreSQLです 故に、今から新規でAmazon RDS／Amazon Auroraを構築する場合は PostgreSQLまたはPostgreSQL互換を選択するのが無難でしょう ➢ 参考：2025 Stack Overflow Developer Survey ⚫ ただし、「互換」は同じSQLなどが使えるという意味であり、 「同じもの」ではないことに留意する必要があります 同じSQLが実行できても、同じ速度が出るとは限りません
20. 20 RDBMSとNoSQL ⚫ 業務システムにおいては、 迷ったらRDBS(Amazon Aurora/RDB)をメインに選択した方がよいと思います ⚫ NoSQL(Amazon DynamoDB)は整合性を維持する設計・運用とその維持の 難度が高く、業務システムの相性がそこまでよくありません ⚫ 明らかに大量の読み書きが発生する部分はAmazon DynamoDBの方が有利 です  ただし、Amazon DynamoDBは分析・集計に向かないので、 RDBMSとは扱うデータを棲み分けた方がよいでしょう  少々複雑になりますがAmazon DynamoDBで書き込みを受けて、分析・集計はRDBMSという構成も あります
21. 21 インメモリDBは必要なのか？ ⚫ インメモリDBであるAmazon ElastiCacheはキャッシュやセッション管理（＝ログ インしているかどうかなどのデータ）に用いられます ⚫ キャッシュはアプリケーション側でも持つことはできますが、それだと負荷分散に不利に になるので、コストに問題がなければアプリケーションサーバーとは別にキャッシュサー バーがあった方がよいと思います
22. 22 大規模データ分析サービスの選択 ⚫ 基本的にコストが割高なサービス群なので、分析頻度で使い分けます ⚫ 現実的にはAmazon Athenaで事足りることが多いです サービス 分析頻度 コストモデル Amazon Redshift 高（定常的） 起動時間（インスタンス） Amazon Athena 低（単発） クエリごとのスキャン量のみ Redshift Spectrumは頻度とコストで選ぶものではなく、 「Amazon Redshiftを使っていてAmazon S3のデータを合わせて集計したい」 のようなケースで選ぶ拡張的な機能です 次頁から次の章に移ります
23. オンプレミスのデータベースをAWSに 移行した場合の注意点
24. 24 オンプレミスとAWSでは使用感に差が出る ⚫ 基本的にオンプレミスとAWSでは使用感に差が出ます これは、ハードウェア（特にストレージ）やネットワーク構成が異なることに起因します ⚫ ストレージ構成の差などにより、Amazon RDSよりもAmazon Auroraの方が差が 大きく、特に書込速度の感覚にかなりの差が生まれます これによりバッチ処理が非常に遅くなるという現象がよく見られます ➢ 参考：サーバーワークスエンジニアブログ – Amazon Aurora の料金
25. 25 パラメータグループの編集は慎重に ⚫ Amazon RDS/Amazon Auroraにおいて、my.cnf・postgresql.confなどの データベースの設定ファイルはパラメータグループが相当します ⚫ パラメータグループで、 my.cnf・ postgresql.confと同じような設定は可能です が、オンプレミスにおける設定をそのまま適用するのは待ってください ⚫ パラメータグループはデフォルトの状態でAWSに最適化されているので、オンプレミス の感覚で設定を編集すると性能が発揮されなくなる可能性があります RDS/AuroraのパラメータはデフォルトでAWSに 最適化されています また、インスタンスサイズに比例して設定値が変化 するようになっています
26. 26 AWS Lambdaとの組み合わせにおける注意点 ⚫ AWS LambdaとAmazon RDS/Amazon Auroraの組み合わせはコネクションの枯 渇問題を起こしやすくなります AWS Lambdaのようなサーバーレス関数は短時間に大量に起動するためです 大量に起動・終了するため、AWS Lambda側でコネクションプーリングするのも難しいで す ⚫ これを回避するために、Amazon RDS Proxyというコネクションプーリングの専用サービ スがあります
27. 27 データベースサービスは組み合わせて良い ⚫ 先述した通り、業務システムにおいては迷ったらRDBMS(Amazon RDS/ Amazon Aurora)だと思いますが、全部をRDBMSでやる必要はありません ⚫ AWSには多数のデータベースサービスがあるので、突き詰めるとそれらを組み合わせ た方が有利になります ⚫ 例えば、大量かつ頻繁に読み書きをする部分はAmazon DynamoDBの方が適 しているし、セッション管理はRDBMSよりもAmazon ElastiCacheの方が適して います。
28. 28 CloudWatch Database Insightsの保持期間に注意 ⚫ Amazon RDS/Amazon Auroraにおいて、遅いクエリの特定や改善案の検討 にはCloudWatch Database Insights（旧Performance Insights）が便 利です ⚫ 性能の課題をベンダーやAWSサポートに相談する場合にも便利です ⚫ 一方で、CloudWatch Database Insightsは無料だと7日分しかパフォーマン スデータ履歴を保持しないことを覚えておいてください 相談しようとした場合に肝心のパフォーマンスデータが既に消失しているということが 起き得ます 次頁から次の章に移ります
29. 直近で発表されたデータベース系の アップデートについて
30. 30 Database Savings Plans の対象に OpenSearch Serviceが追加 ⚫ Database Savings Plans の対象に OpenSearch Service と Neptune Analytics が追加されました ⚫ 個人的にOpenSearchはベクトルデータベースに使うようになってきています ⚫ ベクトルデータベースは生成AIの回答精度向上に役立つRAGとして機能します ⚫ AWSにおけるデータベースの棲み分けは以下のイメージです  大規模：OpenSearch Service  中規模：Aurora＋pg_vector ←基本はこれ  小規模：S3 Vectors
31. 31 Amazon Aurora PostgreSQL Serverlessを数秒で作成可能に ⚫ 2026年3月26日発表 ⚫ Announcing Amazon Aurora PostgreSQL serverless database creation in seconds ⚫ DynamoDB/DSQLではできていたエクスプレス構成がAuroraでも ⚫ Amazon Aurora PostgreSQL Serverlessのエクスプレス構成  VPCなしが可能  デフォルトでIAM認証 ⚫ Vercelのv0 などの統合機能などの後押しになるかも ⚫ CI/CDや自動テストでの「使い捨てDB」として使えるかも 次頁から次の章に移ります
32. 最後に
33. 33 最後に ⚫ 今回はAWSのデータベースの知識を広く紹介しました ⚫ AIの隆盛に伴うアプリケーション開発の仕方の変化により、データベースの役割・運 用・トレンドは変化しています ⚫ 次の機会には、今回あまり触れられなかっOpenSearchを用いたベ クトルデータ ベースの紹介などをお届けしたいと思います