やりたいこと
不定期でSQSにキューが登録され、コンシューマーのEC2にはバッチ処理がSQSのキューを常にポーリングしており、バッチ処理はデキューに成功したら業務処理を行います。
普段、起動しているコンシューマーのEC2は1台だけなので、プロデューサーが一度に大量のエンキューを行なった場合は、キューの数に比例した時間がかかります。しかし、大量のキューであったも、コンシューマーは全てのキューの処理を終えなくてはなりません。
Auto Scaling グループを作成してコンシューマーのEC2の台数を適宜調整すればいいのですが、手動でAuto Scaling グループの「希望」台数を調整するのは事故の元なので大量のキューが登録されたら、自動でスケールアウトして、未処理のキューがなくなったらスケール・インさせます。
HOW TO
素直に公式ドキュメントに沿って設定します。
Amazon SQS に基づくスケーリング
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-using-sqs-queue.html
キューの数に応じて、コンシューマーの台数を変更したい(ダメだった)
例えば、10,000以上のキューなら4台、20,000以上のキューなら8台、30,000以上なら12台といった要領で、オートスケールの台数を変えたいとおもいました。
スケーリング調整タイプがExactCapacity の場合
ExactCapacityは スケールアウト後の台数を指定する方法です。
指定したインスタンス数にグループの現在の容量を変更します。この調整タイプには正の値を指定します。
例: グループの現在の容量が 3 インスタンスであり、調整値が 5 の場合、このポリシーが実行されると、容量は 5 インスタンスに設定されます。
プロデューサーが一度に大量のキューを登録した後に、CloudWatchのアラームが検知してスケールアウトしてEC2の台数が希望した通りになりました。
しかし、コンシューマーが処理を行い続け、キューの数が減り、一つ下のステップの範囲に達するとコンシューマーの数も減ってしまいました。例えば、 スケールアウトの開始時点ではキューの数が17,000件であれば、コンシューマーが8台になります。その後、キューの数が 10,000未満まで減ると下の4台に減りました。最後の0件になるまで8台で処理を行って欲しかったのです。
スケーリングポリシーは下の表の通りです。
| 追加/削除/設定 | 台数 | 閾値下限 | メトリクス名 | 閾値上限 |
|---|---|---|---|---|
| 設定 | 1 | 1 | <= ApproximateNumberOfMessagesVisible < | 9999 |
| 設定 | 4 | 1000 | <= ApproximateNumberOfMessagesVisible < | 19999 |
| 設定 | 8 | 2000 | <= ApproximateNumberOfMessagesVisible < | 29999 |
| 設定 | 12 | 3000 | <= ApproximateNumberOfMessagesVisible < | 無限大 |
スケーリング調整タイプがChangeInCapacity の場合
ChangeInCapacityは スケールアウト時に増やす台数を指定します。
指定したインスタンス数だけグループの現在の容量を増減させます。正の調整値は現在の容量を増やし、負の調整値は現在の容量を減らします。
例: グループの現在の容量が 3 インスタンスであり、調整値が 5 の場合、このポリシーが実行されると、グループに 5 インスタンスを追加して、合計で 8 インスタンスになります。
ExactCapacityのスケーリングポリシーを「設定」から「追加」に変更して試しました。プロデューサーが1,900のキューを登録した場合は4台増え、常に起動させている1台と合わせて5台になりました。その後クールダウンタイムが終わった時点で、キューの数が1,000 を超えていると、4台が追加で起動して合計9台になりました。その後も、同様に増え続けて Auto Scaling グループ の 最大キャパシティに達した所で、増えるのが止まりました。
結局
プロデューサーが1回の処理で投入したキューの数に応じてコンシューマーの台数を固定することを諦め、常に最大キャパシティまでスケールアウトすることにしました。
断念した時に公式ドキュメントが簡易スケーリングポリシーを扱っている理由を理解しました。
実現するのであれば、プロデューサーがAuto Scaling グループの最大を調整する仕組みが必要そうです。