翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 持続可能性の柱
<a name="sustainability-pillar"></a>

 AWS Well-Architected フレームワークの[持続可能性の柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/sustainability.html)は、クラウドワークロードの実行による環境への影響を最小限に抑えることに重点を置いています。主なトピックは、持続可能性に関する責任共有モデル、影響の把握、必要なリソースを最小限に抑えてダウンストリームへの影響を軽減するための使用率の最大化です。

持続可能性の柱には、以下の主要な重点分野が含まれています。
+ ユーザーによる影響
+ 持続可能性の目標
+ 使用率の最大化
+ より効率的な新しいソフトウェアサービスを予測して採用する
+ マネージドサービスの使用
+ ダウンストリームの影響軽減

このガイドでは、影響の理解に焦点を当てています。その他の持続可能性設計原則の詳細については、[AWS 「 Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus-design-principles.html)」を参照してください。

ユーザーによる選択と要件は、環境に影響を及ぼします。炭素強度の低い を選択し、稼働時間と耐久性を最大化するだけでなく、要件 AWS リージョン が実際のワークロードのニーズを反映している場合、ワークロードの持続可能性が向上します。次のセクションでは、ワークロード設計と継続的な運用で採用された場合に環境に悪影響を及ぼすベストプラクティスと考慮事項について説明します。

## AWS リージョン 選択を検討する
<a name="region-selection"></a>

一部の AWS リージョン は Amazon 再生可能エネルギープロジェクトの近くにあるか、グリッドの炭素強度が他のものよりも低い公開されている場所にあります。ワークロードに対して実行可能なリージョンの[持続可能性への影響](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)を考慮し、[Neptune Analytics が利用可能なリージョンとリストを相互参照します。](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/analytics-limits.html#limits-regions)

## 消費の最適化
<a name="consumption"></a>

以下を実践することで、Neptune Analytics の消費量を最小限に抑えます。
+ 多くの場合、分析は一時的なものです。グラフは、アルゴリズムを実行して結果を記録する時間にのみ必要です。この場合、不要になったグラフを[スナップショットして削除](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/managing-deleting.html)します。必要に応じて[、後でスナップショットから復元](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/graph-snapshots.html#graph-snapshots-restoring)できます。
+ ワークロードがエフェメラルで、分析を実行するタイミングを柔軟に決定できる場合は、電力消費量のday-to-day傾向を考慮してください。電力の需要は、特定の時間帯に高くなります。米国にお住まいの場合は、米国エネルギー情報局 (EIA) のウェブサイトで[毎日の電力消費量に関するメトリクス](https://www.eia.gov/electricity/gridmonitor/dashboard/electric_overview/US48/US48)を参照してください。可能であれば、リージョンのオフピーク期間中にワークロードを実行します。
+ ワークロードがエフェメラルではなく、限られた期間のみ使用する必要がある場合は、グラフを削除し、必要に応じてスナップショットから復元します。可用性がスケジュールに従っている場合は、スケジュールされた時刻にグラフの準備ができるように、スクリプトを使用して復元プロセスを自動化します。
+ データが読み取り専用であるか、前回のスナップショット以降に変更されていない場合は、削除前に再度スナップショットを作成しないでください。
+ 使用していない Neptune ノートブックを停止します。
+ `NumQueuedRequestsPerSec`、、`NumOpenCypherRequestsPerSec`、`GraphStorageUsagePercent`、 などの CloudWatch メトリクスをモニタリング`CPUUtilization`して`GraphSizeBytes`、グラフのサイズが大きすぎるかどうかを評価します。小さいインスタンス容量が観測されたリクエストレート、CPU 使用率、グラフサイズに対応できるかどうかを確認します。

## ソフトウェア開発とアーキテクチャパターンを最適化する
<a name="patterns"></a>

無駄を防ぐには、モデルとクエリを最適化し、コンピューティングリソースを共有して、Neptune インスタンスとクラスターで使用可能なすべてのリソースを活用します。具体的なベストプラクティスは次のとおりです。
+ クエリとグラフアルゴリズムの呼び出しを最適化します。パラメータ化されたクエリを使用し、デフォルトで有効になっている[クエリプランキャッシュを使用します](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/query-plan-cache.html)。スロークエリの場合は、[説明プラン](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/query-explain.html)を実行して改善を行います。[ベクトル類似度検索](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/vector-similarity.html)を使用する場合は、小さい埋め込みの方がより効率的に作成、保存、検索できるため、小さい埋め込みの方が正確な類似度結果が得られるかどうかを判断します。[グラフアルゴリズム](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/algorithms.html)を呼び出す前に、 `MATCH`句を使用して入力ノードセットを最小限に抑えます。可能であれば、ノードラベルとエッジラベルをフィルタリングします。
+ グラフにデータをロードする最も効率的な方法を探します。Amazon S3 のデータからロードする場合は、データが 50 GB を超える場合は[一括インポート](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/bulk-import.html)を使用します。小さなデータには[バッチロード](https://docs.aws.amazon.com/neptune-analytics/latest/userguide/batch-load.html)を使用します。
+ 開発者に、それぞれが独自のインスタンスを作成するのではなく、Neptune ノートブックインスタンスを共有するように依頼します。1 つの Jupyter インスタンスで開発者ごとに個別のノートブックフォルダを作成します。インスタンスが使用されていない場合はシャットダウンします。