この記事は「Relux Advent Calendar 2018」25日目（最後）の記事です。
#Microservicies（マイクロサービス）の起点と導入事例
"Microservices"(マイクロサービス)という単語自体は、随分と前からあったとも言われていますが、有名どころでいうと、2014年にマーチン・ファウラー氏と他数名が公開した「Microservice」という記事が起点になる人も多くいると思います。
またそのアーキテクチャを採用している企業も有名なところが多く、
海外では、Amazon、NetFlix、eBay、日本では楽天、メルカリ、LINE、クックパッド、Gunosyなど多くの企業で採用されており、検索すると最近では多くの企業で導入または検討の進んでいることが伺えます。
#当社の導入背景
ローレベルでは書ききれないので、ざっくりとハイレベルでいうと、「ビジネススピードに追従できない」という問題に対する一つの手段となります。
手段は数多くあると思いますが、なぜ”Microservices”かは今後述べていきたいと思っておりますので割愛します。
という事で、トレンドの波に乗るのが遅くなりましたが、当社でもいよいよ「Microservices」の導入を決定し、準備を進めています。
#先ずはメリット・デメリットの考察から
####＜メリット＞
・Improvement fault isolation：単一モジュールの障害において、影響の受けない作りが可能
伝統的？なモノリシックアプリケーションでは、一部の障害＝全体的な障害になるケースが多く、期待大ですね。
・Eliminate vendor or technology lock-in：ベンダーロックインが排除でき、必要に応じ個々のサービスに異なるテクノロジの採用が可能
まさに、多くの企業が直面している問題に対する解決策で、ベンダーAさんはX機能について経験豊富で先端的であっても、システムとしてみた場合、他の機能の経験が少なく結果期待値に満たない作りとなってしまうリスクの回避が可能そうです。また機能によって開発言語を変えることも可能ということは人財（ここは人材ではなくあえて人財とします）の確保の幅が広がりますね。
・Ease o Understanding：追加がシンプルで開発者にとって機能の理解が容易に
外資はもちろん日本の企業でも特にエンジニアは転職率が上がってきており、人財の流動化か加速している中、せっかくJoinしていただいたのに既存システムが複雑すぎるケースにおいては、理解するために時間を要することも多くとても非効率ですが、サービス単位に分割されていることで、オーバーヘッドも効率化できそうですね。
####＜デメリット＞
・個々が独立したサービスになるため、総合的に見ると開発が複雑になる可能性があり、 特にモジュール間のリクエストは慎重に設計する必要があります。 またリモートコールに待ち時間が発生すると、複雑な問題の発生が懸念
・複数のデータベースとトランザクション管理が困難（複数のAPIコールでトランザクションを組むのは困難）
・マイクロサービスベースのアプリケーションをテストするのは困難。モノリシックなアプローチでは、アプリケーションサーバを起動し、基盤となるデータベースとの接続性を確保することでアプリケーションのテストが可能に対しマイクロサービスでは、テストを実行する前に各依存サービスの状況の確認が必要。
・複数のサービス間の調整が必要とするケースにおいて、マイクロサービスのデプロイは複雑になる可能性があるため十分な検討が必要。JavaのケースでいうところのコンテナにWARを配置するほど簡単ではない。
なるほど、世界最初の汎用コンピュータ「ENIAC」の誕生から74年経た現在においても、ソリューションとしての銀の弾（Silver Bullet）は存在しないという事ですね。では可能な限り、ポリシーを決めリスクとなり得るものはマネジメントして進んでいくことにしましょう。
#次に、キーテクノロジーの洗い出しと検証#
・API Gateway
・オーケストレーションとコレオグラフィ
・メッセージング（AMQP, MQTT…)
・サービスモニタリンング、トレーシング
他にも多くのものがありますが、リスト化すると長すぎるため割愛します。
また検証結果は別途、タイトル毎、機能毎に紹介していきたいと思います。
#そして多くの先人たちの事例からの検討事項#
・サービス分割の粒度と分割の切り口（最も重要かつ失敗につながるポイント）
・サービス間のデータ一貫性（運用を想定したデータ不整合に対する対策含め）
この課題は非常に悩ましく、一筋縄での解決は難しいですが、一定の法則を見出したいと検討しております。
#終わりに#
今日おいて、特にWebアプリケーションの開発スタイルは着実に進化し一方で機能は、ますます複雑化（一部は簡略化）してきており、
もはや属人的にアプリケーション全体を抱えるには限界に達しており、必然的にマイクロサービスという手段が生まれました。
当社も同様に” Microservices"化という道のりを選択しましたが、準備・検証は怠りなく十分実施し、いざ歩き始めたらゴールを明確に意識しながら、問題に対しては臨機応変に対応し、ゴールを目指していきます。
今後当社ブログ等で、随時情報を発信していきますので、"Microservices"化を検討しはじめている方々に少しでもお役に立てれば幸いです。