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

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

1. 1. MicroServiceなんて最初から やるもんじゃなかった Akira Miki Repro Inc. shinjuku.rb #27@metaps July 22, 2015
2. 2. Akira Miki CTO / Repro @treetreeslight
3. 3. 定量分析では分からない原因を
4. 4. 動画から推察して改善するツール
5. 5. プッシュもできるようになったよ！
6. 6. At the first of Repro
7. 7. Reproがやりたいこと 情報を送って 変換して 分析する受け取って
8. 8. 責務を分けてスケーラビリティ を担保したい
9. 9. マーティンファウラー御大曰く > 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
10. 10. 時代はマイクロサービシス キタコレ
11. 11. Reproがやりたいこと とりま分けて作っちゃおう!!! 情報を送って 変換して 分析する受け取って
12. 12. 好きな言語でガンガンいこう！ 情報を送って 変換して 分析する受け取って
13. 13. あれ、、、、
14. 14. スキーマ変更やら型変更すると。。。 情報を送って 変換して 分析する受け取って フォーマット チェック
 直して DBが 食えるように パースして ユーザーへの
 見せ方かえて 送るフォーマット
 合わせて
15. 15. れ出す修正漏れ 膨れ上がる管理コスト
16. 16. monolithic
17. 17. 結局 情報を送って 変換して 分析する受け取って • モノリシックにするソリューション • ビジネスロジックのズレをなくす
18. 18. 教訓その１ • 変化に強いアーキテクチャは、激しく変化 に強いのとは意味が違う • 変更が頻発する時期はモノリシックじゃな いとつらい • ビジネスロジックが同じなら使い回すべき
19. 19. 余談・変更の激しさ ここ１年で11万行書いて8万行消しました…
20. 20. After alpha release of Repro
21. 21. リクエストどうにかしたい 情報を送って 変換して 分析する受け取って フォーマット チェック
22. 22. 再びサービス分割へ 情報を送って 変換して 分析する受け取って フォーマット チェック
23. 23. 失敗したのにまたやるの？
24. 24. ビジネスロジックの依存を捨てる 情報を送って 変換して 分析する受け取って フォーマット チェック • 簡易なチェック（JSONフォーマットとキーとなる値）だ けにする • キー値の妥当性チェックはAPIで他のサーバーに聞きに行く
25. 25. 後工程で賄える事は後工程へ 情報を送って 変換して 分析する受け取って フォーマット チェック • 簡易なチェック（JSONフォーマットとキーとなる値）だ けにする • キー値の妥当性チェックはAPIで他のサーバーに聞きに行く
26. 26. 教訓その２ • 単一の責務に集中させる • 後工程のコスト下げたいとか欲を出さない • もし、責務から外れる行為をやりたいとき はAPI作って叩きに行く
27. 27. And now
28. 28. リクエストに合わせた工夫をする • あまりに多いリクエストをさばくにはRails がつらい。 • キャッシュにヒットしない分析データはリ クエストに時間がかかる=unicorn向かない
29. 29. まとめ
30. 30. • 最初はモノリシックに、そこからサービス を分ける方が責務が明確になる。 • リクエスト数や状況に応じて、単一の責務 に特化したサービスに分割する。欲を出さ ない