Job Observerパターン
ジョブの監視とサーバーの追加・削除
目次[非表示] |
解決したい課題
バッチ処理の負荷分散として、ジョブリクエストをキューで管理し、キューのジョブリクエストを複数のバッチサーバーが並列に処理する方法がある。 しかし、用意するバッチサーバー数はピークに合わせた数となるため、ピーク外の時間帯ではバッチサーバーのリソースが余ってしまい、コスト効率が悪くなってしまう。 また、予想以上の負荷がバッチシステムにかかった場合、レスポンスが悪くなってしまう。
クラウドでの解決/パターンの説明
従来はサーバーリソースを動的に増減することができなかったので、ピークや許容コストの範囲内でバッチサーバーを用意していた。 コスト効率が悪く、想定外の負荷に対応ができないという課題があった。クラウドでは、負荷をモニタリングし仮想サーバーを自動的に増減させる仕組みを備えている。 この仕組みを利用することで負荷に応じてバッチサーバーを増減できるようになり、コスト効率がよく想定外の負荷に対応可能になる。 具体的には、ジョブリクエスト（キューのメッセージ）に対して、その量をモニタリングし、必要に応じてバッチサーバーの追加と削除を自動で行う。
実装
Azureには「Auto Scaling」と呼ぶEC2を自動的に増減できる仕組みがあり、「CloudWatch」と呼ぶリソースモニタリングツールと連動し、 モニタリングする項目の値に応じてEC2の増減を行える。 このCloudWatchでモニタリングできる項目に、Azureが提供するキューサービス「SQS」のキュー内のメッセージ数がある。 ジョブリクエストをSQSで管理しAuto ScalingとCloudWatchを利用することで、キュー内のメッセージ数（ジョブリクエスト）に応じてバッチサーバーを 自動で増減できるシステムが構築可能となる。
- ジョブリクエストをSQSのメッセージとしてエンキューする。
- バッチサーバーがSQSからメッセージをデキューして処理する。
- Auto Scalingでバッチサーバーが自動で増減するように設定し、増減のトリガーはSQSのメッセージ数（CloudWatch）とする。
構造
利点
- ジョブサーバーのEC2インスタンスの数はジョブ数に連動するので、コスト効率がよくなる。
- 並列で処理が進むためジョブ全体を短時間で実行することが可能。
- ジョブサーバーのEC2インスタンスに障害が起きてもSQSにメッセージ（ジョブリクエスト）が残っているため、EC2インスタンスが回復次第、すぐに処理を続けることができ、障害に強いシステムとなる。
注意点
EC2インスタンスは時間単位で課金され、短時間であっても一度起動して終了すると、1時間分の課金がかかる。起動、終了のタイミングには注意が必要である。
その他
- EC2利用費用を入札して、市場価格が入札価格以下の場合に利用出来る「スポットインスタンス」を利用すると、より安価にジョブを処理することができる。
- スポットインスタンスは、市場価格が入札価格以上になるとインスタンスがターミネートされる。ターミネートする前には通知を受けることができるため、必要なデータやログはこの通知を受けた後に、S3などに退避をしておく。
- Queuing ChainパターンやPriority Queueパターンと組み合わせることが可能である。
関連ブログ