絵で見てわかるマイクロサービスの仕組み

著者 : 樽澤広亨 佐々木敦守 森山京平 松井学 石井真一 三宅剛史

• 翔泳社 (2021年7月12日発売)

作品紹介・あらすじ

DX実現のための基礎技術“マイクロサービス”のポイントを手早く習得

マイクロサービスとは何でしょうか？
小さな粒度のソフトウェアコンポーネントのことでしょうか？
いえいえ、その本質は違います。
マイクロサービスとは、サービス指向の革新的ソフトウェアアーキテクチャに加え、
コンテナやKubernetesといったアプリケーションランタイム、CI/CDや
アジャイルプロセスなどの開発手法、RESTやメッセージングなどによる
アプリケーション連携形態を包含する、クラウドネイティブコンピューティングの
包括的なアーキテクチャスタイルです。

本書では、マイクロサービスを、クラウドネイティブ時代のアーキテクチャスタイル
として捉えて、マイクロサービス流のソフトウェアアーキテクチャに加えて、
コンテナ、Kubernetes、サービスメッシュ、DevOps、ハイブリッド＆マルチクラウド
など、DXを支えるクラウドネイティブテクノロジーの全体像を解説します。

DX実現のための最新技術動向を知りたい方、クラウドネイティブコンピューティング
の概要を理解したい方、そしてマイクロサービスに興味をお持ちの技術者にとって、
本書はおすすめの一冊です。本書でマイクロサービスの本質とポイントを学び、
「2025年の崖」を飛翔のきっかけとしてください。

感想・レビュー・書評

[あかたさんの感想 · 2022年5月27日]

今の開発でもマイクロサービス化の検討をしようとしているが、なるほどと思う部分があった。が、他はまだまだ理解が追いついておらず。また必要になったら（行き詰まったら）読んでみよう。
140冊目読了。

[onesword0618さんの感想 · 2024年2月27日]

マイクロサービスとは何か改めて理解を深めるため手に取りました。

マイクロサービスを運用する上での設計パターンや留意事項を記載している書籍でした。

この書籍から参考資料へ掘り下げてマイクロサービスへの理解を深めることができると思います。

今まで、大きい単位で管理、ごまかしていたのを細かくすることで浮かび上がりそれに対してどういうアプローチ/ソフトウェアがあるのか紹介をしています。

[norikoniさんの感想 · 2023年10月27日]

図書館で借りた。
マイクロサービスは流行りですな

[akiakikoさんの感想 · 2023年2月19日]

タイトルからもっと平易な内容かと思ってしまいましたが、思ったより詳しく記載があり濃い内容だと思いました。私は過去エンジニアで、今は違うのですが、自分にとっては良いレベルでした。

[mo12inoさんの感想 · 2023年2月18日]

まぁ、範囲が広い技術なので、かいつまんでの説明になっているけど
目次としては良いと思う
CNCFのリンクは初めて知ったし

[japapizzaさんの感想 · 2022年12月25日]

・Saga：ローカルトランザクション、イベント、補償トランザクションといった技術や手法を駆使して、複数のリソース間で同期を取るためのデザインパターン。


　CQRS(Command Query Responsibility Segregation:コマンドクエリ責務分離)とは、データアクセス処理を、更新系処理(コマンド、すなわちデータの挿入/更新/削除)と参照系処理(クエリ、すなわちデータの検索/取得)に二分し、それぞれの実装にあたって、独立したサービスコンポーネントとデータストアを配すというデザインパターンです(図3.9の上)。その発想の背景には、コマンドとクエリはまったく異なるタイプの処理である、という一種の哲学があります。


■Sagaを実装する2つの手法
・コレオグラフィ：データベースにアクセスするサービスが、それぞれメッセージング製品を介してデータの同期を取り合う方法。
・オーケストレーション：Sagaオーケストレーションと呼ばれる特別なサービスが、トランザクションコーディネーションという役割を受け持つことからアプリケーション層に配置されるアプリケーションサービスとして実装。


■リファクタリングパターンの例
・Anti-corruption layer
　Anti-corruption layer (腐敗防止層) は、サービスとモノリス連携において生じる通信プロトコルやアプリケーションプロトコルのギャップを解決するためのマイクロサービスパターンです(4.45)。Anti-corruption layerの仕組みは至ってシンプルで、サービスとモノリスの間に、プロトコルのギャップを解決するためのアダプターを設けるというものです。
　たとえば、モノリスがSOAPベースのRPCスタイルのWeb APIを提供していると仮定しましょう。サービスが他のサービス(やモノリス)を呼び出す際には、REST APIやメッセージング等を使うのが、マイクロサービスにおける理想形です。また、前項で説明したように、サービスがモノリスに依存することは避けたほうがよいでしょう。
　そこで、Anti corruption layerを活用することにします。「腐敗防止」のためにアダプターコンポーネントを開発して配置します。このアダプターには、サービスから呼び出されるインターフェースとしてREST API、そしてREST API呼び出しを受けてSOAPを介してモノリスのWeb APIを呼び出す機能を実装します。さらに、RESTとSOAPベースのRPCの間でアプリケーションプロトコルを変換するロジックも組み込んでおきます。このようなアダプターを設けることでサービスがモノリスに依存することなく、両者が連携できるようになります。

・Strangler application
　次に、クラウドネイティブアプリケーションへの移行に役立つマイクロサービスパターンとして、Strangler applicationについて説明します。図4.46は、Strangler applicationパターンを模式化したものです。まずこの図の見方から解説しましょう。一番左側にPoC局面があり、左から右に時間が流れるのに従って、移行局面がリリース1.0、リリース2.0、リリース3.0と進展しています。各局面の中の上段にはSystems of Engagement(SoE)、すなわち顧客接点のWebアプリケーションのサプシステム群、下段にはSystems of Record(SoR)、すなわち基幹システムのサブシステム群が配置されています。バックグラウンドが白い長方形はモノリシックなサブシステム、バックグラウンドが黒い長方形はマイクロサービス化されたクラウドネイティブサブシステムを表現しています。
　移行作業はPoCから始まります。PoC局面ではSoEとSoRの一番右側のサブシステムの一部を、マイクロサービスを利用してクラウドネイティブ化します。それと同時に、SoEとクライアントの境界である図4.46の上段部分にStrangler Podを開発/配置します。Strangler Podとは、業務アプリケーションのメニュー画面をWebアプリケ ーションとして提供する、いわばポータルシステムです。 エンドユーザーは、Strangler Podの提供するメニュー画面で業務名をクリックすることで特定のアプ リケーションを利用するのです。
　そこで、Strangler applicationパターンでは、各局面の移行作業が終わったら、アプリケーションへのリクエストがマイクロサービス化されたサービスにルーティングされるように、Strangler Podのメニューアイテムが指し示すURIを書き換えます。このような仕組みを用意しておくことで、移行作業後すぐにサービスをリリースし、エンドユーザーに使ってもらうことが可能になりますし、プロジェクトのスポンサーである経営陣にも、具体的な成果を示すことができます。
　また、新規リリースされたクラウドネイティブアプリケーションに障害があった場合には、Strangler Pod上のメニューアイテムが指し示すURIを既存の現行アプリケー ション向けのものに書き換えることで、簡単に実績あるモノリシックアプリケーショ ンに切り戻すことが可能です。
　以上のプロセスを、リリース1.0、リリース2.0、リリース 3.0と横展開することで、段階的にアプリケーションのモダン化を進めるのがStrangler applicationバターンです。
　ちなみに、いささか物騒ですが、Strangleとは「絞め殺す」という意味です。これは他の植物に絡みつき成長するつたやつるなどの植物が、最終的には宿主となっている植物を覆いつくす様を比喩しています。Strangle applicationとは、マイクロサービスがモノリスを置き換えていく様をイメージしたネーミングなのです。


■サーバーレスとは
　サーバーレス(もしくはサーバーレスコンピューティング)とは何でしょうか?サーバーレスとは、一言でいうと「サーバー管理を必要としないアプリケーションを構築して実行する」という概念を表したものです。
　また、その名前からよく勘違いされますが、コードをホストして実行するために「サーバーが不要になった」わけではありません。サーバーレスとは、サーバーのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティ/プランニングに時間とリソースを費やす必要がないという考え方を指しています。そして、これらのタスクや機能は、すべてサーバーレスプラットフォームによって処理され、開発者や運用チームから完全に抽象化されます。
　その結果として、開発者はアプリケーションのビジネスロジックを書くことに集中することができます。運用エンジニアは、よりビジネス上で重要なタスクに集中することができます。


■サーバーレスのユースケース
　ここまで、サーバーレスの概要やアーキテクチャを中心に見てきました。ここでは、それらサーバーレスの特長を活かしたユースケースをいくつか見ていきましょう。特にサーバーレスが有効なのは、以下のようなワークロードです。
　○非同期/コンカレント/独立した作業単位へと並列化しやすいワークロード
　○要求の頻度が低い、散発的なワークロード
　○スケーリング要件のばらつきが多く、予測不可能なワークロード
　○ステートレスで短命なワークロード
　○ビジネス要件が頻繁に変化し、開発もそれにあわせた迅速さが求められるワークロード

■サーバレスの制約
・サーバレス固有の制約
　ステート管理の煩雑さ
　レイテンシの大きさ
　ローカルテストの難しさ
・現在の実装による制約
　コールドスタート
　ツールや実行環境の制約
　ベンダーロックイン

[タイガーさんの感想 · 2022年6月1日]

タイトルからは初学者向けの書籍を想像するが、コンソール画面の記載まであってエンジニア向けという感じ。マイクロサービスの適用が向いているのは大規模で複雑なシステムという主張には驚いた。段階的なリリースはメリットのように聞こえるが、大規模システムだとデータ移行のオーバーヘッドが尋常じゃないと感じる。改修のスピードとスケーラビリティがメリットだから（今のところ）フロント系のシステムに限られてしまうように思う。

[Book Villageさんの感想 · 2022年5月15日]

やや自分には内容が高度であり、中身は理解が十分にできていない。
但し、マイクロサービスやコンテナを語る上で、何を知るべきかについて一定程度イメージができたことは収穫。
自らの設計力を実践にて高めた上で、マイクロサービスアーキテクチャーを本書等を再読しつつ構想していきたい。

[surakuiさんの感想 · 2022年4月3日]

マイクロサービスとはなんぞや本。
概念を知りたい人向けの一冊。

実際自分の担当するシステムに、適用すべきかどうか？といったジャッジには直接的に役立つものではない。
おおよそのシステムがマイクロサービス不向きなような。

[井本英志さんの感想 · 2022年1月30日]

マイクロサービスについてどういうものかをさっと知るだけなら2章だけで充分だと思う。マイクロサービスに付随する理解をさらに深めるなら、この書籍から得られる情報量は多く、具体例や理解が不十分な用語の理解も、しっかり読み込むことで非常に勉強になると思う。

■クラウドネイティブコンピューティングとマイクロサービス

↓これがわかりやすい
マイクロサービスとは、基盤構築のスピード感にあわせて、アプリケーション開発とメンテナンス（変更）を、タイムリーに素早く行うための設計／開発／運用手法をまとめたものです。その中心となるのは、サービスと呼ばれる独立して開発／稼働されるソフトウェアコンポーネントを複数組み合わせることで1つのアプリケーションを開発するというソフトウェア構造にあります。 各サービスは個別に開発され、それぞれ独立して各稼働環境にデプロイできる構造を有しています。各サービスを置き換えることによって、容易にアプリケーションの変更が可能となるのです。

↓少し書籍の説明がわかりづらかったので整理
クラウドネイティブ：「クラウドの長所を徹底的に活用する」という意味を持つ言葉です。システム構築にクラウドを用いることを前提に、その特性を活かし、最適化するような設計を行うことを指します。

クラウドネイティブのランドスケープ
https://landscape.cncf.io/

Cloud Native Trail Mapは、CNCFがGitHub上で公開しているチャートで、ITシステムをクラウドネイティブ化するためのロードマップを示しています。クラウドネイティブコンピューティングに取り組む際、技術適用の順番を判断するための1つの目安になるでしょう。
https://github.com/cncf/trailmap

オーケストレーション：ソフトウェアやシステム、サービスなどの配備や展開、構築、導入、設定、管理、運用などに関わる作業や処理を専門的なソフトウェアを用いて自動化すること

↓マイクロサービスの向き不向き
大規模／複雑なシステム開発を、ガバナンスを利かせながら整合性をもって運営するのはなかなか大変です。このようなケースであればこそ、対象領域（ドメイン）を分割し、それぞれを独自に開発／運用するマイクロサービスが向いているのです。


■用語

SOA：サービス指向アーキテクチャの意。企業に導入されている様々なアプリケーションまたその機能の一部を一つのサービスとしてコンポーネント化し、そういった部分部分を必要に応じて一つのサービスとして組み合わせることで新たなシステムとして使う、といった設計の手法である。

DDD：システムを作る際も業務と切り離さず、密接に設計・実装しようというものです。ビジネスの境界によって分けられたシステムというのは高凝集・疎結合に分けられるという利点があり、まさしくマイクロサービスとの親和性がすごく高いと言えます。