はじめに

こんにちは、第三SAチームのamaebiです。
今回は、6/20(木)、6/21(金)に開催されたAWS summit 2024 のセッション「AWS NoSQL コスト削減大全」のレポートを書いていきたいなと思います。

セッション概要

タイトル：AWS NoSQL コスト削減大全(AWS-38)

AWS セッション(Level 300: 中級者向け)
テーマ：AWS for Data

スピーカー

アマゾン ウェブ サービス ジャパン合同会社 堤 勇人

概要

ここ数年、日本でも Amazon DynamoDB や Amazon ElastiCache といった NoSQL を採用した事例が加速してきました。一方、これらのサービスを採用し便利に使っているけれど、コストが気になってきた、無駄なく使えているか心配、という方も多いのではないでしょうか。実は NoSQL のような目的別に特化したデータベースはコストを削減するポイントが決まっています。このセッションでは AWS の NoSQL サービスによるコスト削減手法について、ベストプラクティスをまとめて一挙にお伝えします。

何故 NoSQL のコスト削減は有効なのか

コストとは？

• インフラコスト
  • サーバーのプロビジョニング料やストレージ使用料等
• ライセンスコスト
• オペレーションコスト
  • 時間や人材、スキル等
• 開発コスト
  • 開発のしやすさ等
• ビジネスコスト
  • 機会損失(メンテナンス、障害、既存アプリケーションの改修の難しさ)も含まれます

データベースのコスト削減は難しい？

• データベースは全体のコストの中で大きい要素の一つ
• 永続層のデータを取り扱っているため、一番目につきやすい
• ただ、ミスや停止ができない分、コスト削減は難しい
• 高い可用性や高い専門性が必要になってしまう
• その結果、データベースのコスト最適化されずに放置されてしまう…

NoSQLのコスト削減

• NoSQL のコスト削減は⽐較的容易
• AWS のデータベースサービス = Purpose-built databases
  • 目的別に特化したデータベースが複数用意されている
  • 目的別に使用していただくだけ、そのままベストプラクティスとなる
• 逆に⽬的に沿わない使い⽅はアンチパターンとなる

NoSQL コスト削減ベストプラクティス

Purpose-built databases

• 説明するNoSQLサービス
  • Amazon DynamoDB
    • 特徴：Key-Value
  • Amazon DocumentDB (with MongoDB compatibility)
    • 特徴：Document
  • Amazon ElastiCache
    • 特徴：In-Memory
  • Amazon MemoryDB
    • 特徴：In-Memory
  • Amazon Neptune
    • 特徴：Graph
  • Amazon Timestream
    • 特徴：Time-series
• 以下のポイントを抑えつつ、説明していく
  • サービスごとの特徴、目的
  • サービスごとのユースケース
  • コスト削減にあたってみるべきポイント

NoSQLにおけるコスト削減ポイント

• サイジング & スケジューリング
  • コンピューティングリソースが適切な量、適切なタイミングで割り当てられているか
• 価格体系
  • 意外と重要
  • とりあえず新しいからと使ってしまうケースが多いが、モードを変えるだけでコスト削減したということも
• オプション設定
  • 価格体系と同様で、ちょっとした設定を変更することでコスト削減に繋がったケースもある
• データモデリング
  • アプリケーションレイヤーの領域
  • データベースの特性に合わせたデータモデリング方法を紹介

コンピューティングリソースの価格体系

名称	プロビジョンドインスタンス	プロビジョンドキャパシティ	オンデマンドキャパシティ
タイプ	インスタンス	サーバーレス	サーバーレス
動的なスケール操作	スケールイン・アウト	キャパシティ変更	キャパシティ変更
支払い	割り当てた分	割り当てた分	実際に利用した分
適するワークロード	定常的なワークロード	ある程度予測可能で変化が滑らかなワークロード	予測不可能、もしくは変化が急激なワークロード

• プロビジョンドインスタンス
  • 割り当てたインスタンスをフルで使い切る場合、スループットあたりのコストが一番低い
  • スケールアップ、ダウンの際に切替が発生するため、バッファを踏まえた切替時間の確保が必要
• プロビジョンドキャパシティ
• オンデマンドキャパシティ

コスト削減ポイント – 価格体系詳細

※価格体系のグラフについては、AWS Summitのセッション資料からご覧ください。

• コンピューティングリソース
  • プロビジョンドインスタンス
    • 基本的に動作中にスケールアップ/ダウンさせない
  • プロビジョンドキャパシティ
    • 動作中にもスケールアップ/ダウンさせる影響は無停止か瞬断
  • オンデマンドキャパシティ
    • スケールを意識しない使用した分支払う
  • リザーブドは適用できるか
• I/O、メモリ、ストレージ、バックアップなど適切なオプションを選択する
• 価格設定の最低値も見る

Amazon DynamoDB

特徴
– 一桁ミリ秒の応答速度
– スケールしてデータが大きくなっても変わらず応答時間は一桁ミリ秒
– 大規模なスケーラビリティ
– 小規模から大規模まで同じアーキテクチャでそのまま増やしていける
– サーバーレス

コスト削減する際のポイント
– 価格体系
– プロビジョンドキャパシティ(Provisioned mode)
– 設定した分の課金
– オンデマンドキャパシティ(On-demand mode)
– 利用した分の課金
– キャパシティユニットという単位で表現され、読み込みは4KB/1キャパシティユニット、書き込みは1KB/1キャパシティユニットとして計算される。
– 結果整合性のある読み込み(反映が遅れても良い読み込み)は半分の0.5キャパシティユニットで利用可能
– 読み込みは書き込みの5倍安い
– DynamoDBに1回書き込む時の価格とDynamoDBに5回読み込む(不利な条件で40回)読み込む価格は同じ
– 5回読み込んでその中からデータを絞り込めるのであれば、セカンダリインデックス(書き込みが発生する)を作成する必要がなくなる

• Provisioned mode は On-demand mode の最大7倍安い(フルのスループットで利用した場合)
  • オートスケーリングで使用率が14.4%あることと同値
  • “On-demand mode + たまにくるスパイク処理”のコスト より “Provisioned mode + 安全率 50%” のコストの方が安く抑えられる
• さらに Provisioned mode はリザーブドキャパシティが使用することで、最大77%安くなる
• 逆にOn-demand modeを利用することで、オートスケーリングの設定や ピーク時の処理、スロットリングエラーを出しなくない場合等を減らすことが可能
  • Provisioned modeだと、上記のオペレーションコスト、ビジネスコストが発生してしまうことが課題
• Provisioned mode と On-demand mode の切替が可能
• ストレージ書き込みが多い場合は Standard-IA クラスを使う
  • 標準テーブルクラスのスループット コストの5割ほどがストレージコストになった場合、Standard-IA クラスを検討するとコストメリットに繋がる

Amazon DocumentDB

特徴
– 非構造型データ(JSON)の格納
– MongoDb 互換のデータベースでスキーマレス
– 複雑なクエリ、アドホックなクエリが使える
– 属性の違うものを一緒に格納できる

コスト削減する際のポイント
– 価格体系
– プロビジョンドインスタンス
– プロビジョンドキャパシティ(ElasticCluster)
– サーバーレス
– 簡単にクラスターの増減が可能
– スケジューリング
– クラスターを一時的に停止でき、最大7日間停止可能
– I/O 最適化ストレージオプション
– I/O コストがデータベースの総コストの 25% を超えたあたりで、上記オプションを検討した方が良いかも
– TTL ストリームはI/Oを消費する
– ローリングコレクションでコレクションごと消すことで、TTLストリームを削減できる

Amazon ElastiCache

特徴
– マイクロ秒レベルの応答速度
– Redis & Memcached 互換
– サーバーレス対応

Amazon MemoryDB

特徴
– インメモリの応答速度
– プライマリデータベースとしてのマルチ AZ 耐久性
– Redis 互換

Amazon ElastiCache / Amazon MemoryDB

コスト削減する際のポイント
– 価格体系
– プロビジョンドインスタンス
– オンデマンドキャパシティ(ElastiCache Serverless)
– Reserved Nodes は最大55%削減
– バージョンアップ←まずはじめにやっていただきたいコスト最適化
– 過去数年にわたって、速度やパフォーマンス改善のバージョンアップを行っている
– バージョンアップをするだけで、かなりのコストメリットが期待できる
– Redisの場合、後方互換性が崩れることがあまりない
– データ階層化インスタンスタイプ
– データが非常に多く、全体の20%以下に頻繁にアクセスされるユースケース
– マッチするユースケースでは60%以上のコスト削減
– その他、Amazon ElastiCacheを他のサービスのキャッシュレイヤとして利用することでコスト削減が期待できる

Amazon Neptune Database / Analytics

特徴
– グラフ構造に対して効率的にクエリ
– グラフ構造をRDBMSで実現しようとすると、複雑なクエリになってしまい、CPUやメモリの使用率が増加してしまう…
– OLTP だけでなく OLAP, 機械学習にも対応

コスト削減する際のポイント
– 価格体系
– プロビジョンドインスタンス
– プロビジョンドキャパシティ
– スケジューリング
– バージョンアップ
– 15回以上バージョンアップがなされている
– クエリチューニング
– Spark GraphX からの移行
– そのまま移行するだけで、それだけでコスト削減に繋がったケースもある

Amazon Timestream

特徴
– 時系列データの扱いに特化
– LiveAnalytics に加え、Managedサービスとして InfluxDB 版をリリース
– 標準のSQLにも対応しているため、学習コストがかからないメリット

コスト削減する際のポイント
– 課金体系
– プロビジョンドインスタンス = InfluxDB
– 二桁ミリセカンドの応答速度がほしい場合
– オンデマンドキャパシティ = LiveAnalytics
– 分析応答で少しレイテンシが発生してもいい場合
– TB、PB規模のデータ量をアグリゲーションしたい場合
– コスト削減アプローチ
– 必要なデータのみを Bulk で書き込む
– メモリ層の保存期間を適切に設定
– Timestreamの裏側では、メモリに保存する場所とストレージに保存する場所でデータがシームレスにやり取りをしている
– クエリチューニング
– 適切なエンジン選択

持続的なコスト削減に向けて

コスト削減のステップ

• リソースの最適化 → 購買オプションの導入 → 自動化・メカニズム → リアーキテクチャ
  • 話した範囲(リソース最適化～購買オプションの導入)
  • 今回話した内容だけでもコスト削減に大きな期待があるが、ここで止まってはいけない
  • 仕組み化・自動化していき、”継続的な削減”を目指していく

クイックウィンで満足してはいけない

• 一時的にコスト削減を行ったとしても、長期的に見ればコストが上がってしまう可能性が十分に考えられる
• 一時的なコスト削減を何回か行ったとしても、前回ほどのコスト削減は期待できない
• 定期的なリソースの精査が重要
  • リソースを精査して無駄を省いた後、最低限のところでリザーブドインスタンスを購入する など

コスト削減のステップ

• コスト削減で出来たリソースを次のステップへ
  • それぞれのサービス、部署、組織がオーナーシップを持って、継続的にコスト削減をし続けることが理想
• 組織規模での継続的なコスト削減の取り組みに関する情報
  • AWS Cost Explorer コスト最適化ハブ
  • AWS Compute Optimizer
  • Trusted Adviser
  • AWS Well-Architected Framework
    • Database Lens

まとめ

• NoSQL (Purpose built database) は⽐較的コスト削減しやすい
  • データベースの設計思想通りに使うことがベストプラクティス
• データベースレイヤーであってもリファクタリングの前にできることがある
• ⾒るべきポイントはサイジング、スケジューリング、価格体系
• クイックウィンに満⾜せず、コスト削減を継続する組織作りが必要

さいごに

AWS NoSQL コスト削減大全 のセッションレポートでした。
AWS NoSQLの各種サービス名や概要を知っている程度でしたが、そんなレベルの私でも理解できるほど内容がまとめられていてとても分かりやすかったです。
セッション内容が中級者向けとなっていますが、「AWS データベースサービスの種類が多く、どのサービスを触れば良いか分からない」という初心者の方が見てもとても勉強になるセッションだと思いました。

普段、データベースのコスト削減が難しいと思われて結局何もできずにいる方も、本セッションを見てから少し出来る範囲でコスト削減してみるのもいいかもしれません。