サーバーレス ApsaraDB RDS for PostgreSQL インスタンスは、変化するビジネス要件に対応するためのリアルタイムスケーリングを提供し、変動するワークロードに適応するために計算リソースを迅速かつ独立してスケーリングできるようにし、リソースの非効率的な使用を防ぎ、O&M コストを削減します。このトピックでは、サーバーレス RDS インスタンスの機能とアーキテクチャ、およびサーバーレス RDS インスタンスの使用方法について説明します。サーバーレス RDS インスタンスは、コストを削減し、O&M 効率を向上させるのに役立ちます。
概要
ApsaraDB RDS for PostgreSQL のサーバーレスインスタンスは、CPU とメモリリソースのリアルタイムな弾力性を提供します。これらは、クラウドディスクアーキテクチャに基づく新しいタイプの ApsaraDB RDS for PostgreSQL 製品であり、ネットワークリソース、名前空間、ストレージの垂直リソース隔離を提供し、計算リソースに対しては従量課金制を採用しています。コスト効率が高く、使いやすく、柔軟性があります。これにより、変動するビジネスワークロードに対応するために、計算リソースを迅速かつ独立してスケールアップまたはスケールダウンできます。ビジネスの変化への迅速な対応は、コストの最適化と企業効率の向上に貢献します。
サーバーレス RDS インスタンスは、RDS キャパシティユニット（RCU）に基づいて課金されます。1 RCU のパフォーマンスは、最大 1 コアと 2 GB のメモリを提供する RDS インスタンスのパフォーマンスと同等です。サーバーレス RDS インスタンスは、ワークロードに基づいて、指定した範囲内で RCU の数を自動的に調整します。
サーバーレス RDS インスタンスへの最大接続数は 2,400 に固定されており、変更できず、RCU の数によって変化しません。
以下の図は、ワークロードが変動するシナリオにおける、通常のインスタンスとサーバーレスインスタンスのリソース使用量と仕様の変動を示しています：
上記の図を参照すると、次の結論が得られます。
通常の RDS インスタンス：オフピーク時のリソース使用率が低いとコストの無駄につながり、ピーク時のリソースが不足するとサービスのパフォーマンスに影響します。
サーバーレス RDS インスタンス：
計算リソースはビジネスの需要に応じてリアルタイムで調整されます。これにより、リソースの無駄を最小限に抑え、リソース使用率を向上させ、リソースコストを削減します。
ピーク時には、ワークロードの要件に合わせてリソースがスケーリングされるため、パフォーマンスとサービスの安定性が確保されます。
ワークロードの実行に使用される実際のリソース量に基づいて課金されます。これにより、コストが大幅に削減されます。
人的介入は必要ありません。これにより、O&M 効率が向上し、O&M 管理者と開発者のコストが削減されます。
サーバーレス RDS インスタンスでは、自動起動および停止機能がサポートされています。サーバーレス RDS インスタンスへの接続が確立されていない場合、インスタンスは自動的に一時停止され、計算リソースが解放され、コストが削減されます。サーバーレス RDS インスタンスへの接続が確立されると、インスタンスは自動的に再開されます。
サーバーレス RDS インスタンスは自動スケーリングをサポートし、高スループットの書き込み操作と高並列処理操作に最適化されています。これは、大量のデータと大きなトラフィック変動が伴うシナリオに適しています。
メリット
低コスト：サーバーレス RDS インスタンスは、他のインフラストラクチャやサービスに依存せず、安定した効率的なデータストレージおよびアクセスサービスを提供できます。このデプロイメントモデルは、スタートアップや、リソースの作成直後にワークロードを実行したいシナリオに最適です。従量課金方式に基づいて、使用したリソースに対してのみ課金されます。
大容量ストレージ：サーバーレス RDS インスタンスには最大 32 TB のストレージ容量を購入できます。システムは、RDS インスタンスのデータ量に基づいてストレージ容量を自動的に拡張します。これにより、サービスがストレージ不足によって悪影響を受けるのを効果的に防ぎます。
計算リソースの自動スケーリング：読み取りおよび書き込み操作に必要な計算リソースは、人的介入なしで自動的にスケーリングできます。これにより、O&M コストと人的ミスのリスクが大幅に削減されます。
フルマネージド型でメンテナンスフリーのサービス：サーバーレス RDS インスタンスは Alibaba Cloud によって完全に管理されているため、システムのデプロイ、スケーリング、アラート処理などの O&M 操作ではなく、アプリケーションの開発に集中できます。O&M 操作はバックグラウンドで実行され、サービスレイヤーでは透過的です。
シナリオ
開発環境やテスト環境のデータベースなど、基盤となるデータベースへのアクセス頻度が少ないシナリオ。
中小企業の Web サイト構築などのサービスとしてのソフトウェア（SaaS）シナリオ
個々の開発者
教育、学生実験などの教育シナリオ
IoT やエッジコンピューティングなど、一貫性のない予測不可能なワークロードを処理するシナリオ
フルマネージド型またはメンテナンスフリーのサービスが必要なシナリオ
サービスが変化しているか予測不可能なシナリオ
断続的なスケジュールされたタスクが関係するシナリオ
料金ルール
使用方法
必要に応じて RCU のスケーリング範囲を調整できます。RCU の上限と下限を指定して、リソース構成を最適化できます。
スケジュールされたタスクを構成して、サーバーレス RDS インスタンスの RCU の数を調整する
特定の期間内にインスタンスの安定性に関する厳格な要件がある場合は、スケジュールされたタスクを構成して、サーバーレス RDS インスタンスの RCU の数を調整し、その期間内の安定性を確保できます。
サーバーレス RDS インスタンスのスケーリングポリシーを変更する
サーバーレス RDS インスタンスのデフォルトのスケーリングポリシーは「強制的に実行しない」です。デフォルトのスケーリングポリシーを使用して、潜在的なサービス中断を防ぐことができます。継続的な可用性ではなく、より高いレベルのパフォーマンスが必要な場合は、スケーリングポリシーを手動で「強制的に実行する」に変更できます。
自動起動および停止機能を有効にしてから 10 分以内にサーバーレス RDS インスタンスへの接続が確立されない場合、インスタンスは自動的に一時停止されます。この場合、RCU は使用されず、計算料金は発生しません。サーバーレス RDS インスタンスへの接続が確立されると、サーバーレス RDS インスタンスは自動的に再開され、計算料金が発生します。
FAQ
Q：サーバーレスインスタンスの CPU またはメモリに関する Cloud Monitor のアラートが届くのはなぜですか？
A：これは通常、事前に構成されたグローバルアラートルールが原因で発生します。すべての ApsaraDB RDS for PostgreSQL インスタンス (または特定のリソースグループ) に対して CPU やメモリなどのメトリックに関するアラートルールが既に存在する場合、新しく作成されたサーバーレスインスタンスはこれらのルールを自動的に継承します。サーバーレスインスタンスは自動的にスケーリングできますが、リソース使用率が一時的にアラートのしきい値に達すると、システムはアラートをトリガーして通知を送信します。
これらのアラートを管理するには、Cloud Monitor コンソールにログインします。 ページで、高度なフィルター機能を使用して、対象のサーバーレスインスタンスで有効になっているアラートルールを表示し、管理します。
Q：高負荷時にインスタンスが時間内にスケールアウト (RCU の増加) できず、サービスが無応答になるのはなぜですか？
A：高負荷時にインスタンスが時間内にスケールアウト (RCU の増加) できない主な理由は 2 つあります：
RCU 上限への到達：インスタンスの計算リソースが、構成された最大 RCU 値に達しています。この場合、ピーク時のビジネス要件を評価し、必要に応じて最大 RCU 上限を引き上げてください。
スケーリングのレイテンシーが急激なトラフィックの急増に追いつかない：サーバーレスインスタンスの弾性スケーリングメカニズムは、応答に時間を要します。スケールアウトは通常、CPU またはメモリ使用率が 80% を超えたときにトリガーされ、プロセスには約 5 秒かかります。短時間 (たとえば 5 秒未満) でサービストラフィックが急激に増加した場合、スケーリングプロセスがトリガーされて完了する前にリソースが枯渇し、インスタンスが無応答になる可能性があります。急激な超高同時実行性が求められるビジネスシナリオでは、サービスの安定性を確保するために、事前にプロビジョニングされた固定リソースを持つ通常のインスタンスを使用することを推奨します。
Q：ビジネス負荷が減少した後、インスタンスが自動的にスケールイン (RCU の減少) しないのはなぜですか？
A：サーバーレスインスタンスがスケールイン (RCU の減少) するのは、CPU 使用率が 50% 未満かつメモリ使用率が 50% 未満の両方の条件が満たされた場合のみです。
スケールインしない一般的な理由は、データベースのページキャッシュが大量のメモリを占有していることです。ビジネス負荷が減少した後でも、PostgreSQL は将来のクエリパフォーマンスを最適化するためにデータをメモリ内に保持することがあります。これによりメモリ使用率が 50% を超えたままになり、スケールインの条件が満たされないことがあります。すぐにスケールインをトリガーするには、インスタンスを再起動してページキャッシュを強制的に解放し、メモリ使用率を下げることができます。
Q：一時停止中で接続がないインスタンスを起動するにはどうすればよいですか？
A：コンソールで、インスタンスの自動起動・停止機能を無効にします。そうすると、インスタンスは自動的に起動します。