マイクロサービスとは？クラウドコンピューティングにおけるマイクロサービスについて
目次
はじめに
マイクロサービスは、人気が高まっているソフトウェアアーキテクチャの一種です。このアーキテクチャは、Amazon、Netflix、Uberなど、技術業界の大手がアプリやシステムに採用しています。
では、マイクロサービスとは何でしょうか。
また、なぜ世界中の企業で導入が進んでいるのでしょうか？
この記事で解説します。
関連記事
マイクロサービスとは？
マイクロサービスは、アプリを疎結合で独立に展開可能な小さな要因に分割するアーキテクチャのアプローチです。これらの独立した要因はマイクロサービスと呼ばれ、通常、以下のような特徴を持ちます。
・独自の技術スタック、ライブラリ、依存関係を持つ。
・開発者は、システムのほかの部分を巻き込まずに作業できる。
・これらは、REST API、イベントストリーミング、メッセージブローカーを介して互いに通信する。
マイクロサービスがほかのアーキテクチャより優れている主な理由は、開発者がアプリの構築と拡張を容易にすることです。マイクロサービスは、アプリの規模が大きくなった時に、より簡単に開発したいというニーズから生まれたものなのです。
マイクロサービスが普及するまでの歴史
マイクロサービスがどのように生まれたかを理解するためには、その前にあった「モノシリック（完全に統制された）」について知る必要があります。
モノシリック、またはモノリシックアーキテクチャとは、アプリが単一の不可分のユニットとして構築されるアーキテクチャアプローチです。システム全体は、データベースからユーザーインターフェースレベルまで、密接に絡み合っています。このアーキテクチャでは、サービスが高度に連携しているため、開発者があるサービスに変更を加えようとすれば、その変更のためにシステム全体を操作しなければならなくなります。
Amazon.comとモノリシックアーキテクチャ
これは、2000年代にAmazon.comのビジネスが大きくなった時に起こったことです。2001年頃、モノシリックで構築されたアマゾンのeコマースサイトは、会社の急激な成長により、あまりにも膨大で複雑になり、管理や更新が信じられないほど難しくなってきました。Webアプリの新機能や新バージョンをリリースするためには、何百人もの開発者による途中変更の調整、開発者間の不一致の解消、1つのバージョンへの統合など、山のような作業が必要だったのです。
この問題を回避するために、AmazonはモノリシックなWebサイトを、疎結合で互いに独立して動作する多数の小さなサービスに段階的に分割していきました。たとえば、商品ページの購入ボタンを表示するサービスは1つ、チェックアウト時に正しい税金を計算するサービスも1つでした。このようなアーキテクチャを実現できたのは、サービス間の唯一の通信手段としてAPIが導入されたからです。APIは、サービス同士が高度にデカップリングされながら通信できるものです。
もちろん、これは話を単純化したものであり、その事業は簡単なものではありませんでしたが、Amazonは成功を収めました。同社がマイクロサービスという言葉を発明したわけではなく、Amazonがシステムを変革していた当時はこの言葉すら存在しませんでしたが、このアーキテクチャは基本的にAmazonが問題解決のために構築されたものです。ですから、Amazonは多かれ少なかれ、私たちが今日知っていて使っているマイクロサービスアーキテクチャを発明したといっても良いでしょう。
NetflixやUberなどほかの大手テック企業も、マイクロサービスによってAmazonのビジネス全体を変化したことを目の当たりにし、同じようにモノシリックからマイクロサービスへの移行を開始し、少しずつこの革命的なアーキテクチャが世界に知られるようになりました。
マイクロサービス とモノリシックアーキテクチャの比較
モノリシックアーキテクチャとは、アプリを単一の不可分な単位として構築するソフトウェア開発手法です。モノリシックなアプリでは、サービスが相互に依存し合っているため、1つのサービスを更新すると、アプリ全体の調整が必要になります。
一方、マイクロサービスでは、サービスは依存性と単一目的に構築されます。つまり、独自のビジネスロジックとデータベースを持ち、単一のタスク（たとえば、商品ページの購入ボタン）を実行します。このアーキテクチャのサービスは疎結合であるため、サービスの更新がほかのサービス動作を中断することはありません。
サービスの構築と接続方法によって、開発者はモノリシックアーキテクチャよりもマイクロサービスでの機能構築と更新がはるかに容易になります。マイクロサービスでは、システムの残りの部分を稼動させ、異なるチームが同時に異なるサービスに取り組めます。このような柔軟性の高い運用は、モノリシックアーキテクチャでは不可能です。
しかし、マイクロサービス同士が通信するためにはAPIが必要で、その分、スピードは遅くなります。APIは、別々のマイクロサービスのパーツをつなぐ橋のようなもので、これがなければ各部分の間の通信は不可能です。一方、モノリシックのサービス同士は密接につながっているため、より高速に通信できます。
マイクロサービスとクラウドコンピューティングの関係
マイクロサービスは、ソフトウェアアーキテクチャのアプローチの一つで、好きな場所に配置できるソフトウェアを構築する方法です。つまり、マイクロサービスアプリは必ずしもクラウド環境で構築する必要はなく、本社にある個人所有のデータセンターでマイクロサービスを構築できます。
マイクロサービスは利用状況に応じてサービスを拡張・縮小でき、クラウドコンピューティングはこの特性を促進するように構築されています。しかし、モノリシックとクラウドコンピューティングには、天と地ほどの差があります。モノリシックなアプリは、クラウド環境に配置することはできても、アプリのアーキテクチャがそのような作業を許さないため、クラウドの機能を利用し、利益を得ることはできません。
一方、マイクロサービスは、アプリがクラウドコンピューティングの機能と同期し、クラウドコンピューティングのメリットを実現できるものです。それゆえ、マイクロサービス上に構築されたアプリは、クラウドネイティブアプリと呼ばれます。
クラウドアプリについてご興味のある方は、こちらの記事も参考にしてください。
関連記事：
マイクロサービスのメリットとデメリット
革新的な技術であるにも関わらず、マイクロサービスは万人に適切に完璧なアーキテクチャアプローチではありません。
マイクロサービスにはメリットとデメリットがあり、それを理解すれば、マイクロサービスに移行すべきかどうかを判断できます。
マイクロサービスのメリット
マイクロサービスの主なメリットは、次の4点です。
柔軟性
各マイクロサービスは独立して作業できるため、別々のチームが異なる機能を同時にデプロイすることで、継続的な改善と迅速なアプリ更新が可能になります。
弾力性
マイクロサービスは、需要に応じて、独立したり規模を拡大したり縮小したりできます。
つまり、アプリ全体ではなく、需要が高まっているサービスだけに容量を追加できるのです。これが、マイクロサービスによる規模拡大を高い費用対効果で実現する理由です。
ダウンタイムの削減
マイクロサービスでは、あるサービスに障害が発生した場合、その障害をほかのシステムから分離できます。
この障害隔離能力により、サービスに障害が発生しても、アプリは稼働し続けます。
より簡単な要因
マイクロサービスは一般的にコードベースが小さいため、開発者はコードを把握し理解しやすく、またサービスの保守や改善もしやすくなります。
マイクロサービスのデメリット
マイクロサービスには、デメリットもあります。
主に、次の5点です。
適切なAPI構築の難しさ
マイクロサービスは独立して動作していますが、それでもアプリ全体として動作させるためには、互いに通信する必要があります。この通信を円滑かつ安全に行うため、適切なAPIを構築することは困難な作業であり、システムを安定的に稼働させるためにそれらのAPIを管理することもまた困難な作業となります。
デバッグの難しさ
エンドユーザーが享受する機能は、多くの場合、多数のマイクロサービスが連携して動作しています。このため、チェックアウトボタンの一つクリックがさまざまなサービスを経由し、チェックアウトを完了するまでに、途中でほかのリクエストの連続を作成する可能性があります。ある機能に障害が発生した場合、どのサービスが問題の原因であるかを追跡することは非常に困難です。
統合テストの難しさ
マイクロサービスでは、ユニットテストは容易かもしれませんが、統合テストはそうではありません。
要因が分散しているため、開発者は所定の要因のセットを必要とする機能をテストする工程に苦労します。
インターフェース制御の難しさ
マイクロサービスはほかのアプリに影響を与えずに更新できますが、API（インターフェース）を変更すると、それを利用しているすべてのマイクロサービスに影響し、正しく行わないと深刻な問題が発生する可能性があります。
マイクロサービスでは必然的に多くのAPIが必要となるため、それらのAPIを効果的に管理することは、アプリを正しく動作させるための必須事項です。
投資額が高くなる
モノリシックなアーキテクチャで運用している場合、データをマイクロサービスにリファクタリングするためには、かなりの投資が必要になります。
また、マイクロサービスを理解し、扱える熟練した開発チームへの投資も必要になります。
マイクロサービスとモノリシックのどちらを採用すべきか？
マイクロサービスとモノリシックはそれぞれ、どのようなケースで採用すれば良いのでしょうか？
マイクロサービス化する場合
マイクロサービスには関連する課題があるため、このアーキテクチャを使用するのは、見返りがある場合に限るべきでしょう。ここでは、一般的な採用ケースは次の通りです。
・ソフトウェア開発において、柔軟性、スケーラビリティ、継続的デリバリーが必要な場合。
・モノリシックなアプリをクラウドに移行したい時。
モノリシックであり続けるために
人々がマイクロサービス化を進めているからといって、それに追随しなければならないわけではありません。モノリシックなアーキテクチャを使うことが最も有益であるような状況もあります。
・最小限の製品でアイデアを試したい時。
・ビジネスや市場の規模によって、柔軟性、スケーラビリティ、継続的デリバリーが必要ない場合。
マイクロサービス活用例
マイクロサービスを活用した著名なサービス例を2つ、ご紹介いたします。
Netflix（ネットフリックス）
Netflixのマイクロサービス化は、2007年に映画ストリーミングサービスを開始した後、サービス停止や規模拡大の問題に悩まされていた2008年に始まりました。Netflixがマイクロサービス化の必要性を認識する転機となったのは、データベースの大規模な破損が発生し、3日間ユーザーにDVDを出荷できなくなった時でした。
その後、Netflixは、AWSが最大の規模と幅広い機能とサービスを提供していることから、AWSを利用してマイクロサービスへ移行するようになりました。2009年、Netflixはモノリシックなアーキテクチャを、サービスごとにマイクロサービスへとリファクタリングし始めました。まず、顧客向けでない映画制作サービスを独立したマイクロサービスとしてAWSに移行し、その後2年間かけて顧客向け機能をマイクロサービス化し、移行は2012年に完了しました。
マイクロサービスにより、Netflixは規模拡大と停止の問題を克服し、2017年には700以上の疎結合マイクロサービスをシステムで稼働させています。現在、Netflixは190カ国の1億3,900万人以上のユーザーに対して、毎日約2億5000万時間のコンテンツを配信しており、今もなお成長を続けています。
Netflixが予想していなかった副次的な効果として、コスト削減が挙げられます。ストリーミングごとのクラウドコストは、個人で運営しているデータセンターの数分の1にまで減少しました。
Uber（ウーバー）
Uberは、そのアプリが爆発的に利用されるにつれ、元来のモノリシックなアーキテクチャによる成長に関する課題に直面しました。新機能の開発、バグの修正、急成長するグローバル事業の把握など、多くの困難がありました。Uberのアプリはモノリシックであるため、簡単なアップデートや変更を行うには、幅広い知識を持つ開発者が必要でした。
これらの問題を克服するために、Uberはシステムをクラウドベースのマイクロサービスに分割することにしました。乗客管理、旅行管理、公正な計算など、異なる機能のために疎結合のサービスを構築しました。マイクロサービス上にシステムを構築したことで、Uberは特定のサービスに対する明確な責任を特定のチームに割り当てることができ、開発のスピードと品質を向上させました。
しかし、Uberにおけるマイクロサービスへの移行は順調に行きませんでした。Uberがマイクロサービスの適用方法を検討し始めた時、約1,300のサービスがあり、中には古いものやもう使われていないものもあったため、変革中にシステムが暴走しないよう、明確な標準化戦略が必要だったのです。
当初、Uberは各マイクロサービスのローカル基準を作成し、それがうまく機能して、マイクロサービスを軌道に乗せることができました。しかし、その後、個々のマイクロサービスは、標準の違いからほかのマイクロサービスと効果的に連携できないことが判明しました。開発者があるマイクロサービスを変更しようとすると、サービス停止を防ぐために、それに関連するほかのマイクロサービスも変更しなければなりませんでした。この問題はプラットフォームのスケーラビリティを阻害するため、Uberは新しいソリューションを見つける必要に迫られました。
結局、Uberはすべてのマイクロサービスのグローバル基準の開発に全力を挙げ、スケーラビリティの問題を解決することに成功しました。
まとめ
マイクロサービスは、多くの企業がその潜在能力を最高に発揮できる画期的な技術です。
しかし、このアーキテクチャのアプローチにはいくつかのトレードオフがあり、それがすべての人にとって完璧なソリューションではありません。
ビジネスと技術的ニーズを理解すれば、モノリシックアーキテクチャにこだわるべきか、それてもマイクロサービスに移行すべきかを決定できるでしょう。
CMC Japanについて
ベトナム第2位のICT企業である当社、CMCグループは、ベトナム政府主導の新型コロナウイルス対策に準拠し、ハノイおよび、ダナン・ホーチミン市の３拠点で、オフショア開発を継続して提供しています。
中長期的なリソース計画や開発コストの最適化をご検討の企業様は、お問い合わせフォームよりご連絡ください。
当社は日本のお客様に「止まらない、持続可能な開発」をベトナムオフショア開発で支援しています。
