Amazon Web Services ブログ
発電設備の系統接続の連携検討をサーバーレスワークフローと拡張性のある HPC で加速する
この投稿は、「Accelerating generator interconnection study with serverless workflow and elastic HPC」を翻訳したものになります。
コスト削減と脱炭素化の取り組みに後押しされたクリーンエネルギーの急速な成長は、既存の電力系統インフラに大きな負担をかけています。太陽光、風力、その他の分散型エネルギーリソースの系統接続要請が増加するにつれ、発電設備の系統接続プロセスはますます複雑化し、課題が山積しています。時代遅れの系統計画プロセス、長期化する系統接続待ち行列、送電容量の不足は、新規電源をスムーズに統合する際の主要な障壁の一部となっています。これらの系統接続における課題は、再生可能エネルギー資源が豊富な地域と需要地との地理的なミスマッチによってさらに深刻化しており、クリーンエネルギーを消費者に届けるために大規模な送電網の整備が必要となっています。
この問題の規模は驚異的です:系統接続待ち行列のプロジェクト数は、現在の米国の電力系統全体の設備容量の2倍に達しています。2022 年時点で、およそ200 万メガワット(MW)のクリーンエネルギー設備容量が接続待ちの状態にあり、2023 年末までにこの数字は 260 万MW(2,600 ギガワット (GW) 、すなわち 2.6 テラワット (TW) )にまで増加しました。これらの提案されているプロジェクトは、電力系統への接続前に必要とされる様々なアセスメントや手続きの段階にあります。2024 年時点で、接続待ち行列への参入から商業運転開始までの平均所要期間は 3〜5 年となっています(レポート参照)。
図1. The U.S. Clean Energy Backlog (2022年末時点データ, 図表元データ)
図2. The U.S. generator interconnection queue in 2022 vs. 2023 (図表元データ)
発電設備の系統接続プロセスは主に、系統接続申込み、系統接続検討、系統接続承諾、商業運転の4つの段階で構成されています。新規の発電設備を電力系統に接続する前に、実現可能性検討(Feasibility Study)、系統影響検討(System Impact Study)、設備検討(Facilities Study)として知られる一連の複雑なシミュレーションベースの技術検討を実施する必要があります。これらの接続検討では、1つまたは複数の提案された発電設備が系統全体の信頼性、安定性、性能にどのような影響を与えるかを評価します。この多段階の検討プロセスでは、提案されたプロジェクトの系統接続に必要な設備増強を決定し、関連コストを算出し、個々の影響度に基づいてこれらのコストを提案プロジェクト間で比例配分します。これらの検討結果は、以下の表に示すように、接続プロセスの後続段階の判断材料となります。
これらの検討は、長期化する系統接続プロセスの唯一の要因ではありませんが、間違いなく重要な要因の一つとなっています。検討の3つのフェーズ、すなわち実現可能性検証(通常 30-60 日)、システムインパクト検証(通常 90-180 日)、そして設備検証(通常 90-180 日)は、全体として考えると6ヶ月から2年以上かかる可能性があります。実際には、検討の複雑さ、再検討の必要性、またはリソースの制約により、目標とする期間を超えて検討が長引くことが少なくありません。
電力会社/系統運用者/AWSにとってのビジネス機会
連邦エネルギー規制委員会(FERC)は、「発電設備の系統接続手続きと契約の改善」と題された Order No. 2023 を通じて、発電設備の系統接続プロセスの合理化に向けた施策を実施しました。本命令の重要な側面として、送電事業者に対し、従来の「先着順」による逐次的なアプローチから、より効率的な「準備が整った順」によるクラスター方式での検討手法への移行を義務付けています。この移行により、複数のプロジェクトを同時に評価することが可能となり、系統接続待ち行列の進捗を加速することを目指しています。この新しいアプローチは、クラウド技術を活用することで、従来は時間のかかっていた重要な系統接続検討を大幅にスケールアップし加速する機会を系統接続のバリューチェーン全体の関係者にもたらします。この変更は、系統接続プロセスのボトルネック解消を実現するだけでなく、新規の電源を電力系統により迅速に統合するという広範な目標にも沿うものとなっています。
従来型ITリソースにおける系統接続検討の技術的課題
系統接続検討は通常、従来型ITインフラを基盤とするオンプレミスのサーバー群で実行されていますが、以下のような技術的課題が存在します:
- 検討量に対する計算リソースの不足: 系統接続検討、特にクラスター方式でのプロジェクト申込みを含む複雑なシステムの検討には、大きな計算能力が必要です。オンプレミスシステムでは、増加する検討の複雑さや量に対応できず、処理時間の長期化につながる可能性があります。
- スケーラビリティの問題: オンプレミスシステムはスケーラビリティが限定的で、ピーク時やクラスター検討のためのリソースを迅速に増強することが困難です。さらに、容量増強のための新規ハードウェア追加には、多くの場合、コストと時間がかかります。
- データ管理: 複数の検討から生成される大量のデータの保存と管理は、ローカルストレージシステムに負担をかけます。ローカルシステムでのデータバックアップの確保は、困難かつリソース集約的となる可能性があります。
- 協業の困難さ: オンプレミス環境では、特に検討が個々のワークステーションで分断されて実施される場合、チームメンバー間のリアルタイムな協業が妨げられます。他のメンバーがどのような作業を実行しているか、その進捗状況の把握、トラブルシューティングでの相互支援が困難です。また、大規模なデータセットや結果を外部の関係者と共有することも煩雑になります。
- 可用性と災害復旧: ローカルハードウェアの障害は、大幅なダウンタイムや潜在的なデータ損失につながる可能性があります。目標復旧時間(RTO)と目標復旧時点(RPO)の要件を満たすことは、オンプレミスシステムではより困難かつ高コストとなる可能性があります。
- 先進技術へのアクセス制限: オンプレミスシステムでは、系統接続検討の最適化に活用されている人工知能(AI)や機械学習(ML)などの先進技術の導入が困難な場合があります。
- 所有コスト: 複雑な検討に必要な高性能計算リソースの総所有コスト(TCO)は、オンプレミスで維持する場合、多額になる可能性があります。
ソリューション
発電設備の系統接続は、主要な産業拠点や電力需要の高い人口密集都市部に大容量の電力を供給する上で極めて重要です。この課題は電力会社やメーカーの懸念にとどまらず、世界最大の再生可能エネルギー購入者である Amazon にとっても特に重要な意味を持っています。
さらに、生成 AI の急速な普及により、データセンターの電力需要は前例のない成長を示しています。これらの増大するエネルギーニーズに対応するには、迅速な配慮が必要です。電力系統への新規電源接続を制限している技術的障壁を克服しなければなりません。この技術的なチャレンジは、系統の拡張と近代化に対して、より適した手法を確立するために継続的な政策改革の取り組みを補完するものとなるべきです。
本記事では、発電設備の系統接続検討プロセスにおける主要な課題に対処するため、AWS 上の包括的かつカスタマイズされたソリューションフレームワークを提示することで、発電設備の系統接続に対する重要な評価を大幅に迅速化・改善する AWS の多様な機能を紹介します。
以下の図は、サーバーレスベースのワークフローオーケストレーションと拡張性の高い HPC(High Performance Computing)クラスターを使用した系統接続検討アクセラレーターの拡張リファレンスアーキテクチャを示しています。この最新の設計図は、以前公開したガイダンスを基に、計算サービス選択の柔軟性向上という重要な改善を加えたものです。この柔軟性により、ユーザーは特定の検討要件に応じて計算環境を調整し、様々な系統接続検討タスクのパフォーマンスとリソース配分を最適化できます。このソリューションでは、AWS Step Functions を使用して検討プロセスをオーケストレーションします。実行時間、データの共通性、複雑さ、ランタイム依存関係などのタスク特性に応じて、Step Functions のステートは、AWS Lambda、AWS Fargate 上の Amazon Elastic Container Service(Amazon ECS)、または AWS ParallelCluster(あるいは、HPCワークロードの実行とスケーリングを管理するサービスである AWS Parallel Computing Service)上で実行できます。ユーザーは、これらのスケーラブルな計算サービスを柔軟に組み合わせて、複雑な分析を実行できます。例えば、Lambda 関数は 15 分の実行制限があるため、目的の系統接続待ち行列からのリクエスト取得などの短時間の計算タスクに理想的です。一方、Fargate 上のECSは、リモートリポジトリからの共通データバンドルの取得(ダウンロードと抽出)など、より長時間のタスクに適しています。事故解析、短絡解析、過渡安定度解析、投資最適化などの計算負荷の高い時間のかかるエンジニアリングシミュレーションジョブについては、Step Functions が ParallelCluster などの HPC クラスターを指定して処理することができます。
図3. 発電設備系統接続検証プロセスのリファレンスアーキテクチャ
このソリューションは、フロントエンドは AWS Amplify を使用してフルスタックの Web アプリケーションを構築・ホストします。Web ユーザーインターフェースへのログイン前に、ユーザーは Amazon Cognito で認証され、管理者、標準ユーザー、レビュアー、承認者などの特定の役割を割り当てられます。また、ユーザーデータとタスク情報の保存には Amazon DynamoDB を使用します。AWS AppSync は、Web ポータルでの情報表示のために NoSQL データベースへのクエリが可能な GraphQL API を作成するために使用されます。
高性能ファイルシステムとして、Amazon FSx for Lustre、または OpenZFS が構成され、Lambda、Amazon ECS、およびHPC クラスターと接続して、系統接続検討ツールによって生成される中間結果および統合結果を保存します。WebUI からのデータアクセスについては、このアーキテクチャ設計では、AWS DataSync を使用して、Amazon FSx から、Amplify バックエンドのストレージリソースとして統合されている Amazon S3 に、選択されたデータを移動します。
このソリューションでは、AWS CodePipeline を使用して DevOps プラクティスを実装し、Amplify コードと Amazon ECS タスクコンテナアーティファクトの両方のビルド、テスト、デプロイプロセスを自動化しています。継続的インテグレーションと継続的デリバリー(CI/CD)パイプラインの一部として、AWS CodeConnection と AWS CodeBuild を組み込んでいます。この統合されたアプローチにより、開発ワークフローが効率化され、開発チームと運用チーム間のコラボレーションが向上します。
このソリューションの主な特徴は以下の通りです:
- マルチユーザー、マルチジョブの実行をサポート
- 並列実行の最大同時実行数を制御可能
- イベント(ジョブ実行要求時)駆動のサーバーレスワークフローとアイドル時にゼロまでスケールダウンする弾力的な HPC クラスターにより、高いコスト効率を実現
- フロントエンドと統合されたユーザー認証とAPI認可
- ユーザー体験を向上させ、学習曲線を緩やかにする独立した WebUI
- 管理者、ユーザー、承認者など、異なる役割に対するきめ細かなアクセス制御
系統接続プロセスは組織によって異なり、各 RTO/ISO (訳註:北米では送電事業に TSO 以外に RTO:広域送電機関、ISO:独立系統運用機関が存在します)が設定した基準に基づいて地域ごとに検討サイクルが異なります。以下の図は、カスタマイズ可能なワークフローを編成するためのソリューションアーキテクチャの機能を示しています。このサンプルは、系統接続検討の全ステップを完全に実装したものではありません。むしろ、スケーラビリティ、信頼性、性能効率、コスト最適化を実現するために、サーバーレスサービスと HPC サービスを使用してどのように主要タスクを実行できるかを示すものです。このサンプルは、ユーザーが構築を進めるための基盤を提供します。AWS Step Functions を使用することで、ユーザーは実際の検討サイクルを正確に反映したより高度なワークフローを作成できます。Step Functions は様々な AWS コンピューティングサービスとの統合を可能にし、特定のジョブ要件に合わせて調整できます。ユーザーは、基本的なフレームワークを、各々の特定のプロセスに沿ったより包括的なシステムに拡張できる柔軟性を持っています。
図4. 系統接続検証のサンプルワークフロー
このプロセスを実現するために、系統接続検討ワークフローの重要なステップすべてを実行する、様々なオープンソースの電力系統解析ツール(GridCal、GridStatus、ANDES、PyPSA、およびその関連ライブラリ PyPSA-USA )を使用しています。これらのツールはすべて Python ベースのパッケージで、デプロイメントの柔軟性を提供します。Lambda、Fargate 上の ECS、ParallelCluster など、前述のすべての種類の計算環境で実行可能です。このアプローチは、電力系統解析における様々な計算ニーズに対応するクラウドベース環境内での、これらツールの汎用性とスケーラビリティを実証しています。
Step Functions では、先に定義したワークフローに基づいてステートマシンが作成されます。このステートマシンは、Task(タスク)、Choice(選択)、Fail(失敗)という3つの主要なステート型を組み込んでいます。Choice ステートはフロー制御メカニズムとして機能し、指定された条件に基づいて実行パスを制御します。この例では、特定のデータの存在有無に基づいてタスクを実行するか省略するかを制御します。Failステートは、失敗とタイムアウトの両方を含む例外を処理し、エラー管理の標準的な方法を提供します。各 Task ステートには、以下に示す定義による再試行ロジックが装備されており、一時的な障害が発生した場合に複数回の実行試行を可能にします。タスクが最大再試行回数を超えた場合、ワークフローは終了し、Fail ステートに移行します。この構造により、系統接続検討プロセス全体を通じて、堅牢なエラー処理とフロー制御が確保されます。
図5. Step Functions の系統接続検証ワークフロー定義
このステートマシンは、AWS Systems Manager Run Command API を通じて ParallelCluster に系統接続検討シミュレーションジョブを投入する必要のあるタスクを管理するため、コールバック待機パターンを統合した標準的な Lambda 関数テンプレートを使用します。このコールバックメカニズムにより、ジョブ完了を示すタスクトークンを受信するまでワークフローを一時停止することができます。クラスターに投入されたジョブが完了すると、タスクの状態(成功:SendTaskSuccess
、または失敗:SendTaskFailure
)を報告するコールバック関数が起動されます。このアプローチにより、ワークフロー内の長時間実行される非同期プロセスを効率的に管理し、検討における順序依存性の整合性を維持できます。これにより、段階的な検討の各フェーズが適切に後続のステージに情報を伝え、開始することが可能となります。
ステートマシンからジョブを受信すると、HPC クラスターは以下の高度なジョブ管理プロセスを実行します:
- ジョブのキューイングとスケジューリング:受信したジョブは初めにキューに配置され、処理のためにスケジューリングされます。
- 動的スケーリング:クラスターは、キューに入れられたジョブを効率的に処理するために必要に応じて計算最適化ノードを動的にプロビジョニングします。
- 固有のジョブ識別子:各ジョブには以下の要素からなる固有の識別子が割り当てられます:
- ユーザー名
- 投入タイムスタンプ
- ジョブタイプ
- ジョブ番号
- 処理コアインデックス
- 出力ファイルの命名規則:クラスターはこの固有識別子を使用して、一貫したパターンで出力ファイルに名前を付けます。この命名戦略は以下の2つの重要な目的を果たします:
- 各出力に固有の名前を付けることでファイル名の競合を防止
- 誤ったファイルの上書きのリスクを排除
この体系的なアプローチにより、複数の系統接続検討を同時に実行する場合でも、効率的なジョブ処理、スケーラブルなリソース使用、および整理された出力管理が確保されます。
図6. ジョブキューステータスと出力結果 (クラスター管理者がアクセス可能)
このソリューションでは、Fargate 上の ECS クラスターを使用して、ParallelCluster で実行されるもの以外の様々な系統接続検討タスク(ベースモデルの選択、クラスター化された接続要求に関連するプロジェクトデータセットの取得、ネットワークモデルの構築など)を実行します。多様な計算環境間でのシームレスなデータアクセスと永続性を確保するため、FSx ボリュームが作成され、ParallelCluster、Amazon ECS タスク、およびコンテナイメージを使用する Lambda 関数に対してマウントされます。
ワークフローの終了時に、Lambda 関数が起動され、2つの重要なタスクを実行します。第一に、検討プロセス全体で生成された分析結果を集約し、包括的な検討レポートを作成します(レポート作成には生成 AI の活用も可能)。第二に、DataSync タスクを開始し、マウントされた FSx ボリュームから出力層の S3 バケットへ選択的にデータを転送し、最終的な検討結果の効率的な保存とアクセシビリティを確保します。
前述のように、ソリューションのフロントエンドは Amplify でホストされ、Cloudscape デザインシステムを使用したユーザーフレンドリーな Web インターフェースを提供します。このインターフェースにより、ユーザーはジョブの実行依頼、ジョブステータスの監視、および詳細な段階的分析結果を含む包括的な検討レポートを圧縮ファイル形式でダウンロードすることができます。ユーザー体験は直感的で魅力的であり、スケーラブルな包括性を備えています。
図7. 発電設備の系統接続検証用の Web アプリケーションホームページ
ユーザーの観点から見ると、系統接続検討の一連のプロセスは以下のように展開されます:
- 開始:ユーザーが個別またはクラスター化された系統接続待ち行列リクエストを指定するトリガーファイルを Amazon S3 のランディングゾーンバケットにアップロードすることで実行が始まります。
- 前処理:このアップロードが Lambda 関数を起動し、データの整合性チェックを実行します。
- ワークフロー開始:Lambda 関数が Step Functions を通じてステートマシンを開始し、同時に実行に関するメタデータを DynamoDB テーブルに記録します。
- データ保存:DynamoDB テーブルには、RunId, Owner, SubmissionTime, SourceFileName, OutputFileName, OutputFileLocation などの重要な情報が保存され、RunId と Owner がそれぞれパーティションキーとソートキーとして機能します。
- リアルタイム更新:AppSync を活用した GraphQL API が定期的にこのテーブルをクエリし、すべてのプラットフォームユーザーに最新情報を提示します。
- 進捗監視:ユーザーは、Amazon API Gateway が管理する WebSocket 接続を通じて、特定の実行の進捗を追跡できます。(詳細は、こちらの AWS sample )
- 結果アクセス:完了後、検討結果が出力層の S3 バケットからダウンロード可能になります。アクセスはオブジェクトタグで指定されたユーザーグループのメンバーシップに基づいて条件付きで許可され、コラボレーションとデータセキュリティの両立を確保します。
この包括的なアプローチにより、堅牢なセキュリティと効率的なデータ管理を維持しながら、ユーザーの系統接続検討プロセスとの対話がスムーズになります。
図8. 発電設備の系統接続検証の Web アプリケーションのダッシュボード(系統ネットワークのトラフィックビュー)
図9. 発電設備の系統接続検証の Web アプリケーションの 「Runs(実行)」ページ
図10. 発電設備の系統接続検証の Web アプリケーションの「Run details(実行詳細)」ページ
複数のエンジニアが同時に系統接続検討を実行する実際のシナリオをシミュレートするため、プラットフォーム上で同時実行テストを実施しました。Lambda、Step Functions、Fargate 上の ECS を使用するこのソリューションのサーバーレスアーキテクチャは、これらの並列実行要求を効率的に管理する堅牢な能力を実証しました。このアーキテクチャに備わるスケーラビリティと非同期処理モデルにより、複数の同時検討要求をシームレスに処理することが可能となり、高負荷状況下でもレスポンス性能とパフォーマンスを確保することができました。
図11. 異なるユーザーによって開始された複数ワークフローの同時実行
まとめ
再生可能エネルギー発電の急速な成長により、系統接続プロセスに大きな課題が生じており、新規のクリーンエネルギープロジェクトの電力系統への接続検討に長い待機時間と遅延が発生しています。本記事では、これらの課題に対処し、系統接続検討プロセスを加速するためのAWSクラウドテクノロジーを活用した革新的なソリューションを提示します。
サーバーレスワークフローオーケストレーションと弾力的な高性能計算を組み合わせることで、提案するアーキテクチャは複雑な系統接続検討を実施するための、スケーラブルで費用対効果が高く効率的なアプローチを提供します。このクラウドベースのソリューションは、従来のオンプレミスシステムの多くの重要な制約に対処し、改善されたスケーラビリティ、協業能力、コスト効率を提供します。系統接続検討プロセスの効率化により、新規電源の系統統合におけるボトルネックを大幅に削減し、最終的によりクリーンで回復力のある電力系統への移行を支援することができます。
エネルギー情勢が進化し続ける中、電力会社、系統運用機関、その他の関係者にとって、クラウドコンピューティングは強力なプラットフォームとなります。このようなクラウドベースのソリューションを採用することで、これらの組織はよりサステナブルなエネルギーの未来に向けた取り組みを加速することができます。これらのアプローチは、再生可能エネルギーの統合と電力系統の近代化に対する増大するニーズへの対応に不可欠です。
本ブログは、ソリューションアーキテクトの丹羽が翻訳しました。原文はこちらです。