Sustainability Pillar(持続可能性の柱)におけるベストプラクティス - Hardware and services-

記事タイトルとURLをコピーする

3月よりIE課(インターナルエデュケーション課) に異動しました山﨑です。

Well-Architected Framework の Sustainability Pillar(持続可能性の柱)についてブログを執筆しましたが、これらはSustainability Pillar(持続可能性の柱)の概念や設計原則といった抽象度が高い内容でした。そこで、今回はベストプラクティスの観点から具体的な内容に踏み込んで行きたいと思います。

おさらい

Sustainability Pillar(持続可能性の柱)とは

Sustainability Pillar(持続可能性の柱)については過去に2本のブログを執筆していますので、こちらをご覧ください。

blog.serverworks.co.jp

blog.serverworks.co.jp

Best practices for sustainability in the cloud

Sustainability Pillar(持続可能性の柱)では、ベストプラクティスとして以下の6つの観点を示しています。

Topic Summary
1 Region selection
(リージョンの選択)
パフォーマンス、コスト、Carbon footprint といったKPI指標に従ってワークロードをデプロイするリージョンを選択する。
2 Alignment to demand
(需要との整合性)
ユーザーのサービス需要やビジネス要件に合わせてインフラを拡張し、必要最低限のリソースのみ使用するよう継続的に調整する。
3 Software and architecture
(ソフトウェアとアーキテクチャ)
アーキテクチャーを見直して使用率の低いコンポーネントを統合し、全体としてリソース使用率の向上および最適化を図る。
4 Data
(データ)
ワークロードをサポートするために必要なストレージと、それを使用するために必要なリソースを削減するために適切なデータ管理手法を導入する。
5 Hardware and services
(ハードウェアとサービス)
ハードウェアの管理方法を変更することで、個々のワークロードに対して最も効率的なハードウェアとサービスを選択する。
6 Process and culture
(プロセスと文化)
開発/テスト/デプロイの手法を変更し、Sustainabilityへの影響を減らす機会を模索する。

上記のうち、Region selection については過去に詳細に記載された弊社ブログがありますので、そちらをご覧ください。ちなみに日本国内だと東京よりも大阪の方が炭素強度が低いです。

blog.serverworks.co.jp

Hardware and services(ハードウェアとサービス)

今回はベストプラクティスのなかでもHardware and services(ハードウェアとサービス) について整理していきます。

Best practices out of Hardware and services

Hardware and services(ハードウェアとサービス)のベストプラクティスは2023年8月時点で4つ紹介されています。

No Best practices Summary
SUS05-BP01 Use the minimum amount of hardware to meet your needs ワークロードに対して必要最小限のハードウェアを利用する。これにより、環境への影響を軽減したり、コストを削減したりすることができる。
SUS05-BP02 Use instance types with the least impact 新しいインスタンスタイプを使用することで、エネルギー効率の改善を図ることができる。
SUS05-BP03 Use managed services AWSマネージドサービスを利用し、ハードウェアそのものの運用等をAWSにアウトソースすることでAWSクラウド全体としてリソースの利用効率の向上が見込まれる。
SUS05-BP04 Optimize your use of hardware-based compute accelerators ハードウェアベースのアクセラレータの使用を最適化することで、ワークロードの物理的なインフラストラクチャの需要を減らすことができる。

docs.aws.amazon.com

What should we do in the end?

AWSドキュメント上ではベストプラクティスごとに実施ガイダンスが記載されていますが、全てを理解して実行することは容易ではありません。そこで、今回は比較的実施ハードルが低く、実践しやすいであろう内容を3つご紹介したいと思います。

1. AWSマネージドサービスを積極的に利用する

これは最もシンプルで分かりやすい実践方法です。例えば、EC2上でDBをホストせずにRDSまたはAuroraといったAWSマネージドなデータベースを利用するといったことが該当します。AWSマネージドサービスの利用には一定の制限はありますが、利用者の運用負荷軽減にも寄与するため導入メリットが大きい対応だと考えられます。

AWS環境で一からシステム構築をする際はもちろんですが、既存のオンプレミス環境からAWS環境へサーバー移行する際もマネージドサービスを検討してみてください。

AWSでは AWS Application Discovery Service と呼ばれるサービスがあり、オンプレミスで稼働しているサーバー情報(OS、ネットワーク設定、CPU、メモリ、ストレージ)やパフォーマンスデータ(CPU、ディスクI/O、ネットワークトラフィック)を取得することができるため、これらの情報を元にAWSマネージドサービスの利用を検討することが可能です。

2. Compute Optimizer を用いてインスタンスタイプを見直す

Compute Optimizerは、デフォルトで最大過去14日間のCloudWatch メトリクスの値を分析することでコンピューティングリソースのスペックが最適かどうかを評価し、推奨されるインスタンスタイプ等の推奨事項を表示するAWS サービスです。

Compute Optimizer の推奨事項に従ってリソースタイプを変更することでコンピューティングリソースのサイジングを適正化します。

ちなみにCompute Optimizer がサポートしている AWS サービスは、EC2、EBS、EC2 Auto Scaling Group、AWS Lambda、Fargate(ECS) の5つです。

詳細については以下のブログをご覧ください。

blog.serverworks.co.jp

blog.serverworks.co.jp

3. Trusted Advisor を用いて使用率が低いリソースの利用を見直す

Trusted Advisorは、AWSのベストプラクティスにもとづいてAWSアカウントの状態を評価し、改善に向けた推奨事項を提案するAWSサービスです。

Trusted Advisor の推奨事項に従ってリソースの利用を見直すことでコンピューティングリソースの利用状況を適正化します。

以下、Trusted Advisor でチェックすることができる内容の一例ですが、例えば利用頻度が低いAmazon EBSボリュームはそもそもEBSボリューム自体が利用されていない可能性があるため、ボリュームの削除を検討することができます。

チェック項目 概要
使用率の低いAmazon EC2 インスタンス 過去 14 日間に常時実行されていた EC2 インスタンスをチェックし、 4 日以上の間 1 日あたりの CPU 使用量が 10% 以下で、ネットワーク I/ O が 5MB 未満であった場合に警告する
利用頻度の低いAmazon EBS ボリューム EBS ボリュームの設定をチェックして、ボリュームが十分に使用され ていない可能性を警告する
Amazon EBSの過剰にプロビ ジョニングされたボリューム ワークロードについて過剰にプロビジョニングされた EBS ボリューム があるかどうかをチェックする
Amazon RDSアイドル状態の DB インスタンス アイドル状態になっていると思われる DB インスタンスの RDS の設定 をチェックする
アイドル状態のLoad Balancer 関連付けされたバックエンドの EC2 インスタンスが存在しないなど、ア クティブに使用されていないロードバランサーの設定をチェックする

まとめ

今回は、Sustainability Pillar(持続可能性の柱)におけるベストプラクティスのうちHardware and services(ハードウェアとサービス)についてブログを書いてみました。Sustainability Pillar に限りませんが、Well-Architected Framework を読み解き、理解するためには様々な分野の知識が必要となるため一筋縄ではいかないですね。今後も精進していきます。

山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ

カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers