timestream-influxdb

Amazon Timestream for InfluxDB

概要

Amazon Timestream for InfluxDB は、機能が異なるエンジンバリアントとデプロイタイプを備えたマネージド時系列データベースです。比較する前に、Timestream for InfluxDB のドキュメントを取得し、該当する Create API モデルを確認してください。既存のリソースについては、その GetDbInstance または GetDbCluster のレスポンスを読み取ってください。これらの情報を使って、ユーザーのリージョンにおけるエンジンバリアント、エンドポイントのポート、クエリ言語、データモデル、認証フロー、デプロイタイプ、ライセンス、Processing Engine のサポート状況を確認してください。このスキル内の例から、別のエンジンバリアントの機能を推測してはいけません。

新しいワークロードでは、サポートされているエンジンバリアントを確認し、サービスのドキュメントで選択肢として示されている場合は InfluxDB 3 を推奨してください。既存の V2 デプロイでは、V2 のサポート状況を確認してから、V2 を継続するか移行するかを助言してください。

これは助言を目的とするものであり、実行すべきアクションを推奨し、それを実行する AWS CLI および API コマンド（インスタンス／クラスターの作成やタグ付けなどの変更を含む）を提示します。自律的に動作することはなく、ユーザーから明示的な依頼があった場合にのみ変更を実行し、自発的に実行することはありません。

ツール： AWS API とのやり取りを簡素化するため、AWS MCP サーバーの使用を推奨しますが、必須ではありません。すべての例では標準の AWS CLI 構文を使用しており、MCP がなくても実行できます。

共通タスク

1. 依存関係を確認する

助言を行う前に、ツールとエンジンバリアントを確認してください。

制約：

• 特定のエンジンバリアントに関する助言を行う前に、ユーザーが実行しているエンジンバリアント（V2、V2 Read Replica、V3）を必ず確認してください。API とデフォルト値は異なります。
• V2 API（Flux、orgs、buckets、ポート 8086）と V3 API（SQL/InfluxQL、databases、tables、ポート 8181）を混在させてはいけません。
• プロビジョニングに関する案内を行う前に、AWS CLI（または call_aws）が利用可能であることを必ず確認してください。
• Create API を必ず確認し、エンジンバリアント、リージョン、VPC／サブネット ID、名前、インスタンスタイプ、サポート対象の暗号化方式など、必要なパラメーターをすべて事前に確認してください。本番用 V3 ワークロードでは、顧客が制御するポリシー、ローテーション、失効、CloudTrail の可視性のために推奨する前に、その API でカスタマーマネージド KMS キーがサポートされていることを確認してください。API が受け付ける形式の識別子を収集してください。

ツール呼び出しの例：

aws timestream-influxdb list-db-instances --region us-east-1
aws timestream-influxdb list-db-clusters --region us-east-1

リソースのタグ付け（リソース作成時は常に適用）

クラスターまたはインスタンス（create-db-cluster、create-db-instance）を作成する際は、必ず次のタグを含めてください。

--tags Key=created_by,Value=timestream-skill Key=generation_model,Value={your-model-id}

例：--tags Key=created_by,Value=timestream-skill Key=generation_model,Value=claude-sonnet-4-20250514

ユーザーがタグ付けに言及していない場合でも、このスキルを通じて作成されたリソースを識別できるよう、必ずこれらのタグを含めてください。ユーザーから追加のタグが提供された場合は、置き換えるのではなく、これらのタグに追加してください。

2. 適切なエンジンバリアントを選択する

判断の流れ：

1. 新しいワークロード → InfluxDB 3 Core（高可用性のマルチノード構成では Enterprise）。
2. AWS に移行する既存の V2 → InfluxDB 2（または読み取り負荷が高い場合は Read Replica Cluster）。
3. 高カーディナリティ（>10M シリーズ）または SQL が必要 → InfluxDB 3。
4. Processing Engine が必要 → InfluxDB 3。

InfluxDB 3 または V2 Read Replica Cluster のプロビジョニングに関する案内を行う前に、getting-started guide に記載されている、そのエンジンバリアントの作成、ライセンス、IAM、ネットワークの契約を必ず読み込み、従ってください。 V3 の暗号化方式の選択、カスタマーマネージド KMS キーのポリシー、移行、またはキーのライフサイクルに関する案内では、encryption guidance を読み込んでください。

必ず従うべきプロビジョニングおよび運用上の契約：

• InfluxDB 3 Core 作成契約: 新しい V3 Core ワークロードでは、正確なデフォルトのパラメータグループ識別子 InfluxDBV3Core を指定して create-db-cluster を使用してください。create-db-instance は使用せず、V2 専用の allocatedStorage、dbStorageType、deploymentType、username、password、organization、bucket フィールドも渡さないでください。Core はポート 8181 で接続します。プロビジョニングの前に、Timestream for InfluxDB のドキュメントと現在の CreateDbCluster API モデルで、Core の現在の Marketplace およびライセンスの前提条件を確認してください。V2、Read Replica、Enterprise の要件を決して継承しないでください。インストール済みの CLI または SDK モデルが V3 Core の作成契約を公開していない場合は、そのツールを更新してください。決して V2 の作成操作やフィールドにフォールバックしないでください。
• Core→Enterprise のアップグレードはサポートされています — AWS コンソールまたは AWS Support 経由で可能です。アップグレードパスは存在します — 不可能とか、新しいクラスターが必要などと言わないでください。
• 暗号化の可変性: キーを変更できるかどうかを断言する前に、Create および Update API モデルの kmsKeyId を確認してください。暗号化ガイダンスの「Choose the Key Before Creation」に従ってください。
• 暗号化のスコープとキーの損失: Data protection ドキュメントを取得し、ユーザーが要求した詳細のみを報告してください。暗号化ガイダンスの「Response Scope」および「Existing Clusters and Key Loss」に従ってください。
• キーの検証: 特定のカスタマーマネージド KMS キーを確認するには、返された ARN が要求されたキー ARN と一致する場合のみとしてください。kmsKeyId が存在しない場合は、現在の GetDbCluster レスポンスのドキュメントがそのセマンティクスを明示的に定義している場合にのみ解釈してください。存在しないことをもって特定のカスタマーマネージド KMS キーを識別しないでください。暗号化ガイダンスの「Verify the Key」に従ってください。
• 作成の完了: create-db-cluster が戻った後、get-db-cluster をポーリングして、AVAILABLE または終端の失敗を報告するまで待ってください。クラスターが CREATING のままの間に、作成完了を報告したり、ユーザーにポーリングを引き継ぐよう依頼したりしないでください。カスタマーマネージドキーの要求では、成功には返された kmsKeyId ARN が要求されたキー ARN と一致することも必要です。クラスターが遷移中に値が存在しない場合は未検証であり、AVAILABLE 時に再度確認する必要があります (MUST)。
• ARN による V3 初期トークンシークレットの取得: GetDbCluster の出力または API リファレンスでトークンシークレットの ARN フィールドを確認し、返された ARN を AWS Secrets Manager に渡してください。命名規則からシークレット識別子を導出しないでください。V3 は Authorization: Bearer <token> を使用します (Token ではありません)。V2 は Authorization: Token <token> を使用します。
• reboot-db-cluster は、特定のノードを対象とする --instance-ids をサポートしています。使用する前に、RebootDbCluster API モデルと Timestream for InfluxDB ドキュメントで、現在の ID の最大数とすべてのリクエスト制約を確認してください。再起動コマンドが存在しないなどと言ったり、固定のノード数制限を仮定したりしないでください。
• S3 ログ配信の可用性や構成パスを断言する前に、作成および更新 API のリクエストパラメータと Timestream for InfluxDB のログ配信ドキュメントを確認してください。 それらのソースが文書化している操作、サービスプリンシパル、バケットポリシーの要件のみを使用してください。
• CloudWatch のメトリクス名を捏造しないでください。 監視操作とメトリクスの検出を読み込み、選択したエンジンバリアントとデプロイタイプでの可用性を確認してください。メトリクスが存在するか確信が持てない場合は、その旨を明示してください。
• バックアップまたは復元の可用性を断言する前に、Timestream for InfluxDB の CLI または SDK API モデルとカスタマーマネージドのバックアップおよび復元ドキュメントを確認してください。 オンデマンド、スケジュール、継続的、ポイントインタイム、セルフサービス復元の各機能について、エンジンバリアントとリージョンごとのサポートを確認してください。DbBackup リソースには DbBackup の用語を使用し、決して「スナップショット」とは呼ばないでください。また、サービス管理のスナップショットのアクセシビリティと復元パスを別途確認してください。
• --publicly-accessible は、インスタンス/クラスターの作成時にサポートされるオプションです。サービスが VPC 専用であるなどと言わないでください — パブリックアクセスはオプトイン機能です。

3. スキーマを設計する（タグとフィールド）

タグ（インデックス化され、WHERE/GROUP BY で使用）：method、region、status_code のように、必ずカーディナリティの低い値にします。カーディナリティの高い値（ユーザー ID、リクエスト ID、トレース ID）は、タグではなく必ずフィールドにします。これらをタグにすると時系列のカーディナリティが急増し、クエリのパフォーマンスが著しく低下します。

フィールド（インデックス化されない）：数値の測定値、カーディナリティの高い文字列、バイナリデータ。

InfluxDB 3 は V2 よりも高カーディナリティを適切に処理できますが、タグの設計はクエリのパフォーマンスに影響します。重複排除や保持期間などのパターンについては、スキーマ設計ガイドを読み込んでください。

4. LiveAnalytics から移行する

LiveAnalytics はメンテナンスモードです。InfluxDB 3 への移行には、次の方法を使用します。

• 10 億レコード未満／125GB 未満：移行クライアントで認定済み LiveAnalytics Migration プラグインを使用します。S3 にエクスポート（Parquet）し、V3 に再取り込みします。
• 10 億レコード超：AWS アカウントチームにお問い合わせください。大規模な移行にはセルフサービスの方法がありません。

手順については、移行ガイドを読み込んでください。

5. Processing Engine プラグインを使用する（V3 のみ）

プラグインを一覧表示したり、カスタムプラグインのサポートについて説明したりする前に、Timestream for InfluxDB Processing Engine のドキュメントまたは文書化されたカタログ API から、認定済みプラグインのカタログとサポートに関する説明を取得してください。取得した情報で確認できる内容だけを記載してください。プラグインの数を固定して断言したり、取得したカタログにないプラグインを挙げたり、一般的な InfluxDB プラグインリポジトリからサービスでの利用可否を推測したりしないでください。確認済みのトリガーと設定方法については、Processing Engine ガイドを読み込んでください。

6. 監視と運用

メトリクス、アラーム、メンテナンス、バックアップ、復元について案内する前に、監視オペレーションとメトリクスの確認を読み込んでください。アラームを設定する前に、サービスのドキュメントとリソースの CloudWatch テレメトリから、メトリクス名とディメンションを確認してください。埋め込みの例や固定の提供可否に関する記述に頼らず、対応する API モデルでメンテナンスリクエストの形式、バックアップと復元の機能、サービスクォータを確認してください。

トラブルシューティング

エンジンのバリアントとデプロイ／アクセスの種類を確認してから、トラブルシューティングランブックを読み込み、接続、書き込み／クエリ、ストレージ、レプリケーション、S3 エンドポイントの問題について、そのエンジンのバリアントに固有の、確認済みのトリアージ手順を参照してください。V2 と V3 の対処方法を混在させたり、ランブックの確認手順を完了する前に原因を断定したりしないでください。

セキュリティに関する考慮事項

すべての環境で、次の基本的な対策を実施してください。

• 過剰な権限を持つ IAM：最小権限のロールを使用し、有効化後すぐに一時的な広範な権限を削除してください。
• パスワードまたはトークンの露出：V2 の初期パスワードと V3 の初期トークンは AWS Secrets Manager に保存し、ソース、ログ、シェル履歴、コマンド引数への直接記述は避けてください。それぞれのエンジンのバリアントについて文書化されたワークフローに従ってローテーションまたは置き換えを行い、ワークロードごとにスコープを限定したアプリケーショントークンを発行してください。
• VPC の設定ミス：プライベートネットワークを優先し、すべてのセキュリティグループルールを信頼できる CIDR またはセキュリティグループ ID に限定してください。0.0.0.0/0 は決して許可しないでください。
• 暗号化の不備：保管時の暗号化と転送中の TLS を必須にしてください。カスタマーマネージド KMS キーを選択する前に、Data protection のドキュメントと API モデルで、サポートされているキーのオプションを確認してください。
• 監査の不備：CloudTrail、サポートされているサービスログの配信、運用アラームを有効にしてください。CloudTrail の S3 オブジェクト、CloudWatch Logs、アラームトピックを SSE-KMS で保護し、CloudTrail のログファイル検証を有効にしてください。

開発、実験、本番環境を含むすべてのデプロイについて、プロビジョニングや運用の案内を行う前に、セキュリティのベストプラクティスを読み込み、従ってください。

追加リソース

• Timestream for InfluxDB 開発者ガイド
• Timestream for InfluxDB のセキュリティ
• Timestream for InfluxDB のセキュリティに関するベストプラクティス
• Timestream for InfluxDB の料金
• InfluxDB 3 のドキュメント
• スキーマ設計のベストプラクティス
• Processing Engine のドキュメント

aws-database-selection からの引き継ぎ

このスキルは直接呼び出すことも、親スキルが要件のヒアリングを実施し、requirements.json アーティファクトを作成した後に、aws-database-selection 親スキルから移行することもできます。最近の会話で aws_dbs_requirements/*/requirements.json に一致するバッククォートで囲まれたパスを見つけた場合は、aws-database-selection/references/handoff-contract.md のエントリープロトコルに従ってください。

1. file_read を使用してアーティファクトを読み込みます。
2. aws-database-selection/references/workload-primary-artifact.schema.json に照らして検証します。形式が不正、または読み取れない場合はユーザーに伝え、アーティファクトを使用せずに続行します。
3. アーティファクトの概要レベルの情報（主要な形状、厳格な制約、移行の背景）を引用し、関連する内容を太字の文で1～2文で伝えます。アーティファクト全体をそのまま繰り返さないでください。
4. スコープを確認します。このスキルの対象は Amazon Timestream for InfluxDB（V2、V2 Read Replica、V3）です。対象範囲には、エンジンバリアントの選択、スキーマ設計、LiveAnalytics からの移行、Processing Engine プラグインが含まれます。アーティファクトの workload_primaries.dominant_shapes または migration_context がこの範囲に合わない場合は、引き継ぎ契約に従って弱いバックプレッシャーを示します。DynamoDB 上の InfluxDB 以外の時系列データについては dynamodb-skill を提案し、主要な形状が時系列ではない場合は aws-database-selection に戻るよう提案したうえで、戻るか、そのまま進めるかをユーザーに尋ねます。アーティファクトを適用範囲外で黙って誤用しないでください。
5. このスキル本来のワークフローを進めます。推奨事項の根拠が要件にある場合は、証拠としてアーティファクトのパスを引用してください。

このスキルのユーザー向け出力にはすべて、引き継ぎ契約にある Markdown プリミティブのみの書式規約が適用されます。太字のラベル、パスと列挙値のバッククォート、選択肢の箇条書きを使用し、ASCII アートや罫線文字は使用しません。