Microserviceなんて最初からやるもんじゃ無かった

1. MicroServiceなんて最初から
やるもんじゃなかった
Akira Miki
Repro Inc.
shinjuku.rb #27@metaps
July 22, 2015

2. Akira Miki
CTO / Repro
@treetreeslight

4. 定量分析では分からない原因を

5. 動画から推察して改善するツール

6. プッシュもできるようになったよ！

7. At the first of Repro

8. Reproがやりたいこと
情報を送って 変換して 分析する受け取って

9. 責務を分けてスケーラビリティ
を担保したい

10. マーティンファウラー御大曰く
> The term "Microservice Architecture" has
sprung up over the last few years to
describe a particular way of designing
software applications as suites of
independently deployable services.
http://martinfowler.com/articles/microservices.html

11. 時代はマイクロサービシス
キタコレ

12. Reproがやりたいこと
とりま分けて作っちゃおう!!!
情報を送って 変換して 分析する受け取って

13. 好きな言語でガンガンいこう！
情報を送って 変換して 分析する受け取って

14. あれ、、、、

15. スキーマ変更やら型変更すると。。。
情報を送って 変換して 分析する受け取って
フォーマット
チェック
直して
DBが
食えるように
パースして
ユーザーへの
見せ方かえて
送るフォーマット
合わせて

16. れ出す修正漏れ
膨れ上がる管理コスト

17. monolithic

18. 結局
情報を送って 変換して 分析する受け取って
• モノリシックにするソリューション
• ビジネスロジックのズレをなくす

19. 教訓その１
• 変化に強いアーキテクチャは、激しく変化
に強いのとは意味が違う
• 変更が頻発する時期はモノリシックじゃな
いとつらい
• ビジネスロジックが同じなら使い回すべき

20. 余談・変更の激しさ
ここ１年で11万行書いて8万行消しました…

21. After alpha release of Repro

22. リクエストどうにかしたい
情報を送って 変換して 分析する受け取って
フォーマット
チェック

23. 再びサービス分割へ
情報を送って 変換して 分析する受け取って
フォーマット
チェック

24. 失敗したのにまたやるの？

25. ビジネスロジックの依存を捨てる
情報を送って 変換して 分析する受け取って
フォーマット
チェック
• 簡易なチェック（JSONフォーマットとキーとなる値）だ
けにする
• キー値の妥当性チェックはAPIで他のサーバーに聞きに行く

26. 後工程で賄える事は後工程へ
情報を送って 変換して 分析する受け取って
フォーマット
チェック
• 簡易なチェック（JSONフォーマットとキーとなる値）だ
けにする
• キー値の妥当性チェックはAPIで他のサーバーに聞きに行く

27. 教訓その２
• 単一の責務に集中させる
• 後工程のコスト下げたいとか欲を出さない
• もし、責務から外れる行為をやりたいとき
はAPI作って叩きに行く

28. And now

29. リクエストに合わせた工夫をする
• あまりに多いリクエストをさばくにはRails
がつらい。
• キャッシュにヒットしない分析データはリ
クエストに時間がかかる=unicorn向かない

30. まとめ

31. • 最初はモノリシックに、そこからサービス
を分ける方が責務が明確になる。
• リクエスト数や状況に応じて、単一の責務
に特化したサービスに分割する。欲を出さ
ない