[特集]

高速化する東京電力の スマートグリッド料金システム ―後編―

― CISに適用した「ユニケージ開発手法」の実際 ―
2014/02/01
(土)

既存システムの処理とユニケージ開発手法の処理の違い

図2は、上部が既存システムによる処理の流れで、下部が開発プロジェクトが推進している、ユニケージ開発手法を適用した業務システムの処理の流れである。

図2 スマートメーターシステムへの適用事例:高速大量バッチ処理が必要になる使用量の確定処理の方式

図2 スマートメーターシステムへの適用事例:高速大量バッチ処理が必要になる使用量の確定処理の方式

〔1〕既存システムによる処理の流れ

既存システム(現行の営業料金システム)による処理の流れを、図2の上部に示す。MDMSからBE(バックエンド)連携基盤を通して受信した一般家庭の電力使用量のデータは、各地域(例:東京1、東京2、神奈川)ごとのファイルを中心にバッチ(一括)処理され、電力使用量を確定する。その後、全店規模でデータベース化され、既存システムに格納される。

〔2〕新業務システムサーバによる処理の流れ

図2の下部は、ユニケージ開発手法を採用し開発プロジェクトが推進する新・業務システムサーバの処理の流れであり、現在、構築中のシステムである。

最初に図2の左側にあるMDMSからBE(バックエンド)連携基盤を通して受信した一般家庭の電力使用量のデータは、支店ごとの並列分散処理アーキテクチャによって、30分値積数注3応答ファイルを作成する。ここでのファイルの分割や計算ソートといった順次処理に、ユニケージを適用する。この場合、料金メニュー(契約種別)ごとの分割処理の完了を待たなくても計算が行えるため、パイプを利用した並列処理が効果を発揮する。

またデータチェックは、ファイルへのランダムアクセスとなるためJavaを適用する。このとき、ランダムアクセス対策として処理速度を上げるためオンメモリ処理注4が必須となる。東京電力では、最終的には2,700万台のスマートメーターからの情報注5を扱うようになるため、大容量のメモリを搭載する必要がある。

図2の左側に示すBE連携基盤の次に示す「使用量確定」という処理がバッチ処理の部分である。このMDMSから「使用量確定」部分(ここにユニケージが実装されている)にデータを転送して処理する仕組みとなっている。

電力の需要家数としては、東京を2つに分けて例えば「東京1」が600万件、「東京2」が500万件、「神奈川」が600万件などとなっている。

この「使用量確定」部分で、ファイルベースでユニケージを使って集計をして、月間使用料を算出する。これは月間処理でなくても、日時処理でもリアルタイムに近いスピードで算出可能となっている。

〔3〕「パターン」ごとの処理

図2に示す「パターン」とは、料金体系と関係してくるもので、例えば、顧客の契約している料金メニューによって時間帯別の契約をしている場合、午前8時から午後2時までの料金契約などというパターンがある。これはメニューによって変わるため、そのユーザーが電力会社と契約したパターンに従って料金計算を行っている。

現在は3パターン程度であるが、今後、スマートメーターが導入されていくため、きめ細かい料金メニューが順次増加される予定となっている。そのため、パターンの数も多くなっていくと予測される。

Javaで構築した場合の35倍もの高速化を実現!

図3の上部には、図2に示した各バッチサーバ(例:東京1、東京2、神奈川など)の仕様について、OSはUNIXを、CPUは1.80GHz×4コア(インテルXeon E5-2650L)、主メモリは16Gバイト、ハードディスク(HDD)は100Gバイトの容量をもっていることが示されている。

図3 スマートメーターシステムへの適用事例:パフォーマンス比較

図3 スマートメーターシステムへの適用事例:パフォーマンス比較

家庭からの電力使用量のデータ集計イメージは、

139,500,000件≒1,500,000(ID)×31日×3区間分注6
(処理件数1億3,950万件とは、150万戸(ID)の家庭から31日間、1日3区間分収集したデータ量に相当するという意味)

となり、その合計は1億3,950万件=5.58Gバイトとなる。

図3に、

  1. Javaで構築した場合
  2. プロトタイプ検証した場合(一部ユニケージコマンド利用)
  3. ユニケージコマンド主体で実装した場合

を示すが、当初(Javaで構築した場合)の34.8倍の高速化を実現した。

すなわち、図3に示すように、

  1. Javaで構築した場合の<処理時間>は、約50分(50分=3,000秒)(図3のreal=処理時間(実際の時間)、user/sys=CPU時間
  2. ユニケージコマンド主体で実装した場合の<処理時間>は、1分 25.596秒(=1分25.596秒=85.596秒)

となるので、

3,000秒(=50分)÷85.596秒
(1分25.596秒)=35.05倍

と、当初の35.05倍もの高速化を実現したことになる。


▼ 注3
30分値積数:30分毎に記録される指針値。

▼ 注4
オンメモリ処理:インメモリ処理とも言われる。データをすべてメモリ上に格納して高速に処理する方式。

▼ 注5
1日は24時間で30分値なので、48コマ〔=24時間÷0.5時間(30分)〕となる。このスマートメーターからの情報は、1世帯から1日約1,920バイト程度収集される。したがって、2,700万世帯の場合には、1日に1,920バイト×2,700万世帯=51.8Gバイトのデータが収集されることになる。

▼ 注6
3区間分:朝昼晩の3区間分。

関連記事
新刊情報
5G NR(新無線方式)と5Gコアを徹底解説! 本書は2018年9月に出版された『5G教科書』の続編です。5G NR(新無線方式)や5GC(コア・ネットワーク)などの5G技術とネットワークの進化、5...
攻撃者視点によるハッキング体験! 本書は、IoT機器の開発者や品質保証の担当者が、攻撃者の視点に立ってセキュリティ検証を実践するための手法を、事例とともに詳細に解説したものです。実際のサンプル機器に...
本書は、ブロックチェーン技術の電力・エネルギー分野での応用に焦点を当て、その基本的な概念から、世界と日本の応用事例(実証も含む)、法規制や標準化、ビジネスモデルまで、他書では解説されていないアプリケー...