マルチビリングパッケージ

自己紹介

自己紹介の方をさせてください。佐藤猛と申します。
入社8年目になりましてエンジニア経歴はだいたい15年ぐらいになります。前職では某社にて、全国の自治体さんを結ぶようなデータ連携基盤を作ったりですとか大手のeコマースで、保守開発などを経験してまいりました。
入社当時は決済の知識は全くなくて、右も左も分からないところからスタートしたという経歴でございます。入社当初から、今回ご説明しますマルチビリングパッケージを一貫して担当しておりまして得意な分野はJavaとAWSとなります。
ちなみに、当社初のAWSCloudを使用したプロダクトの開発リーダーを経験しております。今の仕事は公共事業者様案件のスタートアップをリードしたり、ビジネス寄りの位置に少しシフトしているかなというような状況でございます。

電力ガス業界の動向

本題に入る前に少しだけ昨今の電力・ガス業界の動向についてお話しさせていただきます。
まず電力小売自由化という世の中にとっても私たちにとっても、とても大きな法律改正が2016年にありました。この影響で一般電気事業者でしか販売できなかった電気が様々な業種の企業で販売できるようになりました。
経産省のHPで調べてみると、現在小売電気事業者として登録されている事業者は738社もあるそうです。おそらく皆様のお住いでも、どこが一番安くて便利か、一度は悩まれたご経験があるのではないかと思います。
ガスも同様に、電気自由化の翌年の2017年に自由化されました。こちらも同様に事業者の数が着々と伸びて、私たち消費者側の選択肢も劇的に増えている現状です。
このようにですね、小売自由化をきっかけにして多種多様な業界が参入したことで競争も激化しているわけです。これまで1社独占だった〇〇電力さんとか××ガスさんのような大手各社さんも転換期にあると。既存の料金回収のモデルですとか、販売戦略についても大きな変革を求められている状況といえます。
例えばオペレーターさんの業務効率化であったり、今までは自分たちで全部やってきたけれども他に任せるというような考え方に少しずつシフトしてきて、我々のような決済に特化したサービスを使ってシステム面の効率化を図るというのも傾向にあるのかなと思っております。というのがシステム投資効率化というところです。
電気ガスの単品販売だけだと先行き不安ですので、それを補う付帯サービスを作るであるとか、DXですね。これは先ほど飯島からも説明ありましたけれども、例えば紙の払込票のコストがものすごく高いのでそれをデジタルな手法に変えるとかです。利便性やコスト削減というところを日々追求しているわけです。
こうした課題要望に対してスピーディーに対応するために、電力とガスに特化したマルチビリングパッケージというサービスを開始しました。拡張性と安定性という2つを意識したサービスになっていますので、本日はこの2 つをテーマにお話しさせていただきたいと思っております。

システムを小分けにする（マイクロサービス）

まず1点目、システムを小分けにする、つまりマイクロサービスの考え方です。
マイクロサービスというと、人によって考えややり方が分かれますが、我々は主にプレゼンテーション部分と共用ビジネスロジック部分を分離しています。
プレゼンテーション部分はこの図の中の楕円形の部分で、真ん中の5角形の部分が共用のビジネスロジック部分になります。
プレゼン部分について、A社B社C社と表現していますが、会社ごとの要件に応じてUIやファイルのインターフェースの部分などは完全に分けているイメージになりまして、共用ビジネスロジック部分は、基本的に決済であるとか、クレジットであるとか、口座振替、決済や業務ごと、会員処理であるとか、取引売上処理であるとか、そういった単位で分けているということになります。また、下の方にありますのは、クレジットカード会社などの外部の収納機関との接続を集約している部分になります。

このようなシステムを小分けにしていると何がいいのがという点ですが、細かい単位で開発を進められるという点がまず一つ、担当しているお客様ごとでチームを編成しやすく、小さい規模感で開発を進められるというところが一つの利点かなと思っております。

二つ目は障害ポイントを特定しやすいという点で、システムそのものを分離していると、障害が発生してもその障害によってどれだけ影響が出たかであったり、調査範囲も発生したシステム内の部分に限定しやすい、上に報告をあげるときにも構成を分けているのでここだけが障害ポイントですと説明しやすいみたいなことがあったりします。

三つ目は小ネタ的要素ですけど、新しい技術を試せるということで、例えば新しいフレームワークを入れるとか便利そうな、ちっちゃい話ですけれどもJavaのオープンソースライブラリを試してみるとか、を1個1個が小さいからこそ、挑戦するリスクを取りやすいのかなと思います。

四つ目のテストを回しやすいというのは、一つ一つのシステムのサイズが小さいので、ビルド～テスト～デリバリーの一連のが高速に回せるということで、これも非常に大きなメリットかと思います。

ここまでで一通りマイクロ化の利点４つ申しあげましたが、内部の課題としてはリグレッションテストの強化というところになるかなと思っています。ビジネスロジック部分は共通要素を取り持っている部分のため、ここに万が一手が入った時、十分なテストができないと場合によっては全体に影響が出てしまう可能性があります。

我々も途上段階でありますけれども、特にビジネスロジック部分については、UT単体テストであったり、IT結合テストのレベルまでは自動化するというところを社内での標準とするようにしております。
ということで、当社なりのマイクロサービスの活用事例についてのご説明させていただきました。アプリを表と裏、アプリの表がプレゼンテーション部分で裏がビジネスロジック部分と明確に分離しまして、それぞれ小さい規模感で開発を進めることでシステムの拡張性と安定性を確保しているという話です。
ちなみにですけれども、今回申しあげたようなお客様単位とか会社単位で、並行で開発を進めるというようなスタイルと我々がすごく相性が良いアーキテクチャーはマイクロサービスかと思っていますが、一方で、マイクロ化するとレイテンシの問題や、データの一貫性が保たれないといった負の側面もあるのでそれら全てを理解した上でご判断されるのがよろしいのかなと思っております。

等身大の分散化処理を

等身大の分散化処理についてです。お見せしている資料がクレジットの一括請求処理です。当社の処理の中でも一番ボリューム感がある処理例に対して工夫しているポイントというのを、いくつか説明させていただきたいと思います。
まず、赤枠の①のところ、ジョブコントロールサーバーですね。AとBとCとありますけれども、いくつかのブロックにデータを分割していまして、起動時間もなるべくなだらかになるようにスケジュールしているというところになります。次に②の部分、各Jobの中身になりますけれども、Javaのマルチスレッドで処理しているというのが右側部分のイメージになります。前段で個社単位でABCで分けたブロックを、さらにマルチスレッドでだいたい10ぐらいに分割して並列で処理しているということでございます。最後は③の部分で、DBの処理ですね、バルク処理によって一斉に書き出しを行うということです。一件一件クエリを発行するとクエリ生成のオーバーヘッドが発生してしまいますので、それを削減するようにバルクで処理しているというところになります。
このような構成にすることによるメリットですけれども、先ほどのマイクロサービスの時と若干かぶりますが、何か障害が発生した時の範囲が特定のお客様に限定されるところです。本来であればそもそも障害が起きないように予防するというのが望ましいのですが、100%完璧なシステムを実現するというのは厳しいため、最悪何か想定外のイレギュラーがあった時でも、致命傷を小さい範囲で抑えることを強く意識しているというところでございます。
もう一つは、このクレジット処理はシステム全体の中でも大変重要な機能ですが、何かあるととんでもないインパクトがあります。だからこそ、この部分については自分たちが一番慣れ親しんだピュアなJavaで全て構築しているという事が一つ特徴的な点かと思います。ピュアなJavaなので、DIもORマッパーとか一切使用してないと多少ちょっと不便なところはありますけれども、ブラックボックスをほぼ排除できるという点で安定的に運用するために必要です。とても地味なんですけれども、重要な点です。
もう一つメリットとしては、性能要件に応じてリソースをチューニングしやすいという点です。性能要件はお客様によって大きく違いまして、割と緩めな要件のお客様の場合は jvmのメモリー効率の割り当てを増やすとか、スレッド数を少し増やすとかで、既存のリソースでやりくりするとことで何とかなるケースもあるのですが、お客様によっては短い期間で1000万件を超えるようなデータを処理しなければいけないというような場合には、今あるリソースだと足りないので、ハードごとに調達して専用サーバーを構えるなどして判断がしやすくなります。
ということで、各ブロックに分けて管理するということと、重要な機能こそあえて純正のプログラムで組んでいるという点についてお話しさせていただきました。これらは、一見小さなようですけれども、そうした小さい工夫の積み重ねを行うことで拡張性と安定性を確保しているということであります。
現場によって事情は異なりますけれども、よっぽど厳しい非機能要件がない限りはこうした工夫次第で十分なスループと出すことは可能だと思っております。

大切にしていること

私の方からマイクロサービス化と等身大の分散処理というテーマで、冒頭に申しあげた拡張性と安定性をどうやって確保しているかということについてお話しさせていただきましたが、続いて私たちが仕事を成す上で大切にしているということについてお話しします。
一つ目は、現場を知るということですね。世の中はデジタル化によるキャッシュレス化が進行していますけれども、本当の意味でお客様が望むデジタル化を果たすためには、決して我々の一方的なものではなく、そのお客様の業務であったりとかシステムをより深く理解することが必要になります。
例えば現地にお伺いして信頼を得ながら提案活動するとか、お客様と同じ方向を向いて仕事をするんですね。こうした地道な積み重ねで初めてお客様の業務やシステムに調和したものが提供できると考えています。ちょっとややコンサルっぽい話になってしまいましたけれども、現場を知ることですね。我々はそのことを何より大切にしている舞台であるということをお伝えしたいことの一点目になります。

二点目は挑戦するということであります。冒頭申しあげたように、公共料金決済の市場はまさに戦国時代、群雄割拠で劇的に変化していく状況でありまして、その中で我々も数字を伸ばしているわけですけれども、それはイコールシステムの規模もどんどん大きくなっていると。つまりリスクもそれだけ増えているということを意味します。そうした局面で、どうすればユーザビリティを上げられるかとか、あるいは品質を確保できるか、運用コストを削減できるか、常日頃新しいことに挑戦して様々な問題を打開していくという思考能力が今まさに求められていると思っております。今回はお話ししたトピック以外にもであったりとか CICDであったりとか、一部AWSで組んでいるところもございますので、ハイブリッドクラウドというテーマでもまたの機会でお話しできればと思います。こういった新しいことに挑戦できる土壌が当チームにあるという点を最後にPRして終わりとさせていただきます。

ご清聴ありがとうございました。