営業部 佐竹です。
本日はコスト最適化手法の1つとして、Redshift クラスターを未使用時に停止してコストを削減する方法について記載します。
はじめに
Amazon Redshift の一時停止（Pause）/再開（Resume）は2020年3月にリリースされた新しい機能で、EC2 インスタンスや RDS DB インスタンスと同様にクラスターの停止が可能となる機能です。停止時はクラスターのランニング費用の請求が停止されるため、コスト削減に役立つ機能となります。
加えて、Redshift では他の EC2 インスタンス等と異なり、一時停止と再開の「スケジュール設定が AWS の機能として可能」であり、AWS マネジメントコンソールからも設定が可能です。このため、弊社が開発提供している SaaS である Cloud Automator では Redshift に対するスケジュール機能を現状ご提供しておりません。
本日はこの一時停止と再開を Redshift クラスターに設定する方法を具体的に説明します。
参考までにですが、AWS 公式の告知ブログは以下になります。
スケジュール用の IAM Role を作成する
Redshift クラスターの一時停止を「すぐに行う」場合には、スケジュール用の IAM Role は不要となりますが、スケジュール設定を利用する場合は IAM Role の作成が必須となります。まずはこれを作成します。
AWS 公式ドキュメントを調べてみたのですが、Redshift のスケジュール設定用としてそのまま利用が可能なサンプル IAM Policy が記載されていなかったため、それをこちらに記載します。AWS サポートにも念のため確認しましたが、以下の記載で問題なく動作しています。
IAM Policy JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RedshiftScheduler",
"Effect": "Allow",
"Action": [
"redshift:PauseCluster",
"redshift:ResumeCluster"
],
"Resource": "*"
}
]
}
必要なのは redshift:PauseCluster と redshift:ResumeCluster の2つのみですため、これらを記載した IAM Policy を作成してください。名前は RedshiftSchedulerPolicy などとします。
作成が完了したら、次に IAM Role を作成します。
IAM Role
IAM Role には先ほどの IAM Policy をアタッチするのみですが、scheduler.redshift.amazonaws.com を信頼して利用する必要があります。
そのため「信頼されたエンティティの種類を選択＞AWS サービス＞Redshiftを選択」の後、最下部の「ユースケースの選択＞Redshift - Schedulerを選択」とします。
次のステップに進むと、「Attached アクセス権限ポリシー」が表示されますが、ここに先ほど作成した IAM Policy が表示されないため AmazonRedshiftFullAccess を一旦選択して次に進みます。
RedshiftSchedulerRole などとロール名を入力し、作成を完了します。
作成された RedshiftSchedulerRole のアクセス権限を編集し、先ほど作成した RedshiftSchedulerPolicy をアタッチします。その後 AmazonRedshiftFullAccess をデタッチします。
念のため、「信頼されたエンティティ」を確認してください。
scheduler.redshift.amazonaws.com が記載されていれば問題ありません。編集したい場合は、以下の JSON をご利用いただけます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "scheduler.redshift.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
これで下準備は完了です。
一時停止と再開をスケジュールする
Redshift のコンソールに移動し、対象となるクラスターを開き「アクション」から「一時停止」を選択します。
「スケジュールどおりに一時停止して再開する」のラジオボタンを選択します。
スケジュール名（大文字が使えない点に注意してください）を適切に記載した後、エディタでは設定が不可能なため CRON 構文を選択して記載します。
なお、スケジュール名には、以下の作業の後自動的に接尾語として「-pause」「-resume」が付与されます。そのためスケジュールの名称は daytime-on-weekdays などとしておくと可読性として実用的かと存じます。
CRON の記述方式
AWS における CRON のスケジュール式は、CloudWatch Events のドキュメントに記載があるものが参考になるため紹介します。
指定は6つ必要で「分/時間/日/月/曜日/年」の順に設定します。また、これらのスケジュールは全て UTC で設定が必要ですため、UTC 換算で記載ください。
- 月曜～金曜日の20:00 JST に一時停止する場合：0 11 ? * MON-FRI *
- 月曜～金曜日の8:00 JST に再開する場合：0 23 ? * SUN-THU *
早朝の起動は、時差（-9時間）の影響で「前日の設定」となるため、曜日の指定に注意してください。
最後に IAM Role を設定し「定期的な一時停止と再開をスケジュールする」を押下して完了します。
設定の確認
クラスターの「スケジュール」タブに、「スケジュールの一時停止と再開」があるため、これを確認します。特に「次の呼び出し (UTC)」を見て問題がないか確認すると良いでしょう。
注意点
メンテナンスウインドウ
停止時間にメンテナンスウインドウが来ないよう、メンテナンスウインドウを Redshift クラスターが起動している時間に修正ください。
バックアップ
手動でバックアップを取得している場合、クラスターの停止中は処理が失敗するため Redshift クラスターが起動している時間に修正ください。
一時停止や再開にかかる時間
Redshift クラスターの一時停止と再開には一定の時間を要します。業務開始に合わせて利用したい場合は、業務開始時間より少し早めの起動を行う必要があります。
その他の注意点については、公式ドキュメントにまとまっておりますためこちらも合わせてご参考ください。
補足
Starts on（開始）と Ends on（終了）は同時に設定しないとエラー
Redshift のスケジューラーには、スケジュールを実行する開始日と終了日が指定可能です。ただし、セットで必ず設定が必要となる点に注意してください。片方のみをセットしようとすると、以下のエラーが表示されます。
The action daytime-on-weekdays-pause can only be scheduled for a valid time in the future. If a start or end time is specified for the action, the schedule time must be set between the start time and end time.
Starts on（開始）と Ends on（終了）はコンソールの一覧に表示されない
上記設定は、マネジメントコンソールの一覧から閲覧できないため、「describe-scheduled-actions」が有効です。
以下がその一例です。StartTime と EndTime が正しく設定されているか、本 CLI のコマンドを有効活用ください。
{
"ScheduledActionName": "daytime-on-weekdays-resume",
"TargetAction": {
"ResumeCluster": {
"ClusterIdentifier": "XXXXXXXXXXXXXXXXXX"
}
},
"Schedule": "cron(0 23 ? * SUN-THU *)",
"IamRole": "arn:aws:iam::123456789012:role/RedshiftSchedulerRole",
"State": "ACTIVE",
"NextInvocations": [
"2023-01-29T23:00:00+00:00",
"2023-01-30T23:00:00+00:00",
"2023-01-31T23:00:00+00:00",
"2023-02-01T23:00:00+00:00",
"2023-02-02T23:00:00+00:00"
],
"StartTime": "2023-01-29T00:00:00+00:00",
"EndTime": "2023-03-31T00:00:00+00:00"
}
まとめ
本日のブログではコスト最適化手法の1つとして、Redshift クラスターを未使用時に停止してコストを削減する方法について記載しました。
一週間は168時間あり、そのうち5営業日の12時間＝合計60時間のみの稼働とできれば、コストは64%削減が可能です。50時間の稼働であれば70%削減されます。
特に常時起動の必要がない検証環境においては、Reserved Node を購入するよりかは未使用時間帯の一時停止を行ったほうが利用期間の縛りなどもなく、より柔軟です。
この記事が AWS アカウントのコスト削減に少しでも役に立てば幸いです。
それでは、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
