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

Akira Miki Repro Inc.

shinjuku.rb #27@metaps July 22, 2015

Akira Miki CTO / Repro

@treetreeslight

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

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

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

At the first of Repro

Reproがやりたいこと

情報を送って 変換して 分析する受け取って

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

マーティンファウラー御大曰く

> 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

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

Reproがやりたいこと

とりま分けて作っちゃおう!!!

情報を送って 変換して 分析する受け取って

好きな言語でガンガンいこう！

情報を送って 変換して 分析する受け取って

あれ、、、、

スキーマ変更やら型変更すると。。。

情報を送って 変換して 分析する受け取ってフォーマット チェック直して

DBが 食えるように パースして

ユーザーへの見せ方かえて

送るフォーマット合わせて

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

monolithic

結局

情報を送って 変換して 分析する受け取って

•モノリシックにするソリューション •ビジネスロジックのズレをなくす

教訓その１

• 変化に強いアーキテクチャは、激しく変化に強いのとは意味が違う

• 変更が頻発する時期はモノリシックじゃないとつらい

• ビジネスロジックが同じなら使い回すべき

余談・変更の激しさ

ここ１年で11万行書いて8万行消しました…

After alpha release of Repro

リクエストどうにかしたい

情報を送って 変換して 分析する受け取って

フォーマット チェック

再びサービス分割へ

情報を送って 変換して 分析する受け取って

フォーマット チェック

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

ビジネスロジックの依存を捨てる

情報を送って 変換して 分析する受け取ってフォーマット チェック

•簡易なチェック（JSONフォーマットとキーとなる値）だけにする

•キー値の妥当性チェックはAPIで他のサーバーに聞きに行く

後工程で賄える事は後工程へ

情報を送って 変換して 分析する受け取ってフォーマット チェック

•簡易なチェック（JSONフォーマットとキーとなる値）だけにする

•キー値の妥当性チェックはAPIで他のサーバーに聞きに行く

教訓その２

• 単一の責務に集中させる

• 後工程のコスト下げたいとか欲を出さない

• もし、責務から外れる行為をやりたいときはAPI作って叩きに行く

And now

リクエストに合わせた工夫をする

• あまりに多いリクエストをさばくにはRailsがつらい。

• キャッシュにヒットしない分析データはリクエストに時間がかかる=unicorn向かない

まとめ

• 最初はモノリシックに、そこからサービスを分ける方が責務が明確になる。

• リクエスト数や状況に応じて、単一の責務に特化したサービスに分割する。欲を出さない