SHARE

目次

目次

SHARE

ソフトウェア設計とメンテナンス

「マイクロサービスアーキテクチャ第2版:メリット、デメリット、実装テクノロジーを徹底解説」佐藤 直生

microservices-architecture-2-new-img
この記事は 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冊ほど手がけています。

「マイクロサービスアーキテクチャ 第2版」の構成

第1版、第2版の構成を比べてみると、大きなカバレッジはそこまで変化はなく、どちらかといえば、より広がりをみせた印象です。本書は全16章からなる600ページ超えの超大作です。そのため今回は「第1部 基礎」の中から「1章 マイクロサービスとは」を取り上げ解説します。

マイクロサービス第2版

「1章 マイクロサービスとは」の目次

マイクロサービス第2版

    1章 マイクロサービスとは

    マイクロサービスとは、コミュニティから生まれたアーキテクチャスタイルの “概念” のため、定義は1つではありませんが、基本的にはビジネスドメインを中心にモデル化された独立してリリース可能なサービスのことを指します。ここでいう「サービス」とは何かしらの機能をカプセル化し、ネットワーク経由で他のサービスからアクセス可能なものです。分かりやすい例では、在庫管理、注文管理、商品発送などを表すドメインをもとに分割されたマイクロサービス群が複数システムに分散して存在していて、それら全体が一つのECシステムを構成するようなイメージです。

    マイクロサービス第2版

    マイクロサービスの重要な概念はこのあたりです。

    1. 独立デプロイ可能性
    2. ビジネスドメインに基づくモデル化
    3. マイクロサービスごとの状態の所有
    4. サイズ
    5. 柔軟性
    6. アーキテクチャと組織の連携(チームトポロジーで紹介され広まったストリームアラインドチーム

    ストリームアラインドチーム:これは主なビジネス的な変更フロー、ストリームに沿って配置されるチームですね。一番中心的なチームタイプで、数が多いのもこのチームタイプです。残りの3種類のチームタイプは全てこのチームの負荷を減らすために存在しています。

    引用元:Team Topologies Study 30分で分かった気になるチームトポロジー

    モノリスとマイクロサービスを比較

    マイクロサービス化を検討するうえで、当然モノリスと比較するでしょう。モノリスをやめて、あえてマイクロサービスを選ぶ理由はなんでしょうか。最も大きな理由は「デリバリ競合の起きやすさ」にあります。マイクロサービスであれば独立してデプロイできるわけですから、競合の細かい議論はあれど、基本的にはデリバリ競合が起きません。

    マイクロサービス第2版

    モノリスかマイクロサービスかを選ぶ際は、当然ながらモノリスの知見が必要になります。そこで本書は、モノリスのパターンについても紹介しています。

    1. 単一プロセスモノリス
    2. モジュラーモノリス
    3. 分散モノリス

    マイクロサービス実現に必要な4つのテクノロジー

    では実際にマイクロサービスを作るためには、どのようなテクノロジーが必要なのでしょうか。ここでは4つの方法を紹介します。

    1)ログ集約と分散トレーシング

    まずはオブザーバビリティ(可観測性)です。当然、プロセスが分散するので、ログやメトリック(メトリクス)をどのように集約するのかなどの課題が出てきます。こういったところも、OpenTelemetryのような標準技術や、そこを支えるクラウドサービス、またオープンソース実装などもいろいろと出てきています。

    2)コンテナとKubernetes

    以前からコンテナの概念はありますが、つい最近まで Docker ベースのコンテナが一世を風靡していましたね。その後 Docker社 はいろいろありましたが、いずれにせよ物理マシン、仮想マシン(VM)という世界から一歩進んでアプリケーション開発の世界ではコンテナがメインストリームになりました。そのなかでも Kubernetes は、巨大なエコシステムの後押しもあり、今では完全にメインストリームになってきています。このあたりは第1版の時代から大きく変化している部分ですね。

    3)ストリーミング(Kafkaなど)

    大規模な巨大な数のイベント:メッセージをストリームして配信する基盤です。

    4)パブリッククラウドとサーバレス

    マイクロサービスアーキテクチャ 第2版」で大きくフォーカスした部分はサーバーレスの中でも特にFaaS(代表的なものだと AWS Lambda、Azure Functions、Google Cloud Functions など)です。比較的小規模で単機能のコードをクラウドにデプロイして、イベントドリブンな形でコードを動かします。このあたりも第1版の時代に比べると、市民権を得てきています。

    マイクロサービス 6つのメリット

    マイクロサービス第2版

    マイクロサービスのメリットは、大きく6つほどあげられます。今回はその中から3つを解説します。

    1. 技術の異種性(ヘテロジニアス)
    2. 堅牢性(バルクヘッド)
    3. スケーリング
    4. デプロイの容易性
    5. 組織との連携
    6. 合成可能性

    技術の異種性(ヘテロジニアス)

    マイクロサービスは完全に独立しているので、サービスごとにアプリケーション言語やフレームワーク、ストレージなどを自由に選べるというところがモノリスには無い大きなメリットです。

    堅牢性(バルクヘッド)

    本書でも「バルクヘッド パターン」として紹介していますが、基本的にはマイクロサービスごとに様々な分離を持たせることで、特定のサービスが落ちても別のサービスに影響を与えない構成を指します。

    スケーリング

    モノリスの場合はモノリス全体をスケールアップもしくはスケールアウトしますが、マイクロサービスは、サービス単位でスケールできます。非常に負荷が高いサービスだけをスケールさせて処理することで、他の部分は低いキャパシティで動かすことができます。

    マイクロサービスには、課題もある

    マイクロサービスにはメリットだけでなく、デメリット・課題も存在します。

    開発者体験(デベロッパーエクスペリエンス)

    ローカルでコードを書いてテストをしてというサイクルを、どれだけ高速で回せるかという観点では、容易に想像できるように課題があります。

    技術の過負荷

    色々な技術を使えるからといって異なる技術を使いすぎると、学習コストは上がりますし、別のチームに移ってしまえば過去のスキルが全く再利用できないといったことも考えられます。よほどの理由がない限りは、会社が定めた標準的な言語を使用する方がいいでしょう。

    コスト

    モノリスに比べ動かすものが増えるため、運用管理の難易度も上がります。モノリスに比べると、当然コストは高くなるでしょう。

    レポート

    サービスと各サービスが使うデータベースが分散しているので、レポーティングのためのデータの集約が面倒になります。

    監視とトラブルシューティング

    分散システムなので、どこでトラブルが起きて何が原因なのか把握することが困難になります。オブザーバビリティツールも進化しているので、うまく活用して回避したいところです。

    セキュリティ

    基本的には自分のシステムが動いている(プライベートネットワークの中)とはいえ、認証をどうするかも含めて、モノリスに比べ難易度は上がります。

    テスト

    テストは難しいですね。特に end-to-end で、マルチステップの処理をどうテストするのかが課題です。またレイテンシーの問題もあります。

    データ一貫性

    いわゆる「ACID トランザクション」を実現するのは大変です。

    マイクロサービスを使うべきか

    「結局、マイクロサービスって使った方がいいの?」と思われるでしょう。しかし一概に答えを出すことはできません。会社の規模や状況に応じて導入を検討すべきです。

    マイクロサービスを導入しない方が良い例

    • 新しいプロダクトをゼロから作っているタイミング
    • スタートアップ
    • 顧客がデプロイや管理するソフトウェアを開発する組織

    上記に当てはまる場合、システム要件がふわっとしている可能性が高いはずです。ドメイン分析してマイクロサービス化したところで、1ヶ月後にはそのドメインが変わっているなんてことも普通に起こり得ます。やはり最初はモノリスで作り、あとからマイクロサービス化していく方が好ましいでしょう。

    マイクロサービスを導入した方が良い例

    • 急成長している100人規模の企業
    • SaaSアプリケーション
    • さまざまな新規チャネルで顧客にサービス提供を目指す組織

    反対にある程度の大きな組織になれば、システムの方向性もドメインも安定化してくるはずです。モノリスで同時並行進めるには非効率的なので、ある程度、サービスごとに分けて作っていく方が良いといえるのかも知れません。

    「1章 マイクロサービスとは」まとめ

    • マイクロサービスは技術選択、堅牢性/スケーリング、チーム編成などに非常に高い柔軟性を与える
    • 大きな複雑さも伴うので、 使用が正当化する必要がある
    • 正しく理解・実装すると、強力で生産性の高いアーキテクチャを構築するのに役立つ

    2章〜16章:詳しくは動画をご覧ください

    「マイクロサービスアーキテクチャ 第2版」まとめ

    • 本書は、マイクロサービスが適しているかを判断するための情報、経験を共有
    • マイクロサービスを目標ではなく、漸進的に進む旅
    • システムを分解し、進みながら学ぼう
    • システムを継続的に進化させるための規律が重要
    • 変化を受け入れましょう
    • 「マイクロサービスアーキテクチャ 第2版」を購入しましょう

    関連リリース情報

    マイクロサービス第2版

    O’Reilly Japan

    Azure Architecture Center / Microsoft

    Microsoft

    Forkwellキャリア相談

    フォークウェルプレス編集部

    Follow

    記事一覧へ

    本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

    佐藤 直生
    佐藤 直生
    Microsoft Corporation

    ソフトウェアエンジニア

    Senior Software Engineer, Microsoft Corporation / 『マイクロサービスアーキテクチャ』監修。日本オラクル株式会社における、Java EEアプリケーションサーバやミドルウェアのテクノロジーエバンジェリストとしての経験を経て、Microsoft Corporationで、パブリッククラウドプラットフォーム「Microsoft Azure」のエバンジェリスト、ソリューションアーキテクトなどを歴任し、現在はソフトウェアエンジニアとして活動。