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

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

[持続可能性の柱](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 が利用可能なリージョン](https://docs.aws.amazon.com/neptune/latest/userguide/limits.html)と相互参照します。

## ユーザー行動パターンに基づく使用量
<a name="user-behavior-patterns"></a>

ユーザーのトラフィックと動作に合わせて使用量を適切なサイズにすることで、 AWS が環境に与える影響を最小限に抑えることができます。ソリューションを設計するときは、次のベストプラクティスを考慮してください。
+ `CPUUtilization`、`MainRequestQueuePendingRequests`、`TotalRequestsPerSec` などの Amazon CloudWatch メトリクスをモニタリングして、需要が最も高いときと最も低いときを判断し、そうしたタイミングにおいてクラスターリソースのサイズが適切に設定されていることを確認します。
+ 使用していない時間帯は非本番環境を停止するよう自動化します。詳細については、「[Automate the stopping and starting of Amazon Neptune environment resources using resource tags](https://aws.amazon.com/blogs/database/automate-the-stopping-and-starting-of-amazon-neptune-environment-resources-using-resource-tags/)」を参照してください。
+ トラフィックパターンの変動が頻繁かつ予測不可能な場合は、ピークトラフィック用にプロビジョニングされたインスタンスを使用する代わりに、需要に応じてスケールアップ/ダウンする Neptune サーバーレスインスタンスを使用することを検討してください。
+ サービスレベル契約を、ビジネス継続性の目標だけでなく持続可能性の目標に合わせることを検討してください。マルチリージョンディザスタリカバリ、高可用性、長期バックアップ保持などの簡単な要件については、特に非本番環境やミッションクリティカルでないワークロードの場合、これらの目標を達成するために必要なリソースの量を減らすことができます。

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

無駄を防ぐには、モデルとクエリを最適化し、コンピューティングリソースを共有して、Neptune インスタンスとクラスターで使用可能なすべてのリソースを活用します。具体的なベストプラクティスは次のとおりです。
+ 開発者に、それぞれが独自のインスタンスを作成するのではなく、Neptune インスタンスと Jupyter Notebook アプリケーションのインスタンスを共有してもらいます。[マルチテナンシーパーティショニング戦略](https://explore.skillbuilder.aws/learn/course/external/view/elearning/16133/data-modeling-for-amazon-neptune)を使用して、各デベロッパーに単一の Neptune クラスターに独自の論理パーティションを提供し、単一の Jupyter インスタンスで各デベロッパーに個別のノートブックフォルダを作成します。
+ リソースの使用率を最大化し、アイドル時間を最小限に抑えるパターンを実装します。例えば、データをロードするための並列スレッドや、レコードをより大きなトランザクションにまとめてバッチ処理するなどです。
+ クエリとグラフモデルを最適化して、結果の計算に必要なリソースを最小限に抑えます。
+ Gremlin クエリの結果については、[結果キャッシュ](https://docs.aws.amazon.com/neptune/latest/userguide/gremlin-results-cache.html)機能を使用して、ページ分割されたクエリまたは頻繁に繰り返されるクエリの再計算に費やされるリソースを最小限に抑えます。
+ Neptune 環境を最新の状態に保ちます。Neptune の最新バージョンは、Graviton などの最新の Amazon EC2 インスタンスをより効率的にサポートします。また、クエリ最適化の改善とバグ修正により、クエリの計算に必要なリソースの量を削減できます。