この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。 AWS re:Invent 2022 、楽しんでいますでしょうか。
ラスベガス現地にて Continuous cost and sustainability optimization(SUP304-R) というワークショップに参加してきました。
コスト・サステナビリティの最適化に責任を持つCCoE(Cloud Center of Excellence) へ向けたワークショップとなります。
では早速ワークショップの実施レポート、していきます。
ざっくりした内容
本ワークショップの説明、アジェンダを以下に引用します。
Continuous cost and sustainability optimization: SUP304-R
In this workshop, learn best practices for cost and sustainability optimization. Shift costs and sustainability responsibilities from the Cloud Center of Excellence (CCoE) to end users and application owners aided by automation at scale. Learn about cost efficiency and implementing mechanisms that empower application owners to have clear, actionable tasks for cost and sustainability optimization building upon real-world use cases. You must bring your laptop to participate.
『あなたはCCoEの主要メンバーであり、コストやサステナビリティを最適化しなければなりません。』
…といった前提から始まります。
以下のAWSサービスの利用をどんどん最適化していくワークショップでした。
- EBS
- EC2
- RDS
- S3
- Lambda (Bonus section)
- CloudTrail (Bonus section)
ガイドとAWSラボ環境が渡されるので、各自のPCで進めていきます。 詰まったところや不明点があれば、会場内で周っているスタッフに聞いて解決できます。
ワークショップをやってみた
本ワークショップの時間は大体 2時間弱です。 「大体100分ぐらいで終わる」と書かれていましたが、私は時間内に終わらなかったです。 EBS, EC2 章を実施、RDS章の途中らへんでタイムアップでした。
「後でやるか！」と思っていましたが、このワークショップの提供期間に 制限があるみたいで夕方にはワークショップのガイド・ラボ環境にアクセスできなくなっちゃいました。 S3章以降は実施できず…残念。
※ Duration: 72 hour って書いてたのに…
細かい部分
実際にやった内容を書いていきます。
EBS
2つのシナリオを実践します。
- GP2ボリュームからGP3ボリュームへの移行
- EBSスナップショット管理の改善
まずはマネコンで1台、オンラインでGP3への移行を行います。 その後用意された PythonスクリプトをEC2サーバー上で実行して、 『特定のタグ・キーのボリューム群』に対して一括移行を行います。
EBSスナップショット管理は Data Lifecycle Manager(DLM) を使います スナップショットポリシーを作成して、特定のタグキーのボリュームに対して 定期的にスナップショットを取得する設定を入れます。 その後、DLMで管理されていない「野良EBSスナップショット」を bashスクリプトで一括削除しました。
EC2
2つのシナリオを実践します。
- 起動停止スケジュール
- インスタンスのリサイズ
EC2の起動停止スケジュールは Instance Scheduler というAWSソリューションを使います。 中身はCFnスタックみたいで、(事前入力された)パラメータをいくつか指定して展開するだけで完了しました。 scheduler-cli を使って、コマンドラインから設定の確認・更新もできるようです。 最終的には "Schedule=seattle-office-hours" タグキーがあるインスタンスは 「月曜〜金曜の 09:00〜17:00」の時間帯のみ起動する スケジュールを立てることになります。
インスタンスのリサイズでは、 Compute Optimizer を使います。 まずはマネコンで1台、Compute Optimizerの推奨事項に合わせてインスタンスタイプを変更します。 その後、複数台インスタンスへの一括リサイズを行いますが、 それにはSystems Manager(SSM) Automation を活用します。 AWS-ResizeInstance というAutomationドキュメントを使って、 特定タグキーのインスタンス群に対してリサイズを実行します。
RDS
2つのシナリオを実践します。
- Graviton インスタンスへの変更
- 起動停止スケジュール
RDSインスタンスのプロセッサを、よりエネルギー効率・コスト効率の良い Graviton2 へ変更しました。
起動停止スケジュールには、また Instance Scheduler ソリューションを使います。 特定タグキーの付いたインスタンスが業務時間外に停止するようにスケジュールします。
ほか(S3, Lambda, CloudTrail)
(ここからは実際にできず… メモが取れた範囲になります)
▼ S3
シナリオの一つは「不完全なマルチパートアップロード」の削除です。 マルチパートアップロードがあるものを S3 Storage Lens を使って確認。 ライフサイクルルールを設定して削除します。
もう一つのシナリオは Intelligent-Tiering を使ったストレージクラスの変更です。 同じくライフサイクルポリシーを設定します。
▼ Lambda (Bounus section)
Lambda関数をGravitonプロセッサへ移行します。
▼ CloudTrail (Bonus section)
メモの範囲では Optimize CloudTrail removing duplicate trails を行います。 (おそらく「管理イベントの重複」もしくは「証跡の複数設定」あたりの話なのかなと思います)
おわりに
主要なAWSサービスのコスト(サステナビリティ)最適化手法を学べるワークショップでした。
Instance Scheduler というAWSソリューションは初耳でした。 結構使っている方いるのでしょうか。気になります。
ワークショップの有効期限を失念していたこと、とても後悔しています。 ガイドの内容が結構充実していました。 特に各セクションの Considerations には実際に移行を行う際の注意点や 効果測定の方法など、細かい話が書かれていました。 「あとで必ず見返そう」とやる気満々だったのですが、それも叶わず。 (後ほど公開してくれないかな…)
以上 re:Invent ワークショップレポートでした。
5
