「マイクロサービスアーキテクチャ」という本の、第一章をまとめました。
https://www.amazon.co.jp/dp/4873117607/
がんがんマサカリ待ってます♪

マイクロサービス

マイクロサービスは実世界の動向から登場したもので、
ドメイン駆動設計、継続的デリバリ、オンデマンド仮想化、
インフラ自動化、小規模で自律的なチーム、などの世界から生まれました。

マイクロサービスとは

協調して動作する小規模で自律的なサービスを指します。

小さく、かつ一つの役割に専念

モノリシックの中では多くの場合、
抽象化を行いモジュール作成する事でコードの凝集性がより高まるようにして、
修正や実装が困難にならないようにしています。
凝集性(関連するコードが集まるようにすること)は、
マイクロサービスについて考える際に重要な概念です。

コードをどの程度小さくするかについては、
サービスが小さければ小さいほど、
マイクロサービスアーキテクチャの利点と欠点が最大化されます。
小さくすればするほど、相互依存関係に関わる利点が増加します。
しかし、可動部が増えることで生じる複雑さも増します。
この複雑さへの対応がうまくなると、さらに小さなサービスを追求する事ができます。

自立性

サービス間のすべての通信はネットワーク呼び出しを経由し、
サービス間の分離を強制し、密結合のリスクを回避します。
サービスはアプリケーションプログラミングインタフェース(API)を公開し、
このAPI経由で連携します。

また、サービスがコンシューマと結合しないようにするために、
適した技術についても検討する必要があります。
これは、技術に依存しないAPIを選び、技術の選択を制約しないようにすることを意味します。

黄金率は、「他には何も変更せずに、単独でサービスの変更やデプロイを行えるか」です。

主な利点

利点の多くは分散システムによるものです。
主に分散システムとサービス指向アーキテクチャの背後にある概念を深く取り入れている為、
マイクロサービスはこれらの利点をさらに拡大しつつあります。

技術異質性

複数の連携するサービスからなるシステムでは、
サービス毎に異なる技術を使う決断をできます。
システムの一部の性能で改善する必要がある場合には、
求められる性能水準を達成できる別の技術スタックを使う決断をする事もあるでしょう。

また、マイクロサービスでは技術をより迅速に採用でき、
新たな進歩がどれほど有益かを理解できます。
複数のサービスからなるシステムでは、
新たな技術を試す新しい場所が複数存在します。
リスクが最も低いと思われるサービスを選んでそこでその技術を使うと、
起こり得る悪影響を制限できます。
多くの組織は、新技術を迅速に取り入れることができるこの能力が、
大きな強みになるとわかっています。

回復性

レジリエンス(回復性)エンジニアリングの主要な考え方は隔壁です。
システムのあるコンポーネントに障害が発生していても、その障害が連鎖しなければ、
問題を分離してシステムの残りの部分は機能し続けることができます。

しかし、注意が必要です。
マイクロサービスシステムがこの改善された回復性を適切に得られるようにするには、
分散システムが対処しなければならない新しい障害の原因を理解する必要があります。

スケーリング

小さいサービスでは、スケーリングが必要なサービスだけをスケールでき、
システムの他の部分を小規模で非力なハードウェアで動作させることができます。

AWSが提供しているようなオンデマンドプロビジョニングシステムを取り入れるときには、
スケーリングが必要な部分にオンデマンドでこのスケーリングを適用できます。
これにより、コストをより効率的に制御できます。

デプロイの容易性

マイクロサービスでは、一つのサービスに変更を加えて、
残りのシステムとは独立してデプロイできます。
問題が生じた場合は、問題の原因である個別のサービスを迅速に特定でき、
迅速なロールバックを簡単に実現します。
また、これは新機能を迅速に顧客に提供できることも意味しています。

組織面の一致

マイクロサービスはアーキテクチャを組織によりよく一致させることができ、
一つのコードベースで作業する人数を最小化し、
チームの大きさと生産性を最適化します。
また、サービスの所有権をチーム間で移し、
あるサービスの開発者たちを同じ場所に配置させる事ができます。

合成可能性

分散システムとサービス指向アーキテクチャの主な利点の一つは、
機能を再利用する機会を広げる事です。
マイクロサービスでは、さまざまな目的に対して様々な方法で機能を利用できます。

マイクロサービスでは、
外部の第三者がアドレス可能なシステムの接合部を公開していると考えてください。
状況が変わったら、別の方法で組み立てられます。

交換可能にするための最適化

中規模から大規模な組織で働いていれば、
おそらく巨大で扱いにくいレガシーシステムの存在に気づいているでしょう。
そのようなレガシーシステムには誰も関わりたくありません。

個々のサービスのサイズが小さければ、
さらに優れた実装に置き換えるコストや全てを削除するコストさえも管理しやすい大きさとなります。
一連のマイクロサービスは同程度のサイズであることが多いので、
サービス全体の書き換えや削除に対する障壁は非常に低くなります。

サービス指向アーキテクチャ

サービス指向アーキテクチャ(SOA)は、
複数のサービスが連携して最終的な一連の機能を提供する設計手法です。
SOAにおけるサービスは通常、完全に別個のOSプロセスを示します。
これらのサービス間の通信は、
プロセス境界内のメソッド呼び出しではなくネットワークを介した呼び出しで行われます。

マイクロサービス手法は実世界の用途から登場し、
システムやアーキテクチャをより深く理解してSOAを適切に実現します。
その為、XPやスクラムがアジャイルソフトウェア開発固有の手法であるのと同様に、
マイクロサービスをSOA固有の手法と考えるべきです。

他の分解テクニック

マイクロサービスに取り組むと、
マイクロサービスベースのアーキテクチャの利点の多くは、粒度が細かい性質と、
問題解決方法に関してさらに多くの選択肢を得られることから来ていることがわかります。

共有ライブラリ

ライブラリによって、チームやサービス間で機能を共有できるようになります。
ライブラリを中心にチームを組織化でき、そしてライブラリ自体を再利用できます。

しかし、幾つかの欠点もあります。
まず、技術的多様性が失われます。通常、ライブラリは同じ言語であるか、
少なくとも同じプラットフォームで動作しなければなりません。
次に、システムの各部をそれぞれ独立してスケールさせる事が簡単ではなくなります。
また、ダイナミックリンクライブラリ(DLL)を使っていない限り、
新しいライブラリをデプロイするにはプロセス全体をデプロイし直さなければならないので、
変更を分離してデプロイする能力が低下します。

共有ライブラリには本来の役割があります。
ビジネスドメイン固有では無く組織内で再利用したい一般的なタスクのコードを作成する事は、
明らかに再利用可能なライブラリの候補です。
しかし、注意が必要です。
サービス間の通信に使用する共有コードは結合点となります。

モジュール

簡単なライブラリ以上の独自モジュール式分解テクニックを提供する言語もあります。
そのような言語ではモジュールのライフサイクル管理が可能です。
例えば、実行中のプロセスにモジュールをデプロイでき、
プロセス全体を停止せずに変更が可能です。

技術的には、適切に分解された独立したモジュールを一つのモノリシックプロセス内に、
作成する事は可能なはずです。しかし、まだほとんど登場していません。
モジュールはすぐに残りのコードと密接号になり、主な利点の一つを放棄することになります。
プロセス境界で分離すると、この点で正しい状態が強制されます。

私たちは、モジュールを共有ライブラリと同様の利点を提供するものと考えるべきです。

銀の弾丸などない

マイクロサービスには分散システムに関連する全ての複雑さがあり、
分散システムを適切に管理する方法について多くを学んだとしてもやはり困難です。
あなたがモノリシックシステムの世界から来た場合には、
デプロイの対処、テスト、監視を大幅に上達させて、
これまで述べてきた利点を引き出さなければなりません。

まとめ

マイクロサービスで生じる主な課題の一つは、
システムの進化を導くことの多い人(アーキテクト)の役割を変更する事です。

次章では、この役割に対する様々な手法を調べ、
この新しいアーキテクチャを最大限に生かせるようにします。