Q&A
ご回答ありがとうございます。
なるほど、そんな方法があるんですね！
ちょっと試してみます！
AWSでELBを使用し、配下にEC2インスタンスを2つ起動したいと思っています。
ELBを使用する場合は、ラウンドロビンで使用するのが一般的かと思いますが、
利用しているアプリケーションが複数マシンからのDB同時アクセスに対応していません。
EC2インスタンスがダウンすれば、新しくEC2インスタンスを作成すれば良いのですが、
ダウンタイムを少なくするため、ホットスタンバイで待機させたいと考えています。
ELB配下のインスタンスは2つ起動している状態で、常に1つのEC2インスタンスのみ
使用し、ヘルスチェックに失敗した場合もう一方のEC2インスタンスを参照するような動作は可能なのでしょうか？？
可能であれば、方法をご教示頂けるとたすかります。。
よろしくお願いします。
回答2件
0
ELBにこだわらない（使ってもいいですが）方法だと、Route53を使ったフェイルオーバーなんかもアリかもしれません。
他にも、例えばELB（CLBではないタイプの前提）のターゲットグループを予め複数用意しておいて、Systems ManagerのRun CommandやLambda等を使って死活監視を行い、落ちていたらターゲットグループを切り替える、みたいなことをやっても行けそうです。
インスタンス上のサービスではなくインスタンス自体が落ちたかどうかを確認できればよいのであれば、EC2インスタンスのStatusCheckFailedをトリガーにしてもいいでしょう。
まだ試したことがないのですが、最近のアップデートでALBの転送先に複数のターゲットグループと設定し、それぞれに対して加重を設定できるようになりました。
どうやら加重は０に設定することもできるらしいので、上記を行う際にはターゲットグループの切り替えではなく加重設定の変更（コールドにしたいインスタンスを含むターゲットグループの加重を０、ホットにしたいほうを１以上）を行う、でもいいかもしれません。
試してみてダウンタイムがゼロに近くなる方法を取れればよいかなと。
もっとも
利用しているアプリケーションが複数マシンからのDB同時アクセスに対応していません。
が負債としてあるからこういう構成を検討する必要があるわけで、すでに言及されているように長期的にはこちらを解消することをおすすめします。
投稿2019/12/09 03:03
総合スコア7588
0
ベストアンサー
２つのEC2インスタンスを相互監視させて、ヘルスチェック用のファイルをアクティブ側のみに配置するように構成を作るというのが割とよさそうです。
相互監視はHeartbeatやcron等を利用
参照：
https://cloudpack.media/494
https://dev.classmethod.jp/cloud/aws/multi-az-changed-active-standby/
ただ、この方式ですと性能不足に陥った場合は、EC2のインスタンスタイプを上げるしかないため
とりあえずこの構成でしのいで、「利用しているアプリケーションが複数マシンからのDB同時アクセスできない」という状態を将来的に解決するのがよいと思います。
投稿2019/12/07 04:31
総合スコア55
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/12/09 22:38