寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第2回) – 後半

　本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第2回の前半となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。前半については、こちらのリンクからご確認ください。

　なお、第1回の寄稿については、「寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半)」をご参照ください。

４．システムアーキテクチャ

　次に、私たちが検討を進めている次世代スマートメーターシステムのアーキテクチャの概要をご紹介します。
　上述の開発方針に沿って疎結合アーキテクチャを実装するにあたって、サブシステム間の連携では疎結合を基本としています。具体的には、HES から MDMS 、そして MDMS からデータを一元管理するメーターデータ活用基盤へのサブシステム間連携においては、Amazon SQS を活用してシステム間を非同期に連携させながら、高い弾力性とリアルタイム性の高いデータ転送を同時実現できるよう設計しました。SQS をベースとした仕組みを構築することで、定期的に大量に発生する検針値や、停電や復電時に大量に送信されてくるイベント情報などをバッファリングしながら受信して、後続処理に高速に連携していくことができ、大量のバーストトラフィックに対して弾力性を保ったニアリアルタイムの処理が可能なアーキテクチャを組んでいます。

　また、疎結合アーキテクチャを基本とするサブシステム内では、マイクロサービスの活用を進めます。業務ロジックを見直して機能を細分化し、使用量計算や計器イベントの処理などは AWS Lambda などを活用、パッケージ的なアプリケーション実行環境は Amazon ECS, AWS Fargate をベースとしたコンテナ環境で実現、その上で、Amazon S3 や Amazon DynamoDB などと API 連携することで疎結合アーキテクチャを組み上げます。現在は制度が決まっていない将来的な新機能実装については、機能細分化されたサーバレスやコンテナを活用しながら柔軟かつ俊敏な開発を実現します。

　データベースのセキュリティやバージョンアップの対応に係る運用保守性の向上などを念頭に置いて、AWS マネージドサービスを中心に据えてシステムを組み上げる方針としており、これに伴い、S3 だけではなく、Amazon Aurora 、 Amazon KeySpaces、DynamoDB や Amazon RDS for PostgreSQL といったデータベースや、データ連携のための Amazon API Gateway など各種マネージドサービスを活用しています。

　スマートメーターシステムで収集された検針値データや設備情報などの将来的な高度利活用やその活性化に向けて、まずはメーターデータ活用基盤のデータストアにそれら情報を一元的に集約管理するとともに、これを起点としたデータ活用の仕組みを Lambda や API Gateway などを利用しながら先行開発します。データ利活用の高度化に向けては、このデータストアに Amazon QuickSight などを連携して手軽なデータ分析が可能な環境を整備するとともに、AI/ML サービスも試行錯誤の段階から活用して業務適用できるようにしていく計画です。

　図 6 に、私たちが開発を進めているシステムの全体概要を示します。

図 6 当社の次世代スマートメーターシステムのアーキテクチャ概要

　私たちの 15 年間に亘るスマートメーターの取り組みの中で、様々な課題に直面してきました。それらは例えば、システム間での機能重複や、複雑な連携方式など、データ利活用に際して柔軟性に欠ける課題や、システムベンダの独自 OS や商用データベース、ミドルウェア採用に伴う経済性や将来持続性の課題、システムのブラックボックス化や業務処理ロジックの隠匿化などの課題、更には半導体枯渇によるサーバハードウェア調達納期の遅延など、将来の不確実性も含めた課題というものでした。これらの課題は、一元的なシステムコンセプトのもとでの開発ができなかったことが根源的な要因だと考えており、今回は自らの開発コンセプトを入れ込むことを重視しています。

　そのためには私たちが今回開発プラットフォームとする AWS クラウド上のシステム基盤を正しく理解する必要があります。つまり、アプリケーションレイヤから、それを支えるインフラレイヤまで、すべてをシステムベンダに任せてシステム開発するのではなく、今回は、クラウドのインフラレイヤと、その上のアプリケーション用の AWS アカウント管理からネットワーク機能、セキュリティ対策など、システム全体に係る共通的な機能を「共通基盤」として整理したうえで、私たちが管理することでアプリケーションレイヤの開発方向性を含めて全体統制することとしました。私たちがインフラレイヤを正しく理解し、深層まで把握することで、これを基盤とするアプリケーションの開発についても、システムベンダとしっかり連携して協調しながら進めることができると考えています。システムベンダにとっても、業務に紐付くアプリケーション開発により注力することができるようになるため、結果としてこれまで以上のシステム品質確保が可能になり、将来的なデータ利活用にも確かな道筋を手に入れることができるものと考えています。

　私たちがクラウドのインフラレイヤを正しく理解して所管し、将来的なデータ利活用まで手の内化していくための取り組みのポイントが三つあります。

　一つ目は、AWS のマルチアカウント戦略に基づいて、AWS アカウントを分割することです。これによって責任範囲を明確化するとともに、セキュリティ面の強化を図ります。具体的には、共通基盤は私たちが管理した上でシステムベンダごとに AWS アカウントを分割し、ベンダにはアカウント内でシステム構築や保守を実施いただきます。また、システム間の接続点は最小化し責任分界点を明確化します。必要なユーザ ID も、共通基盤側から提供します。これを、AWS のマルチアカウント戦略(*2)の考え方の元、整理したものが、図 7 となります。

(*2) Organizing Your AWS Environment Using Multiple Accounts

　このように、本番、試験、開発という環境を分離して整備するとともに、各環境内において共通基盤やサブシステムごとの責任分解を AWS アカウントにより明確に分割しています。これにより、システムベンダは付与されたアカウント内においてアプリケーションシステムの開発に注力し、システムの運用保守も担当いただきます。

図 7 AWS アカウントのシステム間分割による責任範囲の明確化とセキュリティ強化

二つ目は、AWS の責任共有モデルをベースに、AWS とシステムベンダ、および私たちの責任範囲を明確にすることです。これに伴い、OS など標準化が必要なものは共通基盤として私たちが管理してベンダに提供します。OS 種別やバージョンに係るシステムごとのバラツキをなくすことができ、TCO 削減にもつながります。具体イメージは、図 8 となります。

　三つ目は、AWS Professional Services の協力を得ることです。クラウドのフル活用を実現するためには、共通基盤の導入が必要不可欠であり、その上でシステムベンダ各社との協力をより緊密にしていくことが重要だと考えています。これには、私たちが当事者としてシステムを正しく理解して、環境変化に伴うシステムの拡張や変更に着実に対応していくことが求められ、つまりは私たちが AWS を正しく理解することが必須であり、AWS Professional Services の協力を得て検討やスキル・知見の獲得を加速しています。AWS Professional Services のメンバーと随時協調を取りながら、多岐にわたる技術課題を適切に理解し柔軟かつ的確に課題解決を図りつつ、プロジェクト推進にかかる PMO のサポートや私たちのメンバーの教育支援など、包括的な支援をうけることで、システム開発を加速させて取り組みを進めています。

6．おわりに

　今回の寄稿では、AWS を活用する次世代スマートメーターシステムについて、技術的な観点も交えて取り組み状況をご紹介しました。次回は現行スマートメーターシステムのクラウドシフトについてご紹介したいと考えています。

以下に、連載記事として第 3 回がの公開されておりますので、ぜひご参照ください。
第 3 回の記事「寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 3 回) – 前半」

執筆者