下記イベントで使用した、発表用資料です。 【ヒカ☆ラボ】明日からはじめるマイクロサービス～サーバレスインフラ、実機テストからクローラー、レピュテーションリスクチェックまで～WEBサービス3社が実務に導入してみた

1. マイクロサービス化の障壁

2. • 佐藤 和輝
• ナイル株式会社
• Scalaを去年５月くらいから
• Applivのマイクロサービス化
やってます
• 社内向けのAPI作り
発表者紹介 2

3. Applivって、何？

4. 4
独自のランキングロジックと検索システムを持つ
ユーザー参加型のアプリ発見サービス

5. フ ィ リ ピ ン 拠 点
英語圏にもApplivを提供
グローバルなアプリ発見プラットフォームを目指す

6. 今日話すこと

7. 細かい技術の話しません！

8. マイクロサービス化の障壁

9. • マイクロすぎるマイクロサービス
• 複数サービスを一つのリポジトリで管理する
• ドメインの境界とチームの境界のズレ
• ドメイン駆動設計の理解不足（諸説あり）
やってみて辛かったことまとめ

10. マイクロすぎるマイクロサービス

11. • 新規機能をとりあえず新しいマイクロサービスに
→ サービスの数が増える
→ 無駄な境界が発生、連携に苦労する
マイクロすぎるマイクロサービス
• 時期尚早な分割を避ける

12. 複数サービスを
一つのリポジトリで管理する

13. • 「それぞれ連携するし、
一つのリポジトリの方がいいよね」
→ リリースの影響範囲が不明瞭に
→ コード同士はとても密結合に
複数のサービスを一つのリポジトリで管理する
• サービスに合わせて適切な分離

14. ドメインの境界と
チームの境界のズレ

15. • すでに存在するチームと、ドメインの境界が違う
→ 相手チームを待たないといけない
→ 「本当に必要か」が十分に議論されない
→ データの所在がバラバラで効率の悪い呼び出し
ドメインの境界とチームの境界のズレ
• 境界を合わせる
• 必要ならチーム構成や組織構造を変える

16. ドメイン駆動設計の理解不足
（諸説あり）

17. • どういう単位でマイクロサービスとするべきか？
→ 手探りでは時間がかかる
→ 試してダメならやり直し、のコストが高い
ドメイン駆動設計の理解不足
• 本を読む
• 人に聞く、勉強会に参加する

18. 簡単なまとめ

19. けして気楽な気持ちで成し遂げられるものではない。
• 先人の知恵を取り入れる
• 組織の改革も進める
簡単なまとめ