スケーラブルで保守可能、復元力のあるシステムを構築するには、マイクロサービス アーキテクチャでますます普及している重要な設計パターンを認識する必要があります。モノリシック アーキテクチャとは対照的に、マイクロサービスは、大規模なシステムを、ネットワークを介して相互に接続する、より管理しやすい独立したサービスに分割します。ただし、この分散型の性質により、通信、データ管理、サービス調整などの分野で複雑さが生じます。

よく知られているマイクロサービス設計パターンを採用すると、これらの問題を軽減し、システムの信頼性と有効性を大幅に向上させることができます。この記事では、すべてのソフトウェア開発者が知っておくべき上位 7 つのマイクロサービス設計パターンについて説明します。

1. API ゲートウェイ パターン

API ゲートウェイは、マイクロサービスに対するすべてのクライアント リクエストの単一のエントリ ポイントとして機能します。クライアントが複数のサービスと直接対話する代わりに、API ゲートウェイはこれらのリクエストを統合し、適切なマイクロサービスにルーティングして、応答を集約します。これにより、クライアントとサーバーの通信が簡素化され、認証、ロギング、レート制限などの横断的な問題を管理する方法が提供されます。

利点：

✓ リクエスト/レスポンス処理の集中制御。

✓ 内部マイクロサービスの複雑さを抽象化することで、クライアント側の対話を簡素化します。

✓ セキュリティ、キャッシュ、スロットルの実装を容易にします。

例：

Node.js で Express.js を使用して基本的な API ゲートウェイを構築する:

import express from 'express';
import proxy from 'express-http-proxy';

const app = express();

// Forward requests to microservice A
app.use('/serviceA', proxy('http://serviceA-url'));

// Forward requests to microservice B
app.use('/serviceB', proxy('http://serviceB-url'));

app.listen(3000, () => {
  console.log('API Gateway running on port 3000');
});

2.サーキットブレーカーパターン

マイクロサービス アーキテクチャでは、サービスの障害は避けられません。サーキット ブレーカー パターンは、サービス呼び出しを監視し、特定の障害しきい値に達した場合に障害が発生したサービスへのさらなる呼び出しを停止することで、連鎖的な障害を防ぐのに役立ちます。サービスが回復すると、サーキット ブレーカーにより通話が再び許可されます。これにより、システムの復元力が向上し、すでに問題が発生しているサービスへの不必要な負荷が防止されます。

利点：

✓ システム全体の障害から保護します。

✓ 障害時にフォールバックまたは代替応答を提供します。

✓ マイクロサービス アーキテクチャの堅牢性を強化します。

例：

Node.js のオポッサム ライブラリをサーキット ブレーカーに使用する:

import CircuitBreaker from 'opossum';
import axios from 'axios';

const options = {
  timeout: 5000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
};

const circuitBreaker = new CircuitBreaker(() => axios.get('http://serviceB-url'), options);

circuitBreaker.fire()
  .then(response => console.log(response.data))
  .catch(err => console.log('Service B is down. Circuit is open.'));

3.サービス パターンごとのデータベース

各マイクロサービスには独自の専用データベースが必要です。これにより、チームが独立して作業できるようになり、サービス間の緊密な結合が軽減されます。この設計パターンにより、共有データベース スキーマへの変更の影響を受けることなく、マイクロサービスが独立して進化できることが保証されます。

利点：

✓ サービス間の依存関係と競合を軽減します。

✓ 独立したスケーリングとスキーマの進化を促進します。

✓ データの所有権と責任を分離します。

4.サガパターン

分散アーキテクチャでは、複数のサービスにまたがるトランザクションを処理することが困難になる場合があります。 Saga パターンは、複数のサービス間で調整される一連のローカル トランザクションを使用して分散トランザクションを管理します。各サービスはトランザクションを実行して次のトランザクションをトリガーし、何か問題が発生した場合に操作を元に戻す補償メカニズムを備えています。

利点：

✓ 集中型のトランザクション マネージャーを使用せずに、一貫した分散トランザクションが可能になります。

✓ マイクロサービス間の結果整合性をサポートします。

✓ 必要に応じて、不完全な操作のロールバックを有効にします。

例：

電子商取引システムでは、注文サービスが注文を作成し、支払いサービスが支払いを処理し、在庫サービスが在庫レベルを更新します。支払いが失敗した場合、注文と在庫の更新をロールバックする必要がありますが、これは補償トランザクションによって処理されます。

5.イベント ソーシング パターン

イベント ソーシング パターンは、システムの状態を一連のイベントとして保存します。マイクロサービスは、現在の状態をデータベースに保存するのではなく、状態の変化を表すイベントを保存します。これらのイベントを再生することで、現在の状態を常に再構築でき、完全な監査証跡が提供され、高度な回復メカニズムが可能になります。

利点：

✓ すべての変更の明確な監査証跡を提供します。

✓ 過去のイベントを再生することで履歴分析が可能になります。

✓ 必要に応じて状態の再構築を容易にします。

例：

会計システムでは、「取引が作成された」「取引が承認された」「取引が完了した」といったイベントがイベントとして保存されます。現在の残高は、すべてのトランザクション イベントを再生することで再計算できます。

6. CQRS (コマンド クエリ責任分離) パターン

CQRS パターンは、読み取り操作と書き込み操作を異なるモデルに分離します。書き込み操作はコマンド モデルによって処理され、読み取り操作はクエリ モデルによって処理されます。このパターンは、読み取りが書き込みよりもはるかに頻繁に行われる高パフォーマンスのアプリケーションに特に役立ちます。

利点：

✓ 読み取り/書き込みの問題を分離することでパフォーマンスを最適化します。

✓ 読み取りと書き込みのさまざまなスケーラビリティ戦略をサポートします。

✓ 特定のタスクに合わせた柔軟なモデルを可能にします。

7.ストラングラーフィグパターン

Strangler Fig パターンは、モノリスの一部をマイクロサービスでリファクタリングまたは置き換えることを可能にする段階的な移行戦略です。新しい機能が追加されると、マイクロサービスとして構築されます。モノリスは、システム全体を一度に中断することなく、時間の経過とともにサービスごとに置き換えられます。

利点：

✓ モノリスからマイクロサービスに移行するための中断のないパスを提供します。

✓ システム全体の書き換えのリスクを軽減します。

✓ 段階的な改善とリファクタリングを可能にします。

例：

システムの他の部分はそのままにしながら、モノリシック アプリケーションのユーザー認証コンポーネントをスタンドアロンのマイクロサービスに抽出することから始めることもできます。時間の経過とともに、システム全体がモジュール化されるまで、より多くのコンポーネントがマイクロサービスに移行されます。

結論

マイクロサービス設計原則を使用するときに分散システムで発生する問題に対処するには、さまざまな方法があります。信頼性とスケーラブルなマイクロサービス アーキテクチャを構築するには、サービス間のデータの管理、サービス間の通信の強化、エラーの適切な処理などの目標に関係なく、これらのパターンを把握する必要があります。特定の要件とトレードオフに対処することで、これらの各パターンはマイクロサービスの回復力とパフォーマンスに貢献します。