Aurora Auto Scalingで増減したインスタンスの数を継続的にモニタリングしてみる

はじめに

こんにちは。大阪オフィスの林です。

Aurora Auto Scalingで増減したインスタンスの数を継続的にモニタリングする方法を検討する機会がありましたので、まとめておきます。

今回やること

今回、LambdaとEventBridgeを利用し、Aurora Auto Scalingで増減したインスタンスの数を定期的にカウントしCloudWatchから増減の推移を閲覧できるようにします。

• Lambda
  • Aurora Cluster配下のインスタンスの数をカウントする処理。(下図②の部分)
  • カウントした結果をCloudWatchのカスタムメトリクスにプッシュする処理。(下図③の部分)
• EventBridge
  • Lambdaを定期実行する処理。(下図①の部分)

デフォルトで用意されているCloudWatchメトリクスは（現状）無い

現状、RDS Auroraにおいて、Aurora Cluster配下のインスタンスの数をカウントするようなメトリクスは用意されていません。そのため、Aurora Auto Scalingで増減したインスタンスの数を継続的にモニタリングするためには何かしらの作り込みが必要になってきます。今回のエントリでは、その「何かしらの作り込み」の1つの案をまとめておきます。

注意点

今回の検証では、EventBridgeで定期的な実行を実装している都合、定期実行の間隔内でインスタンスが増減されてもその時のデータは拾えません。あくまでもLambdaが実行された時に稼働しているインスタンスの数をCloudWatchにプッシュする仕組みなので、増減されたインスタンスの数を厳密にカウントしたい場合は別の仕組みを検討ください。
別の仕組みとして、Auto ScalingのイベントをトリガーにLambdaを実行する方法もあります。
しかし、Auto Scalingのイベント直後は増減したインスタンスの数がまだコマンド結果に反映されなかったりするので、ピンポイントなタイミングで正確な数を拾うのが結構難しかったりします。

やってみた

作業の流れ

それでは検証に戻ります。今回は以下の流れで作業をしていきます。

• Lambdaの設定
• EventBridgeの設定
• 動作確認

Lambdaの設定

今回の検証で使用するランタイムはPython 3.8とします。 コードは下記の通りです。

import boto3
​
def lambda_handler(event, context):
    # ココからAurora Cluster配下のインスタンスの数をカウントする処理
    client = boto3.client('rds')​
    response = client.describe_db_clusters(
        DBClusterIdentifier= "database-1" # Aurora Clusterの識別子を指定します。
    )
    rds_counts = len(response["DBClusters"][0]["DBClusterMembers"]) # DBClusterMembers配下の配列の個数をカウントしています。

    # ココからカウントした結果をCloudWatchのカスタムメトリクスにプッシュする処理
    client = boto3.client('cloudwatch')
    response = client.put_metric_data(
        Namespace='RDSCounts', # 任意の名前を指定します。
        MetricData=[
            {
                'MetricName': 'RDSCountsMetric', # 任意の名前を指定します。
                'Dimensions': [
                    {
                        'Name': 'TestKey', # 任意の名前を指定します。
                        'Value': 'TestValue' # 任意の名前を指定します。
                    },
                ],
                'Value': rds_counts,
            },
        ]
    )

Lambdaにアタッチしているロールにはデフォルトのポリシーの他、以下のポリシーをアタッチしています。

• AmazonRDSReadOnlyAccess
  • RDSに対して読み取り権限でコマンドを実行するため。
• CloudWatchFullAccess
  • カスタムメトリクスにデータをプッシュするため。
  • 厳密にはもう少し絞れるかもしれませんが検証ではこのポリシーをアタッチします。

EventBridgeの設定

続いてEventBridgeの設定を進めます。特殊な設定は無く、定期実行の間隔と対象のLambdaを指定していきます。EventBridgeのダッシュボードから「ルール」-「ルールの作成」を選択します。

任意の名前と説明を入力後、ルールタイプに「スケジュール」を指定し「次へ」を選択します。

定期実行の間隔を指定し「次へ」を選択します。

ターゲットに「AWSサービス」が選択されている状態で、前段で作成したLambda関数を指定します。

必要に応じてタグを設定後「次へ」を選択します。

設定した内容を確認し、問題無ければ「ルールの作成」を選択します。

ルールが作成されたことを確認します。

動作確認

最後にCloudWatchのメトリクスを確認していきます。
CloudWatchのダッシュボードから「メトリクス」-「すべてのメトリクス」から指定したカスタムメトリクスをドリルダウンしていきます。

今回の検証ではRDSのレプリカの数を「1」→「2」→「1」といった感じでスケールさせていたのですが、ライターのインスタンスを足した値である「2」→「3」→「2」という具合に期待した値にグラフ化されていることが分かります。

まとめ

注意点に記載した内容の懸念はありますが、Aurora Auto Scalingで増減したインスタンスの数の傾向をざっくりと把握したい方に参考になりましたら幸いです。

以上、大阪オフィスの林がお送りしました!