コスト最適化の柱

AWS Well-Architected フレームワークのコスト最適化の柱は、不要なコストを回避することに重点を置いています。以下の推奨事項は、Neptune Analytics のコスト最適化設計原則とアーキテクチャのベストプラクティスを満たすのに役立ちます。

コスト最適化の柱は、次の主要分野に焦点を当てています。

• 時間の経過に伴う支出と資金配分の制御について

• 適切なタイプと数量のリソースの選択

• 過剰な支出なしでビジネスニーズを満たすスケーリング

必要な使用パターンとサービスを理解する

Neptune Analytics を採用する前に、ユースケースがグラフ分析に適しているかどうかを評価してください。

• グラフデータベース: Neptune などのグラフデータベースは、データモデルに識別可能なグラフ構造があり、クエリが関係を調べて複数のホップをトラバースする必要がある場合、ワークロードに適しています。グラフデータベースは、次のパターンには適していません。

  • 主にシングルホップクエリ。このユースケースでは、データがオブジェクトの属性としてより適切に表されるかどうかを検討してください。

  • プロパティとして保存される JSON またはバイナリラージオブジェクト (BLOB) データ。

• グラフ分析: Neptune Analytics は、大量のグラフデータをメモリ内ですばやく分析してインサイトを取得し、傾向を見つけることができるグラフ分析データベースエンジンです。Neptune データベースと Neptune Analytics グラフの両方にグラフデータを保存およびクエリできます。Neptune データベースは、スケーラブルなオンライントランザクション処理 (OLTP) のニーズに最適です。Neptune Analytics は、エフェメラル分析ワークロードに最適です。この 2 つを組み合わせて使用するには、トランザクション指向の Neptune データベースから Neptune Analytics グラフにデータをロードして、そのデータの分析を実行します。分析が完了したら、Neptune Analytics グラフを削除できます。詳細については、Neptune Analytics ドキュメントの「Neptune Analytics を使用するタイミング」と「Neptune Database を使用するタイミング」を参照してください。

コストに注意して、Neptune Analytics グラフに入力する最適な方法を決定します。

• S3 バケットにステージングされたグラフデータを一括インポートします。このオプションは、データが以前に Neptune データベースへの一括ロード用にステージングされていた場合、または一括インポートに必要な CSV またはその他のサポートされている形式で分析されるデータがすでにあるか、簡単に生成できる場合にお勧めします。グラフ作成手順の一部として一括インポートを実行できます。最小容量と最大容量に境界を設定できます。 以前に作成した空のグラフでインポートを実行し、実行中にインポートタスクをモニタリングすることもできます。

• 空のグラフを作成し、バッチロードを使用して openCypher クエリで入力できます。このオプションは、ロードするデータが Amazon S3 でステージングされ、50 GB 未満である場合に最適です。

• Neptune データベースクラスターのデータからグラフを入力できます (Neptune データベースバージョン 1.3.0 以降でサポートされています）。このパターンの目的は、現在グラフデータベースにあるデータに対して分析を実行することです。データベースが最初に一括ロードで入力された場合でも、それ以後大幅に変更された可能性があります。データベースからインポートするために、Neptune Analytics はデータベースのクローンを作成し、クローンから S3 バケットにデータをエクスポートします。この手順にはコストが発生します。特に、クローンを実行するための Neptune データベースコストと、エクスポートされたデータを保存および消費するための Amazon S3 コストです。エクスポートが完了すると、クローンは削除されます。Amazon S3 でエクスポートされたデータを削除できます。

• Neptune データベースクラスターのスナップショットからグラフを入力できます。これは、ソースがデータベーススナップショットである点を除いて、前のオプションと似ています。スナップショットからインポートするには、Neptune Analytics はまずスナップショットを新しいデータベースクラスターに復元し、次にデータを S3 バケットにエクスポートします。この手順ではコストが発生します。特に、復元されたクラスターを実行するための Neptune データベースコストと、エクスポートされたデータの保存と消費のための Amazon S3 コストが発生します。

• openCypher クエリを実行して、グラフでアトミック性、整合性、分離、耐久性 (ACID) 準拠のトランザクションを使用してデータを作成、更新、または削除することもできます。このアプローチは、小さな更新を行う方法としてお勧めしますが、グラフをシードする方法としてはお勧めしません。

分析に必要なデータが Amazon S3 ですでにステージングされている場合は、一括インポートまたはバッチロードをお勧めします。これらは、Neptune データベースクラスターまたはスナップショットからグラフを入力するよりもコスト効率が高くなります。

コストに注意してリソースを選択する

Neptune Analytics の料金は、メモリ最適化 Neptune キャパシティーユニット (m-NCU) と呼ばれる単位を使用します。特定の m-NCU でグラフを実行する場合、時間単位の固定コストが発生します。グラフにはフェイルオーバー用のレプリカが含まれている場合があり、これらのレプリカには時間単位の m-NCU コストも発生します。

容量の見積もり、コストの制限、パフォーマンスに対するコストのモニタリングには、次のベストプラクティスをお勧めします。

• 可能であれば、既存のソースからデータをインポートしてグラフを作成します。Amazon S3 または既存の Neptune クラスターまたはスナップショットでステージングされたデータです。これにより、Neptune Analytics はグラフのシードの重労働を実行し、バインドされた最大容量を指定できるため、労力を節約できます。

• 既存のグラフでプロビジョニングされた容量を変更できます。

• グラフが不要になったら、スナップショットを作成してグラフを削除できます。再度使用する必要がある場合は、スナップショットからグラフを復元できます。

• グラフの作成時にレプリカの数を選択できます。分析の可用性要件に従って値を設定します。この設定を最小化してコストを節約します。最大値 2 では、別々のアベイラビリティーゾーンに 2 つのレプリカインスタンスを使用できます。最小値 0 は、Neptune Analytics がレプリカを実行しないことを意味します。ただし、レプリカが利用可能な場合、復旧が速くなります。グラフの障害と復旧の説明については、「信頼性の柱」セクションを参照してください。

• を使用して、現在および過去の請求期間の Neptune Analytics の費用をモニタリングしますAWS Billing and Cost Management。

• CloudWatch、特に NumQueuedRequestsPerSec、、NumOpenCypherRequestsPerSec、GraphStorageUsagePercentおよび GraphSizeBytesの Neptune Analytics メトリクスをモニタリングしてCPUUtlization、プロビジョニングされた容量がグラフに対して適切なサイズであるかどうかを評価します。小さい容量が観測されたリクエストレート、CPU 使用率、グラフサイズに対応できるかどうかを確認します。

• グラフにプライベートエンドポイントが必要な場合は、Elastic IPs、Virtual Private Cloud (VPC) エンドポイント、NAT ゲートウェイ、またはその他の VPC 関連のコストに注意してください。詳細については、「Amazon VPC の料金」とAmazon EC2 の料金」を参照してください。

• 開発者やアナリストがグラフをクエリおよび視覚化するのに役立つクライアントインターフェイスを提供するために、1 つ以上の Neptune ノートブックインスタンスを実行することもできます (「Neptune ワークベンチの料金」を参照）。コストを最小限に抑えるには、ユーザー間でインスタンスを共有し、ユーザーごとに個別のノートブックフォルダを作成します。インスタンスが使用されていない場合はシャットダウンします。シャットダウンを自動化する方法については、ブログ記事 AWS 「リソースタグを使用して Amazon Neptune 環境リソースの停止と開始を自動化する」を参照してください。