日本一やさしく説明する予定の

マイクロサービス入門

#sf_a4

for Beginner

1

日本一やさしく説明する期待外れになる予定の

マイクロサービス入門

#sf_a4

for Beginner

2

3

長谷川 裕一

• 合同会社Starlight&Storm 代表

• 日本Springユーザ会 会長

• Springやオブジェクト指向を中心にしたコンサルティングや教育で活動中

https://www.facebook.com/starlightandstorm/

https://twitter.com/StarlightFuku

3

本日の内容

• マイクロサービスの基本的なハナシ

• マイクロサービスが、なぜ必要なのか？本当に必要なのか？

• マイクロサービスの開発は、どうしたら上手くいくのか？失敗するのはなぜか？

• と云ったことを、自分なりの経験とか知識とかで咀嚼して…

• 技術的なハナシは少ないです

4

マイクロサービスとは…

• みんなが欲しいのは、狭義のマイクロサービスではなく、広義のマイクロサービス

– 狭義

• Microservice

• Spring Bootなどで作った1つのアプリケーション

– 広義

• Microservices

• マイクロサービス=アーキテクチャで作られた、マイクロサービス=エコシステム

5

マイクロサービスとは？

• 固有の責務を持ったサービスをコンポーネント化（部品化）したもの

• 別プロセスで動作するサービス（コンポーネント化されたアプリケーション）

– そのコンポーネントの規模が小さい（マイクロ）

– データは統合されず、サービスごとにデータを持つ

中身の設計は、基本的に今まで通りのNレイヤ

マイクロサービス マイクロサービス

マイクロサービス

6

マイクロサービス=アーキテクチャ

• マイクロサービスは単独で存在するのではなく、メッセージによるコラボレーションを行いつつ全体で1つの仕事をする、自律分散協調のアーキテクチャ

マイクロサービス

マイクロサービス

マイクロサービス

メッセージ

メッセージ

クラウド

7

あれ？オブジェクト指向の説明だっけ？

• メッセージ指向で自律分散協調

• マイクロサービスの位置透過性（サービスロケータ）なども、昔からある設計の考え方

オブジェクト指向自律分散協調

オブジェクト指向はチームワーク１

• オブジェクトは単独で存在するのでなく、メッセージによるコラボレーションを行いつつ全体でひとつの仕事をする。

• オブジェクトは固有の責務（responsibility）を持つ。

オブジェクト

オブジェクト

オブジェクト

メッセージ

オブジェクト

オブジェクト

メッセージ

ごめんなさい。前スライドはこれ

のパクリです

8

参考：これはマイクロサービスではない• 「オブジェクト指向開発超入門」2003年頃の資料から抜粋

• オブジェクト指向の必要性

– 製品やサービスの開発サイクル、ソフトのバージョンアップ間隔が短くなっている• 段階的仕様追加に柔軟に対応した開発体制• 仕様変更、機能追加、システム保守への柔軟な対応• 信頼性の高い堅牢なシステムを短期開発で• インタフェース重視で、部品化と並行開発の現実化

• 高い拡張性/保守性– 保守の容易性

• カプセル化により、変更の影響が広がらない

– 交換、拡張が容易

• 部品となるオブジェクトを取り替えるだけ

• 再利用の仕組み

– オブジェクトを単位として、様々なレベルでのソフトウェアの部品化が可能

• 関連するデータと手続きをパッケージ

– 使い方が明確に決まっているため、クライアント側からの利用が容易

• カプセル化により内部はブラックボックス

• 明確な利用インターフェース

• オブジェクトモデルなら反復型開発

9

マイクロサービス=エコシステム• マイクロサービスで実現されたシステムは、各サービスごとに

変更/追加が行なわれ、漸進的に設計が行われ、進化する

• それを支えるための、ハードウェア等からなるレイヤ

レイヤ1:

ハードウェア

レイヤ2：通信

レイヤ3：アプリケーション=プラットフォーム

レイヤ4：マイクロサービス

• 物理サーバやデータベース、OSなど• ホストレベルの監視、ログ

• ネットワーク、サービスレジストリ、負荷分散など

• 開発環境、テスト、ビルド、リリースツールなど

• マイクロサービスレベルの監視、ログ

• マイクロサービスとその構成情報

10

レイヤ3：インフラストラクチャ自動化• マイクロサービスの開発では必須事項

– 継続的デリバリが実現され、自動テストや自動デプロイなどが採用されてなければならない

11

Concourse CI

コーディングUnit Test...

Unit Test

Metrics

FindBugs

Spring CloudContract

ST

本番

結合システム

管理者

commit

Blue/Green

Deployment結果通知

開発者

自動化の例 Spring Cloud ContracはMicroserviceの単体テストを簡単に実現

Cloud FoundryのCI/CD用に作られたパイプラインCI

エコシステムのチームワーク• マイクロサービス=エコシステムにおける2つの重要な

チームワーク– システム内のマイクロサービスのチームワーク

• マイクロサービスの分散協調

• メッセージ連携による自立と自律

• 責務を持ったマイクロサービスによる役割分担

– 顧客と開発者、開発者、開発チーム同士のチームワーク

マイクロサービス

マイクロサービス開発チーム

開発チームごめんなさい。このスライドも、文章の部分はオブジェクト指向

のパクリです

12

マイクロサービスの粒度• まとめ方

– 固有のサービスをデータとそれを扱う処理の単位でまとめる

– 不自然な複数のサービスをまとめてはいけない

– 単一責任原則

• 変更の理由が同じものは集め、違うものは分ける

• 規模– 2週間で書き直せる程度（Jon Evans）

– 概ね、「郵便番号検索」よりは大きく、基幹システムに含まれる「販売」や「物流」「会計」などよりは小さい

– サービスがチーム構造と一致する程度の大きさ（コンウェイの法則）

– 経験的には、マイクロではなくミニがいい

13

マイクロサービスの正解• クラスの作り方や粒度も、最近になってDDDなどのお陰でよう

やく分かるようになってきてるのに（それでも現場では四苦八苦してるのに）、新しいマイクロサービスに正解を求めることが誤っている

– 正解はプロジェクトで異なる。作ってみないと分からない

• 多分 今後は、異常に大きい（小さい）マイクロサービスや、必要以上に複数の役割を持ったマイクロサービスなどが作られて、10年後ぐらいに笑い話になる

なんでもクラス なんでもマイクロサービス

将来は…

14

マイクロサービスなら上手くいくの？• オブジェクト指向でうまく開発できなかったエンジニア

でも、マイクロサービスだったら上手くいくのか!?

– 大きなモノリシック=システムと、マイクロサービス=エコシステムはどちらがより簡単に、誰でも開発できるか?

マイクロサービス

XP

DDD

UP

Java

オブジェクト指向

Smalltalk

Spring

15

方法論が抜けている…• マイクロサービスには技術論はあっても、開発の方

法論（プロセスと表記法）が抜けている

– サービスとして分割するために、DDDのシステム境界という考え方は役に立つ、とか場面だけを切り取られても…

• 方法論があってもオブジェクト指向開発は、上手くいかなかったケースが多いらしいが…

– アジャイルで動くモノをさっさと作るというのは、少なくともエンプラ系のマイグレーションには向かないだろう

– 方法論がない方が上手くいくという結論にはならないだろう

• カタリシス（コンポーネントベース開発の方法論）やSOAを持ってくる!?

16

マイクロサービス、なぜ必要なのか？

• モノリシックなシステムの問題

– コードが巨大化→全体の把握が困難→１つの修正でデグレが発生→大量のテスト→デプロイのプロセスが複雑→ビジネスの変化に対応できない⇨ じゃあ、マイクロサービスだ！

• マイグレーション

• 時代的な背景の結果

– ビジネスの変化に強い→直ぐに作ってリリースできる→小さく作る→変更した時の影響も小さくしたい→独立性を高くする→そこだけスケールしたい⇨ じゃあ、マイクロサービスだ！

• 新規開発（派生開発の機能追加）

17

モノリシック→マイクロサービス(1)

• 最初に理解しておきたいこと

– 複雑なもの（難しいもの）は簡単にならない

• 「マンガでわかる量子力学」→マンガで描いても量子力学の難しさは無くならない（導入には役立つけど、先に進めば難しさにぶつかる）

• そして、複雑なものは容易に（マイクロサービスに）分割できない

• 間違った理解（新技術に対してよくある）

– マイクロサービスやDDDなどの新技術を使うと、複雑な（難しい）既存システムが簡単になる

• 1つ1つのオブジェクト（コンポーネントやマイクロサービスを含む）のテストなどは簡単になるが、全体が複雑なものは、やっぱり複雑で難しい

18

モノリシック→マイクロサービス(2)• 成功の鍵？その1

– レガシシステムが複雑すぎることを認めて、マイクロサービス化を諦める

• 成功の鍵？その2– マイクロサービス化の前に準備する

• データモデルを整理する

• MyBatisで複雑なSQLを利用するのをやめて、JPAやHibernateで動作可能にする

• 役割ごとにパッケージ化して、複雑な依存関係（特に相互依存）をなくす

– 一度にマイクロサービス化しない

• 変更が多い部分などから少しずつモノリシックから抜き出して、マイクロサービス化する

– 最初から最高を求めない（次からのスライドを参考）

19

参考：構築計画と手順

• 最初から最高レベルを目指すのではなく、開発スケジュールとレベルは概ね下図を目標とする

20

参考：Cloud Native Maturity Model

21

レベル 概要

Cloud Native ・最適化されたMicroservices アーキテクチャが適用されている・APIファーストな設計が行なわれている

Cloud Resillient ・Microserviceは、依存するサービスの障害に影響を受けない・障害やパフォーマンスも含めたMicroserviceの測定とモニタリングができている・作成するMicroserviceはクラウド環境に影響されないようになっている

Cloud Friendry ・アプリケーション（Microservice）では、Twelve Factorが実現されている・システムは、水平方向にスケーラブルとなっている・システムは高可用性となっている

Cloud Ready ・アプリケーションは独立している・インフラはコードで管理されている・クラウド環境を利用している

参考：Cloud Native Application Maturity Model

22

レベル 概要

Adaptive（適応）

GOAL: 運用や管理が自動化された状態・アプリケーションは、サービスの中断なしで、動的にインフラ間を移動できる・アプリケーションは適切にスケールイン/アウトを行うことができる

Abstracted（抽象化）

GOAL: マイクロサービスの構築・サービスはステートレスである・アプリケーションは依存しているサービスを知らない。また失敗による影響も受けない・アプリケーションは、インフラストラクチャにとらわれないで、どこでも実行することができる

Loosely Coupled（疎結合）

GOAL: 主要なコンポーネント（もしくはレイヤ）が独立している・アプリケーションは、疎結合なサービスで構成されている・アプリケーション（サービス）は、名前によって発見される・アプリケーションの処理とストレージが分離している・アプリケーションは1つ以上のサービスを利用している

Virtualized（仮想化）

GOAL: 迅速なインストール・アプリケーションは仮想化されたインフラ上で実行される・システムはイメージとして保存され、インスタンス化できる

マイクロサービスの数が増えたら• もし、レガシシステムをマイクロサービスにすること

が出来るとサイロ化（多くのサイロは、実際には完全に独立している訳ではない）の問題が出てくる

– 大きなサイロを小さくしてもサイロはサイロ

XXXシステム

OOOシステム

大きいサイロは小さくなるが…

23

つまり、誰が管理するのか？• 誰が、システム全体もしくは1つのマイクロサービスを運用/保

守するのか？（コンウェイの法則!?）

• マイクロサービスでは、ビジネスケイパビリティに基づく組織化（役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する）、プロジェクトではなくプロダクト（コンポーネントは期限のあるプロジェクトとして開発されるのではなく、継続的なプロダクトとして提供される）と言われるが…

• そもそも、サービスの数は管理するか？ 上限はどうやって決まるのか？

24

忘れさられるサービス• 特定のサービスに対しては、変更や関連するサービスの追

加などが行われるが、その他多くのサービスはリリース後に何も起きず、担当チームもなくなり、そのうち、それらのサービスは何をしているかも忘れ去られる

この辺のサービスは良く分かるが…

その他のサービスは良くわからない

25

注文システム

復元できないデータモデル

• FKはマイクロサービス化で消した、ER図はもちろんない、いや待てよマイクロサービス図がある…の!?

– そもそもスケールさせることを考えたら、RDBは捨てなければダメ…!?

商品管理 注文管理

商品TBL

注文TBLFK

商品サービス

商品TBL

注文TBL

注文サービス

【外部キーの削除として紹介されているテクニック】

26

技術的な選択

• マイクロサービスでは、分散ガバナンス（サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される）などとも云われるが、現実的には、言語はJavaで、Springに統一した方が良い

• Java以外の言語が許されるのは、フロントエンドのUI部分だけにした方が無難

フロントエンドUI

マイクロサービス

HTML

テンプレート

CSS

$websocket

(Kaazing)

$http

データ

モデルロジック

Web

ストレージ

コントローラロジック

ビューロジック

ビュー コントローラ モデル

ディレクティブ

フィルタ

バリデータ

$scope

サーバサイドはSpring Boot

Angularなど

HTTP/REST

27

現在のシステム• 現在のシステムをSoR(System of Record)とSoE(System of

Engagement)で俯瞰してみる– SoRはメインフレームの基幹システムに代表されるデータを記録するような、定

型的なシステム

– SoEはクラウドやモバイル、センサーデバイスを積極的に利用するような、非定型的なシステム

28

SoE

SoR

オンプレ+

モノリシック

勘定系 販売系 B2B IoT

• Cloud• 分散• 可用性

• Legacy• 集中• 一貫性

マイクロサービスの適用• 既存システムの有無、データモデルや組織的な部分で成功

と失敗が分かれると推測する

29

SoE

SoR

オンプレ+

モノリシック

勘定系 販売系 B2B IoT

• Cloud• 分散• 可用性

• Legacy• 集中• 一貫性

MIcroservices

多分、成功する（している）ところ

MIcros

ervices 多分、あまり成功しないところ

結論!?

• 適材適所でマイクロサービスとレガシシステムのハイブリッド

マイクロサービス

マイクロサービス

マイクロサービス

メ ッ セージ

メ ッ セージ

マイクロサービス

マイクロサービス

マイクロサービス

XXXシステム

OOOシステム

Legacy、一貫性勘定系…

Cloud、分散B２C…

コンシューマ

無理にマイクロサービスにしないところ

マイクロサービスを積極的に取り入れるところ

30

まとめ

• いろんな意味でまだまだ、マイクロサービスには課題は多い

• でも、やってみる、勉強してみるだけの価値はある（エンジニアにとっては）

• そして、 マイクロサービスをやるのならSpring !

新しいものは決してうまく働かない。だがいつも、今度こそうまくゆくだろうという希望がある（G・M・ワインバーグ ）

31

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

32