マイクロサービスについて企業が知っておくべきこと：デメリットも理解しておく

クラウドネイティブ、モダナイゼーション、DXなどの文脈でもてはやされているマイクロサービス。全ての企業が取り組むべきものなのか。デメリットも含めて再整理しよう。

[Daniel Robinson，Computer Weekly]

　マイクロサービスの普及はクラウドネイティブやアジャイル開発などのトレンドと連動しており、特にコンテナといったデプロイ手段と密接に関係している。

関連記事

• コンテナ＆マイクロサービスが常に優れているわけではない
• サーバレス対マイクロサービス──現時点で知っておくべきこと
• マイクロサービスはセキュリティの複雑性を増大させる
• いまさら聞けないコンテナ＆マイクロサービス
• マイクロサービスの複雑性を解決する方法

　O'Reillyが2020年に実施した調査によると、調査対象1500社の中でマイクロサービスを全く利用していない企業は約4分の1にすぎなかったという。だが利用している企業（約75％）で5年以上利用していたのは約10％にすぎない。つまり、大半の企業は5年以内にマイクロサービスを採用したことになる。

　マイクロサービスは具体的な技術ではない。ソフトウェアアーキテクチャの一つであり、アプリケーションやサービスを設計する際のアプローチの一つだ。マイクロサービスではアプリケーションを1つのモノリシックなエンティティーではなく、独立してデプロイできる小さなサービスに分解する。そのサービスがコミュニケーションし合い、アプリケーションに必要な機能を提供する。

　このアプローチには幾つかメリットがある。コンポーネントを個別にスケーリングできることから、スケーラビリティの向上が容易だ。アプリケーション全体をスケーリングするのではなく、需要が多い一部のコンポーネントのみをスケーリングする。その場合、スケーリングするコンポーネントの新しいインスタンスを起動してワークロードのバランスを取る。

　マイクロサービスはアジャイル開発にも適している。マイクロサービスはコンポーネントのサイズが小さいので改善しやすく、迅速にコードを更新できる。開発者がコードを理解するのも容易だ。その結果、信頼性も高まる可能性がある。タスクの種類に適したプログラミング言語があるため、コンポーネントによって使う言語を変えることも可能だ。

　コンポーネントにエラーが発生した際は適切に分離されることから、ダウンタイムが減る可能性があるのもメリットの一つだ。あるマイクロサービスでエラーが起きても、その結果としてアプリケーションやサービス全体がダウンする恐れは減少する。

潜在的なデメリット

　マイクロサービスには考慮すべきデメリットもある。各コンポーネントの開発はシンプルになるとしても、アプリケーションやサービス全体の管理は複雑になるかもしれない。

　マイクロサービスには、さまざまなコンポーネントのインスタンスが数十から数百関係する可能性がある。そのデプロイのスケールを問わず、管理の複雑さは伴う。インスタンス間のコミュニケーションを管理するだけでなく、各インスタンスが想定するパラメーター内で動作し、必要とするよりも多くのリソースを消費しないように監視しなければならない。必要よりも多くのリソースを消費している場合は問題の兆候かもしれない。

　マイクロサービスはテストやデバッグが難しくなる恐れがある。マイクロサービスのバグの原因を追跡するには、それぞれのログが必要だ。各マイクロサービスを適切にテストするには依存関係のあるサービスのテストを全て完了しておかなければならない。そのためアプリケーション全体のテストはさらに難しくなる。

　特にマイクロサービスのデプロイでは監視が重要だ。コンポーネントが分散する性質により、従来のアプリケーションよりも監視は複雑になる。監視システムはさまざまなコンポーネント間で絡み合う依存関係も監視できなければならない。

　マイクロサービスの運用方法はインフラにも影響する。需要の増加に合わせた自動スケーリングをサポートするには、マイクロサービスの新しいインスタンス用のリソースをAPIコールでプロビジョニングできなければならない。これはクラウドのようなソフトウェア定義のインフラを意味する。

　マイクロサービスに基づくアプリケーションやサービスをビルドする際にはデータも厄介な問題になる。もっと正確に言うなら、データをどこに保存するかが問題だ。それは、各マイクロサービスが独自のデータストアを保持している可能性が高いからだ。ただし、共有リポジトリへのアクセスが必要なアプリケーションもある。

　サービスが異なればストレージの要件も異なる。業界の中には、NoSQLデータベースが最も適しているという意見もあれば既にSQLを使っているならSQLにこだわるべきだという意見もある。

　データについては他にもさまざまな意見がある。1つのデータベースを複数のサービスが共有するのが最善のアプローチであり、そうすればデータベースのバックアップとリストアの手順を再利用できるという専門家もいる。それでは単一障害点を生み出す恐れがあり、マイクロサービスの考え方に反するとする専門家もいる。

慎重な計画

　マイクロサービスはあらゆる企業、あらゆる種類のアプリケーションに適しているわけではない。とはいえ、マイクロサービスの採用は拡大し続けている。それは、マイクロサービスによってサービスのデプロイをより簡単にアジャイル化できるためだ。これは多くの企業が求めていることだ。

　独立系アナリストのクライブ・ロングボトム氏は次のように話す。「マイクロサービスへと向かうのは最先端企業が多い。最先端企業ほど、新しいアーキテクチャについてオープンに考える傾向が強い。マイクロサービスを成功に導くのは革新的なことで、行うべきことを全面的に考え直す必要がある」

　言葉を変えれば、マイクロサービスは既存アプリケーションのリファクタリングや更新を試みるよりも、一から構築する「グリーンフィールド」デプロイの方が適している可能性がある。

　既に述べたように、コンテナはマイクロサービスと関連付けて考えられることが多いが、マイクロサービスなどの分散デプロイを実装する方法の一つにすぎない。他にも、軽量の仮想マシンを使う方法や非仮想化サーバで実行する方法もある。サーバレスコンピューティングもマイクロサービスを実装する方法の一つだ。

　恐らく、仮想マシンよりもコンテナの方が適している。コンテナはリソースの消費量が少なく、仮想マシンを新たに起動するよりもコンテナのインスタンスを新たに起動する方がはるかに高速だからだ。コンテナは技術的にも成熟しており、エコシステムも幅広い。

　O'Reillyの調査では興味深い結果が出ている。マイクロサービスの取り組みに成功したと回答した企業は平均よりも高い割合でコンテナを使っており、失敗した企業は高い割合でコンテナを使っていなかったという。

　この結果は、マイクロサービスの実装においてコンテナの方が低リスクであることを示している可能性がある。重要なのは、アプリケーションや要件に適した技術を選ぶことだ。