マイクロサービスの向き・不向きや事例、失敗しないためのポイントをご紹介

マイクロサービスは単一のアプリケーションを小さなサービスの集合体として構成する手法・アーキテクチャのことです。個々のサービスを個別に更新または修正することができる特徴があり、それによりアプリケーションのメンテナンスが容易となり、アプリケーションの潜在的なダウンタイムを減少させることができます。

クラウドネイティブアプリケーションやマイクロサービスを利用したWebアプリケーション、分散サービスやリアルタイム処理など、マイクロサービスの特性が用途に合致する場面が増えています。その結果、アジリティ（俊敏性）や効率性、スケーラビリティが向上し、開発およびメンテナンスに関連するコストを削減しながら、より優れたパフォーマンスと信頼性を実現しています。この記事では、マイクロサービスの運用に向いている・向いていないケースや、運用に失敗しないポイントなどをご紹介します。

マイクロサービスとは

マイクロサービスとは、複数の小さく独立したサービスからなるアプリケーションを構築するための手法・アーキテクチャです。各サービスは独立して実行・展開でき、コードのプロビジョニングと展開にかかる時間はわずか数秒から数分とかなり軽量です。

マイクロサービスは独立性の高い複数の小さなサービスで構成されており、各サービスはビジネスロジックがカプセル化され、他のサービスとは別に構築して修正が可能です。この構造により、迅速かつ確実な変更が容易になります。さらに、マイクロサービスではアプリケーションの特定の部分を容易に複製することもできるため、企業は必要に応じてスケールアップやスケールダウンを行い、パフォーマンスの最適化を実現する事ができます。これらの特徴により、アプリケーションを継続的に更新し、環境の変化に適応させる事が可能となっています。

マイクロサービスについては、以下の記事にて詳しく紹介をしています。

マイクロサービスとは？仕組みやメリット、導入の手順や注意点を紹介

マイクロサービスの運用に向いているケース

1.大規模なシステム開発を進めるケース

マイクロサービスは開発を小さなブロックに分割することで、各サービスが持つ個別のコードベースをより効率的かつ独立して開発・管理できます。それにより、迅速なデプロイと修正が可能になるため、大規模なシステム開発を行う場合に適しています。開発時にはそれぞれのチームが異なるサービスの開発を担い、並行してタスクを共同して進めることが可能です。これにより、複雑なタスクや成果物をより小さく管理しやすい形に分解し、アジャイル開発モデルで同時進行での作業ができます。
さらに、マイクロサービスは、さまざまなアプリケーションでコンポーネント要素の再利用を可能にするように設計されています。これは、開発者がコンポーネントを再利用し、開発時間を短縮し、関連するコストを削減できることにつながります。

マイクロサービスのもうひとつの大きなメリットは、ソフトウェアのスケーラビリティ（拡張性）です。これにより、開発者はコード全体の構造を変更することなく、必要に応じて個々のサービスを迅速に拡張したり、「スピンアップ」したりすることができます。さらに、マイクロサービスではシステムのどのコンポーネントも、アプリケーションの残りの部分に影響を与えることなく迅速に更新できます。

2.アプリケーションが多機能、複雑なケース

従来のソフトウェアエンジニアリングの手法と比較して、マイクロサービスアーキテクチャは個々のサービスが独立してデプロイ、更新、監視できるため、開発プロセスがシンプルで、管理が非常に簡単になります。さらに、サービスはあらかじめ定義されたAPIを通じて互いに通信するため、アプリケーション間の依存性を下げることが可能です。マイクロサービスの特徴により、実装、スケーラビリティ、トラブルシューティングが簡素化し、大規模なアプリケーションを開発に適しています。
また、1つのモノリシックなソリューションではなくマイクロサービスは高度に独立で疎結合しているため、開発期間を短縮し、システム全体を潜在的な障害から防ぐことができます。

3.システムの無停止時間が厳格なケース

マイクロサービスはシステムが稼働していることを厳しく要求され、運用効率が最も重要視されるケースに最適なサービスです。例としてSaaSアプリケーション、リアルタイムストリーミングサービス、銀行アプリケーションなどです。アプリケーションを独立して展開可能な一連の小さなサービスに分解することで、システムの稼働時間を最大化するためのアプリケーション構成にすることが可能です。さらに、マイクロサービスは新機能の迅速な開発を可能にし、より優れたスケーラビリティとロールバック機能を実現します。つまり、新機能と修正を迅速かつ容易にテストし、デプロイすることができるのです。
多くの場合、マイクロサービスアーキテクチャを使用することで、外部の開発者がコードベースの完全な統合を必要とせずマイクロサービスの機能を活用したアプリケーションを作成する機会も広がり、システムのスケーラビリティをさらに促進することができます。高度なクラウド技術が利用可能になり、マイクロサービス基盤のサポートが強化されたことで、高い稼働率とスケーラビリティを実現するための選択肢はこれまで以上に増えています。

マイクロサービスの運用に不向きなケース

1.小規模なシステム開発を進めるケース

小規模なシステム開発を進める場合においては、マイクロサービスに適応させるためのシステムアーキテクチャの設計や分析に必要な時間や労力が、アプリケーションの規模に対して大きすぎてしまう可能性があります。さらに、アプリケーションの管理は、モノリシック・アーキテクチャの場合はアプリケーションデータベースを共有しますが、マイクロサービスではそれぞれにのデータベースにデータまたは外部の状態を保持する役割を担う違いがあります。特に、マイクロサービスが十分に安定しておらず変更される可能性がある場合、その変更のためにシステムアーキテクチャ全体を再設計しなければならないケースが考えられます。
さらに、多数のマイクロサービスを個別に管理しなければならないというオーバーヘッドがあまりにも大きな負担となることもあり、アプリケーションの規模が小さいとマイクロサービスの運用に不向きです。

2.提供するサービスが簡素なケース

分散アーキテクチャによるメリットが少ない場合は、マイクロサービス運用に不向きです。例えば、コンテンツの表示のみを行うアプリケーションで、スケーリングや並列化が必要なバックエンド処理がないケースです。この場合、マイクロサービスのアーキテクチャを選択すると、人的リソースとハードウェアリソースの両方においてコストが高くなってしまうなど弊害が発生します。
一方、アプリケーションが分散並列化と独立したスケーリングの恩恵を受けるさまざまなコンポーネントを含む場合、マイクロサービスによって価値とスケーラビリティを高めることができます。さらに、アプリケーションがサービスを独立して動作させる必要があれば、モノリシックなアーキテクチャでは困難ですが、マイクロサービスでは各サービスが独自のインフラを持つことができるため自律性が確保されます。そのため、1つのアプリケーションを複数の技術チームが担当するような場合に適しています。

このように、マイクロサービスベースのアーキテクチャが有効なのは、顧客要件の機能をカプセル化することが優先的である場合や、複雑な計算を行うサービスや複数の独立したコンポーネントを含む場合と言えるでしょう。

マイクロサービスの運用事例

Amazon、Netflix、Uber、クックパッド、Lineなどの大企業が、従来の開発手法である全てを１つのアプリケーションとして開発されたモノリシックなアプリケーションを解体し、マイクロサービスのアーキテクチャにリファクタリングしています。いくつか、マイクロサービスの運用事例をご紹介しましょう。

1.Amazon

Amazonでは、独立した各サービスのオーナーシップを開発チームに移管しました。そして、マイクロサービスをつなげて（Web API）、より大きなアプリケーションを形成することについて、Amazon AWSの製品管理担当シニアマネージャーであるロブ・ブリガム氏が以下のように述べています

「関数の単一目的化問題の解決のために、デベロッパーが守るべきルールとして、関数は独自のWebサービスAPIを通じてのみ、他の世界と通信できるようにしたのです。標準的なWebサービス・インターフェースに従う限り、これらのサービスは、サービス間の調整なしに、互いに独立して反復することができます」（参考：https://thenewstack.io/led-amazon-microservices-architecture/）

2.Netflix

Netflixではデータベース障害によりサービス停止した経験から、クラウドサービス活用を選択し、サービスごとにマイクロサービスへの変換を進めました。結果として、数千のマイクロサービスから構成されたシステムとなり、毎日20億以上のAPIリクエストに対応することが可能となっています。

▼参考サイト
https://www.integrate.io/jp/blog/microservices-examples-ja/
https://ec-orange.jp/ec-media/?p=23458

マイクロサービスの運用に失敗しないためのポイント

1.サービスの分割を明確にできている

マイクロサービス運用の失敗を防ぐには、サービスの分担を明確にすることが重要です。マイクロサービスは可能な限り独立させ、個々のサービスのニーズに合わせます。これにより、他のサービスに過度に依存せず、迅速かつ効果的に変更とリリースができるようになります。
個々のマイクロサービスは1つの目的だけを果たすように設計することで、テスト、デプロイ、監視、およびスケーリングが容易になります。異なるマイクロサービス間の境界を明確にし、サービスが密結合になりすぎないようにすることが重要です。これにより、影響を受ける可能性のあるサービスの数を減らすことができ、問題解決やデバッグが容易になります。

2.障害発生時にも動作するような設計である

障害が発生しても運用できるようにシステムを設計することです。その設計の中には、フォールトトレラント、パーティショニング、フェイルオーバー、堅牢なメッセージング、保存されたコンポーネントの耐久性、分散コンピューティングなど、多くの考慮点や要素が存在します。これらの対策は、すべて通常時はもちろん、障害が発生した場合においても、システムがその機能を確実に実行できるようにするために必要です。さらに、1つまたは複数のコンポーネントに障害が発生してもアプリケーションが機能し続けることができるよう、システムにはフォールトトレランス機能が必須になります。

3.管理や運用体制を確立している

標準的なサービスレベル目標を策定し、それを実施することが非常に大切です。さらに、セキュリティとコンプライアンスのガイドラインを設定することが重要になります。特定の役割と責任を持つ専門のマイクロサービス運用チームを持つことは、チームの効率を高め、タイムリーにマイクロサービスの問題・課題へ対応することにつながるでしょう。例えば、簡単なトラブルシューティングガイドを作成することでスキルセットを向上させ、不具合やエラーが発生した場合に備えることができます。
マイクロサービスと関連サービスの、包括的なモニタリングとロギングも実施する必要があります。そして、最後にマイクロサービスのパフォーマンスを監視するため、サービスレベルアグリーメント（SLA）をきちんと定義しておくことが不可欠です。

4.サービス間のバージョン管理ができている

サービス間のバージョンの不整合でサービス同士が連携できなくなる可能性があるためバージョン管理を行うことが重要です。それによって複数の開発者が独立して作業することができ、また、どのサービスも壊す心配なく変更を実装して本番稼動させることができます。さらに、ユーザーは詳細なバージョン履歴を確認することができるため、どのユーザーもコードが時間とともにどのように更新されてきたかを知ることが可能です。場合によっては、変更によって発生する可能性のある問題を事前に発見することができるかもしれません。
バージョン管理は、データの整合性と一貫性をもたらします。マイクロサービス間で共有されるデータの不一致を避けるために、変更のたびに検証され更新される必要があります。

まとめ

マイクロサービスについて導入時のメリットは多くありますが、実際に適用するには様々な考慮点があり、事前の検討がとても重要です。本記事では、マイクロサービスに「向いている」「向いていない」を、それぞれ以下の内容でご紹介しました。

【マイクロサービスが向いている】
・大規模なシステム
・アプリケーションが多機能、複雑
・システムの無停止時間が厳格

【マイクロサービスに不向き】
・小規模なシステム
・提供するサービスが簡素

マイクロサービスを採用することで生じる、アプリケーションの変化や求められる技術要素の変化、またはその環境を維持できるのかを、十分に検討する必要があります。

最終的には、プロジェクトの要件や目標、チームのスキルセットなどを総合的に考慮し、適切なアーキテクチャスタイルを選択する必要があります。マイクロサービスの利点や課題を十分に理解し、それを基に判断することが重要です。

［筆者プロフィール］
おじかの しげ
https://twitter.com/shige_it_coach
東京近郊の中堅SIerに20年勤務する、インフラ系システムエンジニア。インフラ環境構築からOS、ミドル導入、構築、運用。最近はインフラ関係だけではなく、WEBアプリ開発など幅広く業務を経験。