マイクロサービス導入が進む理由とモノリシックとの対比

マイクロサービスとは

マイクロサービスの特徴

マイクロサービスとは、「機能を分解して小さなサービスを作り、それらを複数のアプリケーションの集合体として連携させていくことで一つの大きなソフトウェアを構築する」というソフトウェア・アプリケーション開発の新しい開発手法です。
2014年に、米国の著名なソフトウェアエンジニアであるマーチン・ファウラー氏らが公開した「Microservices」という記事から提唱され始めました。
急速なビジネスの変化に応じたサービスを提供するため、アジャイル開発手法が取り入れられる機会が増え、より効率よく高速にシステムを回せる仕組みとして、マイクロサービスが注目されるようになりました。
上記の説明では抽象度が高いため、ショッピングサイトを例に具体的に見てみましょう。

＜オンラインショッピングサイトで見るマイクロサービス＞
ショッピングサイトを一つの大きなサービスとします。このサービスを実行させるにあたり、マイクロサービスでは以下のサービスを個別に開発しています。
ブラウザ画面：ユーザーインターフェース（IDやパスワードによる認証システム）
ビジネスロジック：おすすめ商品の通知や好みのサイズ・色のフィルタリング
データ：在庫管理・配送ステータス管理など

上記機能がそれぞれ別のマシン上で実装されており、通信システムとAPI（連携システム）によって統合され、ショッピングサイトを構成しています。

モノリシックとの違い

従来の開発の基本だったモノリシックアーキテクチャの特徴を見てみましょう。
モノリシックとは、アプリケーションを1つの大きなものとして開発する考えです。
「モノリス＝一枚岩」が語源のとおり、大きな岩の塊のようにソフトウェア全体が1つのモジュールとなっている構造を「モノシリックアーキテクチャ」といいます。
仕様の変更や修正が少ない、ウォーターフォール型開発手法で多く取り入れられてきました。
上記のショッピングサイトの例では、モノシリックはUIからデータベースまで全て1つのシステムで実装されている仕組みとなります。

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

アジャイル開発に適しているマイクロサービスですが、具体的にどういったメリットがあるのでしょうか。 また、マイクロサービスの課題を把握した上で導入を始めないと開発が頓挫してしまう可能性もあります。モノリシックの場合と比べながら、メリットとデメリットを見ていきましょう。

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

新しい技術の採用・機能追加がしやすい

モノリシックでは、サービスのレイヤーに合わせた技術を選択したくても、ソフトウェア全体が使用している技術に縛られてしまう点がネックでした。
マイクロサービスでは、APIの仕様を守ればそれぞれ全く別の言語で作ることが可能なため、個々のサービスに適した技術を採用できます。そのため新しい技術も取り入れやすく、新たな機能の追加も容易な点が特徴的です。
開発時点で仕様が決まっていない場合や、機能の修正や追加を前提としているアジャイル開発手法に適していると言えます。

障害に対応しやすく、保守も容易

モノリシックアーキテクチャでは、障害発生時に発生場所の究明に時間がかかることやシステム全体に障害の影響が及ぶ恐れがあるといった欠点がありました。
また、障害が一部分であったとしても、対応するときにはサービス全体をストップさせなければならないため、効率的とは言えませんでした。
それに対してマイクロサービスは、機能が分割されていて個別に対応できるため、他のサービスに影響を与えることなくロールバックやデプロイができます。
また、リリース後に一部のサービスのコードをより優れたものに改善することや、不要になったサービスを削除するといった保守作業が行いやすい点も特徴的です。

開発期間を短縮でき、リソースを有効活用できる

モノリシックでは、開発→テスト→デプロイ→運用のサイクルそれぞれをバックエンドチーム、テストチーム、オペレーションチームなどと分けるスタイルが基本的です。
ただ、複数のサービスを同時進行させていく場合、負担が一部に偏ってしまうこともあり得ます。
一方でサービスごとに独立したチームで作業できるマイクロサービスでは、それぞれのチームが開発の全フェーズを扱うため統率が取りやすく、作業の無駄を省けるので開発時間の短縮に繋がります。
また、サービスに合わせて適切にシステム資源を割り当てられるため、リソースを有効活用できるというメリットもあります。

機能の再利用、共有が可能になる

マイクロサービスでは機能を細分化するので、異なるサービス同士で機能を共有したり再利用したりできるというメリットがあります。
似たようなサービスを作るときに一からコードを記述する必要が無いため、開発効率の向上につながります。

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

不具合が生じやすくなる

マイクロサービスには個々のサービスを繋ぐ連携システムが必須です。
その通信過程で不具合が生じると遅延やロスが生じるので、モノリシックと比べて速度が落ちてしまうことがあります。
また、マイクロサービスは単一サービスとしての最適化だけでなく、全体のモジュールの最適化も行うようにサービス間でコミュニケーションを取っておかないと、処理が重複したり不足したりしてしまうこともあるので注意が必要です。

バージョン管理、監視の必要性

モノリシックよりも注力する必要があるのが、サービス間の互換性と統合管理です。
1つの製品にマイクロサービスが複数ある場合、それぞれのシステム更新に伴った統合管理とテストが必要になります。
また、エラーが生じたときに依存しているサービスが複数あった場合はそれぞれのサーバーのログを見る必要が生じ、その原因はサービスの1つにあるのか、それとも小さなエラーが複合的に重なって生じたのかがわからないことも。
こういった問題に対処するために、各サービスを横断して1つのダッシュボードに管理するような仕組みやCI/CDのような自動化システムを用意する必要があります。

チーム分けをミスすると失敗しやすい

フェーズごとのチーム分けのままマイクロサービスを導入してしまうと、複数のサービス開発を同時進行するとき、一部のフェーズに負担がかかってしまうことがあります。
マイクロサービスは開発のフェーズごとではなく、サービスごと、事業ごとにチームを構成するのが基本です。
1つのチームで開発から運用まで全て行う方式で進めれば、サービスの数が増えてもどこかがオーバーヘッドすることを避けられます。
また、中には複数のサービスと共有して使うシステムも出てくるため、あらかじめ共有する機能を把握しておく必要もあるでしょう。

幅広い知識と高度な技術力が必要になる

サービスごとにチーム編成をするということは、各チームに開発から運用まで対応できるエンジニアが必要になるということです。
また、サービス間を連携させる際には、サービスの数が多いほど統合テストやバージョン管理も複雑になります。
そのほか、外部にAPIを公開する際の互換性の検証、品質や安定性の保証といった考慮しなければならない事項が増えていきます。
マイクロサービスを最大限に活用するためには、幅広い知識と高い技術力が必要になるという点は考慮しておきましょう。

マイクロサービスとモノリシックの使い分け

今まで見てきたように、サービスの規模が小さく数が多いほど、マイクロサービスのメリットとデメリットが最大化します。
互換性や監視を徹底できていれば、よりサービスの向上に注力でき顧客体験の向上につなげることができます。
とはいえ、シンプルなアプリケーションを開発する場合や分散トレーシングで対応できる場合は、無理にマイクロサービスを導入する必要が無いこともあります。
シンプルなサービスで高速な動作を求める場合はモノリシックの方が適しており、変更や修正を継続的に行い複雑になりやすいシステムや巨大化する可能性がある場合はマイクロサービスが適していると言えるでしょう。

マイクロサービス導入にあたって

導入のコツ

全ての機能やデータベースをマイクロサービスに移行するのは莫大な工数がかかります。
まずは、課題が明確な機能やサービスに限定して最適化を目指すといいでしょう。
また、データベースの変更は既存の機能に影響を与えやすいため、分離しやすいフロントレイヤーから移行を始め、最後にデータベースの移行に時間をかけると負担が少なく済みます。

マイクロサービス導入に必要なツール・関連用語

連携システムや自動化テストなど、マイクロサービスには欠かせないツールがいくつかあります。エンジニアとして知っておくべき用語なので、ひと通り把握しておきましょう。

アジャイル開発手法・DevOps

アジャイル開発手法は、短期間で開発→テスト→デプロイ→運用のサイクルを回し、ブラッシュアップを重ねることで高品質なものを作ることができるので、ユーザーのニーズに素早く応じることができます。
マイクロサービスにはアジャイル型手法が適しているため、もともとウォーターフォール型で進めてきた企業では、開発プロセスだけでなく組織や企業文化もアジャイル開発に順応させる必要があります。
また、類似の開発手法として知られているのが「DevOps」です。開発担当と運用担当が密に連携を取り、柔軟にニーズに対応してスピードと成果を求める手法です。マイクロサービスではより開発と運用の連携が必要になるので、DevOpsも欠かせない考え方となります。

API

API（Application Programming Interface）とは、あるプログラムから他のプログラムの機能を呼び出すための連携システムを指します。代表的なものに、REST APIがあります。

「REST API」

クラウド環境上でマイクロサービスを導入する際に適していて、シンプルな構造でHTTPベースでやりとりを行えるため、多くの場面で活用されています。
プライベートクラウドとパブリッククラウドを連携しているハイブリッドクラウド環境や、複数のパブリッククラウドを介して使うマルチクラウド環境で開発を行うのに向いています。

コンテナ

コンテナとは、OS上に個々のアプリケーションの専用区画を作る仮想化技術の1つです。
プロセスごとにコンテナが整備され、プロセス間の連携をAPIで行っていきます。機能変更が生じた際もコンテナ単位での入れ替えが可能なので、スピーディに対応できます。

基盤技術コンテナ「Docker」

Linuxのコンテナ技術を使ったもので、他の仮想化技術と比べて軽量で高速に動作するのが特徴です。
ユーザー空間を分割して1つのPCで異なる環境を作成でき、オープンソースの管理システム「Git」などを利用してバージョンを管理しておくことができます。
スクラップとビルドが容易にできるという点においても、リリースサイクルの改善に役立ちます。

オーケストレーター「Kubernetes」

数が増えて複雑になったコンテナを自動で管理し、組み合わせる機能のことをオーケストレーターといいます。その代表的なものが、Kubernetesです。
具体的には、コンテナのスケジューリングやローリングアップデート、サービスディスカバリ、ログの管理のような役割を担います。コンテナの数が増えるほど、活用意義が高くなります。

サービスメッシュ「Istio」

サービスメッシュとは、「メッシュ＝網」の言葉の通り、多数のサービスが複雑に繋がっているマイクロサービスで生じやすいオーバーヘッドや不整合といった問題を解決するための機能のことを指します。
マイクロサービスごとにプロキシ（代理接続するサーバー）を設置し、それを経由して他のサービスと連携して互いの依存関係やトラフィックを制御していきます。
Istioは、Google、IBM、Lyftに共同開発されたオープンソースのサービスメッシュであり、分散システムのモニタリングやネットワーク障害・セキュリティ対策を行います。
Kubernetesがインフラレベルで機能するのに対し、Istioはアプリケーションレベルで機能するものになります。

トランザクション

データベースのパフォーマンスを評価する際によく使われるトランザクション。マイクロサービスでは、分散トランザクションという言葉も多用されます。
トランザクションとは、データベースを主とした管理システムの中で実行される、分けることができない一連の処理の単位のことを示します。
「取引」という意味の通り、銀行の口座取引の場でも活用されます。
例えば、「A銀行の口座から5,000円を引き出し、B銀行の口座に振り込む」という一連の動作を行うとします。
もし入金の途中で失敗してしまうと、A銀行の残高では5,000円減っているのにB銀行の残高は5,000円プラスされておらず、その5,000円は消失してしまうことになります。
こういった中途半端な事態を防ぐために、2つの動作を一連の動作として扱うと、Bの残高が増えていなければ、Aの残高も減っておらず「トランザクション失敗」という判定ができ、「成功か失敗か」の2択で済みます。
そして「分散トランザクション」とは、こういった作業が複数のデータベース管理システムに分散されることを指し、マイクロサービスではより多用されるため、ワークフローの管理を徹底する必要があります。

サーバーレスアーキテクチャ

マイクロサービスの基盤技術としてコンテナが広く使われていますが、コンテナは開発者が運用・管理しなければならず、メモリーやストレージも有限です。
それに対して、必要に応じてリソースを割り当てられるプラットフォームとして、クラウドサービスを活用した「サーバーレスアーキテクチャ」があります。
主に、AWS LambdaやAzure Functions、Google Cloud Functionsが該当します。
使用できる言語やライブラリ、機能はプラットフォームによって異なるので、環境に合わせて選択する必要があります。

マイクロフレームワーク

マイクロサービスの構築に適したフレームワークを「マイクロフレームワーク」あるいは「マイクロサービスフレームワーク」「軽量フレームワーク」といいます。
必要最低限の機能を揃えてシンプル、かつ軽量のため、小規模のアプリケーション開発に向いています。ルールも少ないので学習コストが低い点もメリットです。
代表的なものに、PHPのマイクロフレームワークに「Lumen」や「Slim」、Javaの「Lagom」、Pythonの「Bottle」などがあります。

マイクロサービスの実際の導入事例

クックパッド株式会社

レシピ投稿、検索サービスだけでなく「食を中心とした生活のインフラ」として様々なサービスを展開しているクックパッド。
アプリから生鮮食品を購入できる「クックパッドマート」や食育を絵本にして提供するサービス「おりょうりえほん by cookpad」、料理動画サービスの「cookpadDining」など、サービスそれぞれのユーザーに合った技術選定を行うために、マイクロサービスを導入しています。
各サービスはレシピサイトを基盤としているものも多いため、同じドメインモデルを別バージョンで提供したり、サービス同士を組み合わせたりと柔軟な連携システムを構築しています。

Amazon.com

Amazonはマイクロサービスという言葉が出てくる前から導入しており、今やマイクロサービスを構築するプラットフォームやデータベースの提供まで行っています。
REST APIで連携させるシステム作りからスタートし、「各チームがそれぞれのサービスを良くするべく動機を持つべき」という意識でマイクロサービス化を進めました。
「Two-pizza teams」と呼ばれるマイクロサービスの細分化の基準、「2枚のピザで満腹にならないような規模のチームは作るな」というルールは有名ですよね。
Amazonでは、何千ものチームそれぞれに責任者がおり、2014年の時点で年間5,000万回のデプロイが行われていたそうです。

Netflix株式会社

AWSを早くから活用していたとされる米国ストリーミング配信事業のネットフリックスは、マイクロサービスと継続的デリバリを組み合わせてサービスの迅速さと冗長性を両立しています。
導入のきっかけは、当時提供していたDVDレンタルサービスのデータベースに重大な障害が発生し、DVD発送業務が3日間停止する事態に陥ったことにあります。
モノリシックでは1か所の障害がシステム全体へ影響を与えるということを痛感したため、マイクロサービス化による分散システムへ移行しました。
2億人を超えるユーザーを抱え、かつユーザーのUXが重要なサービスを提供している同社では、システム全体の不具合は致命的です。
同社のエンジニアは毎日数千ものコードセクションをデプロイし、継続的な顧客体験の向上を図っています。

まとめ

今回は、マイクロサービスの特徴やメリットとデメリットについて、モノリシックと比較しながらお話ししてきました。
DXが推進され「顧客体験の向上」の重要性が認識されると、より開発のサイクルはスピードアップし効率性と品質の高さが求められます。
フリーランスエンジニアとしての市場価値を高めるには、マイクロサービスやアジャイル開発手法について知見は欠かせません。
実際にマイクロサービスの現場に携わったことがないという方でも、メリットとデメリットについて理解し、適している現場とそうでない現場について自分なりの見解を持っておく必要があるでしょう。
マイクロサービスを導入している案件で経験を積むと、更なるキャリアアップに繋がります。
「実際にどういった企業がマイクロサービスを採用しているのか聞いてみたい」、「具体的にどんなスキルがあれば活躍できるのか知りたい」と思ったら、ぜひエージェントを活用してみてくださいね。

お役立ち記事一覧へ