AIはどの程度エネルギーを使用するのか
開発者プラットフォームHugging Faceで気候問題を担当するSasha Luccioni博士が最近の論説で認めているように、AIが消費するエネルギー量はまだ正確には把握されていない。これは、エネルギー使用量に関するデータを公開している企業が非常に少ないためである。
Boston Consulting Groupは、2030年までにデータセンターが米国の全電力消費量の7.5％を占めるようになると推定している。これは、米国の4000万世帯分の電力消費量に相当する。
現在、世界のデータセンターは世界の電力の約1.5％を消費しており、これは航空産業全体の消費量とほぼ同等である。そして、この割合はさらに増加する可能性が高い。
国際エネルギー機関（IEA）が発表した4月の報告書によると、世界のデータセンターの電力使用量は2017年以降、毎年12％増加しており、これは「総電力消費量の増加率の4倍以上」に相当する。
他のエネルギー使用量がほぼ横ばいであるにもかかわらず、AIによって直接的あるいは間接的に推進されているデータセンターは、世界のエネルギー消費に占める割合が増加している。
⇧ 単純に「データセンター」を所有する「クラウドサービスプロバイダー」の「サービス」を利用する顧客が増加しただけかもしれないし、「ファクト（Fact）」となる「データ」がほとんど公開されていないのなら、統計・分析の精度も推測レベルということになりそうなのよね...
まぁ、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 正確な情報が無いことに因る弊害は、人口に膾炙するようになってきていると思われるので、「データセンター」を所有する「企業」側が「電力消費量」に関する「データ」を提供してくれないことには、分析が意味をなさない気がしする...
勿論、公開される「データ」が改竄や捏造がされていない前提の話になるのだが...
「データ駆動（DD：Data Driven）」で「データ」の重要性が話題に上がるのだが、未だに活用されていないケースが多いのね...
「電力会社」が「契約」してくれている「企業」に対して「請求」する必要上、「電力会社」は「契約」してくれている「企業」の「電力消費量」を「記録」しているはずなので、「電力消費量」の内訳は分からないまでも「企業」が「データセンター」で利用した「総消費電力量」は把握できるはずなので、公開されないということは「企業」側が許可しないということになる気がするので、「企業」側に何か「やましいこと」があるのかと思ってしまうのよね...
異なるAzure 仮想ネットワークに配置されたAzure 仮想マシン間で通信する方法はいくつ用意されているのか
公式のドキュメントを見た限り、
⇧ 通信のパターンとしては、様々あるようなのだが、今回は、
- 同一のAzure リージョン（Azure region）
- 同一のAzure 可用性ゾーン（Azure availability zone）
- Azure 仮想マシンはIaaS（Infrastructure as a Service）に該当
- 異なるAzure 仮想ネットワークに配置されたAzure 仮想マシン間での通信
を実現する方式の選択肢を知りたい。
「Phind」で質問してみたところ、以下の5つの候補が回答として返ってきた。
| No | 機能 | VNet ピアリング | グローバルVNet ピアリング | VNet-to-VNet | VPN ゲートウェイ | ExpressRoute |
|---|---|---|---|---|---|---|
| 1 | リージョン間接続 | ✖ | ✅ | ✅ | ✅ | ✅ |
| 2 | ゲートウェイ要件 | 不要 | 不要 | 必要 | 必要 | 必要 |
| 3 | パブリックIP | 不要 | 不要 | 必要 | 必要 | 不要 |
| 4 | セキュリティ | Microsoftバックボーン | Microsoftバックボーン | IPsec/IKE | IPsec/IKE | 専用回線 |
| 5 | トラフィックコスト | 無料 | 出向きトラフィック課金 | ゲートウェイコスト | ゲートウェイコスト | 専用回線料金 |
| 6 | 設定複雑度 | 低 | 低 | 中 | 中 | 高 |
| 7 | 遅延 | 最低 | 低 | 中 | 中 | 低 |
| 8 | スケーラビリティ | 中 | 高 | 中 | 中 | 高 |
ただ、「Azure VPN ゲートウェイ」と「Azure ExpressRoute」については、
間の通信を実現することを目的とした「サービス」という気がするので、今回の要件を実現するケースでは、実質、
- VNet ピアリング
- グローバル VNet ピアリング
- VNet-to-VNet
の3つの選択肢が用意されていると言えそう。
各々の方式の特徴については、以下の回答が返ってきた。
| No | 方法 | 特徴 | 適している場面 | 制限事項 |
|---|---|---|---|---|
| 1 | VNet ピアリング | - 直接接続 - 同じリージョン内での低遅延 - シンプルな構成 |
- 同じリージョンのVNet間 - 高速な通信が必要な場合 |
- 異なるサブスクリプション間は制限あり - ゾーン間の制限あり |
| 2 | グローバル VNetピアリング | - リージョン間接続 - Microsoftバックボーンネットワーク使用 - ゲートウェイ不要 |
- 異なるリージョンのVNet間 - グローバル展開が必要な場合 |
- 出向きトラフィックに対する課金 - ゾーン間の制限あり |
| 3 | VNet-to-VNet | - ゲートウェイを使用した接続 - 複数VNet間の接続可能 - ルーティング自動設定 |
- 異なるリージョンのVNet間 - 複数VNet接続が必要な場合 |
- ゲートウェイのコスト - 設定が複雑 |
| 4 | VPN ゲートウェイ | - 安全な暗号化接続 - IPsec/IKEプロトコル使用 - フェールオーバー対応 |
- セキュリティ重視の環境 - オンプレミス接続 |
- ゲートウェイのコスト - 遅延が発生する可能性 |
| 5 | ExpressRoute | - 専用回線による接続 - 高帯域幅 - 安定した品質 |
- 大規模なデータ転送 - 低遅延が必要な場合 |
- 初期投資と運用コストが高い - 物理的な接続ポイント必要 |
各々の方式の構成概要図は以下のような形になるらしい。
■1. VNet ピアリング
- 青色のボックスは仮想マシン（VM）を表し、アドレス範囲内のIPアドレスを持ちます。
- 黄色のボックスはゲートウェイサブネットを表し、VNetピアリングの設定に使用されます。
- 実線は直接的な通信経路を、点線はピアリング接続の管理経路を示しています。
- 各VNetには異なるアドレス範囲が設定されており、重複しないように設計されています。
■2. グローバル VNet ピアリング
- 青色のボックスは仮想マシン（VM）を表します。
- オレンジ色の部分がMicrosoftのバックボーンネットワークで、高速かつセキュアな接続を提供します。
- 実線は直接的な通信経路を示し、ゲートウェイやパブリックIPアドレスが不要です。
- 各VNetには異なるアドレス範囲が設定されており、重複しないように設計されています。
■3. VNet-to-VNet 接続（ゲートウェイ経由）
- 青色のボックスは仮想マシン（VM）を表します。
- 黄色のボックスはVPNゲートウェイで、IPsec/IKEプロトコルによる暗号化接続を確立します。
- パブリックIPアドレスにより、外部からの接続が可能になります。
- 実線は安全なVPNトンネルを通じた通信経路を示しています。
- 青色のボックスは仮想マシン（VM）を表します。
- 黄色のボックスはVPNゲートウェイで、IPsec/IKEプロトコルによる暗号化接続を確立します。
- パブリックIPアドレスにより、外部からの接続が可能になります。
- 実線は安全なVPNトンネルを通じた通信経路を示しています。
■5. Azure ExpressRoute
- PE（Provider Edge）：ExpressRouteサービスの提供者側のルーター。
- MSE（Microsoft Enterprise Edge）：Microsoft側のルーター。
- BGP（Border Gateway Protocol）：ルーティング情報の交換に使用。
- プライベートピアリング：インターネットを経由せず、専用回線で接続。
- 青色のボックスは仮想マシン（VM）を表し、VNet内で動作します。
とりあえず、今回の要件だと「Azure VNet ピアリング」を選択する感じになるのかなぁ...
「ネットワーク」何も分からん...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
