60年代と70年代には、 モノリシックアーキテクチャ コンピューティング リソースが限られているため、すべての機能を 1 つのまとまりのあるユニットに組み合わせる必要があるため、アプリケーションの開発に好まれていました。
それは 90 年代後半から 2000 年代にかけて、特にインターネットと分散システムの台頭により、増大し続けるアプリケーションのサイズと複雑さに対してモノリシック構造が制限され始めたときでした。
これにより、次のような、よりモジュール化されたアプローチの開発が行われました。 サービス指向アーキテクチャ (SOA) そしてその後、 マイクロサービス アーキテクチャ (MSA)、最終的には2010年代初頭に顕著になりました。
とはいえ、これはマイクロサービスの基本概念と使用法を簡単に説明したものにすぎません。それでは、マイクロサービスがモノリシック アーキテクチャをどのように置き換えるか、マイクロサービスがどのように機能するか、およびマイクロサービスの例について説明します。その後、マイクロサービスのデプロイの重要な側面と、マイクロサービスをデプロイする場合に何をすべきかについて説明します。
マイクロサービスとは何ですか?どのように機能するのでしょうか?
前に述べたように、マイクロサービスはアプリケーションの複雑さとサイズの増加に対するソリューションとして登場し、企業が機能を独立して展開可能なサービスに分割できるようになりました。
「マイクロサービス」という用語は、Martin Fowler や James Lewis などの業界専門家によって広められ、2014 年にブログ投稿で正式に導入されました。彼らの研究は、独立して展開可能なサービス、分散データ管理、テクノロジーにとらわれないことの必要性など、主要な原則と特徴を定義しました。
それ以来、マイクロサービスはアーキテクチャの主流の選択肢となり、技術の進歩に支えられています。 Docker などのコンテナ化テクノロジー、Kubernetes などのオーケストレーション ツール、サーバーレス コンピューティング プラットフォームなどです。しかし、マイクロサービスはどのように機能するのでしょうか?
マイクロサービスはどのように機能するのでしょうか?
マイクロサービス アーキテクチャの核心は、大規模なアプリケーションをより小さな個別のサービスに分割し、それぞれが特定のビジネス機能を担当することです。これらのサービスは、多くの場合、REST API、gRPC、または RabbitMQ や Apache Kafka などのメッセージ ブローカーを介して、ネットワーク経由で相互に通信します。
Martin Fowler と James Lewis の定義によれば、マイクロサービスはすべて次の 4 つの重要な特徴を持っています。
- 単一の責任: 各マイクロサービスは、特定のタスクまたは機能を実行するように設計されており、専門化が可能になり、複雑さが軽減されます。
- 独立： マイクロサービスは相互に独立して開発、デプロイ、拡張できるため、柔軟性と復元力が得られます。
- 分散型データ管理: 多くの場合、マイクロサービスには独自のデータベースがあり、単一の集中データベースは必要ありません。
- テクノロジーにとらわれない: チームは、他のサービスの選択に束縛されることなく、各サービスに最適なテクノロジーを選択できます。
このアプローチは、すべてのアプリケーション コンポーネントが単一のまとまりのあるユニットに緊密に統合される従来のモノリシック アーキテクチャとは対照的です。
マイクロサービス導入の主要な段階
マイクロサービス アーキテクチャには、高いスケーラビリティ、柔軟性、効率、障害の分離など、無数の利点がありますが、マイクロサービスを効果的にデプロイする方法を理解し、それを成功させるには十分な計画が必要です。
そのため、マイクロサービスをデプロイする際の主要な概念、段階、マイクロサービスのベスト プラクティスについて包括的なアイデアを持つことが、マイクロサービス アーキテクチャを成功させるために不可欠です。それでは、マイクロサービスのデプロイメントの主要な段階と、各段階に伴う内容を見てみましょう。
マイクロサービスの導入の計画と準備
すべての良いことには計画と忍耐が必要であり、マイクロサービスを正常にデプロイするには、確かにかなりの計画と忍耐が必要です。そのため、マイクロサービスのベスト プラクティスに従い、マイクロサービスをデプロイする際に必要なものすべてを計画して準備することが重要です。
前に述べたように、マイクロサービスの重要な原則と特徴の 1 つは次のとおりです。 単一責任の原則。この原則を忠実に守り、各マイクロサービスが 1 つの機能と機能に重点を置き、それを担当するようにすることで、チームがサービスを独立して開発、デプロイ、拡張できるようになります。
さらに、この原則のサブカテゴリは次のとおりです。 疎結合設計原理。これは、各サービスが通信のために独立して機能でき、他のサービスへの依存が最小限であることを意味します。これにより、1 つのサービスに対する変更や更新が他のサービスに影響を与えず、独立したマイクロサービスのスケーリングが可能になります。
これにより、システムの一部での問題や障害が連鎖反応を引き起こし、システム全体に障害が発生し、サービス全体が停止する連鎖障害のリスクが軽減されます。
マイクロサービスの重要な実践方法の 1 つは、疎結合設計原則の拡張としてマイクロサービスをデプロイするときに、サービスごとに専用のデータ ストレージを用意することです。これにより、競合が防止され、サービスのスケーラビリティが向上します。
さらに、すべてのサービスが直接の依存関係なしに通信できるようにするには、メッセージ ブローカーなどの非同期マイクロサービス通信パターンが必要になります。
パズルの最後のピースは、マイクロサービスの継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインの実装です。これらのパイプラインにより、チームは新しい機能や修正をデプロイできるようになります。 CI/CD ツール Jenkins や GitLab のように、組織は新しい機能を頻繁にリリースしながらシステムの安定性を維持できます。
マイクロサービスのデプロイに必要な計画と準備について全体的なアイデアが得られたので、マイクロサービスのデプロイ戦略について話しましょう。
マイクロサービスの導入戦略
マイクロサービスをデプロイする場合、デプロイ戦略の選択は、サービスの機能、トラフィック、インフラストラクチャのセットアップ、チームの専門知識、およびコストの考慮事項によって決まります。ただし、一般に、マイクロサービスのデプロイ戦略は次のとおりです。
- コンテナごとのサービス インスタンス: このアプローチでは、各マイクロサービスが独自のコンテナーで実行され、ホストごとに複数のインスタンスを使用するモデルよりも優れた分離が提供されます。コンテナーを使用すると、スケーリングが容易になり、リソースの割り当てが改善されます。
- 仮想マシンごとのサービス インスタンス: 各サービスは個別の仮想マシン (VM) で実行され、コンテナーよりもさらに分離されています。これによりセキュリティと安定性が向上しますが、通常はより多くのオーバーヘッドが発生します。
- 段階的リリース: 最初に、マイクロサービスのバージョンをユーザーの少数のサブセットにデプロイし、完全な展開の前に安定性をテストします。このアプローチにより、問題が発生した場合の影響が最小限に抑えられ、迅速なロールバックが可能になり、システムの整合性が維持されます。
- ブルーグリーン展開: この方法では 2 つの同一の実稼働環境を使用します。1 つの環境はライブ トラフィックを処理し、もう 1 つは次のリリースのテストに使用されます。 Blue-Green 導入では、2 つの環境間でトラフィックをシームレスに切り替えることができるため、簡単なロールバックとゼロ ダウンタイムの更新が可能になります。
- 段階的リリース: この戦略には、さまざまなユーザー セグメントまたは環境に更新を段階的にロールアウトすることが含まれます。多くの場合、本番環境に到達する前に内部環境から開始され、潜在的な問題の影響範囲が制限され、チームが段階的に問題に対処できるようになります。
- サーバーレス展開: このアプローチでは、AWS Fargate や Google Cloud Run などのサーバーレス プラットフォームを活用し、スケーリングやリソース割り当てを処理することでインフラストラクチャ管理を自動化します。サーバーレス展開では、基盤となるサーバーを管理する必要がないため、マイクロサービス自体に集中できます。
マイクロサービスをデプロイするために上記のマイクロサービスのいずれかを選択したら、マイクロサービス オーケストレーション ツールが必要になります。
マイクロサービスオーケストレーション
数多くのマイクロサービス展開戦略の中から 1 つを選択した後は、マイクロサービス オーケストレーションの一種の指揮者が必要になります。マイクロサービス オーケストレーション ツール Kubernetes、マイクロサービスのデプロイ、マイクロサービスのスケーリング、マイクロサービスの監視、コンテナー化されたマイクロサービスの管理の自動化に役立ちます。
たとえば、Airbnb は Kubernetes を使用しているため、エンジニアは手動で監視することなく、マイクロサービスに何百もの変更をデプロイできます。 Kubernetes などのマイクロサービス オーケストレーション ツールの重要な機能の 1 つは、組み込みの負荷分散です。
適切な負荷分散機能があると、受信トラフィックをマイクロサービスの複数のインスタンスに分散するのに役立ちます。これにより、単一のインスタンスがボトルネックになることがなくなり、需要の急増に対処するシステムの能力が強化されます。
Kubernetes は、障害が発生したコンテナが自動的に置き換えられて再起動される自己修復機能を通じて、マイクロサービスの管理において重要な役割を果たします。 New York Times はこの機能を活用して、ユーザー エクスペリエンスに影響を与えたり、ダウンタイムを発生させたりすることなくマイクロサービスを維持しています。
さらに、Kubernetes は、ConfigMap と Secret を使用して、データベース資格情報や API キーなどの構成とシークレットとしてのマイクロサービスのセキュリティも向上します。これは、顧客やユーザーの機密情報を扱う Uber などの企業やサービスにとって特に重要です。
最後に、Kubernetes のようなマイクロサービス オーケストレーション ツールは、段階的リリースなどのローリング アップデートとロールバックを伴うマイクロサービス戦略に特に有益です。ローリング アップデートでは、古いバージョンの一部のインスタンスを実行し続けることで、サービスを中断することなく新しいマイクロサービス バージョンをデプロイできます。
マイクロサービス オーケストレーション ツールを設定したら、構築して自動化する必要があります CI/CD パイプライン マイクロサービスのデプロイメント用。
マイクロサービス展開のための CI/CD パイプライン
先ほど説明したように、マイクロサービスの継続的インテグレーションと継続的デリバリーのパイプラインは、マイクロサービスのデプロイメントの重要な側面です。 CI/CD パイプラインの CD パイプラインは、コードの変更が CI/CD パイプラインのテストおよび統合段階を通過するとすぐに、実稼働環境に自動的にデプロイする役割を果たします。
次に、CI/CD パイプラインの CD 部分が機能し、コードの変更がテストと統合の段階を通過するたびに、サービスが Kubernetes クラスターなどのマイクロサービス オーケストレーション ツールにデプロイされます。
さらに、単体テスト、統合テスト、エンドツーエンド テストがパイプラインに組み込まれているため、テストと統合の段階はすべて CI/CD パイプラインによって自動的に実行されます。
これにより、チームはシステムの安定性を維持しながら、各段階で更新を検証できます。さらに、さまざまなテストにもかかわらず、コードの変更に問題がある場合は、自動ロールバックによって以前の安定したバージョンに戻すことができます。
最後に、マイクロサービスのベスト プラクティスに従ってマイクロサービスの CI/CD パイプラインを実装すると、組織はより迅速な開発を実現し、手動エラーを減らし、高品質の標準を維持することができます。
Spotify、Expedia、iRobot、Lufthansa、Pandora などの多くの企業は、CircleCI、AWS CodePipeline、GitLab などの CI/CD ツールを通じてマイクロサービスの CI/CD パイプラインを使用して、デプロイメント プロセスを自動化し、一貫したコード品質を確保し、システムの安定性を維持しながら新機能を迅速に提供しています。
マイクロサービスの通信パターン
マイクロサービスが相互に通信する方法は、マイクロサービスの機能、全体的なアーキテクチャ、必要なスケーラビリティ、および信頼性に完全に依存します。一般に、主に 2 種類のマイクロサービス通信パターンが使用されます。 同期 そして 非同期 マイクロサービスの通信パターン。
同期マイクロサービス通信パターンでは、サービスはリアルタイムで対話します。つまり、サービスはリクエストを送信し、応答を待ってから続行します。最も一般的に使用される同期マイクロサービス通信パターンは次のとおりです。 REST (Representational State Transfer) API, gRPC (Google リモート プロシージャ コール)、 そして グラフQL.
通常、この種のマイクロサービス通信パターンは、リアルタイムのデータ処理と即時応答を必要とする業界や企業で使用されます。金融、ヘルスケア、電子商取引などの業界では、同期通信パターンを使用して、トランザクション、データ取得、やり取りが即座に行われるようにし、スムーズで応答性の高いユーザー エクスペリエンスを維持することがよくあります。
とはいえ、同期マイクロサービスの通信パターンには、リアルタイム応答やシンプルさなどの利点がありますが、密結合による潜在的なボトルネック、高負荷時のスケーラビリティの低さ、応答時間の遅さ、高トラフィック インスタンス時の遅延の高さなど、特定の欠点もあります。
一方、非同期マイクロサービス通信パターンは、前に説明した疎結合原則に基づいているため、通常、マイクロサービスにより適しています。
このタイプのマイクロサービス通信パターンは、Kafka や RabbitMQ などのブローカーを介してメッセージを送受信できるようにすることで、サービスを分離します。バッファとして機能するキューにメッセージを送信することにより、サービスは、同期通信パターンのように応答を待つのではなく、独立して通信します。このバッファにより、他のサービスが独自のペースでメッセージを処理できるようになり、送信者は受信者を待たずに作業を続行できるようになります。
非同期マイクロサービス通信パターンは、マイクロサービス展開の分離構造を提供するだけでなく、同期マイクロサービス通信パターンが提供するものと同じリアルタイム応答も提供します。
これは、サービスが特定のアクションが発生したときにイベントを発行することによって通信するため、非同期イベント駆動型マイクロサービス通信パターンのイベント駆動型アーキテクチャによるものです。他のサービスはこれらのイベントをサブスクライブし、それに応じて反応できます。これにより、サービス間を直接結合することなく、変更にリアルタイムで反応する応答性の高いシステムが可能になります。
さらに非同期では、 パブリッシュ-サブスクライブ (パブリッシュ/サブスクライブ) マイクロサービス通信パターンでは、サービス (パブリッシャー) がトピックにメッセージを送信し、他のサービス (サブスクライバー) がそのトピックをリッスンして更新を受信します。このモデルは、複数のサブスクライバをサポートし、多くのサービスにメッセージを同時にブロードキャストします。
最後に、イベント駆動型パターンと同様に、非同期です。 振り付けベースの物語 マイクロサービスの通信パターンでもイベントを使用して相互に通信します。ただし、このパターンでは特定の順序が設定されています。つまり、イベントが次のステップと特定のサービスのアクティブ化をトリガーします。
ここでの違いは、イベント駆動型パターンには特定のシーケンスやワークフローがなく、振り付けベースのサーガ パターンの特定のプロセスや順序ではなく、複数のサービスがイベントに反応できることです。
どのタイプの非同期マイクロサービス通信パターンを使用するかは、マイクロサービスのタスクと全体的な機能によって異なります。 RabbitMQ や Amazon SQS などのメッセージ キューは、通常、タスクのスケジューリング、ワークロード分散、注文処理および通知システムの電子商取引に使用されます。
Apache Kafka や AWS EventBridge などのイベント駆動型メッセージ ブローカーは、通常、金融サービスや AWS 環境などの分野で、大規模なイベント ストリームをリアルタイムで処理したり、マイクロサービス間のイベント ルーティングに使用されます。
Google Cloud Pub/Sub や Redis Streams などのパブリッシュ/サブスクライブ (Pub/Sub) メッセージ ブローカーに関しては、これらのメッセージ ブローカーは通常、リアルタイム分析やイベント取り込み、リアルタイム通知やチャット アプリケーションのための分散システム全体でのスケーラブルなメッセージングに使用されます。
最後に、コレオグラフィー ベースの saga メッセージ ブローカーは、主に e コマース注文処理、旅行予約システム、および中央制御なしで複数のサービス間で複雑な複数ステップのトランザクションを調整する必要があるユースケースに使用されます。
マイクロサービスサービスディスカバリ
ニーズに合った通信パターンを設定して実装したら、最初にサービスが相互に位置を特定できることを確認する必要があります。前に述べたように、Kubernetes などのマイクロサービス オーケストレーション ツールは、マイクロサービス サービスの検出において重要な役割を果たします。
これは、Kubernetes DNS が提供する組み込みのサービス検出を通じて行われ、サービスがスケールしたりクラスター内の場所が変更されると、IP アドレスと DNS レコードが動的に更新されます。
マイクロサービス サービス検出のこの方法は、ルーティングの責任がロード バランサーに委任され、ロード バランサーがレジストリにクエリを実行してトラフィックを適切なインスタンスに送信するため、サーバー側検出と呼ばれます。
一方、マイクロサービス サービス検出のためのクライアント側検出方法もあります。この方法では、サービスまたは API ゲートウェイが Consul や Eureka などのサービス レジストリにクエリを実行して、利用可能なインスタンスを見つけます。
マイクロサービスの展開に最適なサービス検出方法の選択は、システムの要件と規模によって異なります。
クライアント側のマイクロサービス サービス検出を使用すると、クライアントはどのインスタンスと通信するかを完全に制御できます。これにより、より多くのカスタマイズが可能になるだけでなく、一元的な検出サービスが必要なくなるため、複雑さも軽減されます。
たとえば、Netflix のマイクロサービス展開では、負荷分散のために Eureka とリボンを使用したクライアント側のマイクロサービス サービス ディスカバリを使用し、クライアントがレイテンシやサーバー負荷などの基準に基づいて最適なインスタンスを選択できるようにします。
ただし、サーバー側のマイクロサービス サービス ディスカバリは、一元化されたサービス ディスカバリにより効率が向上し、分散システム全体で一貫した負荷分散が可能になるため、大規模な環境により適しています。
Kubernetes、AWS Elastic Load Balancing、API Gateways (Kong、NGINX など) などのサーバー側のマイクロサービス サービス ディスカバリ ソリューションは、トラフィックを効率的にルーティングし、高可用性を維持するのに役立ち、Airbnb、Pinterest、Expedia、Lyft などの企業で使用されています。
マイクロサービスのセキュリティ
モノリシック アーキテクチャは MSA よりもほとんど劣っていますが、モノリシック アーキテクチャが優位性を持っていた 1 つの側面はセキュリティでした。マイクロサービスは疎結合原理に基づいて構築されており、本質的に分散しているため、単一の一般的なセキュリティ対策を実装することはできません。
各サービスを個別に保護する必要があるため、マイクロサービスでは攻撃対象領域がはるかに大きくなり、追加の保護手段が必要になります。この目的のため、ご想像のとおり、認証と認可には OAuth2 や JSON Web Token (JWT) などの標準が一般的に使用されます。
さらに、API ゲートウェイは、エントリ ポイントで認証と認可を強制するため、マイクロサービス全体のセキュリティを管理するためによく使用されます。さらに、ゲートウェイ API はレート制限、ロギング、モニタリングを実装することもでき、これによりマイクロサービス セキュリティの追加レイヤーが提供されます。
これらは主要なエントリ ポイントを保護しますが、サービス間通信をカバーするにはさらに多くのマイクロサービス セキュリティ対策が必要です。
ここでサービス メッシュが活躍します。ネットワーク マイクロサービス セキュリティのレイヤーを追加し、サービス間のトラフィックを暗号化し、相互 TLS などのポリシーを適用します。これらのサーバー メッシュは基本的に、マイクロサービスのセキュリティを大幅に向上させる包括的なエンドツーエンド暗号化を設定します。
マイクロサービスのスケーリング
MSA の最大の利点の 1 つ、そしてそれがモノリシック アーキテクチャを置き換えるために開発されたまさにその理由は、その高い拡張性です。通常、マイクロサービスのスケーリングは、垂直方向と水平方向の 2 つの方法で発生します。
基本的に、垂直マイクロサービス スケーリング (スケールアップ) では、CPU やメモリなどのリソースを既存のインスタンスに追加します。あるいは、水平マイクロサービス スケーリング (スケール アウト) によって負荷が分散され、容量が増加します。
実装の面では、垂直マイクロサービス スケーリングの方が簡単です。これは、より大きなサーバーにアップグレードしたり、クラウド インスタンスのメモリや処理能力を増やしたり、ストレージを追加したりして、単一のインスタンスを変更するだけであるためです。
このタイプのスケーリングは通常、メモリ内キャッシュを担当するサービスなど、RAM または CPU の能力を増やすことでクエリのパフォーマンスとデータ処理を向上できる場合に使用されます。
とはいえ、垂直マイクロサービス スケーリングはより簡単で、すぐにパフォーマンスが向上しますが、欠点もあります。垂直スケーリングはサーバーのハードウェア容量によって制限されるため、垂直スケーリングを継続するには、ある時点で水平スケーリングに切り替える必要があります。
さらに、垂直スケーリングにはハードウェアや大規模なインスタンスには一般的に高額な費用がかかるため、コストがかかります。最後に、スケールアップされたインスタンスに障害が発生した場合、負荷を処理する追加のインスタンスがないため、サービスは完全にダウンします。
マイクロサービスの水平スケーリングの場合、単一インスタンスのリソースをアップグレードするのではなく、そのサービスの新しいインスタンスをデプロイします。これらのインスタンスは独立して動作しますが、同じサービスと同じワークロードの一部を処理します。
垂直方向のスケーリングとは異なり、水平方向のマイクロサービスのスケーリングは無制限です。つまり、増加するワークロードやトラフィックの急増に対処するために必要なだけインスタンスを追加でき、より優れたスケーラビリティを提供します。
さらに、複数のインスタンスがあるため、1 つがダウンしても、他のインスタンスがリクエストの処理を続行できるため、すべての卵を 1 つのカゴに入れる必要はありません。最後に、水平スケーリングは、複数の小さくて安価なインスタンスを使用して、より信頼性が高く強力なパフォーマンスを形成できるため、長期的にははるかにコスト効率が高くなります。
ただし、水平スケーリングとインスタンスの追加には、より多くのロード バランサー、マイクロサービス サービス ディスカバリ メカニズム、およびマイクロサービス オーケストレーション ツールが必要となり、マイクロサービス アーキテクチャはさらに複雑になります。
水平スケーリングは、トラフィックの変動や大量のリクエストが発生することが多い、Web サービスや、電子商取引やソーシャル メディア プラットフォームなどのアプリケーションなどのユースケースに適しています。
とはいえ、両方のタイプのスケーリングがマイクロサービスでサポートされており、多くの場合に必要であるため、実際にはどちらか一方だけの場合ではありません。通常、小規模な組織では実装と管理がはるかに簡単な垂直スケーリングを使用しますが、時間の経過とアプリケーションの成長に応じて、高い需要に対処するために水平スケーリングが導入されます。
最後に、クラウド プラットフォームは、リアルタイムの需要に基づいてインスタンスを自動的に追加または削除する自動スケーリング サービスを提供します。これは、組織が垂直方向と水平方向のスケーリングのバランスをとるのに非常に役立ちます。
マイクロサービスの監視
この段階で、マイクロサービスのデプロイはほぼ完了しました。残っているのは、それが一貫して確実に動作することを確認することだけです。ここで、次のようなマイクロサービス監視ツールが使用されます。 プロメテウスとグラファナ 踏み込んでください。
これらのツールは、サービス メトリクスに対するリアルタイムの洞察を提供するため、チームはリソースの使用状況、遅延、エラー率を追跡できます。さらに、これらのツールは分散トレース (Jaeger、Zipkin など) も提供します。これはサービス全体のリクエスト フローを視覚化するのに役立ち、問題の診断に非常に役立ちます。
最後に、マイクロサービスの分散設計により障害がサービス全体に連鎖する可能性があるため、マイクロサービスの監視ではログの集約が重要な実践となります。ログを一元化されたプラットフォームに統合し、リアルタイムのアラートを設定することで、常に問題の 2 歩先を行き、ユーザーに影響を与える前にプロアクティブに対応できます。
最終的な考え
マイクロサービスの世界は確かに理解するのが難しいものですが、マイクロサービス展開の基礎と主要な段階を理解すると、プロセス全体がはるかに簡単になります。さらに、年が経つにつれて、大幅に多くの機能を備えたツールが増え、マイクロサービスのデプロイがこれまでよりも簡単になりました。
よくある質問
マイクロサービスにはどのような展開戦略が一般的に使用されますか?
マイクロサービスのデプロイメントにはさまざまな戦略がありますが、最も一般的に使用されるデプロイメント戦略には、コンテナーごとのサービス インスタンス、段階的リリース、Blue/Green デプロイメント、およびサーバーレス デプロイメントが含まれ、それぞれが異なるレベルの分離、柔軟性、およびスケーラビリティを提供します。
Kubernetes はマイクロサービスのオーケストレーションにおいてどのような役割を果たしますか?
マイクロサービスは、Kubernetes などのマイクロサービス オーケストレーション ツールに依存して、コンテナ化されたサービスの展開、スケーリング、管理を自動化し、負荷分散、自動スケーリング、自己修復機能を提供して、回復力と効率性の高いマイクロサービスを保証します。
マイクロサービス環境でセキュリティを確保するにはどうすればよいですか?
マイクロサービスは分散された性質があるため、セキュリティに関してはモノリシック アーキテクチャよりも複雑です。マイクロサービスのセキュリティには、リクエストの認証と承認、サービス間通信の暗号化、集中セキュリティ管理のための API ゲートウェイと Istio などのサービス メッシュの実装が含まれます。
