Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a EC2に対するcloudwatchのアクション設定がポリシーで使えないときの代替策
Similar a EC2に対するcloudwatchのアクション設定がポリシーで使えないときの代替策 (20)
EC2に対するcloudwatchのアクション設定がポリシーで使えないときの代替策
- 1. CloudWatch – SNS – SQSで遊んでいるイ ンスタンスを自動ターミネートする IP接続制限＋VPCで、EC2に対する CloudWatchのアクション設定が使え ないときの対策
- 2. 自己紹介 • 長尾 太介 （ながお だいすけ） – twitter : daikumatan • HPC(High Perfomance Computer)のお仕事 – 並列で動作する物理シミュレータの開発 – 大規模計算に適した解析環境の導入 • 好きなAWSのサービス – EC2(c4.8xlarge), SQS
- 4. HPC (High Performance Computer)とは？ 蓮舫︎：「いちばんじゃなきゃダメなんで すか？」もHPC！ 一言でいうとスパコンのこと。 なぜHPCでシミュレーションをするの か？その意義は・・・ ①実験では調べることができない事象 を計算により明らかにする （分子構造、ナノ構造解析など） ②長い時間と多大なコストが必要とな る実験を計算で代替する （車の衝突実験、耐震実験など） http://upload.wikimedia.org/wikipedia/ja/8/82/K _computer_S0071267.JPG
- 5. 大規模な計算をするために・・・・ 複数台で大規模な計算を実施 MPI(Message Passing Interface)による分散メモリ並列を利用 = 高速なインターコネクト（ノード間通信）が必須
- 6. HPC @AWS AWSでは10GEtherが適応されるインスタンスを利用する c3.8xlarge, c4.8xlargeなど・・・ 10GEther (10Gbps ) Placement Group c4.8xlarge (Haswell 18コア) SR−IOVを設定
- 7. つまり言いたいことは・・・・・ c4.8xlarge： $2.352/h @東京リージョン - これを８台使って３日間計算すると約16万円! - １０ケース計算すると80インスタンスで160万円 1week計算もせず放置プレーすると 始末書レベル・・・ 計算中以外は、インスタンスを立ち上げ ないオペレーションが必須！
- 8. 本題： やりたいこと CPUUtiliation[%](CPU負荷) 100% 閾値 5% Time ロ ー ン チ 計 算 開 始 数時間〜1Week 計 算 中 計 算 終 了 タ ー ミ ネ ー ト CPUUtilizationの値が閾 値以下となったときイン スタンスをターミネート - 計算終了後、自動でターミネートしたい - ただしインスタンスローンチから１h程度は猶予時間を設ける （ユーザがデータ転送や計算を実行するまでの猶予時間が必要） 監 視 ス タ ー ト １時間
- 10. 課題：重厚長大な企業であるある! IP接続制限のポリシー • 所属機関のポリシーとしてIP接続制限があるケース • VPCの外側からVPC内へアクセスするサービスが軒並みNG • この場合EC2に対するCloudWatchのアクション設定 （Stop/Terminate）が使えずインスタンスをターミネートできな い
- 11. 代替策：JAWS-UG CLI ハンズオンを応用しよう！ • JAWS-UG CLI専門支部 #8 - SNS & SQS – http://jawsug-cli.doorkeeper.jp/events/17246 • JAWS-UG CLI専門支部 #9 -CloudWatch入門 – http://jawsug-cli.doorkeeper.jp/events/17391
- 12. 代替策のCDP： CloudWatch + SNS + SQS Amazon SQSqueue Amazon SNS email notification topic instances CloudWatch alarm polling message Launch/stop/terminate user HPCユーザのフロン トエンドサーバ （常時起動） HPC環境
- 13. フロー ①, ② Amazon SQSqueue Amazon SNS email notification topic instances CloudWatch alarm polling message Launch/stop/terminateHPC user 常時起動 インスタンス ①HPC環境 ローンチ ②ローンチから１時間後 CloudWatchのアラームを設 定(CPUUtilization 5%以下で アラーム)
- 14. フロー ③, ④ Amazon SQSqueue Amazon SNS email notification topic instances CloudWatch alarm polling message Launch/stop/terminateHPC user 常時起動 インスタンス ③HPC環境の CPUUtilizationが 5% 以下でアラームをだ す。 ④SNSがアラー ムを受け取り、 メッセージを EmailとSQSに送 信
- 15. フロー ⑤, ⑥, ⑦ Amazon SQSqueue Amazon SNS email notification topic instances CloudWatch alarm polling message Launch/stop/terminateHPC user 常時起動 インスタンス ⑤SNSのメッ セージを受け 取りQueueに 格納 ⑥cronでSQS をpolling メッセージが あれば中身 を解析 ⑦HPCクラスタを構成するインスタンスをすべ てターミネート (Alarm descriptionにHPC環境をターミネート するコマンドが記述されている)
- 16. 工夫点・ハマりどころ 1 • インスタンス立ち上げと同時に、CPU負荷5%以下のアラームが鳴ら ないようにCloudWatchの設定タイミング考慮 – CloudWatchのアラーム設定スクリプト（setCloudWatchAlarm.sh）を、HPCローン チと同時に”nohap”で実行 – １時間後から監視が始まるよう上記スクリプト内に”sleep 3600”を記述 # HPC環境を起動する $ launchHPC.sh ・・・・ $ cat launchHPC.sh #!/bin/bash # インスタンス起動＆HPC環境構築 ~~ 省略 ~~ # cloudWatch Alarm設定 nohup setCloudWatchAlarm.sh ・・・・・ $ cat setCloudWatchAlarm.sh #!/bin/bash # 計算開始までの猶予時間 sleep 3600 # CloudWatch Alarm設定 ~~ 省略 ~~
- 17. CloudWatch設定（ほとんどハンズオンと同じ） CWATCH_NAMESPACE=AWS/EC2 CWATCH_METRIC_NAME=CPUUtilization CWATCH_METRIC_UNIT=Percent CWATCH_STATISTICS=Average CWATCH_DIMENSIONS="Name=InstanceId,Value=i-12345678" CWATCH_ALARM_PERIOD=300 CWATCH_EVALUATION_PERIOD=3 CWATCH_THRESHOLD=5 CWATCH_COMPARISON=LessThanThreshold CWATCH_ALARM_NAME=”dnagao_myCluster" WATCH_ALARM_DESC=”terminateHPC.sh myCluster " CWATCH_ALARM_TOPIC=arn:aws:sns:us-east-1:111122223333:dnagao_SNS aws cloudwatch put-metric-alarm --namespace ${CWATCH_NAMESPACE} --metric-name ${CWATCH_METRIC_NAME} --unit ${CWATCH_METRIC_UNIT} --statistic ${CWATCH_STATISTICS} --dimensions ${CWATCH_DIMENSIONS} --period ${CWATCH_ALARM_PERIOD} --evaluation-periods ${CWATCH_EVALUATION_PERIOD} --threshold ${CWATCH_THRESHOLD} --comparison-operator ${CWATCH_COMPARISON} --alarm-name ${CWATCH_ALARM_NAME} --alarm-description "${CWATCH_ALARM_DESC}" --alarm-actions ${CWATCH_ALARM_TOPIC} SQS、SNSはマネジメントコンソール上から設定しています。なので、本資料からは省略 SQSのメッセージ取得後、 HPCをターミネートさせるコマ ンドを記述 CloudWatch > SNS > SQSと内 容が伝搬
- 18. 工夫点・ハマりどころ 2 • キューに格納されたメッセージが複数あるとき、メッセージが ゼロになるまで反復処理。（cronでSQSをpollingしているため、 反復処理をしないとメッセージがなくなるまで時間がかかる） # メッセージ数の取得 NUM_MSG=`aws sqs get-queue-attributes --queue-url ${SQS_QUEUE_URL} --attribute-names ApproximateNumberOfMessages | jq -r ".Attributes | .ApproximateNumberOfMessages”` # メッセージがなくなるまで処理 If [ ${NUM_MSG} -gt 0 ]; then for ((i=0; i<${NUM_MSG}; i++)) do SQSからメッセージ受け取り メッセージの解析によりterminate対象となるHPCクラスタを決定 対象となるHPCクラスタのターミネート メッセージ削除 アラーム削除 done fi
- 19. その他 • SNSのTopic作成、SQSのQueue作成およびcronに よるpolling設定は、ユーザ毎に行うことを考える と、フロントエンドサーバへの新規アカウント作成 時に、自動設定されるのが理想 Amazon SQSqueue Amazon SNS email notification topic polling message user フロントエンドサーバ （常時起動インスタンス）