マイクロサービスとは？ - SOAやコンテナとの違い

これまで、ソフトウェアシステムのほとんどが、一枚岩のモノリシックなアプリケーションとして構築されてきました。コンポーネントが疎結合されているマイクロサービスやサービス指向のアーキテクチャとは対照的に、モノリシックなアプリケーションではコンポーネントと機能は密結合されています。モノリシックなアプローチには以下のようなデメリットがあります。

• コード基盤が拡大する一方で、それに対し改善や変更を加えるのが難しく、個々の変更がアプリケーション全体に影響を及ぼす可能性があるためリファクタリングが容易でない。
• モノリシック(一枚岩)のアプリケーション全体に変更の影響が及ぶため、テストと導入が複雑。
• コンポーネント1つの障害でアプリケーション全体がダウンするため、リスクが高い。

マイクロサービスは、従来のモノリシックなシステムよりも優れた柔軟性を提供します。マイクロサービス開発には決まった1つの方法があるわけではありませんが、マイクロサービスアーキテクチャにおけるデータ管理については一般的なガイドラインがあります。開発チームの関心がマイクロサービスに向く背景には、以下のような理由からデータ管理が複雑になっているという事情があります。

• 大規模なチームで作業を行う
• 多くのユーザーインタラクションモデルをサポートしている
• 各ビジネス機能をそれぞれ別個に強化できるようにしている
• いくつものWebサービスを提供している

しかし、最大の違いはそのサイズです。モノリシックアーキテクチャではサイズが大きすぎて、変更や導入、拡張を行えないことが少なくありません。その点、マイクロサービスアーキテクチャは柔軟に対応することができます。

SOAは、多種多様なアプリケーションとの統合を必要とする大規模で複雑なビジネスアプリケーション環境に適しています。それに対し、マイクロサービスは、開発者がコントロールしやすい、より小規模で細分化されたWebベースのシステムに適しています。つまり、構築するアプリケーションの規模によって使い分ける、といった違いがあるのです。アプリケーションを小さな部品に分割することは新しい概念ではなく、マイクロサービス以前にもサービス指向アーキテクチャ(SOA)ですでに取り入れられていました。

SOAマニフェストでは以下を提唱しています。

• 技術戦略よりもビジネス価値を優先する。
• プロジェクト固有の利益よりも戦略的目標が重要である。
• カスタム統合よりも本質的な相互運用性が重要である。
• 特定の目的を持った実装よりも共有サービスが重要である。
• 最適化よりも柔軟性を優先する。
• 最初から完成を目指すよりも徐々に改善していく。

マイクロサービスはIT部門で起きたDevOps文化への移行の一端です。DevOpsでは開発チームと運用チームが緊密に連携しながら、ライフサイクル全体にわたってアプリケーションをサポートしていきます。すでにSOA文化が浸透している企業では、マイクロサービスの導入を検討すべきです。

本質的にサービス指向のアーキテクチャ(SOA)とは、相互に通信する複数のサービスの集合体です。通信は、単純なデータの受け渡しであることもあれば、何らかのアクティビティを協調的に行う2つ以上のサービスが関与することもあります。

サービス指向のアーキテクチャ(SOA)は、アジャイルの高速な開発サイクルでは効果的な戦略です。マイクロサービスを採用するメリットは、主に開発者が継続的デリバリーサイクルを導入できるという点にあります。マイクロサービスを採用する前に、まずはすでに利用しているテクノロジーを評価する必要があります。どちらのアーキテクチャのパフォーマンスが高いかではなく、構築しようとしているアプリケーションの目的を評価することが重要なのです。

コンテナは、Linuxのプログラムやプロセスをパッケージ化し、導入し、実行するための手法です。1つの巨大なモノリシックアプリケーションをコンテナとして持つこともできれば、コンテナをまったく使わないマイクロサービスでアプリケーションを構成することもできます。

コンテナはリソース割り当てを得意としており、DevOpsで好まれます。マイクロサービスはソフトウェア設計パターンであり、開発者に好まれます。コンテナとマイクロサービスはどちらも有用であり、併用できますが、相互に依存関係はありません。これがマイクロサービスとコンテナの違いです。

マイクロサービスのアプローチでは主に2つの課題があります。相互に自立したチームがそれぞれチームごとに異なる作業スタイルを持つという点と、いつまでたっても「終わった」と感じられないという点です。最初の課題は、マイクロサービスによって生産性の向上やよりよいツール選択が可能になるにもかかわらず、しばしば各チームが別のコーディング言語、フレームワーク、ライブラリを選びたがるというものです。このようなかたちの自立に慣れていないチームは行き詰まってしまうかもしれません。

2つ目の課題は、モノリシックアーキテクチャでは変更そのものが大きな1つのプロジェクトとなり、そのプロジェクトに明確な始まりと終わりがある一方、マイクロサービスでは変更は常に行われるという点です。頻繁な変更は悪いことではなく、システムを進化させるために欠かせない特性の1つなのです。しかし、このようなフローになじみのないチームは適応するための努力が必要になるかもしれません。

さらに、もう1つの課題として、マイクロサービスには複雑さがあり、戦略的なアプローチで監視を行う必要があります。

マイクロサービスへの切り替えが進む背景には、イノベーションが加速する中、企業がビジネス上の優先事項に集中的に取り組もうとしていることがあります。同様に、スピードと成果を重視するDevOpsの広がりも、マイクロサービスへの関心に拍車をかけています。

Amazon、Spotify、Uber、Groupon、Karmaなど、多くの企業がモノリシックアーキテクチャからマイクロサービス構造へとシステムを進化させてきました。Netflix社の開発者はマイクロサービスを使用して、毎日数千ものコードセクションをデプロイし、1億3,900万人の契約者と100億時間に及ぶ映画やTVドラマシリーズをサポートしています。 

マイクロサービスは、ソフトウェアの開発と導入を迅速に行えるため、コストを節約し、企業の競争力を高めることができます。開発時点でアプリケーションがどのようなデバイスで実行されるか予測できない場合、マイクロサービスアーキテクチャは最適な選択です。開発者は、アプリケーションの速度を低下させたり停止させることなく、制御しながら迅速にアップグレードすることができます。その他にも以下のメリットがあります。

• 安定性：機能が分割されているため、アプリケーションのコンポーネントを個別にスケールアップまたはスケールダウンできます。これによって障害も分離できるため、コンポーネントの1つで障害が起きたとしてもアプリケーション全体をダウンさせずに済みます。
• 特定のベンダーやテクノロジーに縛られない：マイクロサービスでは、必要であればマイクロサービスごとに異なるテクノロジースタックを選択することも可能です。
• 構築と保守が容易：単一用途のために設計されているため、小規模なチームで構築と保守を行えます。各チームが複数の機能を担当することもできます。また、各マイクロサービスは個別に導入可能です。
• コードの質が向上：ソリューション全体をモジュール化して別々のコンポーネントにすることで、アプリケーションの開発チームはその都度、小さな一部分に集中できます。そのため、コーディングとテストのプロセス全体が簡素化されます。
• チーム間の調整が容易：従来のサービス指向アーキテクチャ(SOA)はプロセス間で処理の重い通信プロトコルを使用するのに対し、マイクロサービスはイベントストリーミングテクノロジーを使用するため、統合が容易です。
• リアルタイム処理：マイクロサービスの根幹にあるのはパブリッシュ-サブスクライブ型のフレームワークです。リアルタイムデータを処理し、出力結果とインサイトを速やかに提供できます。
• プロジェクト開発が高速：マイクロサービスは独立して動作するため、機能を変更する際にコード基盤を変更する必要がありません。1つのコンポーネントを個別に変更し、テストし、デプロイできるため、アプリケーションを迅速に提供できます。
• 大規模化が可能：拡張性には、より大量の処理が可能になるというだけではなく、労力の面でも利点があります。マイクロサービスの場合、スケーリングのボトルネックを容易に特定でき、マイクロサービスごとに解決できます。

監視は、マイクロサービスアーキテクチャにとって極めて重要な要素です。アプリケーションをコンポーネントに分割するマイクロサービスは、多くのメリットをもたらす一方、複雑化を招きます。マイクロサービスは相互に通信する必要があり、さらに、個別に作成、更新される各コンポーネントと他のコンポーネントを連携させる必要もあります。そして、これらの通信や連携は最小限の遅延で行う必要があります。つまり、マイクロサービスで構成されるアプリケーションの管理とは、相関するコンポーネントからなるネットワークを管理することを意味します。全体の信頼性を確保するには、ネットワークを効果的に管理することが不可欠です。

監視とオブザーバビリティは、DevOpsやアジャイルの考え方を身につけている開発者にはおなじみかもしれません。マイクロサービスを成功させるには、これらのアプローチとともに、SDLC(ソフトウェア開発ライフサイクル)のあらゆる段階で自動化とコラボレーションを実現する必要があります。構成管理、CI/CDサーバー、APM、ネットワーク監視、ダッシュボード、自動アラート、インシデント管理は、マイクロサービスを実行するチームにとっての基盤です。

マイクロサービス監視には、基本的な監視と、迅速なアプリケーションデプロイという2つの要素が不可欠です。

• 基本的な監視：テスト段階で捕捉できなかった問題を速やかに検出できることが重要です。ここでは最低限、技術的な問題(エラー数、サービスの利用可否など)を検出する必要がありますが、ビジネスの問題を監視することにも意味があります(受注減の検出など)。問題が突然発生した場合、個別のサービスやオペレーティングシステムを速やかにロールバックすることができます。
• 迅速なアプリケーションデプロイ：管理するサービスが非常に多いため、テスト環境と本番環境へのデプロイを迅速に行う必要があります。一般には、数時間以内に終えるべきでしょう。初期段階では手動操作による介入が多少あってもかまいませんが、早々に完全な自動化を目指す必要があります。

これらを実現するためには、DevOps文化に見られるような開発者と運用者の緊密な連携という重要な転換が組織に求められます。プロビジョニングとデプロイを迅速に行うには、このような連携が必須です。監視で問題が見つかった場合に速やかに対応できるようにしておくことも重要です。

分散したシステムでは、より効果的なオーケストレーション、負荷分散、障害分離など、さまざまなチームがオブザーバビリティの文化の確立に向けて協力していくことが可能になります。

もちろん監視は、マイクロサービスアーキテクチャを維持するために最優先で実行する必要があり、異常が発見された場合にも対応が必要です。迅速かつ効果的に対応するには、アラートプロセスとインシデント対応計画を策定しておくことが重要になります。

マイクロサービスはまだ比較的新しいアーキテクチャですが、今後も普及はますます進むでしょう。マイクロサービスによって、チームは製品やアプリケーションをスケーリングしながら、自立的に成長します。マイクロサービスをどのように導入するかにかかわらず、市場投入までの時間を短縮することが主要な目標の1つとなるはずです。それだけでも、多くのチームにとって切り替える価値があります。