マイクロサービスアーキテクチャの話 / Micro service architecture

Slide 1

Slide 1 text

  マイクロサービスアーキテクチャの話    2015/1/15  @iwashi86  みんなで構築・運用の話をしよう　第1回

Slide 2

Slide 2 text

●Attribute  　・Name -> Yoshimasa IWASE   　・Twitter -> @iwashi86  　・Web -> iwashi.co    ●Work @ NTT Communications  　・SkyWay(WebRTC)の裏側の開発運用  　・HTML5 Experts.jpというWebメディアの編集  2

Slide 3

Slide 3 text

  今日のテーマ：  マイクロサービスアーキテクチャ   

Slide 4

Slide 4 text

バズった原典 http://martinfowler.com/articles/microservices.html

Slide 5

Slide 5 text

• アプリケーションを複数のサービスを組み合わせて構築する    • サービス間通信は、HTTP経由のAPIか軽量メッセージング(ex. RabbitMQ)を利用    • サービス自体は独立してデプロイ＆動作可能  In a nutshell

Slide 6

Slide 6 text

なんでもかんでも  マイクロサービスアーキテクチャ？ 

Slide 7

Slide 7 text

http://martinfowler.com/articles/microservices/images/sketch.png モノリシック Web / AP / DB を全て含むタイプ (ex. Rails)

Slide 8

Slide 8 text

http://martinfowler.com/articles/microservices/images/sketch.png モノリシック Web / AP / DB を全て含むタイプ (ex. Rails) マイクロサービスそれぞれの機能が独立しているタイプ

Slide 9

Slide 9 text

http://martinfowler.com/articles/microservices/images/sketch.png モノリシック Web / AP / DB を全て含むタイプ (ex. Rails) マイクロサービスそれぞれの機能が独立しているタイプどっちにも良いところ・悪いところがあるなので両方の特徴を知ってから自身の環境にあわせて選ぼう

Slide 10

Slide 10 text

• Good  – シンプルなので開発期間は比較的に短い、デプロイも簡単  – 比較的に全体像をつかみやすい（特に新入りさん歓迎）  • Bad  – Big ball of mud(※)になる  – アジリティの欠如  • ひとたび機能変更があると、全部デプロイしたり  • Caveat  – 決してスケールしないわけじゃない(LBとか使えば？)  モノリシックアーキテクチャ ※　大きな泥団子が直訳だけど、もはやごった煮状態のスパゲッティ状態のサービスを、本スライドでは意味。　http://www.laputan.org/mud/

Slide 11

Slide 11 text

http://microservices.io/patterns/monolithic.html

Slide 12

Slide 12 text

http://microservices.io/patterns/monolithic.html これが巨大泥団子

Slide 13

Slide 13 text

http://microservices.io/patterns/monolithic.html これが巨大泥団子素敵なスパゲッティ

Slide 14

Slide 14 text

• Good  – サービスごとに独立してデプロイ＆スケールできる  – 影響範囲が明確  – チームごとにパラレルに開発しやすい  – 特定の技術へのロックインを避けやすい  • Bad  – 複雑になる（可動部分・結合部分が多いので）  – サービスモニタリングがより大変  マイクロサービスアーキテクチャ ※　大きな泥団子が直訳だけど、もはやごった煮状態のスパゲッティ状態のサービスを、本スライドでは意味。　http://www.laputan.org/mud/

Slide 15

Slide 15 text

独立してデプロイ＆スケール分岐点が明確こっちはRails こっちはdjango http://microservices.io/patterns/microservices.html

Slide 16

Slide 16 text

マイクロサービスアーキテクチャ  について、もうちょっとkwsk 

Slide 17

Slide 17 text

9つの特徴 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    

Slide 18

Slide 18 text

1. Componentization via Services • マイクロサービスでは、主要な機能はライブラリではなく  別プロセスで動作するサービスとして切り出す  （コンポーネントとは別）    • 良い所  – IFが明確で疎結合にできる  – デプロイがコンポーネント単位で済む    • （前提：用語）  – コンポーネント：ライブラリ内の関数呼び出しで完結する要素  – サービス：HTTP APIやRPCで呼び出しする要素   

Slide 19

Slide 19 text

2. Organized around Business Capabilities • ビジネス能力にもとづいてチームを分割しよう  • だってコンウェイの法則に従って、  チーム構造とシステム構造は同じになるから    • 詳細は図にて 

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

じゃなくて http://martinfowler.com/articles/microservices/images/conways-law.png

Slide 22

Slide 22 text

http://martinfowler.com/articles/microservices/images/PreferFunctionalStaffOrganization.png

Slide 23

Slide 23 text

人数にもよるが、割とフルスタックな能力が求められる (ex. UX, Web, NW, DB, PM) http://martinfowler.com/articles/microservices/images/PreferFunctionalStaffOrganization.png

Slide 24

Slide 24 text

3. Products not Projects • 今まで  – アプリケーション開発は  「期限のあるプロジェクト」として管理しておいて  開発がおわってデプロイして終わり    • マイクロサービスだと  – 継続的なプロダクトとして開発運用していく  で、ビジネスとして価値を高める  – Amazonの build it / run it 精神  • 作ったもの24時間365日、運用まで含めて責任を持つ   ⇒　深夜にたたき起こされたくなくて品質を高めようと頑張る   　　（DevOpsな感じですね）   

Slide 25

Slide 25 text

4. Smart endpoints and dumb pipes • クラウド界隈でいえば 

Slide 26

Slide 26 text

OpenStackな感じ http://c204396.r96.cf1.rackcdn.com/nova-cactus-logical.gif

Slide 27

Slide 27 text

5. Decentralized Governance • 中央集権型  　⇒　単一のプラットフォームになりがち  　⇒　活動の抑制につながる    • 分割統治(マイクロサービスアーキテクチャだと）  – 標準化された技術がベストなわけじゃない  – 自身の問題解決に適した言語やDBを選択しよう  – たとえばあるサービスはC++でも良いし、  あるサービスはNode.jsで作っても良い    （上記実現は、アーキテクチャが疎結合だと特に容易）   

Slide 28

Slide 28 text

6. Decentralized Data Management • 一括管理できる統合データベースを作るのじゃなくて  それぞれのサービスでデータベースを持とう    • （ただし、一貫性を保つのは結構大変） 

Slide 29

Slide 29 text

7. Infrastructure Automation • 説明するより見たほうが早し： 

Slide 30

Slide 30 text

7. Infrastructure Automation 引用：http://www.athlsolutions.com/web/Portals/0/news/N_2014.10.07_01z1.jpg

Slide 31

Slide 31 text

7. Infrastructure Automation 引用：http://www.athlsolutions.com/web/Portals/0/news/N_2014.10.07_01z1.jpg 要は自動化してCI/CDしよう

Slide 32

Slide 32 text

8. Design for Failure • 外部のサービスはいつの間にか死んでいるかもしれない  • またいつの間にか復旧しているかもしれない    　なので・・・   

Slide 33

Slide 33 text

8. Design for Failure • 外部のサービスはいつの間にか死んでいるかもしれない  • またいつの間にか復旧しているかもしれない    　なので・・・    • マイクロサービスアーキテクチャでは、  サービス障害の影響を常に考慮しておく  • また自身の提供するサービス障害はいち早く検知する 

Slide 34

Slide 34 text

9. Evolutionary Design • サービス単位に進化できるような設計にする  • 進化させる場合は  – アップグレード  – 廃棄（コンテナちっく）　←　こっちがオススメ  • Blue Green な Deploy とか 

Slide 35

Slide 35 text

まとめ（再掲） 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    