NTTデータ2年目社員の湯川と、1年目社員の喜田(@kidatakeru)と齋藤(@maaya)です。 クラウドインフラ領域に携わる若手エンジニア3名で、2026年7月30日・31日に東京ビッグサイトで開催された Google Cloud Next Tokyo 2026に参加しました。 本記事では、参加したセッションや展示から、クラウドインフラやSREの業務とのつながりを感じた内容を紹介します。 DAY 2のレポートでは、AIエージェントを支えるインフラ、実行基盤、データ、セキュリティについて紹介しています。 https://zenn.dev/nttdata_tech/articles

NTTデータ3年目社員の栫と、1年目社員の喜田（@kidatakeru）、齋藤（@maaya）です。 2026年7月30日・31日に東京ビッグサイトで開催されたGoogle Cloud Next Tokyo 26のDAY 2レポートです。 DAY 2で特に印象に残ったのは、運用に関する話題の多さです。 基調講演ではAIエージェントを動かし続けるための基盤が紹介され、各セッションでもデータベース移行に伴うチューニング、ハイブリッドクラウド運用、障害対応、オブザーバビリティなど、システムを継続的に運用するための工夫が語られていました。 新機能そのものよりも、「作った後にどう運用するか」に焦点

本記事は、 Timestream for InfluxDB 3 workload analysis and best practices を翻訳したものです。 Amazon Timestream for InfluxDB 3 のデプロイメントにおいて、適切なインスタンスサイズの選択は、時系列インフラストラクチャを設計する上で最も影響の大きい判断の 1 つです。インスタンスが小さすぎるとクエリパフォーマンスの低下や取り込みのボトルネックにつながり、大きすぎると未使用のキャパシティに対して余分なコストを支払うことになります。 本記事では、デプロイメントのサイジングの選び方について解説します。このガイドを参考に、お客様のビジネスユースケースに合った Timestream for InfluxDB 3 の構成を選択してください。Amazon Timestream for InfluxDB 3 を今すぐ使い始めるには、 ドキュメント をご覧ください。 サイジングのガイダンス パフォーマンス特性の理解 Amazon Timestream for InfluxDB 3 のデプロイメントに適切なインスタンスサイズを選択するには、ワークロードパターンごとのデータベースの挙動を把握することが重要です。 時系列データベースのパフォーマンスは、相互に関連する多くの要因に左右されます。クエリの複雑さはパフォーマンスに大きく影響します。直近のデータに対するシンプルな集計は、数か月分の履歴データにまたがる複雑な分析クエリとはパフォーマンスが異なります。データモデルも大きく影響します。数百万のユニークなタグの組み合わせを持つ高カーディナリティのデータセットは、低カーディナリティのモニタリングデータとは異なるパフォーマンス特性を示します。バッチサイズ、取り込みレート、ラインプロトコルポイントの構造といった書き込みパターンもパフォーマンスに影響します。 同時実行される操作には、固有の考慮事項があります。複数のアプリケーションがデータベースに同時にクエリを実行しながらデータの取り込みも継続している場合、取り込みとクエリ処理の間でリソースのバランスを取る必要があります。クエリの時間範囲も大きな影響を与えます。InfluxDB 3 のキャッシュとインメモリ最適化により直近のデータへのクエリは非常に高速であり、履歴データへのクエリ（Enterprise クラスターの場合）はコンパクター（圧縮を行うコンポーネント）と Parquet ストレージを使用して効率的に取得します。 本記事の目的は、お客様のワークロードに対する正確な予測を提供することではなく、デプロイメントの出発点となる情報を提供することです。 データとクエリに関する考慮事項 クエリと取り込みのパフォーマンスを向上させるには、以下の点を考慮してください。 カーディナリティが低い場合（ユニークなタグの組み合わせが少ない場合）、クエリがフィルタリングする必要のある系列が少なくなるため、パフォーマンスが向上する可能性があります。InfluxDB 3 ではカーディナリティは問題ではなくなりましたが、カーディナリティが際限なく増加してもパフォーマンスに影響がないわけではありません。クエリ操作のメモリ使用量が増え、圧縮パフォーマンスにも影響する可能性があります。 クエリがシンプルな場合（集計ではなく単一フィールドの取得など）、InfluxDB 3 の Last Value Cache の恩恵を受け、大幅に高速なレスポンスタイムが得られます。クエリが生データに対して数時間または数日にわたる集計を行う場合、データサイズの増加に伴いクエリパフォーマンスは低下します。可能な限り処理エンジンを使用して ダウンサンプリング を行い、クエリ結果として表示したい形式に合わせてデータを事前にフォーマットしてください。 書き込みバッチが大きい場合（medium から 4xlarge インスタンスでは 1 バッチあたり 5,000 ポイント、より大きなインスタンスでは 1 バッチあたり 10,000 ポイント以上）、リクエストあたりのオーバーヘッドが減少するため、書き込みスループットが向上します。 クエリが直近のキャッシュウィンドウを超える長い時間範囲や履歴データを対象とする場合、すべてのエディションで利用可能な ダウンサンプリング と、Enterprise エディションで利用できるコンパクター（圧縮を行うコンポーネント）により、良好なパフォーマンスを維持できます。 同時読み取りユーザーが少ない場合、多数の同時操作にリソースが分散されないため、クエリあたりのパフォーマンスが向上します。 デプロイメントの監視 インスタンスのデプロイ後、サイジングの妥当性を検証し、最適化の余地がないかを確認するため、パフォーマンスをモニタリングすることが重要です。Amazon CloudWatch は、CPU 使用率やメモリ使用量など、Timestream for InfluxDB 3 の重要なメトリクスを提供します。InfluxDB 3 の処理エンジンに含まれる System Metrics Plugin は、CloudWatch と同様のサーバーレベルのパフォーマンスデータを収集します。これには、詳細な CPU 統計（全体およびコアごと）、メモリ使用量の内訳、ディスク I/O パフォーマンス、ネットワークインターフェイス統計が含まれます。詳細な長期メトリクスについては、CloudWatch が 10 秒ごとに同じ粒度でメトリクスを記録するのに対し、System Metrics Plugin は カスタムスケジュール を設定できるため、CloudWatch よりも適しています。 データベース固有のパフォーマンスメトリクスについてより深い洞察を得るには、メトリクスエンドポイントをスクレイピングすることで、クエリパフォーマンス、書き込みスループット、その他のサービスレベル指標を詳細にモニタリングするための包括的な内部メトリクスを収集できます。Timestream for InfluxDB インスタンスの /metrics エンドポイントをスクレイピングする包括的なメトリクス収集ソリューションを提供しています。このソリューションは、 Telegraf を実行する Amazon EC2 インスタンスをデプロイし、クエリパフォーマンス、書き込みスループット、メモリ使用パターンなどの内部エンジンメトリクスを継続的に収集した後、CloudWatch に取り込み、事前設定された Grafana ダッシュボードで可視化します。ダッシュボードには、インスタンスのサイジング仕様に基づく主要パフォーマンス指標をモニタリングするパネルが含まれており、サイジングの判断の検証と最適化の機会の特定に役立ちます。 デプロイメントの手順、設定オプション、サンプルスクリプトについては、 GitHub リポジトリ をご覧ください。リポジトリには、Telegraf の設定から Grafana ダッシュボードの作成まで、セットアッププロセスを自動化する AWS CDK アプリケーションが含まれています。 サイジングの始め方 最初にデプロイメントを計画する際は、以下のアプローチを推奨します。 ベースライン要件を見積もる : 予想される書き込みレート（1 秒あたりのポイント数）とクエリの同時実行数（同時クエリ数）を計算します。データ量の増加や負荷のスパイクに備え、バッファを持たせてください。 開始するインスタンスサイズを選択する : 理想的な条件でインスタンスサイズを決定するための目安として、以下を参考にしてください。ニーズにおおよそ合致するインスタンスをデプロイし、パフォーマンスに応じて調整します。 書き込み（1 秒あたりの行数） 読み取り（1 秒あたりのクエリ数） インスタンスクラス ~35,000 ~40 db.influx.medium <100,000 ~140 db.influx.large ~120,000 ~290 db.influx.xlarge ~130,000 ~400 db.influx.2xlarge ~140,000 ~425 db.influx.4xlarge <200,000 <430 db.influx.8xlarge ~200,000 <430 db.influx.12xlarge ~210,000 ~430 db.influx.16xlarge ~230,000 ~430 db.influx.24xlarge 直近のデータモニタリング（3〜5 日間）に重点を置いたワークロードの場合は、db.influx.xlarge から始めてください。 書き込みスループットやクエリの同時実行数がより高い要件には、db.influx.2xlarge または db.influx.4xlarge を検討してください。 最大スループットが必要な場合は、db.influx.8xlarge や db.influx.24xlarge で評価してください。 履歴データの保持と分析が必要な場合は、適切なインスタンスサイズで Enterprise エディションを選択してください。 インスタンスサイズとワークロード特性に応じて、デプロイメント用の パラメータグループ を作成し設定します。 本番相当のデータでテストする : 本番環境のカーディナリティと時間範囲に一致するデータセットをロードし、実際のクエリパターンを実行してパフォーマンスを検証します。 モニタリングと調整 : CloudWatch メトリクスと System Metrics Plugin を使用して、CPU、メモリ、クエリレイテンシー、書き込みスループットを監視します。リソース使用率が常に高い場合やパフォーマンスが低下している場合は、スケールアップしてください。 本番レベルで稼働する正常なインスタンスは、CPU とメモリの使用率が平均で 40%〜70% の間であるべきです。 通常 40% を下回っており、ワークロードが安定している場合は、オーバープロビジョニングです。 70% の閾値を超えるスパイクがある場合は、最適化またはスケーリングを検討してください。クエリは書き込みよりも CPU 使用率に大きな影響を与えることに留意してください。 ワークロードの変化に応じて、短時間のダウンタイムを伴いますがインスタンスサイズのスケールアップまたはスケールダウンが可能です。控えめな構成から始め、注意深くモニタリングし、お客様固有のユースケースから得られる実際のパフォーマンスデータに基づいて調整してください。 まとめ Amazon Timestream for InfluxDB 3 のデプロイメントを効果的にサイジングするには、スループット要件、クエリパターン、コストの考慮事項のバランスを取る必要があります。Amazon Timestream for InfluxDB 3 がお客様のビジネスニーズにどのように応えるかを判断する出発点として、本記事を活用してください。ワークロードパターン、クエリの複雑さ、履歴データのニーズを分析することで、要件に合った適切な構成を選択できます。 今すぐ Amazon Timestream for InfluxDB のドキュメント にアクセスし、ビジネスが求めるパワー、柔軟性、スケーラビリティを備えた時系列ワークフローの構築を始めましょう。 著者について Victor Servin Victor は AWS の Amazon Timestream チームのシニアプロダクトマネージャーです。プロダクトレッドグロース戦略やスケーラブルなアーキテクチャでスタートアップを支援してきた長年の専門知識を持ち、データドリブンなアプローチで Timestream のような分析プロダクトの普及を推進しています。豊富な経験とカスタマーサクセスへの取り組みにより、お客様が効率的に目標を達成できるようサポートしています。 Forest Vey Forest は Improving 社のチームリードです。時系列およびサーバーレステクノロジーの経験を持ち、クラウド開発と組み込みシステムへの情熱が高まっています。ソフトウェア開発の学習以外の時間では、友人とのロッククライミングやハイキングを楽しんでいます。 Trevor Bonas Trevor は Improving 社のシニアソフトウェア開発者です。時系列データベースと ODBC ドライバーの開発経験があります。プライベートでは小説の執筆や、ゲーム開発にも取り組んでいます。 Fred Park Fred は Improving 社のシニアソフトウェア開発者で、時系列データベースと AI エージェントのオブザーバビリティを専門としています。VR やクラウドサービスから量子コンピューティングまで幅広いバックグラウンドを持ち、新しいテクノロジーに惹かれています。コーディング以外の時間は、ハイキングに出かけたり友人と音楽を作ったりしています。 本記事の翻訳はクラウドサポートエンジニアの平出が担当しました。