Microservices

Basic LT vol.1

今回のテーマ

「データベースでくっつけない」

マイクロサービス間連携

• HTTP
• RPC
• Database　この話

マイクロサービスは「疎結合性」が重要

• 小さいサービス、小さいチーム
• 組織としての独立
  • 高速なリリースサイクル
• 技術的な独立
  • 各サービスはインターフェースを変えない限り、いくらでもリファクタリング可能
  • (DBでさえも差し替えられる)
• サービス間を疎結合にするのが重要
  • 内部実装は隠蔽する

DB結合=密結合

• データベースはあくまでサービスの詳細実装
• 変更されることはありうる
  • (とはいえ、変更するのは大変だけど)
• 他サービスにDBを参照されていると、DBの見直しは不可能
• HTTPのAPIなら?
  • 新しいバージョンのAPIを作り、移行期間を設けて古いAPIを消すことが可能

事例 「タイムライン機能」

• FiNCのアプリに以前からある機能
  • 食事やつぶやきなどを投稿できる
• これを改善し、リッチにしていく方向性になった
  • ハッシュタグをつける、検索できる
  • シェアできる
  • など
• (MySQLだと限界あるな・・・)

事例 「タイムライン機能」

• そうだ、マイクロサービス化しよう ( ･ㅂ･)و ̑̑
  • 高速に改善できる
  • 技術選定も独立して色々できる
• けれど、ひとまず最低限は今のまま実装したい
  • ビジネス的な状況とのバランス
  • MySQLでも半年は大丈夫そう
• 中長期で、技術スタック改善していきたい

DBで結合していると・・

• 一部をマイクロサービス化する => できない
  • 正確には、新しいマイクロサービスも同じDBを見続けることになる
• 新しい技術スタックに切り替えられない

どうしたら良いか

• まずはHTTPから検討
• 無理な場合、「必要なデータだけを同期する」というのを検討する

FiNCの場合

• 基本的にはJSON over HTTP
• 一部のみ、リードレプリカを見ているサービスがある
  • 子分的なサービス
    • 「おすすめユーザのリコメンド」のロジックなど
  • とはいえ、だいぶ成長してきている問題

まとめ

• サービス間の疎結合性が重要
  • マイクロサービスの肝ともいえる
• DBで結合すると、密結合になってしまう
• HTTPでのAPIでの結合を、第一の選択肢にする
  • DB結合は選択肢にいれないほうが良い