AWSに構築した自社サービス環境改善を考える
～再エネ発電量予測サービス：気象データ処理編～
投稿日: 2025/01/27
はじめに
こんにちは、滋野です。
今回は、弊社にて提供している再エネ発電量予測サービス「E-PLSM Forecast（エプリズム フォーキャスト）」のAWS環境改善に関してご紹介します。
日々気象庁等で提供されている気象データのAWS上での扱いの一例としてもぜひご参考ください！
E-PLSM Forecastとは
まず本題に入る前に、E-PLSM Forecastのご紹介です。E-PLSM Forecastとは風力・太陽光発電所における数時間～1週間先までの発電量を予測し、その予測データを1時間毎に提供するサービスです。
複数の数値予報モデルを利用することで、「短期間の予測精度を重視した予測」と「長期的な予測」の両方をご提供しております。以下3種類のメニューをご用意しており、お客様の状況に応じて選択が可能となります。
- 設備情報と気象予報データから発電量を予測するシンプルなモデル（Express）
- 機械学習を駆使して高精度な予測を目指すモデル（Standard）
- 直近の発電量実績データを活用して直近の発電傾向を反映し更に高精度な予測を目指すモデル（Premium）
※詳細は以下をご覧ください。
https://www.engineering-eye.com/E-PLSM/forecast.html
https://www.ctc-g.co.jp/company/release/20241003-01795.html
気象データ処理に関する課題
E-PLSM ForecastはAWS上で稼働しておりますが、気象データ処理に関しては、以下のような課題がありました。
- 1時間に1回のバッチ処理であるが、複数EC2上で稼働しているためコスト効率が悪い。
- CI/CD環境が整備されていない。
- 各種ログの保管場所が集約されておらず、保守対応に時間がかかる。
- 気象データ処理は様々なプロジェクトで共通の処理として用いられているが、環境整備に時間がかかることが多い。
特に環境整備の課題に関しては、気象データに応じた処理プログラムは整備されていたものの、サーバの準備や動作環境の構築に時間を要し、データ分析やサービス開発においてボトルネックとなっておりました。従来から抱えている課題であったものの対策を講じることができていない状況でした。
対応方針
先述の課題から以下のような対応を検討しました。
- 気象データ関連バッチ処理をLambda＋Step Functionsで実装
- 各種設定はAWS Cloud Development Kit (AWS CDK)にて定義
- コードはCodeCommitにて保管・管理、CodeBuild、CodePipelineを通して、ビルド・デプロイ
- 各種ログはCloudWatchにて監視可能とする。
気象データ処理に関しては、大きく分けると以下のステップで実施しております。
- 1. 各種気象データの入電
- 2. 気象データを抽出する地点の特定
- 3. 気象データのデコード
- 4. 気象データの前処理
それぞれの処理をLambdaにて定義し、気象データがS3に保管されたことをトリガーとして動くようなワークフローをStep Functionsで実装します。
なお、利用する気象データの一例として、以下気象庁数値予報モデルデータ等があります。
気象庁数値予報モデルなどの気象データは、世界気象機関WMOが定めるGRIB2というフォーマットが多く利用されています。
GRIB2データを扱うプログラムとして、pygribやアメリカ海洋大気庁（NOAA）が提供しているwgrib2がありますが、Lambdaランタイムとの互換性には注意する必要があります。
| 数値予報システム （略称） |
予報領域と 格子間隔 |
予報期間 （メンバー数） |
実行回数 （初期値の時刻） |
|---|---|---|---|
| 局地モデル （LFM） |
日本周辺 2km | 10時間 | 1日16回 (下記以外の正時) |
| 18時間 | 1日8回 (00,03,06,09,12,15,18,21UTC) |
||
| メソモデル （MSM） |
日本周辺 5km | 39時間 | 1日6回 (03,06,09,15,18,21UTC) |
| 78時間 | 1日2回 (00,12UTC) |
||
| 全球モデル （GSM） |
地球全体 約13km | 5.5日間 | 1日2回 (06,18UTC) |
| 11日間 | 1日2回 (00,12UTC) |
||
| メソアンサンブル 予報システム （MEPS） |
日本周辺 5km | 39時間 （21メンバー） |
1日4回 (00,06,12,18UTC) |
※表の内容は2025年1月時点
結果とまとめ
結果として以下のような構成を検討し、実装しています。
気象データ関連バッチ処理をLambda＋Step Functionsを用いて構築しています。各種設定は全てCDKにて定義し、コードは、CodeCommitにて保管・管理、CodeBuild、CodePipelineを通して、ビルド・デプロイすることにより、ステージング、本番環境に対する開発サイクルに合ったCI/CDパイプラインを実装しました。本構成を実装したことによる、大幅なコスト削減も見込んでいます。
また、CDKにて実装したことにより、他AWS環境への転用も従来と比較して容易に実施可能となります。
なお注意点としては、気象データサイズによっては、Lambdaのメモリ制限（上限10GB）や、エフェメラルストレージ制限（上限10GB）を超える場合があるため、ECSやEFS等のサービス利用を考慮する必要があります。
さいごに
気象が大好きな私としては、AWSでの気象データ利活用がさらに広まることを願っております。
弊社はAWS、気象データともに扱いに長けたエンジニアが多数所属しております。
AWSでの気象データ活用に関するご相談は、お気軽にCTCまでお寄せください！
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。
