View a markdown version of this page

運用上の優秀性の柱 - AWS 規範ガイダンス
IaC アプローチを使用してデプロイを自動化する小規模かつ可逆的な変更を頻繁に行う失敗を予測するすべての運用上の障害から学ぶログ機能を使用して、不正または異常なアクティビティをモニタリングする

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

運用上の優秀性の柱

AWS Well-Architected フレームワークの運用上の優秀性の柱は、システムの実行とモニタリング、ビジネス価値をもたらすためのプロセスと手順の継続的な改善に焦点を当てています。運用上の優秀性の柱には、開発をサポートし、ワークロードを効果的に実行し、運用に関するインサイトを得る能力が含まれます。

人間の介入なしにほとんどの問題を検出して修復する自己修復ワークロードによって、運用上の複雑さを軽減できます。この目標を達成するために、このセクションで説明されているベストプラクティスに従ってください。Amazon Timestream for InfluxDB、InfluxDB ネイティブメトリクスエンドポイント、APIs、およびメカニズムの Amazon Amazon CloudWatch メトリクスを使用して、ワークロードが予想される動作から逸脱したときに応答します。

運用上の優秀性の柱に関するこの説明では、以下の主要分野に焦点を当てています。

  • Infrastructure as code (IaC)

  • 変更管理

  • レジリエンシー戦略

  • インシデント管理

  • 監査目的のログ記録とモニタリング

IaC アプローチを使用してデプロイを自動化する

IaC を使用して Timestream for InfluxDB でのデプロイを自動化するためのベストプラクティスは次のとおりです。

  • IaC を適用して、可能な限り InfluxDB の Timestream をデプロイします。一貫した環境設定を行うには、 AWS CloudFormation テンプレート、AWS Cloud Development Kit (AWS CDK)、または HashiCorp Terraform を使用して、インスタンスに必要なすべてのリソースを作成します。

  • インスタンスのサイズ変更など、InfluxDB の運用手順の Timestream を自動化します。

  • タグを使用して、InfluxDB リソースの Timestream にメタデータを追加し、タグに基づいて使用状況を追跡します。詳細については、「InfluxDB の Amazon Timestream のタグ付け」を参照してください。

小規模かつ可逆的な変更を頻繁に行う

以下の推奨事項は、複雑さを最小限に抑え、ワークロードの中断の可能性を減らすための、小規模かつ可逆的な変更に焦点を当てています。

  • IaC テンプレートとスクリプトを GitHub や GitLab などのソース制御サービスに保存します。ソース管理に AWS 認証情報を保存しないでください。

  • IaC デプロイでは、AWS CodeDeploy や AWS CodeBuild などの継続的インテグレーションおよび継続的デリバリー (CI/CD) サービスを使用する必要があります。これらのサービスは、本番環境の InfluxDB インスタンスに影響を与える前に、一時的な InfluxDB インスタンスを含む非本番環境でコードをコンパイル、テスト、デプロイします。

  • 本番環境にデプロイする前に、インフラストラクチャとアプリケーションのクエリをより低い環境でテストします。これにより、中断の可能性が最小限に抑えられ、ワークロードやスケールに合わせて適切に動作するようになります。

失敗を予測する

自己修復インフラストラクチャは、障害を予測し、介入なしで問題解決を試みることで、運用上の優秀性を実証します。以下の推奨事項は、Timestream for InfluxDB でその成熟度を達成するのに役立ちます。

  • メトリクスを使用して、メモリ、CPU、ストレージの使用状況をモニタリングします。使用パターンが変化したとき、またはデプロイの容量に近づいたときに通知するように CloudWatch を設定できます。このようにして、システムのパフォーマンスと可用性を維持できます。

  • リソース制限に近づいたら、DB インスタンスをスケールアップします。アプリケーションからのリクエストの予期しない増加に対応するために、ストレージとメモリにいくらかのバッファがあることが必要です。

  • データベースのワークロードでプロビジョニングした I/O がより多く必要になると、フェイルオーバーやデータベース障害後の復旧が遅くなります。DB インスタンスの I/O 容量を増やすには、I/O 容量が大きい別の DB インスタンスに移行します。

  • クライアントアプリケーションが DB インスタンスの DNS データをキャッシュしている場合は、time-to-live (TTL) 値を 30 秒未満に設定します。DB インスタンスの基になる IP アドレスは、フェイルオーバー後に変更されている可能性があります。DNS データを長期間キャッシュすると、接続が失敗する可能性があります。アプリケーションが、使用されなくなった IP アドレスに接続しようとする可能性があります。

  • アプリケーションが完全に AWS リージョン 停止した場合、ディザスタリカバリ (DR) プランの一部としてレプリケーションを設定するか、別のリージョンに書き込むことを検討してください。レプリケーションをセットアップする際の制限を理解します。レプリケーションの詳細については、InfluxDB ドキュメントを参照してください。

すべての運用上の障害から学ぶ

自己修復インフラストラクチャは、まれな問題が発生したり、対応が意図したほど効果的でない場合に反復して開発する長期的な労力です。自己修復インフラストラクチャの達成に集中するには、次のプラクティスを採用します。

  • すべての障害から学ぶことで改善を推進します。

  • チームと組織で教訓を共有します。組織内の複数のチームが Timestream for InfluxDB を使用している場合は、共通のチャットルームまたはユーザーグループを作成して、教訓とベストプラクティスを共有します。

ログ機能を使用して、不正または異常なアクティビティをモニタリングする

異常なパフォーマンスとアクティビティのパターンを観察するには、次のプラクティスを検討してください。

  • ログ配信を有効にして、InfluxDB ログを Amazon Simple Storage Service (Amazon S3) に保存します。InfluxDB は、以下を確認するのに役立つレコード情報をログに記録します。

    ログに不正アクセスや異常がないか確認します。全体として、ログ記録はトラブルシューティングの診断情報を提供します。

  • InfluxDB の Timestream は、 を使用したコントロールプレーンアクションのログ記録をサポートしています AWS CloudTrail。詳細については、「Logging Timestream for InfluxDB API calls with AWS CloudTrail」を参照してください。

  • CloudWatch の Timestream/InfluxDB > <Namespace> から CPUUtilizationMemoryUtilization、、 DiskUtilizationメトリクスをモニタリングできます。

詳細については、「Timestream for InfluxDB ドキュメント」を参照してください。