現在、エネがえるの高速化を行っています。進め方としては既存のお客様向けのV3版の高速化、V4版としてゼロから作り変えるもの、の2本立てでお客さまのニーズに合わせてご提供するという方法で高速化を進めております。

１．ゴール設定

V3版、V4版にかかわらず、まずは「本年度のうちに5分掛かっているものを5秒にしましょう！」というゴール設定をしました。こまごまとしたチューニングから、GoogleやAmazonのような検索エンジンのような仕組みを参考にするところまで、魔法のような方法がないかなと期待しながらゴールを目指しています。

２．エネがえるの処理フローとプロセスの解説

エネがえるの処理フローは以下のようになっています。

図1. 処理フロー説明

上の図の主要な処理プロセスを説明すると以下になります。それぞれの【】(カッコ)の記載が計測値で、高速化を行う対象のプロセスとなります。計測値が〜(から)で表現されていますが、これは登録する条件によって処理時間が変動していることを表します。

表1. 各プロセス説明

３．高速化が必要なプロセスと現状

高速化が必要なプロセスと特徴を記載します。比較したい電気料金プラン数、診断したい年数によって処理時間が変動します。

Step5：推計&結果保存
※処理時間が診断年数で変動【5秒〜100秒】 

時間毎の充当される電力量(電力消費量/太陽光発電量)を年数分(N年x365日x24時間分の推計を行います。つづいて、消費される電力量 (蓄電池充電量/電力買電量/電力売電量)の推計を行います。また、この推計は太陽光パネルと蓄電池を導入する前後の2パターンで実施されます。そして、それぞれの結果をファイルに保存します。保存されるファイルは、充当される電力量2種類と、消費される電力量3種類の計5種類となり、2パターンあるので、10ファイルとなります。前処理の結果を次の処理で利用するためすべて順次処理で行います。変動するのは診断年数で、最小1年〜最大35年(今回は15年で計測)となります。

Step7：料金計算&結果保存
※処理時間が比較プラン数と診断年数で変動【5秒〜130秒】　

比較したい電気料金プラン数分の1年分の料金計算を行いますが、ここでは、1年分の電気料金を比較してランキングを行います。変動するのは比較プラン数で、最小1プラン〜最大約200プランとなります。

ランキングで1位になった電気料金プランに対して、診断年数分の電気料金計算を行います。ここでは、1年分をN年分に単純に乗算するのではなく、毎年の蓄電池劣化を考慮するため、N年x365日x24時間の料金計算を行っています。変動するのは診断年数で、最小1年〜最大35年(今回は15年で計測)となります。

比較目安として、変動条件ごとに実際に計測した実測は以下のようになります。

表2. 計測した診断条件(ケース)

４．速度改善に向けての対応案

ここから、本題の実施した/している改善策の状況と課題をご説明します。 

●「電気料金プランの比較を並列にする」

現在1つのLambda関数ごとに複数スレッドが並列実行されるように実装していますが、Java8のForkJoinPoolを使うことでCPU数を考慮しながらスレッドセーフに並列処理が行われるようにしています。この並列数はLambdaの最大メモリ(3008MB)でプロビジョンされるCPU数に最適となるスレッド数(実測で10程度)を上限にして自動で割り当てられてしまいますので、これ以上のスレッド数で同時平行実行をさせるためには、Lambda内部での平行度を上げるのではなくLambdaの平行起動数を増やす対策を行っていきます。 

●「Lambdaがコールドスタンバイなのでホットスタンバイにする」

Lambdaのベストプラクティスそしても掲げられているとおり、CloudWatch Eventルールを使って数秒毎にLambdaの空打ちを実施します。 いつLambdaがコールドスタンバイに戻るかが判定しづらいのでとりあえず1秒毎の空打ちになるでしょうか。

●「N年x365日x24時間の処理を初年の計算結果xN年の掛け算にする」

診断年数がN年の場合に、N年x365日x24時間のループがいたるところで走行しています。経年劣化や再エネ賦課金を考慮しなければ、単年分をN回掛けるだけでも大幅な速度改善が図れるのではないかと思います。

●「診断と料金計算の結果をキャッシュにして同じ条件での診断の場合はキャッシュを返却する」

最後に、上記結果をさらに無駄なく再利用するため、最初に触れた「検索エンジン」の仕組みを使って、超高速な高速化を図ることも検討中です。

●「その他」

他サービスのAPIやライブラリを利用するなど、APIエコノミーを活かしてどんどん高速にしたいと考えます。またUIの使いづらさ(毎回同じような操作が必要になっている、画面が少しスローに動く、画面遷移が多い)も改善することで、UI、UXの両面での高速化を図っていきます。

５．進捗状況と今後について(2018-12-26現在)

上記の考えを元にすすめていきます。高速化も図りつつ、柔軟性もでて、さらにいろいろなご要望にお答えできるものをご提供するべく奮闘中です。サーバーレスでインフラを持たなくても運用ができるというメリットは活かしつつ、Lambdaとの相性を考えて、アーキテクチャやアルゴリズムや処理フロー、言語を変更しています。「V4ではカット？」、「V3でも必要！」といったシビアなジャッジを高速で回しつつ、ご利用されるお客様の笑顔を想像しながら開発を進めております。そして、V3やV4というお互いのメリットを活かしてお客さま取捨選択ししていただけるようなサービス化を目指して進んでいきます(もちろんどちらかがお安くなるかもしれませんよ！)。

それでは、みなさま、良いお年をお迎えください！