Fight with Complicated MircoServices

マイクロサービスの複雑さとの戦い

SBI securiteis Co., Ltd.

System Develop Division

ΛTL

Public Edition

Public Edition

  • 固有名詞は伏せてあります。
  • 過度な誇張が含まれる場合があります。
  • 一般化により実際の環境と異なる場合があります。

In other words

このドキュメントはフィクションであり、

実在の人物・団体とは一切関係ありません

The following story is fictional and does not depict any actual person or group.

Well, I can say anything else ;P

マイクロサービスとは

  • サービスを細かく分割する
  • サービス同士の依存度を減らす

PROS

  • 分割統治による蜜結合と複雑さの回避
  • F/Wや言語を分けてもOKなので少しずつ更新可能

CONS

  • プロジェクトが増える事自体で複雑度があがる

従前のシステム

PL-FP

Large BL

PL-PC

※図にしようしたら時間がかかりすぎるのでやめました

フレームワーク変更するためには

全て作り直さなければならない

PC: Desktop PC

FP: Feature Phone

SP: Smart Phone

PL: Presentation Layer

BL: Business logic Layer

PL-SP

マイクロサービス化

BL-Customer

BL-Products

BL-Order

  • BL間は互いに依存しない
  • PL-BL間はJSON RESTful API
  • 複数のAPIバージョン混在OK

各サービスが独立しているので違う言語でもOK

PL-FP

PL-PC

PL-SP

BL-SSO

BL-Crypto

BL-ATM

PC: Desktop PC

FP: Feature Phone

SP: Smart Phone

PL: Presentation Layer

BL: Business logic Layer

BL-Price

物理配置

LB-PC

LB-FP

LB-SP

WEB-FP

WEB-FP

WEB-FP

WEB-PC

WEB-PC

WEB-PC

WEB-SP

WEB-SP

WEB-SP

LB-Customer

LB: LoadBalancer

AP: Application server

AP-Customer

AP-Customer

AP-Customer

LB-Product

AP-Product

AP-Product

AP-Product

LB-Order

AP-Order

AP-Order

AP-Order

LB-Other

AP-Other

AP-Other

AP-Other

AP層のサーバー群定義が増えすぎてつらい

対策を検討

  • どうせ今のところJava/Scalaしか使わない
  • APサーバーを増やしたくない

対策

各MicroServiceのプロジェクトを

serviceとwebに分割

BL-Web-Customer

BL-Service-Customer

BL-Web-Product

BL-Service-Product

serviceは他のプロジェクトに取り込める

BL-Web-ALL

BL-Service-Customer

BL-Service-Product

BL-Service-Order

BL-Service-Price

必要になったらサービスを独立させる

対策後物理配置

LB-PC

LB-FP

LB-SP

WEB-FP

WEB-FP

WEB-FP

WEB-PC

WEB-PC

WEB-PC

WEB-SP

WEB-SP

WEB-SP

LB-AP

AP-A

AP-All

AP-All

LB: LoadBalancer

AP: Application server

結果

元のLarge BLとあまり変わらない

モジュール化を推進しただけ

重要

モジュール化を推進

「いろんな言語を適材適所で使う」

システムを陳腐化させず、FW等を適宜入替

可能にするにはデプロイ単位を小さくして疎結合にしておく事が最も重要

”選択は、ある時点で確定することはなく、時間の経過とともに、その都度、何度でも行う必要がある"

改修予定

EOSLなFWの入替

ポストJavaへの移行

Scala: バイナリ互換どうにかならないと長期プロジェクトでは厳しい

Clojure: SIerの連れてくる一般的な技術者にS式は無理では

Kotlin: もっと人気がでて情報が出てくれないとトラぶった時大変

・みんな大好きなアレ

<<JVM言語>>

<<その他>>

Haskell: Webの最適解出てない感じ

Go: 冗談でしょ?

D言語: D言語君万歳!

結論:将来に期待

将来の技術進化に

漸進対応できる

作りにしよう

Fin.

Made with Slides.com