CDP:Job Observerパターン

提供:AWS-CloudDesignPattern
移動: 案内, 検索
寄贈したアーキテクト

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

目次

解決したい課題

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

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

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

実装

 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インスタンスが回復次第、すぐに処理を続けることができ、障害に強いシステムとなる。

注意点

  • EC2インスタンスは時間単位で課金され、短時間であっても一度起動して終了すると、1時間分の課金がかかる。起動、終了のタイミングには注意が必要である。

その他

  • EC2利用費用を入札して、市場価格が入札価格以下の場合に利用出来る「スポットインスタンス」を利用すると、より安価にジョブを処理することができる。
  • スポットインスタンスは、市場価格が入札価格以上になるとインスタンスがターミネートされる。ターミネートする前には通知を受けることができるため、必要なデータやログはこの通知を受けた後に、S3などに退避をしておく。
  • Queuing ChainパターンPriority Queueパターンと組み合わせることが可能である。

寄贈したアーキテクト

Ninja of Three

個人用ツール
名前空間
変種
操作
CDPメニュー
ツールボックス