re:Invent 2024: AWSとGE Vernovaによるグリッド制御システム近代化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate control system upgrades through AWS and evergreen testing (ENU306)
この動画では、AWS for Energy and UtilitiesのFarnaz Aminが、エネルギー業界が直面する課題とAWSの取り組みについて説明します。GE VernovaのSean MoserとPPLのJames Lieroを交えて、グリッド制御システムの近代化について議論します。再生可能エネルギーの増加、AIデータセンターの電力需要、分散型エネルギーリソースの普及といった課題に対し、GE VernovaのGridOSとEvergreenアプローチを用いた解決策を紹介します。PPLでの実装例では、Customer Reference Environment（CRE）を活用することで、インストール時間を92%、テスト時間を96%削減し、停電を21%削減、復旧時間を17%短縮できた具体的な成果が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
エネルギー業界の課題に挑むAWSとGE Vernova
「Accelerate Grid Control System Upgrades using AWS and Evergreen Testing」のセッションへようこそ。私はAWS for Energy and UtilitiesのGrid Modernization担当ビジネス開発責任者のFarnaz Aminです。クラウドテクノロジーを活用してグリッドイノベーションを加速するため、世界中のお客様やパートナー様とお仕事をさせていただいています。本日はGE VernovaのSean MoserとPPLのJames Lieroにもご参加いただいています。ご参加ありがとうございます。
まず始めに、これから1時間で取り上げる内容について簡単にご説明させていただきます。エネルギー業界の状況について文脈を提供し、AWS for Energy and Utilitiesの私たちが誰で、業界特有の課題をどのように解決しているのかについてお話しします。その後、Hybrid cloudの概念についてご紹介します。続いてSeanが、GE Vernovaとそのお客様が現在のエネルギー業界で直面している課題と、それらの課題に対応するために開発したソリューションについて説明します。そしてJimが、このソリューションをどのように実装し、どのような経験を得て、このプロジェクトからどのようなメリットを享受しているかについてお話しします。
エネルギー業界の変革と AWS for Energy and Utilities の取り組み
まず、今日私たちが解決しようとしている問題の規模を理解していただくために、エネルギー業界の状況についてより詳しくご説明させていただきます。エネルギー業界は現在、複数の要因が重なって大きな変革期を迎えています。その一つが供給の脱炭素化です。再生可能エネルギーが導入され、全体のエネルギーミックスに占める割合が現在の30%から2030年には50%に急増すると予測されていますが、再生可能エネルギーの特性上、これにはいくつかの課題が伴います。さらに、世界中で多くの再生可能エネルギーと蓄電プロジェクトが系統連系を待っている状況です。米国だけでも、系統連系プロセスに何年もかかることや、許認可の課題、送電網の混雑により、1000ギガワットの再生可能エネルギーと400ギガワットの蓄電設備が連系を待っています。
供給の脱炭素化を進める一方で、需要側では電力消費が急速に増加しています。これまでは需要曲線が横ばいでしたが、新興国のニーズ、産業・建物・輸送の電化により、現在は増加傾向にあります。最近では、AIデータセンターや暗号資産関連施設からの需要が顕著です。これらの需要は2026年までに倍増し、日本の総電力消費量に匹敵する規模になると予測されています。
もう一つの大きな変化が分散化です。これは屋根置き太陽光発電、家庭用蓄電池、EVなどの分散型エネルギーリソースの増加によるものです。お客様は電力の消費方法により深く関わるようになり、クリーンな電力を選択的に消費し、グリッドに貢献したいと考えるようになっています。これらの変化が総合的に電力網に圧力をかけ、これまでとは異なる運用を求めています。再生可能エネルギーを受け入れ、需要と供給のマッピングを行い、エンドユーザーに信頼性の高い手頃な価格のサービスを維持しながら、これらの変化に対応する必要があるのです。
Jim、業界で見られる変化と課題について、あなたの視点からさらに付け加えることはありますか？「私たちが目にしている変化は非常に速いペースで起きています。そして電力会社として、私たちもその速度に対応していく必要があります。従来、私たちは直面している課題に対処するために3〜5年のアップグレードサイクルで動いていました。このプレゼンテーションの後半で説明しますが、私たちは多様化するエネルギーが電力網に入ってくることで生じている課題をより迅速に解決できるよう、そのプロセスを加速させています。」ありがとうございます。
では、AWSはこれらの課題をどのように解決しているのでしょうか？また、どのように組織化しているのでしょうか？AWSには、私が所属している AWS for Energy and Utilities という専門のビジネスユニットがあり、エネルギーおよび公益事業分野における顧客固有の課題解決に注力しています。私たちは、400人以上のエネルギー専門家を擁するエネルギー分野の専門知識と、幅広い技術知識およびクラウドの専門知識を組み合わせて活動しています。これにより、お客様の課題と、それを解決できる技術ソリューションとの橋渡しが可能となっています。
このビジネスグループの一環として、私たちは業界特有のソリューションと、技術を活用して課題に対処する方法についてのガイダンスを提供しています。また、エネルギー業界にとって重要なトピックであるセキュリティとコンプライアンスについてもサポートしています。さらに、お客様のデータ戦略についても支援しており、基盤となる課題や、これらの課題を解決するためのデータ組織化について検討します。加えて、私たちは大規模なパートナーネットワークを持っており、これらの課題解決を支援できるパートナーコミュニティと、AWSを使用してソリューションを構築するすべてのパートナー間でベストプラクティスを共有しています。
昨日の Matt Garman による基調講演でお聞きになった方もいらっしゃると思いますが、金融サービスのお客様は以前、セキュリティやコンプライアンス、規制、レイテンシー要件など、さまざまな理由で本番環境のワークロードをクラウドに置くことは決してないと言っていました。AWSは10年以上かけて、これらの懸念事項一つひとつに対応してきました。現在では、それらの金融サービス企業のほとんどがAWSのお客様となり、本番環境のワークロードにクラウドを利用しています。エネルギー業界も同様に、高度なセキュリティと厳格な規制が必要とされ、コンプライアンス規制をソリューションに組み込む必要があります。
公益事業のお客様は、さまざまなワークロードでクラウドを使用していますが、現時点でクラウドへの移行が容易でないワークロードもあります。これは、規制上の理由や、一桁ミリ秒のレイテンシー要件を持つアプリケーションとの統合が必要な場合、あるいはローカルデータセットが必要な場合などが考えられます。このような状況では、AWS Hybrid Cloudが、オンプレミス、クラウド、エッジのいずれであっても、お客様が必要とする場所で一貫したAWSエクスペリエンスを提供します。
AWS Hybrid Cloudとは、オンプレミスインフラストラクチャとAWSパブリッククラウドサービス、そしてOutpostsなどのAWS Edgeサービスを組み合わせたクラウドコンピューティング環境を指します。北米電力信頼度協議会（NERC）の規制当局の一つは、電力会社が送電用のリアルタイムエネルギー管理システム（EMS）などのシステムを、重要度に基づいてコンポーネントを分類する方法についてホワイトペーパーを作成しました。これにより、リアルタイムの重要システムをオンプレミスに保持しながら、高度な分析、履歴データの利用、可視化、その他の分析にクラウドを活用することが可能となり、重要な系統運用に関する規制に準拠しながらクラウド技術のメリットのバランスを取ることができます。
Hybrid Cloudのメリットは、規制遵守に加えて、顧客が自身のペースで近代化を進められることです。また、災害復旧とバックアップも重要な側面です。気候変動シナリオと頻発する停電という現在の課題を考えると、これらの事象により電力会社は災害復旧オプションを検討せざるを得なくなっており、Hybrid Cloudはそのようなオプションを提供し、電力網の確実な運用を継続することができます。 Hybrid Cloudの採用を本当に推進しているのは、低レイテンシーが必要なワークロード、データレジデンシー要件、ローカルデータ処理のニーズだけでなく、企業全体で一貫したインフラストラクチャサービスの可用性とパフォーマンスを確保する必要性です。これにより、開発者は同じ体験で一度開発し、一貫して展開することができます。これは構築面だけでなく、デプロイメント、管理、サポートにも当てはまります。
GE Vernovaが提案するGridOSとEvergreenアプローチ
デプロイメント、管理、サポートについては、本日のセッションでより深く掘り下げていきます。インフラストラクチャのデプロイメントと管理を簡素化することで、運用リスク、ダウンタイム、管理とサポートにかかる時間とリソースを最小限に抑えることができます。ここで、GE VernovaがこのSpecificな分野でどのようなイノベーションを起こしているのか、Seanに話を振りたいと思います。
まず、このセッションに来ていただき、ありがとうございます。ここにいる方で、実際に電力業界の経験がある、または電力について何か知っている方は何人いらっしゃいますか？約12人ですね。電力セクターで興味深いのは、基本的に他のネットワークと同じようにネットワークを管理しているということです。他のネットワークに詳しい方なら、可用性、セキュリティ、容量と回復力の最適化について考えると思いますが、さらに安全性という要素もあります。Farnazが話したことすべてが、Jimが指摘したように、非常に速いペースで起こっているのが課題です。これは電力会社が経験した中で、おそらく最もダイナミックな時期であり、電子の発生源と行き先に大きな変化が起きています。
変動する発電と老朽化するネットワークに加えて、これらの大規模な負荷もあります。 このイベントで多く耳にしたのはAIですが、これは私たちが見てきた中で最大の集中型商用負荷となる可能性があります。現在、AIデータセンターの要求は、データセンターを設置しようとしている地域の発電容量よりも大きくなっています。これらすべてを考慮すると、大きな課題はスピードと、それらの問題をいかに解決するかということです。新しいツールが必要であり、そのツールは電力会社が慣れているよりもはるかに速く提供される必要があります。
事業環境について見てみましょう。左端にあるのはAI負荷です。この新しい機能を動かすために必要な電力需要は膨大なものです。そして、発電がどのように変化しているかを見てください。以前の発電は、ユーティリティに馴染みがない方のために説明すると、非常にウォーターフォール的でした。ダムや原子力発電所、大規模なガス発電所などからの大規模発電が、高圧送電線を通り、そこから低圧配電線を通って目的地に届くという、非常に予測可能な形で系統を通って流れていました。しかし今では、発電が配電網に移行しています。これが問題なのは、高い冗長性を持つ高圧送電網と違って、配電網には冗長性がないからです。
上流に負荷が流れることを想定していなかったネットワークが、今後の進化に伴って発電容量の大部分を担うことになるのです。さらに、サイバー攻撃や暴風雨などによってグリッドがダウンする影響を考えると、これらは非線形的に増加しています。これらすべての要因に対して、私たちはユーティリティが対処して解決することを期待しています。スイッチを入れると電気がつく、それは魔法のようなものです。それが毎回確実に起こることを、私たちは期待しているのです。そして今、ユーティリティは、このような非常にダイナミックで変革的な事業環境の中でそれを実現しなければならないのです。
GE Vernovaは、グリッドを発明し、最初のグリッドを構築した会社からのスピンアウト企業です。この会社は世界の電化を支援することを目的として設立されました。その中で、私たちはグリッドを管理するソフトウェアを開発しています。 グリッドについて、私たちは単一のネットワークのように話しますが、実際にはそうではありません。グリッドは実際には緩やかに結合された多くのパーツの集まりなのです。例えば、先ほど話したAI負荷は、このCommercial and Industrial領域の最上部にあります。そして私たち全員が接続している配電網があり、私たちの家庭やビジネスはすべてそこにつながっています。送電網、大規模発電、分散型発電、バッテリー、走り回る車など、すべてがこの事業環境の中で動いています。私たちは、これらすべての場所で動作するソフトウェア、制御室にあるソフトウェア、ネットワークに組み込まれたソフトウェア、そしてエッジで動作するソフトウェアを開発しています。
私たちのユーティリティパートナーは、グリッドの可用性とセキュリティを維持するために、これらすべてのソフトウェアを展開し管理しています。Jimが、ユーティリティの視点からそれがどのように感じられるかを説明してくれるでしょう。私たちが気付いたのは、過去30年間に構築したこれらのソフトウェアがもはや機能しなくなるということでした。それらは非常にサイロ化され、モノリシックで、特定の部分を管理するために構築されており、それぞれが異なる管理フレームワークを持っていましたが、もはやそれでは機能しません。
そこで私たちは新しいアイデアを思いつき、 それをGridOSと名付けました。これは基本的に、他の産業で見られるような、モジュール化され、組み合わせ可能な最新のソリューションです。それをユーティリティにもたらしているのです。このソフトウェアはAIベースで、クラウドアーキテクチャを採用しており、迅速な対応に必要なすべての機能を備えています。しかし最大の課題は、Jimとそのチームのような人々が実際にどのように素早くこれを利用できるかということでした。なぜなら、彼が先ほど話していたように、 ソフトウェアの展開に1〜3年かかり、その展開に時間がかかりすぎるため、しばらくは触れないようにするというプロセスだったからです。そして再び同じことを繰り返し、アップグレードは通常、初期展開と同じくらいのコストがかかりました。それは非常に苦痛を伴うプロセスで、このモデルではアジャイルになることはできません。
この新戦略の一環として、皆さんもよくご存じの方法に移行しました - より頻繁なデリバリーモデルです。現在では、より短い間隔で新機能をリリースし、継続的に提供しています。大規模な一括アップデートの代わりに、小規模な段階的なアップデートを行い、ソフトウェアを進化させ続けています。しかし、公益事業者はこのような消費モデルに慣れていません。そこで、私たちは新しいパラダイムを導入する必要がありました。 それが、ABCDまたはBlue-Greenモデルに基づいたEvergreenと呼ばれるものです。これは、クラウドインスタンスとソフトウェアファクトリーが、そのお客様向けの参照環境としてクラウドインスタンスに移行し、検証を行い、その後オンプレミスインスタンスを経て、最終的に本番環境に移行するというものです。
目標は、3〜5年のデリバリー頻度と18〜36ヶ月の実際の所要時間を、3ヶ月以下、あるいはお客様の選択により月次にまで短縮し、サイクルを非常にタイトにすることでした。これにより、より良いフィードバックループも得られるようになりました。つまり、 製品がより良くなり、ユーザー体験が向上し、すべてが改善されるのです。お客様は、急速に変化する動的な環境に対応するための新機能を手に入れ、より多くのフィードバックを反映した高品質なソフトウェアを得ることができます - これらはすべて、最新のデプロイメントモデルがもたらす素晴らしい利点です。
これを実現するために、私たちは多くの新しいコンポーネントを必要としました。GEは自社のやり方を変える必要があり、お客様も自身のアプローチを変える必要がありました。私たちは、これらの機能を実現するための新しいツール、プロセス、プラットフォームを開発する必要がありました。AWSと密接に協力してこれらを構築し、Amazonのテクノロジーを活用しながら、他の業界での私たちの専門知識と経験を活かしました。金融業界、防衛産業、通信業界ではすでに実施されていたことを、ここで実装する必要があっただけです。
PPLにおけるEvergreenシステムの実装と効果
お客様から見ると、アセットのファクトリー、つまり組み合わせ可能なアセットのセットがあり、クラウドインスタンスを構築してそれを移行できる形になっています。さらに、このお客様と一緒にテストしているAWS Outpostsのような、クラウドアーキテクチャをオンプレミスで活用する機会もあります。ここには大きな可能性があると思います。この点について何か付け加えることはありますか？はい、もう一つあります。
このスライドについて、実際の例を皆さんに説明させていただきます。私たちはEvergreenアプローチを長期にわたって実装してきており、大きな成功を収め、このプロセスを十分に検証してきました。ここでの核心は、プロジェクトからパイプラインへの移行です - すべてがシームレスに流れることを目指しています。大規模なプロジェクト、ビッグバン的なフォークリフトアプローチから脱却したいのです。利点は、GE Vernovaが他の公益事業者向けに何かを開発した場合でも、それが標準製品に組み込まれれば、月次アップデートの高速トラックに乗っているため、本番環境に移行した時点で即座にそれを入手できることです。
私たちのCustomer Reference Environment（CRE）は、図の中央にある紫またはピンク色のボックスで表されていますが、ここに私たちのモデルと設定が置かれています。エンジニアリングから何かがリリースされると、彼らのファクトリーから出てきて、私たちはそのモデルをEvergreenクラウド環境でさらに一段上のレイヤーに移動させます。これにより、GEのエンジニアが実際のユーティリティモデルでテストを行い、バグや問題をより早期に発見できるようになります。その後、それを私たちのCREに取り込みます。この環境では、GEの用語を使うと、Fantasy Island configとモデルと呼ばれる標準的な既製のコンポーネントで設定されます。
そこから、私は通常、アプリケーションを望む通りに設定し始め、自分のモデルがそれで動作するようにします。これは非常に時間のかかるプロセスで、多くの試行錯誤が必要です。よく、GEが設定の問題だと言い、私がバグだと主張する状況に陥り、最終的に解決するまで行ったり来たりします。これは時間の無駄で、私たちは素早く進めたいのです。そこでCRE環境では、Fantasy Islandモデルと設定、つまりGEの標準的な既製のバニラモデルを要求しました。彼らはそれでテストを行い、問題があれば、エンジニアリングに戻します。
次に、私たちは標準設定で私のモデルを使用して別のインスタンスを立ち上げるよう依頼します。問題が発生した場合、それは設定の問題ではなく、モデルの観点から製品が何が起きているのを受け入れていないということが分かります。その後、私のモデルと設定を実装します。素晴らしいのは、彼らがこれらの環境を超高速で立ち上げられることです - 環境を立ち上げ、テストを行い、終了させ、素早く次に移ることができます。すでに、GEチームがプレリリーステスト中にバグを発見し、そのラピッドフィードバックループの一部としてエンジニアリングに戻し、修正してもらった成功例があります。通常なら数ヶ月かかるプロジェクトサイクルと比べて、1ヶ月後には環境に戻ってきました。
Evergreenモデルでは、特定のバージョンに縛られることなく、製品の次のイテレーションに移行できます。バグ修正が来たら、次のリリースで取り込んでテストを継続します。Seanが説明したように、問題を発見し、そのラピッドフィードバックループを維持するという点で、このアプローチで大きな成功を収めています。これは業界にとって完全に新しいアーキテクチャであり、完全に新しい製品であるため、私たちが過去30年から40年行ってきたことを再発明しているのです。これにより、より速く作業を進め、お客様の信頼をより早く構築し、私たちのConsumptionモデルをサポートすることができます。制御ソフトウェアに関する規制が厳しいこの業界特有の課題がありますが、お客様は私たちが認定してリリースできる速さでこれらのアップデートを利用することができます。理想的には、これをさらに効率化して高速化していきたいと考えていますが、現時点でもプロセスの量は対数的に変化しており、時間スケールの面で大きな進歩を遂げています。
クラウドアーキテクチャソリューションを構築する際のAWSの機能について見てみましょう。カスタマー実装では、通常このような形になります。 私たちにはソフトウェアツールキットがあり、CitiesやArgoなどのコンポーネントと、製品やソリューション内に構築された他の多くの要素が含まれています。実質的に、それを公開してお客様の設定とデータをソフトウェア環境にマージし、AppStreamを使用してお客様がその環境にアクセスしてテストできるようにしています。
私たちは、これら全ての展開を自動化しています。パッケージ全体と展開プロセスは自動化されており、Jimが言及したように、必要に応じてこのプロセスを何度でも繰り返すことができます。これは必ずしも新しい技術というわけではありませんが、追加要件に対応する必要があるため、この環境では新しいものとなっています。既存のものを適応させ、安全性要件やサービスの信頼性を考慮して、公益事業向けの規制要件を組み込む必要がありました。このコンテキストでは、検証されていないソリューションを単純に展開するわけにはいきません。私たちは数多くのAWSサービスを活用し、さらなるオプションを継続的に評価しています。AWSとのパートナーシップにより、このプロセスを加速し、より迅速に結果を出すことができています。
それでは次に移りましょう。Jim、PPLではこれがどのように見えるのか、説明していただけますか？ありがとう、Sean。私たちはAWS環境、Evergreenシステム、そしてデリバリーパイプラインについて話してきました。ここでご覧いただいているのは、配電網を制御するための Advanced Distribution Management System（ADMS）です。このアプリケーションは非常に複雑で、多数のサーバーと内部アプリケーションがPowerアプリを実行しています。私たちのCREの目的は、本番環境をできるだけ正確に反映し、システム全体を通して全てが同一であることを確実にすることです。
クラウド環境を活用した電力系統制御システムのテストと展開
白いボックスで示されているサーバーを見ると、このシステムはマルチノード冗長化されており、レジリエンシーのために主要データセンターとバックアップデータセンターがあります。私たちには4つのノード（一方の場所にAとB、もう一方にCとD）があります。CRE内で全てのPowerアプリが構成されており、GEがアップデートをリリースすると、この環境に取り込まれます。フェイルオーバーシナリオを含む包括的なテストを実施できます。Aノードを取り除いてBがプライマリになる様子を観察し、CとDが代替として期待通りに動作するのを確認できます。さらに、AとBが停止する全データセンター障害をシミュレートし、システムが他方にフェイルオーバーする様子も確認できます。
私たちの目標は、通常オンプレミス環境で行うテストを全てこのクラウド環境に移行することです。これには統合テストも含まれます。クラウド環境での統合テストに懐疑的な人もいますが、入出力とミドルウェアとの接続ポイントを理解しているため、これらの接続を効果的にテストできます。このハンドシェイクポイントまでの環境で、可能な限り広範なテストを行いたいと考えています。問題を特定した場合は、Seanのチームとエンジニアリンググループにフィードバックし、継続的な改善サイクルを維持します。私たちは展開と管理にJenkinsやパイプラインなどの最新ツールを使用しています。
SeanはGridOSについて話しましたが、彼らがテクノロジースタックを最新化し、変更を加え、新機能をリリースする過程で、その多くがティール色のボックスに組み込まれています。これにより、既存バージョンの製品を実行しながら、同時に新しいGridOSを含む別バージョンをスピンアップできます。私にとって、これは全システムをGridOSに移行する近道となります。なぜなら、彼らがコンポーネントをリリースする際に、私の環境で直接プラグアンドプレイできるからです。うまく機能すれば本番環境にも展開できますし、そうでなければ次のコンポーネントが登場するのを待って、それを環境に取り込むこともできます。
私にとって、必要なときに必要なものを迅速にデプロイできる柔軟性が本当に重要です。理想的には、これは革新的なテストラボとしても機能します。例えば、制御やモニタリングで問題のあるバッテリーへの対応など、問題を特定した場合、解決策を開発することができます。パッチを適用し、Customer Reference Environment (CRE)に導入して、実際のモデルでテストすることができます。正しく動作することを確認してから、本番環境に移行できます。通常なら数ヶ月かかる開発期間を短縮し、グリッドで起きていることにより迅速に対応できることが重要なのです。
最終的には、送電用のEnergy Management System (EMS)をこの環境に移行するためのインターフェースを用意しています。ただし、これはステップ2で、まずSIPの問題に対処する必要があります - SIP Jailと呼ばれる状況を避けたいのです。両方の制御システムがここに配置されれば、それらがどのように連携するかをテストできます。というのも、情報やデータが双方向に行き来する重要な統合があるからです。私が望むのは、所有しているGEのエコシステム全体がこのドメイン内で稼働することです。そうすれば、所有しているGEアプリケーション間のすべての統合が継続的にテストされ、一部が変更された場合でも、すべてを一緒にテストする必要があり、より高い信頼性が得られます。
Farnazが話したAWS Outpostsについては、現在AWSとGEの両方との議論で次のフォーカスポイントとなっています。現在、彼らとPOCを実施しており、すでにこの環境にあるモデルを実行しているハイブリッドOutpostsについて検討しています。そのモデルをアウトポストに移行し、オンプレミスのOutpostラックとクラウドのOutpostラックを使用したハイブリッド環境で、それらがどのように連携するかを確認できます。モデルに関して重要な点は、機密性の高い情報や重要な顧客情報はすべて削除され、難読化されているということです。
特に電力業界外の人々にとって重要なのは、私たちが解決しようとしている課題です。電力会社は、これらのシステムをすべて自社で実装することに慣れており、その結果、環境は本質的にスノーフレーク（一つ一つが独特）になっています。彼らは実際の正当な理由もなくデータモデルをカスタマイズし、単に独自の方法でラベル付けや命名をしたいだけなのです。隣接する電力会社が持っているものと基本的に同じモデルなのに、それを異なる方法で記述する独自のバリアントを作成しています。構成やデプロイメントモデル、ソフトウェアの配置をカスタマイズし、各電力会社を完全にユニークにしていますが、これらの電力会社は互いに競合していないため、この独自性には特に価値がありません。
これらの電力会社は独自性を持ちながらも競合していません。彼らは友好関係にあります。これは単に「いつもそうだった」という理由以外にありません。私たちが解決しようとしていることの1つは、バリアントを排除し、システムインテグレーターからグリッドオペレーターへの転換を図ることです。私たちは、ソフトウェアを寄せ集めて動作させようとすることではなく、毎日電力を必要とする何百万人もの利用者にサービスを提供することに集中してほしいのです。
自動化とAWS Outpostsによる電力会社の変革支援
PPLで私たちが行っているのはユニークです。なぜなら、これらはGEがテストし、設計し、検証した標準構成であり、PPLが導入したものだからです。Outpostはその延長線上にあります。基本的にはアプライアンス群であり、クラウド上のCustomer Reference Environmentと全く同じものがオンプレミスに完全に複製されています。VPCを拡張して効果的に活用することで、このソフトウェアをテストと検証の価値創造パイプライン全体を通じて、シームレスに本番環境まで移行できます。
では、どれくらい早く導入できるのかについてお話ししましょう。ここに示されている導入時間を見ると、セットアップ全体で約7～8時間程度です。通常、導入作業には週末を要していました。1日目は丸一日かけてこれを導入して稼働させていたのです。ご覧の通り、かなりの時間短縮が実現できています。テスト用に環境が必要な場合、すぐに用意してもらえます。すべてがコンテナ化されJenkins deploymentで管理されているので、文字通りボタン一つで実行できます。実行したいスクリプトを選択でき、アプリケーションの異なるバージョンを使用したり、1つ前のバージョンに戻したり、最新版を使用したりと、望む通りに設定できます。
NRAWC環境では、常時稼働させておくとコストがかかるため、必要に応じて環境の起動と停止を行っています。起動してテストを行い、そこから作業を進めています。PPLはこの点で特に優れています。他の電力会社では数日かかるような作業でも、PPLならずっと速く実行できます。通常のプロジェクト環境では、プロジェクトを開始してDEV環境、QA環境、そして最終的に本番環境に導入する際、GEからキットを受け取ります。キットを受け取るたびに、導入やテストなど、全工程を繰り返す必要があります。このアプローチにより、キットを受け取ってからテストを開始するまでのプロジェクトの進行が格段に速くなります。
テストについて言えば、ここでのテスト自動化が重要です。いくら環境を素早く立ち上げられても、テストを自動化していなければ、まだある程度の制約が残ります。これが現在のプロジェクトフェーズです。GEには彼らのテストスクリプトがあり、私たちにも独自のテストスクリプトがあります。GEとの契約の一環として、私たちは自社のテストスクリプトを提供し、さらに新しいテストスクリプトを開発して提供することになっています。これらは後に自動化されます。テスト全体を自動で実行し、環境を立ち上げ、テストを開始し、実行を完了させ、失敗した箇所を調査して、次のステップに進むことができます。理想的には、PPLのスタッフが触れる前に、GEがすべてのスクリプトを実行し、すべてのテストを完了させ、承認を与えて問題なしとしています。その後、PPLが期待通りに動作しているかを確認します。最終テストでは、オペレーター体験に焦点を当てています。
このプロセスは通常、多くの電力会社にとって最も時間のかかる部分で、高い信頼性を確保するためにテストに数日から数週間を費やします。自動化できるものを自動化し、早期に検証済みの出力を提供することで、より迅速に前進することができます。この受け入れテストプロセスの効率化は極めて重要で、現在では数週間かかっていたサイクルを数分から数時間に短縮しています。
また、Utilityのクラウドおよびソフトウェアチームにおけるスキルギャップの問題もあります。GEのソフトウェアに精通したCloud Engineerがいても、様々なタスクを処理するためのスキルが不足している場合があります。オンプレミス、クラウド、エッジのいずれにおいても、一貫したTech Stackを持つことで、Utilityはこれらのスキルギャップに対処し、従業員に必要なスキルを効率的に習得させ、全体的なプロセスをシンプルにすることができます。
自動化の一環として、毎月更新するモデルをGEに戻す作業があります。現在、私たちのCustomer Reference Environment（CRE）を本番環境と同期させる方法を検討しています。現状では、本番環境にロードしてモデルを変更する際、そのモデルと設定をGEチームに送り、彼らがCREにロードする形を取っています。現在はファイルを扱い、特定のゾーンに配置する方法を採用していますが、このプロセスをどのように機能させるべきか、さらなる検討が必要です。理想的には、すべてが継続的に移動するパイプラインにしたいと考えています。
AWS Outpostsを使用し、自社のオンプレミスデータセンターにラックを設置することで、プロセスがより簡単になります。CREでの作業が完了すれば、そこから引き出すことができ、私たちの環境に直接取り込むことができます。環境間の移行をより簡単にするため、障害を乗り越えて物事を移動させる必要がない、いわばドラッグ＆ドロップのような感覚を目指しています。できる限りシームレスにすることが私たちの目標です。
最終的な目標は、Utilityが直面している変化に対応できるようにすることであり、私たちはそれを支援するソフトウェアを開発しています。他のソリューションと比べて停電を21%削減し、復旧時間を17%短縮し、再生可能エネルギーの導入率を70%まで可能にし、管理コストを40%削減できるソフトウェアを提供することは素晴らしいことです。しかし、Utilityがそれを利用・展開できなければ、これらのメリットは意味がありません。インストール時間を92%、テスト時間を96%削減することで、Utilityは現在の課題に対してこの技術を実際に導入することができます。私たちは皆、部屋に入ってスイッチを入れれば電気がつくことを当たり前のように期待しています - それは魔法のように、ただ起こるべきなのです。それが私たちのミッションです：PPLのようなUtilityがそれを続けられるようにすること。そしてAWSは、私たちが彼らを支援する上で素晴らしいパートナーとなっています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion