Amazon Redshift Serverless での請求

オンデマンド容量を購入できます – オンデマンドコンピューティング容量を選択した場合、リソースは従量制料金となります。これは、Amazon Redshift Serverless を使い始めたばかりの場合や、安定した使用パターンがまだ明確でない場合に最適です。オンデマンドは、最も高い柔軟性を提供します。詳細については、「オンデマンドのコンピューティング容量に対する請求」を参照してください。

予約を購入できます – 特定の期間 (1 年間など)、事前設定された量のコンピューティングリソースを購入する場合、予約には割引があります。これは、一定量の容量を着実に使用することがわかっている場合に最適です。容量のニーズをある程度予測できる場合、コスト削減に役立ちます。詳細については、「サーバーレス予約に対する請求」を参照してください。

使用量の記録 - クエリやトランザクションは、トランザクションの完了、ロールバック、停止後にのみ測定、記録されます。例えば、トランザクションが 2 日間実行された場合、RPU の使用量はトランザクションの完了後に記録されます。sys_serverless_usage のクエリを実行することで、使用中の状況をリアルタイムでモニタリングできます。トランザクション記録は、RPU 使用量の変動として反映され、特定の時間や毎日の使用のコストに影響を与える可能性があります。

明示的なトランザクションを記述する - トランザクションを終了することは、重要な役割を果たすベストプラクティスです。開いているトランザクションを終了またはロールバックしない場合、Amazon Redshift Serverless は RPU を使用し続けます。例えば、BEGIN TRANを明示的に記述する場合、それに対応した COMMIT や ROLLBACK の記述があることが重要です。

クエリのキャンセル - クエリを実行し、終了する前にキャンセルした場合は、クエリの実行時間に対して請求されます。

スケーリング - Amazon Redshift Serverless インスタンスは、パフォーマンスを一定に保つためにスケーリングを開始して、負荷の高い時間に対応する場合があります。Amazon Redshift Serverless の請求には、同じ RPU レートでの基本のコンピューティング性能とスケール処理容量の両方が含まれます。

スケールダウン - Amazon Redshift Serverless は、基本 RPU 容量からスケールアップして、負荷の高い時間を処理します。場合によっては、クエリの負荷が低下した後も、RPU 容量が一定期間高い設定のままになる場合があります。予想外のコストを防ぐため、コンソールで最大 RPU 時間を設定することを推奨します。

システムテーブル - システムテーブルのクエリを実行すると、クエリ時間が請求されます。

Redshift Spectrum - Amazon Redshift Serverless があり、クエリを実行する場合、データレイククエリには別途の料金は発生しません。Amazon S3 に保存されているデータに対するクエリの場合は、トランザクション時間ごとに、ローカルデータに対するクエリと同じ料金になります。

フェデレーティッドクエリ - フェデレーションクエリは、データウェアハウスまたはデータレイクでのクエリと同様に、特定の時間で使用される RPU に基づいて課金されます。

ストレージ - ストレージは GB/月単位で別途請求されます。

最低料金 – リソース使用量は最低 60 秒として課金され、1 秒単位で計測されます。

スナップショットの請求 - スナップショットの請求は変更されません。スナップショットの請求は、GB /月のレートで請求されるストレージに応じて課金されます。データウェアハウスを過去 30 分単位で、24 時間内の特定のポイントに、無料で復元できます。詳細については、Amazon Redshift の料金を参照してください。

各トランザクションを必ず終了してください。BEGIN を使ってトランザクションを開始する場合、それを END することも重要です。

また、エラー処理のベストプラクティスに従ってエラーに適切に対応し、各トランザクションを終了します。オープントランザクションを最小化することで、不要な RPU の使用を回避できます。

SESSION TIMEOUT を使用して、開いているトランザクションとアイドルセッションを終了します。これにより、3600 秒 (1 時間）を超えてアイドル状態または非アクティブの状態のセッションがすべてタイムアウトします。これにより、21600 秒 (6 時間) を超えて開いたままの状態または非アクティブの状態のトランザクションがすべてタイムアウトします。このタイムアウト設定は、長時間実行されるクエリに対してセッションを開いたままにする場合など、特定のユーザーに対して明示的に変更できます。CREATE USER のトピックに、ユーザーに対して SESSION TIMEOUT を調整する方法が記載されています。

接続プーリング設定でヘルスチェックまたはキープアライブクエリの頻度を確認して最適化することで、ヘルスチェックの頻度を調整します。

システムのアイドル時間中に不要な接続チャーンやバックグラウンドクエリアクティビティを最小限に抑えるように接続プーリングを設定して、アイドルシステム設定を最適化します。

オーバーヘッドを削減できる場合は、アプリケーションレベルのプーリングを実装するか、接続ライフサイクル管理を改善します。

接続プーリング設定で許可されている場合は、ハートビートクエリまたは検証クエリを無効にします。特定の接続文字列パラメータまたは設定ファイルをチェックして、これらの設定を調整します。

TCP キープアライブ設定のファインチューニング: ドライバーの内部ハートビートメカニズムを無効にすることができない場合は、オペレーティングシステムまたはアプリケーションレベルで Transmission Control Protocol (TCP) キープアライブ設定を調整して、接続タイムアウトの問題に対処します。詳細については、オペレーティングシステム、JDBC/ODBC ドライバー、または接続プールのドキュメントを参照してください。

データベース接続プーリングの最適化: 接続を管理し、接続オーバーヘッドを最小限に抑えるように接続プール (HikariCP、Apache データベース接続プール) を設定します。最大接続数、アイドルタイムアウト、検証クエリ (必要な場合) などのパラメータに焦点を当てます。この最適化により、Amazon Redshift Serverless のコンピューティング使用量を実際のワークロード需要に合わせて調整できるため、コスト削減につながる可能性があります。

ワークロードで使用可能な場合は、8 RPU のより低い基本 RPU 容量を使用します。

ターゲット Redshift インスタンスの REFRESH_INTERVAL を設定し、鮮度とコストのバランスを取ることができます。間隔を短くすると、ほぼリアルタイムの更新が確保されますが、計算コストが増加します。間隔を長くすると (5 分以上)、レポートや履歴分析など、即時の鮮度が重要ではないワークロードの料金が削減されます。Redshift ターゲット REFRESH_INTERVAL を編集するには、ALTER DATABASE の説明の更新間隔句を参照してください。

ゼロ ETL データの取り込み中に分析ワークロードを同時に実行することで、Amazon Redshift Serverless 環境の使用率を最大化します。これにより、コンピューティング性能が複数のビジネス目的にアクティブに対応できるようになります。