マイクロサービスとは？

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

マイクロサービスは、変化するビジネス要件に適応できるクラウド ネイティブ アプリケーションを構築するためのフレームワークを提供します。無数の利点は、アプリケーションのアーキテクチャから生まれます。

敏捷性

マイクロサービスアーキテクチャは、独立した開発とデプロイメントに適しています。コードの1行を変更するだけで、アプリケーション全体が更新されるモノリシックなアプリケーションとは異なり、開発者は分散システムに影響を与えることなく、サービスを変更したり置き換えたりすることができます。個々のサービスをデプロイできるので、アプリケーションに新しい機能を追加したり、変更をロールバックしたりするのが簡単になります。

スケーラビリティ

アプリケーション全体のスケーリングは最適化されません。マイクロサービスでは、スケーリングが必要なコンポーネントだけがスケーリングされます。開発者は必要に応じて個々のサービスに対応できるため、最終的には高負荷時のパフォーマンスの向上、リソースの効率的な使用、インフラコストの削減が可能になります。

選択

マイクロサービスアーキテクチャでは、クラウドネイティブアプリケーションは共通のスタックやデータベースを共有しません。開発者は、個々のサービスの明確な要件を満たすために、好みのツールや技術を選択することができます。

統合

開発者はどの言語でもマイクロサービスを書くことができ、どの言語でプログラムされたマイクロサービスにも接続できます。さらに、マイクロサービスはあらゆるプラットフォーム上で実行できるため、レガシーシステムとの統合も可能です。

コードの再利用

マイクロサービス・アーキテクチャは、開発者がアプリケーション間で再利用できるモジュラー・サービスを構築することを可能にします。再利用可能なコンポーネントを使用することで、プログラマーは開発時間を短縮し、「一度書いて、何度も再利用する」文化に投資することで、コードの品質を向上させることができます。

フォールト・トレランス

マイクロサービスアーキテクチャはレジリエンスを促進します。自律的に動作するように設計されたサービスでは、モノリシックなアプリケーションで起こりがちなように、1つのサービスの障害でアプリケーションが停止することはほとんどありません。

コラボレーション

マイクロサービスアーキテクチャは、チームが異なるサービスに同時に取り組むことを可能にし、市場投入までの時間を短縮します。開発者は他のチームと調整することなく意思決定を行う一方で、マイクロサービスは各チームが全体の一部を開発・保守する責任を負うため、チーム間のコラボレーションも促進します。これにより、ビジネス目標との整合性を高め、リソースをより効率的に活用することができます。

継続的反復

マイクロサービスで構築されたアプリケーションは、進化するように構築されています。開発者はコアとなるマイクロサービスを最小実行可能プロダクトとして迅速にデプロイし、チームが追加サービスを完成させるたびにアプリケーションをアップグレードすることができます。新しい技術が登場すれば、それを設計に取り入れることができます。マイクロサービスベースのアプリケーションは、理論的な完成に向けて継続的に動きながら、現在も進行中です。

マイクロサービスを使うとき

コンテナベースのマイクロサービスは多くの利点をもたらしますが、常に正しいアプリケーションアーキテクチャを選択できるわけではありません。ソフトウェアエンジニアリングを決定するとき、アプリケーションの目標、アプリケーションの寿命を考慮して予測される開発のハードルとニーズについて考えてください。マイクロサービスは複雑なアプリケーションに最適です。マイクロサービスの利用を検討するシナリオには、次のようなものがあります：

大型アプリケーション

大規模で複雑なアプリケーションを構築している場合、マイクロサービスによってアプリケーションを管理可能な部分に分割することができ、開発、デプロイ、保守が容易になります。

タイムラインの複雑さ

マイクロサービス・アーキテクチャは、開発速度の異なる独立したサービスに対応できます。サービスに予期せぬ遅延が発生しても、アプリケーション開発のタイムラインに世界的な影響を与えることなく、プロジェクトを継続することができます。

頻繁な更新

マイクロサービスアーキテクチャは、独立したサービスによって開発者がアプリケーションの代わりにモジュールを修正できるため、頻繁な更新が必要なアプリケーションに最適です。

高いスケーラビリティ

アプリケーションが大量のトラフィックを処理する必要がある場合や、迅速に大規模化する必要がある場合は、マイクロサービスが不可欠です。これは特に、アプリケーション全体をスケーリングするのではなく、アプリケーションの特定の部分をスケーリングする必要がある場合に有効です。

複数チーム

複数の開発チームが同じアプリケーションに取り組んでいる場合、マイクロサービスは俊敏性と効率性を維持するのに役立ちます。各チームは、アプリケーションの残りの部分を気にすることなく、自分たちに適した技術スタックを使用して、マイクロサービスに取り組むことができます。

分散型アーキテクチャ

分散型アーキテクチャでアプリケーションを構築したい場合、マイクロサービスは自律的で、異なるクラウドサービスプロバイダー間であっても、異なる場所にデプロイすることができます。

ハイブリッドクラウド

ハイブリッドクラウドアーキテクチャを計画しており、一部のサービスはオンプレミスで継続的に実行し、他のサービスはクラウドで実行する場合、マイクロサービスはアプリケーションの複雑さを管理するのに役立ちます。

マイクロサービスベースのアプリケーションの構築とデプロイメント

マイクロサービス・アーキテクチャには慎重な計画が必要です。本番環境に共通する特定のテクノロジーとプラクティスによって、開発者はマイクロサービスベースのアプリケーションを効率的に開発、保守、運用することができます。

DevOps

CI/CDを含むDevOpsのプラクティスは、マイクロサービスのアーキテクチャアプローチに不可欠です。モノリシックなアプリケーションとは異なり、マイクロサービスは本来、多数の可動部分と独立した技術スタックを持つ複雑な分散システムです。この複雑さの要件は、コンポーネントがシームレスに統合されていることを保証するために、開発チームと運用チームの間で頻繁にコラボレーションを行うことです。

DevOpsの プラクティスは、 ソフトウェア開発ライフサイクル全体を通じてチームを効果的にまとめるために必要なコラボレーション、コミュニケーション、自動化ツールを提供します。

継続的デリバリー

継続的デリバリーはマイクロサービスと密接な関係にあり、継続的インテグレーションサーバー、デプロイメントパイプライン、自動テストフレームラインなどのインフラ自動化ツールを活用してCI/CDプロセスを合理化することで、開発者はソフトウェアアップデートを頻繁かつ確実にリリースできます。

継続的デリバリーは 、各サービスが他のマイクロサービスから独立して更新・リリースできるようにするために特に重要です。

REST

マイクロサービスはマイクロサービスと通信し、そのほとんどはウェブアプリケーション内で行われます。REST（Representational State Transfer）は、RESTful APIを構築するためのアーキテクチャデザインパターンで、XML、HTML、JSONなどの標準的なフォーマットでHTTPを介して通信するサービスを可能にします。しかし、REST APIは重大な理由により、マイクロサービスベースのアプリケーションの基礎となります。

REST APIは軽量でプラットフォームにとらわれません。つまり、基盤となるテクノロジーに関係なく、マイクロサービスが通信できる標準化されたインターフェースを提供します。要件にはリクエストを完了するために必要な情報が含まれているため、REST APIはサーバーに保存されたコンテキストを必要としません。RESTベースのマイクロサービスアーキテクチャのサービスは、ステートレスで効率的に通信しながら、独立して進化することができます。

容器

マイクロサービスでは、チームがサービスの言語やフレームワークを選択することができますが、同じCDパイプラインでさまざまな言語を使用することは困難です。コンテナは サービス間の差異を抽象化し、各マイクロサービスがコードベース、データベース、依存関係をパッケージ化した自己完結型のユニットになります。CDパイプラインが均質化されたことで、各コンテナに対して一貫したテストを実施できるようになりました。

デプロイメントされたコンテナは、軽量でポータブルなランタイム環境を提供し、サービスがプラットフォーム間で一貫して機能することを可能にします。DockerやKubernetesのようなツールは、コンテナ化されたマイクロサービスを管理するために広く使用されています。

Kubernetesオーケストレーター

Kubernetesのようなオーケストレーションツールは、基盤となるインフラストラクチャを抽象化し、複数のサーバーにまたがるコンテナの管理、デプロイメント、スケーリングを自動化できます。また、その拡張性により、開発者やオペレーターは好みのオープンソースや商用のソフトウェアツールを使用することができ、コンテナ管理の手作業を減らすことができます。

サーバーレス

サーバーレス・コンピューティングは、マイクロサービスをデプロイするためのもう1つの選択肢です。サーバーレスアーキテクチャは 、FaaS（Function as a Service）プラットフォームを使用して、さらに小さなデプロイメント単位を作成し、オンデマンドでスケールします。サーバーレスアーキテクチャはベンダーへの依存度を高めますが、運用コスト、複雑さ、エンジニアリングのリードタイムを削減します。

マイクロサービスのベストプラクティス

マイクロサービス・アーキテクチャの設計には、慎重な計画と配慮が要件です。マイクロサービスベースのアプリケーションを成功させるために、開発者は以下のベストプラクティスを遵守すべきです：

• ドメイン駆動設計：ドメイン駆動設計（DDD）は、ビジネスドメインとアプリケーションの動作に焦点を当てた設計アプローチです。開発者は、アプリケーションをより小さく管理しやすいコンポーネントに分割し、ビルド、デプロイ、保守を容易にすることができます。
• サービスの境界：マイクロサービス・アーキテクチャを設計する際には、明確なサービス境界を定義することが不可欠です。各マイクロサービスは明確に定義された責任を持つべきです。
• 小規模なサービスサービスを「マイクロ」に保ち、単一の責任に集中。この基本原則を見失うと、管理性が犠牲になります。
• APIの設計：マイクロサービスはAPIを通じて通信するため、データアクセスを許可されたアプリケーション、ユーザー、サーバーに制限する、一貫性があり、スケーラブルでセキュアなAPIを使用します。
• データの分散管理：マイクロサービス・アプリケーションには、さまざまなストレージとデータベースの要件が必要です。各マイクロサービスは独自のデータストアを持つ必要があります。このアプローチにより、データの不整合を回避し、各マイクロサービスを自律的にスケールさせることができます。開発チームが各サービスのデータベースを選択し、プロジェクトに最適なものを選択できるようにします。
• CI/CDパイプライン：CI/CDを実装することで、バグを素早く見つけて修正することができます。これは、マイクロサービスアーキテクチャで管理する複数のコードベースでは特に価値があります。
• 意図的な回復力：依存性障害によるシャットダウンからアプリケーションを保護します。可能であれば、マイクロサービス間でリモートプロシージャコール（RPC）を使用せず、サーキットブレーカーのような機能を組み込んで、障害が連鎖するのを阻止します。
• SOPです：コーディング規約、ディレクトリ構造、通信プロトコルを定義する標準操作手順を開発します。一連の標準に従うことで、一貫性があり管理しやすいマイクロサービスが生まれます。

マイクロサービスの採用

eBay、Etsy、Uberなど、数え切れないほどの企業がモノリシックなアプリケーションを解体し、マイクロサービスベースのアーキテクチャにリファクタリングすることで、スケーリングの優位性、ビジネスの俊敏性、財務的な利益を活用してきました。

マイクロサービスへの移行を計画している組織は、まず DevOpsを導入する必要があります。基本的なことですが、プロジェクトを計画する際には、以下の段階を想定してください。

ビジネス能力の特定

マイクロサービスアーキテクチャに移行する最初のステップは、アプリケーションがサポートする必要のあるビジネス機能や機能を特定することです。これにより、アプリケーションのスコープを定義し、どの機能を優先的に開発すべきか、また、それらのマイクロサービスをどのように設計し、互いに統合すべきかについての意思決定に役立ちます。

モノリシック・アプリケーションの分解

ほとんどの組織は、ドメイン駆動設計または機能ベースの分解を使用して、モノリシックなアプリケーションを分解します。

アプリケーションのビジネス機能を特定した後、各マイクロサービスのサービス境界を定義し、各マイクロサービスが明確に定義された責任を持つようにします。ビジネス機能、データストア、外部システム間の依存関係をマッピングします。制限されたコンテキストと依存関係に基づいて、モノリシックなアプリケーションを置き換えるマイクロサービスを定義します。

各マイクロサービスは、単一のビジネス機能に焦点を当て、明確なインターフェースを持つ必要があります。データ・エンティティへのアクセス方法を見直し、最後に、サービス間の依存関係を減らすためにデータを分割する方法を検討します。

サービスインターフェースの定義

各マイクロサービスのサービスインターフェイスを実装し、インターフェイスがマイクロサービスの唯一の責任を反映するようにします。RESTful APIやメッセージング・プロトコルなど、さまざまなテクニックを使ってサービス・インターフェースを定義できます。

サービスの実装とテスト

要件や専門性に応じて、サービスを実装するためのプログラミング言語やフレームワークを選択します。新しいインターフェイス、通信プロトコル、データストアのテストなど、必要に応じて設計を繰り返します。

サービスのコンテナ化

サービスを実装してテストしたら、DockerやKubernetesなどのコンテナ技術を使ってコンテナ化します。コンテナ化することで、サービスを独立してデプロイし、管理できるようになります。

デプロイメントとオーケストレーションの自動化

KubernetesやDocker Swarmなどのツールを使用して、サービスのオーケストレーションを自動化します。サービスのデプロイメントを効率的に合理化するだけでなく、KubernetesやDockerによる自動化によって、アプリケーションの信頼性と可用性が向上します。どちらのプラットフォームでも、サービス・インスタンスの障害や応答不能を検出し、問題を修復するためのアクションを取ることができます。例えばKubernetesは、障害が発生したインスタンスを再起動したり、他のノードに再スケジュールしたりすることができます。一方Dockerは、障害が発生したコンテナを自動的に他のノードに移行することができます。

サービスの監視と管理

モノリシックなアプリケーションを分解するのは、一度だけのプロセスではありません。アプリケーションとそのユーザーのニーズが進化するにつれて、メンテナンスとアップデートが必要になります。新しいマイクロサービスを監視し、レスポンスタイムやリソース使用率などの主要メトリクスを追跡します。

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

高度に分散されたクラウド ネイティブのマイクロサービス アプリケーションでは、セキュリティが複雑になります。単一のエントリー・ポイントではなく、何十、何百もの潜在的な脆弱性ポイントがあり、それぞれを保護する必要があります。API とコードの依存関係は、現代のアプリケーションの拡大するアタックサーフェスにおける 2 つのリスク源にすぎません。

ウェブアプリケーションとAPIのセキュリティ

最近のアプリケーションは、標準的なウェブリクエスト、モバイルデバイスのAPIコール、クラウドイベント、IoTデバイスのテレメトリ通信、クラウドストレージなど、さまざまなソースから入力を消費します。さらに、1つのクライアントのウェブリクエスト（つまり南北のトラフィック）が、内部のマイクロサービス間の何百ものAPIコール（つまり東西のトラフィック）を生み出すこともあります。

API中心のWebアプリケーションは複雑であるため、スケーラブルで柔軟性が高く、どのようなタイプの環境またはクラウドアーキテクチャのワークロードにも 対応する多層的な戦略が必要です。クラウドネイティブアプリケーションのフロントエンドのWebインタフェースを保護するだけでは十分ではありません。クラウド ネイティブ アプリケーションには、クラウド ネイティブ API のアプリケーション層保護が必要です。ウェブアプリケーションとAPIのセキュリティ（WAAS ）は必須です。

コード依存性とソフトウェア構成分析

オープンソースのソフトウェアコンポーネントは、クラウドネイティブアプリケーションの約70％を占めています。これは開発を迅速化する一方で、多くのオープンソースパッケージとその依存関係には脆弱性が含まれています。また、依存関係のあるOSSパッケージは、バージョンごとに重要な機能が変更される可能性があります。完全な可視性がなければ、脆弱性は発見されません。

スタンドアロンの ソフトウェア構成分析（SCA） ツールは、開発ライフサイクルの遅すぎる時期にオープンソースのリスクを表面化し、常に解決できない脆弱性のバックログを引き起こします。SCAと IaCセキュリティの ための別々のツールは、相互に関連するリスクについてのコンテキストや知識がないまま、ノイズの多いアラートを出すことになります。ランタイムとワークロードのカバレッジがなければギャップは避けられないため、統合された クラウドネイティブ・セキュリティでクラウドネイティブ・アプリケーションを保護するのが最善です。

Code-to-Cloud CNAPP

クラウド ネイティブ アプリケーション 保護プラットフォーム(CNAPP) は、クラウド ネイティブ アプリケーション全体の重大なリスクを特定して優先順位を付け、複数の種類のセキュリティを統合して、クラウド セキュリティ姿勢管理(CSPM)、クラウド ワークロード保護、クラウド インフラストラクチャ権限管理(CIEM)、Kubernetes セキュリティ姿勢管理(KSPM)、インフラストラクチャ アズ コード セキュリティ、WAAS、SCA などの包括的なコードからクラウドへの保護を実現します。

コンテナ、マイクロサービス、サーバーレス機能など、クラウド ネイティブ技術を採用したアプリケーションの迅速な開発ニーズを保護する最善の方法を模索しているクラウド セキュリティ リーダーは、CNAPP の採用を検討する必要があります。

マイクロサービスFAQ