エンジニア全般
「マイクロサービスアーキテクチャ」という構成方法を聞いたことがあるでしょうか。
筆者は開発者ですが、初めて「マイクロサービス」と聞いたときはイメージが全く湧きませんでした。
この記事では、マイクロサービスアーキテクチャについて、基本的な考え方、メリット、デメリット、導入事例から付随する技術やマイクロサービスの設計法について、網羅して解説します。
小中規模プロジェクトを中心にSEやコンサルとして活動。クラウド導入やスタートアップ、新規事業開拓の支援も経験しました。
マイクロサービスアーキテクチャとは？
マイクロサービスアーキテクチャとはソフトウェアの構成技法の一つで、ソフトウェアを小さな（マイクロな）サービスの集合体として構成する技法のことです。
アーキテクチャとはこの場合「構成」という意味で使われています。
最初に提唱されたのは2013年と、ソフトウェアの歴史では比較的新しい技法です。
従来のソフトウェアは、モノリス（正確にはモノリシックアーキテクチャ）という技法で構成されていました。
IT技術の進化に伴いモノリスでは限界が生じ、マイクロサービスアーキテクチャは考案されました。
現在では、特に大規模なシステムを中心として、マイクロサービスアーキテクチャを導入する企業が増えています。
全面的にマイクロサービスアーキテクチャとはいかなくても、部分的に採用することが一般的です。
モノリスとマイクロサービスの違い
さて、では、マイクロサービスとモノリスはどのように違うのでしょうか。実は根本的に違うのですが、ソフトウェア内部の話なのでなかなか分かりにくいですよね。
まず、マイクロサービスとモノリスの違いについて比較します。
| 特徴 | モノリス | マイクロサービス |
| アーキテクチャ | 単一の大きなアプリケーション | 小さな独立したサービスの集合 |
| 開発 | 一つのコードベースで開発 | 各サービスが独立して開発可能 |
| デプロイ | アプリケーション全体をデプロイ | 個別のサービスごとにデプロイ可能 |
| スケーリング | アプリケーション全体をスケール | 必要なサービスのみをスケール可能 |
| 技術スタック | 通常は単一の技術スタックを使用 | サービスごとに異なる技術を選択可能 |
| データ管理 | 中央集中型のデータベース | サービスごとに独立したデータストア |
| 障害の影響 | 1箇所の障害がシステム全体に影響 | 障害の影響は特定のサービスに限定される |
| 開発チーム | 大きな単一チームで開発 | 小さなチームがサービスごとに担当 |
| 通信 | 主に内部関数呼び出し | API経由の通信（HTTP/RPCなど） |
| 複雑性 | 単純な構造だが大規模になると複雑化 | 個々のサービスは単純だが全体の管理は複雑 |
モノリスは、ソフトウェア全体を1つの（モノリシックな）サービスとして構成する技法です。
Webシステムは、入力を受け付けて、サーバーで処理して、ブラウザに結果を返して表示する、ここまでが一つの流れです。
例えば、モノリスではサーバーで処理する部分が一つの大きなプログラムになります。
Webシステムとして複雑になると、サーバーの処理も複雑になります。そこが1つの大きな塊としてあると、以下のような問題が発生します。
- 一ヵ所で障害が起きると全体が止まる
- 大きな塊なのでプログラムが大変複雑なものになっていき、メンテナンスしにくくなる
こういった問題を解決するために、「互いに独立して動作するプログラムを小さな単位に分割し、協調して全体としての結果を出すように構成しましょう」という構成技法がマイクロサービスなのです。
マイクロサービスアーキテクチャの技術と構成要素
マイクロサービスアーキテクチャの技術と構成要素について、サービス設計、開発、デプロイ、運用、データ管理の観点から説明します。
サービス設計
サービス設計では、単一責任の原則に基づき、各サービスが特定の機能や業務ドメインに焦点を当てることが重要です。
RESTful APIやgRPCなどを用いて明確なインターフェースを定義し、ドメイン駆動設計（DDD）の考え方を取り入れてビジネスロジックを適切に分割します。
また、イベント駆動アーキテクチャを採用することで、サービス間の疎結合性を高めることができます。
サービス開発
サービス開発においては、各サービスに最適な言語やフレームワークを選択できる柔軟性があります。
例えば、Java/Spring、Node.js/Express、Python/Flaskなどから選択できます。開発環境の標準化にはDockerなどのコンテナ技術が活用され、テスト駆動開発（TDD）によって品質を担保します。
また、継続的インテグレーションと継続的デリバリー（CI/CD）のプラクティスを導入し、迅速かつ安全なデプロイを実現します。
サービスデプロイ
サービスデプロイでは、Kubernetesのようなコンテナオーケストレーションツールを使用して、コンテナのデプロイと管理を自動化します。
AWS LambdaやGoogle Cloud Functionsなどのサーバーレス技術も選択肢の一つです。
Blue-Greenデプロイメントやカナリアリリースといった戦略を採用することで、ダウンタイムの最小化やリスク管理を行います。
サービス運用
サービス運用面では、PrometheusやGrafanaなどのツールを使用してサービスの健全性を監視し、ELK Stack（Elasticsearch、Logstash、Kibana）でログを集中管理します。
JaegerやZipkinといった分散トレーシングツールを導入し、サービス間の呼び出しを追跡します。
さらに、IstioやLinkerdなどのサービスメッシュを活用して、サービス間通信の制御と監視を行うこともマイクロサービスの特徴です。
データ管理
データ管理においては、サービスごとに適切なデータベース（RDBMSやNoSQL）を選択します。
分散システムにおけるデータ一貫性の課題に対しては、SAGAパターンを使用して分散トランザクションを管理します。
パフォーマンス向上のためにRedisなどのキャッシュ技術を導入し、イベントソーシングを採用することでデータの変更履歴を保存し、状態の再構築も可能です。
マイクロサービスアーキテクチャのメリット
それでは、上記の表を詳しく解説していきます。まずはマイクロサービスのメリットからです。
スケーラビリティがある
マイクロサービスアーキテクチャは非常に優れたスケーラビリティを持っています。
各サービスを独立してスケールアップまたはスケールアウトできるため、システム全体のリソース利用効率が向上し、コスト最適化が可能です。
特定のサービスに高負荷がかかっている場合でも、そのサービスのみを拡張することで対応できるため、柔軟な負荷分散が実現します。
また、各サービスの特性に応じて適切なハードウェアやクラウドリソースを割り当てることができ、性能の最適化も簡単です。
新しい機能や要件に応じて新たなサービスを追加しやすく、システム全体の拡張性が高まります。
柔軟性が高い
柔軟性もマイクロサービスアーキテクチャの大きなメリットです。
各サービスに最適なプログラミング言語やフレームワーク、データベースなどを選択できるため、特定の機能に最適なツールを使用できます。
また、各サービスを独立して開発、テスト、デプロイできるため、新機能の追加や既存機能の更新が簡単です。
小規模なサービス単位で変更を加えられるため、新しいアイデアや技術を試しやすくなり、リスクを最小限に抑えながらシステムの現代化を進められます。
開発・運用の効率化ができる
開発・運用の効率化も、マイクロサービスアーキテクチャの重要なメリットです。
サービスごとに小規模なチームを編成できるため、コミュニケーションが円滑になり、意思決定が迅速化されます。
また、一つのサービスの障害が他のサービスに影響しにくいため、システム全体の安定性が向上します。
つまり、小規模なサービス単位でのデプロイが可能なため、継続的デリバリーが促進され、頻繁かつ安全なリリースが実現できるのです。
運用面でもメリットがあります。
各サービスのコードベースが小さいため、理解しやすくメンテナンスが簡単です。また、適切に設計されたサービスは他のプロジェクトや異なるコンテキストで再利用しやすくなります。
マイクロサービスアーキテクチャの事例
それでは、実際のマイクロサービスアーキテクチャを使ったシステムを、例を挙げて説明します。
アマゾンウェブサービス (AWS)
AWSはクラウドと呼ばれる、遠隔地のコンピュータ資源を活用するサービスの1つです。
AWSはもともと、Amazonの社内システムを刷新するためにAmazon社内で開発されたクラウド基盤です。
当時、Amazonのシステムは巨大なモノリスで、自社の急激な業績拡大についていけてませんでした。何か一つを変更しようにもさまざまな箇所に影響が出るので、変更の手間が膨大だったのです。
そのために、マイクロサービスを利用しやすい基盤を自社で整えることから始まったのがAWSです。
この大刷新により、社内システムの修正が容易になり、Amazonの急成長を支えました。
Netflix
Netflixはアメリカの動画ストリーミングサービスです。
Amazonと同様、自社のモノリスのシステムに悩まされていました。2008年には一部の業務を数日間停止するという事態も発生したことがあります。
そのため、自社のシステムを徐々にマイクロサービスに移行しました。
これはその後のストリーミングの急成長に耐えました。たくさんのトラフィックが同時に行き交うストリーミングサービスにおいてマイクロサービスはなくてはないならないものでした。また配信コストを下げるという効果もあったようです。
メルカリ
メルカリは日本のフリーマーケット大手です。メルカリが自社のシステムのマイクロサービス移行を開始したのは2018年です。
それまでは一つのサーバーですべての処理を賄っていました。提供サービスの多様化にだんだん追いつけなくなっていました。
そこで、自社サービスのマイクロサービス移行を始めたのです。2022年の時点でほぼ完了したとのレポートが出ています。
メルカリのマイクロサービスの特色はユーザ認証基盤にあります。
技術的な詳細に立ち入るのは避けますが、安全性と性能を上手に両立した仕組みです。メルカリはその技術の詳細を公開しているので、日本の企業でメルカリのユーザ認証基盤の仕組みを取り入れる企業も出てきています。
Spotify
Spotifyはスウェーデンの音楽ストリーミングサービスです。音楽ストリーミングサービスでは世界最大手です。ユーザー数は、全世界で3億6000人以上とも言われています。
そんな膨大な数のユーザからの要求を処理するのはモノリスでは難しいでしょう。各部分が独立して動作するマイクロサービスでシステムを構築するのはSpotifyにとっては必然でした。
開発チームの独立性を高め、機能追加がやりやすいメリットがあるようです。Spotifyの取り組みは先進的な事例として取り上げられることも多いです。
マイクロサービスアーキテクチャのデメリット
ここまでマイクロサービスのメリットを紹介していきましたが、とは言えメリットばかりではありません。
マイクロサービスについて理解を深めるために、デメリットの部分も見ていきましょう。
設計が複雑
マイクロサービスアーキテクチャの設計は、モノリシックなアプリケーションと比較してはるかに複雑です。
各サービスの責任範囲を適切に定義し、サービス間の依存関係を管理することは困難な作業です。
また、分散システムの設計には特有の課題があり、データの一貫性維持やトランザクション管理などの問題に対処する必要があります。
サービス間の通信プロトコルやAPIの設計、バージョン管理なども考慮しなければならず、全体的なシステム設計の複雑さが増大します。
連携の難しさ
マイクロサービス間の連携は、単一のアプリケーション内での機能連携よりも難しくなります。
なぜかというと、ネットワークを介した通信が必要だからです。そのため、レイテンシーの増加や通信の失敗といった問題に対処する必要があります。
また、サービス間のデータの整合性を保つことも課題です。異なるチームが開発する場合、サービス間のインターフェースの変更や進化を調整することが難しくなり、全体としてのシステムの一貫性を維持するのが大変になります。
運用コストの増加
マイクロサービスアーキテクチャの採用は、運用コストの大幅な増加につながる可能性があります。
各サービスを個別にデプロイ、監視、スケーリングする必要があるため、運用の複雑さが増します。それに伴い、多数のサービスを管理するためのインフラストラクチャコストも増加します。
監視やログ管理のツールも各サービスに対して設定する必要があり、問題の診断やデバッグも複雑です。
サービス間の依存関係を管理し、全体のシステムの健全性を維持するために、より高度なスキルと時間が不可欠です。
適さないアプリケーションもある
マイクロサービスアーキテクチャは、すべてのタイプのアプリケーションに適しているわけではありません。
具体的には以下の場合が挙げられます。
- 小規模なアプリケーションやビジネスドメインが明確に分離できない場合
- 厳密なトランザクション整合性が要求される場合
- レガシーシステムとの統合が必要な場合
- チームの技術力が十分でない場合
これらの場合はマイクロサービスの導入は適切でない可能性があります。慎重に検討しましょう。
まとめ：マイクロサービスアーキテクチャとは
マイクロサービスアーキテクチャは、現在の開発現場において重要な技法です。
しかし、マイクロサービスアーキテクチャの採用を決定する前に、プロジェクトの規模、複雑さ、チームのスキルセット、ビジネス要件などを慎重に評価することが重要です。
場合によっては、モノリシックアーキテクチャや他のアプローチがより適している可能性があります。マイクロサービスの導入は段階的に行い、組織とシステムが成熟するにつれて徐々に拡張していくアプローチも考えられます。
もし自社に適しているかわからないという場合、マイクロサービスアーキテクチャの実績が豊富な株式会社Jiteraに一度ご相談ください。要件に対する的確なアドバイスを提供いたします。
