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

本稿は、関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。
連載記事として、以下も公開されておりますので、ぜひご参照ください。

1. はじめに

本稿では、三部構成で当社の取り組みをご紹介してきました。第 1 回は、当社スマートメーターシステムにおけるクラウド活用に向けた議論の全体像をご紹介しました。第 2 回では、次世代スマートメーターシステムの全体像について、技術的な観点も交えて私たちの現在の取り組みをご紹介しました。最後となる今回、第 3 回は、現行スマートメーターシステムのクラウド移行を中心に、私たちのクラウド活用に関する思いとこだわり、及びその取り組みについてご紹介します。

2. オンプレミスからクラウド活用へ

　当社の現行スマートメーターシステムは、第 1 回のブログで記載した通り、他電力に先立って開発を進めていた当時の背景もあって、昨今のようなメーターデータの収集管理システムのパッケージソリューションが存在しない中、複数のシステムベンダーとの協力のもと試行錯誤しながらシステム開発を進め、システムベンダーの技術や仕様に基づいて組み上げたシステムを、当社データセンターで構築しました。スマートメーターは 2012 年から当社管内のお客さまに本格導入を開始し、2023 年 3 月に全戸導入が完了するまで、スマートメーターの設置台数の拡大に伴い、現行システムで利用するサーバ数も増台しながらも、継続的な安定稼働を実現してきました。
一方で、そのような経緯で開発されたシステムであるため、独自 OS や商用データベースおよびミドルウェア採用に伴う経済性や将来持続性の問題、開発と運用のシステムベンダー依存に伴うシステムのブラックボックス化、業務処理ロジックの隠匿化などの課題に直面しており、また、スマートメーター収容数の拡大に伴うサーバハードウェアの増台、サーバのメーカー保守切れ対応の継続的な発生、さらにそのリプレイスに伴う OS やミドルウェアの技術検証など影響範囲が広く、コスト面だけではなく人的な業務負担も大きくなっていました。加えて、昨今の社会情勢の大きな変化により、半導体枯渇によるサーバのハードウェアの調達納期の遅延に代表される将来の不確実性といった、様々な課題も顕在化しています。そしてそのような複雑な状況が、スマートメーターから収集されるデータの柔軟かつ高度な利活用の拡大の障壁となっていました。

自社のオンプレミス環境でシステム運用していれば、私たちと同じような状況に陥り、同様の課題に直面するケースも多いかと思います。私たちは、それら課題に対する包括的な解決方策として、クラウド技術の活用が一つの選択肢になると考え、現行スマートメーターシステムのクラウドシフトを指向することにしました。

3. 現行スマートメーターシステムにおけるクラウド活用方針

本章では、私たちの現行システムにおける AWS 機能やサービスの捉え方やシステム移行の方針についてご紹介します。掲げた方針は 3 点あります。

現行システムのクラウド移行に向けた取り組み方針

AWS クラウドのサービスで代替できるものは、AWS に任せてオフロードする
AWS クラウドならではの柔軟性をフル活用する
開発を進めながら AWS クラウドの技術革新や新サービスを随時取り込む

3-1. AWS クラウドサービスへのオフロード

オンプレミスではディスク故障など日々のハードウェア障害にも個々に対処していく必要がありますが、クラウドではそういった障害対応は AWS にオフロードし私たちは意識する必要がなくなります。また、オフロードする割合を高めることで、インフラの構築や運用保守は、単にサービスの利用という形に置き換えることができます。つまり、データベースさえも組み上げる必要はなく、単にサービスを選んで利用するだけというように、システム構築の体制や考え方も大きく変わります( 図 1 )。
私たちのオンプレミスのサーバシステムでは、信頼性確保に必要となるクラスタソフトなどミドルウェアはシステムベンダー各社各様のものを採用されてきましたが、こういったミドルウェアはまず脱却の対象として位置付けました。その実現のため、 Amazon Elastic File System(EFS) や Amazon FSx 等を活用したステートレス化を含めたアプリケーション改修を実施するとともに、Elastic Load Balancing(ELB) を活用したサーバ群のヘルスチェックを組み合わせ、かつ、マルチ AZ による拠点間冗長も実現しながら、システム全体としてのシステム信頼度を向上させています。
併せて、商用データベースの脱却も基本としています。検討当初から DB on Amazon EC2 の考え方は一切取らず、Amazon Aurora または Amazon RDS の AWS マネージドサービス活用を前提とした移行検討を行っています。こういった AWS の各種マネージドサービスの積極活用の考え方は、マネージドサービスを活用した方が信頼性や運用保守性の向上とともに、運用負荷軽減に確実につながると評価した結果です。

図 1. AWS マネージドサービス活用による IT インフラ業務の AWS へのオフロード

3-2. AWSクラウドならではの柔軟性の活用

クラウドでは、リソースを必要な時に使って不要となれば捨てる、という身軽さがあり、「後戻りできる」というメリットがあります。
例えば、従来はサーバのリソースサイジングを緻密に行ったうえで、サーバの調達や導入に時間をかけながら進めていましたが、クラウドにおいては、「好きなときに、好きなリソースを、好きなだけ使える」という従量課金の考えのもと、その時点で決めた構成やソリューションを、よりよいものに柔軟に変更できます( 図 2 )。私たちの検討においては、インスタンスの変更も柔軟かつ簡単であることから、リソースサイジングを綿密に行うことなく、机上検討や実機検証を進めながらインスタンスタイプの選定を進めています。

図 2. AWS を活用する IT インフラ調達観点でのメリット

また、従来は本番環境や開発環境をそれぞれ整備するのに、それぞれ大きな手間とコストをかけてきました。私たちは、今回、IT インフラの構築において Infrastructure as Code（IaC）を積極活用しています。IaC を活用し IT インフラのデプロイを自動化することで、人的ミスも回避することができますし、システム構成の見直しもアプリ開発を進めながら柔軟に対応可能です( 図 3 )。

図 3. AWS における IaC メリット

3-3.技術革新や新サービスの随時取り込み

導入当時には適切と判断したアーキテクチャであったとしても、導入からの時間経過に伴う技術革新により、当時よりも選択肢が増えたことで検討の幅が広がり、より良い構成を選択できる可能性があります( 図 4, 図 5 )。
例えば、私たちが検討を進める中で、「Network Load Balancer(NLB) でセキュリティグループのサポートを開始」という発表が 2023 年 8 月にありました。当初は、NLB についてはセキュリティグループチェーンの対象外としていましたが、この発表を受けて設計変更した結果、システム全体にわたるセキュリティグループのチェーン化を取り込みシンプルな仕組みでのセキュリティ確保が実現できています。
現在進めている、次世代スマートメーターシステムの構築においても、同様により良いサービスや機能が提供開始された場合には、それを活用しながら開発を進める方向です。

図 4. AWS の技術革新による新サービス・新機能の提供拡大

図 5. アナリティクス分野を含めて拡大する AWS サービス(抜粋)

本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「 3．現行スマートメーターシステムにおけるクラウド活用方針まで」をご紹介致しました。後半については、「寄稿：関西電力送配電株式会社におけるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 3 回) – 後半」をご参照ください。

Amazon Web Services ブログ