Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (Part 3) — First half

This article is the third of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the first half of that.

The following articles have also been published as serialized articles, so please be sure to check them out.

1. Introduction

In this article, we have introduced our efforts in three parts. In the first session, we introduced the overall picture of discussions aimed at utilizing the cloud in our smart meter system. In the second session, we introduced the overall picture of next-generation smart meter systems, including technical perspectives, and our current efforts. The 3rd session, which is the last one, will focus on cloud migration of current smart meter systems, and introduce our thoughts and commitments related to cloud utilization and our efforts.

2. From on-premise to cloud utilization

Our current smart meter system, as described in the first blog, is partly due to the background at the time when development was proceeding ahead of other electric power utility companies, and while there is no package solution for meter data collection and management systems like these days, we proceeded with system development through trial and error in cooperation with multiple system vendors, and built a system assembled based on the system vendor’s technology and specifications at our data center. Full-scale introduction of smart meters to customers began in 2012, and until implementation was completed in 100% households in March 2023, we have achieved continuous stable operation while the number of servers used in the current system has also increased along with the expansion in the number of smart meters installed.

On the other hand, since it is a system developed in such situation, it is facing issues such as economic efficiency and future sustainability issues associated with adopting proprietary OS, commercial databases, and middleware, system blackboxing associated with dependency on system vendors for development and operation, and concealment of business processing logic, etc. Furthermore, the increase in server hardware associated with the expansion of smart meter deployment, and continuous occurance of the termination of server manufacturer maintenance. The impact range was wide, such as technical verification of OS and middleware associated with the outbreak, and not only in terms of cost but also in terms of human workload, both of which were increasing. In addition, due to recent major changes in social conditions, various issues have also become apparent, such as future uncertainty represented by delays in server hardware procurement delivery due to lack of semiconductors. And this complex situation has been a barrier to the expansion of flexible and advanced utilization of data collected from smart meters.

If we operate the system in our own on-premise environment, we will fall into a situation similar to ours, and I think there are many cases where people experience to fall into a situation similar to ours and face issues of the same kind if operating the system in their own on-premise environment. We thought that utilizing cloud technology would be an option as a comprehensive solution to these issues, so we decided to aim for a cloud shift in the current smart meter system.

3. Cloud Utilization Policy for Current Smart Meter Systems

In this chapter, we will introduce how to utilize AWS functions and services in our current system and our system migration policy. There are 3 policies we have set out.
Initiatives for migrating current systems to the cloud

Leave it to AWS to offload things that can be replaced with AWS cloud services
Take full advantage of the flexibility unique to the AWS Cloud
Incorporate technological innovations and new services from the AWS Cloud appropriately while proceeding with development

3-1. Offload to AWS cloud services

On premises, it is necessary to individually deal with daily hardware failures such as disk failures, etc., but in the cloud, such failure response is offloaded to AWS, so we don’t need to be aware of it. Also, by increasing the offloading rate, infrastructure construction and operation and maintenance can be replaced by simply using services. In other words, there is no need to even set up a database, and the system and way of thinking about system construction will change drastically, such as simply selecting and using services (Figure 1).

In our on-premise server system, middleware such as cluster software necessary to ensure reliability has been adopted by each system vendor, but we first positioned this kind of middleware as a target to break away from it. To achieve this, we will implement application improvements including Various things from each company using Amazon Elastic File System (EFS), Amazon FSx, etc., and health checks of server groups utilizing Elastic Load Balancing (ELB). In combination, while multi-AZ redundancy between sites has also been realized, the system reliability of the system as a whole has been improved.

At the same time, it is also basic to break away from commercial databases. We did not take any way of thinking about DB on Amazon EC2 from the beginning of the study, and we are conducting migration studies that assume the use of Amazon Aurora or Amazon RDS like AWS managed services. This way of thinking about actively utilizing various managed services on AWS is the result of evaluating that utilizing managed services will surely lead to an improvement in reliability, operation maintainability, and a reduction in operational load.

Figure 1. Offload IT infrastructure operations to AWS by utilizing AWS managed services

3-2. Utilizing the Flexibility Unique to the AWS Cloud

In the cloud, there is the lightness of using resources when they are needed and discarded when they are no longer needed, and there is an advantage of “being able to go back.”

For example, in the past, server resource sizing was carried out precisely, and then server procurement and implementation were carried out over time, but in the cloud, based on the idea of pay-as-you-go billing, where “you can use your favorite resources, when you like, and for as long as you like,” you can flexibly change the configurations and solutions decided at that point to better ones (Figure 2). In our study, changing instances is also flexible and simple, so we are proceeding with instance type selection while proceeding with desk studies and actual machine verification without closely performing resource sizing.

Figure 2. Advantages of utilizing AWS from an IT infrastructure procurement perspective

Also, in the past, it took a lot of time and money to set up the production environment and development environment, respectively. We are now actively utilizing Infrastructure as Code (IaC) in building IT infrastructure. By automating IT infrastructure deployment using IaC, human errors can also be avoided, and system configuration reviews can be handled flexibly while proceeding with application development (Figure 3).

Figure 3. IaC benefits on AWS

3-3. Appropriately incorporating technological innovation and new services

Even if the architecture was determined to be appropriate at the time of implementation, due to technological innovation associated with the passage of time since implementation, there are more options than at that time, so the range of considerations has expanded, and there is a possibility that a better configuration can be selected (Figure 4, Figure 5).

For example, as we proceed with our consideration, there was an announcement in August 2023 that “Network Load Balancer (NLB) will begin supporting security groups.” At that time, NLB was not covered by security group chains, but as a result of design changes in response to this announcement, it was possible to ensure security with a simple mechanism by incorporating the chaining of security groups across the entire system.

In the construction of next-generation smart meter systems that are currently underway, if better services and functions are similarly provided, the direction is to proceed with development while utilizing them.

Figure 4. Expanding the provision of new services and features through technological innovation at AWS

Figure 5. Expanding AWS services to include the field of analytics (excerpt)

In this article, we have introduced the first three chapters regarding our efforts aimed at cloud adoption of smart meter systems. For the latter half, please see “Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems at Kansai Transmission and Distribution, Inc. (Part 3) — Second half”

Author

This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

Amazon Web Services ブログ