Asynchronous Messaging入門

株式会社 ランドコンピュータ

酒井 達明JAZUGアドバイザー

Microsoft MVP – Microsoft Azure

Microsoft Regional Director

クラウドデザインパターン

こちらを想像した人、、、、素直に挙手をお願いします。

本シリーズは右側の本の内容を解説するセミナーです。

AWSクラウドデザインパターン

http://aws.clouddesignpattern.org/images/a/ac/Cdp-overview-org.png

パターンの分類

• AWS

– 基本

– 可用性を向上

– 動的コンテンツを処理

– 静的コンテンツを処理

– データをアップロード

– リレーショナルデータベース

– 運用保守

– ネットワーク

• Azure

– 設計と実装

– 可用性

– データ管理

– パフォーマンスとスケーラビリティ

– メッセージング

– 回復性

– 管理と監視

– セキュリティ

5

Azureのクラウドデザインパターンは何が違う

• サービスの組合せパターンではなくアプリケーションのアーキテクチャに言及

• クラウド上でアプリケーションを最適に実行するためのノウハウが満載

• 実際の事例等で実証済みのパターンが網羅

• サンプルコードの紹介によりインプリメントを例示

• 24のパターンと10のガイダンスから構成

パターンとガイダンスについて

• まずは「ガイダンス」から読んでください！

• ガイダンスにはパターン成り立ちの基本的な考え方が網羅

• 書籍中では10項目のガイダンスが紹介

• Asynchronous Messaging

• Autoscaling

• Caching

• Compute Partitioning

• Data Consistency

• Data Partitioning

• Data Replication and Synchronization

• Instrumentation and Telemetry

• Multiple Datacenter Deployment

• Service Metering

各パターンの構成

• 課題と背景

– パターンが必要とされる課題と、その課題の持つ背景を解説

• 解決策

– パターンがどのように課題を解決するかを解説

• 問題と検討事項

– パターン適用時に必要となる検討事項や制約などを解説

• いつこのパターンを使うか

– パターン適用が有効なケースを解説

• 例

– パターン実現のための実装例の解説とサンプルコードの掲載

• 関連するパターンとガイダンス

• 追加情報

Asynchronous = 非同期

非同期のソリューション

• 非同期のパラダイムは以前から

– メインフレームにおける順序制御

– EDIなどアプリケーション間連携

– サービス指向(SOA)におけるサービス統合

ロングトランザクションの実現

フライトF2の

座席を予約

フライトF1の座席をキ

ャンセル

フライトF2の

座席を予約

フライトF3の

座席を予約

ホテルH1の

部屋を予約

ホテルH2の

部屋を予約

フライトF2

の座席を

キャンセル

フライトF3

の座席を

キャンセル

ホテルH1

の部屋を

キャンセル

ホテルH2

の部屋を

キャンセル

旅行プラン作成の操作手順

旅行プランをキャンセルする補正トランザクション

長時間トランザクションの各手順の

逆向き操作を記録

逆向きの操作に対する

ビジネスルールに適用

される補正ロジック

補正ロジック補正ロジック補正ロジック 補正ロジック 補正ロジック

クラウドにおける非同期

• 従来のパラダイムが、従来以上の規模で発生

• 適切なスケーリングによるスループット確保

• インターネットを介した環境下における耐障害性向上

• etc...

密結合モデルの問題点

• 同期型の密結合モデル

– 負荷集中によるオーバーヘッド増大

– 単一障害点(SFP)の存在による信頼性の低下

– スケールアウトのメリットが不十分

スケールメリットの問題

• クラウドサービスの持つスケールメリットを活かせない

– 無意味なインスタンス分割とオーバーヘッドの作りこみ

– 特定インスタンスへの負荷集中によるスループットと信頼性の低下

非同期化による負荷平準化

Webロール

メッセージキューを使ったメッセージの送受信

• 送受信操作をサポートするバッファ

• 合意されたフォーマットでメッセージを作成

複数送受信者間でのメッセージキューの共有

• 単一のキューを複数の送受信者で共有

• スケールアウトされた送信者＆受信者間でメッセージ処理が可能

Microsoft Azureのメッセージキュー

• Queueストレージ

• ６４KB以下のテキストメッセージを送受信• 格納されたメッセージの生存期間は7日間• キューの最大サイズは200TB• 作成可能なキューの数に制限なし• トランザクションサポートなし

Queueストレージのエラーハンドリング

Complete!一定時間非表示

一定時間経過後、再度参照可能に

Microsoft Azureのメッセージキュー

• Service Bus Queue

• 256KB以下のメッセージを送受信• 格納されたメッセージは永続化される• キューの最大サイズは5GB• パーティション分割時におけるキューの最大サイズは80GB(5×16)• 作成可能なキュー数は最大10,000/名前空間

(パーティション分割キューは最大100)• ローカルトランザクションをサポート

QueueストレージとService Bus Queueの比較(一例)

比較条件 Microsoft Azure キュー Service Bus キュー

順序の保証 × ○ 先入れ先出し (FIFO)

配信保証 At-Least-Once At-Least-Once At-Most-Once

トランザクションのサポート

× ○ (ローカル トランザクションを使用)

受信動作 非ブロッキングブロッキング (タイムアウトあり/なし)非ブロッキング (.NET マネージ API のみを使用)

受信モード Peek & Lease Peek & Lock Receive & Delete

排他アクセス モード リース ベース ロック ベース

リース/ロックの期間30 秒 (既定)7 日 (最大)

60 秒 (既定)

リース/ロックの粒度 メッセージ レベル キュー レベル

一括受信○ メッセージ数 (最大 32) を明示的に指定)

○ (プレフェッチ プロパティを有効 orトランザクションを使用)

一括送信 × ○ (トランザクションまたはクライアント側のバッチ処理を使用)

http://msdn.microsoft.com/ja-jp/library/hh767287.aspx

Microsoft Azureのメッセージキュー

• Service Bus Topic / Subscription

Subscription B

受信者

Topic送信者

Subscription C

Subscription D

Subscription A

基本的なキューのパターン

• 一方向メッセージング

送信者 受信者

基本的なキューのパターン

• リクエスト/レスポンスメッセージング

送信者A

送信者B

送信者A専用のレスポンスキュー

送信者B専用のレスポンスキュー

共有メッセージキュー

受信者

基本的なキューのパターン

• ブロードキャストメッセージング

受信者B用の

Subscription

受信者A用の

Subscription受信者A

受信者B

Topic送信者

非同期メッセージングのシナリオ

• ワークロードの分散

時間の掛かる処理をバックエンドで実行

時間の掛かる処理を分離し応答性を向上

非同期メッセージングのシナリオ

• 時間的な分離

7:00～23:30受付毎日24時間申込可能

非同期メッセージングのシナリオ

• 負荷分散

複数で分散処理

非同期メッセージングのシナリオ

• 負荷平準化

※「Queue-based Load Leveling」パターンを参照

非同期メッセージングのシナリオ

• クロスプラットフォームの統合

オンプレミス

Microsoft Azure

非同期メッセージングのシナリオ

• 遅延処理

ex.60分に1度起動してリクエスト処理

非同期メッセージングのシナリオ

• 高信頼性メッセージング

障害が発生しても処理の継続が可能

非同期メッセージングのシナリオ

• 回復性のあるメッセージ処理

他の受信者による読み込みをブロック

※キューにメッセージのロック機能があること• Azure Service Bus キューにはPeek/Lockモードが存在• AzureキューストレージはメッセージのPeekが可能

非同期メッセージングのシナリオ

• ブロックされない受信者

ロック中において他の受信者による

Peek(覗き見)を許可

Scheduler Agent supervisorパターン

実装に関する検討事項

• メッセージの順序性

– メッセージの順序性は必ずしも保証されない

– AzureではService Bus Queueのみ順序性を保証

– Priority Queueパターンでは、特定のメッセージが優先配信されることを保証するメカニズムを提供

Priority Queueパターン

コンシュマー

アプリケーション

３

2

2

1 11

３３

優先度1のメッセージに対応するメッセージキュー

優先度2のメッセージに対応するメッセージキュー

優先度3のメッセージに対応するメッセージキュー

実装に関する検討事項

• メッセージのグループ化– 理想的にはすべてのメッセージは独立すべき

– 要件上の制約で複数のメッセージをグループ化する場合• 大容量のメッセージを分割する必要がある場合

• 複数の独立したメッセージをセットで利用する必要がある場合

– Service Bus QueueではSession IDが利用可能• プロパティを指定

• 関連するメッセージをセッションに配置

• 同一Session IDを持つメッセージはロックされ他ユーザからの参照をブロック

実装に関する検討事項

• 冪(べき)等性

– 同じメッセージが複数回配信される可能性がある• 処理の大半が完了しているタイミングでの障害発生等

• 同じ処理を繰り返しても同じ結果が得られるように

– 冪等性を実現するためのアイディア例• メッセージにユニークなIDを付与

• メッセージ処理開始時点で状態ストアへ処理状態を問い合わせ

• 存在しない場合に当該メッセージIDを「処理中」として記録

• 既に処理中である場合、処理中止 or 補正トランザクション実行

• 処理完了時に状態ストアをクリア

実装に関する検討事項

• 反復メッセージ

– 同じメッセージが複数回送信される事象の回避• 送信者がメッセージ送信後の処理で失敗した場合など

– Azure Service Busキューの重複除去機能• メッセージに固有のIDを付与

• ポストされたメッセージIDのリストを記録

• リストを走査し、重複メッセージのポストを排除

実装に関する検討事項

• ポイズンメッセージ

– 受信者の処理が失敗するようなメッセージ• 不正なフォーマット

• 想定外の情報を含む

– Azure Service Busキューでのポイズンメッセージ検出• メッセージ受信回数をカウント

• 受信回数が閾値を超えた場合にメッセージをキューから削除

実装に関する検討事項

• メッセージの有効期限

– 長期間残存するメッセージの扱い• 処理に無関係な場合も

• 適宜削除すべき

– Azure ストレージキューは最大7日間の期限

– Azure Service Busキューは無期限• メッセージ属性に有効期限を設定

• 有効期限切れのメッセージは配信不能キューへ移動

実装に関する検討事項

• メッセージのスケジューリング

– メッセージが指定日時まで処理されないよう制限

– AzureストレージおよびAzure Service Busキューにはメッセージ有効化の日時指定が可能• 送信時に有効にする日時を指定

• 指定時間になるまで非表示

• アクセス可能な日時以降は直ちに取得可能

• 但し、Azureストレージは最大7日以内

関連するパターンとガイダンス

• Autoscalingパターン

• Circuit Breakerパターン

• Competing Consumersパターン

• Priority Queueパターン

• Queue-Based Load Levelingパターン

• Retryパターン

• Scheduler Agent supervisorパターン