microservicesのdesign patterns

23
マママママママママママママママママ ママ IBM ママママママ & マママママママママ ママママママ ママママ

Upload: naohiko-uramoto

Post on 15-Jan-2017

883 views

Category:

Internet


0 download

TRANSCRIPT

Page 1: Microservicesのdesign patterns

マイクロサービスのデザインパターン日本 IBM ソフトウエア &

システム開発研究所クラウド開発

浦本直彦

Page 2: Microservicesのdesign patterns

© 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

Page 3: Microservicesのdesign patterns

This is Bluemix

#bluemix - #ibmcloud

Page 4: Microservicesのdesign patterns

Microservices• Microservice アーキテクチャスタイルは、それぞれが独自の

プロセスで実行され,軽量のプロトコル ( たいてい HTTP リソース API) で通信する小さなサービスを組みあせることで単一のアプリケーションを開発するためのアプローチです。

これらのサービスは、ビジネス能力 (capability) に対応して構築され、完全に自動化された機構によって独立にデプロイが可能です。サービスの集中管理は最小限であり,異なるプログラミング言語で記述され、異なるデータストレージ技術を使用することができます.

出典 : http://martinfowler.com/articles/microservices.html

Page 5: Microservicesのdesign patterns

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

Page 6: Microservicesのdesign patterns

目次 人に優しい Web から機械に優しい Web へ

IoT の出番だ! マイクロサービスとは?

サービスの定義と結合による動的なアプリの構築 マイクロサービスを構成する標準技術たち

REST, API 管理 , 水平スケーラビリティ 今までの分散プログラミングとの違い

CORBA 、 RMI 、 DCOM, SOA ・・・とはどう違うのか ? まとめ

Page 7: Microservicesのdesign patterns

Web Services による動的なWeb アプリケーションの構築にむけて

2001 年 11 月 27 日

浦本 直彦日本 IBM 東京基礎研究所

国立情報学研究所[email protected]

Page 8: Microservicesのdesign patterns

目次 人に優しい Web から機械に優しい Web へ

XML の出番だ! Web サービスとは?

サービスの定義と結合による動的な Web アプリの構築 Web サービスを構成する XML 標準たち

SOAP 、 UDDI 、 WSDL 、・・・ 今までの分散プログラミングとの違い

CORBA 、 RMI 、 DCOM, ・・・とはどう違うのか ? まとめ

Page 9: Microservicesのdesign patterns

マイクロサービスのデザインパターン

• サービスの粒度

• サービスの結合

• サービスの独立性

• アンチパターン

9

Page 10: Microservicesのdesign patterns

Circuit Breaker概要分散されたサービスの呼び出しにおいて提供サービスが失敗しているに関わらずサービス呼び出しを続けると,計算リソースの枯竭を招き,システム全体の性能低下を招く.サービスと呼び出し側コードの間にCircuit Breaker を置いて,失敗するサービスの呼び出しをバイパスする.

考察無駄なサービス呼び出しを抑制するがシステム回復そのものを行うものではない実装 : Netflix OSS の Hystrix

10

Client Circuit Breaker Service

通常

サービス異常

遮断器作動

タイムアウト

タイムアウト

復帰

N 回失敗

タイムアウト

結合

Page 11: Microservicesのdesign patterns

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

11

Service

ServiceGateway

Service

Client

認証 (API キー )モニタリング登録などの機能を追加しても良い

結合

Page 12: Microservicesのdesign patterns

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

12

Service

Service ServiceRegistry

Service

登録検索リコメンデーション

結合

Page 13: Microservicesのdesign patterns

Polyglot Persistence概要一つのシステムの中で ) 複数のデータベース (SQL や NoSQL) を用途に応じて使い分けること. Polyglot Programmingのデータベース版

考察特定の data consistency メカニズムを意味するのではなく,複数のデータベース実装を使い分けるという意味で用いられているようだマイクロサービスにおいて,データベースの共有や同期はいつでも否か?

13

Service

Service

Service

結合

Page 14: Microservicesのdesign patterns

Tolerant Reader概要サービスを疎結合しても,サービス間の通信はなくならない.コードの更新に対して寛容性を持ったデータ読み込みを行う 考察REST/JSON だとデータスキーマを前提としない ( できない )

簡単なことは簡単だけど,そもそも難しいことが簡単に解けているわけではない :-P

14

DataReceiver

DataSender

データ

“ 送信に関しては厳密に、受信に関しては寛容に .” by Jon Postel

結合

Page 15: Microservicesのdesign patterns

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

15

Service Service Service

Service

結合

Command Command Command

UNIX Pipe

Service

Page 16: Microservicesのdesign patterns

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

メッセージフォーマットの同意が必要

16

Service Service Service

Message QueueService

結合

Page 17: Microservicesのdesign patterns

Service Instantiation概要それぞれのサービスを適切なプラットフォーム,孤立化の単位で生成する. - Multiple service instances per host - Single service instance per host - Service instance per VM - Service instance per Container

考察VM かコンテナか,単一か複数か軽量さ,モビリティイミュータブルかどうか

17

ServiceService

Service

結合

Page 18: Microservicesのdesign patterns

18

Page 19: Microservicesのdesign patterns

Bulkhead

概要システム障害を局所化するために,同じシステムを複数用意し,それぞれを隔壁を用いて孤立化しておく.孤立化の単位として,データセンター, VM ,コンテナなどが考えられる.

考察クラウドでは自然に実現

19

Service

Service

Service

Service

LoadBalancer

Database Database

LoadBalancer

独立性

Page 20: Microservicesのdesign patterns

Command Query Responsibility Segregation (CQRS)概要データを照会するサービスと更新を行うサービスを分離することで副作用を最小化する.データ更新の際には,照会よりも重いロジック ( 検証やセキュリティなど )が必要であり,両者を分けることで複雑さを抑制できる .

考察かえって複雑さが増す場合もありえる( ビジネス能力をサービスの粒度単位とするならば,細か過ぎるのではないか ?)

20

ReadService

WriteService

DatabaseGateway

サービス呼び出し側に対しては Gateway サービスが相対しても良い

粒度

Page 21: Microservicesのdesign patterns

Conway’s Law ( コンウェイの法則 )概要ソフトウェアのアーキテクチャは、それを開発した組織の構造を反映したものになる

ビジネス能力単位でサービスを独立に開発し,運用まで行うチーム=マイクロサービスの粒度

=2枚のピザチーム

(個人的には,これが SOA と Microservices の違いに思える )

21

粒度

出典 ://martinfowler.com/articles/microservices/images/conways-law.png

Page 22: Microservicesのdesign patterns

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

Page 23: Microservicesのdesign patterns

23

出典 : http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html

- バージョニング- 結合したものの機能,非機能要件- 全体的なスケーラビリティ- テスト