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

著者 : Sam Newman 木下哲也

• オライリージャパン (2016年2月26日発売)

作品紹介・あらすじ

注目度の高いアーキテクチャ「マイクロサービス」を解説！
本書は「最近良く聞く“マイクロサービス”っていったい何？」という疑問に答える本です。マイクロサービスとは、ThoughtWorksのジェームス・ルイスが提唱するアーキテクチャです。モノリシック（一枚岩）なアーキテクチャでは、変更やメンテナンスも大変なため、複数の小さいサービスに分割してそれを連携させたアーキテクチャにして、開発やメンテナンスの負担軽減を図ろうとするものです。マイクロソフトをはじめ採用する企業が現れてきており、ますます浸透が期待される技術です。

感想・レビュー・書評

[onesword0618さんの感想 · 2023年8月3日]

マイクロサービスがどういうアーキテクチャを指しているのか改めてどう定義されていたりしているのか興味を持ちました。

その為、この書籍からスタートして肉付けをしていこうと思い手に取りました。

内容としては、肥大化したコードベースを分割統治するアプローチに言及していました。

その分割方法やメリット、デメリットについて展開していました。

出版した段階の情報の鮮度と現在の情報鮮度は別で突き合わせる必要があると認識しています。

しかし、大枠の概念や定義について自分の中に落とし込むことができました。

まずは、どんな概念なのかということを押さえたい場合は有用なのかなと思いました。

[misunderstandさんの感想 · 2022年5月23日]

マイクロサービスアーキテクチャ自体はソフトウェア全般の話題なのだろうと認識しているが、自分のドメインに当てはめて考えるのは難しかった。
翻訳が素晴らしく良いというわけではない。

[KHさんの感想 · 2022年4月28日]

分散させた時にどうトランザクションなど担保するのか。
セキュリティ（認証）はどうサービス間で連携するのか。
データベース分散したら、外部キーどうするのか。

などなど、気になってた点について書かれていて、よい答え合わせができました。

[kaota01さんの感想 · 2022年3月24日]

訳があまりにもひどい。
中学生の作文ですか？みたいな日本語訳の連発で、おそらく良書であろう原著の内容がちっとも頭に入ってこない。
英訳の問題かと思ってたら、巻末の付録の日本語文章がまたひどい。真っ平らな描写の羅列で抑揚がなく、ただのazureのマニュアル転記みたい。
これだったら辞書引きながらでも原著読んだほうがいい。久々に買って損した一冊。

[ドラレプさんの感想 · 2021年3月14日]

気軽なマイクロサービス化について思うことがあり、数年ぶりに読んだ。

なんというか思ってたことが全て書いてある印象。
もちろん今と状況が違う点ももちろんあるのであくまで『当時の』とカギカッコ付きで読むべきだが、普遍的な内容が多く現在にも適用できるものだった。

マイクロサービスをいつ選択すべきか、BFFをいつ選択すべきか議論されており、決して銀の弾丸として扱ってはいない。
コンテキストマップや共有モジュール、イベントソーシングなどの話も網羅的に示されている。
「みんながこれを読んでくれれば楽なのに...」と思う一方で、昔の自分は読んだ上で全然本質を理解できてなかったなーとも思う。
本を手に取るときのモチベーションが「マイクロサービスどうやるんだろう」であり、その時点でやり方にしか目が向かなくなっているのかもしれない。

どちらかというと考えが広がるというよりただただ同意する読み方をしてしまったため、もう一度しっかり読んで自分にない要素を拾い上げていきたい。
（古い本を処分するつもりで読み直したが、引用できそうな点が多く処分できそうにない）

[soさんの感想 · 2020年9月5日]

・事前の知識は必要です。

[2319chanさんの感想 · 2020年7月19日]

マイクロサービスのお勉強。

　モノシリックシステムの中では多くの場合、抽象化を行いモジュールを作成することでコードの凝集性がより高まるようにして、修正や実装が困難にならないようにしています。凝集性（関連するコードが集まるようにすること）は、マイクロサービスについて考える際に重要な概念です。…『プログラマがしるべき97のこと』…。この定義では、「変更する理由が同じものは集める、変更する理由が違うものは分ける」としています。

■主な利点
・技術異質性
・回復性
・スケーリング
・デプロイの容易性
・組織面の一致
・合成可能性
・交換可能にするための最適化

　SOAは、大規模なモノリシックアプリケーションの課題に有効な手法として登場しました。SOAは、ソフトウェアの再利用性が促進を目指す手法です。

■優れたサービスにするためには
　疎結合と高凝集性

■境界づけられたコンテキスト
　この考え方は、どのドメインも複数の境界づけられたコンテキストからなり、それぞれの境界づけられたコンテキストには外部と通信する必要のないものと、外部の他の境界づけられたコンテキストと共有されるものがあります。境界づけられたコンテキストには明示的なインターフェースがあり、そのインターフェースが他のコンテキストと共有するモデルを決定します。
　私が好きな境界づけられたコンテキストの別の定義は、「明示的な境界によって強制される特定の責務」です。

■オーケストレーションとコレオグラフィ
　オーケストレーションでは、オーケストラの指揮者のように中枢部に頼ってプロセスを推進します。コレオグラフィでは、バレエで周りの動きに合わせて自分の動きを決めるダンサーのように、システムの各部分にジョブを知らせ、詳細に対処させます。
　…
　このオーケストレーション手法の欠点は、顧客サービスが中央監督機関になり過ぎることです。…
　一般に、コレオグラフィ手法に向かう傾向が強いシステムの方が、疎結合で柔軟性があり、変更を受け入れることがわかっています。しかし、システム境界にまたがるプロセスの監視と追跡には追加の作業が必要です。


　私たち開発者がよく耳にする略語の１つがDRY(Don't Repeat Yourself)です。…DRYのより正確な意味は、システムの振る舞いと知識の重複を回避することです。…
　DRYは、再利用可能なコードの作成につながります。


　ポステルの法則は、「送信するものに関しては厳密に、受信するものに関しては寛大に」というものです。

■統合まとめ
・いかなる代償を払ってもデータベース統合を避けます。
・RESTとRPCとの間のトレードオフを理解し、RESTをリクエスト/レスポンス統合の優れた出発点と積極的にみなします。
・オーケストレーションよりもコレオグラフィを選びます。
・ポステルの法則を理解して耐性のあるリーダーを使って破壊的変更を避け、バージョンが必要ないようにします。
・ユーザーインタフェースを合成レイヤと考えます。


　モノリシックアプリケーションのデプロイは、かなり簡単なプロセスです。しかし、相互依存するマイクロサービスでは全く別の困った事態となります。デプロイは、適切に行わないと複雑になってしまい、悲惨な目に合う分野の1つです。

■デプロイまとめ
　まず、サービスを他のサービスとは独立してリリースする機能を維持することに重点を置き、どの技術を選んでもこの機能をサポートするようにします。私はマイクロサービスごとに1つのリポジトリを持つことを大いに好んでいますが、マイクロサービスを別々にデプロイしたければ、マイクロサービスごとに1つのCIビルドが必要だと、より強く確信しています。
　次に、可能ならホスト/コンテナごとに1つのサービスに移行してください。可動部の管理をより安価で簡単にするために、LXCやDockerといった代替技術を調べますが、どの技術を採用しても、すべてを管理するには自動化の文化が重要であることを理解してください。すべてを自動化してください。AWSのようなプラットフォームを利用できるようになると、自動化の際に大きな利点となります。

■テストまとめ
・フィードバックが高速になるように最適化し、それに応じてテストの種類を区別します。
・コンシューマ駆動契約を使って、できる限りエンドツーエンドテストが必要ないようにします。
・コンシューマ駆動契約を使用し、チーム間の対話の焦点を提供します。
・テストへのさらなる労力の投入(MTBFの最適化)と本番環境での迅速な問題検出(MTTRの最適化)との間のトレードオフを理解しようとします。


　セキュリティにおいては、認証はある関係者が確かに名乗っている本人であることを確認するプロセスです。人に対しては、通常はユーザ名とパスワードを入力させることで、ユーザを認証します。…一般に、抽象的に認証対象の人や物について話すときには、その関係者をプリンシパル(主体)と呼びます。
　認可は、プリンシパルとプリンシパルに許されている動作をマッピングするメカニズムです。多くの場合、プリンシパルを認証するときに、私たちはプリンシパルに何を実行させるべきかを判断するための情報を与えられます。

■マイクロサービスの原則
１．ビジネス概念に沿ったモデル化
　経験上、ビジネスで境界づけられたコンテキストに基づいて構築されたインタフェースの方が、技術的概念に基づいたインタフェースよりも安定性があります。システムが稼働するドメインをモデル化することで、より安定したインタフェースの構築を図れるだけでなく、ビジネスプロセスの変化を簡単かつ適切に反映できるようにもなります。
２．自動化の文化の採用
　サービスが常に正常に動作するように保証するのは、モノリシックシステムよりも複雑なので、自動テストが不可欠です。統一されたコマンドライン呼び出しでどこでも同じようにデプロイするのが効果的であり、これは継続的デリバリを採用して本番品質のチェックインごとにフィードバックを迅速に得るために重要です。
３．内部実装詳細の隠蔽
　サービスが他のサービスとは独立して進化する能力を最大化するには、実装詳細を隠すことが不可欠です。境界づけられたコンテキストをモデル化すると、共有すべきモデルと隠すべきモデルを調べる上で有効です。また、サービスはデータベースを隠して、従来のサービス指向アーキテクチャ（SOA）で生じる最も一般的な結合の１つに陥らないようにしデータポンプやイベントデータポンプを使ってレポートのために複数のサービスからデータを集約すべきです。
　可能であれば、技術非依存のAPIを選んで、さまざまな技術スタックを自由に利用できるようにしてください。そしてRESTの使用を検討してください。RESTは内部実装詳細と外部を正式に分離しますが、たとえリモートプロシージャコール(RPC)を使っていても、この考え方を取り入れることができます。
４．すべての分散化
　マイクロサービスが可能にする自律性を最大化するには、サービスを所有するチームに意思決定と制御を委譲する機会を常に追い求める必要があります。これにはまず可能な限りセルフサービスを採用し、必要に応じてソフトウェアをデプロイできるようにし、開発とテストをできる限り容易にし、これらの作業を行うために別々のチームが必要ないようにします。
５．独立したデプロイ
　常にマイクロサービスを単独でデプロイできるように努めるべきです。破壊的変更が必要なときでも、バージョン付けされたエンドポイントを共存させてコンシューマが徐々に変更できるように努めるべきです。…
　ホストごとに１つのサービスというモデルを採用すると、あるサービスのデプロイが別の無関係なサービスに影響を与える副作用が減ります。デプロイとリリースを分離するブルーグリーンやカナリアといったリリーステクニックの使用を検討し、リリースが失敗するリスクを減らしてください。
６．障害の分離
　マイクロサービスアーキテクチャはモノリシックシステムよりも回復性を備えますが、それはシステムの部分障害を把握して考慮した場合に限られます。下流呼び出しが失敗し得るという事実を理解していなければ、システムは破滅的な連鎖障害に見舞われ、以前よりもはるかに脆弱となります。
７．高度な観測性
　システムが正しく機能しているかどうかを確認するには、１つのサービスインスタンスの振る舞いや１台のマシンの状態の観察では不十分です。代わりに、何が起こっているかを統合的に見通す必要があります。セマンティック監視を利用してシステムが正しく動作しているかどうかを確認し、システムに合成トランザクションを投入して実際のユーザ動作をシミュレートします。ログと統計データを集約し、問題が起こったときに原因を突き止められるようにします。また、面倒な問題の再現や本番環境でのシステムの対話の確認に関しては、相関IDを使ってシステムへの呼び出しを追跡できるようにします。

■マイクロサービスを使用すべきでない場合
　…ドメインの理解度が低いほど、サービスにとって適切な境界づけられたコンテキストを見つけにくくなります。既に述べたように、サービス境界を間違えると、サービス間連携で多くの変更をしなければならなくなります。これはコストのかかる作業です。ドメインを理解していないモノリシックシステムを開発する際は、まずはシステムが担当することの把握に時間をかけ、そしてサービスを分割する前に明確なモジュール境界を特定するようにしてください。
　新規開発も困難です。これは、ドメインに対する知識が不足しているだけではありません。存在しないものを分割するよりも、存在するものを分割する方がはるかに簡単です。そこで、やはりまずモノリシックから始め、安定したら分割を検討してください。
　マイクロサービスで直面する多くの課題は、大規模になると悪化します。…REAやGiltがしばらく時間を費やしてマイクロサービスを大量に使えるようになった話をしました。これらの話は徐々に始めて変更に対する組織の欲求や能力を理解することの重要性を植え付け、マイクロサービスを適切に採用することができます。

[fujiyamaeggさんの感想 · 2020年4月24日]

マイクロサービスアーキテクチャは、現在のシステム設計を行ううえでは、避けて通れない概念であり、本書は、その最初のステップとなるべきだと思う。

以下のような気付きがあった。

・マイクロサービスの粒度をどうするのか？という疑問へのヒントがある。「２週間で書き直せるもの」といった回答も可能である。また、その疑問への回答として、役に立つ概念が「コンウェイの法則」である。それは、「システムの構造は、組織のコミュニケーション構造に倣った構造になる」という法則である。その法則に従えば、どんな組織にも適用する正解はない。その組織構造に従って、マイクロサービスの粒度も変わってくるのである。
・本書では、Netflix社とAmazon社のシステムに関して、よく引き合いに出されている。これらの企業は、マイクロサービスアーキテクチャにおけるトップランナーなのだろう。

本書を読んで、以下のようにしていきたいと思う。
・「２週間で書き直せるもの」をサービス粒度の指針にする、という考え方は、個人レベルのあらゆる作業に関しても適用できるのではないか？ある人はブログは4時間程度かけて一定のものを作るべき、というかもしれない。しかし、1日に4時間もそれに時間をあてられない人は、15分でひとつのブログ記事を書く、というのが正解なのかもしれない。そういった、有名な人がいっていることを自分にそのまま当てはめるのではなく、一旦、自分の生活に置き換えて変換する、ということを行うようにしよう。

[takashiiwasakiさんの感想 · 2020年3月31日]

イベント駆動+CQRS、コレオグラフィは依存関係逆転の法則と根本的な考え方は同じで、これまでのアーキテクチャ理解をもって応用可能だと思う。

一方で
SSOゲートウェイへの権限委譲、
冪等性の考慮、
CAP定理を理解した上でのトレードオフ
あたり具体的な実践に使えるところあたりは、これまでのCRUDアーキテクチャの考え方とは異なるところなので、パラダイムシフトが必要だと感じる。

手元に置きながら実践と読み返しを繰り返すことになるであろう一冊。読み応えあり。

[masterkaさんの感想 · 2019年9月3日]

感想は以下
https://blog.masterka.net/archives/1520