Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マイクロサービスアーキテクチャの話 / Micro service architecture
Search
iwashi
November 27, 2022
Technology
0
220
マイクロサービスアーキテクチャの話 / Micro service architecture
マイクロサービスアーキテクチャについてお話したときのスライド
iwashi
November 27, 2022
Tweet
Share
More Decks by iwashi
See All by iwashi
エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門 / Engineering management for the rest of us
iwashi86
22
5.2k
エレガントパズル 30分 ダイジェスト版/ Elegant Puzzle 30min Digest
iwashi86
5
560
エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle
iwashi86
18
4k
ベロシティを高く保つ仕事のすすめ方 / Maintaining a High Velocity as Productivity Hacks
iwashi86
54
20k
マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
iwashi86
65
32k
30分でわかる「エンジニアのためのドキュメントライティング」- インフラエンジニアBooks / Docs for Developers within 30 minutes
iwashi86
9
2.5k
エンジニアのためのドキュメントライティング / Docs for Developers
iwashi86
34
22k
なぜ変化を起こすのが難しいのか? - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
iwashi86
60
88k
2015年 第4四半期の WebRTC 標準化 アップデート / 2015 update of WebRTC Standards
iwashi86
0
220
Other Decks in Technology
See All in Technology
エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers
rince
4
340
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.4k
SA Night #2 FinatextのSA思想/SA Night #2 Finatext session
satoshiimai
1
140
Classmethod AI Talks(CATs) #16 司会進行スライド(2025.02.12) / classmethod-ai-talks-aka-cats_moderator-slides_vol16_2025-02-12
shinyaa31
0
110
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
130
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
250
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
6
57k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
2.9k
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
740
表現を育てる
kiyou77
1
210
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
16
5.9k
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
Producing Creativity
orderedlist
PRO
344
39k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
GitHub's CSS Performance
jonrohan
1030
460k
Optimizing for Happiness
mojombo
376
70k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Scaling GitHub
holman
459
140k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
Agile that works and the tools we love
rasmusluckow
328
21k
Transcript
マイクロサービスアーキテクチャの話 2015/1/15 @iwashi86 みんなで構築・運用の話をしよう 第1回
•Attribute ・Name -> Yoshimasa IWASE ・Twitter -> @iwashi86 ・Web
-> iwashi.co •Work @ NTT Communications ・SkyWay(WebRTC)の裏側の開発運用 ・HTML5 Experts.jpというWebメディアの編集 2
今日のテーマ: マイクロサービスアーキテクチャ
バズった原典 http://martinfowler.com/articles/microservices.html
• アプリケーションを複数のサービスを組み合わせて 構築する • サービス間通信は、HTTP経由のAPIか軽量メッセー ジング(ex. RabbitMQ)を利用 •
サービス自体は独立してデプロイ&動作可能 In a nutshell
なんでもかんでも マイクロサービスアーキテクチャ?
http://martinfowler.com/articles/microservices/images/sketch.png モノリシック Web / AP / DB を全て含むタイプ (ex. Rails)
http://martinfowler.com/articles/microservices/images/sketch.png モノリシック Web / AP / DB を全て含むタイプ (ex. Rails)
マイクロサービス それぞれの機能が 独立しているタイプ
http://martinfowler.com/articles/microservices/images/sketch.png モノリシック Web / AP / DB を全て含むタイプ (ex. Rails)
マイクロサービス それぞれの機能が 独立しているタイプ どっちにも良いところ・悪いところがある なので両方の特徴を知ってから 自身の環境にあわせて選ぼう
• Good – シンプルなので開発期間は比較的に短い、デプロイも簡単 – 比較的に全体像をつかみやすい(特に新入りさん歓迎) • Bad – Big
ball of mud(※)になる – アジリティの欠如 • ひとたび機能変更があると、全部デプロイしたり • Caveat – 決してスケールしないわけじゃない(LBとか使えば?) モノリシックアーキテクチャ ※ 大きな泥団子が直訳だけど、もはやごった煮状態のスパゲッティ状態のサービスを、本スライドでは意味。 http://www.laputan.org/mud/
http://microservices.io/patterns/monolithic.html
http://microservices.io/patterns/monolithic.html これが巨大泥団子
http://microservices.io/patterns/monolithic.html これが巨大泥団子 素敵なスパゲッティ
• Good – サービスごとに独立してデプロイ&スケールできる – 影響範囲が明確 – チームごとにパラレルに開発しやすい – 特定の技術へのロックインを避けやすい
• Bad – 複雑になる(可動部分・結合部分が多いので) – サービスモニタリングがより大変 マイクロサービスアーキテクチャ ※ 大きな泥団子が直訳だけど、もはやごった煮状態のスパゲッティ状態のサービスを、本スライドでは意味。 http://www.laputan.org/mud/
独立してデプロイ& スケール 分岐点が明確 こっちはRails こっちはdjango http://microservices.io/patterns/microservices.html
マイクロサービスアーキテクチャ について、もうちょっとkwsk
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
1. Componentization via Services • マイクロサービスでは、主要な機能はライブラリではなく 別プロセスで動作するサービスとして切り出す (コンポーネントとは別) •
良い所 – IFが明確で疎結合にできる – デプロイがコンポーネント単位で済む • (前提:用語) – コンポーネント:ライブラリ内の関数呼び出しで完結する要素 – サービス:HTTP APIやRPCで呼び出しする要素
2. Organized around Business Capabilities • ビジネス能力にもとづいてチームを分割しよう • だってコンウェイの法則に従って、 チーム構造とシステム構造は同じになるから
• 詳細は図にて
http://martinfowler.com/articles/microservices/images/conways-law.png
じゃなくて http://martinfowler.com/articles/microservices/images/conways-law.png
http://martinfowler.com/articles/microservices/images/PreferFunctionalStaffOrganization.png
人数にもよるが、割とフルス タックな能力が求められる (ex. UX, Web, NW, DB, PM) http://martinfowler.com/articles/microservices/images/PreferFunctionalStaffOrganization.png
3. Products not Projects • 今まで – アプリケーション開発は 「期限のあるプロジェクト」として管理しておいて 開発がおわってデプロイして終わり
• マイクロサービスだと – 継続的なプロダクトとして開発運用していく で、ビジネスとして価値を高める – Amazonの build it / run it 精神 • 作ったもの24時間365日、運用まで含めて責任を持つ ⇒ 深夜にたたき起こされたくなくて品質を高めようと頑張る (DevOpsな感じですね)
4. Smart endpoints and dumb pipes • クラウド界隈でいえば
OpenStackな感じ http://c204396.r96.cf1.rackcdn.com/nova-cactus-logical.gif
5. Decentralized Governance • 中央集権型 ⇒ 単一のプラットフォームになりがち ⇒ 活動の抑制につながる • 分割統治(マイクロサービスアーキテクチャだと)
– 標準化された技術がベストなわけじゃない – 自身の問題解決に適した言語やDBを選択しよう – たとえばあるサービスはC++でも良いし、 あるサービスはNode.jsで作っても良い (上記実現は、アーキテクチャが疎結合だと特に容易)
6. Decentralized Data Management • 一括管理できる統合データベースを作るのじゃなくて それぞれのサービスでデータベースを持とう • (ただし、一貫性を保つのは結構大変)
7. Infrastructure Automation • 説明するより見たほうが早し:
7. Infrastructure Automation 引用:http://www.athlsolutions.com/web/Portals/0/news/N_2014.10.07_01z1.jpg
7. Infrastructure Automation 引用:http://www.athlsolutions.com/web/Portals/0/news/N_2014.10.07_01z1.jpg 要は自動化してCI/CDしよう
8. Design for Failure • 外部のサービスはいつの間にか死んでいるかもしれない • またいつの間にか復旧しているかもしれない なので・・・
8. Design for Failure • 外部のサービスはいつの間にか死んでいるかもしれない • またいつの間にか復旧しているかもしれない なので・・・
• マイクロサービスアーキテクチャでは、 サービス障害の影響を常に考慮しておく • また自身の提供するサービス障害はいち早く検知する
9. Evolutionary Design • サービス単位に進化できるような設計にする • 進化させる場合は – アップグレード –
廃棄(コンテナちっく) ← こっちがオススメ • Blue Green な Deploy とか
まとめ(再掲) 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