CDP:Job Observerパターン

From AWS-CloudDesignPattern
Jump to: navigation, search

ジョブの監視とサーバの追加・削除

Contents

解決したい課題

バッチ処理の負荷分散として、ジョブリクエストをキューで管理し、キューのジョブリクエストを複数のバッチサーバが並列に処理する方法がある。 しかし、用意するバッチサーバ数はピークに合わせた数となるため、ピーク外の時間帯ではバッチサーバのリソースが余ってしまい、非常にコスト効率が悪くなってしまう。 また、予想以上の負荷がバッチシステムにかかった場合、当然、同数のバッチサーバで処理するためレスポンスが悪くなってしまう。

クラウドでの解決/パターンの説明

従来はサーバリソースを動的に増減することができなかったので、ピークや許容コストの範囲内でバッチサーバを用意し、コスト効率が悪かったり、想定外の負荷への対応ができないという課題があった。 クラウドでは、負荷をモニタリングし仮想サーバを自動的に増減させる仕組みをもっている。この仕組を利用することで負荷に応じてバッチサーバを増減することができるようになり、コスト効率と想定外の負荷に対応することも可能となる。 具体的には、ジョブリクエスト(キューのメッセージ)に対して、その量をモニタリングし、必要に応じてバッチサーバの追加と削除を自動で行う形となる。

実装

AWSにはAuto Scalingと呼ばれるEC2を自動的に増減できる仕組みがあり、CloudWatchとよばれるリソースモニタリングツールと連動し、モニタリングする項目の値に応じてEC2の増減を行える。 このCloudWatchでモニタリングできる項目に、AWSが提供するキューシステムであるSQSのキュー内のメッセージ数がある。 ジョブリクエストをSQSで管理しAuto ScalingとCloudWatchを利用することで、キュー内のメッセージ数(ジョブリクエスト)に応じてバッチサーバを自動で増減できるシステムが構築可能となる。

  • ジョブリクエストをSQSのメッセージとしてエンキューする。
  • バッチサーバをSQSからメッセージをデキューして処理する。
  • Auto Scalingでバッチサーバが自動で増減するように設定し、増減のトリガーはSQSのキュー内のメッセージ数(CloudWatch)とする。

構造

6wNg0ISJczU5Pz1m-F051C.png

利点

  • EC2の数はジョブの処理に最適化されるため、コスト効率が非常に高くなる。
  • 並列で処理が進むためジョブ全体を短時間で実行することが可能。
  • EC2に障害が起きてもSQSにメッセージ(ジョブリクエスト)が残っているため、EC2が回復次第、すぐに処理を続けることができ、障害に強いシステムとなる。

注意点

  • ジョブの失敗時にキュー上のメッセージが残り続けたり、二重処理や中途半端な状態を防ぐ必要がある。
  • このような状態を防ぐ方法として以下の対応が考えられる。
    • ジョブ処理プログラムのメッセージの待ち受けタイミング(処理)を調整
    • メッセージのVisibility Timeout(受信したメッセージが再び可視化するまでの時間)の調整

その他

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox