はじめに
みなさん、こんにちは。グローバルでは単なるクラウドの活用から先に進み、クラウドのビジネス価値を最大化するための取り組みである「FinOps」の実践が当たり前になりつつあります。
もちろんFinOpsの目指すべきゴールは、正しくはコスト削減ではないものの、今回はあえて削減の部分にフォーカス当てて紹介していきたいと思います。
よくあるコスト最適化のポイント
まず前段として、クラウドにおける一般的なコスト最適化のポイントとしては以下のような項目が挙げられます。
- コンピューティングの適正化
- 未使用リソースの棚卸
- 料金プランの適正化
- ストレージ/ネットワークの適正化
- ライセンスの適正化、など
もちろんこれらの項目はRedshiftにも当てはまってくる部分があります。今回はこちらに沿ってRedshiftの最適化ポイントを紹介していきたいと思います。
コンピューティングの適正化
過剰なサイジングの見直し
机上でサイジングした結果をもとにインスタンスファミリーやサイズを選択し、そのまま使い続けているといったケースも少なからずあると思います。しかし、机上のサイジングでは安全係数をかけていることが多く、実際に必要なサイズよりも過剰になっていることが多いです。
そのため、CPU使用率、読み取りおよび書き取りIOPSなどのメトリクスをもとに、過剰なサイジングになっていないかを定期的に見直し、必要に応じてスケールイン/スケールダウンを行うことで過剰なリソース分に支払っている料金を節約できる可能性があります。
とくにPoC/開発環境などの場合は、性能試験のときに一時的にスケールアウト/スケールアップすればいいだけのことも多いため、定常的に用意しておくべきスペックになっているのか、改めて見直してみてください。
過剰な冗長構成の見直し
高可用性の必要ないPoC/開発環境などでマルチAZ構成を組んでいるリソースは、過剰な冗長構成となっている可能性があります。過剰な冗長構成を適正化し、シングルAZ構成かつシングルインスタンスにすることでコストを節約することができます。
とくにPoC/開発環境などの場合は、試験のときに一時的にマルチインスタンス、マルチAZにすればいいだけのことも多いため、定常的に冗長構成にしておかなければいけない構成なのか、改めて見直してみてください。
未使用リソースの棚卸
アイドル状態のクラスターの棚卸
DB接続が長期間にわたって確立されていない状態（アイドル状態）のクラスターは、未使用リソースの可能性があるため、削除もしくはスケールイン/スケールダウンすることによってコストを削減できる可能性があります。
また、定常的にアクセスが少ないということであれば料金プランの変更を行うことでコストを削減できる可能性があります。詳細は「Redshift Serverlessの活用」を参照ください。
不要な手動スナップショットの棚卸
取得してから長期間経過かつ保持期間を設定していない手動スナップショットについては、すでに不要となっていないかを確認し、不要であれば削除することによってコストを削減できる可能性があります。
料金プランの適正化
リザーブドインスタンスの適用
24時間365日の稼働ではなくとも長時間稼働するリソースは、リザーブドインスタンス（RI）を適用することによってオンデマンド料金よりもコストを削減できる可能性があります。
RI購入によるコスト最適化の機会の気づきとして、AWS Billing and Cost ManagementのRIレコメンデーション機能が活用できます。稼働統計データを基にRI購入に関するレコメンデーションが提供された場合は、詳細調査を行った上でRIを追加購入できないか検討してみてください。
Redshift Serverlessの活用
定常的にアクセスが発生するようなユースケースではなく、ごくごくまれにアクセスが発生するといったようなケースでは、常にノードに料金を払いつづけるのではなく、サーバーレスにしてしまった方がコストを低減できる可能性があります。
スケーリングの調整
未使用の時間帯はクラスターを自動停止
PoC/開発環境などの平日日中の業務時間帯のみに稼働するリソースは、スケジュールにあわせて確実にリソースの停止を実行することでリザーブドインスタンスを適用するよりもコストを抑えられる可能性があります。
ストレージ/ネットワークの適正化
ストレージサービスの見直し
一定期間を過ぎた古いデータのように常には使わないけどごくごくまれに参照するようなデータについては、マネージドストレージに保存しておくのではなく、より料金の安いS3へParquet形式で保存しておき、必要に応じてRedshift Spectrumを使って分析するといった形にした方がコストを抑えられる可能性があります。
最後に
もちろん今回紹介したもの以外にも最適化ポイントはあります。とはいえ、まずは今回紹介したような、よくある最適化ポイントから始めてみるのが良いのかなと思っています。
なお、一点注意していただきたいのですが、コスト削減に注力するがあまり、パフォーマンスを損なってしまうようでは本末転倒です。修正を加える際は、実際の環境への影響をしっかりと調査を行った上で実行するとともに仮に悪影響が出てしまった際には、すぐ切り戻せるようにしておくことも重要であることをご認識いただければと思います。
以上、Amazon Redshiftのよくあるコスト最適化ポイントのご紹介でした。今回の内容は基本的に使い古された情報ですが新たな気づきがひとつでもあったなら幸いです。
- AWS は、米国その他の諸国における Amazon.com, Inc. またはその関連会社の商標です。
- その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。