fincとマイクロサービス

組織の急成長を支える技術

FiNCとマイクロサービス

株式会社FiNC　Shinozuka Fumiya

I. マイクロサービスがそれなりに II. マイクロサービスで踏みやすい地雷 III. FiNCにおけるマイクロサービスの実情

この講演を聞いてわかること

自己紹介マイクロサービス FiNCでの導入事例困難と対策課題と今後の対応予定まとめ

~table of contents~

自己紹介

• 篠塚史弥 (@shinofumijp) • FiNCエンジニア

• FiNC内のほとんどのアプリケーションの立ち上げに関わる • アプリケーションアーキテクチャの設計と実装を行う

• APIへの目覚め • 大学院在学中に総務省の情報流通連携基盤の共同研究に携わり、Web API、マイクロサービスに興味を持つ


~table of contents~

1つのアプリケーションを小さなサービスの集合として開発する手法

マイクロサービスって?

http://dev.otto.de/2014/07/29/scaling-with-microservices-and-vertical-decomposition/

マイクロサービス9つの特徴

① サービスによるコンポーネント化 ② ビジネス機能中心の構成 ③ プロジェクトではなくプロダクト ④ スマートエンドポイント、ダムパイプ ⑤ 分散ガバナンス ⑥ 分散データ管理 ⑦ インフラストラクチャ自動化 ⑧ 障害設計 ⑨ 進化的設計

http://martinfowler.com/articles/microservices.html


マイクロサービス9つの特徴①サービスによるコンポーネント化 HTTPやRPCで連携するサービスを分離してコンポーネントとして扱う

②ビジネス機能中心の構成技術レイヤーではなく、ビジネス能力に基づきサービスの分割を行うコンウェイの法則

③プロジェクトではなくプロダクト機能を提供して終わりではなく、プロダクトやユーザを意識する



マイクロサービス9つの特徴④スマートエンドポイント、ダムパイプ複雑なプロトコルではなくRESTfulなHTTP APIや軽量なメッセージングプロトコルを用いる

⑤分散ガバナンス中央集権的にすると特定の技術にロックインされがち適材適所で技術の選定ができる

⑥ 分散データ管理個々のサービスがデータベースを所有結果整合性境界づけられたコンテキスト



マイクロサービス9つの特徴⑦インフラストラクチャ自動化自動テストや自動デプロイを行うビルドパイプラインを作成する

⑧障害設計障害体制があるように設計する。障害がUXに影響しないか考慮。障害を検知できるようにモニタリングする

⑨進化的設計他への影響を少なくデプロイできるのでざっくりとしたリリーススケジュールを立てることができる



マイクロサービスでなにがうれしいの？

•モノリシックでやっていると辛いことがある •デプロイが全体のアプリケーションに影響を与える •開発の影響範囲、責任の分解点が難しい •プロジェクトにジョインしたもののどこから読めばいいんすか

なんでマイクロサービスて流行ってるの？

•技術環境の変化 •ハードウェアの低廉化と高速化 •ネットワークの高速化と普及 •クラウド環境の充実

•技術スタートアップに代表されるプロダクト中心の組織構成 •コンウェイの法則

前から似たような手法ない？

SOA(Service Oriented Architecture)があるマイクロサービスもSOAの焼き直し (マイクロサービス自体明確な定義がないしSOAも多義的)

新規性は？

概念自体は新しくない HTTP APIといったシンプルなWeb技術の利用とか CI環境により実現しやすくなったとか

銀の弾丸？

もしかして

もしかして

NO

パフォーマンス

もしかして：銀の弾丸？

インフラ管理コスト

デプロイ順序

整合性分散

APIルーティング

テストサーバ構築方法多様化

障害発生ポイントの増加

車輪の再発明

バージョンアップが地獄

もしかして：銀の弾丸？

ググると出てくるような一般的な話ですが

運用すると大変さがわかります(後述)


~table of contents~

マイクロサービスに至った経緯

サービス多角化とDivision経営

ダイエット家庭教師

CEO

マ｜ケティング事業部

フィットネス事業部

オンラインワ｜クス事業部

EC 事業部

ライフサイエンス事業部

マイクロサービスの実例 FiNC App

マイクロサービスの実例 FiNC App

• チェック→ソリューション→EC • 行動変容と継続のためのウェルネスバリューチェーン

ウェルネスサーベイ

遺伝子･血液検査

食事指導

サーベイ＋各種検査

分析結果レポート

パーソナライズソリューション&コンテンツ

専門家のアドバイス SNSヘルスケア

の知識・智恵

レシピ豆知識理想の食事

腕を大きくふって歩く

背伸びを3回する

肩甲骨を3回す

野菜を毎食食べる

1日1ℓ以上水を飲む

朝ヨーグルトを食べる

• 総合結果 • 心身の状態 • 解決すべき行動 • 生活習慣病リスク • お勧めプラン etc.

フィットネスタスク

FiNC STORE

ポイント獲得

• オーダメイド･パーソナル･サプリメント

• 酵素ドリンク • スムージー etc.

タスク実行や食事投稿で貯まるポイント

ポイント適用可サーベイ結果

ヘルスケアツーリズム

健康食コンテンツ

etc.

食事タスク

スクワットを10回ｘ3

継続して10分歩くライスを半分に控える

毎食野菜から食べる

FiNC Appのシステム構成

• APIサーバの大部分はRailsアプリケーション • Backend APIの一部はGoを使用 • Front APIへのリクエスト負荷が大きくなってきたら別言語やフレームワークの利用も検討

具体的な事例①

Instance

Instance Instance Instance

Front API

血液検査 API 遺伝子検査 API 生活習慣 API

• 各サービス間のAPI連携

具体的な事例②

• ユーザーが日々行うタスクはタスク生成バックエンドサービスにより生成

• 言語にはGoを採用

・生活習慣・運動ログ・睡眠・タスクの実行・食事・アプリログ等

・タスクDB・学習エンジン・GO

具体的な事例③• Webクライアントは独立したアプリケーションにする • ユーザ側・管理画面もそれぞれ別アプリケーション • ユーザ側ではReact.jsを採用

具体的な事例④

• ユーザの食事に対する、専門家による指導はFiNCオンラインワークス事業部。

• 別アプリケーションから行っている。


~table of contents~

I. API管理の複雑化 II. 共通機能の再開発 III. ユーザ情報の分散 IV. ローカル開発の困難 V. 障害ポイントの増加 VI.整合性

発生した問題

• このデータはどのアプリケーションの責務？どのアプリケーションが何のAPI持っている？

• アプリケーション開発者が都度確認しながら開発することにより効率が下がった

• マイクロサービスに備えてちゃんと設計しないと初期に起こる問題

API管理の複雑化発生した問題

• ドメインモデルによる分割とRESTfulなインターフェース

• アプリケーション開発者はデータの出自を気にせずに欲しいデータを取得できるように

• データを自アプリケーション内にキャッシュするかは各アプリケーション運用方針に委ねる

対応

• ビジネススキームの変化、ドメインの追加により分割が変更する可能性は大いにある。最初から賢く設計しすぎないことが大事。

• ドメインの分割は頭を使う作業 • 提供したい、利用したいものを適切な粒度の言葉(=概念)で抽象

• サービスを通して何を提供したいのか、事業のフォーカス、設計思想、ハードウェアリソース、etc.に左右される

余談)ただし、、、

• ツールやtips系のメソッドを別アプリケーションでも書いてしまう

共通機能の再開発発生した問題

• Gemで！ • 言語をまたがる時は車輪の再発明してしまっている

対応

• 各アプリケーションで独立してDBを利用 • 認証情報が分散し同期が困難に

ユーザの認証情報の分散発生した問題



• FiNCAccountManagerというライトな認証サービスをバックエンドアプリケーションとして作成

• 基本はOAuth

対応

• アプリケーションをいくつも立ち上げる必要がある • すべてのアプリケーションを自分でclone & pull(!) • バージョンが古いまま開発することも、、、

ローカル開発環境発生した問題

• Dockerを用いたローカル開発環境基盤の作成 • コマンドラインから以下の操作が可能に

• ローカル環境にデプロイ • 個人情報をマスクしたデータを利用 • 最新バージョンをpull

対応

• サーバ数の増加に伴う障害発生ポイントが増加

障害ポイントの増加発生した問題

• 障害が発生するのは仕方ない • 冗長構成にする • 死活監視を行う • 逆にモノリシックなシステムだと障害回数自体は少なくなるかもしれないが、その分1回あたりのダメージが大きくなるので恩恵を受けている

• 障害が起きても他アプリケーションが稼動できるような設計は必要

対応

• 分散環境ではSQLのトランザクションが行えない

整合性発生した問題

• 結果整合性を採用 • 現在は定期的なバッチによる同期処理 • 失敗時のロールバックをアプリケーションで保障

対応

マイクロサービスって大変そうだし本当にやる意味あるの？

困難はあれどそれを上回る恩恵がある!!

マイクロサービスにより得た恩恵

• 独立した開発サイクル • 小さなチームで機動力のある開発 • 技術的なチャレンジがしやすい

• 適材適所で言語が変えられる • コードが小さく影響範囲も小さい

• サービスにメンバーがジョインしやすい • リファクタリングも楽

• 独立してデプロイできる • 影響範囲が小さなPDCAが回せる • テストからデプロイまでが早い • 障害が波及しない


~table of contents~

• APIオーケストレーション層の作成 • クライアントとサーバの間にクライアント用にAPIを変換する層

• 各クライアント開発者がカスタマイズ可能

課題1:各クライアントに最適化されたAPIがほしい

http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

• RDBをキューとして利用 + デーモン • キューに保存するまでをトランザクションにする

課題2:分散環境での整合性保障を楽にしたい

• アプリケーションの改善、組織の拡大は続く • 疎結合にしたつもりが依存しあうこともある • アプリケーションを運用し続ける限り避けられない

課題3:それでも残る(悪い)密結合！

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.jhtml


• アプリケーションの改善、組織の拡大は続く• 疎結合に• アプリケーションを運用し続ける限り

課題3:それでも残る(悪い)密結合！

一緒にマイクロサービスを支えてくれるエンジニア求む！




~table of contents~

I. マイクロサービスはスケーラビリティ上有効な手段だが運用上の困難が多く伴うことを説明した

II. FiNCでのマイクロサービス導入の経緯と実例、現在の課題と今後の対応予定を話した

III. FiNCでも様々な技術的困難があったがそれに見合うだけの恩恵にあずかった

IV. 紹介しきれなかった開発秘話もまだまだあります

ありがとうございました！

fincとマイクロサービス

Technology