1台のサーバですら Auto Scaling でケチる - HDE BLOG
こんにちは。小椋です。 「まあ15分ぐらいなら落ちてても実際そこまで困らないけど、基本的には24時間起動していてほしいんだよね……」 という緩めのサービスレベルで稼働しているSPOF気味なサーバー、ありますよね。社内向けのジョブスケジューラーとか、一日に数回なんか集めて分析する奴とか。あんまり表立って言わないだけで、御社にもありますよね？ サービスレベルが緩めだし、ミッションクリティカルでもないので、ただ起動しっぱなしにしてほっとけばいいや……と思いきや、やっぱり止まったら止まったで処置も必要だし、生死確認はちゃんとしないといけないし、そもそも起動しっぱなしなのでお金もかかるし、とか、意外とお金も労力もかかりますよね。 私HDEの社長ですが、サーバ代に関してはかなりケチです！ そういうケースに関しては、場合によってはEC2のAutoScaling Groupで管理すると節約ついでに横着でき
Amazon EC2 Auto Scaling のスケールアウトが遅い時に確認すること | DevelopersIO
困っていること Amazon EC2 Auto Scaling のターゲット追跡スケーリングポリシーを作成しました。 ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、Auto Scaling グループをスケールアウトする挙動と認識してます。 指定されたメトリクスがターゲット値を超えているものの、時々スケールアウトするまでの応答時間が長く掛かっていることを確認しています。 確認するべき点（原因）と、対処法を教えてください。 どう対応すればいいの? 確認するべき点（原因） ターゲットグループに対して CloudWatch の詳細モニターリングを使用しているか確認する CloudWatch の基本モニタリング は 5 分間隔でメトリクスが公開されます。 基本モニタリング データは自動的に 5 分間隔で取得されます。 詳細モニタリング データは 1 分
運用中のEC2インスタンスにAuto Healingを設定してみた | DevelopersIO
こんにちは。AWS事業本部トクヤマシュンです。 運用中のEC2インスタンスにAuto Healingを設定することがありました。 EC2の耐障害性を向上させるはじめの一歩として使うことのできる機会も多いかと思い、今回紹介します。 Auto Healingって何？ Auto Healingとは、Auto Scaling Groupを使って、起動中のEC2インスタンスを常に一定数に保つデザインパターンのことです。 Auto Scaling Groupのヘルスチェック失敗を契機として、インスタンスをサービスから切り離し、新たなインスタンスをサービスインさせることで障害復旧を行います。 Auto Scalingを複数AZで設定しておけば、AZ障害の際も別AZにEC2インスタンスを起動させることができます。 余談ですが、EC2インスタンスの自動復旧の仕組みとして、Auto Recoveryというもの
停止保護を有効にしているEC2インスタンスがAuto Scalingでスケールインすると、保護を無視して削除される | DevelopersIO
コンサル部のとばち（@toda_kk）です。 2022年5月のアップデートにより、EC2インスタンスの「停止保護」の機能が追加されました。 従来の「削除保護」に加えて、「停止」の動作に対しても保護機能が追加されたことになります。 そこでふと疑問に思いました。 Auto Scalingを利用している場合、「停止保護」を有効にしているEC2インスタンスがスケールインしようとすると、どういう動作になるんでしょうか？ ドキュメントに答えがあった 疑問をそのままTwitterに呟いていたら、同僚から教えてもらいました。 削除保護と一緒でAuto Scallingの場合は無視して削除するみたい > Enabling stop protection does not prevent Auto Scaling from terminating an instance when the instance i
Auto Scalingの起動設定で指定できるインスタンスタイプをSCPで制限する | DevelopersIO
こんにちは。サービスグループの武田です。 Auto Scalingグループを使用する際、起動するEC2インスタンスの設定テンプレートとして、「起動設定」と「起動テンプレート」があります。今回は「起動設定」を対象として、作成する際に指定されたインスタンスタイプが含まれていた場合、拒否するようなSCPを設定してみました。 今回作成したポリシーは次のようなものです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "autoscaling:CreateLaunchConfiguration", "Resource": "*", "Condition": { "StringLike": { "autoscaling:InstanceType": "t2.*" } } } ] } T2ファミリーをインスタ
ECS コンテナインスタンスを停止すると自動起動する挙動を回避するためには | DevelopersIO
困っていた内容 コスト削減のため ECS コンテナインスタンス（EC2）を停止しましたが、いつの間にか「終了状態」になり、新しいコンテナインスタンスが起動しました。 コンテナインスタンスでは通常の EC2 のように終業時に停止して、始業時に開始するといったコスト削減はできないのでしょうか。 どう対応すればいいの? Auto Scaling を利用した自動終了・開始をお試しください。 ECS クラスターを作成する際に「EC2 Linux + ネットワーキング」を選択すると、自動的に Auto Scaling も作成されます。Auto Scaling によりコンテナインスタンスの起動数が自動的に制御されるため、EC2 を直接停止しても、自動的に終了状態になり、新しいインスタンスが作成されます。 そのため、コンテナインスタンスを特定時間だけ起動したい場合は、Auto Scaling の機能を使用
EC2のログをfluentdを使ってタグ情報を利用したフォルダ構成でS3にアップロードする - Qiita
オートスケール環境ではEC2の起動、停止が動的に行われるのでログ(syslogやアプリ、ミドルウェア)を外部に出す必要があります。 やり方として S3にアップロード CloudWatchLogsを使う ログサーバーに転送 などが一般的だと思います。 S3にアップロードする方法を考えた場合、どのようなフォルダ構成でアップロードするかは結構大切なことだと思います。(探しずらいとあとで大変) また、本番環境、検証環境などがある場合、どこにどうおくかをEC2のタグの情報を利用して考えたい場合もあると思います。 そこで今回はEC2のログをfluentdを使ってmetadataやタグ情報を利用したフォルダ構成でS3にアップロードすることをやってみました。 今回の例では/var/log/messagesをS3に以下の構成でアップロードするようにしてみました。 Bucket │ ├-Env(product
【EC2】Fluentd で Auto Scaling グループ配下にあるインスタンス内のログをS3へ転送 (後編) | クロジカ
ホーム / クラウドコンピューティング / 【EC2】Fluentd で Auto Scaling グループ配下にあるインスタンス内のログをS3へ転送 (後編)
EC2のオートスケーリングについて整理する | DevelopersIO
Amazon EC2 Auto Scalingについて勉強していて整理がついてきたのでまとめてみました。 以下のドキュメントをもとに要約や自分で調べた加筆を行っています。 オートスケーリングについて オートスケーリングは何らかの条件に応じて動的に計算リソースを変化させることです。 例えば、WebサーバーのCPU使用率が一定数を超えたらサーバーの台数を1増やすなどがこれに該当します。 こういった手法はAWSなどのクラウドと相性が良いです。 というのも、今回考えるEC2ではサーバーの起動など計算リソースの確保、開放が非常に用意なためです。 これを上手に活用することで様々な恩恵を受けることができます。 以下ではオートスケーリングに必要な要素を整理し、そのメリットについて考えていきましょう。 オートスケーリングの3つの要素 ここではAmazon EC2の場合にオートスケーリングを実現するのに必要な
AutoScallingのライフサイクルフックを使用してスケールイン時にEC2インスタンス内のログを退避させる | DevelopersIO
はじめに こんにちは。大阪オフィスの林です。 EC2 AutoScalling環境下でEC2インスタンスがターミネートする際のログ退避についてライフサイクルフックを使用したアーキテクチャーを検討したのでまとめておきたいと思います。 今回検討したアーキテクチャーはザックリ下図のイメージです。 よくあるログ管理（退避）のアーキテクチャとして、CloudWatchAgentを使用しCloudWatchLogsにログを転送し、Kinesisを挟んでS3に転送するといった方法もありますが、CloudWatchLogs自体の料金がネックとなり採用を見送るケースもあったりします。かと言ってOS上で定期的な間隔でログ転送バッチを回したりするのも良いのですが、その定期的な間隔とEC2インスタンスのターミネートのタイミング次第では直近のログが欠陥してしまうことも十分考えられます。今回のアーキテクチャはその折衷
簡単にできる！Auto Scalingの「起動設定」を「起動テンプレート」に移行しよう | DevelopersIO
既に夏のような湿気と暑さに参っています。 ▲ 心がサマーカットしたがっています こんにちは。Shirotaです。 この時期は毎年湿気への怨嗟をどこかしらに漏らしている気がします。 気を取り直して、怨嗟よりもお話ししたいAuto Scalingの話を今日はしたいと思います。 Auto Scalingで「起動テンプレート」、使っていますか？ EC2インスタンスの起動などで便利な、インスタンス起動に必要な情報を設定しておける「起動テンプレート」というものがあります。 こちら、Auto Scalingでも利用することができるようになっております。 Launch Templates for Amazon EC2 instances の紹介 Auto Scalingには元々「起動設定」と言うインスタンス起動に必要な情報を設定しておける機能があったのですが、こちらは2021年6月16日現在、公式ドキュメ
Auto Scaling グループへロードバランサーを登録して確認する | DevelopersIO
こんにちは、yagiです。 本日は、AutoScalingGroupにロードバランサーを登録して確認する内容について記載します。 AutoScalingGroupにロードバランサーを登録することについて Auto Scaling グループを Elastic Load Balancing ロードバランサーに登録すると、アプリケーションの負荷分散をセットアップできます。Elastic Load Balancing は Amazon EC2 Auto Scaling と連携して、正常な Amazon EC2 インスタンス間で着信トラフィックを分散します。これにより、アプリケーションのスケーラビリティと可用性が向上します。複数のアベイラビリティーゾーン内で Elastic Load Balancing を有効にして、アプリケーションの耐障害性を向上させることができます。 （公式ドキュメントからの引
Auto Scalingの段階スケーリングポリシーについて | DevelopersIO
オートスケーリングの種類 オートスケーリング機能は、アプリケーションの安定的な「性能を維持」し「費用を抑える」ような、自動的なサーバー運用を実現する上で重要な機能です。オートスケーリングには、いくつかの種類があります。 手動スケーリング：例）今からインスタンスを4台にする スケジュールに基づくスケーリング：例）午前6時にインスタンスを2台増やす 動的スケーリング：例）CPU90%になったらインスタンスを1台増やす 固定数維持：例）障害が発生してもインスタンスを4台を維持する 今回は、動的スケーリングの新機能である、「段階スケーリング」についてご紹介したいと思います。 段階スケーリングポリシー（Step Scaling Policies） 段階スケーリングポリシーは、CloudWatchメトリクスから得られる値（CPU使用率やSQSキューサイズなど）の閾値を超えて発せられるアラームに対して、
AmazonAutoScaling機能について - サーバーワークスエンジニアブログ
こんにちは、開発・運用部の川口です。 最近は僕個人として繁忙期を過ぎたので今のうちにと技術検証に明け暮れている毎日を過ごしています。今まで機能のみを知っていてなかなか手が出せなかった多くの機能に触れていくたびに新たな発見が有り、「もっと早く検証していれば楽ができたのに・・・」と思うことしきりです。 さて、現在検証しているのはAmazonAutoScaling機能についてです。発表当時は話題になり多くの人が実際にスケーリング機能を試したようですがここ最近での検証・実証例が少なく、 2010/08/1以降に行われたAPIバージョンアップ以降の日本語の情報は特に少なかった為ので今回の検証を行いました。なお、以降の検証内容に関する説明については基本的に「EC2インスタンスをAPI経由で操作できる程度のAWS経験者」を基準としていますので基礎的な説明はいくつか省かせていただいています。 なお、EC2
Auto Scaling グループとインスタンスの CloudWatch メトリクスを監視する - Amazon EC2 Auto Scaling
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Auto Scaling グループとインスタンスの CloudWatch メトリクスを監視する メトリクスは Amazon CloudWatch での基本的な概念です。メトリクスは、&CW; に発行された時系列のデータポイントのセットを表します。メトリクスはモニターリング対象の変数と考え、データポイントは時間の経過と共に変数の値を表します。これらのメトリクスを使用して、システムが正常に実行されていることを確認できます。 Auto Scaling グループに関する情報を収集する Amazon EC2 Auto Scaling メトリクスは、AWS/AutoScaling 名前空間にあります。Auto Scaling インスタンスから CPU やその他の使用状況データを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Building a minecraft server for a family using Auto Scaling Groups
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する（終） - シンプライン（Simpline）公式採用サイト‐採用情報