FiNCとマイクロサービス
•
40 likes•54,156 views
FiNCでのマイクロサービスの取り組みについてまとめました。 2015/9/3 ヒカラボでの登壇資料です。
Recommended
More Related Content
What's hot
What's hot (12)
Similar to FiNCとマイクロサービス
Similar to FiNCとマイクロサービス (20)
Recently uploaded
Recently uploaded (9)
FiNCとマイクロサービス
- 2. I. マイクロサービスがそれなりに II. マイクロサービスで踏みやすい地雷 III. FiNCにおけるマイクロサービスの実情 この講演を聞いてわかること
- 4. 自己紹介 • 篠塚 史弥 (@shinofumijp) • FiNCエンジニア • FiNC内のほとんどのアプリケーションの立ち上げに関わる • アプリケーションアーキテクチャの設計と実装を行う • APIへの目覚め • 大学院在学中に総務省の情報流通連携基盤の共同研究に携わり、 Web API、マイクロサービスに興味を持つ
- 7. マイクロサービス9つの特徴 ① サービスによるコンポーネント化 ② ビジネス機能中心の構成 ③ プロジェクトではなくプロダクト ④ スマートエンドポイント、ダムパイプ ⑤ 分散ガバナンス ⑥ 分散データ管理 ⑦ インフラストラクチャ自動化 ⑧ 障害設計 ⑨ 進化的設計 http://martinfowler.com/articles/microservices.html
- 13. 前から似たような手法ない？ SOA(Service Oriented Architecture)がある マイクロサービスもSOAの焼き直し (マイクロサービス自体明確な定義がないしSOAも多義的)
- 15. 銀の弾丸？ もしかして
- 16. もしかして NO
- 17. パフォーマンス もしかして：銀の弾丸？ インフラ管理コスト デプロイ順序 整合性 分散 APIルーティング テスト サーバ構築方法多様化 障害発生ポイントの増加 車輪の再発明 バージョンアップが地獄
- 20. マイクロサービスに至った経緯 サービス多角化とDivision経営 ダイエット家 庭 教 師 CEO マ ｜ ケ テ ィ ン グ 事 業 部 フ ィ ッ ト ネ ス 事 業 部 オ ン ラ イ ン ワ ｜ ク ス 事 業 部 E C 事 業 部 ラ イ フ サ イ エ ン ス 事 業 部
- 22. マイクロサービスの実例 FiNC App • チェック→ソリューション→EC • 行動変容と継続のためのウェルネスバリューチェーン ウェルネス サーベイ 遺伝子･ 血液検査 食事指導 サーベイ＋ 各種検査 分析結果 レポート パーソナライズ ソリューション&コンテンツ 専門家の アドバイス SNS ヘルスケア の知識・智恵 レシピ 豆知識 理想の食事 腕を大きくふって歩く 背伸びを3回する 肩甲骨を3回す 野菜を毎食食べる 1日1ℓ以上水を飲む 朝ヨーグルトを食べる • 総合結果 • 心身の状態 • 解決すべき行動 • 生活習慣病リスク • お勧めプラン etc. フィットネスタスク FiNC STORE ポイント 獲得 • オーダメイド･ パー ソナル･ サプリ メント • 酵素ドリンク • スムージー etc. タスク実行や 食事投稿で 貯まるポイント ポイント適用可サーベイ結果 ヘルスケア ツーリズム 健康食 コンテンツ etc. 食事タスク スクワットを10回ｘ3 継続して10分歩く ライスを半分に控える 毎食野菜から食べる
- 23. FiNC Appのシステム構成 • APIサーバの大部分はRailsアプリケーション • Backend APIの一部はGoを使用 • Front APIへのリクエスト負荷が大きくなってきたら 別言語やフレームワークの利用も検討
- 24. 具体的な事例① Instance Instance Instance Instance Front API 血液検査 API 遺伝子検査 API 生活習慣 API • 各サービス間のAPI連携
- 26. 具体的な事例③ • Webクライアントは独立したアプリケーションにする • ユーザ側・管理画面もそれぞれ別アプリケーション • ユーザ側ではReact.jsを採用
- 29. I. API管理の複雑化 II. 共通機能の再開発 III. ユーザ情報の分散 IV. ローカル開発の困難 V. 障害ポイントの増加 VI. 整合性 発生した問題
- 30. • このデータはどのアプリケーションの責務？どのアプ リケーションが何のAPI持っている？ • アプリケーション開発者が都度確認しながら開発する ことにより効率が下がった • マイクロサービスに備えてちゃんと設計しないと初期 に起こる問題 API管理の複雑化発生した問題
- 31. • ドメインモデルによる分割とRESTfulなインターフェ ース • アプリケーション開発者はデータの出自を気にせずに 欲しいデータを取得できるように • データを自アプリケーション内にキャッシュするかは 各アプリケーション運用方針に委ねる 対応
- 32. • ビジネススキームの変化、ドメインの追加により分割 が変更する可能性は大いにある。最初から賢く設計し すぎないことが大事。 • ドメインの分割は頭を使う作業 • 提供したい、利用したいものを適切な粒度の言葉(= 概念)で抽象 • サービスを通して何を提供したいのか、事業のフォー カス、設計思想、ハードウェアリソース、etc.に左 右される 余談)ただし、、、
- 37. • アプリケーションをいくつも立ち上げる必要がある • すべてのアプリケーションを自分でclone & pull(!) • バージョンが古いまま開発することも、、、 ローカル開発環境発生した問題
- 38. • Dockerを用いたローカル開発環境基盤の作成 • コマンドラインから以下の操作が可能に • ローカル環境にデプロイ • 個人情報をマスクしたデータを利用 • 最新バージョンをpull 対応
- 40. • 障害が発生するのは仕方ない • 冗長構成にする • 死活監視を行う • 逆にモノリシックなシステムだと障害回数自体は少な くなるかもしれないが、その分1回あたりのダメージ が大きくなるので恩恵を受けている • 障害が起きても他アプリケーションが稼動できるよう な設計は必要 対応
- 42. • 結果整合性を採用 • 現在は定期的なバッチによる同期処理 • 失敗時のロールバックをアプリケーションで保障 対応
- 45. マイクロサービスにより得た恩恵 • 独立した開発サイクル • 小さなチームで機動力のある開発 • 技術的なチャレンジがしやすい • 適材適所で言語が変えられる • コードが小さく影響範囲も小さい • サービスにメンバーがジョインしやすい • リファクタリングも楽 • 独立してデプロイできる • 影響範囲が小さなPDCAが回せる • テストからデプロイまでが早い • 障害が波及しない
- 47. • APIオーケストレーション層の作成 • クライアントとサーバの間にクライアント用にAPI を変換する層 • 各クライアント開発者がカスタマイズ可能 課題1:各クライアントに最適化されたAPIがほしい http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html
- 48. • RDBをキューとして利用 + デーモン • キューに保存するまでをトランザクションにする 課題2:分散環境での整合性保障を楽にしたい
- 49. • アプリケーションの改善、組織の拡大は続く • 疎結合にしたつもりが依存しあうこともある • アプリケーションを運用し続ける限り避けられない 課題3:それでも残る(悪い)密結合！ http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.jhtml
- 50. • アプリケーションの改善、組織の拡大は続く • 疎結合に • アプリケーションを運用し続ける限り 課題3:それでも残る(悪い)密結合！ 一緒にマイクロサービスを支えてくれるエンジニア求む！ http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.jhtml
- 52. I. マイクロサービスはスケーラビリティ上有効な手段だ が運用上の困難が多く伴うことを説明した II. FiNCでのマイクロサービス導入の経緯と実例、現在の 課題と今後の対応予定を話した III. FiNCでも様々な技術的困難があったがそれに見合うだ けの恩恵にあずかった IV. 紹介しきれなかった開発秘話もまだまだあります
- 53. ありがとうございました！