Microsoft Azure版デザインパターン41個を1行で説明する[1/3:A～C]

デザインパターンといえば1995年にGoFと呼ばれる4人が書いたものが有名で、それ以降も2016年のDesign patterns for container-based distributed systemsなどアーキテクチャのトレンドに合わせて幾つか発展している。デザインパターンが便利なのは中身というより、よい名前の付け方だろう。

Microsoftがまとめたバージョンが良い意味で寄せ集めになっている気がするので、ちょっと目を通してみようかと思う。

Cloud design patterns - Azure Architecture Center

Ambassador pattern

Create helper services that send network requests on behalf of a consumer service or application. An ambassador service can be thought of as an out-of-process proxy that is co-located with the client. This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and resiliency patterns in a language agnostic way. It is often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features.

Ambassador(大使)のようにコンシューマーのアプリケーションを代表して通信するヘルパーサービスを作るというパターン。

レガシーが古くて手を付けられないような場合などに使われるようだ。例ではAmbassadorの中にセキュリティやモニタリング、後述するCircuit Breakingが実装されている。

Anti-corruption Layer pattern

Implement a façade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem. Use this pattern to ensure that an application's design is not limited by dependencies on outside subsystems. This pattern was first described by Eric Evans in Domain-Driven Design.

異なるサブシステムとの間にfacade（教会建築の正面玄関を示す用語で、GoFのデザインパターンではインタフェースを提供する役割）を置くというもの。こうすることでアプリケーションの設計がサブシステムの外側の依存性に制限を受けることがなくなる。

Anti-corruption Layer（腐敗防止層）という呼び方はエリック・エバンスのドメイン駆動開発によるものらしい。個人的にはfacadeでいいんじゃないかなと思う。

Asynchronous Request-Reply pattern

Decouple backend processing from a frontend host, where backend processing needs to be asynchronous, but the frontend still needs a clear response.

リクエストとリプライをasynchronous(非同期)にするというパターン。

Message Queueを想像したが、読んでみるとHTTPでポーリングする例が出ていたのでMessage Queueとは別ものだろう。

Backends for Frontends pattern

Create separate backend services to be consumed by specific frontend applications or interfaces. This pattern is useful when you want to avoid customizing a single backend for multiple interfaces. This pattern was first described by Sam Newman.

モバイルやデスクトップなど異なるフロントエンドで共通のバックエンドを作るのではなく、それぞれのフロントエンドのためのバックエンドを作った方がいいという話。

「モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド」や「マイクロサービスアーキテクチャ」などの著作があるSam Newmanによる用語らしい。

Bulkhead pattern

The Bulkhead pattern is a type of application design that is tolerant of failure. In a bulkhead architecture, elements of an application are isolated into pools so that if one fails, the others will continue to function. It's named after the sectioned partitions (bulkheads) of a ship's hull. If the hull of a ship is compromised, only the damaged section fills with water, which prevents the ship from sinking.

船が浸水しないように内部にbulkhead(隔壁)を設けているという例えから、サービスAとサービスBがリソースを共有していて、サービスAの負荷が高くなったらサービスBにも影響するということが発生しないよう、サービスAとサービスBには個別にリソースを割り当てましょうという話。

bulkheadという言葉の響きがいいので、無駄に使いたくなる。

Cache-Aside pattern

Load data on demand into a cache from a data store. This can improve performance and also helps to maintain consistency between data held in the cache and data in the underlying data store.

データストアからキャッシュにデータを読み込むことでパフォーマンスを改善し、データとキャッシュとのconsistency(一貫性)も維持しましょうという話。

単に「キャッシュ」でも良いような。

Choreography pattern

Have each component of the system participate in the decision-making process about the workflow of a business transaction, instead of relying on a central point of control.

choreographyとは「（ダンスなどの）振付師」のこと。クライアントからのリクエストをオーケストレータが受け、オーケストラが各サービスを呼び出す場合、オーケストレータが各サービスについて把握しなければいけない。それに対して、choreography patternではオーケストレータの位置にあるのはMessage Brokerだけで、各サービスの方からMessage Brokerにメッセージを取りに行く。

新たなサービスを追加するたびにオーケストレータに手を入れるのが面倒だということはよくあるのでユースケースはわからなくもない。でも振付師と言われてもという気がする。

Circuit Breaker pattern

Handle faults that might take a variable amount of time to recover from, when connecting to a remote service or resource. This can improve the stability and resiliency of an application.

Circuit Breakerは電気回路(circuit)に大きな電流が流れたときに回路を壊さないように電流を遮断する仕組みのこと。システムがビジーになったときに、各システムがリトライしようとして却って負荷が高くなるから、途中にCircuit Breakerを入れてリトライを制御しようという話。

これは比喩と実際のシステムの動きがマッチしてる。ちなみにMichael Nygardが「Release It！ 本番用ソフトウェア製品の設計とデプロイのために」で書いたらしい。（読んだはずだが覚えてない）

Claim-Check

Split a large message into a claim check and a payload. Send the claim check to the messaging platform and store the payload to an external service. This pattern allows large messages to be processed, while protecting the message bus and the client from being overwhelmed or slowed down. This pattern also helps to reduce costs, as storage is usually cheaper than resource units used by the messaging platform. This pattern is also known as Reference-Based Messaging, and was originally described in the book Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf.

claim checkは日本語でいうと「手荷物預かり証」のこと。ということでお察しの通り、手荷物預かり証（制御）と手荷物（処理）をシステム内で分けることで重たい処理をしても制御に影響しないようにしようという話。

これもユースケースとしてはあると思うが「手荷物預かり証」の例を出すまでもなく制御信号は分離しましょうで話が通じる気がする。

Command and Query Responsibility Segregation(CQRS)

CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level.

名前の通りコマンドとクエリを分離しましょうという話。

コマンドとクエリというより、データストアの中で参照用モデルと更新用モデルを分けましょう、もしくは参照用データストアと更新用データストアを分けましょうという話といった方が正確かも。これはChatworks Dev Dayなど国内でも議論されているのを見かけますね。

Compensating Transaction pattern

Undo the work performed by a series of steps, which together define an eventually consistent operation, if one or more of the steps fail. Operations that follow the eventual consistency model are commonly found in cloud-hosted applications that implement complex business processes and workflows.

別のサービスにより更新される可能性のあるデータは単純にロールバックすることができないから、あらかじめeventually consistent(結果整合性)のあるCompensation Transaction(補償トランザクション)を決めましょうという話。

例としてシアトルからロンドンへの航空券とロンドンからパリへの航空券を予約し、ロンドンとパリのホテルを予約するというトランザクションがある場合、パリのホテルが満席だからといってシアトルからロンドンへの航空券までキャンセルしないよねと書いている。なるほど、この例はわかりやすい。

Competing Consumers pattern

Enable multiple concurrent consumers to process messages received on the same messaging channel. This enables a system to process multiple messages concurrently to optimize throughput, to improve scalability and availability, and to balance the workload.

複数のコンシューマーが同じチャンネルでメッセージを処理できるようにするというパターン。

アプリケーションとコンシューマが別々にチャンネルでメッセージのやりとりをすると制御できないのでメッセージキューを入れましょう、そうすると負荷も平準化するし、メッセージが少なくとも１回は配信されることが保証されるし、障害があったときに復元もできるよねということらしい。competing（競合する）という名前との関連がイマイチ。

Compute Resource Consolidation pattern

Consolidate multiple tasks or operations into a single computational unit. This can increase compute resource utilization, and reduce the costs and management overhead associated with performing compute processing in cloud-hosted applications.

複数のタスクをひとつの計算ユニットにconsolidate(統合)しましょうという話。

これをパターンと呼ぶのは微妙かも。

というわけで41個中13個まで紹介しました。なぜかABC順に並んでいて、それを上から読み始めてしまったので、関連するものが後になって出てくることになりますが、同じような感じで残りも読んでいきます。