マイクロサービス

マイクロサービスの定義

マイクロサービスベースの構造は、アプリやデジタルプロダクト開発の最新の方法です。全体を小さな自立したモジュールに分割し、後で連携させる仕組みです。主にクラウドネイティブなソリューションに用いられます。 

‍

主な特徴

この革新的な開発手法では、異なる独立した要素やサービスが結びつき、マイクロサービスを形成します。各サービスは円滑なデータ交換を行い、目的を達成するために連携します。これが基本です。

以下は、この仕組みを適切に表すいくつかの用語です。

• 独自性: 各コンポーネントは唯一無二で、特定のニーズや機能を果たすよう設計されています。
• ‍分散化: 各要素の依存関係はほとんどなく、分散され緩やかに連携しています。定期的かつ明確な通信が求められます。
• ‍高い耐障害性: 各マイクロサービスは高い耐障害性を持ち、障害が発生しても全体に影響が少なくなります。
• ‍API依存: APIはアプリの動作に不可欠で、内部・外部の通信で重要な役割を担います。 
• ‍個別データ保存:この手法では、小さなサービスは共有データベースを使用せず、各サービスが専用の保存領域を有します。

‍

マイクロサービスの利点と欠点

他の手法と同様、マイクロサービスにも明確な利点と欠点があります。採用を検討する際は、両面を比較して選択する必要があります。この手法を採用すると、アプリ開発が非常にシンプルになります。 

採用する上での利点は以下のとおりです:

• 独立性と高いスケーラビリティ

ご存知の通り、この方式では各サービスが互いに依存せず、個別に開発可能です。そのため、一方の作業完了を待つ必要はありません。

開発作業は同時に進められ、小規模なチームでも対応できます。これにより開発が迅速化され、スケールアップも容易となります。マイクロサービスでは、一部の機能を拡張しても全体に影響しません。 

例えば、データ分析アプリのレポート機能を更新する際、全体を改修する必要はなく、該当するレポート機能だけを更新できます。これにより、スケーリングが容易になります。

• 低い障害発生率

マイクロサービスは高い障害耐性を備えており、1つのサービスで問題が発生しても他にはほとんど影響しません。これにより、全体の障害発生率が低減されます。

• 容易なコーディング

マイクロサービスのコーディングは簡単です。まず、各サービスのコードは独立しているため、パターン把握やバグ検出がしやすくなります。

さらに、サービスごとに異なるプログラミング言語を使用できるため、全体で1つの言語に拘る必要がなく、柔軟な開発が可能です。これは、多様なスキルを持つ人材が活躍できる環境に最適です。

• 容易な運用とカスタマイズ

マイクロサービスは独立しているため、特別な専門知識がなくても扱いやすいです。どの開発者でも各サービスの内容を理解しやすくなります。

また、以前のバージョンに簡単に戻せるため、チームが交替しても開発プロセスに影響しません。新たなチームでもすぐに状況を把握し、作業を継続できます。

さらに、多くのオープンソース統合ツールとシームレスに連携でき、開発プロセス全体のカスタマイズ性も高いです。

以上の利点は魅力的ですが、マイクロサービスが万能というわけではなく、いくつかの欠点も存在します。たとえば:

• 分散配置のため、テストが従来より難しくなります。
• APIやAPIゲートウェイの多用により、APIセキュリティには特に注意が必要です。初期段階からセキュリティ基準、クラウドベースWAF、API認証などを導入するのは簡単ではありません。
• ‍通信の負荷が増大します。
• 小規模なデジタルソリューションの開発には不向きで、場合により複雑化するため利用ケースは限定されます。  
• 耐障害性、リスク軽減、負荷分散、低ネットワーク遅延などを実現するため、追加の対策が必要です。

マイクロサービスの実例

マイクロサービスの採用は年々増加しており、日々多くの組織が短期間で柔軟なクラウドネイティブなアプリ開発に取り組んでいます。そのため、この手法で構築されたアプリが数多く存在します。以下、いくつかの実例を紹介します。

• Netflix

今日広く利用されているNetflixアプリは、初期のモノリシック構造からSOAを経て、継続的な開発と更新を重ねることで高い完成度を実現しました。

しかし、ユーザーリクエストの増加と多様なデバイスへの対応要求により、開発チームはAPI利用が可能なマイクロサービスへと移行しました。これにより、一度に5件以上のバックエンドコールが可能となりました。

• Amazon

最近、Amazonもマイクロサービス手法を採用し始めました。以前は二層構造で運用していましたが、膨大なAPIコールへの対応が難しく、複雑さが増していました。

その後、サービス指向のアプローチが模索され、これがマイクロサービス導入への道を開きました。Amazon AWSやApolloといった、AWSがこの手法で開発したアプリがその例です。マイクロサービスへの移行は、AWSの著しい成長に寄与しました。

• Uber

世界中で利用されるライドシェアリングアプリ、Uberもマイクロサービスを採用しています。かつては、迅速なバグ修正やグローバルな運用、急成長の実現が難しい課題がありました。‍

マイクロサービス対モノリシック構造

1. ‍主要な違い

開発者コミュニティは、モノリシックなアプローチの問題点を解決するためにマイクロサービスを採用しました。

モノリシックは、全コードを一度に実行するため、テストや更新、トラブルシューティングが非常に困難です。また、一部のコードの脆弱性が深刻な影響を及ぼす恐れがあります。

さらに、モノリシック構造は詳細な計画や高い運用負荷、時間を要し、更新やスケーリングは全体の構造改修が必要となります。

これに対し、マイクロサービス構造は各要素を独立して実行できるため、テストやスケールアップも容易です。

この細分化された開発手法は他にも多くの利点があり、例えば:

• 各チームや個人が異なるサービスを同時に担当でき、開発が迅速に進む。
• 障害が特定の部分に留まりやすく、全体への影響を抑えられる。
• 影響を受けた部分だけを対象にテストできるため、迅速かつスムーズに問題解決が可能である。
• 1部分だけの更新が可能なため、スケーリングが容易である。

2. ‍技術スタック

モノリシックなアプリ構築には、Java、.NET、Python、PHP、Ruby、Djangoなどのスキルが必要です。一方、Docker、DevOps、Lambda、Kubernetesはマイクロサービス開発の基盤となります。 

モノリシック方式では1つの言語に統一するのが一般的ですが、マイクロサービスは複数言語を併用でき、非常に柔軟で機敏です。

3. ‍利用ケース 

小規模なアプリ開発にはモノリシックが適しており、マイクロサービスは大規模・エンタープライズ向けの開発で真価を発揮します。 

‍

SOA 対 マイクロサービス

概要

サービス指向構造（SOA）は、再利用可能なソフトウェアの要素を活用する国際的に認められた開発手法です。SOAで開発されたアプリは独自のコードと統合を持ち、各サービスがそれぞれの役割を果たします。 

SOAはマイクロサービスに非常に似ていますが、実際はマイクロサービスがSOAの最新バージョンと位置付けられます。

どちらもAPIやAPIゲートウェイを用いた疎結合なサービスですが、疎結合により再利用性が高まります。

ただし、ソフトウェア部品の再利用は利点でもあり欠点でもあり、マイクロサービス開発ではあまり重視されません。

再利用は手間を省く反面、複数のアプリに影響を及ぼすリスクも伴います。

1つのリソースで障害が起これば、そのリソースを利用する全アプリに問題が波及します。XMLはSOAの重要な要素で、主にWebサービスの構築に用いられ、1990年代後半のSOAの普及はモノリシック開発の問題解決に寄与しました。

SOAでは、アプリ別、エンタープライズ向け、インフラ解決、機能特化型など、多様なサービスを構築できます。

どこが異なるのか

• SOAはウェブサービス向けであるのに対し、クラウドネイティブなプロダクトはマイクロサービスを採用する。
• SOAは再利用性を重視するが、マイクロサービスはあまり推奨しない。
• マイクロサービスは独立したコンポーネントの構築に重点を置くのに対し、SOAは協調性を重視する。
• SOAではデータの重複が起こりやすく、基本コードの変更でデータ修正が可能。一方、マイクロサービスは個別のデータを使用する。
• マイクロサービスは個別のAPIで通信するが、SOAは共有可能なESBを用いる。
• SOAは共有データストレージを用いるのに対し、マイクロサービスは専用データベースを利用する。

基本的な基盤技術とツール

マイクロサービスは高度にカスタマイズ可能で、さまざまな技術やツールの採用が可能ですが、最適なシナリオも存在します。

1. APIゲートウェイ

サービス間の通信に不可欠なリソースであり、逆プロキシとしてAPI通信を実現します。

逆プロキシとして、リクエストの振り分け、複数アプリへの分散、認証強化に大いに役立ちます。 

API管理プラットフォームがAPIゲートウェイの展開に広く使われますが、k8sコンテナを用いる場合はIngressが利用されます。

2. サーバーレス

この技術は、マイクロサービスやクラウドのパターンを取り入れ、実行単位を関数として扱います。関数は短いコードから長いコードまで様々ですが、サーバーレス関数は小規模で、FaaSと類似しています。 

3. コンテナ、Docker、Kubernetes

Dockerは強力なコンピューティングモデルを提供し、Docker Machine、Docker Compose、Docker Swarmといったツールでマイクロサービスのオーケストレーションを容易にします。

Docker Machineはどのクラウド環境でもコマンドライン操作を可能にし、Docker Composeは同一のユースケースでコンテナの管理を支援します。

Docker Swarmは大規模なマイクロサービスの調整を容易にし、コンテナは運用負荷を低減し、迅速に起動できます。 

コンテナやサービスの管理、展開の制御、円滑なオーケストレーションは容易ではありません。 

その課題は、極めて最適化されたコンテナオーケストレーションプラットフォームであるKubernetesが解決します。

仮想マシンは大規模で動作が遅いため、マイクロサービスを用いたプロダクトの開発やホスティングには適しません。‍

マイクロサービスとDevOps

ソリューション開発では、マイクロサービスとDevOpsという用語がしばしば混同されますが、両者には明確な違いがあります。

DevOpsはアプリやシステム運用の各タスクを統合して、開発や運用チームの作業を簡素化します。一方、マイクロサービスは大規模なアプリを小さな部品に分割し、段階的に構築します。 

DevOpsは予算管理、アップグレード、運用タスクなどの各側面を一体化し、集中管理を実現することで開発を加速させます。

運用と開発が継続的に連携するマイクロサービスアーキテクチャは、DevOpsチームによって容易に管理できます。‍

共通パターン

マイクロサービスを効果的に活用するには、既存のパターンを賢く利用することが重要です。いくつかのパターンがあり、開発目標に最も合致するものを選ぶ必要があります。 

• BFF（Backend-for-frontend）

最も一般的なパターンの1つであるBFFは、ユーザー体験と各リソースの間に安全なレイヤーを挟みます。例えば、モバイルとデスクトップで異なるフォントサイズや表示パターンを提供する際に用いられます。 

BFFは、バックエンド要素がそれぞれのインターフェースと適合するように設計され、最適なフロントエンド操作を実現します。

• Entityとアグリゲート

このパターンは、各エンティティが固有の識別子を持ち、アグリゲートがそれらの集合として扱われるという考えに基づいています。 

例として、ファッションストアのサマーコレクションはアグリゲートであり、その中の衣服はエンティティとなります。このパターンは、大量データのわかりやすい分類に役立ちます。

• サービスディスカバリー

このパターンは、変化し続けるマイクロサービスを容易に発見するために用いられます。各サービスは変更や更新、スケールアップが行われるため、検出が難しい場合があります。

サービスディスカバリーパターンにより、一貫した標準的な方法で迅速な検出が可能となり、負荷分散でも障害検知に利用されています。

• アダプターマイクロサービス

このパターンは、異なるオブジェクトやクラス間の互換性を実現するために用いられ、特に3rdパーティのリソースを多用するアプリで効果を発揮します。 

• ストラングラーアプリ

モノリシックアプリの増大を抑制し、マイクロサービスの整合性を維持するためのパターンです。‍

マイクロサービスセキュリティ

増加するAPI利用、モノリシックアプリの台頭、複雑な展開など、さまざまな要因がマイクロサービスのセキュリティ上の懸念を増大させています。これらを放置すると、予期せぬセキュリティ問題が発生する恐れがあります。

主なセキュリティ上の懸念点は次の通りです:

• 分散されたインフラにより、開かれたネットワークが増え、各ネットワークがサイバー攻撃の対象となる。
• アプリの更新が一貫しておらず、一部のサービスのみ更新され、他が旧態依然とするため、セキュリティ侵害のリスクが高まる。
• 多数のポートやAPIが利用されるため、攻撃対象が拡大し、リスクが増加する。
• 3rdパーティツールや技術に対する制御が難しく、セキュリティ上の課題が増大する。
• 各サービスごとに異なるセキュリティ対策が必要となり、全体が複雑になる。

これらの問題は深刻ですが、早期発見は容易ではありません。1つの問題が特定のマイクロサービス内で発生し、長期間見過ごされる可能性があるため、即時に問題を検知できる対策が求められます。

セキュリティスキャナーの利用、Dockerなどの内部ネットワークの導入、アクセス制御の徹底、通信チャネルからのサイロ排除などが、現行のセキュリティ問題の解決に有効です。

マイクロサービスアーキテクチャの未来は？

開発者コミュニティはこの手法に前向きで、その使いやすさ、柔軟性、スケーラビリティを高く評価しています。

クラウド利用の拡大に伴い、マイクロサービスはクラウドのスケーリングを容易にするため、ますます重要となります。クラウドの機能は複雑さに煩わされることなく、容易に更新・修正できます。

しかし、通信の複雑さを解消する実用的なソリューションが必要です。効果的なAPIゲートウェイの利用により、多くの通信障壁が解消されます。将来的には、さらなる統合と容易な再利用が実現されるでしょう。 

GitHubでは、複数のマイクロサービスを共有するプロジェクトが見受けられ、いわゆる『Microservices as a Service』として普及しています。再利用性により、マイクロサービスはより広く浸透するでしょう。全体として、マイクロサービスの未来は明るいと言えます。