翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
運用上の優秀性の柱
AWS Well-Architected フレームワークの運用上の優秀性の柱は、システムの実行とモニタリング、プロセスと手順の継続的な改善に焦点を当てています。開発をサポートし、ワークロードを効率的に実行し、運用に関するインサイトを得て、ビジネス価値をもたらすサポートプロセスと手順を継続的に改善する能力が含まれます。人間の介入なしにほとんどの問題を検出して修復する自己修復ワークロードによって、運用上の複雑さを軽減できます。このセクションで説明されているベストプラクティスに従うことで、この目標を達成できます。Amazon Neptune メトリクス、API、各種メカニズムを使用して、ワークロードが予想される動作から逸脱した場合に適切に対応します。
運用上の優秀性の柱に関するこの説明では、以下の主要分野に焦点を当てています。
-
Infrastructure as code (IaC)
-
変更管理
-
レジリエンシー戦略
-
インシデント管理
-
コンプライアンスのための監査レポート
-
ログ記録とモニタリング
IaC アプローチを使用してデプロイを自動化する
IaC を使用して Neptune でのデプロイを自動化するためのベストプラクティスは次のとおりです。
-
可能な限り、Infrastructure as Code (IaC) を適用して Neptune クラスターをデプロイします。一貫した環境設定を行うため、クラスターに必要なすべてのリソースを作成するには AWS CloudFormation テンプレート、AWS Cloud Development Kit (AWS CDK)、または HashiCorp Terraform
を使用します。 -
インスタンスのサイズ変更、リードレプリカの追加または削除、グローバルテーブルでの手動フェイルオーバーなど、Neptune の運用手順を可能な限り自動化します。
-
接続文字列をクライアントの外部に保存します。ブルー/グリーンデプロイ戦略、ディザスタリカバリ (DR)、新しいクラスターへのほぼゼロのダウンタイムでの移行を容易にするため、抽出、変換、ロード (ETL) プロセスを使用します。接続文字列は、AWS Secrets Manager、Amazon DynamoDB、または動的に変更できる任意の場所に保存できます。
-
タグを使用してメタデータを Neptune リソースに追加し、タグに基づいて使用量を追跡します。詳細については、「Amazon Neptune リソースのタグ付け」を参照してください。
小規模かつ可逆的な変更を頻繁に行う
以下の推奨事項は、複雑さを最小限に抑え、ワークロードの中断の可能性を減らすための、小規模かつ可逆的な変更に焦点を当てています。
-
IaC テンプレートとスクリプトを GitHub や GitLab といったソースコントロールサービスに保存します。
重要
ソース管理に AWS 認証情報を保存しないでください。
-
IaC デプロイでは、AWS CodePipeline や AWS CodeBuild などの継続的インテグレーションおよび継続的デリバリー (CI/CD) サービスを使用する必要があります。これらのサービスは、本番環境の Amazon Neptune クラスター
に影響を与える前に、一時的な Neptune クラスターを含む非本番環境でコードをコンパイル、テスト、デプロイします。 -
本番環境にデプロイする前に、インフラストラクチャとアプリケーションのクエリをより低い環境でテストします。これにより、中断の可能性が最小限に抑えられ、ワークロードやスケールに合わせて適切に動作させることができます。
失敗を予測する
自己修復インフラストラクチャは、障害を予測し、介入なしで問題解決を試みることで、運用上の優秀性を実証します。以下の推奨事項は、Neptune でその成熟度を実現するのに役立ちます。
-
Amazon CloudWatch メトリクスを使用して DB インスタンスの CPU とメモリの使用状況をモニタリングし、使用状況のパターンを理解するモニタリングプランを作成します。アプリケーションログにある主要なメトリクスと Neptune クライアントレスポンスを確認するための CloudWatch ダッシュボードとアラームを作成します。CPU 使用率の高低を示す指標の詳細については、Neptune ドキュメントの「Using CloudWatch to monitor DB instance performance in Neptune」を参照してください。
クエリでout-of-memory例外が頻繁に発生する場合は、クエリが通過するノードの合計数を減らすか、RAM-to-CPU の比率が高い
X2ファミリーのインスタンスの使用を検討してください。 -
Neptune クラスターの状態をモニタリングするために通知を設定します。例えば、
BufferCacheHitRatioは常に高い (99.9% を超える) 必要がありますが、MainRequestQueuePendingRequestsは常に低い (理想的には 0 ですが、要件とレイテンシーの許容値によって異なります) 必要があります。 -
Neptune 内で高可用性を実現するには、リードレプリカの使用を検討してください。フェイルオーバーイベント中にインスタンスが常に読み取りクエリを処理できるように、ライターインスタンスとは異なるアベイラビリティーゾーンに少なくとも 2 つのリードレプリカが必要です。
-
使用率メトリクスに基づいてリードレプリカを自動的にスケーリングします。詳細については、「Amazon Neptune DB クラスター内のレプリカの数の Auto-scaling」を参照してください。
-
DB インスタンスのフェイルオーバーをテストすることで、そのプロセスでユースケースにかかる時間を把握します。
-
アプリケーションが完全に AWS リージョン 停止した場合、DR プランの一部としてグローバルデータベースを使用することを検討してください。
すべての運用上の障害から学ぶ
自己修復インフラストラクチャは、まれな問題が発生したり、対応が意図したような効果を出さなかったりするたびに反復的に進化していく長期的な取り組みです。以下のプラクティスを採用することで、その目標に焦点を当てることができます。
-
すべての障害から学ぶことで改善を推進します。
-
チームと組織で教訓を共有します。組織内の複数のチームが Neptune を使用している場合は、共通のチャットルームまたはユーザーグループを作成して、学習とベストプラクティスを共有します。
ログ機能を使用して、不正または異常なアクティビティをモニタリングする
異常なパフォーマンスやアクティビティのパターンを観察するには、Amazon CloudWatch Logs にログを保存します。以下のベストプラクティスを考慮します。
-
スロークエリロギングを有効にします。ログを定期的に確認し、特定のクエリが遅い理由を診断します。Gremlin、SPARQL、または openCypher 向けの Neptune の explain エンドポイントと profile エンドポイントを使用して、これらのクエリが遅い理由に関するインサイトを取得します。
-
Neptune 監査ログを有効にし、ログに不正アクセスや異常がないか定期的に確認します。
-
スロークエリログ記録または監査ログ記録を使用している場合は、CloudWatch Logs への発行を有効にします。これにより、インスタンスのディスク容量が不足するのを防ぐことができます。Neptune インスタンスのログストレージ容量は限られており、ログ容量を超えると古いログファイルは上書きされます。CloudWatch Logs は、ログの長期保持をサポートしています。CloudWatch Logs の強化されたモニタリング機能を使用すると、ログをクエリして問題を診断する能力が向上します。
-
監査ログの分析ツールを改善するため、監査ログデータを CloudWatch Logs のロググループに発行するように Neptune DB クラスターを設定できます。CloudWatch Logs を使用すると、ログデータのリアルタイム分析、CloudWatch を使用したアラームの作成およびメトリクスの表示、CloudWatch Logs を使用した、耐久性に優れたストレージへのログレコードの保存を行うことができます。詳細については、「Publishing Neptune logs to Amazon CloudWatch Logs」を参照してください。
-
Neptune は、 AWS CloudTrailを使用したコントロールプレーンのアクションのログ記録をサポートしています。詳細については、「 を使用した Amazon Neptune API コールのログ記録 AWS CloudTrail」を参照してください。