CDP:Priority Queueパターン
優先順位の変更
目次 |
解決したい課題
多くのバッチジョブを処理する必要があり、しかもジョブに優先順位がケースが考えられる。
例えばプレゼンテーションファイルをWebブラウザーからアップロードして公開できるサービスで、無料ユーザーと会員ユーザーでサービスレベル（公開までの時間）が異なる場合などが、そのケースに該当する。ユーザーがプレゼンテーションファイルをアップロードすると、システム側で公開するための変換処理などをバッチ処理で行い、変換後のファイルを公開する。そのバッチ処理を会員種別毎に、どのように優先順位付けするかが課題となる。
クラウドでの解決/パターンの説明
バッチジョブの管理にはキューが使える。キューを優先順位の数だけ用意すればよい。ジョブリクエストをキューで管理し、キューのジョブリクエストをバッチサーバーが処理する。 クラウドには信頼性の高いキューがサービスとして提供されており、それを用いることで容易に信頼性の高いバッチシステムを構築できる。キューを優先順位に応じて複数用意し、ジョブリクエストを優先順位によってキューに入れ分けることで、バッチ処理の優先順位を付けることができる。キューに対応するバッチサーバーの性能（数）は、優先順位に応じたものにしておく必要がある。
実装
AWSのキューサービスは「SQS」である。SQSのキューを複数用意することで優先順位別のキュー（プライオリティキュー、セカンダリキュー）を用意することが可能となる。またメッセージの遅延送信機能を利用することで処理実行をあえて遅延させることもできる。
- SQSを用いて優先順位ごとに複数のキューを用意する。
- 処理を急ぐもの（ジョブリクエスト）は、優先順位の高いキューに入れる。
- 優先順位に応じてキューのジョブリクエストを処理するバッチサーバーの台数を用意する。
- キューには「メッセージの遅延送信」機能がある。それを利用することで、処理開始時間を遅延させることも可能である。
構造
利点
- ジョブを処理するサーバーを増減することで、プライオリティーキュー、セカンダリーキューの処理速度を動的に変更できる。
- パフォーマンスやサービスの要件に対して、ジョブ処理に利用するEC2の増減のみで対応可能。
- EC2に障害が起きてもキューサービスにメッセージ（ジョブ）が残っているため、EC2が回復次第、すぐに処理を続けることができ、障害に強いシステムとなる。
注意点
処理するEC2インスタンスの数とキューイングされたメッセージ数のバランスにより、セカンダリキューの方が処理が早く終わるケースがあるので、プライマリキューとセカンダリキューの処理速度を監視しておく方が望ましい。
その他
- Queuing Chainパターンを参照。
- Job Observerパターンを参照。
