マイクロサービスとは

栄光からの転落

いわゆる「最新の技術トレンド」は、ほぼ例外なく一時的な流行に終わります。なぜでしょう。それは、プロが何年も実践してきたことが突然流行になるからです。プロの成功に刺激されたアマチュアが真似しようと思っても、そううまくはいきません。一握りの有能な個人が手をかけてサービスを作成するのを、それ以外のIT業界関係者がうらやましそうに眺めるという構図です。

アジャイルの創始者の1人であるMartin Fowler氏は、大半の組織は本当の意味でSOAに移行したわけではなく、主にエンタープライズサービスバス（ESB）などに複雑さを転嫁しただけだと評しています。ESBはサービスとコンシューマとの間の通信を処理するミドルウェアの1つです。企業は、モノリシックな母体からビジネスプロセスを分離する際の複雑さを軽減するためにこのESBを利用しました。その結果、技術的には機能するものの、変更やテストが難しく管理が不可能なブラックボックスソリューションができあがってしまったのです。

その結果、技術的には機能するものの、変更やテストが難しく管理が不可能なブラックボックスソリューションができあがってしまったのです。この状況を見たFowler氏は、ESBは「Erroneous Spaghetti Boxes（エラーだらけのスパゲティボックス）」の略語としたほうがよいのではないかと考えたそうです。

マイクロサービスの登場

何かを説明しているとき、話した内容とはかけ離れた、明らかに誤解のある内容を相手がオウム返しにしてきたことはないでしょうか。もしくは、会話の最中に相手のうなずきが明らかに過剰だったことはないでしょうか。そのときの気持ちを思い出してください。世界中の企業がサービス指向アーキテクチャをうまく理解できず、様々な問題を発生させているのを見て、考案者はまさにそれと同じ気持ちになりました。

こうした状況では、誤解を解きたくなるものです。そこで考案者は、最初のコンセプトを「マイクロサービス」という形で言い換えました。基本的に、マイクロサービスはサービスが本来もたらすはずだったメリットを実現します。一般的な決まりは次のとおりです。

• ネットワークアクセス可: スパゲティボックスのようなカスタムコードが入り込む余地はありません。マイクロサービスには、HTTPやTCP/UDPなどのプラットフォームに依存しないネットワークプロトコルを利用するという厳密な制限があります。このプラクティスは、後にSOAにも適用されるようになりました。
• 独立したデプロイ: マイクロサービスアーキテクチャで最も大切なのが、完全な分離です。他のコンポーネント、特にコンシューマのことを気にすることなく、マイクロサービスに更新をデプロイできるようにしておく必要があります。
• 置き換え可能: 他のコンポーネント、最初の2つの規則があるため、元のサービスの規約に従うだけでマイクロサービスを別のものに置き換えることが可能です。ここでいう「規約」とは、API仕様のことです。
• 狭いスコープ: マイクロサービスに持たせるのは、特定のビジネス価値やビジネス機能のみです。各マイクロサービスのスコープを定義するのは難しいものですが、一般的には請求、写真保存、位置情報サービスなどが挙げられます。
• 異種混合: マイクロサービスでは、モノリシックアーキテクチャで強要されていたものではなく、ユースケースに最適なライブラリやテクノロジーを利用します。
• 完全な自動化: マイクロサービスはDevOpsと非常に相性の良いユースケースです。DevOpsには、ソフトウェア開発（作成者）とIT運用（ソフトウェアを稼働させ、変更後に動作させる担当者）の隔たりをなくすという哲学があります。DevOpsとマイクロサービスを組み合わせると、デプロイ、テスト、監視プロセスが自動化され、サービスの信頼性が向上し、ストレスのない開発サイクルを推進できます。

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

Netflix、Amazon、Uberといったテクノロジー企業大手は、多くのメリットが期待されるマイクロサービスをすでに導入しています。マイクロサービスのメリットは以下のとおりです。

• POCまでの期間の短縮: 開発者は、提供したいビジネス価値に最適なツールを使用してマイクロサービスを作成できます。また、データが完全に分離されているため、プロトタイプ作成を非常に高速に行うことができます。
• チームによる所有: ビジネス価値を一連のマイクロサービスに分割することにより、小規模な水平型チームがマイクロサービスの完全な所有権を持つことができます。これによって、チームの権限と、優れた製品を提供しようというモチベーションが向上します。一方、大規模なモノリスでは、開発者はタスクからタスクへと作業を渡り歩くことになり、達成感を感じられる機会がほとんどありません。
• 拡張性: マイクロサービスは、他のアプリケーション要素に依存せず作成・パブリッシュされるため、組織のニーズに応じて拡張（縮小）することが可能です。
• 再利用性: 作成したマイクロサービスは、あらゆるユーザーが利用できます。また、必要に応じて拡張できるようになっているため、負荷の増加にも対応可能です。
• 耐障害性: データやアプリケーションサーバーが他のコンポーネントから分離されているため、マイクロサービスで障害が発生しても製品全体が停止することはありません。マイクロサービスは小さな製品であり、リリース、管理、拡張も独立して行われるため、このタイプのアーキテクチャでは耐障害性を簡単に実現することができます。システムを構成する小さな要素に耐障害性を持たせることで、簡単に対障害性の高いシステムを構築できます。つまり、1つまたは複数のサービスで障害が発生した場合に、システム全体を完全に停止させず、エクスペリエンスを少し落とすだけにとどめられるようになるのです。
• リスクの軽減: 当然ですが、マイクロサービスはビジネス価値を提供します。また、他のコンポーネントからの独立性を保つことでリスクを軽減します。つまり、開発チームと組織の利益が設計上連携するようになっています。

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

残念ながら、他の最新のトレンドと同様、マイクロサービスもすべてがバラ色というわけではありません。以下のような問題があります。

• ネットワーク依存: マイクロサービスは標準のネットワークプロトコルのみで通信します。つまり、ネットワークが何らかの（主に組織の管理できない）理由で停止したり中断したりすると、業務に支障が生じます。また、デプロイしているマイクロサービスの数が増えるほど、ネットワークの停止がサービス停止につながるリスクも高まります。ネットワークを使用するということは、システムに遅延の影響が及ぶということなので、それを考慮する必要もあります。ネットワークの通信速度が遅いというだけの理由で口座残高の表示を何秒も待たされて平気な顔をしていられるエンドユーザーはいません。
• オーバーヘッド: マイクロサービスでは、大きな製品を分割して小さな製品グループにします。その結果、このグループを管理する際にオーバーヘッドが生じます。実は、これが多くの組織がマイクロサービスの全面的な導入に踏み切っていない理由のひとつです。また、マイクロサービスはそれぞれにDevOpsプロセスが必要です。組織内でマイクロサービスの数が増えるほど、維持のために必要な保守や監視の負荷も高くなります。
• 非常に複雑な依存関係: 何百ものアプリケーションコンポーネントが依存する、規約（API仕様）の確立されたマイクロサービスがあるとしましょう。その仕様を、マイクロサービスのチームが再設計（または、少しだけ変更）したらどうなるでしょう。組織は多くのチーム間でこの変更に関する調整を行う必要があります。さらに、依存関係を常に追跡しておく必要もあります。
• 厳格な規約: 前の項目の補足となりますが、初回リリース後も長期的にビジネス価値を提供できるよう、しっかりしたマイクロサービスAPI仕様を慎重に定義する必要があります。ここまで先回りして考える組織は少ないものです。それができない組織には、マイクロサービスはあまりお勧めできません。
• リリースの容易さ: これは長所でもあり欠点でもあります。マイクロサービスはデプロイや組み込みが非常に簡単であるため、やりすぎてしまうことがあります。代償を完全に理解せずに何でもマイクロサービス化してしまうと、アーキテクチャの再構築が失敗したり、思いどおりにいかなかったりします。

マイクロサービスを次のソフトウェアプロジェクトのアーキテクチャとして採用すべきか

マイクロサービスのメリットとデメリットを理解した今であれば、この問いに答えることができるはずです。最後にひとつアドバイスです。マイクロサービスの開発に着手する前に、なぜマイクロサービスアーキテクチャを開発したいのか考えてください。答えが「大企業がこぞって導入しているから」である場合は、方向性を間違っているかもしれません。

この記事では、マイクロサービスに関するメリットをいくつか紹介してきました。なぜそうしたアーキテクチャが有用なのかは、もうおわかりのはずです。独立した継続的統合および継続的デリバリー（CI/CD）パイプラインを複数持ち、様々なスキル、ベンダー、テクノロジーを活用しているチームもあるでしょう。

ただし、大切なのは有効活用できそうなタイミングを見極めることです。ほとんどの企業は、世界トップクラスのエンジニアを擁し、1つのアプリケーションを専門的に管理する開発スタッフを多数抱えているNetflixとは違います。人材は不足がちであり、平均的な企業では確保が難しいことが多いものです。また、そうした企業では開発が小規模であり、1つの製品ではなくビジネスで利用するアプリケーションポートフォリオに重点を置く傾向にあります。適切に利用しないと、マイクロサービスは手に負えないものになってしまうおそれがあります。

各アプローチのメリットとデメリットを理解することは、アーキテクチャに関する意思決定を適切に行ううえで重要です。

様々なアプローチの詳細と開発プロジェクトに適したアーキテクチャの選び方については、以下のリソースが参考になります。

• アプリケーションアーキテクチャ: 将来を見据えたアプリのためのベストプラクティス
• サービス指向アーキテクチャとは
• モノリスとマイクロサービスの両立
• Webアプリケーションのアーキテクチャ設計