memorycraftです。 ついにAWSの管理コンソールからAutoScalingが管理可能になりました。 早速触ってみます。 EC2のコンソールの左ペイン最下部にAutoScaling(以下AS)の項目が追加されています。 選択してみると、左側に概要が表示されるので、「Create Auto Scaling Group」をクリックします。
Auto Scalingから起動されたEC2には、下記のようにaws:autoscaling:groupNameタグが付与されます。 これにより、このタグの存在をチェックすれば自分がAuto Scalingから起動されたEC2かどうか確認できるはずです。 そこで、以前紹介したEC2のコマンドラインツールのインストールと起動時にホスト名をNameタグの値とする方法のコマンドラインツールを利用し確認してみます。 タグは下記のように確認することができます。 # ec2-describe-tags TAG instance i-da1fdcd9 aws:autoscaling:groupName vpc-ag-2 TAG instance i-965bb495 Name OpwnVPN TAG instance i-cde3f7cd Name Win TAG instance i-da1fdcd9
Auto Scalingの設定をしている際に気になっていた、Metrics Collectionについて少し調査してみました。 (MetricsということなのでCloudWatch関係と予想) まず、as-describe-metric-collection-typesというコマンドがあるので、実行してみます。 # as-describe-metric-collection-types METRIC-COLLECTION-TYPE GroupMinSize METRIC-COLLECTION-TYPE GroupMaxSize METRIC-COLLECTION-TYPE GroupDesiredCapacity METRIC-COLLECTION-TYPE GroupInServiceInstances METRIC-COLLECTION-TYPE GroupPendingInstanc
今回も、書籍(Amazon Web Servicesクラウドデザインパターン設計ガイド)からCloud Design Pattern(CDP)の記事になります。 今回は「Scale Outパターン」に関して、運用よりの話になります。 このパターンの「注意点」に下記のような記載があります。 EC2内のアップデートが必要な場合は、Auto Scalingで起動する元となるAMIもアップデートする必要がある。 今回は、以前紹介した記事「コマンドラインツール使ってVPCでAuto Scaling」内で紹介した コマンドラインツールで、Auto Scalingで利用するAMIを差し替えてみます。 そもそも、AMIの情報はLaunch Configで指定されています。 そのため、Launch ConfigのAMI情報をアップデートすればよいと思うのですが、Launch Configの情報をアップデート
以前、コマンドラインツール使ってVPCでAuto ScalingとAuto ScalingのScaling Policyを作成しCloudWatchと連携してみるの記事でAuto Scalingの準備ができたので実際に負荷をかけて挙動を確認したいところですが、その前にAuto ScalingのアクションをSNS(メール)で通知できるようにしておきます。 はじめに、SNSのトピック作成です。 Auto Scalingのコマンドで通知先を設定する時にこのトピックを指定することになります。 次に作成したトピックに対して、サブスクリプションを設定します。 サブスクリプションはトピックに投げられたメッセージの通知先(メール)となります。 設定だけでは有効にならないので、下記のメールが届きましたら本文中の確認用のリンクをクリックする必要があります。 You have chosen to subscri
今回は、先日書籍(Amazon Web Servicesクラウドデザインパターン設計ガイド)の発売も発表された Cloud Design Pattern(CDP)の記事になります。 対象はコマンドラインツール使ってVPCでAuto Scalingに引き続き、「Scale Outパターン」です。 今回は「実装」の部分に関して、具体的に試してみます。 EC2数を増減させるトリガーとなる条件(メトリクス)を定義する。 EC2の平均CPU使用率、ネットワーク流量、セッション数、EBSのレイテンシーなどがよく使われる。 そのメトリクスをCloudWatchを使って監視し、一定の条件を満たすとアラームを出すように設定する。 アラームを受けた際、Auto ScalingがEC2数を増減するように設定する。 (前提として最初に紹介した記事の手順でAuto Scaling Groupまで作成できているとしま
今回は、先日書籍(Amazon Web Servicesクラウドデザインパターン設計ガイド)が発売されたCloud Design Pattern(CDP)の記事になります。 対象は「Scale Outパターン」です。 このパターンの「実装」に下記の記載があります。 ロードバランサ―サービス「ELB」、モニタリングツール「CloudWatch」 そして自動でスケールアウトする「Auto Scaling」の三つのサービスを組み合わせることで、負荷に応じて自動でスケールアウトするシステムを容易に構築できる。 コマンドラインツールでのAuto Scalingは以前、Auto Scaling API Tools(Auto Scalingのコマンドラインツール)、Auto Scaling API Toolsを使ってみる(中途半端…)の記事のように紹介しましたが今回は、VPC環境で試してみました。 まず
Auto Scalingの有名な使い方として、CPU使用率やSQSのキューサイズなど、CloudWatchのメトリクスの変化をトリガーに、インスタンス数を自動で増減させるものがありますが、実は、指定時刻や定期的にインスタンス数を増減させることも可能です。 では早速、今回もPHPを利用して試してみます。 今回は、インスタンスを起動していない状態から、指定時刻に1インスタンス起動するようにしてみました。 ○create_launch_configuration まずは、Auto Scalingの設定になります。 増減させるインスタンスのAMIやインスタンスタイプ、そして、セキュリティグループなどを登録します。 require_once("/opt/aws/php/sdk.class.php"); define("AWS_KEY" , "AAAAAAAA"); define("AWS_SECRE
前回の記事(Auto Scaling API Tools(Auto Scalingのコマンドラインツール))で、実際にAuto Scaling API Tools”使ってみました。 やはり、PHP(AWS SDK)で設定することにしたため、launch-configとauto-scaling-groupの作成/削除までという、中途半端な状態まではありますが、準備してみました。 コマンドは下記のようになります。 ▼ launch-configの作成 # ./as-create-launch-config crawl > --image-id ami-xxxxxxxx > --instance-type t1.micro > --key suz-lab_ap-northeast-1 > --group default > -I IIIIIIII > -S SSSSSSSS > --region
Auto Scalingのコマンドラインツールは、Auto Scaling API Toolsからダウンロードが可能です。 利用するOSはCentOSで、Javaがインストールされているという前提になりますが、下記のようにすると、利用できるようになります。 # cd /opt/aws # curl -OL http://ec2-downloads.s3.amazonaws.com/AutoScaling-2010-08-01.zip # unzip AutoScaling-2010-08-01.zip # mv AutoScaling-1.0.33.1 auto-scaling # export AWS_AUTO_SCALING_HOME=/opt/aws/auto-scaling # export JAVA_HOME=/usr/java/default # cd auto-scaling
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く