Asynchronous Messaging入門
- 1. Asynchronous Messaging入門 株式会社 ランドコンピュータ 酒井 達明 JAZUGアドバイザー Microsoft MVP – Microsoft Azure Microsoft Regional Director
- 4. パターンの分類 • AWS – 基本 – 可用性を向上 – 動的コンテンツを処理 – 静的コンテンツを処理 – データをアップロード – リレーショナル データベース – 運用保守 – ネットワーク • Azure – 設計と実装 – 可用性 – データ管理 – パフォーマンスと スケーラビリティ – メッセージング – 回復性 – 管理と監視 – セキュリティ 5
- 5. Azureのクラウドデザインパターンは何が違う • サービスの組合せパターンではなくアプリケーションのアーキテクチャに 言及 • クラウド上でアプリケーションを最適に実行するためのノウハウが満載 • 実際の事例等で実証済みのパターンが網羅 • サンプルコードの紹介によりインプリメントを例示 • 24のパターンと10のガイダンスから構成
- 6. パターンとガイダンスについて • まずは「ガイダンス」から読んでください！ • ガイダンスにはパターン成り立ちの基本的な考え方が網羅 • 書籍中では10項目のガイダンスが紹介 • Asynchronous Messaging • Autoscaling • Caching • Compute Partitioning • Data Consistency • Data Partitioning • Data Replication and Synchronization • Instrumentation and Telemetry • Multiple Datacenter Deployment • Service Metering
- 7. 各パターンの構成 • 課題と背景 – パターンが必要とされる課題と、その課題の持つ背景を解説 • 解決策 – パターンがどのように課題を解決するかを解説 • 問題と検討事項 – パターン適用時に必要となる検討事項や制約などを解説 • いつこのパターンを使うか – パターン適用が有効なケースを解説 • 例 – パターン実現のための実装例の解説とサンプルコードの掲載 • 関連するパターンとガイダンス • 追加情報
- 9. 非同期のソリューション • 非同期のパラダイムは以前から – メインフレームにおける順序制御 – EDIなどアプリケーション間連携 – サービス指向(SOA)におけるサービス統合
- 11. クラウドにおける非同期 • 従来のパラダイムが、従来以上の規模で発生 • 適切なスケーリングによるスループット確保 • インターネットを介した環境下における耐障害性向上 • etc...
- 12. 密結合モデルの問題点 • 同期型の密結合モデル – 負荷集中による オーバーヘッド増大 – 単一障害点(SFP)の存在に よる信頼性の低下 – スケールアウトのメリット が不十分
- 13. スケールメリットの問題 • クラウドサービスの持つ スケールメリットを活か せない – 無意味なインスタンス 分割とオーバーヘッド の作りこみ – 特定インスタンスへの 負荷集中によるスルー プットと信頼性の低下
- 17. Microsoft Azureのメッセージキュー • Queueストレージ • ６４KB以下のテキストメッセージを送受信 • 格納されたメッセージの生存期間は7日間 • キューの最大サイズは200TB • 作成可能なキューの数に制限なし • トランザクションサポートなし
- 19. Microsoft Azureのメッセージキュー • Service Bus Queue • 256KB以下のメッセージを送受信 • 格納されたメッセージは永続化される • キューの最大サイズは5GB • パーティション分割時におけるキューの最大サイズは80GB(5×16) • 作成可能なキュー数は最大10,000/名前空間 (パーティション分割キューは最大100) • ローカルトランザクションをサポート
- 20. 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
- 21. Microsoft Azureのメッセージキュー • Service Bus Topic / Subscription Subscription B 受信者 Topic送信者 Subscription C Subscription D Subscription A
- 28. 非同期メッセージングのシナリオ • 負荷平準化 ※「Queue-based Load Leveling」パターンを参照
- 32. 非同期メッセージングのシナリオ • 回復性のあるメッセージ処理 他の受信者による読 み込みをブロック ※キューにメッセージのロック機能があること • Azure Service Bus キューにはPeek/Lockモードが存在 • AzureキューストレージはメッセージのPeekが可能
- 35. 実装に関する検討事項 • メッセージの順序性 – メッセージの順序性は必ずしも保証されない – AzureではService Bus Queueのみ順序性を保証 – Priority Queueパターンでは、特定のメッセージが優先 配信されることを保証するメカニズムを提供
- 37. 実装に関する検討事項 • メッセージのグループ化 – 理想的にはすべてのメッセージは独立すべき – 要件上の制約で複数のメッセージをグループ化する場合 • 大容量のメッセージを分割する必要がある場合 • 複数の独立したメッセージをセットで利用する必要がある場合 – Service Bus QueueではSession IDが利用可能 • プロパティを指定 • 関連するメッセージをセッションに配置 • 同一Session IDを持つメッセージはロックされ他ユーザからの 参照をブロック
- 38. 実装に関する検討事項 • 冪(べき)等性 – 同じメッセージが複数回配信される可能性がある • 処理の大半が完了しているタイミングでの障害発生等 • 同じ処理を繰り返しても同じ結果が得られるように – 冪等性を実現するためのアイディア例 • メッセージにユニークなIDを付与 • メッセージ処理開始時点で状態ストアへ処理状態を問い合わせ • 存在しない場合に当該メッセージIDを「処理中」として記録 • 既に処理中である場合、処理中止 or 補正トランザクション実行 • 処理完了時に状態ストアをクリア
- 39. 実装に関する検討事項 • 反復メッセージ – 同じメッセージが複数回送信される事象の回避 • 送信者がメッセージ送信後の処理で失敗した場合など – Azure Service Busキューの重複除去機能 • メッセージに固有のIDを付与 • ポストされたメッセージIDのリストを記録 • リストを走査し、重複メッセージのポストを排除
- 40. 実装に関する検討事項 • ポイズンメッセージ – 受信者の処理が失敗するようなメッセージ • 不正なフォーマット • 想定外の情報を含む – Azure Service Busキューでのポイズンメッセージ検出 • メッセージ受信回数をカウント • 受信回数が閾値を超えた場合にメッセージをキューから削除
- 41. 実装に関する検討事項 • メッセージの有効期限 – 長期間残存するメッセージの扱い • 処理に無関係な場合も • 適宜削除すべき – Azure ストレージキューは最大7日間の期限 – Azure Service Busキューは無期限 • メッセージ属性に有効期限を設定 • 有効期限切れのメッセージは配信不能キューへ移動
- 42. 実装に関する検討事項 • メッセージのスケジューリング – メッセージが指定日時まで処理されないよう制限 – AzureストレージおよびAzure Service Busキューには メッセージ有効化の日時指定が可能 • 送信時に有効にする日時を指定 • 指定時間になるまで非表示 • アクセス可能な日時以降は直ちに取得可能 • 但し、Azureストレージは最大7日以内
- 43. 関連するパターンとガイダンス • Autoscalingパターン • Circuit Breakerパターン • Competing Consumersパターン • Priority Queueパターン • Queue-Based Load Levelingパターン • Retryパターン • Scheduler Agent supervisorパターン