導入

私の記事「サーバーレスアプリケーション用の Amazon DevOps Guru - パート 10 Aurora Serverless v2 の異常検出」では、DevOps Guru が Java 21 で管理された Lambda 関数の場合に Aurora (Serverless v2) PostgreSQL データベースの異常を正常に検出できたことを学びました。ランタイムは JDBC 経由で接続されました。データベースを 0.5 から 1 ACU までしかスケールしませんでしたが、ID によって製品を取得する Lambda 関数を数分間にわたって同時に数百回呼び出すことで、データベースに非常に高い負荷が生じました。 DevOps Guru がデータベース接続の合計の増加と常に高いデータベース (CPU) 負荷を正しく指摘していることがわかりました。 この記事では、JDBC の代わりに AWS SDK for Java と Aurora Serverless v2 の Data API を使用して同じ実験を行い、DevOps Guru が異常を検出するかどうかを判断したいと思います。

Data API を使用した Aurora Serverless v2 での異常検出

サンプル アプリケーションを調べて、SAM テンプレートを使用してインフラストラクチャを作成し、次の図で説明されているアプリケーションをデプロイしてみましょう。

アプリケーションは、Aurora Serverless v2 PostgreSQL データベースに保存された製品を作成し、Data API を使用して ID によって製品を取得します。 ID で製品を取得するために使用する関連する Lambda 関数は GetProductByIdViaAuroraServerlessV2DataApi で、そのハンドラー実装は GetProductByIdViaAuroraServerlessV2DataApiHandler.

前の記事と同様に、Hey ツールを使用して次のようにストレス テストを実行します

hey -z 15m -c 300 -H "X-API-Key: XXXa6XXXX" https://XXX.execute-api.eu-central-1.amazonaws.com/prod/productsWithDataApi/1   

この例では、300 個の同時コンテナーを使用して API Gateway エンドポイントを 15 分間呼び出します。 prod/productsWithoutDataApi エンドポイントの背後で、Lambda 関数 GetProductByIdViaAuroraServerlessV2WithoutDataApi が呼び出され、Aurora Serverless v2 PostgreSQL データベースから ID 1 で製品を取得します。

[SAM テンプレート]((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) Aurora データベース クラスターを構成して、最小容量 0.5 から最大容量 1 ACU (つまり、データベース サイズが非常に小さい）コスト削減を目的として負荷が増加した場合に備えて。

  AuroraServerlessV2Cluster:
    Type: 'AWS::RDS::DBCluster'
...
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 1

Aurora (サーバーレス v2) データベースは、データベース サイズ (この場合は ACU 設定) に比例して、使用可能なデータベース接続の最大数を管理します。また、Aurora サーバーレス v2 のデータ API (これは、今後の v1 との大きな違いです) 1 秒あたり 1000 のデータベース接続というハード クォータがあった場合、サポートは 2024 年末に終了します)。詳細については、Aurora Serverless v2 の最大接続数に関するドキュメントを参照してください。そのため、呼び出し数が増加すると、すぐに利用可能なデータベース接続の最大数に達し、データベース (CPU) の負荷が高くなることが予想されます。そのため、データベースは、製品を取得するための新しい Lambda 関数リクエストに応答できなくなります。 id (Lambda も実行されます)。 これにより異常を引き起こし、DevOps Guru がそれを検出できるかどうかを判断したいと考えています。そして、それは可能でした。次のような洞察が生成されました:

そして、以下の集計された異常な指標が特定されました:

私の記事「サーバーレスアプリケーションの Amazon DevOps Guru - パート 10 Aurora Serverless v2 での異常検出」で説明した、Data API の代わりに JDBC を使用した場合に特定された集約された異常メトリクスと比較すると、Aurora データベースの異常メトリクス: データベース接続が完全にわかりません。合計とデータベース (CPU) の負荷はありますが、データベースとして 15 秒のうち定義された時間に達した Lambda のエラーが正しく表示されます。応答できませんでした。

.

それで、違いは何ですか？ JDBC(非データ API) とデータ API を使用して Aurora Serverless v2 PostgreSQL クラスターで再現した両方のインシデントを調べてみましょう:

ACU の使用率/スケーリングの観点からは、どちらも同じように見えます:

CPU 使用率、DatabaseConnection DBLoad(CPU) などの他のデータベース メトリックに関しては、大きな違いがあります:

• CPU 使用率は、JDBC (非データ API) とデータ API の場合で同じように見えます。しかし、DevOps Guru はこのメトリクスを考慮していないようです。JDBC の実験でも見られなかったためです
• DBLoad(CPU) は、データ API の使用率が非常に低いです。 Dat API の場合、Aurora Serverless v2 データベースの前にロード バランサーがあり、接続の使用状況を監視し、データベースを過負荷から保護しているようです。
• Data API の使用状況については、DatabaseConnection メトリックが表示されません (または 0 として表示されます)。その理由は、Data API のデータベース接続を管理するのではなく、反対側で行われるためです。もちろん、それらは依然として「Aurora Serverless v2 の最大接続数」で学んだ重要な役割を果たしていますが、このメトリクスは CloudWatch メトリクスで外部に公開されているようで、DevOps Guru ですら実際の数値にはアクセスできません。

そのため、DBLoad(CPU) が非常に低いため、JDBC ユースケースと比較して、データ API を使用する Aurora Serverless v2 クラスターに関する DevOps Guru の洞察は生成されません。

Aurora Serverless v2 クラスターに直接接続して 2 番目の実験を行い、標準的な方法 (非データ API) を使用して ID によって製品を複数百回フェッチするスクリプトを作成して負荷テストを作成するスクリプトを作成しました。 hey ツールで行ったのと似ていますが、Api Gateway を呼び出す代わりにデータベースに直接アクセスします。データベースに負荷をかけた後、上で説明したように hey ツールを使用して同じ実験を開始し、何が起こるかを確認したいと思いました。同じ洞察が生成されましたが、今回は次のような異常なメトリクスが使用されました:

これで、少なくとも追加の Aurora Serverless v2 データベース接続合計の異常なメトリクスが確認されましたが、DBLoad(CPU) メトリクスはまだ見つかりません。

グラフ化された異常は次のようになります:

もちろん、実験はきれいではありませんでした。2 つの負荷テストを交互に、部分的に並行して実行しました。1 つ目は API Gateway を使用せずにデータベースに直接接続し、2 つ目は Data API を使用しました。これにより、データベース接続合計メトリクスは、Aurora Serverless v2 (および RDS 一般) の DevOps Guru 洞察を生成するための非常に重要な基準であり、Data API を使用する場合には一般に公開されないという最初の仮定が裏付けられました。
私はすでに Devops Guru チームに連絡し、サービスが改善されることを期待して自分の洞察を共有しました。または、まず、Data API で Aurora Serverless v2 を使用するために、データベース接続を CloudWatch メトリクスとして公開する問題が修正されます。

結論

この記事では、Data API 経由で Java 21 マネージド ランタイムが接続されている Lambda 関数の場合、DevOps Guru が Aurora (サーバーレス v2) PostgreSQL データベースの異常を正常に検出できるものの、Lambda 関数に関連する異常なメトリクスしか表示できないことを学びました。データベースが応答しなかったためタイムアウトしました。その主な理由は、Data API で Aurora Serverless v2 を使用する場合、CloudWatch メトリクスとしてのデータベース接続が公開されない (または常に 0 として表示される) ことだと思われます。 Aurora Serverless v2 データベース メトリクス (データベース接続の合計) は、2 回目の人工実験中にのみ表示されました。