- データベース›
- Amazon Timestream›
- よくある質問
Amazon Timestream のよくある質問
全般
すべて開く時系列データは、Amazon EC2 インスタンスの株価、気温、CPU 使用率など、時間の経過とともに記録された一連のデータポイントです。時系列データでは、各データポイントはタイムスタンプ、1 つ以上の属性、および時間とともに変化するイベントで構成されます。このデータは、アプリケーションのパフォーマンスと状態に関する洞察を導き出し、異常を検出し、最適化の機会を特定するために使用されます。
たとえば、DevOps エンジニアはインフラストラクチャのパフォーマンス指標の変化を測定するデータを見たいと思うかもしれませんし、メーカーは施設全体の機器の温度の変化を測定する IoT センサーデータを追跡したいと思うかもしれません。オンラインマーケティング担当者は、時間の経過と共にユーザーがどのようにウェブサイトをナビゲートしたかをキャプチャするクリックストリームデータを分析したいと思うかもしれません。時系列データは複数のソースから非常に大量に生成されるため、重要なビジネス上の洞察を引き出すには、費用対効果の高い方法でほぼリアルタイムで保存および分析する必要があります。
Amazon Timestream は、市場で最も人気の高いオープンソース時系列データベースの 1 つであるフルマネージド型の InfluxDB と、スケールを考慮して構築されたサーバーレスの時系列データベースである LiveAnalytics を提供しています。
はい。Amazon Timestream の使用量に応じて Database Savings Plans を購入し、1 年間にわたって一定量の使用量を確約することで、コストを最大 20% 削減できます。 対象となる使用量に関する追加情報は、Database Savings Plans の料金ページでご確認いただけます。
Timestream の利用を開始するには、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、または SDK を使用できます。チュートリアルやその他の入門コンテンツを含む詳細については、開発者ガイドをご覧ください。
Amazon Timestream for InfluxDB は、ほぼリアルタイムの時系列クエリを必要とするユースケースや、InfluxDB の機能やオープンソース API が必要な場合に使用する必要があります。既存のタイムストリームエンジンである Amazon Timestream for LiveAnalytics は、1 分間に数十ギガバイトを超える時系列データを取り込み、テラバイトの時系列データに対して SQL クエリを数秒で実行する必要がある場合に使用する必要があります。
はい。この 2 つのエンジンは互いに補完し合い、低レイテンシーで時系列データを大規模に取り込むことができます。Timestream for InfluxDB にデータを取り込み、Telegraf プラグインを使用してデータを Timestream に送信し、SQL クエリを通じて履歴データを分析することができます。
Timestream for InfluxDB データを Timestream for LiveAnalytics に移行する場合、そのサービスの使用に対して、取り込み、ストレージ、クエリなどの公共料金が発生します。Timestream for LiveAnalytics と Timestream for InfluxDB の使用はオプションです。
Timestream for InfluxDB は、個別に使用することも、Timestream for LiveAnalytics ワークロードと一緒に使用することもできます。Timestream for InfluxDBは、応答時間が 1 桁ミリ秒のほぼリアルタイムのアプリケーションを対象としています。Timestream for LiveAnalytics は、ギガバイトのデータを数分で取り込み、数テラバイトのデータを数秒でクエリする必要があるユースケースに対応します。Timestream for InfluxDB と Timestream for LiveAnalytics をアプリケーションまたはダッシュボード内で組み合わせることができます。
いいえ。Timestream は、一連のディメンション属性とメジャーに基づいてテーブルのスキーマを動的に作成します。これにより、可用性に影響を与えることなくいつでも調整できる柔軟で段階的なスキーマ定義が可能になります。
データベースが作成されて使用可能になると、Timestream コンソールからエンドポイント情報を取得できます。あるいは、Describe API を使用してエンドポイント情報を取得することもできます (LiveAnalytics の Timestream を使用する場合は DescribeDatabase、InfluxDB の Timestream を使用する場合は DescribeDBInstances)。
Timestream の時系列データを視覚化し、マルチプラットフォームのオープンソース分析およびインタラクティブな視覚化ツールである Grafana を使用してアラートを作成できます。詳細およびサンプルアプリケーションについては、ドキュメントを参照してください。
Timestream とやり取りする AWS Lambda 関数を作成できます。詳細については、ドキュメントを参照してください。
オープンソースの Telegraf を使用して収集された時系列データを、Telegraf コネクタを使用して Timestream に直接送信できます。詳細については、ドキュメントを参照してください。
Amazon Virtual Private Cloud (Amazon VPC) から、VPC エンドポイントを使用して Timestream にアクセスできます。Amazon VPC エンドポイントは設定が簡単で、インターネットゲートウェイや NAT インスタンスを設定せずに、Timestream API への信頼できる接続を提供します。
AWS CloudFormation は、サービスやアプリケーションをすばやく確実にプロビジョニングする CloudFormation テンプレートを用意することで、プロビジョニングと管理作業をシンプルにするサービスです。CloudFormation は、データベースを作成するためのテンプレートを提供することにより、Timestream を包括的にサポートします (Timestream for LiveAnalytics と Timestream for InfluxDB の両方)。テンプレートは Timestream for InfluxDB の発表に合わせて最新のものになっており、Timestream のお客様には柔軟で使いやすいものになっています。
Timestream for LiveAnalytics
すべて開くAmazon Timestream for LiveAnalytics は、大規模なワークロード向けに構築された、高速でスケーラブルなサーバーレスの時系列データベースです。サーバーレスで、容量とパフォーマンスを調整するために自動的にスケールアップまたはスケールダウンされるため、基盤となるインフラストラクチャを管理する必要がありません。完全に分離されたアーキテクチャにより、1 日に何兆ものデータポイントを取り込み、数百万のクエリを実行できます。
Timestream for LiveAnalytics のアダプティブクエリエンジンを使用すると、場所を指定しなくても、最新データと履歴データに同時にアクセスして分析できます。時系列分析関数が組み込まれており、ほぼリアルタイムでトレンドやパターンを特定するのに役立ちます。
Timestream for LiveAnalytics は、時系列データを収集、保存、処理するように設計されています。サーバーレスアーキテクチャは、独立してスケーリング可能な完全に分離されたデータインジェスト、ストレージ、クエリ処理サービスをサポートし、アプリケーションのニーズに合わせて事実上無制限のスケールを実現します。Timestream テーブルのスキーマは、テーブル作成時にスキーマを事前に定義するのではなく、受信する時系列データの属性に基づいて動的に作成されるため、柔軟で段階的なスキーマ定義が可能になります。
データストレージの場合、Timestream for LiveAnalytics はデータを時間と属性ごとに分割し、専用のインデックスを使用してデータアクセスを高速化します。測定値名や選択したパーティション化キーなどのデータの属性は、データを効果的に分割して効率的に取得する上で重要な役割を果たします。さらに、Timestream for LiveAnalytics は、最近のデータ用のインメモリストア、履歴データ用の磁気ストアを提供し、一定の経過時間に達したときにデータをメモリストアから磁気ストアに自動的に移動する設定可能なルールをサポートすることで、データライフサイクル管理を自動化します。
また、Timestream for LiveAnalytics は、専用の適応型クエリエンジンを介してデータアクセスを簡素化します。このエンジンは、データの場所を指定しなくても、ストレージ階層全体でデータにシームレスにアクセスして組み合わせることができるため、SQL を使用してデータから迅速かつ簡単に洞察を引き出すことができます。最後に、Timestream は、お好みのデータ収集、視覚化、分析、機械学習 (ML) サービスとシームレスに連携するため、時系列ソリューションに Timestream を簡単に組み込むことができます。
Timestream for LiveAnalytics は、99.99% の可用性を実現します。詳細については、サービスレベル契約 (SLA) を参照してください。
Timestream for LiveAnalytics では、使用した分のみの料金が発生します。書き込み、格納されたデータ、クエリによってスキャンされたデータに対して個別に請求されます。Timestream では、使用量に応じて書き込み、ストレージ、クエリのキャパシティーが自動的にスケーリングされます。テーブルごとにデータ保持ポリシーを設定したり、インメモリストアまたはマグネティックストアにデータを格納することを選択したりできます。詳細な価格については、料金ページをご覧ください。
はい。Timestream for LiveAnalytics では、すべての新規アカウントに 1 か月間の無料トライアルを提供しています。無料トライアルの使用量の上限は、50 GB のインジェスト、100 GB のマグネティックストレージ、750 GB 時間のメモリストレージ、750 GB のスキャンデータです。
無料トライアルの対象範囲を超える使用分については、Timestream for LiveAnalytics の標準料金で請求されます。その他の詳細については、料金ページをご覧ください。
現在のリージョンの可用性については、料金ページをご覧ください。
Timestream for LiveAnalytics では、データインジェストのレイテンシーがほぼリアルタイムで表示されます。Timestream for LiveAnalytics の組み込みメモリストアは迅速なポイントインタイムクエリに最適化されており、マグネティックストアは高速な分析クエリをサポートするように最適化されています。Timestream for LiveAnalytics では、メモリストアにある数十ギガバイトの時系列データをミリ秒以内に分析するクエリと、磁気ストアからのテラバイトの時系列データを数秒以内に分析する分析クエリを実行できます。スケジュールされたクエリは、頻繁にアクセスされる運用ダッシュボード、ビジネスレポート、アプリケーション、およびデバイス監視システムを強化するために使用される集計、ロールアップ、およびその他のリアルタイム分析を計算して保存することにより、クエリのパフォーマンスをさらに向上させます。
1 つのテーブルにエクサバイトのデータを格納できます。時間の経過とともにデータが増加するにつれて、Timestream for LiveAnalytics は分散アーキテクチャと大量の並列処理を使用して、クエリのレイテンシーをほとんど変化させずにますます大量のデータを処理します。
Timestream サーバーレスアーキテクチャは、独立して拡張できる完全に分離されたデータインジェスト、ストレージ、およびクエリ処理システムをサポートします。Timestream for LiveAnalyticsは、取り込み、ストレージ、クエリレートに関するアプリケーション要件を継続的に監視し、アプリケーションのダウンタイムなしで即座にスケーリングします。
現在の制限とクォータについては、ドキュメントを参照してください。
接続されたデバイス、IT システム、産業機器から時系列データを収集し、Timestream for LiveAnalytics に書き込むことができます。AWS SDK を使用してアプリケーションから直接、または AWS IoT Core、Amazon Managed Service for Apache Flink、Telegraf などのデータ収集サービスから、Timestream for LiveAnalytics にデータを送信できます。詳細については、ドキュメントをご覧ください。
遅れて到着したデータとは、タイムスタンプが過去であり、メモリストアの保持境界外にあるデータです。将来のデータとは、将来のタイムスタンプを持つデータです。Timestream では、両方の種類を保存してアクセスできます。
到着が遅れたデータを保存するには、データを Timestream for LiveAnalytics に書き込むだけで、サービスはデータのタイムスタンプとメモリストアとマグネティックストアに設定されたデータ保持期間に基づいて、データをメモリストアに書き込むかマグネティックストアに書き込むかを自動的に判断します。15 分を超える将来のデータを保存するには、データを複数のメジャー レコードとしてモデル化し、将来のタイムスタンプをレコード内のメジャーとして表します。
AWS IoT Core ルールアクションを使用して、IoT デバイスからデータを収集し、そのデータを Amazon Timestream に保存できます。詳細については、ドキュメントを参照してください。
Apache Flink を使用すると、時系列データを Amazon Kinesis から Timestream for LiveAnalytics に直接転送できます。詳細については、ドキュメントを参照してください。
Apache Flink を使用すると、時系列データを Amazon Managed Streaming for Apache Kafka (Amazon MSK) から直接 Timestream for LiveAnalytics に送信できます。詳細については、ドキュメントを参照してください。
Timestream は、時系列データをパーティションに整理して格納します。データの分割は、データの属性に基づいてサービスによって決定されます。timestamp や measure_name などの属性や顧客定義のパーティションキーは、パーティションを決定する上で重要な役割を果たします。詳細については、Werner Vogels のブログを参照してください。特定のニーズに合わせてクエリのパフォーマンスを最適化したい場合は、顧客定義のパーティションキーを使用することをお勧めします。Timestream を使用すると、設定した保存期間に達したデータをメモリストアから磁気ストアに自動的に移動するようにデータ保持ポリシーを設定するだけで、データライフサイクル管理を自動化できます。
Amazon Timestream のメモリストアは、受信する時系列データを受け入れて重複排除する、書き込みに最適化されたストアです。メモリストアは、レイテンシーの影響を受けやすいポイントインタイムクエリにも最適化されています。
Timestream for LiveAnalytics マグネティックストアは、数百テラバイトのデータをスキャンできる高速な分析クエリを実行するために構築された、読み取りに最適化されたストアです。マグネティックストアは、数百テラバイトのデータをスキャンする高速分析クエリにも最適化されています。
メモリストアとマグネティックストアの両方に保持期間を設定できます。デフォルトはそれぞれ 12 時間と 10 年です。レコード内のタイムスタンプによって決まるデータの経過時間が、設定されているメモリストアの保持期間を超えると、Timestream for LiveAnalytics はデータを自動的にマグネティックストアに階層化します。同様に、データの保存期間が設定されたマグネティックストアの保持期間を超えると、サービスはデータを自動的に削除します。
Timestream for LiveAnalytics は、メモリとマグネティックストアのデータを 1 つのリージョン内のさまざまなアベイラビリティーゾーンに自動的に複製することで、データの耐久性を確保します。書き込みリクエストの完了を確認する前に、すべてのデータがディスクに書き込まれます。
SQL を使用して、Timestream に保存されている時系列データをクエリできます。時系列分析関数を使用して、SQL を使用した補間、リグレッション、平滑化を実行することもできます。詳細については、ドキュメントをご覧ください。Timestream のアダプティブクエリエンジンにより、1 つの SQL ステートメントを使用してストレージ階層全体のデータにアクセスできます。データの場所を指定しなくても、ストレージ階層全体のデータに透過的にアクセスして結合します。
Timestream for LiveAnalytics のスケジュールされたクエリは、頻繁にアクセスされる運用ダッシュボード、ビジネスレポート、アプリケーション、およびデバイス監視システムを強化するために使用される、集計、ロールアップ、およびその他のリアルタイム分析を計算して保存するためのサーバーレスでスケーラブルなフルマネージドソリューションを提供します。
スケジュールされたクエリでは、受信データの集計、ロールアップ、その他のリアルタイム分析を計算するリアルタイム分析クエリを定義するだけで、Timestream はこれらのクエリを定期的かつ自動的に実行し、クエリ結果を別のテーブルに確実に書き込みます。その後、ダッシュボード、レポート、アプリケーション、および監視システムに、受信時系列データを含むかなり大きなソーステーブルをクエリする代わりに、単純に対象テーブルをクエリするように指示できます。これにより、ターゲットテーブルに含まれるデータがソーステーブルよりもはるかに少ないため、パフォーマンスとコストが大幅に削減され、データアクセスとストレージがより高速で安価になります。
Amazon QuickSight と Grafana を使用して、Timestream for LiveAnalytics の時系列データを視覚化および分析できます。また、機械学習のニーズに合わせて QuickSight を使用することもできます。
QuickSight を使用すると、時系列データ用の豊富でインタラクティブなダッシュボードを作成できます。詳細については、ドキュメントをご覧ください。
Amazon SageMaker ノートブックを使用して ML モデルを Timestream for LiveAnalytics と統合することができます。詳細については、ドキュメントをご覧ください。
データは、保存中でも転送中でも常に暗号化されます。Timestream for LiveAnalytics では、マグネティックストア内のデータを暗号化するための AWS Key Management Service (AWS KMS) のカスタマー管理キーを指定できます。
Timestream for LiveAnalytics は、ISO (9001、27001、27017、27018)、PCI DSS、FedRAMP (モデレート)、および Health Information Trust (HITRUST) Alliance Common Security Framework (CSF) に準拠しています。また、HIPAA にも準拠しており、AWS SOC 1、SOC 2、および SOC 3 レポートの対象となります。
Timestream リソースには、オンデマンドバックアップとスケジュールバックアップの 2 つのバックアップオプションがあります。オンデマンドバックアップは、Timestream コンソールまたは AWS Backup を使用して開始できる、1 回限りのバックアップです。オンデマンドバックアップは、テーブルに変更を加える前にバックアップを作成して、変更を元に戻す必要がある場合に役立ちます。 定期バックアップは、AWS Backup ポリシーを使用して、必要な頻度 (12 時間、1 日、1 週間など) で設定できる定期的なバックアップです。定期バックアップは、データ保護の目標を達成するために継続的なバックアップを作成したい場合に役立ちます。
テーブルの最初のバックアップ (オンデマンドまたは定期バックアップ) はフルバックアップであり、同じテーブルの後続のバックアップはすべてインクリメンタルで、前回のバックアップ以降に変更されたデータのみがコピーされます。
バックアップとリストアは、選択したテーブルのバックアップストレージサイズに基づいて、GB-月単位で課金されます。料金は AWS 請求書のバックアップの下に表示され、バックアップストレージ、データ転送、復元、早期削除の費用が含まれます。バックアップは本質的にインクリメンタルであるため、テーブルの後続バックアップのストレージサイズは、前回のバックアップ以降に変更されたデータ量のサイズです。詳細については、AWS Backup の料金表を参照してください。
開始するには、AWS Backup を有効にして Timestream for LiveAnalytics リソースを保護する必要があります (これは 1 回限りのアクションです)。有効になったら、AWS マネジメントコンソールに移動するか、AWS Backup の CLI または SDK を使用してデータのオンデマンドバックアップまたは定期バックアップを作成し、それらのバックアップをアカウントやリージョン間でコピーします。 データ保護のニーズに基づいてバックアップライフサイクル管理を設定できます。詳細については、「バックアップの作成」ドキュメントを参照してください。
AWS マネジメントコンソール、または AWS Backup CLI または SDK を使用して、Timestream for LiveAnalytics テーブルを復元できます。復元するリソースの回復ポイント ID を選択し、復元プロセスを開始するために必要な入力 (宛先データベース名、新しいテーブル名、保存プロパティなど) を指定します。復元が成功すると、データにアクセスできます。テーブルの最新のインクリメンタルバックアップを復元しようとすると、テーブルデータ全体が復元されます。詳細については、ドキュメントを参照してください。
Timestream for InfluxDB
すべて開くAmazon Timestream for InfluxDB は、アプリケーション開発者や DevOps チームがオープンソース API を使用してリアルタイム時系列アプリケーション用の InfluxDB データベースを AWS 上で簡単に実行できるようにする新しい時系列データベースエンジンです。Timestream for InfluxDB を使用すると、1 桁ミリ秒のクエリ応答でクエリに答えることができる時系列ワークロードを簡単にセットアップ、操作、スケールできます。
Timestream for LiveAnalytics は、InfluxDB のオープンソース 2.7 バージョンをサポートしています。
InfluxDB を自己管理している場合、オープンソースの時系列 API を使用したい場合、または 1 桁のミリ秒単位のクエリ応答を必要とするリアルタイム時系列アプリケーションを構築している場合は、Timestream for InfluxDB を使用する必要があります。Timestream for InfluxDB を使用すると、オープンソースの API と、時系列データを収集するためのさまざまなオープンソースの Telegraf エージェントのメリットを享受できます。InfluxDB のインストール、アップグレード、ストレージ、高可用性のためのレプリケーション、バックアップなど、複雑で時間のかかるタスクを管理する必要はありません。
Timestream for InfluxDB は、マルチ AZ 設定でデプロイした場合 99.9% の可用性を、シングル AZ 設定でデプロイした場合には 99.5% の可用性という SLA を提供します。
Timestream for InfluxDB は、ほぼリアルタイムの時系列ユースケース向けに構築されています。インスタンスの設定とワークロードの特性にもよりますが、書き込みから読み取りまでのレイテンシーは約 1 秒で、クエリレイテンシーは 1 桁ミリ秒です。
自己管理型の InfluxDB インスタンスから Timestream for InfluxDB に移行するには、既存の InfluxDB データベースから Timestream for InfluxDB インスタンスにバックアップを復元するだけで、数分のダウンタイムが発生します。オープンソースの Telegraf エージェントなどのデータ収集エージェントを、Timestream for InfluxDB が管理する InfluxDB エンドポイントをターゲットにするように再構成できます。InfluxDB UI、セルフホスト Grafana、Amazon Managed Grafana などのダッシュボードテクノロジーは、他のコードを変更することなく Timestream for InfluxDB エンドポイントを使用するように設定することで引き続き機能します。
Timestream for LiveAnalytics から Timestream for InfluxDB に移行するには、Timestream for LiveAnalytics から Amazon S3 にデータをエクスポートし、エクスポートされた CSV ファイルに必要な変更を加え、それを Timestream for InfluxDBにロードできます。
DB インスタンスを、お客様が指定したコンピューティングおよびストレージリソースを備えた、クラウド内のデータベース環境であると考えることができます。AWS マネジメントコンソール、Timestream for InfluxDB API、AWS CLI を使用して、DB インスタンスの作成と削除、DB インスタンスのインフラストラクチャ属性の定義と調整、アクセスとセキュリティの制御を行うことができます。1 つ以上の DB インスタンスを実行でき、各 DB インスタンスは、ワークロードの特性とインスタンス設定に応じて 1 つ以上のデータベース (バケット) または組織をサポートできます。
DB インスタンスは、AWS マネジメントコンソール、Timestream for InfluxDB API、または AWS CLI を使用して簡単に作成できます。AWS マネジメントコンソールを使用して DB インスタンスを起動するには、[InfluxDB データベース] を選択し、ダッシュボードの [InfluxDB データベースを作成] ボタンを選択します。そこから、インスタンスタイプ、ストレージタイプと量、プライマリユーザー認証情報などを含む DB インスタンスのパラメータを指定できます。
代わりに、CreateDBInstance API や create-db-instance コマンドを使用して、DB インスタンスを作成することも可能です。
DB インスタンスが使用可能になると、AWS マネジメントコンソールの DB インスタンスの説明、GetDBInstance API、または get-db-instance コマンドを通じてそのエンドポイントを取得できます。このエンドポイントとアクセストークンを使用すると、InfluxDB API を使用して書き込みおよび読み取りリクエストを送信したり、お気に入りのデータベースツールやプログラミング言語を使用してエンジンを管理したりできます。同じエンドポイントを使用してブラウザから InfluxDB UI にアクセスすることもできます。実行中の DB インスタンスへのネットワーク リクエストを許可するには、アクセスを承認するか、パブリック IP アクセスを有効にする必要があります。
デフォルトでは、合計で最大 40 の Timestream for InfluxDB インスタンスを使用できます。
使用料金は従量課金制となっており、最低料金やセットアップ料金はありません。以下の内容に基づき、請求が行われます。
- DB インスタンス時間: 消費された DB インスタンスのクラス (例: db.influx.large および db.influx.4xlarge) によって異なります。 DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。
- ストレージ (/GB-月): DB インスタンスに対してプロビジョニングしたストレージ容量。プロビジョニングしたストレージ容量を当月内にスケールした場合、請求額は按分されます。
- データ転送: DB インスタンスのインターネット経由のデータ転送 (IN および OUT)。
Timestream for InfluxDB の料金情報については、料金ページをご覧ください。
DB インスタンスが利用可能になるとすぐに、DB インスタンスへの請求が始まります。削除またはインスタンス障害の際に発生する DB インスタンスの停止まで、請求が続きます。
利用可能な状態で DB インスタンスが動作している各時間に対して、DB インスタンス時間が請求されます。これ以上 DB インスタンスへの課金を望まない場合は、追加のインスタンス時間に対して請求されないよう、DB インスタンスを停止するか、終了する必要があります。 DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。
データベースインスタンスが停止している間、プロビジョニングされたストレージに対して課金されますが、DB インスタンス時間は課金されません。
お客様の DB インスタンスがマルチ AZ デプロイとなるよう指定する場合、Timestream for InfluxDB 料金ページに記載されたマルチ AZ 料金設定に応じて料金が請求されます。マルチ AZ 請求は以下に基づいています。
- マルチ AZ DB インスタンス時間: 消費された DB インスタンスのクラス (例: db.influx.large および db.influx.4xlarge) によって異なります。単一のアベイラビリティーゾーンにおける標準的なデプロイと同様に、DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の消費された DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。特定の 1 時間以内に、標準とマルチ AZ 間で DB インスタンスデプロイを交換する場合、その時間に対して該当する両方の料金が課金されることになります。
- プロビジョニングされたストレージ (マルチ AZ DB インスタンス用) – 特定の 1 時間以内に標準とマルチ AZ 間でお客様の配置を交換する場合、その時間に該当するストレージ料金のうち高い方の金額が課金されます。
- データ転送: お客様のプライマリおよびスタンバイ間でデータをレプリケーションする際に発生するデータ転送に対しては課金されません。DB インスタンスの受信および送信におけるインターネットのデータ転送は、標準デプロイと同様に課金されます。
別途記載がない限り、表示される料金には付加価値税や売上税など、一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS のサービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。
- Timestream for InfluxDB リードレプリカクラスターの請求額は、Timestream for InfluxDB 料金ページに記載されている価格に従って、クラスター内のインスタンスごとに計算されます。請求構造は、次の 4 つの主要コンポーネントで構成されています。
クラスターノード時間は、選択したインスタンスクラス (db.influx.large や db.influx.4xlarge など) に基づいて課金されます。スタートアップ、起動、インスタンスクラスの変更など、請求対象となるステータスの変更が発生すると、1 秒単位で最低料金が 10 分単位で請求されます。1 時間以内にクラスタータイプを切り替えた場合は、その期間中に両方の適用料金が請求されます。 - ストレージについては、プロビジョニングされた容量に基づいて請求されます。1 時間以内にデプロイタイプ (クラスター、スタンダード、マルチ AZ DB) 間の変換を行う場合、その時間に適用されるストレージ料金のうち高い方が適用されます。
- データ転送に関しては、プライマリインスタンスとレプリカインスタンス間のデータレプリケーションには料金は発生しません。ただし、DB クラスターの送受信インターネットデータ転送には、標準デプロイと同じ料金が適用されます。
- リードレプリカ機能は、InfluxData が構築、販売するライセンス付きアドオンを通じて提供され、AWS Marketplace を通じて有効化されます。このライセンスは従量課金制モデルで動作し、設定されたインスタンスクラス内の vCPU の数に応じてインスタンス時間に基づいて課金されます。
最初の DB インスタンスのクラスとストレージ容量を選択するには、アプリケーションでのコンピューティング、メモリ、およびストレージのニーズを評価する必要があります。使用可能な DB インスタンスクラスについては、『Timestream for InfluxDB ユーザーガイド』を参照してください。
Timestream for InfluxDB IOPS Included Storage とは、高速かつ予測可能な一貫した I/O パフォーマンスを提供するよう設計された SSD ベースのストレージオプションです。Timestream for InfluxDB IOPS Included Storage では、小規模なワークロードから大規模で高性能に最適化されたワークロードまで、3 つの階層を選択できます。階層に割り当てられるボリュームサイズは、ニーズに合ったものだけを指定してください。Timestream for InfluxDB IOPS Included Storage は、I/O 集約型のトランザクション (OLTP) データベースワークロード向けに最適化されています。詳細については、Timestream for InfluxDB ユーザーガイドを参照してください。
ワークロードに最も適したストレージタイプを選択してください。
- 高パフォーマンス OLTP ワークロード: InfluxDB IOPS ストレージの Timestream。
Timestream for InfluxDB では、デフォルトでインスタンスクラスとストレージ容量が考慮され、DB インスタンスに最適の設定パラメータが選択されます。ただし、変更したい場合は、AWS マネジメントコンソール、Timestream for InfluxDB API、または AWS CLI を使用して変更できます。推奨値からの設定パラメータの変更は、性能の低下からシステムクラッシュまで、予期しない影響を生じる場合があり、これらのリスクを想定できる上級ユーザーのみが行えることにご注意ください。
起動時に、ユーザーが変更できる限定されたパラメータセットが提供されます。これには、flux-log-enabled、log-level、metrics-disable、no-tasks、query-concurrency、query-queue-size、および tracing-type が含まれます。このリストは、お客様の要件によっては、時間が経つにつれて増加する可能性があります。
DB パラメータグループは、1 つまたは複数の DB インスタンスに適用できるエンジン設定値のコンテナとして機能します。DB パラメータのグループを指定せずに DB インスタンスを作成する場合、デフォルトの DB パラメータグループが使用されます。このデフォルトグループには、実行している DB インスタンス用に最適化されたエンジンデフォルトと Timestream for InfluxDB システムデフォルトが含まれています。
しかし、カスタム指定のエンジン設定値で DB インスタンスを実行したい場合、新しい DB パラメータグループを作成し、必要なパラメータを修正し、新しい DB パラメータグループを使用するため DB インスタンスを修正するだけで十分です。
マルチ AZ デプロイとして実行するように DB インスタンスを作成または変更すると、Timestream for InfluxDB は、同期スタンバイレプリカを別のアベイラビリティーゾーンで自動的にプロビジョニングおよび維持します。DB インスタンスに対する更新は、アベイラビリティーゾーン間でスタンバイに同期的にレプリケートされ、両方の同期を維持し、DB インスタンスの障害から最新のデータベース更新を保護します。
特定の種類の計画的なメンテナンスの期間中や、DB インスタンスの障害もしくはアベイラビリティーゾーンの障害といった予期せぬイベントが発生した際には、Timestream for InfluxDB はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格したら直ちにデータベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないため、アプリケーションによるデータベースオペレーションは、管理者による手動での介入なしで再開できます。
マルチ AZ デプロイのレプリケーションは透過的です。スタンバイと直接やり取りすることはできません。また、スタンバイを読み取りトラフィックの処理に使用することはできません。
アベイラビリティゾーンとは、別のアベイラビリティゾーンで発生した障害から隔離するために作られたリージョン内の場所です。各アベイラビリティーゾーンは、その独自の、物理的にはっきりと独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。発電機や冷却装置などの障害対策用装置がアベイラビリティーゾーン間で共有されることはありません。さらに、これらは物理的にそれぞれ別々の場所にあるため、火災、竜巻、または洪水などの極めてまれな災害が発生しても、影響を受けるのは単一のアベイラビリティーゾーンのみです。同一リージョンにある Availability Zone は、待ち時間が短いネットワーク接続を提供します。
DB インスタンスをマルチ AZ 配置として実行する場合、プライマリはデータベースに読み込みと書き込みの機能を提供します。さらに、Timestream for InfluxDB は、背後で「スタンバイ」を設定して管理します。これはプライマリの最新レプリカになります。スタンバイはフェイルオーバーのシナリオで昇格されます。フェイルオーバー後、スタンバイはプライマリとなり、お客様のデータベースオペレーションを受け付けるようになります。昇格前には、どの時点においても、スタンバイと直接やりとり (例: 読み込みオペレーション) することはありません。
DB インスタンスをマルチ AZ 配置として実行することの主な利点は、データベースの耐久性と可用性が向上することです。マルチ AZ 配置によって高められる可用性と耐障害性は、本番環境に最適です。
DB インスタンスをマルチ AZ デプロイとして実行すると、万一 DB インスタンスコンポーネントに障害が発生した場合や、特定のアベイラビリティーゾーンで可用性が失われた場合でも、データの安全が守られます。
例えば、プライマリ上のストレージボリュームが障害を受ける場合、Timestream for InfluxDB はスタンバイに対して自動的にフェイルオーバーを開始し、お客様のデータベース更新はそのスタンバイですべて完全な状態に保たれます。これにより、ユーザーが開始する復元操作が必要となり、最新の復元可能時間 (通常は過去 5 分以内) 以降に発生した更新は利用できなくなる単一のアベイラビリティーゾーンでの標準的なデプロイに比べて、データの耐久性が向上します。
データベースの可用性を向上できることも、DB インスタンスをマルチ AZ 配置として運用する場合の利点の 1 つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生した場合、可用性が影響を受けるのは、自動フェイルオーバーが完了するまでの間のみです。マルチ AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。DB インスタンスをマルチ AZ デプロイとして実行することによる暗黙の利点は他にもあります。それは、DB インスタンスのフェイルオーバーが自動で行われ、手動管理が必要ないことです。
実行される同期的データレプリケーションの結果として、単一のアベイラビリティーゾーンにおける標準 DB インスタンスの配置と比較した場合、レイテンシーが増加する可能性があります。
いいえ。マルチ AZ のスタンバイは、読み込みリクエストに対応していません。マルチ AZ 配置は、読み込み機能の拡張による恩恵よりも、データベースの可用性と堅牢性の強化を提供するよう設計されています。そのため、この機能はプライマリとスタンバイの間で同期するレプリケーションを行います。当社の実装では、プライマリとスタンバイが常に同期するようにしてありますが、スタンバイを読み込みまたは書き込みオペレーションのために使用する機能は除外しています。
マルチ AZ DB インスタンスデプロイを作成するには、AWS マネジメントコンソールで DB インスタンスを起動するときに、マルチ AZ デプロイスタンバイインスタンスの作成オプションを選択するだけです。代わりに、Timestream for InfluxDB API を使用している場合は、CreateDBInstance API を呼び出してマルチ AZ パラメータの値を True に設定することもできます。
既存のインスタンスのいずれかを変更して、デプロイタイプを マルチ AZ に設定することもできます。
Timestream for InfluxDB では、マルチ AZ デプロイにおける一般的な障害シナリオが検出され自動的に復旧されるので、管理者の介入は不要でデータベース操作を可能な限りすみやかに再開できます。Timestream for InfluxDB は、以下のいずれかの場合に自動的にフェイルオーバーを実行します。
- プライマリ利用可能ゾーンの可用性損失
- プライマリに対するネットワーク接続の喪失
- プライマリ上でのコンピューティングユニット障害
- プライマリへのストレージ不良
なお、Timestream for InfluxDB マルチ AZ デプロイでの自動フェイルオーバーは、データベースオペレーションにおけるエラー (長時間実行クエリ、デッドロック、データベース破損など) の発生に対しては行われません。
フェイルオーバーは Timestream for InfluxDB によって自動的に処理されるため、管理者の介入なく、可能な限り迅速にデータベース操作を再開することができます。フェイルオーバーの際には、Timestream for InfluxDB は単純に DB インスタンスの正規名レコード (CNAME) を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。ベストプラクティスに従い、アプリケーションレイヤーでデータベース接続のリトライを実施することを推奨いたします。
フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ～ 2 分以内に完了します。フェイルオーバー時間は、コミットされていない大規模なトランザクションを回復する必要があるかどうか、インデックスのサイズ、その他の要因によっても影響を受ける可能性があります。最良の結果を得るには、マルチ AZ では十分な大きさのインスタンスタイプを使用することをお勧めします。AWS では、高速で予測可能で一貫したスループットパフォーマンスを実現するために、マルチ AZ インスタンスで Timestream for InfluxDB IOPS Included Storage を使用することも推奨しています。
Timestream for InfluxDB は、さまざまな障害状態のときにユーザーが介入しなくても、自動的にフェイルオーバーを行います。現時点では、Timestream for InfluxDB DB インスタンスの強制フェイルオーバーを手動で開始することはできません。
マルチ AZ 配置を使用するには、Multi-AZ パラメータを true に設定するだけです。スタンバイ、同期的レプリケーションおよびフェイルオーバーの作成は、すべて自動的に処理されます。つまり、スタンバイが配置されているアベイラビリティーゾーンを選択したり、利用可能なスタンバイ数を変更したりすることはできません (Timestream for InfluxDB は、DB インスタンスプライマリごとに 1 つの専用スタンバイを設定します)。また、スタンバイは、データベースの読み取りアクティビティを許可するよう設定できません。
はい、スタンバイは、DB インスタンスプライマリと同一のリージョンの異なるアベイラビリティーゾーンに自動的にプロビジョニングされます。
はい。AWS マネジメントコンソールまたは GetDBInstance API を使用することで、現在のプライマリの場所を確認できます。
アベイラビリティーゾーンは、同一リージョンの別のアベイラビリティーゾーンに対して低レイテンシーでネットワーク接続できるように設計されています。さらに、1 つのアベイラビリティーゾーンでのサービス障害時にお客様のアプリケーションが回復力を持つように、複数のアベイラビリティーゾーン全体で冗長性を持つアプリケーションや他の AWS リソースの設計も検討できます。マルチ AZ 配置は、お客様サイドでの管理作業なく、データベース層に対するこのニーズを解決します。
Timestream for InfluxDB リードレプリカクラスターは、データベースの可用性と読み取りスケーラビリティを向上させます。クラスターを作成すると、Timestream for InfluxDB は、別のアベイラビリティーゾーンに少なくとも 1 つの非同期読み取り可能なレプリカを自動的にプロビジョニングして維持します。プライマリノードの更新はこれらのリードレプリカに非同期でレプリケートされるため、クエリのワークロードを複数のノードに分散できます。
クラスターは、計画的なメンテナンス中、またはまれにノードまたはアベイラビリティーゾーンに障害が発生した場合の自動フェイルオーバーをサポートします。フェイルオーバーが発生しても、ライターのエンドポイントとリーダーのエンドポイントが同じ名前レコードを保持するため、アプリケーションは手動による操作なしで動作を継続できます。ただし、復旧期間中、障害が発生したノードを復元してリードレプリカとして復元する間、レプリカノードエンドポイントを読み取りに使用するアプリケーションは一時的に利用できなくなることに注意してください。
リードレプリカクラスターでは、プライマリノードがデータベースのすべての書き込み、読み取りを処理し、エンジン固有の構成と管理機能を管理します。これに加えて、Timestream for InfluxDB は、プライマリノードで常に最新の状態に保たれるリードレプリカを自動的にプロビジョニングして維持します。リードレプリカには 2 つの主な目的があります。1 つは、追加の読み取りリクエストを受け付けることで読み取り容量を拡張すること、もう 1 つはフェイルオーバーシナリオ中にプライマリに昇格できることです。フェイルオーバーイベント中にリードレプリカがプライマリに昇格すると、リードレプリカがすべてのデータベース操作を引き継ぎます。以前に障害が発生したノードが再び動作可能になると、リードレプリカとしてクラスターに再参加し、クラスターの回復力を維持します。
リードレプリカクラスターには、スケーラビリティの強化、可用性の向上、ワークロードの最適化という 3 つの主な利点があります。スケーラビリティの向上は、読み取りワークロードを複数のクラスターノードに分散できることによるもので、読み取り要件が書き込み操作を大幅に上回るアプリケーションにとって特に役立ちます。
フェイルオーバーを有効にして構成すると、リードレプリカクラスターはより高速なフェイルオーバー機能により高い可用性を提供します。クラスター内のすべてのノードはアクティブなままなので、ノードのスタートアップを待たずにレプリカをプライマリに昇格させることができ、フェイルオーバーシナリオ中のダウンタイムを最小限に抑えることができます。
さらに、リードレプリカクラスターは効率的なワークロード管理を可能にします。プライマリノードは、通常はリアルタイムのダッシュボード、アラーム、通知に使用されるシンプルで高速なクエリの処理専用にすると同時に、より複雑な分析クエリをリードレプリカに送ることができます。この分離により、さまざまなタイプのワークロードで最適なパフォーマンスが保証されます。
レプリケータープロセスによるパフォーマンスへの影響はごくわずかで、CPU やメモリの消費への影響は最小限に抑えられています。ただし、レプリケーションラグ (プライマリでレコードが受け入れられてからリードレプリカで使用できるようになるまでの時間) は、レプリカノードの負荷レベルによって異なる場合があることに注意してください。
Timestream for InfluxDB は、リードレプリカの同期状態を監視するのに役立つ「ReplicaLag」と呼ばれる CloudWatch メトリクスを公開しています。このメトリックスはミリ秒単位で測定され、レプリカがプライマリノードからどれだけ遅れているかを追跡します。レプリケーションのレイテンシーはデータベースの負荷レベルによって影響を受ける可能性があるため、お客様はこのメトリクスを積極的に監視して、リードレプリカがユースケースで許容できる同期レベルを維持していることを確認することをお勧めします。
Timestream for InfluxDB のリードレプリカクラスターを設定するには、まず AWS マネジメントコンソールにサインインして Amazon Timestream コンソールに移動します。InfluxDB データベースセクションから「InfluxDB データベースを作成」を選択します。デプロイ設定を設定するときは、「リードレプリカを使用する DB クラスター」を選択します。」 AWS Marketplace を通じてサブスクリプションをアクティベートする必要があります。これには、AWSMarketplaceManageSubscriptions または AWSMarketplaceFullAccess 権限のいずれかが必要です。サブスクリプションを確認したら、基本構成の詳細を入力し、クラスター内のすべてのノードに適用される適切なノードとストレージクラスを選択します。
いいえ。リードレプリカクラスターでは、一度に書き込み操作を処理できるプライマリノードは 1 つだけです。プライマリノードはすべての書き込み要求を処理すると同時に、データベースの読み取り、エンジン固有の構成、および管理機能も管理します。リードレプリカはこのプライマリノードで最新の状態に保たれ、リードリクエストのみを受け入れることができます。フェイルオーバーのシナリオではリードレプリカをプライマリに昇格させることができますが、クラスターアーキテクチャではデータ整合性を確保するためにシングルライターモデルを維持しています。
リードレプリカクラスターでは、クラスターの作成または変更中にフェイルオーバー機能を有効または無効にできます。有効にすると、レプリカ、レプリケーション、およびフェイルオーバープロセスの管理が Timestream for InfluxDB によって自動的に処理されます。レプリカに特定のアベイラビリティーゾーンを選択することはできません。Timestream for InfluxDB は、クラスターごとに少なくとも 1 つのリードレプリカを維持します。リードレプリカは、ワークロードの分散に役立つ読み取りリクエストを積極的に受け入れます。
Timestream for InfluxDB は、リードレプリカクラスターデプロイの一般的な障害シナリオを検出して自動的に回復するため、管理者の介入なしにデータベース操作を迅速に再開できます。以下のいずれかの場合、システムは自動的にリードレプリカへのフェイルオーバーを実行します。
- プライマリノードのアベイラビリティーゾーンの可用性の喪失
- プライマリノードに対するネットワーク接続の喪失
- プライマリノードでのコンピュートユニットの障害
- プライマリノードでのストレージ障害
注: Timestream for InfluxDB リードレプリカクラスターは、実行時間の長いクエリ、デッドロック、データベース破損エラーなどのデータベース操作に応答しても自動的にフェイルオーバーしません。自動フェイルオーバーが発生するのは、セットアップ時またはクラスターの変更時にリードレプリカクラスターに対してこの機能を特別に有効にした場合のみであることに注意してください。
リードレプリカクラスターのフェイルオーバーは、この機能が有効になっていると Timestream for InfluxDB によって自動的に処理されるため、管理者の介入なしにデータベース操作を迅速に再開できます。フェイルオーバー中、Timestream for InfluxDB はデータベースの正規名 (CNAME) レコードを更新して読み取りレプリカを指すようにし、その後、読み取りレプリカが新しいプライマリに昇格されます。ベストプラクティスとして、アプリケーション層にデータベース接続再試行ロジックを実装することをお勧めします。
リードレプリカクラスター内のノードはアクティブであるため、ワークロードの特性に関係なくフェイルオーバー時間は安定しています。通常、フェイルオーバーは、プライマリ障害の検出からプロモートされたレプリカでのトランザクションの再開まで、数分以内に完了します。最適なパフォーマンスを得るには、適切なサイズのノードタイプと Timestream for InfluxDB IOPS Included Storage を使用することをお勧めします。
フェイルオーバーが有効になっている場合、Timestream for InfluxDB はさまざまな障害状態でのフェイルオーバーを自動的に処理します。現在、強制フェイルオーバーの手動開始は、Timestream for InfluxDB リードレプリカクラスターではサポートされていません。
はい、リードレプリカはプライマリノードと同じリージョンの別のアベイラビリティーゾーンに自動的にプロビジョニングされます。
はい。プライマリノードとリードレプリカノードの両方の場所は、AWS マネジメントコンソールまたは GetDBInstance API を使用して確認できます。
アベイラビリティーゾーンは、同一リージョンの別のアベイラビリティーゾーンに対して低レイテンシーでネットワーク接続できるように設計されているため、レイテンシーの影響は最小限に抑えられます。ただし、耐障害性を最大化するために、アプリケーションおよびその他の AWS リソースは、複数のアベイラビリティーゾーンにわたって冗長性を持たせて設計することをお勧めします。リードレプリカクラスターはこのアーキテクチャを自然にサポートします。異なるアベイラビリティーゾーンのノードにリードワークロードを分散でき、フェイルオーバーが有効になっていると、アベイラビリティーゾーンが使用できなくなった場合でもアプリケーションは引き続き動作できます。