■概要
Aurora PostgreSQL（ライターとリーダー）の定期的な再起動をEventBridge Schedulerで設定します。
■実際に設定してみる
EventBridgeの画面へ進み、ルール名を記載後、EventBridge Schedulerに進みます。
次にcronを設定しましょう。
今回は毎月1日の18時に再起動したいので以下のような式になりました。
0 18 1 1-12 ? *
次にターゲットの選択を行います。
「すべての API」を選択し、「RDS」で検索をかけます。
「Amazon RDS」を選択し、次はrebootで検索をかけます。
今回はDBインスタンスの再起動になるので「RebootDBInstance」を選択しました。
（「RebootDBCluster」もありますが、aurora-postgresqlではサポートしていないとの事… ）
以下のように対象DB名を記載しましょう。
スケジュール完了後のアクションではNONE、再試行ポリシーとデッドレターキュー (DLQ)はなしとしています。
最後にこのイベントルールを動作させる為にIAMロールが必要となります。
まずはIAMポリシーを作成しましょう。
今回はクラスターの再起動を行うので以下で設定しました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "rds:RebootDBInstance",
"Resource": "*"
}
]
}
次にIAMロールを作成します。
EventBridgeで実行できるように信頼されたエンティティで以下のように設定しておきましょう。
エンティティを設定したら、上で作成したポリシー（RDS再起動する権限のやつ）も付与しておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
上記、作成したロールを「アクセス許可」で指定し、設定を最終確認後、スケジュールを作成してください。
これで設定は完了です！
実際に動作したかはauroraの「ログとイベント」より確認できます。
■Auroraの再起動について
ちなみに、ライターとリーダーで構成されているAuroraの再起動は以下のように動作します。
・ライターを再起動した場合
ライターとリーダーが再起動される
・リーダーを再起動した場合
再起動されるのは選択したリーダーのみ
ライター DB インスタンスを再起動すると、クラスター内の各リーダー DB インスタンスの再起動も開始されます。
これにより、クラスター全体のパラメータの変更がすべての DB インスタンスに同時に適用されます。
ただし、すべての DB インスタンスの再起動により、クラスターのための短時間の停止が発生します。
リーダー DB インスタンスは、ライター DB インスタンスの再起動が完了して利用可能になるまで利用できません。
■最後に
EventBridge Schedulerは導入が簡単であり、様々な動作をスケジュールできます。
もちろんRDS再起動以外でもターゲットAPIは豊富にありますので、色んな使い方を模索してみたいと思います。