最近、よく聞く「マイクロサービス」という言葉。この言葉を初めて耳にした時、私が所属するR&Dチームのプロダクトもある意味「マイクロサービス」の開発スタイルを採用しているなあと思いました。
これまでの歴史を振り返りつつ、なぜ小さな会社がScalaでマイクロサービスを始めたのか？、始めてみてどんなところが良かったのか？、また現在どんな問題に直面しているのか？について話をしていきたいと思います。
マイクロサービスとは？
James Lewis氏によって提案された小さなサービスの組み合わせでアプリケーションを開発する手法のことを言います。
詳しいことについては以下を参考に。（会社の仲間がシェアしてくれました！）
弊社の開発体制について
弊社の開発体制はPerl製のコア部分を作っているチームと、ScalaやJava等で新機能を開発しているチームに分かれています。プロダクト同士は相互にAPI連携をしてURL的には統合され顧客に機能を提供しています。
.png)
R＆Dチームのプロダクトについて
R＆Dチームのプロダクトは、複数の小さなサービスがお互いにHTTP通信やAkkaのRemote-Actorのメッセージでデータのやり取りを行って、システムを構築しています。
（例）スコアリング機能の場合
・Score：リードの属性や行動履歴からリードスコアリングを行うメインプロダクト
・OpenAPI：スコアリングに使用するMARKRTING PLATFORM（以下MP）データをキャッシュして、Jsonによる軽量なAPIを提供
・FourC：JavascriptによるMP認証機能を提供
・Malba：リクエストをタスクとして登録して各サーバにバランシングするジョブキューイングマネージャ（詳細はこちら）
.png)
Scalaでマイクロサービスを始めた経緯について
R＆Dチームが発足したのが２年半ほど前で、新しいテックスタックでビジネスインパクトの大きい新製品、機能を提供するというのがミッションでした。当時チームリーダーだった方がPlay1のコミッタだったこともあり、関数型とオブジェクト指向のハイブリッドであるScala＋Play2で、コアの製品とAPI連携して新しい機能を開発し、MARKETING PLATFORM自体の製品力強化に結びつけようとしたのが発端だったと聞いています。
＜良かったところ＞
その①：アプリ一つ一つが小さいため、全体を把握するのが容易。
一枚岩の巨大なアーキテクチャの場合、全てを把握するエンジニアがいなかったり、ちょっとした修正でも影響範囲の調査に時間がかかったり、影響が大きい場合、思い切った改修やリファクタができなかったりすると思います。マイクロサービスの場合、アプリ一つ一つが小さく、改修のコストが低く抑えられます。
また、コンポーネントの入れ替えやいらなくなったサービスの破棄が躊躇なく行えます。
その②：デプロイがラクチン
アプリ単体が小さいため、デプロイがシンプルにでき、自動化が楽です。
以下は私たちのプロダクトのテスト環境へのリリースまでの流れなのですが、メインのリポジトリにソースがマージされた後は自動でデプロイまで行われます。
その③：新しいライブラリ、ツールが試せる。
基本的にPlay2+Scalaで開発していますが、ライブラリやツールについては新しいものをどんどん試していこうという方針です。Scalaは非同期でnon-blockingな処理が簡単に書ける言語です。（慣れるまでは苦しみますが・・・）
現在はReactive Slickという新しいライブラリを試しに使用して開発を進めています。
番外編（悪いところ）
２年半ほどマイクロサービスを開発・運用して、新たな課題もたくさん見つかってきました。複数のプロセスが稼働し続けることを保証するため、高品質な監視とインフラ運用が必要だったり、複数のプロダクトが連携して一つの機能を提供するため、一つの製品で障害が発生すると各製品に影響を及ぼしたりします。また、コードを汎用的なもにしライブラリ化しているとはいえ、似たようなコードが重複して複数のサービスに入ったりするのは避けられません。
私たちはこういった課題への取り組みを模索し、解決していかなくてはならない新たな局面に入ったとも言えます。
まとめ
何よりもScalaで作ることの楽しさはメンバ全員、共通していることです。アプリを小さくすることで保守しやすくリリースを自動化でき、少ない人数で素早く開発できるというのが最大の魅力なのではないかと考えています。
また、個人的にはモノリシックなアーキテクチャがダメでマイクロサービスがいいという考えではなく、ビジネス要件に合わせて、システム全体の最適化を考え、都度よりよい選択をしていくのがいいと思っています。
最後に
いろいろ偉そうなことを言ってきましたが、現在のサービスの仕組みは今いるメンバや過去にいたメンバの思想と技術力のたまものです。（私はそこにちゃっかり乗っかっただけ）
いい仲間に囲まれて開発できてきたことがとてもありがたいです。
ほんとありがとうございます。
開発は楽しさとチームワークが大事だと改めて実感している月曜の午後でした。
