エウレカのマイクロサービスデザイン – pairsフルスクラッチを通して
- 2015.12.13
- Event
- by Shintaro Kaneko
この記事はエウレカ Advent Calendar 2015 (Qiita) の13日目の記事です。
pairsのリリース当初から開発に携わっている金子です。
普段はエウレカのフォトグラファーとして撮影をしており、その合間に開発を行っています。
さて、今回はpairsがマイクロサービスを選択した理由と、現在の状況とこれからどのようにしていくかを紹介します。
マイクロサービスとは?
マイクロサービスとは、システムのアーキテクチャパターンの一つであり、システムを一つ以上のサービスに分割してそれらの組み合わせてシステムを稼働させるアプローチとなります。
また、マイクロサービス化されていないサービスをモノリシック(一枚岩)なサービスと呼ぶこともあります。
pairsのマイクロサービス化
マイクロサービス化する理由
pairsがリリースされてから3年以上が経過し、その中で様々な施策を打ち出し実施してきました。リリース当初からスピード感を持って施策に関する開発と運用機能を積極的に追加し、その結果として巨大化したモノリシックなpairsになってしまいました。
この状態ではpairsの開発に携わる全員がpairsの全機能に対して影響範囲を考慮して開発する必要が生じますし、この巨大化されたシステムを細分化・縮小させることも、密結合が過ぎたこのシステムでは不可能に近い状態でした。
そのため、pairsのフルスクラッチに併せてシステムをマイクロサービス化させ、それぞれのサービスを疎結合として影響範囲を少なくし、デプロイサイクルも別々に行えるような設計へとシステムを変更していっています。
現在のマイクロサービス状況
先日弊社で開催したeureka Goにて、現在pairsがマイクロサービス化をどこまで達成することができたのかお話させて頂きました。
今までは全てのサブシステムが統合されていたシステムでしたが、今回からWeb・管理画面・バッチを別々のビルドシステムを持ち形にしてサービスを提供しています。
そして、決済サービスが完全なるマイクロサービスとして提供し、検索サービスはまだコンポーネントレベルですがマイクロサービスに向けて開発を進めています。
半年〜1年後を見据えたマイクロサービス
pairsの開発で実装されたマイクロサービスを事業を跨いで使用できるマイクロサービス開発をエウレカでは見据えて動いています。
現在マイクロサービス化されている決済サービスは既にエウレカ全体で使用できるレベルのマイクロサービス化で提供されています。
今後、pairsの質を保つための監視サービス (Surveillance Service) や検索サービスの完全マイクロサービス化、機械学習やアルゴリズムを責務する解析サービス (Analysis Service) を開発中です。
解析サービスは全社全体で使用可能なサービスにするべく開発を進めていますし、検索サービスもCouplesで使用できるようにすべきかどうかを考えて実装しています。
エウレカでのマイクロサービス設計
マイクロサービス化の基準
「マイクロサービス」と言うものの、一定に定まった定義が無ければ無用なサービスが生まれる可能性がありますし、マイクロサービスの旨味でもある「疎結合」が達成されない可能性もあります。
それらを避けるためにエウレカでは「何をもって、どのように」実現していくかを下記の4つで言語化してマイクロサービスを考えています。
- サービス指向設計に基づく (Service-Oriented Architecture)
- データストアの分割 (Separated Data Store from a Specific Layer)
- プロダクションコードを最新に保つ (Keep Code at a Similar Level)
- マイクロサービスごとのビルドサイクル (Do a Separate Build for Each Microservice)
サービス指向設計・データストア分割の補足をすると
サービス指向設計に基づく
サービス指向設計(以降、SOA)を完全に取り込んでいるというわけではありません。サービスをどのように定義・分割していくかの「目的」として、サービス指向のコンテキストをうまく活用しています。
※マイクロサービスとSOAは実現手法が違うため、実現させる手立てはRESTful Web APIでサービスを提供しています。
データストアの分割
エウレカ全体で使用可能なマイクロサービス (Payment Service) はスタンドアロンなデータベースで実装されています。
pairs内のマイクロサービスは同じデータベースを参照するようにしていますが、今後、サービスが拡大するにつれて分割することも見据えています。
上記を守ることができれば、マイクロサービスの思想と恩恵を享受することができます。
エウレカでは、他にも様々な側面から考慮し話し合いのもとでマイクロサービス化を進めています。
おわりに
エウレカではサービスが成長するにつれてチーム・組織状況も劇的に変化してきました。
今回のマイクロサービス化はこれからの成長を見据えたアーキテクチャ選定となっており、全てが実現された暁にはpairsを最速でグロースさせる基盤が整い、独立して動けるチームがそれぞれの裁量のもとでスピード感をもって最大化されたパフォーマンスを発揮することができるようになります。
マイクロサービスを実現させる上で他に色々と苦労や悩み続けた話もありますが、その話はまた次の機会ということにしておきます。
マイクロサービス化について更に聞きたい方、今度弊社で行われるGOもくもく会(ごもくかい)に是非ご参加ください!
- 2015.12.13
- Event
- by Shintaro Kaneko
この記事はエウレカ Advent Calendar 2015 (Qiita) の13日目の記事です。
pairsのリリース当初から開発に携わっている金子です。
普段はエウレカのフォトグラファーとして撮影をしており、その合間に開発を行っています。
さて、今回はpairsがマイクロサービスを選択した理由と、現在の状況とこれからどのようにしていくかを紹介します。
マイクロサービスとは?
マイクロサービスとは、システムのアーキテクチャパターンの一つであり、システムを一つ以上のサービスに分割してそれらの組み合わせてシステムを稼働させるアプローチとなります。
また、マイクロサービス化されていないサービスをモノリシック(一枚岩)なサービスと呼ぶこともあります。
pairsのマイクロサービス化
マイクロサービス化する理由
pairsがリリースされてから3年以上が経過し、その中で様々な施策を打ち出し実施してきました。リリース当初からスピード感を持って施策に関する開発と運用機能を積極的に追加し、その結果として巨大化したモノリシックなpairsになってしまいました。
この状態ではpairsの開発に携わる全員がpairsの全機能に対して影響範囲を考慮して開発する必要が生じますし、この巨大化されたシステムを細分化・縮小させることも、密結合が過ぎたこのシステムでは不可能に近い状態でした。
そのため、pairsのフルスクラッチに併せてシステムをマイクロサービス化させ、それぞれのサービスを疎結合として影響範囲を少なくし、デプロイサイクルも別々に行えるような設計へとシステムを変更していっています。
現在のマイクロサービス状況
先日弊社で開催したeureka Goにて、現在pairsがマイクロサービス化をどこまで達成することができたのかお話させて頂きました。
今までは全てのサブシステムが統合されていたシステムでしたが、今回からWeb・管理画面・バッチを別々のビルドシステムを持ち形にしてサービスを提供しています。
そして、決済サービスが完全なるマイクロサービスとして提供し、検索サービスはまだコンポーネントレベルですがマイクロサービスに向けて開発を進めています。
半年〜1年後を見据えたマイクロサービス
pairsの開発で実装されたマイクロサービスを事業を跨いで使用できるマイクロサービス開発をエウレカでは見据えて動いています。
現在マイクロサービス化されている決済サービスは既にエウレカ全体で使用できるレベルのマイクロサービス化で提供されています。
今後、pairsの質を保つための監視サービス (Surveillance Service) や検索サービスの完全マイクロサービス化、機械学習やアルゴリズムを責務する解析サービス (Analysis Service) を開発中です。
解析サービスは全社全体で使用可能なサービスにするべく開発を進めていますし、検索サービスもCouplesで使用できるようにすべきかどうかを考えて実装しています。
エウレカでのマイクロサービス設計
マイクロサービス化の基準
「マイクロサービス」と言うものの、一定に定まった定義が無ければ無用なサービスが生まれる可能性がありますし、マイクロサービスの旨味でもある「疎結合」が達成されない可能性もあります。
それらを避けるためにエウレカでは「何をもって、どのように」実現していくかを下記の4つで言語化してマイクロサービスを考えています。
- サービス指向設計に基づく (Service-Oriented Architecture)
- データストアの分割 (Separated Data Store from a Specific Layer)
- プロダクションコードを最新に保つ (Keep Code at a Similar Level)
- マイクロサービスごとのビルドサイクル (Do a Separate Build for Each Microservice)
サービス指向設計・データストア分割の補足をすると
サービス指向設計に基づく
サービス指向設計(以降、SOA)を完全に取り込んでいるというわけではありません。サービスをどのように定義・分割していくかの「目的」として、サービス指向のコンテキストをうまく活用しています。
※マイクロサービスとSOAは実現手法が違うため、実現させる手立てはRESTful Web APIでサービスを提供しています。
データストアの分割
エウレカ全体で使用可能なマイクロサービス (Payment Service) はスタンドアロンなデータベースで実装されています。
pairs内のマイクロサービスは同じデータベースを参照するようにしていますが、今後、サービスが拡大するにつれて分割することも見据えています。
上記を守ることができれば、マイクロサービスの思想と恩恵を享受することができます。
エウレカでは、他にも様々な側面から考慮し話し合いのもとでマイクロサービス化を進めています。
おわりに
エウレカではサービスが成長するにつれてチーム・組織状況も劇的に変化してきました。
今回のマイクロサービス化はこれからの成長を見据えたアーキテクチャ選定となっており、全てが実現された暁にはpairsを最速でグロースさせる基盤が整い、独立して動けるチームがそれぞれの裁量のもとでスピード感をもって最大化されたパフォーマンスを発揮することができるようになります。
マイクロサービスを実現させる上で他に色々と苦労や悩み続けた話もありますが、その話はまた次の機会ということにしておきます。
マイクロサービス化について更に聞きたい方、今度弊社で行われるGOもくもく会(ごもくかい)に是非ご参加ください!
Recommend
これだけは気をつけたい!WordPressプラグインを選定する際の注意点3つ
- 2015.12.04
- Event
- by Shuhei Katori
Tech Blogはじめます
- 2015.12.01
- Tech-management
- by Junya Ishibashi