マイクロサービスに関する説明資料です。

1. マイクロサービス
MICROSERVICES

2. MICROSERVICES?
マイクロサービスとは？
・少しバズワードぽいがとりあえず流行り言葉の一つだから抑えておきたい
・触ってみて自システムへの導入検討につなげたい
・アマゾンやクックパッド等、実例は多いものの、SOA(Service Oriented Architecture:サービス指向アーキテクチャ)と
の違いが今一つわからない
複数の小さなサービスの集合体としてシステムを構築し、各サービス同士をHTTP経由のAPIやメッセージングなどの
軽量な通信で連携する手法。
JAMES LEWIS氏によって提案された言葉で、同氏がMARTIN FOWLER氏と執筆した記事「MICROSERVICES」に
より各所で取り上げられるようになった。
複数の機能をひとつのアプリケーションの実行物として構築する「モノリシック(一枚岩)」アーキテクチャと比較さ
れる。
＜マイクロサービスに対するイメージ＞
＜定義＞
https://news.mynavi.jp/itsearch/encyc/microservices

3. 画面 ロジック DB
開発 ビルド デプロイメント
MONOLITH AP
画面 ロジック DB
画面 ロジック DB
開発 ステージ
ング
本番
業務A
一枚岩単位での
ハード増強
A
業務B
業務C
B
C
A
B
C
A
B
C
A
B
C
修正時
一枚岩単位の
再ビルド
MONOLITHとは一枚岩の意で、システムを単一のアプリケーションで構築します。
PROBLEM OF MONOLITH

4. 本番
開発 ステージ
ング
本番
開発 ステージ
ング
本番
開発 ビルド デプロイメント
MICROSERVICE AP
MICROSERVICE AP
MICROSERVICE AP
業務A
業務B
業務C
開発 ステージ
ング
本番
A A A
C C C
B B B
C
業務単位での
ハード増強
業務単位で
再ビルド
画面 ロジック DB
画面 ロジック DB
画面 ロジック DB
システム全体を小さな粒度に分けて構築
SOLVED BY MICROSERVICE

5. SOAMICROSERVICES
REST SOAP/WSDL
/ESB/BPEL
中央集権分散統治
マイクロサービスとSOAの1つの共通点と2つの違い
1 common and 2 differencebetween microservices and SOA
サービス化

6. WEBAPサ
ーバ
WEBAPサ
ーバ
A
B
WEBAPサ
ーバ ESB
WEBAPサ
ーバ
A B
プロトコル変換
メッセージ変換
高負荷制御
セキュリティ
REST
SOAP
+WSDL
SOAP
+WSDL
<マイクロサービス>
<SOA>
通信方式面での複雑さの違い
Difference of Complexity about communication
• SOAは端的通信に関わる部分にESB製品を利用でき高機能である反面、導入のハードルが高かった
• マイクロサービスは「スマートエンドポイントとシンプルな土管」と呼ばれる思想を前提
• 通信部分にスマートさ（高機能）を載せるのではなく、シンプルな通信経路（土管）とし、サービス（のエンドポイント）
に対して必要な機能を設ける

7. マイクロサービスの起源と流行
Origin of Microservices / in trend
• 33RD DEGREE CONFERENCE CONFERENCE FOR JAVA MASERSにて、JAMES LEWIS氏が2012/3/20
に発表した”MICRO SERVICES - JAVA, THE UNIX WAY”が始まりとされる
• JAMES LEWIS氏とMARTIN FOWLER氏が2014/3/25に掲載した”MICROSERVICES”が各所で引用

8. Google Trends「microservices」
「microservices」のGoogle Trendsの比較結果
GOOGLE TRENDSを見ると、マイクロサービスは2014年あたりから伸び始め、2015年に入って急激な伸び
を示していることがわかります。

9. 青：microservices、赤：EJB(Enterprise JavaBeans)、黄：SOA(Service-oriented
Compare with agile, cloud, and IoT
クラウド、AGILE、IOTといった以前より知名度の高い単語と比べる
と、まだまだ小さい値
EJBやSOAといった類似した単語と比べると、
他が下降傾向にあるのに対し、マイクロサービスの伸びを考慮する
と、数年後には逆転の可能性有
青：microservices、赤：Cloud computing、黄：Agile software development、緑：IOT

10. 「YOU BUILD IT」
「プロジェクト」
（開発フェーズ：数ヶ月〜数年）
「YOU RUN IT」
「プロダクト」
（運用フェーズ：数ヶ月〜数年）
運用・監視
障害対応
「two pizza team」
「ビジネス遂行能力に基づいた組織整理」
「Two pizza team」と「You Build It, You Run It」
「YOU BUILD IT, YOU RUN IT」 ：「コードを作った人は、運用の責任も持つ」
「プロジェクトではなくプロダクト」：運用含めシステムのプロダクトとしての
ライフサイクル全体を管理すべき

11. CONTROLLER
(サーブレット)
VIEW
(JSP)
MODEL
(EJB)
・リモートインタフェース
public class HelloBean implements SessionBean {
public String sayHello(String myName) throws EJBException {
return ("Hello " + myName);
}
public void ejbCreate() throws CreateException {}
public void setSessionContext(SessionContext ctx) {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void ejbRemove() {}
}
・ejb-jar.xml
<enterprise-beans>
<session>
<ejb-name>Hello</ejb-name>
<home>hello.HelloHome</home>
<remote>hello.Hello</remote>
<ejb-class>hello.HelloBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
マイクロ
サービス化
MVCモデル・EJBと、モデル部分のマイクロサービス化
EJBは3.Xになってこそ、実装が簡易化されましたがインタフェース定義等の複雑さや機能の過剰性からか、爆発的な普及には至らなかった印象

12. MICROSERVICE AP
業務A
開発 ステージ
ング
本番
A A A
ビルド デプロイメント
コンパイル
(JAVAC)
テスト実行
(JUNIT)
パッケージ
(WAR)
WAR
配備
テスト実行
(SELENIUM)
Jenkins
Build Pipeline using Jenkins
JENKINS 2.0のリリースなど、ビルド・デプロイメントを構成する単体のジョブに関する機能に加えて、ビルドパイプラインと呼
ばれる、ジョブのつながりを管理する機能が強化
スピーディーにビルド・リリースしていく仕組みが考えられています。
・一部の先行ユーザだけに先行してリリースする「カナリアリリース」
・２つの環境を切り替えることによるデプロイメントを実現する「ブルーグリーンデプロイ」

13. ハードウェア・ネットワーク
OS・ミドルウェア・RUNTIME(JVM等)
アプリケーション
Saas
Paas
Iaas
多様な機能を具備
REST,Docker,CDN,
Hadoop,CI/CD
PaaS has many functions
クラウドは古くから、SAAS/PAAS/IAASのサービスレイヤーで語られてきており、DOCKERやHADOOPやCDN（CONTENTS DELIVERY NETWORK）等様々
な技術要素へ対応してきています。そんな中マイクロサービス対応についても、REST APIやCI等の観点でラインナップに加えられるようになってきています。

14. I. コードベース
II. 依存関係
III. 設定
IV. バックエンドサービス
V. ビルド、リリース、実行
VI. プロセス
VII. ポートバインディング
VIII. 並行性
IX. 廃棄容易性
X. 開発/本番一致
XI. ログ
XII. 管理プロセス
THE TWELVE-FACTOR APP
12の要素を踏まえクラウドネイティブな開発スタイルを体系的に整理したもので、
クラウドイミグラントにとっては欠かせないノウハウ
例えば以下の通り
• 「V. ビルド、リリース、実行」などCI/CDに関わる事項
• 「VII. ポートバインディング」のようにマイクロサービスの公開に関わる事項

15. 環境構築 環境変更
運用・監視
障害対応
開発 ビルド デプロイメント
旧来のコーディング・自動化範囲
マイクロサービス時代のコーディング・自動化範囲
INFRASTRUCTURE
AS CODE
INFRASTRUCTURE
AS CODE
CI/CD
DEV OPS
SPRING BOOT
デザインパターン
クラウド
フェーズ別の技術要素マップ
近年ビルドや環境構築フェーズにおいてコーディングし自動化可能となってきている

16. No 領域名 対象フェーズ 利用技術例
1 ソースコード
自動生成
開発(設計・実装
)
Eclipse, TERASOLUNA ViSC
2 テスト自動化 開発(テスト) JUnit, JsTestDriver,
Selenium,Selenide
3 ビルド・デプロイ
自動化
(DevOps, CI/CD)
ビルド・デプロ
イメント
Jenkins, Gradle, Maven
4 基盤自動化
(Infrastructure as
Code)
環境構築・環境
変更
構築:SDN, Chef, Puppet
テスト:ServerSpec
概念:Immutable Infrastructure
仮想化:Docker
4つの自動化領域とInfrastructure as Code
CI/CDの領域がより活発になってきており、さらに、INFRASTRUCTURE AS CODEと呼ばれる「基盤をコーディング」する、いわば第四の自動化領域が出
てきています。

17. ハードウェア・ネット
ワーク
OS・ミドルウェア・
RUNTIME(JVM等)
アプリケーション
Saas
Paas
Iaas
仮想化：
不変部分の再利用
Infrastructure as Code：
可変部分の自動化
CI/CD：
繰り返し
ビルド・デプロイ
仮想化、CI/CDとの住み分け
仮想化を用いて、個別システム・業務に依存しない不変部分を雛形化し、仮想イメージをコピーするのみである程度の構
築作業を完了させる。その後、INFRASTRUCTURE AS CODEにおけるCHEFやPUPPETといった基盤構築技術を用いて
可変部分を自動化

18. SpringプロダクトにおけるSpring Bootの位置付け

19. No 特徴名(英語) 特徴名(筆者による日本語訳)
1
Componentization via Services サービスを通じたコンポーネント化
2
Organized around Business Capabilities ビジネス遂行能力に基づいた
組織整理
3
Products not Projects プロジェクトではなくプロダクト
4
Smart endpoints and dumb pipes スマートエンドポイントと
シンプルな土管
5
Decentralized Governance 分散統治
6
Decentralized Data Management 分散データ管理
7
Infrastructure Automation インフラの自動化
8
Design for failure 障害発生を前提とした設計
9
Evolutionary Design 進化的な設計
マイクロサービスの「9つの特徴」
• マイクロサービスを深く正しく理解するには以下のJAMES LEWIS氏・MARTIN FOWLER氏が名付けた「９つの特徴」
をおさえる必要
• それぞれの「位置付け」や必ずしもメリットとは言えない部分もある

20. MICROSERVICE AP MICROSERVICE APMICROSERVICE AP
業務A 業務B 業務C
4. Smart endpoints and
dumb pipes
1. Componentization via Services
9. Evolutionary Design
チームA チームB チームC
2. Organized around Business Capabilities
5. Decentralized Governance
A
B C
6. Decentralized
Data Management
システム構成要素および開発チームにおける「９つの特徴」

21. 設計
コー
ディン
グ
コンパ
イル
テスト
デプロ
イ
運用・
監視
7. Infrastructure
Automation
8. Design for failure
3. Products not Projects
※設計〜運用・監視まで一気通貫で実施
開発サイクル（設計〜運用・監視）における「９つの特徴」

22. 1: Componentization via Services:
サービスを通じたコンポーネント化
マイクロサービスではアプリケーションをサービスに分けて構築し、サービスの単位でコンポーネント化を実現します。では
、ここでいうコンポーネントとはどういったものを指すのでしょうか。デプロイの観点でサービスの対極に位置づけられるラ
イブラリとの比較により説明します。
・「コンポーネント」：独立して交換やアップグレード可能なソフトウェアの単位
・「ライブラリ」：プログラム内にてリンクされ、インメモリの関数呼び出しされるコンポーネント
・「サービス」：プロセス境界を超えてウェブサービスやリモートプロシージャコールにて呼び出しされるコンポーネント
ライブラリとサービスの決定的な違いはプロセス境界をまたぐかどうかという点です。これにより、デプロイの単位をサービ
スの単位で独立させることができます。単一プロセス内に複数ライブラリを用いてモノシリックなアプリケーションを構築し
た場合、特定のライブラリの修正がアプリケーション全体の再デプロイにつながります。もちろん、一つのサービスの再デプ
ロイが他のサービスの再デプロイにつながることはあります。良いマイクロサービスを作る際のポイントとしては、サービス
境界を利用し、こういった影響範囲を局所化することにあります。

23. 2: Organized around Business Capabilities:
ビジネス遂行能力に基づいた組織整理
巨大なアプリケーションを開発する際、UI・業務ロジック・基盤・DBAといったチームに分割するケースがあります。これ
はこれで良い面もありますが、単純な仕様変更や機能追加であっても、チーム横断のプロジェクトとなり、時間がかかった
り、予算承認が困難になります。コンウェイの法則が示すように、組織構造とソフトウェアの構造には密接な関係がありま
す。
マイクロサービスでは、ビジネス遂行能力に基づいて整理されたサービスの単位にチームを分割します。具体的には、UI・
業務ロジック・基盤・DBAなどの必要なスキルを全て含む、クロスファンクショナル型と呼ばれます。勘の良い方は気づか
れたかもしれませんが、これはアジャイルの一つであるSCRUMの文脈でも語られる内容になります。
こういったクロスファンクショナル型は、MONOLITHアプリケーションでも実現可能ですが、マイクロサービスは組織間を
サービスで疎結合にすることができるため、より実現しやすいと言えます。

24. 3: Products not Projects:
プロジェクトではなくプロダクト
開発チームがシステム開発プロジェクトを担い、リリースしたら運用に引き渡す。そう言ったスタイルをとっているケー
スは多いのではないでしょうか。これは、いわゆるDEVOPSの文脈で語られる内容となります。
マイクロサービスでは、プロジェクトが終わったら、開発チームは解散という考えではなく、プロダクトのライフサイク
ル全体に渡って、サポートしていくべきだという考えがあります。AMAZONにおいて「YOU BUILD, YOU RUN IT」とい
う言葉があり、類似の思想です。
運用やサポートに部分的にでも関わることで、開発者がソフトウェア製品の振る舞いに日々接し、ユーザとの接点を増や
すことができます。これにより、単にソフトウェアの完成のみに注力するのではなく、ユーザのビジネスに貢献すること
にも注力しやすくなります。

25. 4: Smart endpoints and dumb pipes:
スマートエンドポイントとシンプルな土管
プロセス間通信を行う際、通信機構にスマートさを与えるプロダクトやアプローチが多く存在します。ESBがその好例で
、洗練されたメッセージルーティングやビジネスルール等の機構を持ちます。
一方、マイクロサービスは「スマートエンドポイントとシンプルな土管」のアプローチを提供します。通信機構にスマー
トさを与えるのではなく、サービス（エンドポイント）にスマートさを与え、通信機構をシンプル（土管）にします。
具体的にはREST APIのようなシンプルなプロトコルを用い、通常WS-CHOREOGRAPHYやBPELやESBを使ったプロト
コルは利用しません。

26. 5: Decentralized Governance:
分散統治
組織で開発プロセスやフレームワークを「標準化」することで、人材の流動性を増すことができるといったメリットが得
られる等の理由で中央集権型が当たり前のように語られてきました。全ての問題が釘ではなく、全ての解決方法がハンマ
ーではないと語られています。
非機能の観点から考えてみると、超高性能を求められる業務では、NODE.JSやMEMCACHEDといった選択肢がある一方
で、そうでない業務には通常通りJAVAでRDBMSを使うといったやり方が考えられます。
MONOLITHなアプリケーションにおいても、こう言った使い分けは行われてきましたが、マイクロサービスは、サービ
ス間の独立性の面から、分割統治がやりやすいと言えます。

27. 6: Decentralized Data Management:
分散データ管理
本番
本番
本番
A
C
B
A
B
C
本番
本番
A
B
C
A
B
C
A B C
Monolith
シングルDB
マイクロサービス
業務DB

28. 7: Infrastructure Automation:
インフラの自動化
インフラの自動化技術はここ数年で目覚ましく進化しています。
CI(CONTINUOUS INTEGRATION:継続的インテグレーション)/CD(CONTINUOUS DELIVERY:継続的デリバリ)がその中
核にあり、インフラの自動化の中では、以下の２点の自動化に着目しています。
・テスト自動化
・デプロイ自動化
テスト自動化に関しては、単体テスト・機能テスト・パフォーマンステストといった一連のテストを自動化するものです
。デプロイ自動化については、開発環境・ステージング環境・本番環境へのデプロイを自動化します。

29. 8: Design for failure:
障害発生を前提とした設計
NETFLIXでは、主に平日日中帯のオンライン時間帯に、サービスやデータセンタ単位で「敢えて」障害を発生させます。こ
れにより、開発・運用チームは耐障害性と監視の有効性について、絶えず検討・改善することができます。
サービスはいつでも停止し得るため、即時検知および可能であれば自動回復の仕組みが重要となります。
多くの開発プロジェクトにおいては、個々のサービスごとに、以下を一覧表示するいわゆるダッシュボードが活用されます
。
・サービスの死活状態
・システム面のメトリクス：データベースが受け付けるトランザクション数等
・ビジネス面のメトリクス：顧客からの注文数等

30. 9: Evolutionary Design:
進化的な設計
システム開発の全てが新規開発で、一度作ればおわりというわけではありません。機能追加・削除やハード更改等が行わ
れていき、いわば進化していきます。ここで重要なのは、変更容易性です。
GURDIANのWEBサイトの例を用いて説明します。GURDIANのWEBサイトは、当初モノリスのシステムとして構築され
、新しい機能はモノリスAPIを用いてマイクローサビスとして構築されます。
こう言ったアプローチはスポーツイベントの特設サイトのような一過性のイベントサイトを構築する際に有効です。
WEBサイトを構築する際は高生産性が期待できる言語を用いて開発し、イベント終了後削除するのも容易です。また、
金融機関においても同様のアプローチが見られます。マーケティング用のサイトを構築し、数ヶ月あるいは数週間にて削
除されます。

31. 生産性
複雑さ
複雑でないシステムに置いて
は、サービスの分割によるオ
ーバーヘッドが大きい
複雑さが増すと、
急激に生産性が落ちる
サービスの分割により
複雑さによる生産性の
低下を防ぐ
Monolith
Microservice
複雑さによる生産性低下におけるMonolithとの違い
MARTIN FOWLER氏がMICROSERVICEPREMIUMにて、「複雑さ」に応じてMONOLITHとマイクロサービスを選択すべ
きだと述べています。
「複雑さ」を表す要素はチームの大きさやマルチテナント等が挙げられていますが、特にCD(CONTINUOUS DELIVERY)
を実現できないほど複雑なMONOLITHなアプリケーションに対しては、生産性を大きく下げる要因となるためマイクロサ
ービスを選択すべきです。また、チームのスキルも選択における大きな要素です。