Amazon Neptune Serverlessでコストとパフォーマンスを最適化するベストプラクティスおよびユースケースの紹介

この記事では、Amazon Neptune Serverless の一般的なユースケースと、推奨されるベストプラクティスに従ってコストとパフォーマンスの両方を最適化する方法を紹介します。

Amazon Neptune は、グラフ・アプリケーションの構築と実行を容易にする、クラウド向けに最適化されたフルマネージド・データベース・サービスです。RDF と プロパティグラフ 両方のグラフ・データモデルをサポートしています。データベース管理を簡素化し、新規アプリケーションの構築や既存アプリケーションの移行を迅速に行うことができます。高価なライセンス料からの脱却を目指す組織は、Neptuneに移行することで、最新のオープンソース・イノベーションの恩恵を受けることができます。求められる要件に対してカスタマイズできるよう、高可用性や耐久性 など幅広い機能を提供します。

Neptune Serverless は、オンデマンドの自動スケーリング構成で、必要に応じてNeptuneクラスタをスケールするようにデザインされています。Neptune Serverlessでは、いくつかの制限 はありますが、プロビジョニングされたインスタンスと同じ機能を使用できます。費用対効果が高く、データベースの容量を管理・最適化することなく、グラフのワークロードを実行し、迅速にスケーリングすることができます。Neptune Serverlessインスタンスでは、次のようなメリットがあります。

• 迅速かつ無停止のキャパシティ・スケーリング
• きめ細かく予測可能なキャパシティ調整
• 高可用性、ディザスタリカバリ、拡張機能
• すでにNeptuneを使用している場合、アプリケーションを変更することなく簡単に移行することが可能

Neptune Serverlessクラスタのスケーリング構成は Neptune Capacity Unit（NCU）で定義され、NCUはそれぞれ2 GBのメモリと、関連する仮想プロセッサ（vCPU）およびネットワーク容量で構成されます。サポートされる NCU の最小値は 1.0 で、最大値は 128 です。NCU 構成は 0.5 NCU 単位で調整できます。Neptune Serverlessはコンピュートリソースのみスケールすることにご注意ください。ストレージの上限 は変わらず、サーバーレスのスケーリングの影響を受けません。

Neptune Serverlessの一般的な使用例

Neptune Serverlessは、非定常的かつ突発的なトラフィックを伴うワークロードに最適です。定常的で予測可能なトラフィックを持つワークロードに使用することはお勧めしません。その理由は、定常的なワークロードの場合、プロビジョニングされたインスタンスの方がコスト効率が良いからです。たとえば、プロビジョニングされたdb.r5.xlargeインスタンスを選択する方が、NCU=16 最小値=最大値に設定して 、NCU=16 のままのサーバーレスインスタンスよりも費用対効果が高くなります。

以下は、サーバーレスがデータの分離や費用対効果などの利点を提供できる、その他の使用例です。

Neptuneの新規利用あるいは新規アプリケーションに対するリソースの最適化

Neptuneを初めて利用するお客様にとって、グラフデータのワークロードに必要なインフラストラクチャを決定することが困難な場合があります。お客様のワークロードに 最適なインスタンスサイズを推定する方法 を提供していますが、クエリのレイテンシや予想されるトラフィックなどの追加情報が必要であり、初期段階では明らかにできないケースが多くあります。そのため、新規でNeptuneを利用するお客様や新規アプリケーションにとっては、キャパシティ要件を決定することが難しくなります。代わりに、コンピュートリソースの計算を気にせずにNeptune Serverlessを開始し、それまでのリソース消費量を確認することで要件を満たすプロビジョニング・インスタンス・サイズを特定することができます。また、アプリケーションの書き込み/読み込みが多かったり、トラフィックにばらつきがあることに気づいたら、サーバーレスインスタンスとプロビジョニングインスタンス を1つのクラスタで組み合わせることもできます。

開発環境とテスト環境

多くのお客様は、本番環境ではない開発環境とテスト環境でコストを削減する新しい方法を模索しています。開発チームやテストチームが大規模なインスタンスをデプロイし、その停止や削除を忘れてしまうことは、多くのお客様にとって懸念事項です。しかし、開発チームやテストチームは、大規模な負荷テストを実行できるインスタンスをデプロイしなければいけません。サーバーレスは両方の長所を提供することができます。つまり、稼働していない期間中のコストを削減するために最小NCU数が少ないサーバーレスインスタンスをデプロイすることができ、開発チームやテストチームが高稼働期間中に迅速にスケーリングできるように最大NCU数が多いサーバーレスインスタンスをデプロイすることができます。

テナントごとのデータベースを備えたマルチテナント・アプリケーション

何千人ものエンドユーザーにサービスを提供する SaaS (Software as a Service) アプリケーションのようなプラットフォームでは、現在または予想される需要に基づいて Neptune クラスタを過剰または過小にプロビジョニングすることがよくあります。また、個々の顧客データを分離する必要がある場合、データの分離要件に直面することもあります。Neptune Serverlessを使用すると、個々のNeptuneクラスタを提供することで各顧客のデータを物理的に分離できるだけでなく、Neptune Serverlessの自動スケーリング機能を使用して、基盤となるインフラストラクチャを積極的に管理する必要がなくなり、各テナントデータベースを独立してスケーリングできます。

データベースに支えられたいくつかのアプリケーション

今日の最新のアプリケーション・アーキテクチャでは、何百、何千ものカスタム・アプリケーションが存在し、それぞれが1つ以上のデータベースによって成り立っています。アプリケーションの要件が進化するにつれて、それらをサポートし続けるためのデータベース容量も追随しなければなりません。費用対効果の高い方法でデータベース・フリートの容量調整を管理することは、困難かつ労力を要します。サーバーレスは、アプリケーションと関連するキャパシティ要件が進化するにつれて、データベース・キャパシティの管理負担を軽減するのに役立ちます。

効率的な水平および垂直スケーリング

スケーラビリティを必要とするアプリケーションは、より高いスループットを得るために、データベースを複数のインスタンスに分割することがお勧めです。各インスタンスの容量を予測するのは困難で非効率的です。なぜなら、予想されるリクエスト数と各クエリのレイテンシに関する複雑な情報や経験が必要だからです。インスタンスの数が少なすぎると、データを再配置しなければならず、ダウンタイムが発生します。インスタンスの数が多すぎると、すべてのインスタンスが均等に利用されないため、高いコストを支払うことになります。サーバーレスインスタンスを使用することで、初期コストをあまり追加することなく、アプリケーションを複数のインスタンスにシャードすることができ、シャードされたデータベースはそれぞれ、必要なときに必要な容量を垂直方向に拡張することができます。過少利用や過剰なプロビジョニング、不要なコストの支払いは必要ありません。

Global DatabaseとNeptune Serverlessによるディザスタリカバリ

Neptune Global Database は、プライマリーインスタンスと最大 5 つのセカンダリーリージョン間でグラフデータをレプリケートする機能を提供します。これにより、リージョン全体が停止した場合のディザスタリカバリの機能を提供します。しかし現実には、リージョン全体で障害が発生する可能性は低いため、セカンダリーリージョンにプロビジョニングされたNeptuneインスタンスは十分に活用されないケースもあります。セカンダリーリージョンでプロビジョニングされたインスタンスの代わりにサーバーレスインスタンスを使用することで、NCUの最小値を許容可能な最小値に設定することで、積極的に使用されていない間のコストを節約することができます。また、必要に応じて、クラスタ構成を更新することでNCU値を増やし、新しい需要に合わせて自動的にスケールさせることもできます。

Neptune Serverlessのベストプラクティス

このセクションでは、Neptune Serverlessを使用する際のベストプラクティスを紹介します。

ワークロードと機能に最適な最小および最大NCUの構成

次のことを検討します。

• 一括ロードを使用するワークロード – バルクロードのようなリソース集約型のワークロードには、Neptune Serverlessを適切に構成することをお勧めします。最大 NCU は、希望するレートでデータを取り込むことができるレベルに設定する必要があります。たとえば、バルクロード操作時に 128 NCU に設定すると、Neptune は一括ロードに必要なリソースを確保できます。正確な最大 NCU は、取り込むデータ量と希望するデータ取り込みレートに依存します。また、NCU 最小値=最大値 とする構成は、スケーリングが容易にならないため、この種のユースケースではアンチパターンです。この場合、同じようなサイズ（メモリ・サイズとvCPU数）のプロビジョニングされたNeptuneインスタンスの方が良い選択かもしれません。
  サーバーレスリーダーインスタンスを大規模なプロビジョニングされたプライマリーインスタンスと組み合わせて使用する場合、書き込みの数に追いつけず、共有ストレージからの読み込みを再起動するような状況が発生します。この場合、プライマリーからのレプリケーショントラフィックを満たすためにサーバーレスリーダーインスタンスの最小NCU構成を1NCU以上の値にスケールアップするか、一括ロード操作中に一時的に削除する必要があります。詳細については、一括ロード中に再起動を繰り返さないようにする を参照してください。
• IAMデータベース認証が有効になっているNeptuneクラスタ – AWS Identity and Access Management (IAM)データベース認証 が有効になっているNeptuneクラスタでは、エラーを回避するために最低でも2以上の最小NCU値が必要です。

トラフィックが急増するワークロードをサーバーレスインスタンスに切り替える

需要が急増し、一貫性のないワークロードに対しては、サーバーレスインスタンスを使用することで、Neptuneクラスタに関連するコンピュートリソースを垂直方向にスケールする自動化されたコスト効率の高いメカニズムが提供されます。しかし、トラフィックが一貫しているワークロードでは、サーバーレスインスタンスを使用すると、同じ容量のプロビジョニングされたインスタンスを使用する場合と比較してコスト効率が悪くなります。また、サーバーレスクラスターでNCU 最小値=最大値を設定することは、推奨されるパターンに反しています。要件によっては、プロビジョニングされたインスタンスの方がコスト効率とパフォーマンスが高く、ニーズを満たせるかもしれません。

最小容量を増やし、より高速なスケーリングを可能にする

Neptune Serverlessは、最小NCUの設定値に基づく速度でスケールします。最小NCUが1.0に設定されている場合、サーバーレスクラスターが重いトラフィックに対応する容量を提供するためにスケールアップするのに時間がかかります。これは、Neptune Serverlessが 現在使用されているサーバーレス容量に基づいてスケーリング増分を選択 するためです。これを高い値に設定することで、特にデータベースへの需要が増加することが分かっているイベントの前に、Neptune Serverless はより高いスケーリング率を使用し、需要に対応するためにより速くスケールアップします。

リーダーインスタンスの正しい昇格階層を設定する

Neptune Serverlessリーダーインスタンスが最小NCUまでスケールダウンせず、プライマリーインスタンスと同じかそれ以上の容量にとどまっている場合は、リーダーインスタンスの昇格階層を確認してください。Tier 0または1では、サーバーレスリーダーインスタンスはライターインスタンスと同じ容量に維持されます。リーダーの昇格階層を2以上に変更することで、ライターから独立してスケールアップあるいはスケールダウンするようになります。詳細については、Neptune Serverlessインスタンスの昇格階層 の設定を参照してください。

Neptune Serverlessと自動スケーリングの組み合わせ

Neptuneリードレプリカ自動スケーリング を使用して、接続要件とワークロードに基づいてNeptuneクラスタ内のレプリカ数を自動的に調整できます。また、Neptune Serverless を使用して、アプリケーションからの突然のトラフィック急増にも対応することができます。CPU使用率ベースの自動スケーリングを使用する場合、最小値と最大値の両方のNCUを低く設定したり、最小値と最大値のNCUの範囲を狭く実装したりすると、Neptuneリードレプリカの追加と削除が急激に行われることがあります。

クエリのタイムアウトを正しく設定し、クエリがバックグラウンドで実行され、コストがかかるのを防ぐ

プロビジョンドインスタンスと比較して、長時間稼働するワークロードに対してNeptune Serverlessを実行するコストは高くなるため、特定の要件に対応できるように クエリタイムアウトパラメータ(neptune_query_timeout) を調整することをお勧めします。短時間のクエリのみが予想される場合は、クエリタイムアウトを短く設定します。これは、バックグラウンドで実行されている予期せぬ長時間実行クエリによって不要なコストが発生するのを避けるためです。

サーバーレスインスタンスを監視してコストと最適化を図る

サーバーレスクラスターやインスタンスを監視するために、サーバーレスインスタンス用のAmazon CloudWatchメトリクス が2つ追加されています。

• ServerlessDatabaseCapacity – (インスタンスレベルの) 現在のインスタンス容量、または (クラスタレベルの) 全インスタンスの全値の平均を提供する
• NCUUtilization – ServerlessDatabaseCapacityを NCU の最大値で割って、使用可能な容量の割合をレポートする

もしNCUUtilizationメトリックが100%に近づいている場合は、サーバーレスインスタンス全体でNCUの最大値を増やすことを検討してください。

Neptune Serverlessの価格

サーバーレスインスタンスをデプロイする際、価格設定などはプロビジョニングインスタンスと同じ要素が適用されます。

• ストレージはGB/月で請求
• 消費されたI/Oオペレーション
• バックアップ・ストレージ
• データ転送料金
• Global Database やスナップショットエクスポートなどの特別機能の料金

サーバーレスインスタンスの課金の主な違いは、1時間あたりのNCUでの使用量 に基づいて価格が設定されることです。実際のコストは、Neptuneクラスタがデプロイされたリージョンによって異なります。

Neptune Serverlessの価格比較

以下は、サーバーレスインスタンスと db.r6g.8xlarge プロビジョニングインスタンスを使用した場合の、30日間にわたるスパイク上のトラフィックと一貫したトラフィックを持つワークロードのコスト比較です。どちらの見積もりにも以下の構成が含まれています。

• リージョンはus-east-1
• 50GBのデータと100GBのバックアップ
• 月間2億回のI/Oオペレーション
• 月間50GBのデータ転送
• 月間10GBのデータ転送

次の表は、トラフィックが急増しているワークロードの例を比較したものです。最大 NCU (128) で 1 日あたり 1 時間、最小 NCU (1) で 1 日あたり 23 時間です。

サーバーレスを使用した場合、プロビジョニングされたインスタンスと比較して、スパイク特性の高いワークロードにかかるコストの差は、月額3,076.20ドルの節約となりました。
次の表は、最大NCU（128）で1日あたり23時間、最小NCU（1）で1日あたり1時間、一貫したトラフィックのワークロードの例を比較したものです。

一貫したワークロードに対してプロビジョニングされたインスタンスとサーバーレスを使用した場合のコストの差は、月額10,402.18ドルの増加となりました。

Neptune Serverlessの制約

Neptune Serverlessは垂直スケーラビリティとコスト効率を迅速に提供できますが、その制約を理解することが重要です。

• サーバーレスは すべての地域で利用できるわけではない（訳注:東京リージョンではご利用可能です）
• エンジンリリース1.2.0.1 以降で使用可能
• Neptuneの ルックアップキャッシュ とは互換性がない
• サーバーレスインスタンスの最大メモリは256GB（最大NCUは128）

詳細は Amazon Neptune Serverless constraints を参照してください。

まとめ

この投稿では、Neptune Serverlessの一般的なユースケースとベストプラクティスについて説明しました。様々なトラフィックやデータ分離を必要とするワークロードに対してプロビジョニングされたインスタンスよりもサーバーレスインスタンスを使用したり、本番環境ではない開発環境やテスト環境などで高い費用対効果を得たりすることでメリットを得ることができます。さらに、同じNeptuneクラスタ内でサーバーレスインスタンスと従来のプロビジョニングされたインスタンスを組み合わせることで、最も負荷の高いワークロードに対して柔軟性とスケーラビリティを提供する方法についても説明しました。
Neptune Serverlessを始めるには、Neptuneコンソール にアクセスするか、Amazon Neptune Serverless を参照して詳細を確認してください。

著者について

Kevin Phillipsは、Amazon Web Servicesの英国で働くNeptuneスペシャリスト・ソリューション・アーキテクトです。18年にわたる開発とソリューション・アーキテクチャの経験を生かし、顧客のサポートと指導にあたっています。
Ankit Guptaは、インドの Amazon Neptune Platform チームのソフトウェア開発マネージャーで、製品立ち上げ当初から Neptune チームの一員です。AWSの顧客や社内の開発チームと協力し、Neptuneのユーザビリティ、パフォーマンス、スケーラビリティ、ユーザーエクスペリエンスの向上に取り組んでいます。

本記事は 2023/06/28に投稿された Use cases and best practices to optimize cost and performance with Amazon Neptune Serverless を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。