マイクロサービス向けのデザイン パターン (Design patterns for microservices)

Posted: 2017/07/07 カテゴリー: Uncategorized
タグ:, , , , , , ,

AzureCAT patterns & practicesチームは、Azureアーキテクチャ センターで9つの新しいデザイン パターンを公開しました。これら9つのパターンは、マイクロサービスの設計、実装時に特に有益です。業界内のマイクロサービスへの興味の高まりが、これらのパターンを文書化する動機でした。

次の図は、マイクロサービス アーキテクチャでこれらのパターンをどのように使えるかを示しています。

image

それぞれのパターンに対して、問題、解決策、いつそのパターンを使うか、実装の考慮事項を説明しています。

新しいパターンは、次の通りです。

  • Ambassador (大使) は、言語に依存しない方法で、監視、ロギング、ルーティング、(TLSなどの) セキュリティといった、クライアント接続の一般的なタスクをオフロードするために使えます。
  • Anti-corruption layer (腐敗防止層) は、新規アプリケーションの設計がレガシー システムへの依存関係によって制限されないようにするために、新規アプリケーションとレガシー アプリケーションとの間のファサード (正面) を実装します。
  • Backends for Frontends (フロントエンド向けのバックエンド) は、デスクトップやモバイルといった異なる種類のクライアント向けに、別々のバックエンド サービスを作成します。これによって、単一のバックエンド サービスが、多様な種類のクライアントの相反する要件に対処する必要がなくなります。このパターンは、クライアント固有の関心事を分離することで、それぞれのマイクロサービスを単純なままにするのに役立ちます。
  • Bulkhead (隔壁) は、接続プール、メモリー、CPUといった重要なリソースを、それぞれのワークロードやサービスごとに分離します。隔壁を使うことで、単一のワークロード (またはサービス) が全てのリソースを消費できなくなり、他のワークロードでリソースが欠乏しなくなります。このパターンは、1つのサービスが引き起こした障害がカスケードするのを防ぐことで、システムの回復性を向上させます。
  • Gateway Aggregation (ゲートウェイ集約) は、複数の個別のマイクロサービスへのリクエストを単一のリクエストに集約し、コンシューマーとサービスとの間のやり取りの回数を削減します。
  • Gateway Offloading (ゲートウェイ オフロード) は、それぞれのマイクロサービスが、SSL証明書の利用といった共有サービス機能を、APIゲートウェイにオフロードできるようにします。
  • Gateway Routing (ゲートウェイ ルーティング) は、コンシューマーが多数の別々のエンドポイントを管理する必要をなくすために、単一のエンドポイントを使って、複数のマイクロサービスへのリクエストをルーティングします。
  • Sidecar (サイドカー) は、分離とカプセル化を提供するために、ヘルパー コンポーネントを別個のコンテナーやプロセスとしてデプロイします。
  • Strangler (ストラングラー、絞め殺し) は、特定の機能の一部を新規サービスに徐々に置き換えることで、インクリメンタルな移行をサポートします。

マイクロサービスの目標は、アプリケーションを、独立してデプロイ可能な小さく自律的なサービスに分解することで、アプリケーション リリースの速度を向上することです。マイクロサービス アーキテクチャはいくつかの課題ももらたし、これらのパターンはこれらの課題を緩和するのに役立ちます。皆さんが自分のプロジェクトでこれらのパターンが有益だと気づくことを、我々は期待しています。いつものように、皆さんからのフィードバックに大いに感謝しています。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中