

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

# 信頼性の柱
<a name="reliability"></a>

[信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html)には、ワークロードが意図した機能を正しく一貫して実行する能力が含まれます。これには、ライフサイクル全体を通じてワークロードを運用およびテストする機能が含まれます。

信頼性の高いワークロードの設定は、ソフトウェアとインフラストラクチャの両方の設計に関する事前の決定から始まります。アーキテクチャの選択は、Well-Architected の柱のすべてにおいて、ワークロードの動作に影響を与えます。信頼性を実現するには、特定のパターンに従う必要があります。

信頼性の柱は、次の主要分野に焦点を当てています。
+ サービスクォータとデプロイパターンを含むワークロードアーキテクチャ
+ InfluxDB インスタンスの管理とスケーリング

## サービスクォータとデプロイパターンを含むワークロードアーキテクチャ
<a name="workload-architecture"></a>

各 AWS アカウント には、各 で提供されるリソースのクォータがあります AWS リージョン。たとえば、各リージョンには、インスタンスサイズに関係なく、[InfluxDB インスタンスの Timestream のクォータ](https://docs.aws.amazon.com/general/latest/gr/timestream.html#timestream-quotas)があります。リージョン内のインスタンスの最大数に達すると、インスタンスを作成するための追加の呼び出しは例外で失敗します。InfluxDB インスタンスストレージボリュームの Timestream は、サポートされているすべての で最大サイズ 16 テビバイト (TiBs) まで拡張できます AWS リージョン。

### デプロイパターン
<a name="deployment-patterns.bb62d876-ed6a-53fc-bfb8-7c6ac1a14e72"></a>

InfluxDB インスタンスの Timestream の[高可用性](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-multi-az-instance-deployments.html)とフェイルオーバーのサポートのために、単一のスタンバイ DB インスタンスでマルチ AZ 配置を使用できます。このタイプのデプロイは、マルチ AZ DB インスタンスのデプロイと呼ばれます。Amazon Timestream for InfluxDB は、Amazon フェイルオーバーテクノロジーを使用します。マルチ AZ DB インスタンスのデプロイでは、Amazon Timestream は、異なるアベイラビリティーゾーンで同期スタンバイレプリカを自動的にプロビジョニングおよび維持します。データの冗長性を提供するために、プライマリ DB インスタンスはアベイラビリティーゾーン間でスタンバイレプリカに同期的にレプリケートされます。

高可用性を備えた DB インスタンスを実行すると、DB インスタンスの障害時やアベイラビリティーゾーンの中断時に可用性が提供される可能性があります。DB インスタンスの予期しない停止がインフラストラクチャの欠陥に起因する場合、Amazon Timestream for InfluxDB は自動的にスタンバイレプリカに切り替わります。フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなったときのデータベースアクティビティおよびその他の条件によって異なります。

フェイルオーバー時間は通常 60～120 秒です。ただし、カーディナリティの高いデータを含む大規模なトランザクションや、ウォームアップ前の要件を含む長い復旧プロセスでは、フェイルオーバー時間が長くなる可能性があります。フェイルオーバーが完了したら、Timestream コンソールに新しいアベイラビリティーゾーンが反映されるまでに追加の時間が必要になる場合があります。

完全な AWS リージョン 停止中にアプリケーションを使用できるようにする必要がある場合は、ディザスタリカバリ (DR) プランの一部としてレプリケーションを設定するか、別のリージョンに書き込むことを検討してください。ただし、レプリケーションを設定する前に、必ず制限事項を理解してください。詳細については、[InfluxDB ドキュメント](https://docs.influxdata.com/influxdb/cloud/write-data/replication/replicate-data/)を参照してください。

Amazon Timestream for InfluxDB は、可用性と耐久性をサポートするため、内部バックアップを定期的に取得してこれを 24 時間保持します。削除中はスナップショットが作成され、復元をサポートするために 30 日間保持されます。これらにアクセスまたは使用するには、 でケースを作成します[AWS サポート](https://console.aws.amazon.com/support/home?nc2=h_ql_cu#/)。

## InfluxDB の Timestream の管理とスケーリング
<a name="manage-scale"></a>

InfluxDB の Timestream は、オープンソースの InfluxDB データベースでメモリを大量に消費するワークロードを実行するのに最適なインスタンスクラスをサポートしています。異なる [db.influx インスタンスクラス](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-dbi-classt-hw)には、vCPUsメモリ、ストレージ、ネットワーク帯域幅に制限があります。アプリケーションの書き込みおよびクエリのレイテンシー要件に合ったインスタンスクラスを選択するには、テスト中に Amazon CloudWatch `CPUUtilization`、`MemoryUtilization`、および `DiskUtilization`メトリクスを確認します。ワークロードの要件に基づいて[インスタンスをスケールアップまたはスケールダウン](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-modifying-db.html)できます。InfluxDB の Timestream は、さまざまなタイプのワークロードに必要な最適な IOPS とスループットで事前設定された複数のストレージ層を提供します。要件に基づいて、ワークロードに最適なものを選択します。

スケーリングのニーズが予測可能な時間に変化する場合は、 [AWS Lambda 関数](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-run-lambda-schedule.html)またはカスタムスケジューラを使用して API または SDK を実行して、バッファ時間を指定してスケールアップまたはスケールダウンできます。

パラメータグループのパラメータを使用して、Timestream for InfluxDB で InfluxDB InfluxDB 設定を管理します。パラメータグループは、1 つ以上の DB インスタンスに適用される InfluxDB 設定オプションの*コンテナ*として機能します。パラメータグループのパラメータを変更するときは、静的パラメータと動的パラメータの違いと、それらがどのようにいつ適用されるかを理解します。現在適用されている設定を確認するには、[GetDbParameterGroup](https://docs.aws.amazon.com/ts-influxdb/latest/ts-influxdb-api/API_GetDbParameterGroup.html) API アクションを使用します。