COLUMN

1. 書こうと思ったきっかけ

昨年行われたre:Invent2022や、先日行われたAWS Summitに参加したところ、基調講演やスペシャルセッションにおいてサステナビリティについて語られていること、そしてこうしたテーマに応じたセッションだけではなく会場全体で環境面やダイバーシティに配慮された空間があり、かなり重要なテーマにもかかわらず、エンジニアサイドからはあまり触れられていないテーマであると感じました。

また、この取り組みは日本だけではなく、各国のAWS Summitで触れており、たとえばドイツで行われたAWS Summit Berlinではウクライナ政府のデータの移行を通じて平和支援に貢献した事例紹介など、各国の関心の高いテーマを中心に共通的に話されているようでした。

一方で、日本の各企業においても、サステナビリティに関する取り組みは広がってきており、経営課題となってきております。

例えば、NTT東日本もサステナビリティに関して、パーパスに応じて下記のようなサステナビリティステートメントを定めております。

• 地域活性化
• 脱炭素・循環型社会の実現
• 高品質で安定した通信サービスの提供
• 多様な社員が成長できる職場づくり

参照：NTT東日本グループのサステナビリティ

こうした取り組みによって、企業はただ利益を追求するだけではなく、社会貢献を数字で求められることが大切になってきております。

2. サステナビリティと技術革新について

サステナビリティは経営目線では非常に大切な項目ですが、一方でエンジニア目線ではどうでしょうか？

技術革新の方向性としては、「新技術の提供(AIなど)」と、「サービスの効率的な提供(コスト削減など)」があると思います。

サステナビリティは後者を実現する形になりますが、「環境負荷を下げる」「電力消費量を下げる」といった課題解決も工夫が必要で、仮に1回しかできないワークロードを実行するよりも、継続的に実行できるワークロードのほうが影響度という点では大きいと考えます。

したがって、新技術を投入した次のフェーズで継続的に提供し続けるためには、サステナビリティに貢献する必要があります。

3. AWSを利用したサステナビリティへの貢献

経営目線においてもエンジニア目線においてもサステナビリティにおいては貢献が必要というお話をさせていただきました。

ようやく本題ですが、AWSを使ってどのようにサステナビリティに貢献するのかをお話ししていければと思います。

主にテクノロジーで貢献できる観点では、環境面への貢献になります。

大原則としては、なにもクラウドに限った話ではなく「電力使用量を下げる」「二酸化炭素排出量を下げる」「ごみの排出量を減らす」など、一般的な貢献と大きく異なる箇所はありません。

クラウドに特化すると、環境面の貢献に対しては二つのアプローチがあり、「クラウド事業者側のアプローチ」「利用者側のアプローチ」の二つとなります。これはクラウドサステナビリティにおける責任共有モデルといわれております。

出典：AWS Well-Architected Framework

4. AmazonおよびAWSのサステナビリティ

これは、先に挙げた「クラウド事業者側のアプローチ」となります。

主なものを見ていきたいと思います。

4-1. 再生可能エネルギーを利用する

AmazonおよびAWSでは、2025年までに100%再生可能エネルギーで事業運営ができるよう進められており、AWSが運営されているデータセンタでどの程度再生可能エネルギーを使われているか公開されております。

2021年現在では95%再生可能エネルギーで運営されているリージョンは北米や欧州を中心に13リージョン、日本のリージョンではまだ割合は公表されておりませんが、2か所の太陽光発電システムが運営されていることが公表されております。

出典：Amazon | Sustainability| Renewable Energy

4-2. Water Stewardship

データセンタの運営にあたり、機器の冷却のための水の使用量削減についても触れられております。

日本だと「水と安全はタダ」といわれるようにあまり課題に感じることは少ないですが、世界では淡水の確保が課題となっている地域が多くあり、SDGsの6番目「安全な水とトイレを世界中に」の課題に貢献することになります。

AWSでは2030年までに使用する水よりも、世界中に届ける水の量を多くする「Water Positive」にコミットしており、再生可能水での運営ができるようにプロジェクトを進めているようです。

4-3. 電力使用量を下げる

AWSでの電力使用量を下げるためには、主に3つの取り組みを行っています。

「電力効率」「冷却効率」「パフォーマンスの予測と追跡」となります。

電力効率においては、AWSで独自開発したチップやNitro systemと呼ばれるプラットフォームを使い効率化を行っております。

とくに、最新世代のGraviton3というチップを使ったEC2インスタンスはそうでないインスタンスと比較して、同パフォーマンスで電力消費量が最大60%削減され、特に機械学習のようなシステムで効果を発揮しています。

冷却効率においては20%の削減が見込まれているとのこと。

こうしたパフォーマンスを追跡、予測することで最適化を行っております。

5. AWSを利用したサステナビリティ

こちらは「利用者側のアプローチ」となります。

AWSでのサステナビリティを実現するためにやることの大方針は変わりません。

「再生可能エネルギーを使う」「電力使用量を下げる」の2点が基本方針となります。

実際にサステナビリティを実現する指標として、AWS Well-architected Frameworkの中に

サステナビリティの柱、というものがあります。

これは、2021年12月のre:Invent2021で発表され、その他の5本の柱と同様クラウド利用時にアーキテクチャを評価し、

効率的に使うアプローチとなります。

読んでいて理にかなったアプローチと思いますので、ここからはAWS Well-architected Frameworkのサステナビリティの柱に基づいてお話していきたいと思います。

大きく分けると４つの観点があります。

5-1.削減目標を決め、実行計画を立てる

削減目標はどうするのか、これは課題解決のアプローチとして一般的に求められるものです。

経営計画や、サステナビリティ計画の中で決められるものかもしれませんが、決まってからアプローチするのではなく、策定の段階から経営層を巻き込んで行くことが大切です。

実際の目標が決まったら、実行に移していきます。

アーキテクチャの変更を伴う場合がほとんどですので、クラウド移行する際と同じく一部でテストし、全体へ展開し、最終的な効果測定を行うことが必要です。

しかしながら、可用性やパフォーマンス効率とはトレード・オフの関係になります。

サステナビリティを優先するあまり、可用性やパフォーマンス効率を犠牲にすべきである、ということではなくWell-Achitected Frameworkの基本は「何を優先し、何を優先しないか」を定めることになります。

5-2.再生可能エネルギーの使用率など、削減率に合わせたリージョンを選択する

リージョン選択が最初になります。「そもそもサステナビリティが高いリージョンを選べば、目標達成に近づく」という考え方です。

リージョン選択の要件としては、他にも遅延の度合い、コンプライアンス上データ保存場所に制約がある、などを踏まえて選択する形になります。

執筆日時点では残念ながら日本のリージョンは必ずしもサステナビリティの観点で効率的なリージョンとは言えないのですが、2025年のAWSの目標を踏まえて近い将来の達成を見越し、他のリージョンで削減率をテストし、日本のリージョンで期待できる達成度を測っておく、という戦略もあります。

どうしても直近に達成する必要がある、という形であれば、海外のリージョンを選択し、

日本のリージョンが再生可能エネルギーで運用を始めた際に移行するという形もとれますが、このあたりはコストも見据えて戦略を決定する必要があります。

5-3.リソースの最適化を行う

リージョンを選択したら、基本的な戦略は「いかにリソースを効率的に使うか」という形になります。

無駄なリソースを持たないことで、電力使用量をはじめサステナビリティに貢献することができます。

5-3-1. 伸縮性を柔軟にもたせる、マネージドサービスを利用する

クラウドの基本は「使用した分だけ利用する」ですが、サステナビリティの観点では待機しているだけのEC2インスタンス・FargateのCPUは積極的に見直していく必要があります。

インスタンスサイズの最適化、AutoScaling可能なリソースはAutoScalingを活用していきましょう。

また、マネージドサービスを積極的に利用することで、電力効率はAWS側が管理する形になります。

5-3-2. CPU利用時間を下げる

CPUを効率的に使っていくことも必要なアプローチとなります。

そもそもの処理量を減らすために、コードの最適化や、Lambdaを利用したイベントドリブン型のアーキテクチャを使用することで最適化を目指すアプローチもあります。

コードの最適化はリファクタリングなどにかかる稼働も多いですが、得られる効果も大きくなります。

CodeGuruなどのレビュープロセスを使用する、APMで負荷の高いプロセスを特定する、効率的なプログラミング言語を選択する、無駄なアルゴリズムを効率化するなどがあります。

また、使用していないコンポーネントを停止する、削除するといった行為も必要な工程となります。

CloudWatchなどの運用データや、安定したワークロードであればAWS Compute Optimizerを使用してインスタンスサイズを最適化する、使用率の低いRDSインスタンスから、複数の小さなデータベースをプロビジョニングして集約するといった行為も効果的です。

5-3-3. データ使用を効率化する

データアクセスの最適化を行うことで、永続的に保存されているデータを減らすことも効果的です。

基本的には、他の柱で問われているような効率性や可用性を追い求めることとアプローチはそう変わりません。

例えば、このようなアプローチがあります。

データの特性やアクセスパターンを分析して必要なデータベースやストレージサービスを選択する。

データの転送を減らして、ネットワーク転送容量を減らす。

データ形式を選択し、クエリのパフォーマンスを改善して処理時間を減らす。

S3のライフサイクルポリシーを設定して、効率的なデータ保管を行う

5-3-4. 効率的なハードウェアの利用

電力効率に優れたハードウェアを使用する、というアプローチになります。

具体的なアプローチ例としては、インスタンスタイプを最適化する（メモリが必要なのに、計算用のインスタンスを使ってないかというのもあります）、ARMベースで動くのであれば、Gravitonを使用するといったアプローチとなります。

一時的に多くのリソースを使うが、追加のインスタンスを構築する必要性が低いものであれば、バースト可能なインスタンス(tシリーズ)を選択する手もあります。

また、機械学習のワークロードは昨今非常に大きなコンピュートリソースを必要としますので、GPUベースのインスタンスではなく、できるだけTrainumやInferentiaなどワークロードに特化したハードウェアを使用するといったアプローチも効果的です。

ここでも必要なことは継続的なモニタリングと改善になります。運用データをもとに定期的に改善していく仕組みを整えることが大切です。

5-4. 効果を測定する

リソースの最適化に運用データを使いました。しかしながら、どの程度サステナビリティに貢献できているかを可視化するツールではありません。

こうした環境への貢献度を可視化することで効果測定が可能となります。

たとえば、このようなツールで自身のAWSアカウントでどのくらい貢献できているかを可視化できます。

• AWS Customer Carbon Footprint Tool

このツールで、炭素排出量を可視化、オンプレミスで同ワークロードを実行した場合と比較した比較も可能となります。

場所ごとの排出量や、サービスごとの排出量も統計で取ることができます。

残念ながら執筆時時点では電力消費量を可視化するツールはございませんが、今後こうしたツールが出てくることも期待されます。

可視化して効果を示すことができることで、経営課題の解決度合いをチェックできるというのはうれしいですね。

6. サステナビリティを意識した結果、他に得られること

ここまではサステナビリティに貢献する観点で見てきましたが、

すでにお気づきの方もいらっしゃるかと思いますがこれらのアプローチを行った結果、こんな効果も得られます。

• AWS利用コストの削減（リソースの最適化により、無駄なリソースの使用量が下がる効果）
• 可用性・信頼性の向上（マネージドサービスを活用することで貢献）

サステナビリティは一見遠回りのように見えて、実はAWSを最適に使うための道筋の上にもあり、皆様のクラウドシフトに貢献できる効果を持っています。

7. 最後に

ここまでAWSを使ったサステナビリティへの貢献というテーマでお話してきました。

NTT東日本のクラウドソリューションにおいても、タイマーを活用したEC2インスタンスの最適化、コスト最適化などを通じてサステナビリティに貢献できるソリューションを持ち合わせておりますので、お気軽にお問い合わせください。

クラウド経験の高い担当者がご支援させていただきます。

• Amazon Web Services(AWS)は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。