[B! autoscaling] jinjin252525のブックマーク

(小ネタ) AutoScaling で増減した EC2 インスタンスに動的に CloudWatch Alarm を設定 - エムスリーテックブログ

こんにちは、エムスリーエンジニアの園田です。 AWS の AutoScaling で増減する EC2 インスタンスに対して CloudWatch Alarm を動的に設定したくなることありますよね？ AutoScalingGroup のメトリクスで AutoScalingGroup 内の平均 CPU 利用率などを監視することはできますが、個々のインスタンスそれぞれに対してアラームを設定することは（今のところ）できません。正確には、設定したとしても AutoScaling で新しく起動したインスタンスには設定されませんし、スケールインで削除されたからといって自動でアラームの設定が削除されることもありません。そこで、 CloudWatch Event Rule と Lambda を使って増減するインスタンスに対して動的にアラームを設定するのを試してみました。（何番煎じかわかりませんが・

jinjin252525 2019/06/23

リンク

AutoScaling(オートスケーリング)時のデプロイのベストプラクティス(CodeDeploy) - keiwt’s diary

AutoScaling(オートスケーリング)時にはLaunchConfigのAMIを元に新しいインスタンスが作成されます。しかし、GitHub等のリビジョンが進んでいると新しいインスタンスのみ古いリビジョンのソースになってしまいます。そのため、主に以下の２つの方法があります。デプロイの度にAMIを作成して、AutoScalingGroup(オートスケーリンググループ)とELBを差し替えるサーバー内の変更時もデプロイ時も常に同じことをすればいいので、判断が不要になることが利点です。しかし、デプロイの度にAMIを作成して、AutoScalingGroupとELBを作成して、 CodeDeployのApplicationStopイベントが初回のデプロイ時には動かないため、 AutoScalingGroup(オートスケーリンググループ)に対して1回デプロイして、 Route53のCNAM

jinjin252525 2017/07/07

リンク

AutoScaling導入によって得たメリットと気をつけたいポイント - Qiita

AWSにはAutoScalingという便利な機能があります。AutoScalingは負荷の状況や指定した時間に自動的にインスタンスを用意してくれる機能です。ソーシャルゲームの様なアクセスがピンポイントで大量にくるような場面で大変活躍してくれます。そんなAutoScalingを導入して得たメリットと導入の際に気をつけたいポイントについてお話しようと思います。インスタンス構築時間が30分から5分に！！スケジュール機能により、必要な時間に必要な台数をコントロール！！サーバ費のコスト削減！！ 1. インスタンス構築時間が30分から5分に！！アプリサーバがいますぐ欲しいんです！こんな依頼が時にはありますよね？今まではアプリサーバを構築するのにインフラの手とアプリエンジニアの手が必要でした。まず、インフラがEC2を建ち上げ、chefもしくはansibleでプロビジョニングします。その後

jinjin252525 2017/07/07

リンク

1台のサーバですら Auto Scaling でケチる - HDE BLOG

こんにちは。小椋です。「まあ15分ぐらいなら落ちてても実際そこまで困らないけど、基本的には24時間起動していてほしいんだよね……」という緩めのサービスレベルで稼働しているSPOF気味なサーバー、ありますよね。社内向けのジョブスケジューラーとか、一日に数回なんか集めて分析する奴とか。あんまり表立って言わないだけで、御社にもありますよね？サービスレベルが緩めだし、ミッションクリティカルでもないので、ただ起動しっぱなしにしてほっとけばいいや……と思いきや、やっぱり止まったら止まったで処置も必要だし、生死確認はちゃんとしないといけないし、そもそも起動しっぱなしなのでお金もかかるし、とか、意外とお金も労力もかかりますよね。私HDEの社長ですが、サーバ代に関してはかなりケチです！そういうケースに関しては、場合によってはEC2のAutoScaling Groupで管理すると節約ついでに横着でき

jinjin252525 2015/02/14

リンク

【新機能】Auto Scalingのインスタンス起動/破棄時に初期処理/終了処理を追加 – LifeCycleHook機能のご紹介 | DevelopersIO

【新機能】Auto Scalingのインスタンス起動/破棄時に初期処理/終了処理を追加 – LifeCycleHook機能のご紹介こんにちは、せーのです。 Auto Scalingの新機能についてはこれまでStandby State、Detach Instanceとご紹介してきましたが、実はもう一つ新機能があります。それが今回ご紹介する「LifeCycleHook」機能です。読んで字のごとく、Auto Scalingにおけるインスタンスのライフサイクルをフックする、という機能です。それでは詳しく見ていきましょう。 Auto Scalingにおけるインスタンスのライフサイクル Auto Scalingのインスタンスの「ライフサイクル」、つまりインスタンスが生まれてから死ぬまでの状態遷移はどのようなものでしょう。インスタンスが起動し始めてからAuto Scaling Groupに追加するま

jinjin252525 2014/10/29

リンク

Amazon Auto Scalingの Desired Capacity を理解する | DevelopersIO

ども、大瀧です。げんしけん二代目の伍(14)、波戸くんが煮詰まってきていい感じですね、次巻の展開に期待!! さて、今回はAWSで最もわかりやすくElasticしてくれる(?)機能としてお馴染みの、Auto Scalingの上級編な話題です。ここがムズいよAuto Scaling AWSのAuto Scalingは、EC2インスタンスを自動でCreate/Terminateする機能として負荷分散や可用性向上のためによく使われる機能です。しかし、Management Consoleでは作成できなかったり、使うために必要な設定が比較的多かったりと、敷居が高い印象があります(実際はそんなことないんですけどね)。 Auto Scalingでインスタンス数を設定するパラメータは3つ、Min Size(最小数)/Max Size(最大数)/Desired Capacity(今回の話題)があります。