近年、DX実現へ向けた開発手法として「マイクロサービス」が注目されています。マイクロサービスは、特定の機能を持った小さなサービスを組み合わせて大きなサイトやアプリケーションを開発する技法で、従来の方法より柔軟かつ拡張性にも優れていると考えられています。
では、DXが加速する中でマイクロサービスが注目されているのはどのような理由からなのでしょうか。ここでは、マイクロサービスの基礎知識や導入のメリット、課題について説明するとともに、DXにおいて期待されるマイクロサービスの役割を解説します。
まずは、マイクロサービスとはどのようなものかを解説します。
マイクロサービス(Microservices)とは、さまざまな機能を持った規模の小さなサービスを組み合わせることで、大きなサイトやアプリケーションを構築するソフトウェア開発技法のことです。
それぞれの小さなサービスは自律して動き、ネットワークを通じて互いに通信を行います。サービス間の通信には、HTTPリソースAPIなどの軽量でシンプルな方法が使われており、難しい技術を習得する必要がないことも特長です。
サイトやアプリケーションの開発は、すべての機能をまとめて行う「モノリシックアーキテクチャ」が主流でした。モノリシックアーキテクチャは全体を集約して開発するため、品質が安定しやすい特長があります。一方、全体を集約して開発するため、ひとつの機能だけを臨機応変に改修することはできませんでした。また、サービスが拡大しスケールアウトする際も全体を調整しながら計画的に行う必要があります。
マイクロサービスは、それぞれの機能が独立したサービスになっているため全体を集約する必要がなく、必要に応じてこまめに改修することや、サービス単位でこまめにスケールアウトすることが可能になります。また、障害が発生したときも影響を小さい範囲に留(とど)めやすく、サイトやアプリケーションが安定しやすくなることも特長です。
マイクロサービスと似たものとして、SOA(Service Oriented Architecture=サービス指向アーキテクチャ)があります。この2つは基本的な考え方がほぼ同じで、機能ごとに独立したサービスに分割している点でも似ています。
主な違いは、サーバー、ストレージ、データベースなどの共有です。マイクロサービスは、各サービスが完全に自立して動作し、他のサービスと共有するものは最小限ですが、SOAではサーバーやストレージ、データベースを共有することが多くなっています。
そのため、マイクロサービスほどの独立性はなく、どこかに問題が起きた場合、他のサービスにも影響が出ることがあります。
次に、マイクロサービスを導入することでどのようなメリットを得られるか解説します。
開発・スケールアウトが柔軟になる
マイクロサービスは機能(=サービス)ごとに独立して開発・改修できるため、従来のモノリシックアーキテクチャよりも、サイトやアプリケーションの開発、スケールアウトなどが柔軟にできます。
モノリシックアーキテクチャの場合、改修を繰り返しているうちにコードが複雑になってしまうことがよくあります。そうなると、サービスの全体像が掴(つか)みづらくなり、改修の難易度が高くなりますが、マイクロサービスは小さなサービス単位で開発・改修を行うため、こうしたことは起こりづらくなっています。
マイクロサービスは、サービス単位で開発・運用できることから制約が少なく、システム開発・運用のサイクルを高速化しやすくなります。
従来のモノリシックアーキテクチャは、システム全体が巨大であり、テストに時間がかかることや、気軽に機能追加がしづらいといったデメリットがありましたが、マイクロサービス化することでこうした点を解消できます。
また、マイクロサービスでは、サービスの開発を行ったチームが運用も行うことが望ましいとされています。これにより、改善サイクルを加速し、質の高い開発を継続できます。
マイクロサービスは、他のサービスがどのような言語によって開発されていても、それらの制約を受けません。これは、開発言語が固定されるモノリシックアーキテクチャとの大きな違いです。
これにより、開発チームは使い慣れている言語を使用できるため、より高いパフォーマンスを維持できます。また、そのサービスの実現に適した新しい言語を採用できるため、より柔軟かつ時代にあった開発が可能になります。
また、すでにあるサービスに似たサービスを開発する場合、コードの再利用が可能です。実績あるコードを再利用できるため、開発時間の短縮につながります。
マイクロサービスの場合、どこかひとつのサービスに障害が起こっても、他に影響を及ぼす可能性が少なくなっています。そのため、障害発生時のリスクを最小化できます。
また、新機能を追加する際に障害が発生したときにも有利です。マイクロサービスは障害が起こった機能だけを切り離せばよいため、サービス全体に影響を及ぼす心配がありません。これは、全体に影響を及ぼすモノリシックアーキテクチャとの大きな違いです。
マイクロサービスにはデメリットもあります。ここでは、マイクロサービスの抱える課題について解説します。
マイクロサービスは、サービスごとに異なる開発言語を使えますが、結果としてシステム全体が複雑化し管理が難しくなることがあります。そのため、マイクロサービスの全体像を設計する際は、組み合わせるサービスを慎重に検討する必要があります。
特に、はじめに設定する各サービスは後からの変更が難しいことが多いため注意が必要です。マイクロサービスだからといって、設計そのものが簡単になるわけではないことを理解しておくべきでしょう。
マイクロサービスは、サービスごとに異なるデータセットを使い、それらを同期せずに処理することがあります。そのため、サービス間でデータの整合性を保つことが従来よりも難しくなっています。
マイクロサービスを用いてサイトやアプリケーションを開発する際は、データの管理に労力がかかるケースがあることを理解しましょう。運用に携わる人数が非常に限られる場合は、無理にマイクロサービスを導入しないほうがよいケースもあります。
マイクロサービスは、DX(デジタル・トランスフォーメーション)推進に欠かせない技術で、いわゆる「2025年の崖」問題への対応策として期待されています。2025年の崖とは、既存システムを刷新せずに使い続けた場合、2025年以降大きな経済的損失を被るとされる問題のことです。
主に期待されているのは「技術的負債」への対応です。2018年に経済産業省が発表したレポートでは、老朽化したシステムや建て増しを繰り返したシステムを利用している企業が8割程度あるとされており、これらの刷新は喫緊の課題です。
こうした技術刷新の遅れへの反省もあり、今後のシステム開発は、新たな技術をタイムリーに採用し、システムをモダンな状態に保ち続けることに重点が置かれるようになるでしょう。
新たな技術が次々に現れるITの世界は技術の陳腐化が早く、技術的負債が生まれがちです。しかし、標準的なテクノロジーでシステムの基盤をつくり、そこに汎用性の高いマイクロサービスを組み合わせてサイトやアプリケーションを構築することで、システム全体をモダンな状態に保ちやすくなると考えられます。
また、2025年を踏まえてシステムの刷新を急ぐ場合も、マイクロサービスを利用することで開発期間を短縮できる可能性があります。さらに、AIや自動化に関するマイクロサービスを組み合わせれば、サイトやアプリケーションの品質向上にもつながるでしょう。
サイトやアプリケーションの開発にマイクロサービスを用いる場合、「DevOps」や「CI/CD」といった開発手法の導入についても検討する必要があるでしょう。
マイクロサービスの目的のひとつは、開発・運用のサイクルを効率よく回すことにあります。そのため、従来型のウォーターフォール開発を行ってきた組織の場合、「DevOps」や「アジャイル開発」といった開発手法を取り入れることが必要になるでしょう。この場合、組織の刷新を含む大きな変革が求められます。
また、サービスのリリースに際して、テストやデプロイがボトルネックにならないよう、開発~検証などの工程を自動で行うCI/CD(継続的インテグレーション/継続的デリバリー)の導入も同時に行うことが望ましいと考えられます。
マイクロサービスは、その技術だけを導入するのではなく、開発に関する概念そのものを刷新することで効果を最大化できるといえるでしょう。
マイクロサービスを利用することで、サイトやアプリケーションの開発期間を短縮でき、機能の追加や改修もより柔軟に行えるようになります。製品やサービスのアップデートが容易になるため、時代が求める機能を追加しやすくなり、製品のクオリティを高めることにつながるでしょう。
マイクロサービスはコンパクトなチームがひとつのサービスの開発から運用まで担当することが望ましいとされており、そのためにはアジャイル開発はDevOpsといった開発手法の導入も必要です。マイクロサービスを用いてサイトやアプリケーションの開発を行う際は、開発手法を取り入れるだけでなく、開発体制の見直しもセットで行うことが重要になるでしょう。
掲載日:2024年4月4日