開発者が注意すべき「マイクロサービスの問題点」、そのトップ10を解説：問題点がメリットを上回るケースも

TechTagetは、「マイクロサービスの問題点」に関する記事を公開した。多くのメリットが得られるマイクロサービスだが、管理やコスト、デバッグの難易度などアプリケーション開発者が注意すべき点も多いという。

[Bob Reselman，TechTarget]

　TechTagetは2023年11月16日（米国時間）、「マイクロサービスの問題点」に関する記事を公開した。

あなたが克服すべきマイクロサービスの10の欠点（提供：TechTarget）

　「Docker」と「Kubernetes」をベースとする環境で構築されたクラウドネイティブアーキテクチャが流行している。クラウドネイティブと相性の良いマイクロサービスには、次のような利点がある。

• サービスごとに、アーキテクチャ、言語、プロセス、ツールを自由に選択できる
• ドメイン駆動型設計やイベント駆動型アーキテクチャなど、ソフトウェアコンポーネントで長年提唱されてきた多くのベストプラクティスが体系化されている
• 適切にカプセル化されているため、サービスを個別に更新できる
• 柔軟性が高く、短期間でのリリースが可能
• マイクロサービスに対応した技術（DockerやKubernetesなど）は多くのハードウェアで動作する

　マイクロサービスはこうしたさまざまなメリットをもたらす。一方で、幾つかの重要な問題点があるため、アプリケーション開発チームは注意する必要がある。特に、信頼性の高いモノリスアプリケーション（以下、「モノリスで構築されたシステムやアプリケーション」という意味で、まとめて「モノリス」と表記する）をマイクロサービス化する（同等の機能を持った多数のマイクロコンポーネントに分割する）際は、マイクロサービスの問題点とその回避策（または問題点との共存方法）を確実に理解することが重要だ。

　本稿では、マイクロサービスの問題点のトップ10を以下のカテゴリーに分けて説明する。

• トポロジーの複雑性の増加
• 自動デプロイメントの必要性
• 複雑な統合のオーバーヘッドと面倒な依存関係
• データの変換と非互換性
• ネットワークの混雑
• パフォーマンスの低下
• コストの増加
• ログ記録とトレースの複雑化
• テストとデバッグの課題
• 硬直化した組織

複雑性が増す

　モノリスを、ネットワークを介して通信する独立したマイクロサービスのサブセットに分割すると、アプリケーションのアーキテクチャが大幅に複雑化する。例えば、1つのモノリスを10個のマイクロサービスに分割するとしよう。すると、これまで実施していたタスクが以下のように変化する。

• スケーリングするアプリケーションが1個から10個に増える
• セキュリティを確保するAPIエンドポイントが1個から10個に増える
• 管理するGitリポジトリが1個から10個に増える
• ビルドするパッケージが1個から10個に増える
• デプロイするアーティファクトが1個から10個に増える

　単一かつ単独のモノリスよりも、多数の小さなプログラムを管理する方が難しい。これはマイクロサービスの問題点の一つだ。

デプロイメントの自動化が必要になる

　マイクロサービスは、Webスケールで動作するアプリケーションに大きな価値をもたらすが、テスト、デプロイ、メンテナンスなどが複雑になるというデメリットがある。そのため、こうした作業は手動ではなく、自動で実施する（自動化する）必要がある。エンタープライズレベルのアプリケーション内で機能する膨大な数のサービスには、この自動化が欠かせない。

　マイクロサービスアーキテクチャの採用を検討している企業は、Microsoftの「GitHub」、オープンソースの「Jenkins」、HashiCorpの「Terraform」などの自動化技術を採用すべきだ。また、担当者にはスクリプト作成の専門知識も必要になる。

　一貫性のある包括的な方法で自動化を実装するには、多くの時間やリソースの投入が必要になる。これはマイクロサービスのメリットと引き換えに企業が負わなければならないコストだといえる。

統合のオーバーヘッドと依存関係による負担が生じる

　マイクロサービス同士のデータ交換のルールを標準化するには多くの作業が必要になる。

　各マイクロサービスは個別に開発され、それぞれ独立したコンテナ内にデプロイされる。分離され、独立した各マイクロサービスは、実行時にはその全てが相互に通信する。つまり、“RESTful”なエンドポイント（HTTP経由でデータやリクエストのやりとりをするエンドポイント）や標準化された「JSON」「XML」形式による交換が増えるということだ。

　マイクロサービス同士の相互依存関係の管理は大変な作業だ。RESTfulエンドポイントは極めて不安定であり、あるコンポーネントを変更しただけで、他のコンポーネントに予期しない影響が及ぶ可能性がある。

　モノリスなら、「Java」や「Python」ベースのAPI呼び出しによってコンポーネント同士が直接相互作用するため、共通のデータ交換形式や「RESTful API」は必要ない。また、全てのインタラクション（相互作用）はコンパイル時に型チェックが行われ、検証される。

データの変換が必要になる

　全てのマイクロサービスが同じデータ構造と通信プロトコルを使用するのであれば問題はない。だが、多くの場合、そうはならない。例えば、RESTマイクロサービスとgRPCマイクロサービスが異なるHTTPプロトコルを使用して通信を試みるような状況は普通にあり得る。しかし、両マイクロサービスには、本質的に互換性はない。

　このような非互換性を克服する方法の一つが、プロキシなどの変換メカニズムを実装することだ。

異なるマイクロサービス形式間のコンテキスト変換をサポートするのは難しい

　マイクロサービス間でのデータ変換が課題になることもある。例えば、あるサービスの米国の郵便番号が、別のサービスでは英国やカナダの郵便番号になるといったものだ。

　こうしたデータコンテキストの変換の問題は何十年も続いている。モノリスは、データ全てを単一データベース内に格納しているため、こうした問題を最小限に抑えられる。マイクロサービスアーキテクチャの場合、1つのアプリケーションは数十から場合によっては数百のマイクロサービスに分割される。こうした多くのマイクロサービス間にデータ変換を実装することは深刻な課題につながる可能性がある。

ネットワークが混雑する

　マイクロサービス同士はRESTful APIを介してJSON、XML形式のデータを交換する。それらは全てHTTPプロトコル経由で実施されるため、モノリスと比べ、非常に多くの通信が発生し、ネットワークが混雑することになる。

　幸い、マイクロサービスの通信の大半は、プライベートなローカルサブネット内で行われる。このため、ネットワーク帯域幅を増やすことは簡単だ。だが、このJSON、XML形式のデータのやりとりは新たな問題を引き起こす。それはパフォーマンスへの影響だ。

パフォーマンスが低下する

　マイクロサービスは、同等のモノリシックアーキテクチャよりもメモリ、クロックサイクル、ネットワーク帯域幅の消費量が多い。

　モノリスは、全てのコンポーネントが単一プロセスのスコープ内で実行され、コンポーネント同士の相互作用は、ハードウェアレベルで実施される。各コンポーネントは標準のメソッド呼び出しを介して別のコンポーネントを呼び出す。この各コンポーネントを呼び出すスケジュールをローカルCPUで設定することが、パフォーマンス上唯一のオーバーヘッドになる。同じプロセス内で実行されるコンポーネント同士はデータはメモリ内を参照する単なるポインターにすぎないため、即座にデータを共有できる。

モノリスとマイクロサービスの違い

　モノリスのデータ共有と、マイクロサービスのデータ共有を比較してみよう。以下は2つのマイクロサービスがデータをやりとりする例だ。

1. 1つのマイクロサービス（マイクロサービスA）が保有するデータをテキストベースのJSONファイルに記述する
2. 記述したJSONファイルを、ネットワーク呼び出しを使って2つ目のマイクロサービス（マイクロサービスB）に送信する
3. マイクロサービスBがJSONファイルを解析し、データを取り出す
4. 送り返すデータ（応答データ）のために、マイクロサービスBが独自のJSONテキストファイルを作成する
5. マイクロサービスBがマイクロサービスAにネットワーク呼び出しで応答データを送る
6. マイクロサービスAがJSONファイルを受け取り、解析して返送されたデータを取り出す

　モノリスなら即座に行われるデータ共有だが、マイクロサービスの場合はこれだけのオーバーヘッドがかかる。マイクロサービスのパフォーマンスとリソース使用量に関する問題は、コストという新たな問題につながる。

コンピューティングコストが増加する

　1つのモノリスを複数のマイクロサービスに分けるとき、以下の事象が生じる。

• 実行に必要なメモリが増える
• コンテナや仮想マシン（VM）を複数使用する際にリソースを複製しなければならない
• RESTfulなWebサービスを呼び出すために帯域幅の使用量が増える
• JSONファイルの送信、解析、読み取り、再組み立てに伴い、多くのCPUサイクルが発生する

　クラウドで稼働させているアプリケーションであれば、CPUやメモリが増えるほど、クラウドコンピューティングの費用も増えることになる。マイクロサービスアーキテクチャのサポートに必要なリソース数が増えると、モノリシックなアーキテクチャよりも負担するコストが増加する。これはマイクロサービスの大きな問題点だ。

ログ記録、トレース、監査が複雑になる

　クラウドネイティブアプリケーションは、一時的なコンテナが必要となるマイクロサービスランタイムを提供するKubernetesクラスタにデプロイされるのが一般的だ。この“一時的にしか存在しない”という性質は、ログ記録、追跡、監査と相性が悪い。マルチノードネットワークの場合はログ確認の難易度が増す。

　マイクロサービスをホストするDockerコンテナが落ちてしまうと、バックグラウンドのデーモンプロセスがログデータをコンテナ外部に移動させ、信頼できるストレージロケーションに保存していない限り、ログファイルは瞬時に失われる。もちろん、オープンソースの「Fluentd」など、この“ログ消失問題”に対処できるツールはあるが、問題点であることに変わりはない。

　モノリシックアーキテクチャは、全てのログ、トレース、監査のデータがサーバの1つのフォルダに書き込まれ、従来型サーバの大半にはログローテーションメカニズムが組み込まれている。そのため、モノリスでは、ログ記録とトレースが非常に簡単に管理できる。

　クラウドネイティブクラスタ全体に広がるログファイル、トレースファイル、監査データを管理するのに必要な追加作業は、マイクロサービスアーキテクチャの大きな問題点の一つだ。

トラブルシューティングや問題点の検出が難しくなる

　ログの消失と同じ理由で、問題点のトラブルシューティングが難しいという問題がマイクロサービスにはある。複数のマイクロサービスがそれぞれ独立したランタイム内でホストされている場合、ある要求（リクエスト）が失敗すると、そのリクエストが失敗した場所と原因を追跡するのは非常に難しい。モノリスとなら、1台のPCでホストされる単一サーバ上で失敗したリクエストの経路をたどってトラブルシューティングするのはそれほど難しくはない。

　また、失敗したリクエストの正確なパスを複製するのも手間がかかる。特に、コンテナでホストされるマイクロサービスがスピンアップとスピンダウンを絶えず繰り返している場合は面倒な作業になる可能性が高い。

分散デバッグ

　ログの消失やトラブルシューティングの難解さと同様の理由で、マイクロサービスアーキテクチャのアプリケーションはデバッグが難しい。数百規模になり得るマイクロサービス同士が連携し、相互作用してそれぞれ独立したコンテナを持つアーキテクチャにおいて、マイクロサービス内外で行き交うリクエストの経路をトレースしなければならないとする。これを実現するには、包括的な監査計画が必要になる。マイクロサービスアーキテクチャ内部でログを記録すれば限定的なビューは得られるとしても、監視で把握しなければならないのは全体像だ。

　分散トレースを使って、サービス間のアクティビティーのデバッグを支援するツールは幾つか存在する。オープンソースプロジェクトの「Jaeger」「Zipkin」、商用製品の「Datadog」「Dynatrace」、VMwareの「Wavefront」などがその一例だ。ただ、どのようなツールを利用するとしても、アプリケーションを構成するさまざまなマイクロサービスの内部や外部のアクティビティーを監視するには、監視計画が必要なことが分かるだろう。

硬直化した組織

　最後に、マイクロサービスに関する最大の問題が「硬直化した組織の克服」だ。マイクロサービスを導入するには組織を説得する必要がある。

　モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行は大掛かりな取り組みになる。新しいツールを導入し、新たな開発アプローチに取り組み、新たなスキルを習得する必要がある。そのため、クラウドネイティブアーキテクチャに移行するやむを得ない理由がなければ、このままモノリシックアーキテクチャを維持する方が簡単だと考える組織は多い。

　硬直化した組織を解きほぐすのは、説得力のある議論だ。IT部門でモノリスをマイクロサービスに分ける準備が整っていなければ、恐らくまだマイクロサービスの問題点がそのメリットを上回っている。

　だがそれは決して間違いではない。全てのIT部門がクラウドネイティブ環境に移行する準備が整っているわけではないし、必ず移行しなければならないわけでもないからだ。現代のIT環境でも、モノリスが果たすべき役割は残っている。