1960年代と1970年代に モノリシックアーキテクチャ は計算リソースが限られていたため、すべての機能を 1 つの統合されたユニットに組み合わせる必要のあるアプリケーション開発に支持されていました。
それが 1990 年代後半から 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つの部分の問題または障害が連鎖反応を引き起こし、システム全体の障害につながり、サービス全体がダウンする段階障害のリスクが軽減されます。
マイクロサービスの重要な実践の1つは、マイクロサービスをデプロイする際に各サービスに専用のデータストレージを用意することで、これは疎結合設計原則の拡張です。この実践により、競合を防ぎ、サービスのスケーラビリティを向上させることができます。
さらに、メッセージブローカーのような非同期マイクロサービス通信パターンが必要です。これにより、各サービスが直接的な依存関係なく通信できるようになります。
最後に必要なのは、マイクロサービス用の継続的インテグレーションと継続的デリバリー(CI/CD)パイプラインの実装です。これらのパイプラインにより、チームは新機能や修正を以下のようにデプロイできます CI/CDツール JenkinsやGitLabなどを使用することで、組織は頻繁に新機能をリリースしながらシステムの安定性を維持できます。
マイクロサービスのデプロイに必要な計画と準備についての全体像を理解したところで、マイクロサービスのデプロイ戦略について説明しましょう。
マイクロサービスデプロイ戦略
マイクロサービスをデプロイする場合、デプロイ戦略の選択はサービスの機能、トラフィック、インフラストラクチャのセットアップ、チームの専門知識、コストの検討によって異なります。ただし、一般的にはマイクロサービスデプロイ戦略は以下の通りです。
- コンテナあたりのサービスインスタンス このアプローチでは、各マイクロサービスが独自のコンテナで実行され、ホストあたりの複数インスタンスモデルよりも優れた分離を提供します。コンテナにより簡単なスケーリングが可能になり、リソース配分が向上します。
- 仮想マシンあたりのサービスインスタンス 各サービスが独立した仮想マシン(VM)で実行され、コンテナよりも優れた分離を実現します。セキュリティと安定性は向上しますが、通常はオーバーヘッドが増加します。
- 段階的リリース: 最初に、マイクロサービスの新バージョンをユーザーの小規模なグループにデプロイし、本番環境への全面展開前に安定性をテストします。このアプローチにより、問題が発生した場合の影響を最小限に抑え、システムの完全性を維持するための迅速なロールバックが可能になります。
- ブルーグリーンデプロイ この方法は2つの同一の本番環境を使用し、一方の環境は実際のトラフィックを処理し、もう一方は次のリリースのテストに使用されます。ブルーグリーンデプロイにより、2つの環境間でトラフィックをシームレスに切り替えられるため、ロールバックが簡単で、ダウンタイムのないアップデートが可能になります。
- ステージド リリース: この戦略では、異なるユーザーセグメントまたは環境に更新を段階的にロールアウトします。通常は本番環境に到達する前に内部環境から開始され、潜在的な問題の影響範囲を制限し、チームが段階的に問題に対処できるようにします。
- サーバーレスデプロイメント このアプローチでは、AWS FargateおよびGoogle Cloud Runなどのサーバーレスプラットフォームを活用します。これらはスケーリングとリソース配分を自動的に処理することでインフラストラクチャ管理を自動化します。サーバーレスデプロイを使用すれば、基盤となるサーバーを管理する必要がなくなり、マイクロサービス自体に集中できます。
上記のマイクロサービスデプロイ戦略のいずれかを選択した後は、マイクロサービスオーケストレーションツールが必要になります。
マイクロサービスオーケストレーション
多くのマイクロサービスデプロイ戦略の中から1つを選択した後は、マイクロサービスオーケストレーション用の調整者が必要になります。以下のようなマイクロサービスオーケストレーションツールは、 Kubernetesマイクロサービスのデプロイ、スケーリング、監視、およびコンテナ化されたマイクロサービスの管理を自動化するのに役立ちます。
例えば、AirbnbはKubernetesを使用しており、エンジニアは手動での監視なしに数百のマイクロサービス変更をデプロイできます。Kubernetesなどのマイクロサービスオーケストレーションツールの重要な機能の1つは、組み込みのロードバランシングです。
適切なロードバランシング機能は、複数のマイクロサービスインスタンス間に受信トラフィックを分散させるのに役立ちます。これにより、単一のインスタンスがボトルネックになるのを防ぎ、需要の急増に対処するシステムの能力を向上させます。
Kubernetesは、障害が発生したコンテナが自動的に交換および再起動されるセルフヒーリング機能により、マイクロサービスの管理において重要な役割を果たします。ニューヨーク・タイムズはこの機能を活用して、ユーザーエクスペリエンスに影響を与えず、ダウンタイムなしにマイクロサービスを維持しています。
さらに、Kubernetesはマイクロサービスのセキュリティも向上させ、ConfigMapsとSecretsを使用してデータベースの認証情報やAPIキーなどの設定とシークレットを保護します。これは、機密顧客情報を扱うUberなどの企業やサービスにとって特に重要です。
最後に、Kubernetesなどのマイクロサービスオーケストレーションツールは、段階的なリリースなどのローリングアップデートとロールバックを含むマイクロサービス戦略に特に有益です。ローリングアップデートは、古いバージョンのインスタンスの一部を実行状態で保つことで、サービスを中断することなく新しいマイクロサービスバージョンをデプロイするのを実現します。
マイクロサービスオーケストレーションツールをセットアップしたら、次は以下を構築および自動化する必要があります CI/CDパイプライン マイクロサービスのデプロイメント向け。
マイクロサービスデプロイメント用CI/CDパイプライン
前述の通り、マイクロサービス向けの継続的インテグレーション(CI)と継続的デリバリー(CD)パイプラインは、マイクロサービスデプロイメントの重要な要素です。CI/CDパイプライン内の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 Remote Procedure Call)、そして GraphQL.
一般的に、この種のマイクロサービス通信パターンは、リアルタイムデータ処理と即座の応答が必要な業界や企業で使用されます。金融、医療、電子商取引などの業界は、トランザクション、データ取得、相互作用が瞬時に行われることを保証し、スムーズで応答性の高いユーザー体験を維持するために、同期型通信パターンを頻繁に使用しています。
とはいえ、同期型マイクロサービス通信パターンはリアルタイム応答とシンプルさというメリットがある一方で、密結合による潜在的なボトルネック、高負荷下でのスケーラビリティの低さ、遅い応答時間、トラフィック増加時の高レイテンシーなど、特定の欠点もあります。
一方、非同期型マイクロサービス通信パターンは、前述のルーズカップリング原則に基づいているため、一般的にマイクロサービスにより適しています。
この種のマイクロサービス通信パターンは、KafkaやRabbitMQなどのブローカーを通じてメッセージを送受信することで、サービスをデカップリングします。キューにメッセージを送信することで、サービスは同期型通信パターンのように応答を待つのではなく、互いに独立して通信します。このバッファにより、他のサービスは自身のペースでメッセージを処理できるようになり、送信者は受信者の応答を待たずに処理を続行できます。
非同期型マイクロサービス通信パターンはマイクロサービスデプロイメント用のデカップリング構造を提供するだけでなく、同期型マイクロサービス通信パターンと同じリアルタイム応答ももたらします。
これは非同期イベント駆動型マイクロサービス通信パターンのイベント駆動アーキテクチャによるものです。サービスは特定のアクションが発生したときにイベントを発行することで通信します。他のサービスはこれらのイベントをサブスクライブして、それに応じて対応できます。これにより、サービス間の直接的な結合なしにリアルタイムで変化に対応する、非常に応答性の高いシステムが実現されます。
さらに、非同期で Publish-Subscribe(Pub/Sub) マイクロサービス通信パターンでは、サービス(パブリッシャー)がトピックにメッセージを送信し、他のサービス(サブスクライバー)がそのトピックをリッスンして更新を受け取ります。このモデルは複数のサブスクライバーをサポートし、多くのサービスへのメッセージの同時ブロードキャストを実現します。
最後に、イベント駆動型パターンと同様に、非同期型 コレオグラフィーベースのサガ マイクロサービス通信パターンもイベントを使用して相互に通信しますが、このパターンでは特定の順序が存在しており、イベントが次のステップと特定のサービスの起動をトリガーします。
イベント駆動パターンの場合、特定のシーケンスやワークフローがなく、複数のサービスが単一のプロセスと順序に従うコレオグラフィベースのサガパターンではなく、イベントに反応できるという点が異なります。
使用する非同期マイクロサービス通信パターンは、マイクロサービスのタスクと全体的な機能によって異なります。RabbitMQやAmazon SQSなどのメッセージキューは、通常、タスクスケジューリング、ワークロード分散、eコマースの注文処理と通知システムに使用されます。
Apache Kafkaやこんにちは0119XZ EventBridgeなどのイベント駆動型メッセージブローカーは、通常、リアルタイムでの大規模なイベントストリームの処理と、金融サービスやAWS環境などの領域でのマイクロサービス間のイベントルーティングに使用されます。
Go Google Cloud Pub/SubやRedis Streamsなどのパブリッシュ・サブスクライブ（Pub/Sub）メッセージブローカーは、通常、分散システム全体の拡張可能なメッセージング、リアルタイム分析とイベント取得、リアルタイム通知、チャットアプリケーションに使用されます。
最後に、コレオグラフィベースのサガメッセージブローカーは、主にeコマース注文処理、旅行予約システム、複雑な多段階トランザクションが中央制御なく複数のサービス間で調整される必要があるユースケースに使用されます。
マイクロサービスのサービスディスカバリー
通信パターンをセットアップして実装したら、サービスが相互に見つけられるようにする必要があります。前述したように、Kubernetesなどのマイクロサービスオーケストレーションツールはマイクロサービスのサービスディスカバリーで重要な役割を果たします。
これは、Kubernetes DNSが提供する組み込みサービスディスカバリーを通じて実現され、クラスタ内でサービスがスケーリングまたは場所を変更する際にIPアドレスとDNSレコードを動的に更新します。
このマイクロサービスのサービスディスカバリー方法はサーバー側ディスカバリーと呼ばれます。ルーティング責任がロードバランサーに委譲され、そのロードバランサーがレジストリを照会して適切なインスタンスにトラフィックを送信するためです。
一方、マイクロサービスのサービスディスカバリーのクライアント側ディスカバリー方法もあります。この場合、サービスまたはAPIゲートウェイがConsulやEurekaなどのサービスレジストリを照会して利用可能なインスタンスを見つけます。
マイクロサービスのデプロイにどのサービスディスカバリー方法を使用するかの選択は、システムの要件と規模によって異なります。
クライアント側のマイクロサービスのサービスディスカバリーでは、クライアントが通信対象のインスタンスを完全に制御します。これにより、より多くのカスタマイズが可能になるだけでなく、中央集中型のディスカバリーサービスが不要なため複雑性も低減します。
例えば、NetflixのマイクロサービスデプロイはEurekaとRibbonを使用したクライアント側マイクロサービスのサービスディスカバリーを使用しており、クライアントがレイテンシとサーバー負荷などの基準に基づいて最適なインスタンスを選択できます。
一方、サーバー側マイクロサービスのサービスディスカバリーはより大規模な環境に適しています。中央集中型のサービスディスカバリーにより効率が向上し、分散システム全体で一貫したロードバランシングが可能になるためです。
Kubernetes、AWS Elastic Load Balancing、APIゲートウェイ（Kong、NGINXなど）などのサーバー側マイクロサービスのサービスディスカバリーソリューションは、トラフィックを効率的にルーティングし高可用性を維持し、AirbnbやPinterest、Expedia、Lyftなどの企業で使用されています。
マイクロサービス セキュリティ
モノリシックアーキテクチャはほとんどの場合MSAに劣りますが、モノリシックアーキテクチャが優れていた側面の1つはセキュリティです。マイクロサービスは疎結合の原則に基づいて構築され、分散的な性質を持っているため、単一の一般的なセキュリティ対策を実装することはできません。
各サービスは独立して保護される必要があるため、攻撃対象領域がマイクロサービスではより広いため追加的な保護措置が必要です。このため、OAuth2やJSON Web Tokens（JWT）などの標準が、認証と認可に一般的に使用されます。
さらに、APIゲートウェイもマイクロサービス全体のセキュリティを管理するために頻繁に採用されます。エントリーポイントで認証と認可を実施するためです。また、ゲートウェイのAPIは、レート制限、ログ、監視も実装でき、マイクロサービスセキュリティの追加層を提供します。
これらはメインエントリーポイントを保護しますが、サービス間通信をカバーするにはさらに多くのマイクロサービスセキュリティ対策が必要です。
ここでサービスメッシュが役に立ちます。ネットワークマイクロサービスセキュリティの層を追加し、サービス間のトラフィックを暗号化し、相互TLSなどのポリシーを実施します。これらのサーバーメッシュは基本的に包括的なエンドツーエンド暗号化をセットアップし、マイクロサービスセキュリティを大幅に向上させます。
マイクロサービススケーリング
MSAの最大の利点の1つであり、モノリシックアーキテクチャを置き換えるために開発された理由そのものが、その高い拡張性です。通常、マイクロサービスのスケーリングは2つの方法で行われます。垂直と水平です。
基本的に、垂直マイクロサービススケーリング（スケールアップ）とは、既存のインスタンスにCPUやメモリなどのリソースを追加することです。一方、水平マイクロサービススケーリング（スケールアウト）は負荷を分散し容量を増やします。
実装の観点からすると、垂直マイクロサービススケーリングはより簡単です。単一のインスタンスを変更して、より大きなサーバーにアップグレードしたり、クラウドインスタンスのメモリまたは処理能力を増やしたり、より多くのストレージを追加したりするだけで済むためです。
このタイプのスケーリングは通常、RAMまたはCPU処理能力の向上がクエリパフォーマンスとデータ処理を改善できる場合に使用されます。例えば、インメモリキャッシングを担当するサービスなどです。
とはいえ、垂直スケーリングはより簡単で即座なパフォーマンス向上をもたらしますが、欠点もあります。垂直スケーリングはサーバーのハードウェア容量に制限されるため、ある時点で水平スケーリングに切り替える必要が出てきます。
さらに、垂直スケーリングはコストが高くなります。ハードウェアとより大きなインスタンスは一般的に高い価格がつくためです。最後に、スケールアップされたインスタンスに障害が発生すると、追加のインスタンスがないため、サービス全体がダウンします。
水平スケーリングでは、単一インスタンスのリソースをアップグレードするのではなく、そのサービスの新しいインスタンスをデプロイします。これらのインスタンスは独立して動作しますが、同じサービスと同じワークロードの一部を処理します。
垂直スケーリングと異なり、水平スケーリングは無制限です。増加するワークロードとトラフィックスパイクに対応するために、好きなだけインスタンスを追加でき、より高いスケーラビリティを提供します。
また、複数のインスタンスがあるため、1つが停止しても他のインスタンスがリクエストを継続処理できます。最後に、水平スケーリングはより多くの小さく安価なインスタンスを使用してより信頼性が高く、より強力なパフォーマンスを実現するため、長期的にはコスト効率が大幅に改善されます。
とはいえ、水平スケーリングと追加インスタンスにはロードバランサー、マイクロサービスのサービスディスカバリーメカニズム、マイクロサービスオーケストレーションツールが必要となり、マイクロサービスアーキテクチャがはるかに複雑になります。
水平スケーリングはWebサービスやeコマース、ソーシャルメディアプラットフォームなどのアプリケーションに適しており、これらは変動するトラフィックと大量のリクエストを頻繁に経験します。
とはいえ、両方のスケーリング方式はマイクロサービスでサポートされており、多くの場合に必要です。通常、小規模な組織は実装と管理がシンプルなため垂直スケーリングから始めますが、時間とともにアプリケーションが成長すると、高い需要に対応するために水平スケーリングが導入されます。
最後に、クラウドプラットフォームはオートスケーリングサービスを提供し、リアルタイムの需要に基づいて自動的にインスタンスを追加または削除します。これは組織が垂直スケーリングと水平スケーリングのバランスを取るのに大きく役立ちます。
マイクロサービス監視
この段階では、マイクロサービスのデプロイはほぼ完了しており、残されているのは一貫して信頼性高く動作することを確認することだけです。ここで登場するのがマイクロサービスモニタリングツールです。 Prometheus および Grafana 今すぐ参加してください。
これらのツールはサービスメトリクスへのリアルタイムインサイトを提供し、チームがリソース使用率、レイテンシー、エラーレートを追跡できます。さらに、これらのツールは分散トレーシング機能(Jaeger、Zipkinなど)も備えており、サービス間のリクエストフローを可視化し、問題の診断に非常に役立ちます。
最後に、マイクロサービスの分散設計により障害がサービス間で連鎖する可能性があるため、ログ集約はマイクロサービスモニタリングにおける重要な実践です。ログを一元化されたプラットフォームに統合し、リアルタイムアラートを設定することで、常に問題より先手を打ち、ユーザーに影響を与える前に積極的に対応できます。
最後に
マイクロサービスの世界は確かに複雑ですが、基礎と主要段階を理解することで、プロセス全体をはるかに簡単にできます。また、年を重ねるごとに、より多くの機能を備えたツールが手に入るようになり、マイクロサービスのデプロイはこれまで以上にシンプルになっています。
よくあるご質問
マイクロサービスに一般的に使用されるデプロイ戦略は何ですか?
マイクロサービスのデプロイ戦略には多くの種類がありますが、最も一般的に使用される戦略としてはコンテナごとのサービスインスタンス、段階的リリース、ブルーグリーンデプロイメント、サーバーレスデプロイメントが挙げられ、それぞれが異なるレベルの分離、柔軟性、スケーラビリティを提供します。
Kubernetes はマイクロサービスのオーケストレーションにどのような役割を果たしていますか?
マイクロサービスは、Kubernetes などのマイクロサービスオーケストレーションツールに依存して、コンテナ化されたサービスのデプロイメント、スケーリング、管理を自動化し、ロードバランシング、オートスケーリング、自己修復機能を提供して、堅牢で効率的なマイクロサービスを実現します。
マイクロサービス環境でセキュリティを確保するにはどうすればよいですか?
マイクロサービスはその分散特性により、モノリシックアーキテクチャと比べてセキュリティがより複雑です。マイクロサービスのセキュリティには、リクエストの認証と認可、サービス間通信の暗号化、API ゲートウェイと Istio などのサービスメッシュの実装が含まれ、一元化されたセキュリティ管理を実現します。
