この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
AWS Summit 2023 に2日間現地参加しました。4/21に行われた以下のセッションを聴講しましたので、セッションレポートをまとめます。
- AWSセッション（AWS-58）
- サステナブルなアーキテクチャをはじめませんか？ AWS が考えるサステナビリティジャーニーの３つのステップ
セッション概要
スピーカー：
アマゾン ウェブ サービス ジャパン合同会社
デジタルトランスフォーメーション本部
マイグレーション&モダナイゼーションソリューションアーキテクトマネージャー
内村 友亮 氏
デジタルトランスフォーメーションは数か月あるいは数年で結果につながる一方で、サステナビリティは数十年かかると言われています。これは長い道のりであり、成果を出すために適切な目標を設定する必要があります。これを実際に行うにはどうすればよいでしょうか？ AWS は、先行するケーススタディから、企業のサステナビリティ ジャーニーは３つのステップで進むと考えています。また、新たに追加された AWS Well-Architected Sustainability の柱を使用すると、エネルギー節約のためのベストプラクティスを通じて、温室効果ガス排出量をさらに削減できます。そして、自社の温室効果ガス排出量のモニタリングや、分析、将来予測には、AWS Customer Carbon Footprint Tool を使用することができます。本セッションでは、AWS が考える企業 IT のサステナビリティを加速する３つのステップと 支援ツールについてご紹介します。
ちなみに内村氏が好きな資料は 451 Research Report とのこと。
セッション視聴
AWS Summit Tokyoの登録を行うことで2023/6/23までオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）
登録済みの場合、以下から直接遷移できます。
セッションレポート
想定オーディエンス
- 情報システムを管轄するチームのテクニカルリーダー
- 持続可能な IT インフラストラクチャを設計しなければならない
- が、何やからやらなければいいか、どれくらい大変かが分からない
- 持続可能な IT インフラストラクチャを設計しなければならない
- 情報システムを管轄するチームのビジネスリーダー
- 会社の役員や DX を推進するチームから持続可能性のテーマが展開され IT インフラストラクチャの使い方を見直す企画書を書くことになった
AWSに慣れ親しんだ方向けというわけではないので、AWSの専門用語などをしっかり説明していきます、ということで始まりました。
カスタマーがサステナブルなアーキテクチャに取り組む理由
サステナビリティトレンドの増加
- 顧客需要
- 政府による規制
- 従業員需要
- 企業に採用される際に重要視、社会活動への貢献を気にしている
- インパクト投資
- ESG基準、メディア、投資目録書に出てくる
- 競争優位性としてのサステナビリティ
「上記の要因についてどのくらい当てはまりますか？（取り組まれていますか？）」
ここで、聴衆に向けて挙手でのアンケートが行われました。わたしが最前列に座っていたので全体を見れていない部分もありますが、大体以下の結果でした。
| 選択肢 | 挙手人数（目視） |
|---|---|
| 全部当てはまる | ほぼいない |
| 半分くらい当てはまる | チラホラ（数十〜100程度？） |
| ほぼやっていない | 上記より少ないがチラホラ |
サステナビリティトランスフォーメーション
サステナビリティトランスフォーメーションの課題例
- 温室効果ガス排出量が高まっている箇所を特定するにはどうしたらいい？
- 事業運営でエネルギーと水資源の使用量を削減するには？
- サステナビリティの変革の達成のために迅速にイノベーションするには？
- 温室効果ガス排出量削減に向けてバリューチェーン内の他の企業と協力するにはどうしたらいいか？
企業としてサステナビリティを促進していくには上記のような観点を気にする必要があるのですね。普段あまり意識したことがない観点でした。
どの課題においても、無駄を減らすというのが大事な観点です。AWSはエラスティックであり、必要時にのみリソースを作成することで二酸化炭素削減に寄与する、とされました。
AWS が考えるサステナビリティジャーニー３つのステップ
- ３つのステップ
- 移行：クラウドとAWSの効率性を有効活用
- 最適化：AWS Well-Architected Framework サステナビリティの柱を活用しワークロードを最適化
- 変革：データ、AWSプロフェッショナルサービス、デジタルイノベーションプログラムを活用
移行
- 二酸化炭素排出削減の可能性
- クラウドのワークロードは、オンプレミスデータセンターの平均的なワークロードに比べ二酸化炭素排出量を80％近く削減できる
- 削減の内訳
- 67%：クラウドサーバーの高いエネルギー効率と利用度
- 11%：クラウド施設がより効率的な電力系および冷却システムを利用
- 15%：（今後）再生可能エネルギーを利用可能になることによる削減
- AWS ITトランスフォーメーションパッケージ
- 検討、評価、準備、移行のフェーズからなる
- 検討・評価のフェーズの後に「意思決定」があり、それより前は無償で提供、それより後は無償・有償・クレジットのプログラムがある
AWS IT トランスフォーメーションパッケージについては、AWS Summit 当日に発表された以下ブログに詳しいです。
最適化
最適化のステップとして、2021年12月に AWS Well-Architected Framework に追加されたサステナビリティの柱が取り上げられます。
- サステナビリティの柱におけるベストプラクティス
- リージョンの選択
- 再生可能エネルギープロジェクトに近いリージョンを選択
- 参考：Sustainability in the Cloud - Amazon Sustainability
- ユーザーの行動
- ユーザー負荷に合わせてインフラストラクチャをスケールする
- SLAを持続可能性目標に合わせる
- 未使用のアセットの創出やメンテナンスをなくす
- ワークロードの地理的配置を最適化
- チーメンバーのリソースを最適化
- ソフトウェアとアーキテクチャ
- 非同期ジョブおよびスケジュールされたジョブに最適化
- 使用率が低いコンポーネントの削除またはリファクタリング
- 時間やリソースを多く消費するコードの最適化
- デバイスや機器への影響を最適化
- データアクセスとストレージパターンのサポートを踏まえた選定
- ハードウェア
- ニーズに合わせて最小限に使用する
- 影響が最も少ないインスタンスタイプを使用する
- マネージドサービスを使用する
- GPUの使用を最適化する
- データ
- データの分類ポリシーの実装
- データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用
- ライフサイクルポリシーによる不要なデータの削除
- ブロックストレージの過剰プロビジョニングを避ける
- 不要または冗長なデータの削除
- 共通データへのアクセスには共有ファイルストレージやオブジェクトストレージを使用
- ネットワーク間でのデータ移動を最小限にする
- バックアップ対象を選定する
- 例：Amazon S3 Intelligent-Tiering を使用する
- 開発およびデプロイプロセス
- 持続可能性の改善を迅速に導入できる方法を採用する
- ワークロードを最新に保つ
- ビルド環境の使用率を増加させる
- マネージド型 Device Farm を利用してテストをする
- 例：開発環境では台数を減らす代わりにオートヒーリングを使う
- リージョンの選択
また、2022年3月に発表された Customer Carbon Footprint Tool についても取り上げられました。
- AWS Customer Carbon Footpint Toolの提供
- データの視覚化でわかりやすい画面構成
- ビリングコンソールから参照可能
変革
- サステナビリティのユースケースを特定する
- カーボンフットプリントの可視化
- サステナブルなビルディング
- エネルギー分析と予測
- ウォータースチュワードシップ
- 製造と流通
- サステナブルで責任あるサプライチェーン
- サステナブルな梱包
- サーキュラーエコノミー（循環型経済）
- AWSソリューションを活用する
- AWSサステナビリティスペシャリストとパートナーと協力し、
- AWSサービスを利用し、
- 各ユースケースに即したガイダンスとソリューションを活用
- サステナビリティデータ：オープンデータと商用データ
サステナブルなアーキテクチャを始めませんか？
二酸化炭素排出量の追跡の自動化
- もし自前で実装しようとするとたくさんのモジュールが必要
- ゼロから考えるのは大変ですよね
- フレームワークで用意しています
サステナビリティトランスフォーメーションの課題例（再掲）
- できるところから小さく始めましょう
- 無駄を減らす、というのが一番大事な観点です
3つのステップ（再掲）
- 3つのステップ
- 移行：クラウドとAWSの効率性を有効活用
- 最適化：AWS Well-Architected Framework サステナビリティの柱を活用しワークロードを最適化
- 変革：データ、AWSプロフェッショナルサービス、デジタルイノベーションプログラムを活用
- 場合によっては「変革」から始まることもあると思うが、ステップを1から順にやってもらうのが一番
- 適切な利用を最大化して、無駄や重複を排除、が大事
- できるところから始めてみましょう、例えば Instance Scheduler を利用してみるのも一つの手段
サステナビリティトランスフォーメーションと聞くと大仰な気もしますが、EC2 インスタンスの常時稼働をやめて不要時には停止させる、というのも結果的には二酸化炭素削減に寄与しています。そう考えるとハードルが低くなりますね。
終わりに
「サステナブルなアーキテクチャをはじめませんか？ AWS が考えるサステナビリティジャーニーの３つのステップ」のレポートでした。
普段わたしが AWS 利用のご支援をする際には「コスト効率」「耐障害性」「運用負荷」などを考慮することが多く、それは言ってみれば「技術寄り」な視点だと思います。それに対して今回のテーマであったサステナビリティは「ビジネス寄り」な視点の印象であり、普段なかなか意識しない領域であったため新鮮に聴講しました。
とは言え大事な観点はセッション中に繰り返し出てきた「無駄を減らす」であり、それは技術寄りな視点とも密接に関わっていると感じました。不要なリソースやデータを削減する、という試みはコスト削減とともにエネルギー削減にも繋がるのだな、と認識しました。
手軽に取り組める部分としては EC2 のインスタンスタイプを最適化する、必要時のみ稼働させる、といったものがあると思います。EC2 インスタンスや RDS DB インスタンスの自動停止・起動のジョブ実行は弊社のツール opswitch をご利用いただくと手軽に実装できますのでお試しください（宣伝）。
以上、 チバユキ (@batchicchi) がお送りしました。
0
