ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■ソフトウェア設計とメンテナンス
2023.03.30 2024.03.05 約4分
| この記事は 2022年12月発売 『マイクロサービスアーキテクチャ 第2版』監修 佐藤 直生 氏による connpass勉強会 を再編集し、記事化したものです。 |
2014年にThoughtWorks社のマーチン・ファウラーとジェームス・ルイスが提唱したソフトウェア開発手法の1つで、モノリシック（一枚岩）なアーキテクチャを、ビジネス機能に沿って複数の小さい「マイクロサービス」に分割し、それらを連携させるアーキテクチャにすることで、迅速なデプロイ、優れた回復性やスケーラビリティといった利点を実現しようとするものです。
2016年には、O’Reilly Japanから「マイクロサービスアーキテクチャ」が出版され、今後普及が期待されるマイクロサービスについて深く理解できる一冊として好評を博しました。
そんなマイクロサービスは、いまではすっかり市民権を得て、さまざまな手法やツールが開発されています。2022年12月には600ページを超える超大作となってアップデートされた「マイクロサービスアーキテクチャ 第2版」が出版。そこで本セッションでは、マイクロサービスに「賛成」でも「反対」でもないという中立的な立場から、マイクロサービスの仕組み、特徴、長所、短所、課題を丁寧に説明しています。
 |
マイクロサービスの原典とも言える書籍の待望の改訂版！
2016年に第1版が発刊された当時とは異なり、いまではマイクロサービスはすっかり市民権を得、さまざまな技法やツールが開発されています。この改訂版では、マイクロサービスの発展に伴い、重要となっている面を掘り下げ、また事例を豊富に盛り込むなど、時代に沿った改訂を行っています。第2版では「第1部 基礎」「第2部 実装」「第3部 人」の3部構成を取り、チームの構造、組織、UIといった異なる視点から考察していることも特徴です。この一冊でマイクロサービスを構築、管理、運用、拡張する内容をカバーしています。 |
佐藤 直生です。日本オラクル、マイクロソフトなどを経て、ここ3年ほどはソフトウェアエンジニアとして活動する傍ら、付き合いの長いオライリーさんの書籍の監訳・翻訳・執筆などを18冊ほど手がけています。
第1版、第2版の構成を比べてみると、大きなカバレッジはそこまで変化はなく、どちらかといえば、より広がりをみせた印象です。本書は全16章からなる600ページ超えの超大作です。そのため今回は「第1部 基礎」の中から「1章 マイクロサービスとは」を取り上げ解説します。
マイクロサービスとは、コミュニティから生まれたアーキテクチャスタイルの “概念” のため、定義は1つではありませんが、基本的にはビジネスドメインを中心にモデル化された独立してリリース可能なサービスのことを指します。ここでいう「サービス」とは何かしらの機能をカプセル化し、ネットワーク経由で他のサービスからアクセス可能なものです。分かりやすい例では、在庫管理、注文管理、商品発送などを表すドメインをもとに分割されたマイクロサービス群が複数システムに分散して存在していて、それら全体が一つのECシステムを構成するようなイメージです。
マイクロサービスの重要な概念はこのあたりです。
ストリームアラインドチーム：これは主なビジネス的な変更フロー、ストリームに沿って配置されるチームですね。一番中心的なチームタイプで、数が多いのもこのチームタイプです。残りの3種類のチームタイプは全てこのチームの負荷を減らすために存在しています。
引用元：Team Topologies Study 30分で分かった気になるチームトポロジー
マイクロサービス化を検討するうえで、当然モノリスと比較するでしょう。モノリスをやめて、あえてマイクロサービスを選ぶ理由はなんでしょうか。最も大きな理由は「デリバリ競合の起きやすさ」にあります。マイクロサービスであれば独立してデプロイできるわけですから、競合の細かい議論はあれど、基本的にはデリバリ競合が起きません。
モノリスかマイクロサービスかを選ぶ際は、当然ながらモノリスの知見が必要になります。そこで本書は、モノリスのパターンについても紹介しています。
では実際にマイクロサービスを作るためには、どのようなテクノロジーが必要なのでしょうか。ここでは4つの方法を紹介します。
まずはオブザーバビリティ（可観測性）です。当然、プロセスが分散するので、ログやメトリック（メトリクス）をどのように集約するのかなどの課題が出てきます。こういったところも、OpenTelemetryのような標準技術や、そこを支えるクラウドサービス、またオープンソース実装などもいろいろと出てきています。
以前からコンテナの概念はありますが、つい最近まで Docker ベースのコンテナが一世を風靡していましたね。その後 Docker社 はいろいろありましたが、いずれにせよ物理マシン、仮想マシン（VM）という世界から一歩進んでアプリケーション開発の世界ではコンテナがメインストリームになりました。そのなかでも Kubernetes は、巨大なエコシステムの後押しもあり、今では完全にメインストリームになってきています。このあたりは第1版の時代から大きく変化している部分ですね。
大規模な巨大な数のイベント：メッセージをストリームして配信する基盤です。
「マイクロサービスアーキテクチャ 第2版」で大きくフォーカスした部分はサーバーレスの中でも特にFaaS（代表的なものだと AWS Lambda、Azure Functions、Google Cloud Functions など）です。比較的小規模で単機能のコードをクラウドにデプロイして、イベントドリブンな形でコードを動かします。このあたりも第1版の時代に比べると、市民権を得てきています。
マイクロサービスのメリットは、大きく6つほどあげられます。今回はその中から3つを解説します。
マイクロサービスは完全に独立しているので、サービスごとにアプリケーション言語やフレームワーク、ストレージなどを自由に選べるというところがモノリスには無い大きなメリットです。
本書でも「バルクヘッド パターン」として紹介していますが、基本的にはマイクロサービスごとに様々な分離を持たせることで、特定のサービスが落ちても別のサービスに影響を与えない構成を指します。
モノリスの場合はモノリス全体をスケールアップもしくはスケールアウトしますが、マイクロサービスは、サービス単位でスケールできます。非常に負荷が高いサービスだけをスケールさせて処理することで、他の部分は低いキャパシティで動かすことができます。
マイクロサービスにはメリットだけでなく、デメリット・課題も存在します。
ローカルでコードを書いてテストをしてというサイクルを、どれだけ高速で回せるかという観点では、容易に想像できるように課題があります。
色々な技術を使えるからといって異なる技術を使いすぎると、学習コストは上がりますし、別のチームに移ってしまえば過去のスキルが全く再利用できないといったことも考えられます。よほどの理由がない限りは、会社が定めた標準的な言語を使用する方がいいでしょう。
モノリスに比べ動かすものが増えるため、運用管理の難易度も上がります。モノリスに比べると、当然コストは高くなるでしょう。
サービスと各サービスが使うデータベースが分散しているので、レポーティングのためのデータの集約が面倒になります。
分散システムなので、どこでトラブルが起きて何が原因なのか把握することが困難になります。オブザーバビリティツールも進化しているので、うまく活用して回避したいところです。
基本的には自分のシステムが動いている（プライベートネットワークの中）とはいえ、認証をどうするかも含めて、モノリスに比べ難易度は上がります。
テストは難しいですね。特に end-to-end で、マルチステップの処理をどうテストするのかが課題です。またレイテンシーの問題もあります。
いわゆる「ACID トランザクション」を実現するのは大変です。
「結局、マイクロサービスって使った方がいいの？」と思われるでしょう。しかし一概に答えを出すことはできません。会社の規模や状況に応じて導入を検討すべきです。
マイクロサービスを導入しない方が良い例
|
上記に当てはまる場合、システム要件がふわっとしている可能性が高いはずです。ドメイン分析してマイクロサービス化したところで、1ヶ月後にはそのドメインが変わっているなんてことも普通に起こり得ます。やはり最初はモノリスで作り、あとからマイクロサービス化していく方が好ましいでしょう。
マイクロサービスを導入した方が良い例
|
反対にある程度の大きな組織になれば、システムの方向性もドメインも安定化してくるはずです。モノリスで同時並行進めるには非効率的なので、ある程度、サービスごとに分けて作っていく方が良いといえるのかも知れません。
O’Reilly Japan
Azure Architecture Center / Microsoft
Microsoft
ソフトウェアエンジニア
Senior Software Engineer, Microsoft Corporation / 『マイクロサービスアーキテクチャ』監修。日本オラクル株式会社における、Java EEアプリケーションサーバやミドルウェアのテクノロジーエバンジェリストとしての経験を経て、Microsoft Corporationで、パブリッククラウドプラットフォーム「Microsoft Azure」のエバンジェリスト、ソリューションアーキテクトなどを歴任し、現在はソフトウェアエンジニアとして活動。
