フロムスクラッチ開発者ブログ

from scratch Engineers' Blog

マイクロサービスアーキテクチャと技術選定

こんにちは。

フロムスクラッチでエンジニアをしている原口と申します。

普段はアーキテクトとしてスクラムチームのサポートを行ったり、それ以外にもAWS EMR周りの管理を担当したりしています。

先日、フロムスクラッチ Advent Calendar 2017 - Qiitaにて、AWS EMRのコストと安定稼働の両立に関する記事を執筆させていただきました。もしよろしければそちらもご覧ください。

【AWS】【EMR】スポットインスタンスでの安定稼働を目指して(1/3):スポットインスタンスとは - Qiita

【AWS】【EMR】スポットインスタンスでの安定稼働を目指して(2/3):インスタンスフリートを考える - Qiita

【AWS】【EMR】スポットインスタンスでの安定稼働を目指して(3/3):処理特性と設定指針 - Qiita

 

さて、はじめてはてなブログで執筆するブログの記事、どうしようかなと思ったのですが、まあ・・・初回は真面目に書きましょうかね?

ということで、今回取り上げるのはマイクロサービスアーキテクチャと技術選定というお題でブログを書こうと思います。

 

マイクロサービスアーキテクチャとは

マイクロサービスアーキテクチャについて、ここで改めて細かく言及するつもりはありません(章末にいくつかのリンクを記載しておきます。)が、

  • アプリケーションのコンポーネントを小さな単位に分割する
  • それぞれのコンポーネントは極力疎結合の状態にし、コンポーネント間のインタラクションはAPIを通じてやりとりすることで実現する

という特徴があります。

f:id:shun-haraguchi:20180103225558p:plain

マイクロサービスアーキテクチャの図例

(出典:Microsoft Azure アーキテクチャスタイル https://docs.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/microservices

そうすることによって、例えばアプリケーションの改修を行う際にその影響範囲を小さくすることができたり、障害が発生した場合の影響範囲を小さくすることができるというメリットがあります。逆にデメリットとしては、インフラ面が細かい単位で分断されるので、管理が煩雑になることが挙げられるでしょう。

フロムスクラッチのプロダクトであるb→dash 2.0においても、このマイクロサービスアーキテクチャを採用しています。フロムスクラッチでは複数のスクラムチームで、おおよそ2週間スパンでのアジャイル開発を行っているため、マイクロサービスアーキテクチャのメリットが開発の効率化に繋がっています。

マイクロサービスアーキテクチャにおける技術選定

フロムスクラッチの各コンポーネントは、例えば"分析機能"や"レコメンド機能"といった、それ単独でお客様に価値を提供するサービスの単位で分割されています。それぞれのコンポーネント内はそれぞれのサービスごとに設計・開発していますが、プログラミング言語にはWeb系にRails+Vue.js、バッチ系にJavaやScalaなど、おおよそお決まりのパターンがあります。

 

話は少し変わりますが、私は昨年、米IBMが毎年ラスベガスで開催しているイベントInterConnect 2017に参加しました。その中で印象に残ったセッションの1つに、「Java, Node.js and Swift: Which, When, and Why?」にというセッションがありました。

このセッションはマイクロサービスモデルにおいて、どういう時にどの言語(ここではJava, Node, or Swift)を選定するべきかという内容のセッションで、ざっくり内容を述べるならば、

せっかくコンポーネント間が疎結合で、かつAPIでやりとりするのであれば、コンポーネントごとにその特性に合わせた言語選定をすれば良いのではないか。それは例えば、

  • ファイルI/OやDBとのやりとりが中心になるコンポーネント:Java
  • 外部サービスとのやりとりなどでJSONの変換が多く発生するコンポーネント:Node

といったように。(注:セッション内では言語のスペック比較を示して上記の結論を出していましたが、ここではそこまでは紹介しません。)

このセッションではアプリケーションの言語選定のみを考えていましたが、もっと攻めるならば、例えば外部サービス:メール配信サービスをスループット重視なのか価格重視なのかをサービスによって変えてみたり、といったことなど、言語に限らずもっと様々な範囲で活用できる話だと思っています。もっとも、上記のセッションでは技術的な観点だけで考察しており、その他の要素(例えば、組織の柔軟性や、コスト面などの組織やビジネスの観点)は一切考えていないので、現実的にはもっと様々な観点で判断する必要があるでしょうが・・・。

ただ、マイクロサービスアーキテクチャによって、これまでにはできなかった組み合わせや設計も実現できる可能性がある。だから、固定観念にとらわれず、もっと大胆に色んなことを考えることができるのではないかな、と思っています。

 

この章の冒頭でも述べましたが、フロムスクラッチのb→dashではおおよそお決まりのパターンがあります。それにより、必要なスキルセットをコンポーネント間である程度固定することによって、組織の柔軟性を確保している面があります。

そのため、新しい技術要素を取り入れるということは、そういった流動性を一時的に損なってしまったり(その技術要素のスキルを持った人に依存してしまう)、管理が煩雑になってしまうというデメリットもあります。

しかし、私はマイクロサービスアーキテクチャにはまだまだ可能性が眠っていると思っています。なので、アーキテクトとして固定観念にとらわれることなく大胆な発想で様々な選択肢を、しかし冷静に客観的にそれらの選択肢を評価して、その上で良いと思うものはしっかりと取り入れていきたいと思っています。

まだまだb→dashは発展途上。これからも進化していきます。もちろん使っている技術も、私たちエンジニアも。

 

今後のフロムスクラッチに益々ご期待いただければ幸いです! 

それでは、ごきげんよう!

 

参考文献