FiNC Microservices
Present and Future
Who am I?
森 久太郎 (もり きゅうたろう)
- 2016/2 FiNC 入社
- 1つのサービスのLead Engineer
- 多分FiNCで一番小さいサービス
- Node.js (3年) / Ruby on Rails (3ヶ月)
DEMO
microservices of FiNC
- 本体
- サーベイ
- FiNC Mall
- Chat
- 認証
- 法人管理
- 優待サービス
- etc...(他にも多くある)
分類？
Cookpad 吉川さんによる分類
- ユーザサービス
- ビューサービス
- 共通基盤
現在、FiNCにはビューサービスはない
分類(仮)
| ユーザ | 管理画面 | 共通基盤 | |
|---|---|---|---|
| 本体 | ○ | ○ | |
| サーベイ | ○ | ○ | |
| FiNC Mall | ○ | ○ | ○ |
| Chat | ○ | ||
| Chat Client | ○ | ||
| 認証 | ○ | ||
| 法人管理 | ○ | ○ | |
| 優待サービス | ○ |
microservicesで良かったこと
一般的に言われているメリットは享受できている
- (今回は省略)
microservices由来の問題点
もちろん銀の弾丸ではない
極力具体的に
この3ヶ月で、僕が感じたことや
直面した問題・ドラマを中心に4つ話します
※今回はコミュニケーションの話はあまりしません
今回挙げる事象
-
他サービスのAPI不詳問題
-
ClientがRESTful辛い問題
-
リリース順事件
-
どっちが何するか問題
1. 他サービスのAPI不詳問題
- APIの返りのパターンが詳細に分からない
- 例外処理したい時とか困る
- APIの挙動が思ってたのと違う
1. 他サービスのAPI不詳問題
- ふわっとしたコミュニケーションをしない
- HTTPの仕様で会話する
- method, uri, request body, status code, response body
- ...必要だけど意外と面倒
- 同一サービスなら、メソッドみれば分かる、、
解決案
1. 他サービスのAPI不詳問題
解決案: JSON Schema で in/outを完全に定義する?
2. RESTfulがClient辛い問題
クライアントの1画面に対して、多数のAPIが紐づくため、リクエストが多くなりすぎる。
その画面に必要最低限なデータがほしい。
2. RESTfulがClient辛い問題
2. RESTfulがClient辛い問題
解決策: API Orchestration Layerを入れる?
(類語 Front-end Server / API Gateway)
1と2の解決案について
うまくやらないと二度手間になる
-
JSON Schema
- requestのバリデーション2回書くのか
- docは今の所 Swagger で事足りてる部分もある
-
APIオーケストレーション
- BackendにAPI実装するたびに、その層にもコード書く必要ある？
求、実践例！！
3. リリース順事件
- 「優待サービス」の機能で、クレカ決済が必要
- 決済はすでにFiNC Mallの機能にあった
- APIは公開されていなかった
- 新しい要件もあった
- FiNC Mallで手直ししてAPI公開してもらった
- Stagingで繋ぎこみ完了
3. リリース順事件
- 優待サービス uses FiNC Mall
- 3/31 優待サービス リリース予定
- 4/1 FiNC Mall リリース予定
！！？！？？？
3. リリース順事件
- FiNC Mallは決済以外にも、Mall自体の機能で
重要なリリースがあった - しかしFiNC Mallのリリース日は全員から盲点だった
- 3/29くらいに問題に気づく
-
幸い、FiNC mallのリリースを3/30に早められた
- QAが順調だったため
3. リリース順事件
解決策(案)
- FiNC Mallと決済機能をサービス分割する
(次ページ: マイクロサービス分類表の修正版)
[再掲] 分類
| ユーザ | 管理画面 | 共通基盤 | |
|---|---|---|---|
| 本体 | ○ | ○ | |
| サーベイ | ○ | ○ | |
| FiNC Mall | ○ | ○ | ○ |
| Chat | ○ | ||
| Chat Client | ○ | ||
| 認証 | ○ | ||
| 法人管理 | ○ | ○ | |
| 優待サービス | ○ |
[変更後] 分類
| ユーザ | 管理画面 | 共通基盤 | |
|---|---|---|---|
| 本体 | ○ | ○ | |
| サーベイ | ○ | ○ | |
| FiNC Mall | ○ | ○ | |
| 決済基盤 | ○ | ||
| Chat | ○ | ||
| Chat Client | ○ | ||
| 認証 | ○ | ||
| CAM | ○ | ○ | |
| 優待サービス | ○ |
4. どっちが何するか問題
- 複数のAPIが連携して動くことは意外なほど多い
- どちらのサービスに何をどこまでさせるか
例) 法人管理と優待サービスの連携
- FiNC プラス ... 法人で加入してもらうサービス
- 法人に属するユーザがアプリを利用できる
- 優待サービスの一部は、法人単位で出しわけする
- 法人を管理するマイクロサービスがある
- 法人管理画面で、出しわけの情報を設定する
例) 法人管理と優待サービスの連携
- 最初、API連携の設計を失敗した
- 考え直して、設計を修正した
失敗した設計
- 「どの法人がどの優待サービスを利用できるか」は
法人管理がもつ - 法人管理の設定画面では、
- 優待サービスに一覧を問い合わせる(GET)
- 設定(POST)は法人管理に行う
- ユーザが優待サービスにアクセスしたときは
- 設定を法人管理に問い合わせる
API連携設計 初版(失敗)
※CAM=法人管理, O2O=優待サービス
この設計の問題点
- 法人管理が優待サービスドメインに関する情報を持ってしまう
-
法人管理が万能サービスのようになる
- 優待サービス以外の出しわけが発生したら？
- 法人管理が全ての情報を持つことになる
-
優待サービスで、法人以外の出しわけが発生したら？
- ex.アカウントのプランによる出しわけ(実際ある)
- 今度はまた別サービスに持つことになる
- 凝集度が低い
修正した設計
- 「どの法人がどの優待サービスを利用できるか」は
優待サービスがもつ - 法人管理の設定画面では、
- 優待サービスに一覧を問い合わせる(GET)
- 設定(POST)も優待サービスに行う
- ユーザが優待サービスにアクセスしたときは
- 法人IDだけ法人管理に問い合わせる
- 設定は優待サービス内にあるのを利用する
API連携設計 改定版
※CAM=法人管理, O2O=優待サービス
最初に間違えた理由
- 最初は「出しわけは法人管理の機能」と思ってしまった
- 法人管理画面で設定するから
- しかしよくよく考えれば、優待サービスの機能と考えるべき
- 「法人管理画面で設定」に惑わされた
- UI と Model はいかなる場合でも別と考えるべき
- 「法人管理ドメイン」と「法人管理画面」は別物
[再掲] 分類
| ユーザ | 管理画面 | 共通基盤 | |
|---|---|---|---|
| 本体 | ○ | ○ | |
| サーベイ | ○ | ○ | |
| FiNC Mall | ○ | ○ | ○ |
| Chat | ○ | ||
| Chat Client | ○ | ||
| 認証 | ○ | ||
| 法人管理 | ○ | ○ | |
| 優待サービス | ○ |
[変更後] 分類
| ユーザ | 管理画面 | 共通基盤 | |
|---|---|---|---|
| 本体 | ○ | ○ | |
| サーベイ | ○ | ○ | |
| FiNC Mall | ○ | ○ | ○ |
| Chat | ○ | ||
| Chat Client | ○ | ||
| 認証 | ○ | ||
| 法人管理 | ○ | ||
| 法人管理画面 | ○ | ||
| 優待サービス | ○ |
| ユーザ | 共通基盤 | |
|---|---|---|
| 本体 | ○ | |
| サーベイ | ○ | |
| FiNC Mall | ○ | |
| 決済基盤 | ○ | |
| Chat | ○ | |
| 認証 | ○ | |
| 法人管理 | ○ | |
| 優待サービス | ○ |
クライアントは分類から外してみる
3.4より サービス分割の一基準
- ユーザ向け機能と共通基盤機能が一つのサービスに重なったら、サービス分割を考えるべきかもしれない
- 「管理画面」はできればリポジトリを分割。
できなくても、あくまでUIなので別物と考える
Domain-Driven Design & Microservices
- ドメインの適切な境界を理解し、そこでサービスを分割する
- APIの適切な置き場所を考え、高凝集を保つ
まとめ
- JSON Schemaなどの知見ほしいです><
- フロントサーバの知見ほしいです><
- Domain-Driven Designを取り入れる