Future Tech Blog
フューチャー技術ブログ
Programmingカテゴリ

マイクロサービスパターン MicroServicePatterns の感想文

51ChNGhBinL._SX390_BO1,204,203,200_.jpg

積読を消化しようというテーマの、読書感想文連載 の 7冊目です。

はじめに

TIG コアテクの川口です。

こちらの本は 2020年3月23日 に発売された本で、当時は私が社会人1年目となった年でもありました（会社は、フューチャーではなかったですが）。

最初に配属されたチームでは、いわゆるマイクロサービスアーキテクチャが導入されておりました。ただ当時は、マイクロサービスアーキテクチャは経験したことがなく本書を読んで勉強した覚えがあります。それからはまた別でその知見を活かし、リアーキテクチャということでゼロイチでマイクロサービスアーキテクチャの設計をしたりしていました。

読書感想文として本書を選んだ理由としては、私自身のマイクロサービスアーキテクチャとやらについての考え方の整理ができたらなー！ といったものになります。

改めて本書を読み直してみると、マイクロサービスアーキテクチャに関する考慮事項が網羅的に記載されているような気がしています。しかし、詳細な部分に関してはどうしても紙面の都合上、書ききれない部分も多かったのかこれを読んだだけでマイクロサービスアーキテクチャを設計・開発・実装までできるかというと、そこにはちょっとステップがあるかなというイメージです。

ただこれからマイクロサービスアーキテクチャについて知りたい！ とか、導入を検討している！ とかという方にはオススメの本かなと個人的には思っております！

さて改めて、本書の紹介に戻ります。基本情報は以下です。
※ この記事の執筆時点では、Google ブックス等で試し読みも可能でした。

  • 発売日: 2020年3月23日
  • ページ数: 549ページ
  • コードサンプル: Java（考え方がメインなので、Java 未経験でもそんなに問題もないかなと思います）。

目次とそれらのテーマとしては、以下のようになります（テーマは、私自身が独断と偏見でつけたものになりますが）。

  • マイクロサービスとは。
    • Chapter 1: モノリシック地獄からの脱出
    • Chapter 2: サービスへの分割
  • マイクロサービス間通信について。
    • Chapter 3: マイクロサービスアーキテクチャで使われるプロセス間通信
    • Chapter 4: サーガによるトランザクションの管理
  • マイクロサービス特有の実装課題と解決について。
    • Chapter 5: マイクロサービスアーキテクチャにおけるビジネスロジックの設計
    • Chapter 6: イベントソーシングを使ったビジネスロジックの開発
    • Chapter 7: マイクロサービスアーキテクチャでのクエリーの実装
    • Chapter 8: 外部 API パターン
  • マイクロサービスのテストについて。
    • Chapter 9: マイクロサービスのテスト（前編）
    • Chapter 10: マイクロサービスのテスト（後編）
  • マイクロサービスの運用・保守について。
    • Chapter 11: 本番環境に耐えられるサービスの開発
    • Chapter 12: マイクロサービスのデプロイ
  • モノリスからマイクロサービスへ。
    • Chapter 13: マイクロサービスのリファクタリング

それでは、それぞれのテーマごとに所感を述べていく感じで本記事では進めていこうと思います。

Ch. 1 ~ 2 「マイクロサービスとは」

最初の Chapter 2つでは、マイクロサービスのメリット・デメリット。そもそもマイクロサービスとはということと、必ず悩まざるをえなくなるサービスの分割方法といったことについて述べられています。

まず、マイクロサービスアーキテクチャを導入するということであればこの部分が整理できていないと、後で必ず後悔する（後の章を見るとわかりますが、本当にマイクロサービスアーキテクチャは、モノリスと比べて考慮事項が多くなります）。と思うので、必ずこの部分は整理できているとよいなと思いました。

気になりトピックは以下にまとめておきます（※ 以降、斜字部分は本書からの引用です）。

  • マイクロサービスは、チームに自主性・自律性を与え、開発チーム間の結合が疎になる
    • こちらは、マイクロサービスアーキテクチャを導入するメリットとして記載されているものです。
    • このような組織構造としてのメリットというのは、蔑ろにされがちのような気がする？（熟達したエンジニアであればそうではないと思いますが）。のですが真のメリットとしてこちらを考慮できていたらナルホドヨサソウ。と思いました。
    • コンウェイ・逆コンウェイの法則（ 逆コンウェイの方は、作戦とかと言い換える方が多いような気もしますが…。）の記載も本書中にありましたが、やっぱり組織構造とアーキテクチャというのは切っても切り離せない関係なのかなーと再認識しました（本当の本当に、マイクロサービスアーキテクチャを考えるうえではその通りだなと思っています）。
  • マイクロサービスアーキテクチャを使う時、個々の境界づけられたコンテキスト（DDD の bounded context）はサービス、またはサービスのグループになります
    • こちらは、マイクロサービスアーキテクチャと DDD の相性は非常に良いよねという文脈で記載されているものです。
    • この記載だと、境界づけられたコンテキストのグループが1つのサービスになるという風には読み取れないですかね…。しかし、組織の構造やその他のメリット・デメリットを整理したうえで境界づけられたコンテキストのグループを1つのモジュラーモノリスとして定義することは可能なのかな（むしろそうしておくべきタイミングは多々あるのではないか）。とも思いました！

Ch. 3 ~ 4 「マイクロサービス間通信について」

以降、だんだんとマイクロサービスアーキテクチャ特有の考慮事項に入っていきます。
こちらでは、マイクロサービス間での通信や、マイクロサービス間でのトランザクション処理について述べられています。

同期・非同期通信の使い分けや API のあり方、各種通信プロトコル、非同期処理のベストプラクティス etc… といった内容が幅広く紹介がされており、この辺はマイクロサービスアーキテクチャによらず重要な考え方だなと思いました。
また、マイクロサービス間におけるトランザクション処理も必ず悩まざるをえなくなるものの1つで、よく Saga といったものが挙げられますがこちらも非常にわかりやすくまとめられていました。

気になりトピックは以下になります。

  • 可用性をできるかぎりあげたいなら、同期通信をできるかぎり減らさなければなりません。（非同期通信を増やさなければなりません。）
    • 複数システムを利用する場合は、それらの可用性の積になるからね。といった文脈で述べられています。
    • 特にこれは、コマンド系のものに限定した話かとは思うのですが（もちろん参照系のものでは、非同期通信は有効な手段ではないため）。全てのリソースにおいてこちらの話を適用しようとするとなかなか壮大になりそうな気もしたので使い所はあるのかなとも思いました。
  • ごく単純なサーガを除き、オーケストレーションを使うことをお勧めします。
    • サーガにて、コレオグラフィベースとオーケストレーションベースどちらがよいかという文脈で述べられています。
    • こちらは確かにソウデスネー！ と思いました。上記の通り全てコマンド系のものは、オーケストレーションベースのサーガに則ってハンドリングするかと言われると悩ましいところではありますが…（ACID トランザクションのうち分離性を担保できないため、不必要に複雑さが増してしまう可能性がありそう？）
    • （ただ、一度マイクロサービス内でオーケストレータを飼える仕組みを整理できれば絶対できないことでもないのかなー？ とも思ったり？）

Ch. 5 ~ 8 「マイクロサービス特有の実装課題と解決について」

こちらでは、マイクロサービス特有の実装課題がいくつか紹介されていて、またそれらに対する解決方法も述べられていました。

ナルホドナーポイントがたくさんあるのですが、Chapter ごとに1つの記事が書けるくらいのボリュームがあるものなので、ここでは軽い紹介程度にとどめておきますがざっと以下のようなものについて述べられています。

  • マイクロサービスと DDD の相性の良さとは。アグリゲートや Domain event の関連・有効性。
  • マイクロサービスにおけるイベントソーシング。
  • マイクロサービスにおけるクエリーの実装（API composition。CQRS。API gateway）。

気になりトピックは以下になります。

  • 1つのトランザクションで1つのアグリゲートを作成または更新する。
    • こちらは、アグリゲートのルールということで3つ目のルールとして述べられていたものです。
    • 筆者もこちらには初めて読んだ時驚いたという記載がありましたが、私も ？？？ となりました。今まで開発してきたモノリスのものであっても、トランザクションの扱いには幾分悩まされましたので（そのような場合には、しっかりとデータ設計ができていない場合が多かったのもありますが）。、一考の余地はありそうかなと思いました。
  • API ゲートウェイの開発と運用を担当するかは重要な問題です。
    • こちらは、いわゆるマイクロサービスにおけるクエリーの実装部分で API gateway のオーナーシップについて述べられていたときの一節です。
    • API gateway には本書中に記載がありますが、普通いくつかの役割が含まれています。特にこの部分では、いわゆるプレゼンテーション的な役割に焦点をあてて述べられています。このプレゼンテーション的な役割は、どのチームが責任を持つようにするかは、きちんと最初に整理しておく必要があるかなーとも思いました（もちろん、その他の役割についてもそうですが）。
  • GraphQL を使った API ゲートウェイの実装
    • こちらは、API ゲートウェイを実装する際にはといった文脈で述べられています。
    • 最近？ だと、Appolo が、マイクロサービスの API gateway として活躍してくれる Appolo Federation や、 Apollo Router を開発してくれているのでそちらも取り入れるのも1つの手かもしれません。
    • ただ GraphQL が全てのマイクロサービス間通信にとってかわるものになるかと言うと、一概にそうとは言えないかなと個人的には思っています（そこまで本書中でも述べていたとも思っていないですが）。こちらもメリット・デメリットを整理したうえでの話となるかとは思いますが、適切な部分では適切な通信プロトコルを用いるのがよいのかなーと思っていたりします（ Production Ready GraphQL でも、そのような記載があった気がします）。

Ch. 9 ~ 10 「マイクロサービスのテストについて」

こちらでは、やや毛色が変わりテストの文脈に入っていきます。
はじめにテストとは？ ということが述べられており、段々とマイクロサービスにおいてはね。という流れで話が進んでいきます。

ユニットテストから始まり、統合テスト、コンポーネントテスト、エンドツーエンドテストという順序でテストに関しておおよそ網羅的に述べられていました。
それぞれのテストにおける得意な部分・不得意な部分に明示的に触れられていたのと、具体的にどのようにそれぞれのテストを記載するのがよいのかといったことが述べられていたので、テストに対する考え方が整理できるものになっていました。

気になりトピックは以下になります。

  • サービスの受け入れテストとしては、エンドツーエンドテストよりもコンポーネントテストのほうがはるかに優れています。
  • エンドツーエンドテストは、できる限り少なくするに越したことはありません。そのためには、ユーザージャーニーテストを書くようにするとよいでしょう。
    • これらは、エンドツーエンドテストの使いどころに関するところで述べられていたものになります。
    • マイクロサービスにおいて、いわゆるエンドツーエンドテストを行おうとすると、意外と考慮することが多く大変なイメージがあります。他のマイクロサービスに関しては、自身の管理下にないことが多いため（組織構造をもとに設計しているとなおのことかなと）。
    • ユーザージャーニーテストを普段から扱う（負荷試験等では扱うことが多かったですが）。というのはなかなか考えになかったので、ナルホドナーと思いました。

Ch. 11 ~ 12 「マイクロサービスの運用・保守について」

こちらでは、また毛色が変わりましてマイクロサービスの運用・保守等について述べられています。
マイクロサービスでは、デプロイはもちろんのこと監視といった部分も途端に複雑になっていきます。また、マイクロサービス間での認証や認可も考慮する必要が出てくるといったことはモノリスとの決定的な違いの1つですね。

監視の文脈で取り上げられていたものは、以下になります。

  • Health Check API
    • これはマイクロサービスに限った話でもないとは思いますが、いわゆる Health Check のためのエンドポイントを公開しておくというやつですね。
  • Log aggregation
    • マイクロサービスだと1つの不具合が複数のマイクロサービスにまたがっておきている場合がほとんどです。そのような場合に原因を突き止めるためのログはどのように管理しておけばよいのかというやつです。
  • Distributed tracing
    • Log aggregation と同様に、何かパフォーマンス的な課題を解決したいとなったときにどのようにトレースを管理しておけばよいのだろうかというやつです。
  • Exception tracking
    • イメージとしては Log aggregation のエラーレベル ver. といったものかなと。ただ、エラーログはその後の障害管理・追跡が困難なため、分けて述べられているようでした。
  • Application metrics
    • こちらもマイクロサービスに限った話ではないですが、各サービスでメトリクスを収集するためにはといったことが述べられています。
  • Audit logging
    • こちらも（略）ですが、ユーザーの動きをロギングしたやつですね。

特に、ログやトレースの管理というのはマイクロサービスならではのものになるので、しっかりと整理できていないといけないなと思いました。またこれらを実現するためにはということで、マイクロサービスシャシーやサービスメッシュも導入程度ではありますが述べられています。

デプロイ部分では、Google Cloud や AWS の具体的なサービスも取り入れて、どのように実現できるかが詳細に述べられていました。

やや発売日から日にちが経ってしまったこともあり、現在ではまた様々なサービスが新しく出て実現方法は色々と変わってきてはいそうですが、これらの考え方は決して無くなったわけではないので現在でも非常に有用な知識なのかなと思います。

Ch. 13 「モノリスからマイクロサービスへ」

こちらでは、モノリスからマイクロサービスへ移行していくにはといったことが述べられています。

こういった Chapter では、混み入ったものは出てこなそうだなーとも思ったのですが…。なかなか具体的にどのようにしてモノリスからマイクロサービスへ移行すればよいのかといったことが述べられていました。

基本的に、モノリスからマイクロサービスにダウンタイム無く移行したいといった場合には、既存のモノリスのシステムも動かしつつ、そこから段階的に新たなマイクロサービスのシステムへと移行するといった風なものが自然かなと思います。

そのような場合には、以下のようなことが悩みポイントとして出てくるはずです。これらを整理してくれているのがこちらの Chapter です。

  • そもそも移行作業をどのように価値として他チーム（主にビジネス領域のチーム）に訴求していくべきか。
  • そもそもどのようなアーキテクチャで2つのシステムを組み合わせるか。
  • 既存の認証・認可機構があった場合にはどのようにするべきか。
  • マイクロサービスアーキテクチャに移行する順序はどうするべきか。
  • マイクロサービスへの分割はどのような粒度で行うべきか。
  • モノリスとマイクロサービスでのトランザクションはどのように担保するべきか。
  • 新たなマイクロサービスに移行するうえでより適切なモデリングも行うとなった場合にそれらのモデルの変換はどのように行うか。

モノリスからマイクロサービスに移行しようと考えている場合には、こちらも必ず整理しておきたいものになりそうですね！

おわりに

マイクロサービスパターン MicroServicePatterns 実践的システムデザインのためのコード解説 の読書感想文でした。

マイクロサービスアーキテクチャとはなんぞや！ どうやって実現するんや！ といったことが本書を読めば一定は理解できるものかなと思っています。

アーキテクチャを検討するうえでは、同時にしっかりと組織（組織構成・既存メンバーの能力・採用 etc…）のことも一緒くたにして考えなくてはならないものなのカナーと思った次第でした！

またおそらくモノリスであったとしても、いわゆる外部サービス（メール送信や、Push 通知、何かに特化した別の Data Store etc…）。を使う際にも一部は導入できる考え方もあったりするのかなーとも思いましたので、まだまだマイクロサービスアーキテクチャを導入する予定もない。という方でも一読の価値はあるものかなと思ってます。

次は、藤戸さんの 図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書 です！ よろしくお願いいたします！