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結合は選択肢にいれないほうが良い
Made with Slides.com