マイクロサービス・アーキテクチ...
マイクロサービス
マイクロサービス・アーキテクチャのメリットを解説!DX推進の切り札となるか?
アンドエンジニア編集部
2021.04.01
この記事でわかること
1.今話題のマイクロサービス・アーキテクチャの概要について知る
2.マイクロサービス・アーキテクチャのメリット・デメリット・導入時の留意点を知る
3.マイクロサービス・アーキテクチャがDX対応の切り札となる可能性がある

マイクロサービス・アーキテクチャとは

マイクロサービスとは、読んで字のごとく、小さなサービスです。マイクロサービス・アーキテクチャは規模の小さなサービスを幾つも組み合わせて、1つのアプリケーションとして活用する、ソフトウェア開発の1つの技法です。(以降、マイクロサービスと呼びます)

これまでは、あらゆる機能を1つにまとめた形でソフトウェアを設計するのが一般的でしたが、マイクロサービスでは機能を細かく分けて、それぞれを小さなサービスとして作り、それらを組み合わせて、1つの大きなソフトウェアを構成します。

それぞれのサービスは小さいのですが、それぞれが自らの役割に専念して、自律的に活動するのがマイクロサービスの基本要素です。

それぞれのサービスは独立しており、OSやハードも別です。互いにネットワークを介して繋がり、必要な機能はネットワーク経由で他のサービスに提供します。

マイクロサービスアーキテクチャとは?詳細と課題について徹底解説!

マイクロサービスを例えると?

経営に置き換えると、アメーバー経営に近いでしょう。アメーバー経営では、組織はアメーバーと呼ぶ小集団に分かれ、それぞれがアメーバーの計画を立て、メンバーが協力し合って小集団の目標を達成します。マイクロサービスはこのようなイメージです。

マイクロサービスは政治に例えると、中央集権政治ではなく、地方分権政治と言えます。アメリカ合衆国なども地方分権の連邦制ですね。

それぞれが独自の州法を持ち、統治を行っています。日本は中央の権限を地方に少し譲るという考え方ですが、アメリカは州があって連邦があり、州の権限を連邦に譲るという考えが基本です。

ですから、マイクロサービスはアメリカ合衆国型のようなサービスと言うこともできるでしょう。

マイクロサービスとモノリシック

マイクロサービスが新しい技法ですが、このマイクロサービスの対極に位置するアーキテクチャは従来型の「モノリシック」です。

「モノリシック」とは1枚岩のことです。「モノリシック」はソフトウェアの設計において、機能ごとに分割せず、全てを1つのモジュールとして考えます。まさに、マイクロサービスとは真逆の考え方です。

マイクロサービスの導入企業

マイクロサービスは先進的なアーキテクチャで、既にLINEやAmazon、Facebookなどの大手企業が導入しています。どの企業も大変なスピード成長していますが、それがマイクロサービス採用の理由です。

なぜなら、マイクロサービスはビジネスモデルの早い変革に最も適応するアプリケーション開発方式だからです。ちなみに日本ではクックパッドがいち早くマイクロサービスを導入しています。他、メルカリ、Netflixなどが有名です。

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

経済産業省がDX推進と併せて提唱する「マイクロサービス」を提唱していますが、マイクロサービスにはどんなメリットがあるのか、探っていきましょう。

開発期間の短縮

マイクロサービスでは「開発期間の短縮」が可能となります。その背景としては「それぞれが小さな、特定の機能に特化した」サービス単位で、しかも小さなチームで開発しますので、効率的に、俊敏な対応が行えることなどがあげられます。

個別のスケーリングでコスト抑制が可能

マイクロサービスは各サービスごとの機能要求に応じて、個別にスケーリングが可能です。この結果、柔軟性のある適正なスケーリングを行え、必要なリソースも抑制でき、コスト面、人的面でもメリットを得られます。また、各サービス単位で処理能力を調整することがてきるため、無駄が発生しません。

個別管理が行いやすい

1つ1つのサービスが小さいため、状況の把握や管理がしやすく、何か問題が起きてもサービス単位で対応が可能なため、迅速な対応が行えます。

柔軟性に優れている

サービスが小さく、それぞれが独立しているため、個々のシステム変更や改修が行いやすく、また最新技術などを採用しやすいという柔軟性が強みです。

ビジネスに合わせて組合せが可能

機能が細分化されており、必要な機能を取り出して組合せる、あるいは再利用するといったことが柔軟に行え、新たなビジネスのために1から機能を開発する必要がありません

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

マイクロサービスにはさまざまなメリットがありますが、まだ新しいアーキテクチャということもあり、十分な受入れ体制が整わない企業で採用すると、逆にデメリットとなるケースも想定されます。以下、課題や留意点として認識しておいてください。

マイクロサービスの経験や専門知識が必要

マイクロサービスは利用されだしてから数年程度しか経っていないため、マイクロサービスの経験者や専門知識を持つエンジニアが不足しています。こうしたエンジニアの確保ができないまま導入すると失敗する可能性があります。

柔軟がゆえに運用が複雑になる

マイクロサービスは個々のサービスについて、異なるOSや異なる技術を使うことが可能です。そのため、運用業務には一貫性がないため、これが運用業務を妨げることになりかねません。

チーム間の連携が課題になる

マイクロサービスの個々のサービス機能開発は、サービス単位で編成されたチームに任されます。それぞれが異なる分野の開発を行うため、チーム間の報告や連絡、情報共有などが難しくなります。これを円滑かつ効率的に行うための共通ルールが新たに必要になります。

新たなセキュリティリスクが生まれる

サービスが分散するマイクロサービスでは、1つにまとまった「モノリシック」のサービスと比較してセキュリティ面が弱くなりがちです。それぞれのサービスごとにセキュリティを確保するには、マイクロサービスに適応したセキュリティに関するノウハウの獲得が必要になります。

システム全体のモニタリングが必要

個別のサービス単位のモニタリングは容易に行えても、システム全体の状況を把握する必要があります。また、障害が発生した際の対応についても、全体への影響を考慮しなくてはなません。つまり、分散でありながらも全体コントロールの中央機関が必要となり、そのノウハウも新たに獲得しなければなりません。

マイクロサービスで失敗しないために

マイクロサービス化を推進していく上で、技術的な面での準備が必要なことはお分かり頂けたと思いますが、ここでは主に考え方を中心に、マイクロサービスで失敗しない考え方を述べていきます。

マイクロサービスの分割レベルに配慮

マイクロサービスを採用する場合、それぞれに求められる機能を分割する際のサイズが重要です。機能の分割を細かくしすぎると、全体のコストアップやパフォーマンス低下を招く可能性があります。

かといって、機能分割の単位が大き過ぎるとマイクロサービスのメリットが得られません。コスト、パフォーマンス、運用管理面の負荷など、さまざまな視点から分割単位の最適解を求めることが求められます。

アジャイル開発手法を検討する

マイクロサービスはサービス単位に少人数のチームで開発すると述べましたが、少人数のチームで従来のウォーターフォール型開発を行っていたのでは、開発の効率が悪すぎます。少人数で機能ごとに開発を進めるアジャイル開発方式が、マイクロサービスには最適と考えられます。

イテレーション(反復)と呼ばれる短期間での工程を反復する方法によって、要求仕様と結果の乖離を防ぎながら、効率的に開発を進められます。

ハイブリッド型も検討してみる

マイクロサービスは従来のモノリシックと比較して、全ての点で上回っているわけではありません。また、マイクロサービスの推進者たちもモノリシックを否定しているわけではないのです。

既存システムのマイクロサービス化を検討する際は、たとえばメインの処理をモノリシックで残し、一部の機能はマイクロサービス化を行い、ハイブリッド型の構築を行うという手法も選択肢になり得ます。

「マイクロサービスが主流だから」、「AmazonやLINEが採用しているから」といった安易な発想でマイクロサービスを採用すると失敗する可能性があります。身の丈に合う形で、出来るところから採用していく、マイクロサービスが最もパフォーマンスを発揮できる分野から始めるという姿勢が求められます。

焦りは禁物

既存システムをマイクロサービスで再構築するのは非常に難易度が高いと認識しておくことが重要です。マイクロサービス化を果たしたNetflixでさえも、モノリシックからマイクロサービスへの移行に2年を要したそうです。

中長期の視点でロードマップを描き、小さな改善を積み上げていくという姿勢で臨んでください。「ウサギと亀」の亀で構わないのです。マイクロサービスを進める上ではスピードよりも、着実に進めることが肝要です。焦りは禁物です。

マイクロサービスとDX

今や、日本はDXブームです。DXの波に乗り遅れると企業の未来が無くなるのではないかと、不安を抱く経営者もいます。それは逆に、私たちエンジニアが活躍の場を与えられる絶好のチャンスです。

そして、こんな時だからこそ、マイクロサービスを用いたITシステムの再構築にチャレンジできるのではないでしょうか。ここではDXとマイクロサービスの関係について述べていきます。

DXとは?その意味と日本の現状、DX推進の障壁となる要因を分かりやすく解説!

マイクロサービスは政府の提言

日本はシステムの複雑化、老朽化、ブラックボックス化で危機に瀕していると、経済産業省が「2025年の崖」と呼んで、同省が公開した「DXレポート」で警鐘を鳴らしています。「DXレポート」によると、日本企業がシステム開発に採用すべきとされているアーキテクチャは「マイクロサービス」なのです。

遅々として進まないDX化

政府主導のDXですが、DX推進は企業にとっても「勝ち組」と「負け組」の岐路になってきました。企業は、お荷物となってきたレガシーシステムを捨てるのか、再構築するのか、残すのかの選択を迫られています。

しかし、既存システムに新技術の組込みをうまく行えないケースが多発しているようです。特に既存システムが巨大なモノリシック型のシステムとして定着している場合、システムが複雑化・ブラックボックス化してしまい、新技術の組み込みが困難な状態になっているケースも少なくありません。

既存システムの新技術組み込みの必要性が分かりながら、なかなか手を付けられないジレンマに苦しむIT関係者が数多くいます。

マイクロサービスはDXの切り札となる?

一方、DX推進の救世主となり得るのが「マイクロサービス」です。顧客やユーザーから見た機能ごとにシステムの機能を分割し、それぞれを連携させるのです。たとえば、私たちが利用しているLINEアプリは、トーク(メッセージ)機能以外に、タイムライン、ニュース、ウォレットなどの機能に分かれています。

この1つ1つの機能がマイクロサービスです。基幹システムも、従来は受発注在庫管理システムとして1つだったものを、受注システム、発注システム、在庫管理システというように機能ごとに分割すれば良いのです。

それぞれが連携する必要があるので、一見複雑に見えますが、連携のためのデータ形式や呼出しの手順などが明確になり、またそれぞれのサービスが分離されることで、見える化が行え、新技術の組込みも行いやすくなります。

マイクロサービスは政府が推奨する通り、DXの切り札になる可能性を秘めています。既存システムのマイクロサービス化を進めながら、併せて新技術の組み込みを図ってDX化を進めていくのがよいでしょう。ITエンジニアの皆さんには、この機会にマイクロサービスに関する勉強をされることをおすすめします。

この記事をシェア
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!