10/27のクラウド研究会で講演した"マイクロサービスのデザインパターン"の資料です．

1. マイクロサービスのデザインパターン
日本 IBM ソフトウエア &
システム開発研究所
クラウド開発
浦本直彦

2. © 2015 IBM Corporation
自己紹介
 浦本直彦 (@urarara, www.facebook.com/naohiko.uramoto, LinkedIn も )
 IBM 東京基礎研究所から，今年開発ラボに移り， Bluemix の開発チームを立ち上げ
 自然言語処理 , XML, Web サービス , SOA, Semantic Web, Web 2.0, Cloud <- 今ココ
 ブログ一応やっています http://blogs.itmedia.co.jp/look4innovation/
 丸山不二夫先生 クラウド研究会 (2008 年 8 月 -) 事務局長
 W3C Resource Description Framework (RDF) 作業部会メンバー ( 当時 )
 2015 年より人工知能学会副会長
2

3. This is Bluemix
#bluemix - #ibmcloud

4. Microservices
• Microservice アーキテクチャスタイルは、それぞれが独自のプロ
セスで実行され，軽量のプロトコル ( たいてい HTTP リソー
ス API) で通信する小さなサービスを組みあせることで単一の
アプリケーションを開発するためのアプローチです。
これらのサービスは、ビジネス能力 (capability) に対応して構築
され、完全に自動化された機構によって独立にデプロイが可
能です。サービスの集中管理は最小限であり，異なるプログ
ラミング言語で記述され、異なるデータストレージ技術を使
用することができます．
出典 : http://martinfowler.com/articles/microservices.html

5. Micro Services の特徴
• サービス単位のコンポーネント化 (Componentization via Services)
• ビジネス能力による構成 (Organized around Business Capabilities)
• プロジェクトではなくプロダクト (Products not Projects)
• 賢いエンドポイント、愚直なパイプ (Smart endpoints and dumb pipes)
• 分散されたガバナンス (Decentralized Governance)
• 分散データ管理 (Decentralized Data Management)
• インフラの自動化 (Infrastructure Automation)
• 障害を前提とした設計 (Design for failure)
• 進化的設計 (Evolutionary Design)
出典 : http://martinfowler.com/articles/microservices.html) 5

6. 目次
 人に優しい Web から機械に優しい Web へ
 IoT の出番だ！
 マイクロサービスとは？
 サービスの定義と結合による動的なアプリの構築
 マイクロサービスを構成する標準技術たち
 REST, API 管理 , 水平スケーラビリティ
 今までの分散プログラミングとの違い
 CORBA 、 RMI 、 DCOM, SOA ・・・とはどう違うの
か ?

7. Web Services による動的な Web
アプリケーションの構築にむけて
2001 年 11 月 27 日
浦本 直彦
日本 IBM 東京基礎研究所
国立情報学研究所
uramoto@jp.ibm.com

8. 目次
 人に優しい Web から機械に優しい Web へ
 XML の出番だ！
 Web サービスとは？
 サービスの定義と結合による動的な Web アプリの構築
 Web サービスを構成する XML 標準たち
 SOAP 、 UDDI 、 WSDL 、・・・
 今までの分散プログラミングとの違い
 CORBA 、 RMI 、 DCOM, ・・・とはどう違うのか ?
 まとめ

9. マイクロサービスのデザインパターン
• サービスの粒度
• サービスの結合
• サービスの独立性
• アンチパターン
9

10. Circuit Breaker
概要
分散されたサービスの呼び出しにおいて提
供サービスが失敗しているに関わらずサー
ビス呼び出しを続けると，計算リソースの
枯竭を招き，システム全体の性能低下を招
く．サービスと呼び出し側コードの間に
Circuit Breaker を置いて，失敗するサービス
の呼び出しをバイパスする．
考察
無駄なサービス呼び出しを抑制するが
システム回復そのものを行うものではない
実装 : Netflix OSS の Hystrix
10
Client
Circuit
Breaker
Service
通常
サービス
異常
遮断器
作動
タイム
アウト
タイム
アウト
復帰
N 回失敗
タイム
アウト
結合

11. API Gateway
概要
サービス利用者にとって，サービスの
粒度が小さすぎる場合など，それぞれ
と接続するのは効率が悪いときがある
． API を直接呼び出すのではな
く， API Gateway を介して接続する
考察
Gateway を介することで，ここにモニタ
リングや認証の仕組みを持ち込める反
面，ここが単一故障点になりえる．ま
た，ここが重くなると，マイクロサー
ビスが忌み嫌う ESB に向かってしまう
． 11
Service
ServiceGateway
Service
Client
認証 (API キー )
モニタリング
登録
などの機能を
追加しても良い
結合

12. Service Registry / Service Discovery
概要
サービス同士を直接繋げるのではなく
サービスを Service Registry に登録
し， Service Registry を用いた発見，結合
を行う． Discovery は，サーバー側ある
いはクライアント側で行われる
(Server-side Discovery / Client-side Discovery)
考察
UDDI 再び ?
API に関する情報を一元管理できる
API は自己記述的か ?
12
Service
Service
Service
Registry
Service
登録
検索
リコメンデーション
結合

13. Polyglot Persistence
概要
一つのシステムの中で ) 複数のデータ
ベース (SQL や NoSQL) を用途に応じ
て使い分けること． Polyglot
Programming のデータベース版
考察
特定の data consistency メカニズムを意味
するのではなく，複数のデータベース
実装を使い分けるという意味で用いら
れているようだ
マイクロサービスにおいて，データベ
ースの共有や同期はいつでも否か？
13
Service
Service
Service
結合
？

14. Tolerant Reader
概要
サービスを疎結合しても，サービス間
の通信はなくならない．コードの更新
に対して寛容性を持ったデータ読み込
みを行う
考察
REST/JSON だとデータスキーマを
前提としない ( できない )
簡単なことは簡単だけど，そもそも
難しいことが簡単に解けているわけで
はない :-P 14
Data
Receiver
Data
Sender
データ
“ 送信に関しては厳密に、受信
に関しては寛容に .” by Jon
Postel
結合

15. Chained Services
概要
サービスが順列に接続し通信を行う．
“ Dumb pipe” であるが， UNIX Pipe と違
って分岐を許す．
考察
オーケストレーション ( 中央集権 ) と
コレオグラフィ ( 非集中 ) は明確に区
別される .
安易なチェイニングは複雑さを生み出
す？
15
Service Service Service
Service
結合
Command Command Command
UNIX Pipe
Service

16. Asynchronous Messaging
概要
複数のサービスがメッセージング
サービス (queue) を共有する．
考察
サービスの独立性，非同期性を保つた
めよく使われる．ロジックが必要な場
合は ? Queue が単一故障点になる場合
がある．
メッセージフォーマットの同意が必要
16
Service Service Service
Message Queue
Service
結合

17. Service Instantiation
概要
それぞれのサービスを適切なプラットフォーム
，孤立化の単位で生成する．
- Multiple service instances per host
- Single service instance per host
- Service instance per VM
- Service instance per Container
考察
VM かコンテナか，単一か複数か
軽量さ，モビリティ
イミュータブルかどうか
17
Service
Service
Service
結合

18. 18

19. Bulkhead
概要
システム障害を局所化するために，同じシ
ステムを複数用意し，それぞれを隔壁を用
いて孤立化しておく．孤立化の単位として
，データセンター， VM ，コンテナなどが
考えられる．
考察
クラウドでは自然に実現
19
Service
Service
Service
Service
Load
Balancer
Database Database
Load
Balancer
独立性

20. Command Query Responsibility Segregation (CQRS)
概要
データを照会するサービスと更新を行うサ
ービスを分離することで副作用を最小化す
る．データ更新の際には，照会よりも重い
ロジック ( 検証やセキュリティなど )
が必要であり，両者を分けることで
複雑さを抑制できる .
考察
かえって複雑さが増す場合もありえる
( ビジネス能力をサービスの粒度単位と
するならば，細か過ぎるのではないか ?)
20
Read
Service
Write
Service
DatabaseGateway
サービス呼び出し側に
対しては Gateway サービスが
相対しても良い
粒度

21. Conway’s Law ( コンウェイの法則 )
概要
ソフトウェアのアーキテクチャは、それを開
発した組織の構造を反映したものになる
ビジネス能力単位でサービスを独立に開発し
，運用まで行うチーム＝マイクロサービスの
粒度
=2 枚のピザチーム
( 個人的には，これが SOA と Microservices の違
いに思える )
21
粒度
出典 ://martinfowler.com/articles/microservices/images/conways-law.png

22. Microservices Anti-patterns
• 無秩序な凝集性 (Cohesion Chaos)
• 自動化が重要視されていない (Not taking Automation Seriously)
• 階層化されたサービスアーキテクチャ (Layered Services Architecture)
– かっこ良く階層化したら複雑さが増す
• 利用者のサインオフに依存 (Relying on Consumer Sign-off)
– 凝集化，独立性が低いサービス
• 自動化されていない構成管理 (Manual Configurations Management)
– …多数のサービスの構成をそれぞれ手動で管理するのは
• バージョニングの回避 (Versioning Avoidance)
– Graceful migration
• サービスごとにゲートウエイを作成 (Building a gateway in every service)
– API Gateway を使う
22
出典 : http://www.infoq.com/articles/seven-uservices-antipatterns

23. 23
出典 : http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html
- バージョニング
- 結合したものの機能，非機能要件
- 全体的なスケーラビリティ
- テスト