はじめに
マイクロサービス
IT業界にいる人間なら一度は聞いたことがある単語だと思います。
一般的にモダンと言われているシステム開発において、積極的に使われているアーキテクチャ（設計や構造）です。
概念自体はそこまで難しくないので簡単に説明していきたいと思います。
マイクロサービスとは
マイクロサービスとは、小さな独立した複数のサービスでソフトウェアを構成することを指します。
サービスとは
何かしらの機能を実現する単独動作、単独デプロイ/リリースできるコンポーネント
※データも分割対象
今までのシステム開発では、通常大きなシステムは一つの大きなプログラムとして作成されていました。
各機能は別の機能を直接呼び出すことが可能ですし、データは単一のデータベースで管理されており、システム内のすべての機能が同じデータベースにアクセスできます。
この構造をモノリシックアーキテクチャ（モノリシックシステム）と言います。
モノリシック 【monolithic】
モノリシックとは、一枚岩の、頑丈な、巨大な、などの意味を持つ英単語。組織や機器、システムなどの構造について、要素に分割されておらず全体が一体になっている様子を表す。
IT用語辞典 e-Words
マイクロサービスアーキテクチャではその大きなプログラムを小さな部品に分けて独立して動作するシステムとして構築します。
各機能は別の機能を直接呼び出すことが出来ず、各サービスは独自のデータベースを持ち、サービスを超えてデータベースのアクセスはできません。
図にすると下記のようなイメージです。
図のモノリシックアーキテクチャでは、「通販システム」という一つの大きなシステムの中にユーザ管理機能や注文管理機能といった各機能が含まれています。
対してマイクロサービスアーキテクチャでは、各機能が独立した小さなシステム（サービス）になっています。
機能とそれに紐付くデータがそれぞれ別サービスとして独立しているため、下記の図のようにそれらのサービス間で情報のやり取りをする必要が出てきます。
モノリシックシステムのように別機能のデータを直接参照したり、処理を直接呼び出すことが出来ないため、マイクロサービスではAPIを用いてシステム間の連携を行います。
図中の情報取得や更新のリクエストはすべてAPI通信を指しています。
この章のまとめ
■モノリシックアーキテクチャ
・大きくて様々な機能を持っているシステム
・単一のデータベース（システム内のすべての機能が同じデータベースにアクセスできる）
・別機能の処理を直接呼び出せる
■マイクロサービスアーキテクチャ
・小さい機能がそれぞれ独立したシステムになっているシステム群
・独自のデータベース（サービスを超えてデータベースのアクセスはできない）
・別機能の処理はAPIを用いて呼び出す
マイクロサービスのメリット
マイクロサービス化することで何が嬉しいのか。
近年トレンドになっている技術なので、それ相応のメリットがあると言われています。
柔軟性とスケーラビリティ
マイクロサービスは小さなサービス単位で機能を分割しているため、特定のサービスのみを変更・拡張することができます。
また、システム全体を変更せずに新機能を追加したり、負荷が高まった場合に必要なサービスのみをスケールアップできます。
例えば、オンラインストアのシステムで、ユーザ管理、注文管理、在庫管理などの機能があったとします。
クリスマスのある12月には注文が急増するため、需要の高い注文管理サービスが突出して高負荷になります。モノリシックシステムでは高負荷に耐えるため、大きなシステム全体のスケールアップが必要になってしまいます。
マイクロサービスを使用すると、高負荷になっているサービスのみを迅速にスケールアップさせることができます。注文管理サービスだけをスケールアップさせることで、無駄なくサービス全体のパフォーマンスを維持することができます。
独立した開発とデプロイ
マイクロサービスは個別のサービスとして開発・デプロイされるため、開発チームが各サービスを独立して開発できます。
これにより、開発者は自身の担当範囲に特化し、スピードや効率が向上します。
また、各サービスは独立してデプロイ可能なので、一部の変更が他のサービスに影響を与えることが少なくなります。
例えば、オンラインストアのシステムで、問い合わせ機能のサービスに修正があるとします。
モノリシックシステムではリリース時にオンラインストアのシステムすべてを停止する必要があります。
マイクロサービスでは各機能が独立しているため、問い合わせ機能のみ停止して他のサービスを継続して使用させることができます。
技術的な自由
マイクロサービスでは、各サービスごとに最適な言語や開発ツールを選択できます。
これにより、各サービスの要件やニーズに最適な技術を活用し、柔軟性やパフォーマンスの向上が可能となります。
例えば、オンラインストアのシステムで、レコメンド機能のサービスを追加するとします。
他サービスはJavaを使用して開発していますが、レコメンド機能はAIを使用して機械学習によってユーザーの購入履歴やアクセス履歴を学習することで、「ユーザーひとりひとりに最適な商品の紹介」を行う予定です。
そのため、「レコメンド機能の開発では、機械学習などのAI開発にはなくてはならないライブラリが多く用意されているPythonを選択する」といった柔軟な選択が可能になります。
高い可用性と耐障害性
モノリシックシステムでは、1つの機能に障害が発生すると、アプリケーション全体に障害が及ぶおそれがあります。
マイクロサービスでは、各サービスが独立しているため、一つのサービスの障害が他のサービスに影響を与えることが少ないです。
そのため、システム全体の可用性（システムが継続して稼働できる能力）が向上します。
この章のまとめ
マイクロサービスのメリット
■柔軟性とスケーラビリティ
・特定のサービスのみを変更・拡張することが可能
・負荷が高まった場合に必要なサービスのみのスケールアップが可能
■独立した開発とデプロイ
・開発チームが各サービスを独立して開発可能
・一部の変更が他のサービスに影響を与えることが少ない
■技術的な自由
・各サービスごとに最適な言語や開発ツールを選択可能
■高い可用性と耐障害性
・一つのサービスの障害が他のサービスに影響を与えることが少なく、
システム全体の可用性が向上する
マイクロサービスのデメリット
マイクロサービスにはメリットがいくつもありました。
では、マイクロサービスがシステム開発における銀の弾丸（解決が困難な諸問題を一撃で解決するような万能な解決策）になるかと言うとそうではないようです。
Amazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）では、相当の規模でなければマイクロサービスやサーバレスは現実にはシステムを不必要に複雑にするものだと警告しています。
具体的にどのようなデメリットがあるのかを紹介します。
サービスの適切な分割範囲
サービスを適切に分割するためには、ビジネスの機能と境界を把握する必要があります。
適切な分割ができないと、サービス間の関連性や依存関係が複雑化し、システム全体の理解や変更の容易性が低下します。
どこまで分割すればいいという明確な「解」を出すことは困難です。
システムの複雑性
マイクロサービスでは、システムが複数の小さなサービスに分割されているため、サービス間の通信やデータ整合性の管理など、モノリシックシステムでは存在しなかった複雑性が生じます。
サービスの数が増えると、システム全体の把握やトラブルシューティングが難しくなる場合があります。
分散システムの管理
マイクロサービスは独立してデプロイされるため、複数のサービスが分散して存在します。
そのため、サービスの監視、管理、デプロイの調整など、分散システム全体の管理が必要となります。
これには適切な管理ツールの導入や管理手順の整理が必要であり、運用コストが増える可能性があります。
サービス間通信のオーバーヘッド
マイクロサービスはAPI通信を使用してサービス間の連携を行います。
サービス間の通信はオーバーヘッドを引き起こす可能性があります。
特に、大量のサービス間通信が必要な場合や、大きなデータの通信がある場合、同期的な呼び出しが多い場合にはパフォーマンスの問題が生じることがあります。
さきほど紹介したAmazon Prime Videoの技術部門の記事でも、サービス間の画像データ受け渡しがコスト増の要因になったと書かれています。
分散トランザクションの複雑性
マイクロサービスは各々が独立してデータを管理するため、分散トランザクションの処理が複雑化します。
複数のサービスでトランザクションを制御する必要がある場合、データ整合性やロールバックの処理が困難になることがあります。
セッション管理の複雑性
通常、モノリシックなアプリケーションではセッション情報をサーバー側に保存し、セッションIDをクライアントにクッキーやトークンとして送信します。
しかし、マイクロサービスでは各サービスが独立して運用されるため、異なるサービス間でセッション情報を共有する必要が生じます。
サービス間でセッション情報を共有するためのセッションストアを用意するなどして、今までとは異なるセッション管理が必要になります。
開発・テストの困難さ
マイクロサービスでは、複数のサービスが連携してシステムを構成しているため、開発やテスト時にはそれらのサービスを組み合わせて動作させる必要があります。
そのため、開発環境やテスト環境のセットアップやデバッグがより複雑になる可能性があります。
この章のまとめ
マイクロサービスのデメリット
■サービスの適切な分割範囲
・サービスの適切な分割範囲を決定することは困難
・適切な分割ができないと、サービス間の関連性や依存関係が複雑化する
■システムの複雑性
・サービス間の通信やデータ整合性の管理が複雑になる
・サービスの数が増えると、システム全体の把握やトラブルシューティングが難しくなる
■分散システムの管理
・分散して存在しているサービスの監視、管理、デプロイの調整などが必要
・適切な管理ツールの導入や管理手順の整理が必要であり、運用コストが増える可能性がある
■サービス間通信のオーバーヘッド
・各サービス間の通信はネットワークオーバーヘッドを引き起こす可能性がある
・大量のサービス間通信が必要な場合や、大きなデータの通信がある場合、
同期的な呼び出しが多い場合にはパフォーマンスの問題が生じる可能性がある
■分散トランザクションの複雑性
・複数のサービスでトランザクションを制御する必要がある場合、
データ整合性やロールバックの処理が困難になる
■セッション管理の複雑性
・サーバー側に保存する従来のセッションが使用できない
・異なるサービス間でセッション情報を共有する仕組みの導入が必要
■開発・テストの困難さ
・開発やテスト時にはサービスを組み合わせて動作させる必要があるため、
テスト環境のセットアップやデバッグが複雑になる
マイクロサービスの注目度
独立行政法人情報処理推進機構（IPA）が公開したDX白書2023を見てみると、日本においてマイクロサービスを活用している、または活用を検討しているの合計値が3割を超えています。
一方のアメリカでは、マイクロサービスを活用している、または活用を検討しているの合計値が7割を超えています。
上記の結果からも、マイクロサービスの注目度はかなり高いことがわかります。
この章のまとめ
アメリカ人はマイクロサービスが好き
さいごに
マイクロサービスは現代のソフトウェア開発において非常に注目されているアーキテクチャの一つです。
デメリットもそれ相応にあるので、それを充分に理解して設計する必要がありますが、マイクロサービスが適している業務であれば、その柔軟性、拡張性、効率性は、多くの組織や開発者にとって魅力的な解決策となると思います。
最近よく聞くけど今さら聞けない技術用語について、いくつか記事を書いています。
良かったらそちらもご覧ください。
参考