AWS ALB で、固定インスタンスに一定のアクセスをさせるターゲットグループ設定は可能か

Question

前提

AWS EC2 1台で動いている Rails サービスに、ALB （と WAF）を導入しようとしています。別の要件があって、固定IPをもったインスタンス（でさらに、Rails を動かしている）が必要です。
現状上記1台のみで稼働しています。

費用削減のため、現存のインスタンスサイズを少し小さくし、Auto Scaling グループを加えて、費用削減をしたい、と目論んでいます。
アクセス数は時刻依存の傾向をもちます。

• 月次ではあるが、バッチ処理がある（残念なことに Crontab に書いてある）
• システムフローにメール送信があるが、SQS は使っていないため、現状使っているIPはできるだけ確保しておきたい

ので、稼働中のインスタンスは可能であればそのまま用いたいと考えています。

バッチ処理を抜いたAMIを作成して Auto Scaling グループを作成することを考えていました（他の方法があれば変更します）。

（自分が構築していないシステムを運用・保守してほしいと頼まれて、あまりにひどいのでどこから手を付けようか悩んでいるところです。）

実現したいこと

AWS ALB で、固定インスタンスに一定のアクセスをさせるターゲットグループ設定は可能かという話になると考えています。

• 固定インスタンスを利用して、一定のアクセスを処理したい（アクセス数ベースでも、CPU 利用率ベースでも良い）
• 固定インスタンスでは処理しきれない量のアクセスが来た場合は、Auto Scaling グループ側のインスタンスが補う形で処理をする

あるいは、同様のことが実現できる代替案はあるでしょうか。

毎日、（アクセスが増える時間帯の前後に）インフラの定時変更処理を入れ構成変更をする…といった仕組みにはできるだけしたくありませんが簡単な方法があれば、伺っておきたいです。

月次で固定インスタンスを起動・停止するのはありかもしれません。

Comments

[yu_1985]

>AWS EC2 1台で動いている Rails サービスに、ALB （と WAF）を導入しようとしています。別の要件があって、固定IPをもったインスタンス（でさらに、Rails を動かしている）が必要です。

あまりイメージがつかなかったのですが、これらは同じインスタンスですか？それとも別のインスタンスですか？
このあたり補足をお願いします。図があるとわかりやすいですが、図を作るのは大変なので言葉で補足でも問題ないです。
また、何のために固定IPが必要なのでしょうか。
もう少し具体的には、どこかからそのインスタンスに直接アクセスさせるために固定IPが必要なのか、それともそのインスタンスからどこかにリクエストを送る際にIPで許可しているなどの理由なのか。
そのへんまで含めて考えるともう少し色んなアプローチが見えるかもしれません。

[takotakot]

ありがとうございます。
「同じインスタンス」です。

固定「IP」であることはあまり重要ではないかと思っていたのですが、そうでもないかもしれないので、もう少し追記します。

[yu_1985]

バッチ処理をしているEC2インスタンスにはリクエストを振らないようにしてAutoScalingグループだけで捌くようにするほうがシンプルじゃないでしょうか。
バッチをWebサーバー上でバッチを動かすのは避けたほうが賢明です。
メール送信はもしサーバー上のpostfixなどで行っているのであればなるべくそれを避けてAWS SESやSendGridなどのメール送信サービスを利用することを強く推奨します。

[takotakot]

はい、シンプルなのは確かですが、計算リソースがもったいないのです。
私も SQS, SES を使いたいんですが…
> 自分が構築していないシステムを運用・保守してほしいと頼まれて、あまりにひどいのでどこから手を付けようか悩んでいるところです。
のです

[yu_1985]

自分の稼働時間とシステムに残る負債に対処する時間のほうがもったいないと思いますよ。
メール送信の方法を変えることはSMTPを利用することにすれば大した手間ではありませんし、SQSは最悪なくてもいいと思います。大量にメール送信するならメール送信の方法を問わずどのみちどこかで対処しなければいけないですけどね。

[yu_1985]

どうしても1台確保しておきたいなら1台をバッチ専用に隔離しておくのが最もシンプルですし、わざわざ複雑な構成にして何か発生したときに対処する工数分のコストのほうが大きいと思います。

[takotakot]

それは仰る通りです。

こちらも分かっている上で、仕組みとして、ヘテロな負荷分散ができるかどうかを尋ねています。

Answer 1

一応、目的に近い状態はAutoScalingのTemination Policyの設定によって実現できそうではあります。
Auto ScalingのTermination Policyを使いこなそう
おそらくはインスタンスの最低容量を1にして、Termination PolicyをNewestInstanceにすれば、最初に起動したインスタンスは維持されるでしょう。もちろんちゃんと検証はしたほうが良いです。

より確実にするためには、Lambdaを使ってカスタムポリシーを作ることもできます。
EC2 AutoScalingのScale-in時にどのインスタンスを終了するかAWS Lambdaで制御できるようになりました

いずれも要検証です。

毎日、（アクセスが増える時間帯の前後に）インフラの定時変更処理を入れ構成変更をする…といった仕組みにはできるだけしたくありませんが簡単な方法があれば、伺っておきたいです。

これはAutoScalingグループの設定で容易に行なえます。
【新機能】スケジュールベースのAuto ScalingをAWS Management Consoleから操作できるようになりました
また、時間に明らかな傾向があるなら予測スケーリングがうまく機能しそうです。
Amazon EC2 Auto Scaling の予測スケーリング

月次で固定インスタンスを起動・停止するのはありかもしれません。

それで良いならそれが最もシンプルだと思います。
そしてそれが許されるのなら、スポットインスタンスを使用すると費用を大きく削減できることが期待できます。

Comments

[takotakot]

ありがとうございます。
固定インスタンスがグループ内に入るということは、その固定インスタンスと、他の（自動起動される）インスタンスは同じタイプ（サイズ）にする必要がありますか？

[yu_1985]

見た限り、それを設定で分けるのは難しそうです。

AutoScalingグループをターゲットグループに設定した上で、AutoScaling外のインスタンスとして固定インスタンスをターゲットグループに追加するということも可能かもしれませんが、それができたとして何をもとにスケールイン・アウトすればよいかの妥当な設定が非常に難しいです。
それをするくらいならインスタンスの台数でコントロールするよりスポットインスタンスを使った料金削減を考えたほうが効果的でしょう。

[takotakot]

ありがとうございます。先程
Amazon EC2 Auto Scaling のインスタンスの重み付けを設定する
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups-instance-weighting.html
というのを見つけました。「複数のインスタンスタイプを起動」というのもできるようですね（昔はなかったはず）。

いずれにせよ、特定の何か（リクエスト量とか）を固定する…のは難しそうだが、グループ内に入れて工夫するという方法がありそうなのが分かりました。