API Meetup Tokyo #25 AIの民主化を推進する日本のAPI提供者 ～ クラウドベンダーだけじゃない ～ https://api-meetup.doorkeeper.jp/events/72837 で発表した資料です

1. Microservices Architecture
の利点と欠点
ota42y
2018/04/20

2. • ota42y
• サーバサイドエンジニア
– 元ゲームのクライアントエンジニア
• rubyとかrustとかgoとかC++とか
• Twitter、github → ota42y
• 技術書典4で本を出します
自己紹介

3. • 話すこと
– Microservice Architectureとは
– 何故このアーキテクチャを使っているか
• 良い点と悪い点
• (多分)本編で必要になる前提知識です
• 話さないこと
– FiNCのこと
– 採用
• 懇親会で聞いてください
今日話すこと・話さないこと

4. Microservices Architecture

5. • 複数のチームとサービスから構成される
• 各自が組み合わさり、1つの価値を提供
Microservices Architecture
FiNCダイエット家庭教師
FiNCモール
FiNC アプリ
lifelog FiNC for BUSINESSchat
ranking main

6. Microservices Architecture

7. Microservices Architecture
try
app
ai

8. Microservices Architecture

9. 何故 Microsecvices か？

10. Microsecvices の利点
• 複数のサイクルで回せる
– モノリシックだとリリースは1つのサイクル
– 課金系とフロントは違うサイクルで回したい
– ビジネス事に適切な速度でPDCAを回せる
• 影響が局所化される
– 障害が起きても他の場所に影響を与えない
– 変更による影響が限定的になる
• その他色々…
– ( 詳しくはオライリーのマイクロサービスアーキテクチャを読んでください )

11. サービスが独立して動けるので
巨大なサービスほど恩恵が大きい

12. とはいえ銀の弾丸ではない

13. Microsecvices の欠点
• オーバーヘッドが大きい
– 通信回数が増える
– チーム間コミュニケーション、スケジュール調整
• 分散システムの問題を抱える
– サービスを超えてトランザクションができない
– データが分断される
• 違うDBになるのでJoinができない
• データを横断して使いたい場合に厄介
• レコメンドとか複数サービスにデータがわかれて…😱

14. 😢

15. 対応策
• オーバーヘッド
– API設計・サービス分割を工夫する
• ネストしたアクセスを避ける
– 共通化や、仕様の定義をしっかりと詰める
• 特に共通化はマイクロサービスでは大きく効く
• トランザクションがかけられない
– 分割を慎重に行い、1サービスで完結させる
• データが分断される
– 後の発表でレコメンドでどう対応したか話します

16. • マイクロサービスは大きい組織ほど利点が多い
• 全て良しではなく、いくつかのトレードオフがある
– ある程度の対応は可能
• コストがかかるが、それ以上の利益は出せる
– チームが増えるほど利点が大きくなる
– 規模が小さいと欠点の方が大きくなる可能性も
まとめ

17. おまけ
Microservices Architectureの
こんな話を書いた本が
日曜の技術書典4で出ます
( ﾟ∀ﾟ)o彡ﾟ