こんにちは、 虎の穴ラボのS.Sです。
最近のIT業界では、マイクロサービス化について話題になっていますが、そもそもマイクロサービス化にする利点や、実際にモノリシックなシステムをマイクロサービス化していくためにどうすれば良いか、その辺りを学ぶために「マイクロサービスパターン」を購読しましたので、今回はこちらの本の感想を書きたいと思います。
- 書籍情報
- 内容
- Chapter 1 モノリシック地獄からの脱出
- Chapter 2 サービスへの分割
- Chapter 3 マイクロサービスアーキテクチャで使われるプロセス間通信
- Chapter 4 サーガによるトランザクションの管理
- Chapter 5 マイクロサービスアーキテクチャにおけるビジネスロジックの設計
- Chapter 6 イベントソーシングを使ったビジネスロジックの開発
- Chapter 7 マイクロサービスアーキテクチャでのクエリーの実装
- Chapter 8 外部APIパターン
- Chapter 9〜10 マイクロサービスのテスト
- Chapter 11 本番環境に耐えられるサービスの開発
- Chapter 12 マイクロサービスのデプロイ
- Chapter 13 マイクロサービスのリファクタリング
- 感想
- P.S.
書籍情報
- タイトル:マイクロサービスパターン 〜実践的システムデザインのためのコード解説〜
- 著者:Chris Richardson(クリス・リチャードソン)
- 訳者:長尾高弘
- 監修者:橂澤広亨
- 出版社:インプレス
- 発行:2020年3月23日
内容
架空のオンラインフードデリバリー会社(FTGO)の古いWebアプリケーションを最新化するという設定の中で、マイクロサービスに関連する設計手法や技術、運用方法などが解説されています。
(※ちなみにFTGOのWebアプリケーションは、Java と Springフレームワークを使用している設定のため、本書のサンプルコードもJava と Springフレームワークを使用したものになっています。)
Chapter 1 モノリシック地獄からの脱出
FTGOのWebアプリケーションには、オーダ管理や配達管理などの複数の機能がモジュール化されたアーキテクチャになっているが、物理的には1個のJava WARファイルでパッケージ化されています。
そんなモノリシックも規模が小さいうちは、TomcatサーバーにWARファイルをコピーするだけでデプロイ出来たりと、開発がしやすい利点があります。
しかし、時が進むにつれ、システムとチームの規模が大きくなると、システムが複雑になり、開発者ひとりがシステム全体を完全に理解するのが不可能な状況になっていき、次第にメンテナンスが困難な状況に陥る。これがモノリシック地獄。そんなモノリシック地獄から脱却するために、FTGOのシスステムはマイクロサービス化に移行します。
ちなみに既存のサービスをマイクロサービス化するにあたり以下のメリットとデメリットがあります。
【メリット】
・個々のサービスが小さくメンテンスがしやすい
・サービスを個別にデプロイとスケーリングができる
・障害分離に優れている
・新しいテクノロジーも容易に採用が出来る
【デメリット】
・サービスの適切な分割方法を見るけるのが難しい
・複数のサービスに跨って使われる機能のデプロイには、サービス間で調整が必要なる
Chapter 2 サービスへの分割
既存のサービスをマイクロサービス化するデメリットのひとつに「サービスの適切な分割方法を見るけるのが難しい」が挙げられていますが、そのサービスの適切な分割方法について解説されています。
マイクロサービスというと名前からして、小さく細かく分割化しなければいけないイメージがありますが、分割化する上で、サービスのサイズはあまり重要ではありません。業務単位で分割したり、サブドメイン単位での分割するといいそうです。
Chapter 3 マイクロサービスアーキテクチャで使われるプロセス間通信
マイクロサービスに関する5つのプロセス間通信のパターンについて解説がされています。
まずは、クライアントのリクエストが1つのサービスだけによって処理される場合
・リクエスト&レスポンス
・非同期リクエスト&レスポンス
・ 一方的な通知
→ レスポンスを要さないクライアントからの一方的なリクエスト
次に、クライアントのリクエストが複数のサービスによって処理される場合
・ パブリッシュ&サブスクライブ
→ クライアントが通知メッセージを発行した後、メッセージを受け取ったサービスから順次処理する方式
・パブリッシュ&非同期レスポンス
→ クライアントが通知メッセージをパブリッシュ(発行)した後、レスポンスがあるまで一定時間待つ方式
マイクロサービスにておいて、APIのファースト設計は必須!まずは、インターフェース定義を書いてみて、レビュー&修正を加えてからサービスの実装を行うことで、クライアント側とサービス側の認識違いが減らせます。 また同期通信か非同期通信のどちらで通信を行うか設計時に選択をしますが、オススメは非同期によるメッセージング!同期的な通信は、送信先のサービスで障害発生していると、その後の後続の処理が止まり影響がシステム全体に及ぶが、非同期メッセージングで通信すると、エラーが発生しているサービスにメッセージを送ったとしても、後続の処理には影響しないため、サービスの障害がシステム全体に及ぼさないです。
Chapter 4 サーガによるトランザクションの管理
サーガ(Saga)とは、非同期メッセージングでコーディネートされた一連のローカルトランザクションのことを指します。
そんなSagaを使用したサービス間でデータの整合性を管理する方法が解説されています。
Chapter 5 マイクロサービスアーキテクチャにおけるビジネスロジックの設計
マイクロサービスにおけるビジネスロジックの設計について、大きく分けて2つのパターンで解説されています。
1. トランザクションスクリプトを使ったビスネス設計
→ リクエストタイプごとにひとつずつ手続型のトランザクションスクリプトを書き、トランザクションスクリプトのコレクションとしてビジネスロジックを構成する設計手法。オブジェクト指向の言語の機能はほとんど使用されないため、C言語など非オブジェクト指向の言語でかつ、単純なビジネスロジックの場合にオススメです。
2. ドメインモデルを使ったビスネス設計
→ 状態と動作をあわせ持つクラスによって構成されるオブジェクトモデルでビジネスロジックを構成する設計手法。この場合、ビジネスロジックは、小規模なクラスで構成するため、メンテナンスがしやすくなる。よほど単純なビジネスロジックを実装する以外は、基本的にはドメインモデルを使った設計がオススメとのことです。
Chapter 6 イベントソーシングを使ったビジネスロジックの開発
Chapter 5 で設計したビジネスロジックを実際に開発する方法が解説されています。
Chapter 7 マイクロサービスアーキテクチャでのクエリーの実装
マイクロサービスにおけるクエリーの実装について、2つのパターンで解説がされています。
1. API composition パターンを使ったクエリー
最も簡単な手法であり、可能であれば、こちらを使うべき。APIを介して複数のサービスのそれぞれにクエリーを送って得られたデータを結合する形でクエリーを実装する
【利点】
・ マイクロサービスでクエリー操作を実装するための方法としては、単純でわかりやすい
【欠点】
・オーバーヘッドが高くなる
・可用性が下がるリスクがある
・トランザクション処理で見られるようなデータ整合性がない
2. CORS(Command and Query Responsibility Segregation)パターンを使ったクエリー
上記よりも強力だが、実装も複雑。クエリーのサポートだけを目的とするビューデータベースを1つ以上管理する。
【利点】
・マイクロサービスで効率良いクエリーを実装できる
・多様なクエリーを効率よく実装できる
・イベントソーシングベースのアプリケーションでクエリーを可能にする
【欠点】
・アーキテクチャーが複雑になる
・レプリケーションのタイムラグへの対処が必要になる
Chapter 8 外部APIパターン
マイクロサービスにおけるAPIゲートウェイの設計・実装方法について解説がされています
APIゲートウェイにも利点と欠点があり、その上でAPIゲートウェイの設計・実装で気を付けなければいけない点が書かれています。
Chapter 9〜10 マイクロサービスのテスト
マイクロサービスにおける自動テストの開発方法について解説がされています。 Chapter 9では、まず単体テストの自動テストについて解説されています。Chapter 10は、前章の単体テストを元に、結合テストとコンポーネントテストの自動テストの開発について解説されています。
Chapter 11 本番環境に耐えられるサービスの開発
マイクロサービスにおける3つの品質属性から、本番環境に耐えられる品質について解説されています。
・各アプリケーションをセキュアにするためのセキュリティ
・DBなどの認証情報を保持するためのサービスの設定可能性
・監視のし易さを担保する可観測性
Chapter 12 マイクロサービスのデプロイ
仮想マシン、コンテナ、サーバーレスなどサービスのデプロイ方法について解説されています。 Kubernetesを使ったDockerコンテナのデプロイ方法と、サーバーレスではAWS Lambdaを使ったデプロイ方法が解説されています。
Chapter 13 マイクロサービスのリファクタリング
実際にモノリシックなアプリケーションをマイクロサービスに移行する方法が解説されています。
まずは、新機能のサービスの実装をマイクロサービス化していきます。その際の既存のサービスとの連携方法も解説されています。
感想
この本を読むまでは、マイクロサービス化と言っても何をどうすればいいのかイメージが付かない状況でしたが、 本のストーリーが架空のシステムを元にマイクロサービス化していく話の元で、マイクロサービス化するために必要なプロセスが全て解説されているので、すごくイメージが湧きやすいです。また設計、開発、テストと各プロセスごとにマイクロサービスに必要なことが解説されているため、マイクロサービスについて学ぶには、この一冊があれば十分かと思います。 モノリシックな一枚岩のシステムに悩みを抱えているエンジニアに、マイクロサービス化に踏み切るための判断材料として、この本を読むのをお勧めします!
P.S.
直近のイベント情報
■5月21日(金)19:30~ とらのあなラボエンジニア座談会Vol.8【なぜとらラボエンジニアはラジオを始めたのか】
を開催します!興味のある方はぜひご参加ください!
■5月26日(水)19:30~ とらのあなエンジニア&マーケター採用説明会+リモート懇親会
を開催します!オタク企業で自社開発に携わるということに興味があるという方は、お気軽にご参加ください!
yumenosora.connpass.com
■5月28日(金)19:30~ 【オンライン】オタクが最新技術を追うLTイベント#24【初心者歓迎】【テーマフリー】 を開催します!こちらは発表者も募集中ですので、LT初心者という方でもぜひご応募ください!
採用情報
■募集職種
yumenosora.co.jp
カジュアル面談も随時開催中です
■お申し込みはこちら!
yumenosora.connpass.com
■ToraLab.fmスタートしました!
メンバーによるPodcastを配信中!
是非スキマ時間に聞いて頂けると嬉しいです。
anchor.fm
■Twitterもフォローしてくださいね!
ツイッターでも随時情報発信をしています
twitter.com