このページの本文へ

業界を知り、業界をつなぐX-Tech JAWS ― 第8回

JAWS DAYS 2018のX-Techセッション第一弾は「ポケット発電所長」

太陽光発電の監視システムをサーバーレスで実現した話

2018年05月07日 09時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

幅広い業界で採用されるようになったAWSの知見を共有しようという趣旨ですでに3回の勉強会を行なっているX-Tech JAWSがJAWS DAYSにもやってきた。TrexEdgeの小川達さんは太陽光発電の遠隔監視システムのデータを収集・可視化する「ポケット発電所長」の概要や開発について説明した。

地方創生のためにITを駆使するTrexEdge

 トップバッターとして登壇した小川達さんは、2012年にIT系のコンサルティング会社であるフューチャーアーキテクトに入社し、その後子会社のTrexEdge(トレックスエッジ)に出向してCTOを務めている。セッション20分間のうち前半はビジネス、後半はテクノロジーという配分でまずは会社概要から説明を開始した。

TrexEdge CTOの小川達さん

 2017年6月に設立されたばかりのTrexEdgeは一言で言えば地方創生を進める会社。「地方にITで革新を起こし、持続可能な社会を作っていくことを目的としている」とのことで、スマートシティより小さく、一次・二次産業まで含んだ「スマートビレッジ」という単位で人やモノのセンシングサービスを展開している。

 具体的な取り組みの1つとしては、LPWAとして注目度の高いLoRaWANが挙げられる。長距離・低速・低消費電力という特徴を持つLoRaWANだが、現在TrexEdgeでは京都府の与謝野町と提携し、街の中にLoRaWAN網を敷設し、巡回バスやトラックなど物流の効率化を進めている。

京都府与謝野町と連携し、LoRaWANでの実証実験を推進中

 また、農業支援アプリ「Agrion(アグリオン)」はタッチ操作で農業データのログ化・見える化が可能なアプリ。公開から1年でさまざまなデータが取得できており、「圃場への移動が全体の20%を占めていたり、新規参入者がベテランに比べて余計なところまで草を刈ってしまっている実態がわかってきた」と語る。

改正FIT法と太陽光発電の監視を実現する「ポケット発電所長」

 今回のセッションのテーマは太陽光発電だ。小川さんは再生可能エネルギーの普及を目的としたFIT法(固定価格買い取り制度)について説明する。FIT法とは「簡単に言えば太陽光で発電した電力を、電力会社が固定価格で買い取らなければならないという法律」とのことで、「再エネ発電賦課金」という用途で電気料金から徴収されているという。

 2010年のFIT法の施行により、再生可能エネルギーの利用は急速に高まった。「それまで年間伸び率は9%だったのが、一気に29%まで伸び、いわゆる太陽光バブルみたいな状態になった」(小川さん)とのこと。とはいえ、賦課金の負担も増加し、当初は50円くらいだったが、現在は十倍くらいに跳ね上がっている。さすがにこれは厳しいということで、2017年4月には改正FIT法が施行され、再生可能エネルギーの事業が従来よりシビアに見られるようになったという。

 今回TraxEdgeが目を付けたのも、この改正FIX法で必須要件となったメンテナンスの義務化という箇所だ。太陽光発電はリモート監視の機能があるが、複数の事業者の監視システムを使っていると、すべてにログインしてデータを取得する必要がある。これらのデータは、いわゆる太陽光発電のオーナー(売電事業者)へのレポートで使われるのだが、これらもすべて手作業で集計する必要があり、大きな負担になっていたという。そこで、TrexEdgeが作ったのが、システムの監視と保守運用業務をワンストップで行える「ポケット発電所長」になる。

太陽光発電の監視システムのデータを集約化する「ポケット発電所長」

 現在、太陽光発電の業界は、太陽光発電所を運営する管理事業者(アドバイザー)と、管理事業者に投資をする代わり、売電収益を得る売電事業者(オーナー)、、管理事業者から委託を受ける工事業者(サポーター)などから構成されている。ポケット発電所長では、太陽光発電の遠隔監視データを一元的に集約し、アドバイザー、オーナー、サポーター、それぞれの業務に合わせたアプリを提供しているという。

ServerlessFrameworkでの開発苦労話

 後半はポケット発電所長のテクノロジー面のお話し。TraxEdgeのメンバーは10人で、そのうちエンジニアは4人。フロントエンドは2人でアドバイザー、オーナーで合計30画面、サーバーサイドは1人でAPIを63個作っている。約500におよぶというデータ連携は1人で10システムを構築している。3ヶ月という短期間だったが、AWSだからこそ実現までこぎ着けられたと言える。

 アーキテクチャはServerlessFrameworkを採用し、監視システムとの連携はすべてLambdaで実装。「監視システムはレガシーなシステムが多くて、APIを用意しているところがほとんどないため、Lambdaでスクレイピングさせている」(小川さん)とのこと。また、データベースはDynamoDBを用いており、データが入った際にDynamoDB Streamで日次・週次・月次のサマライズデータにリアルタイムに変換しているという。

アーキテクチャとしてServerlessFrameworkを採用

 API GatewayとLambdaの連携は、サーバーレスフレームワークのうちAPI Gatewayに対して複数のLambdaファンクションをぶら下げるマイクロサービスパターンで実装。ServerlessFrameworkはCloudFormationを内部的に使っているが、200というリソース上限があるため、Serverless.ymlは分割した。とはいえ、オフライン開発用のServerless.ymlが必要になるなど、管理は面倒。また、エンドポイントが複数できるため、クライアントごとに投げ先を変えなければならなかったという。「規模が大きくなければ、Serverless.ymlは分割しない方がオススメ」とのことだ。

Serverless.ymlは分割したが……

 その他、Cognitoのカスタム属性に組織IDを入れ込むことで、リクエストごとにDynamoDBにアクセスしなくても、どこの組織の人かを判定できるようにしたり、編集の必要がない発電データはAPI Gatewayでキャッシュしたり、さまざまな工夫が盛り込まれているという。まだまだベストプラクティスが確立していないサーバーレスの事例において、エンジニアとして悩みながら開発を進めてきた経緯が赤裸々に共有された事例だった。

■関連サイト

カテゴリートップへ

この連載の記事