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にはビューサービスはない

分類(仮)

  microservicesで良かったこと

一般的に言われているメリットは享受できている

• (今回は省略)

  microservices由来の問題点

もちろん銀の弾丸ではない

極力具体的に

この3ヶ月で、僕が感じたことや

直面した問題・ドラマを中心に4つ話します

※今回はコミュニケーションの話はあまりしません

今回挙げる事象

1. 他サービスのAPI不詳問題

2. ClientがRESTful辛い問題

3. リリース順事件

4. どっちが何するか問題

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と決済機能をサービス分割する

(次ページ: マイクロサービス分類表の修正版)

[再掲] 分類

[変更後] 分類

4. どっちが何するか問題

• 複数のAPIが連携して動くことは意外なほど多い
• どちらのサービスに何をどこまでさせるか

例) 法人管理と優待サービスの連携

• FiNC プラス ... 法人で加入してもらうサービス
  • 法人に属するユーザがアプリを利用できる
• 優待サービスの一部は、法人単位で出しわけする
• 法人を管理するマイクロサービスがある
• 法人管理画面で、出しわけの情報を設定する

例) 法人管理と優待サービスの連携

• 最初、API連携の設計を失敗した
• 考え直して、設計を修正した

失敗した設計

• 「どの法人がどの優待サービスを利用できるか」は
  法人管理がもつ
• 法人管理の設定画面では、
  • 優待サービスに一覧を問い合わせる(GET)
  • 設定(POST)は法人管理に行う
• ユーザが優待サービスにアクセスしたときは
  • 設定を法人管理に問い合わせる

API連携設計 初版(失敗)
※CAM=法人管理, O2O=優待サービス

この設計の問題点

• 法人管理が優待サービスドメインに関する情報を持ってしまう
• 法人管理が万能サービスのようになる
  • 優待サービス以外の出しわけが発生したら？
  • 法人管理が全ての情報を持つことになる
• 優待サービスで、法人以外の出しわけが発生したら？
  • ex.アカウントのプランによる出しわけ(実際ある)
  • 今度はまた別サービスに持つことになる
• 凝集度が低い

修正した設計

• 「どの法人がどの優待サービスを利用できるか」は
  優待サービスがもつ
• 法人管理の設定画面では、
  • 優待サービスに一覧を問い合わせる(GET)
  • 設定(POST)も優待サービスに行う
• ユーザが優待サービスにアクセスしたときは
  • 法人IDだけ法人管理に問い合わせる
  • 設定は優待サービス内にあるのを利用する

API連携設計 改定版
※CAM=法人管理, O2O=優待サービス

最初に間違えた理由

• 最初は「出しわけは法人管理の機能」と思ってしまった
  • 法人管理画面で設定するから
• しかしよくよく考えれば、優待サービスの機能と考えるべき
• 「法人管理画面で設定」に惑わされた
• UI と Model はいかなる場合でも別と考えるべき
  • 「法人管理ドメイン」と「法人管理画面」は別物

[再掲] 分類

[変更後] 分類

クライアントは分類から外してみる

3.4より サービス分割の一基準

• ユーザ向け機能と共通基盤機能が一つのサービスに重なったら、サービス分割を考えるべきかもしれない
• 「管理画面」はできればリポジトリを分割。
  できなくても、あくまでUIなので別物と考える

Domain-Driven Design & Microservices

• ドメインの適切な境界を理解し、そこでサービスを分割する
• APIの適切な置き場所を考え、高凝集を保つ

まとめ

• JSON Schemaなどの知見ほしいです><
• フロントサーバの知見ほしいです><
• Domain-Driven Designを取り入れる