Zenn
😎

マイクロサービスについてまとめてみました

2024/09/16に公開
マイクロサービス
トランザクション
マイクロサービスアーキテクチャ
ロールバック
tech

マイクロサービスとは

マイクロサービス（Microservicesは、ソフトウェアアーキテクチャの一つであり、大規模なアプリケーションを複数の小さな独立したサービス（マイクロサービス）に分割する設計スタイルです。各マイクロサービスは特定のビジネス機能を担い、他のマイクロサービスとは疎結合で独立してデプロイおよびスケーリングすることができます。マイクロサービスアーキテクチャは、モノリシックアーキテクチャ（単一の大きなアプリケーション）に対する代替として、スケーラビリティ、開発の迅速化、保守性の向上を目指しています。

マイクロサービスの特徴

  • 単一の責任原則（Single Responsibility Principle）:
    各マイクロサービスは、特定のビジネス機能またはドメインに焦点を当て、その機能のみを提供します。これにより、サービスが小さく、理解しやすく、変更に強くなります。

  • 疎結合（Loose Coupling）:
    マイクロサービス同士は独立して運用され、他のサービスに依存せずに機能します。サービス間の通信は一般的に軽量なAPI（RESTful APIやgRPCなど）を通じて行われます。

  • 独立したデプロイ（Independent Deployment）:
    各マイクロサービスは独立してデプロイ可能です。これにより、個別のサービスを再デプロイしたり、バージョンアップしたりする際に、他のサービスに影響を与えることなく行うことができます。

  • 独自のデータストア（Polyglot Persistence）:
    マイクロサービスは、必要に応じて異なるデータストア（リレーショナルデータベース、NoSQLデータベースなど）を使用することができます。各サービスがそのニーズに最適な技術スタックを選択できます。

  • スケーラビリティ（Scalability）:
    特定のサービスのみを個別にスケールアップまたはスケールアウトすることが可能です。これにより、システム全体のパフォーマンスとリソース使用効率を最適化できます。

  • 自律的なチーム（Autonomous Teams）:
    各マイクロサービスは独立して開発・運用が可能であるため、異なるチームが異なるサービスを同時に開発・保守できます。これにより、開発プロセスの効率化とリリースの迅速化が図られます。

マイクロサービスの利点

  • 開発とデプロイのスピード向上:
    小さなサービスに分割することで、チームは独立して作業でき、迅速にリリースやデプロイを行うことができます。

  • 柔軟性の向上:
    各サービスは独自の技術スタックを持つことができるため、異なる言語やフレームワークを適用する柔軟性があります。

  • スケーラビリティ:
    必要なサービスだけをスケールアウトすることができるため、コスト効率の良いスケーラビリティを実現します。

  • 障害の隔離:
    一つのマイクロサービスに障害が発生しても、システム全体には影響を与えずに済む場合が多いです。これにより、全体的な耐障害性が向上します。

  • 保守性の向上:
    小さなコードベースを管理するため、理解しやすく、変更やテストも容易です。

マイクロサービスの課題

  • 複雑性の増加:
    システム全体が多くの独立したサービスに分かれるため、サービス間の通信やデータの一貫性管理が複雑になることがあります。

  • デプロイの管理:
    各マイクロサービスのデプロイを個別に管理する必要があり、デプロイメントパイプラインの自動化と管理が求められます。

  • データの一貫性:
    各サービスが独自のデータストアを持つことが多いため、データの整合性を保つのが難しくなる場合があります。

  • 分散システムの管理:
    サービス間の通信やトラフィックの管理、監視、トラブルシューティングが複雑になります。

  • ネットワークのオーバーヘッド:
    サービス間の通信がネットワークを介して行われるため、ネットワークのオーバーヘッドや遅延が発生することがあります。

マイクロサービスの具体例

  • 例1: オンラインショッピングサイト:

    • ユーザーサービス: ユーザーの登録、認証、プロファイル管理など。
    • 商品サービス: 商品の情報、在庫の管理など。
    • カートサービス: ショッピングカートの管理（追加、削除、購入）。
    • 注文サービス: 注文の生成、更新、支払い処理。
    • 配送サービス: 配送状況の管理と更新。

  • 例2: 動画ストリーミングサービス:

    • ユーザー管理サービス: ユーザー登録、認証、サブスクリプション管理。
    • コンテンツ管理サービス: 動画のアップロード、メタデータの管理、カテゴリ分け。
    • ストリーミングサービス: 動画のエンコードとストリーミング配信。
    • レコメンデーションサービス: 視聴履歴に基づくおすすめの提供。

マイクロサービスの導入の際の考慮点

  • サービスの境界を明確にする:
    各サービスの責任範囲を明確に定義し、サービス間の相互依存を最小限に抑える。

  • 監視とロギングを強化する:
    各サービスのパフォーマンスやエラーを詳細に監視し、統合的に管理できるようにする。

  • 自動化の活用:
    継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインを構築し、サービスのビルド、テスト、デプロイを自動化する。

  • セキュリティの強化:
    各サービス間の通信を保護し、セキュリティ対策を徹底する。

  • データの一貫性の管理:
    分散トランザクションやイベント駆動アーキテクチャを使用して、データの一貫性を保つ戦略を考慮する。

マイクロサービスのアーキテクチャ設計の注意点は？

マイクロサービスアーキテクチャの設計には、多くの利点がありますが、同時に特有の課題や注意点も伴います。以下は、マイクロサービスアーキテクチャを設計する際の主な注意点です。

1. サービスの適切な分割（境界の定義）

  • 注意点: マイクロサービスの成功には、適切なサービス分割が不可欠です。サービスの責任範囲が適切に定義されていないと、モノリシックな依存関係が残ったり、サービス間の通信が過度に複雑になるリスクがあります。
  • ポイント:
    • ドメイン駆動設計（DDD）の「バウンデッドコンテキスト」を活用し、各サービスのドメインモデルと責任を明確に分ける。
    • 各サービスは単一のビジネス機能を担当し、他のサービスとの依存関係を最小限にする。

2. サービス間の通信設計

  • 注意点: マイクロサービスは分散システムであるため、サービス間の通信が不可欠です。通信プロトコル（例：HTTP/REST、gRPC、メッセージブローカー）を選択し、通信の遅延や失敗に対処する設計が必要です。
  • ポイント:
    • 軽量で効率的なプロトコルを選択する（例：gRPC、HTTP/2）。
    • 非同期通信が適している場合は、メッセージブローカー（例：RabbitMQ、Kafka）を使用して疎結合を実現する。
    • リトライ、サーキットブレーカー、タイムアウトなどの通信エラー処理を組み込む。

3. データ管理と整合性の確保

  • 注意点: マイクロサービスでは、各サービスが独自のデータストアを持つことが多いため、データの整合性と一貫性を保つことが課題になります。
  • ポイント:
    • 各サービスが独自のデータベースを持つ「データベースの分離（Database per Service）」を採用する。
    • 分散トランザクションの代わりに「最終的な整合性（Eventual Consistency）」を許容する設計を検討する。
    • イベントソーシングやCQRS（Command Query Responsibility Segregation）パターンを使用して、データの変更をイベントとして扱い、データの整合性を保つ。

4. セキュリティの考慮

  • 注意点: 分散システムでは、各サービスがネットワーク越しに通信するため、セキュリティリスクが増加します。
  • ポイント:
    • 各サービス間の通信を暗号化する（例：TLS/SSL）。
    • サービス間の認証と認可を実装する（例：OAuth 2.0、JWT）。
    • セキュリティの境界（例：APIゲートウェイ）を設置し、サービスへの直接アクセスを制限する。

5. 分散トレーシングと監視

  • 注意点: マイクロサービス環境では、複数のサービスが連携して機能を提供するため、問題のトラブルシューティングが難しくなります。サービスの状態やパフォーマンスを監視するための仕組みが不可欠です。
  • ポイント:
    • 分散トレーシングツール（例：Jaeger、Zipkin）を使用して、サービス間のリクエストフローを追跡し、ボトルネックやエラーの発生箇所を特定する。
    • ロギング（例：ELKスタック、Prometheus）とメトリクス収集ツールを統合し、リアルタイムの監視を行う。

6. デプロイとリリースの戦略

  • 注意点: マイクロサービスでは、各サービスが独立してデプロイ可能であるため、複数のサービスを同時にリリースする場合の整合性が問題になります。
  • ポイント:
    • CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを構築し、各サービスのビルド、テスト、デプロイを自動化する。
    • カナリアリリースやブルーグリーンデプロイメントを利用して、リリースリスクを最小化する。

7. フェイルオーバーとフォールトトレランス

  • 注意点: マイクロサービス環境では、各サービスが他のサービスに依存しているため、障害が発生した場合の影響を最小限に抑えるための設計が重要です。
  • ポイント:
    • サーキットブレーカー（Circuit Breaker）パターンを実装し、障害時にシステムの安定性を保つ。
    • フォールバック（Fallback）メカニズムを用意して、依存するサービスが利用できない場合でも代替処理を行う。

8. ネットワークの信頼性とレイテンシの管理

  • 注意点: 分散環境ではネットワークの信頼性が重要です。ネットワーク遅延やパケットロスに対処するための設計が求められます。
  • ポイント:
    • ネットワークのレイテンシを最小化するために、可能な限り同一のリージョンやデータセンター内でサービスをデプロイする。
    • ネットワークの冗長性を確保し、ネットワーク障害に備える。

9. 自動スケーリング

  • 注意点: マイクロサービスでは、異なるサービスが異なる負荷を持つ可能性があり、個々のサービスを自動的にスケーリングできるようにする必要があります。
  • ポイント:
    • コンテナオーケストレーションツール（例：Kubernetes、Docker Swarm）を使用して、サービスごとに自動スケーリングルールを設定する。
    • スケーリングの閾値を適切に設定し、過負荷を防止する。

10. データのキャッシングとパフォーマンスの最適化

  • 注意点: 各サービスが独自のデータベースにアクセスするため、パフォーマンスの最適化が重要です。
  • ポイント:
    • RedisやMemcachedなどの分散キャッシュを使用して、頻繁にアクセスされるデータの読み取りを高速化する。
    • 適切なインデックスの設定とクエリの最適化を行う。

Sagaの基本概念

Sagaは、複数のローカルトランザクションで構成され、それぞれのトランザクションが独立したマイクロサービスで実行されます。各トランザクションが成功するたびに、その結果が次のサービスに引き渡され、すべてのトランザクションが完了すると、全体のトランザクションが成功と見なされます。どこかで失敗が発生した場合、その時点までに行われたすべての操作をロールバックするための補償トランザクションを実行します。

sagaの実装パターンとは

Sagaパターンは、分散トランザクションの管理に使用されるデザインパターンであり、マイクロサービスアーキテクチャにおいて複数のサービスが関わる一貫性のある長いトランザクションを管理するために使用されます。分散システムでは、従来のACIDトランザクションを使用することが難しいため、Sagaパターンを使って、最終的な整合性（eventual consistency）を保ちながら、複数のサービス間でトランザクションを調整します。

Sagaパターンには主に2つの実装方法があります：

1. コレオグラフィー（Choreography）パターン

  • 概要: コレオグラフィーパターンでは、各サービスが独立して動作し、他のサービスと直接的にコミュニケーションを取ります。サービスはイベントを生成し、それを他のサービスがリッスンしてトリガーとして使用します。イベント駆動型のアプローチであり、サービス間の依存が緩く、シンプルに実装できます。

  • 動作:

    1. 各サービスは、Sagaの一部として自身のローカルトランザクションを実行します。
    2. トランザクションが成功すると、次のサービスが処理を開始するためのイベントを発行します。
    3. このイベントを受け取った次のサービスは、トランザクションを開始し、同様にイベントを発行します。
    4. どこかで失敗が発生した場合、そのサービスは補償トランザクションを開始し、イベントを発行します。他のサービスも同様に補償トランザクションを実行します。

  • 利点:

    • 分散性が高く、単一障害点（single point of failure）がない。
    • サービスが独立して動作できるため、疎結合であり、シンプルに拡張が可能。

  • 欠点:

    • すべてのサービスが他のサービスからのイベントを認識している必要があるため、イベントストームのリスクがある。
    • サービス間の依存関係が複雑になる可能性があり、管理が難しくなる。

  • 例:

    • オンラインショッピングの注文処理：
      1. 注文サービスが注文を受け取り、「注文受け付け」イベントを発行。
      2. 在庫サービスが「注文受け付け」イベントを受付け、在庫を引き当て、「在庫引き当て成功」イベントを発行。
      3. 支払いサービスが「在庫引き当て成功」イベントを受付け、支払いを処理、「支払い成功」イベントを発行。
      4. 各ステップで失敗が発生した場合、補償トランザクションを行い、それぞれのイベント（例：「在庫引き当てキャンセル」、「支払いキャンセル」）を発行してロールバックを実行。

コレオグラフィー（Choreography）パターンの図を以下に示します。これは、各サービスが独立してイベントを発行し、それに基づいて他のサービスがアクションを実行する様子を表しています。

   +------------------+          +------------------+          +------------------+
   |   Order Service  |          |  Inventory Service|          |   Payment Service |
   +------------------+          +------------------+          +------------------+
            |                           |                           |
            | 1. Order Placed           |                           |
            +--------------------------> |                           |
            |                           |                           |
            |                           | 2. Inventory Reserved       |
            |                           +--------------------------> |
            |                           |                           |
            |                           |                           | 3. Payment Processed
            |                           |                           +--------------------------> 
            |                           |                           | 
            |                           |                           |
            |                           |                           |
   +------------------+          +------------------+          +------------------+
   | Compensation     |          | Compensation     |          | Compensation     |
   | Service          |          | Service          |          | Service          |
   +------------------+          +------------------+          +------------------+
            ^                           ^                           ^
            |                           |                           |
            | 4. Rollback Order         | 5. Rollback Inventory      | 6. Rollback Payment
            +--------------------------> +--------------------------> +------------------------>

説明

  1. Order Service が注文を受け付けると、「Order Placed」イベントを発行します。
  2. Inventory Service は「Order Placed」イベントを受け取り、在庫の引き当てを行い、「Inventory Reserved」イベントを発行します。
  3. Payment Service は「Inventory Reserved」イベントを受け取り、支払い処理を行い、「Payment Processed」イベントを発行します。

もし途中で失敗が発生した場合：

  1. Compensation Services がロールバック処理を行い、注文、在庫、支払いの各サービスに対してキャンセルや修正の指示を出します。

この図では、各サービスがイベントを通じて連携し、トランザクションの各ステップを独立して実行している様子が示されています。失敗時には、補償トランザクションが実行されて、全体の一貫性が保たれるようにします。

2. オーケストレーション（Orchestration）パターン

  • 概要: オーケストレーションパターンでは、中央のオーケストレーターサービスが全体のトランザクションフローを管理します。オーケストレーターは、各サービスに対して個別の指示を出し、トランザクションのステップを制御します。各サービスはオーケストレーターの指示に従ってトランザクションを実行し、その結果をオーケストレーターに通知します。

  • 動作:

    1. オーケストレーターがトランザクションを開始し、最初のサービスに対して操作を依頼します。
    2. サービスがトランザクションを実行し、結果をオーケストレーターに返します。
    3. オーケストレーターが次のサービスに対して操作を依頼し、このプロセスをすべてのステップで繰り返します。
    4. 途中で失敗が発生した場合、オーケストレーターは補償トランザクションを開始し、各サービスにロールバックを指示します。

  • 利点:

    • 中央のオーケストレーターがトランザクションのフローを管理するため、全体のプロセスの可視性と制御が向上します。
    • トランザクションフローの管理がシンプルで明確になります。

  • 欠点:

    • オーケストレーターサービスが単一障害点（single point of failure）となり得る。
    • オーケストレーターの複雑さが増すと、メンテナンスが難しくなる。

  • 例:

    • 同じオンラインショッピングの注文処理：
      1. オーケストレーターが注文を受け取り、注文サービスに注文作成を依頼。
      2. 注文サービスが注文を作成し、結果をオーケストレーターに返す。
      3. オーケストレーターが次に在庫サービスに在庫引き当てを依頼。
      4. 在庫サービスが在庫を引き当て、結果をオーケストレーターに返す。
      5. オーケストレーターが支払いサービスに支払い処理を依頼。
      6. 途中で失敗が発生した場合、オーケストレーターが補償トランザクションを開始し、各サービスにロールバックを指示します。

オーケストレーション（Orchestration）パターンの図を以下に示します。このパターンでは、中央のオーケストレーターサービスが全体のトランザクションフローを管理します。

   +---------------------+
   |   Orchestrator      |
   +---------------------+
              |
              | 1. Start Order Transaction
              v
   +------------------+
   |  Order Service   |
   +------------------+
              |
              | 2. Order Created
              v
   +------------------+
   | Inventory Service|
   +------------------+
              |
              | 3. Inventory Reserved
              v
   +------------------+
   | Payment Service  |
   +------------------+
              |
              | 4. Payment Processed
              v
   +---------------------+
   |   Orchestrator      |
   +---------------------+
              |
              | 5. Complete Transaction
              v

  [Failure Handling]
       |
       | 6. Start Compensation
       v
  +------------------+
  | Rollback Order   |
  +------------------+
              |
              v
  +------------------+
  | Rollback Inventory|
  +------------------+
              |
              v
  +------------------+
  | Rollback Payment |
  +------------------+

説明

  1. Orchestrator がトランザクションの開始を指示します（例：「Start Order Transaction」）。
  2. Order Service が注文を作成し、結果を Orchestrator に通知します（例：「Order Created」）。
  3. Orchestrator が次に Inventory Service に在庫の引き当てを指示します（例：「Reserve Inventory」）。
  4. Inventory Service が在庫を引き当てた後、結果を Orchestrator に通知します（例：「Inventory Reserved」）。
  5. Orchestrator が Payment Service に支払い処理を指示します（例：「Process Payment」）。
  6. Payment Service が支払いを処理した後、結果を Orchestrator に通知します（例：「Payment Processed」）。
  7. Orchestrator がトランザクションの完了を指示します（例：「Complete Transaction」）。

もし途中で失敗が発生した場合：

  1. Orchestrator が補償トランザクションを開始し、各サービスにロールバック処理を指示します（例：「Rollback Order」、「Rollback Inventory」、「Rollback Payment」）。

この図では、中央のオーケストレーターサービスがトランザクション全体を制御し、各サービスに指示を出している様子を示しています。失敗時には、オーケストレーターが補償トランザクションを管理して一貫性を保ちます。

Sagaパターンの選択時の考慮事項

  • トランザクションの複雑さ: トランザクションが非常に複雑で、サービス間の依存関係が多い場合、オーケストレーションパターンの方が管理がしやすいです。
  • 可視性と制御: トランザクションの全体的な可視性と制御が必要な場合、オーケストレーションパターンが適しています。
  • サービスの独立性: 各サービスが独立して動作する必要があり、疎結合であることを優先する場合、コレオグラフィーパターンが適しています。
  • 障害管理: 単一障害点を避ける必要がある場合、コレオグラフィーパターンの方が適していることが多いです。
  • 運用の複雑さ: コレオグラフィーパターンはサービス間のイベントストームを引き起こす可能性があるため、イベントの流れが管理しやすいオーケストレーションパターンの方が適している場合があります。

まとめ

  • マイクロサービスアーキテクチャは、スケーラブルで柔軟なシステムを構築するための有効な手法ですが、同時に運用の複雑さを増す可能性があります。設計の初期段階での慎重な計画と適切なツールの選択が成功の鍵となります。
  • マイクロサービスアーキテクチャの設計は、多くの利点を提供する一方で、適切に設計・運用しないと複雑さを招き、システムの信頼性やパフォーマンスが低下するリスクがあります。設計段階でこれらの注意点を考慮し、慎重に計画を立てることで、スケーラブルで効率的なマイクロサービスアーキテクチャを構築することができます。
  • Sagaパターンは、マイクロサービスアーキテクチャで分散トランザクションを管理するための強力なツールです。コレオグラフィーとオーケストレーションの2つのアプローチは、それぞれ異なる利点と課題を持っており、アプリケーションの特定のニーズと要件に応じて適切な方法を選択することが重要です。いずれのアプローチを選択するにしても、サービスの分離、データの整合性、エラーハンドリング、トランザクションの可視性と制御などを慎重に設計することが重要です。

Discussion