aws auto scalingによるwebapサーバbatchサーバの構成例
TRANSCRIPT
takemikami’s note– http://takemikami.com/
三上威 (フリーランスITエンジニア)twitter:@takemikami
AWSAutoScalingによるWebAPサーバ/Batchサーバの構成例
AutoScalingでサーバを構成するために必要な周辺知識
1
AWS AutoScaling
2016.1.26
Copyright (C)2016TakeshiMikami.Allrightsreserved.
takemikami’s note– http://takemikami.com/
アジェンダ
• 自己紹介• AWSAutoScalingとは• 想定するサーバ構成• 実現に必要な周辺知識
– どのように処理を分散するか…ELB,SQS– どこにデータを保持するか…RDS,S3– どこにログを出力するか…CloudWatch Logs– どのようにサーバを起動/構成するか…LaunchConfiguration,cloud-init– 何をきっかけにScalingするか…CloudWatch,Alarm
• Tips– アプリケーションのデプロイと切り戻し– バッチサーバの安全な減設
• まとめ
2Copyright (C)2016TakeshiMikami.Allrightsreserved.
takemikami’s note– http://takemikami.com/
自己紹介
• 三上威 (@takemikami)• フリーランスITエンジニア
– マーケティングデータ分析基盤のシステム開発運用• 略歴
– 情報通信ネットワークの研究@甲南大学理学部応用数学科– Web系システムの開発・構築@NEC系SIer– 旅行系ECサイトのマーケティングデータ分析@DeNA
• 近扱っている技術領域– Spark,Scala,Akka,Hadoop,AWS,Redshift,docker,embulk,fluentd
3Copyright (C)2016TakeshiMikami.Allrightsreserved.
takemikami’s note– http://takemikami.com/
AWSAutoScalingとは
EC2のインスタンス群をグループとして管理し、①障害が生じたノードを検出して自動で置き換え
②需要に応じてインスタンス数を拡大・縮小
を実現するための仕組み
但し、実現するためには、AutoScalingだけで無く、関連するAWSのサービスなど、周辺知識が必要になります。
4Copyright (C)2016TakeshiMikami.Allrightsreserved.
AWSAutoScalingとは
EC2
AWSのAutoScalingとは何かについて概要を示します。
Auto Scaling group
takemikami’s note– http://takemikami.com/
AutoScalingを構成するために考えるべきこと
5Copyright (C)2016TakeshiMikami.Allrightsreserved.
AWSAutoScalingとは
AWSのAutoScalingを構成するために考えるべきことについて整理します。
考えること 関連サービス 説明
どのように処理を分散するか
ELBSQS
各サーバへのリクエストをどのように分散すべきか仕組みを検討
どこにデータを保持するか
RDSS3
EC2にデータを保持できない(動的に起動/終了するため)ため、保持先を検討
どこにログを出力するか
CloudWatch Logs EC2にログを保存できない(動的に起動/終了するため)ため、出力先を検討
どのようにサーバを構成するか
LaunchConfigurationcloud-init
動的にEC2を起動する際のミドルウェア/アプリケーションの構成方法を検討
何をきっかけにScalingするか
CloudWatchAlarm
Scalingする条件を設定
takemikami’s note– http://takemikami.com/
想定するWebAPサーバの構成
6Copyright (C)2016TakeshiMikami.Allrightsreserved.
想定するサーバ構成
本スライドで想定するWebAPサーバの構成図を示します。
CloudWatch
ELB
EC2
CloudWatchLogs
LaunchConfiguration S3
Auto Scaling group
EC2
EC2
RDS,S3
Alarm
WebAPサーバへの要求を分散
監視によるAlarmに応じてScaling
LaunchConfigurationによってサーバを構成
CloudWatchLogsにログデータを集約
RDS,S3にデータを保持
takemikami’s note– http://takemikami.com/
想定するBatchサーバの構成
7Copyright (C)2016TakeshiMikami.Allrightsreserved.
想定するサーバ構成
本スライドで想定するBatchサーバの構成図を示します。
CloudWatch
SQS
EC2
CloudWatchLogs
LaunchConfiguration S3
Auto Scaling group
EC2
EC2
RDS,S3
Batchサーバへの要求をQueueに保持各EC2からpolling
(実行パラメータはRDS)
CloudWatchLogsにログデータを集約
RDS,S3にデータを保持
LaunchConfigurationによってサーバを構成
RDS
Alarm監視によるAlarmに応じてScaling
takemikami’s note– http://takemikami.com/
どのように処理を分散するか〜WebAPサーバの場合
8Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どのように処理を分散するか
どのように処理を分散するか(WebAPサーバの場合)について説明します。
ELB
EC2
Auto Scaling group
EC2
EC2
WebAPサーバへの要求を分散
• ELB(LoadBalancer)で処理を分散
AutoScalingGroupに対応するELBを指定→(HealthCheck成功後)自動でELBに接続される
takemikami’s note– http://takemikami.com/
どのように処理を分散するか〜Batchサーバの場合
9Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どのように処理を分散するか
どのように処理を分散するか(Batchサーバの場合)について説明します。
• SQSでJobキューを作り、Batchサーバからpollingすることで処理を分散
各EC2インスタンスで、以下の処理を実施①SQSからJobIDを取得②該当JobIDのパラメータをRDSから取得③該当JobIDのRDS上のStatusを実行中に④該当バッチを実行⑤該当JobIDのRDS上のStatusを完了に⑥①に戻り次のJobを処理
SQS
EC2
Auto Scaling group
EC2
EC2
Batchサーバへの要求をQueueに保持各EC2からpolling
(実行パラメータはRDS)
RDS
※SQSの仕様上Queueに同じJobIDが入る可能性があるので、実行StatusはRDSで管理
JobID投入
実行パラメータ投入
takemikami’s note– http://takemikami.com/
どこにデータを保持するか
10Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どこにデータを保持するか
どこにデータを保持するかについて説明します。
EC2
Auto Scaling group
EC2
EC2
RDS,S3RDS,S3にデータを保持
• EC2インスタンスは動的に起動/終了するためデータを保持することは出来ない→RDSやS3にデータを保持
EC2のDisk上のデータはインスタンス終了時に消える
データはEC2のDisk上に持たず、RDSやS3に保存する
takemikami’s note– http://takemikami.com/
どこにログを出力するか
• EC2インスタンスは動的に起動/終了するためログを保存出来ない→CloudWatch Logsにログを転送
11Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どこにログを出力するか
どこにログを出力するかについて説明します。
EC2
CloudWatchLogsAuto Scaling group
EC2
EC2
CloudWatchLogsにログデータを集約
EC2のDisk上のデータはインスタンス終了時に消える
※awslogsパッケージをinstallし、設定ファイルに転送するログファイルを記載すれば転送設定できる。
ログは逐次、CloudWatchLogsに転送
takemikami’s note– http://takemikami.com/
どのようにサーバを構成するか〜インスタンスのスペック等
12Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どのようにサーバを構成するか
構成するサーバのスペックなどの情報の設定方法を説明します。
EC2
LaunchConfiguration
EC2
EC2
Auto Scaling group
• ベースとするAMIやInstanceTypeなどはLaunchConfigurationに設定
設定する主な項目:・ベースとするAMI・InstanceType・SecurityGroup・BlockDeviceのサイズ
takemikami’s note– http://takemikami.com/
どのようにサーバを構成するか〜インストールするパッケージ
13Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どのようにサーバを構成するか
構成するサーバにインストールするパッケージの設定方法を説明します。
EC2
LaunchConfiguration
EC2
EC2
Auto Scaling group
• インストールするパッケージの情報はcloud-initで設定
LaunchConfigurationのUserDataにcloud-initの設定を記載
#cloud-config
#userandgroupsgroups:- admin
users:- default- name:adminprimary-group:admingroups:wheel
#repositoryandpackagesrepo_upgrade: security
packages:- awslogs- nginx
cloud-initの例→・Adminユーザ作成・awslogs/nginxセットアップ
takemikami’s note– http://takemikami.com/
どのようにサーバを構成するか〜設定ファイル・アプリケーション
14Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:どのようにサーバを構成するか
構成するサーバに設定ファイル・アプリケーションをセットアップする方法を説明します。
EC2
LaunchConfiguration S3
Auto Scaling group
EC2
EC2
• 設定ファイル・アプリケーションはS3に置き、cloud-initのruncmdでインストール
以下を配置・インストール用スクリプト・設定ファイル・アプリケーションのバイナリ
EC2にはS3bucketがRead出来るようIAMInstanceProfile(IAMRole)を設定※実際にはLaunchConfigurationに設定
Cloud-initのruncmdでインストール用スクリプトを実行
#runcommandsruncmd:- aws s3cp s3://xxxx-bucket/install.sh - |bash>/var/log/xxxx-install.log
※「s3://xxxx-bucket/install.sh」にインストール用スクリプトを置く場合インストール用スクリプト内では、以下の処理を実施。①設定ファイル・アプリケーションバイナリをS3からダウンロード②ダウンロードしたファイルを適切なパスに配置③必要なサービスを起動
takemikami’s note– http://takemikami.com/
何をきっかけにScalingするか〜AlarmによるScaling
15Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:何をきっかけにScalingするか
何をきっかけにScalingするか(AlarmによるScaling)について説明します。
CloudWatch
EC2
Auto Scaling group
EC2
EC2
Alarm
監視によるAlarmに応じてScaling
• CloudWatchでAlarmを設定、Alarmに応じてインスタンス数の拡大縮小を実行
※AutoScalingのきっかけとして考えられるAlarmの例:・ELBへのリクエスト数・ELBのLatency・SQSのキューの長さ
takemikami’s note– http://takemikami.com/
何をきっかけにScalingするか〜指定時間でのScaling
16Copyright (C)2016TakeshiMikami.Allrightsreserved.
実現に必要な周辺知識:何をきっかけにScalingするか
何をきっかけにScalingするか(指定時間でのScaling)について説明します。• 指定時間になったらインスタンス数の拡大縮小を実行することも可能
EC2
Auto Scaling group
EC2
EC2指定時間になったらインスタンスを増減
※2016/1/26現在、ManagementConsoleから設定できないようですが。aws-cliの「aws autoscaling put-scheduled-update-group-action」で設定が可能。
トラフィック増が事前に予測可能ならば、Alarmより、指定時間でのScalingの方が扱いやすいと思います。
takemikami’s note– http://takemikami.com/
アプリケーションのデプロイと切り戻し
17Copyright (C)2016TakeshiMikami.Allrightsreserved.
Tips
アプリケーションのデプロイ方法と切り戻し方法について説明します。
• アプリケーションのデプロイ/切り戻しを、新旧のAutoScalingGroupとLaunchConfigurationを用意して実施出来る
• アプリケーションは切り替え前後で以下の状態になる– ①旧アプリケーションが稼働 (切り替え前)– ②新旧アプリケーションが両方稼働 (切り替え中)– ③新アプリケーションが稼働 (切り替え後)
→以降のスライドで切り替えの流れを説明
takemikami’s note– http://takemikami.com/
EC2
EC2
EC2
アプリケーションのデプロイと切り戻し 〜切り替え前
18Copyright (C)2016TakeshiMikami.Allrightsreserved.
Tips
アプリケーションのデプロイ方法と切り戻し方法について説明します。
ELB
EC2Launch
Configuration S3
Auto Scaling group
EC2
EC2Auto Scaling group
LaunchConfiguration S3
切り替え前
①新アプリケーションをビルドし、バイナリをS3に配置
②LaunchConfigurationとAutoScalingGroupを作成
takemikami’s note– http://takemikami.com/
EC2
EC2
EC2
EC2
EC2
アプリケーションのデプロイと切り戻し 〜切り替え中
19Copyright (C)2016TakeshiMikami.Allrightsreserved.
Tips
アプリケーションのデプロイ方法と切り戻し方法について説明します。
ELB
EC2Launch
Configuration S3
Auto Scaling group
Auto Scaling group
LaunchConfiguration S3
切り替え中
新アプリケーションのAutoScalingGroupのEC2インスタンスを起動HealthCheckが通り次第ELBに接続
takemikami’s note– http://takemikami.com/
EC2
EC2
EC2
EC2
EC2
EC2
アプリケーションのデプロイと切り戻し 〜切り替え後
20Copyright (C)2016TakeshiMikami.Allrightsreserved.
Tips
アプリケーションのデプロイ方法と切り戻し方法について説明します。
ELB
LaunchConfiguration S3
Auto Scaling group
Auto Scaling group
LaunchConfiguration S3
切り替え後
旧アプリケーションのAutoScalingGroupのEC2インスタンスを停止
※旧アプリケーションのAutoScalingGroup/LaunchConfigurationを残しておけば切り戻しが可能
takemikami’s note– http://takemikami.com/
EC2
EC2
バッチサーバの安全な減設
• バッチサーバでバッチ実行中はAutoScalingのInstanceProtectionを設定→ScaleIn時にバッチを実行していないインスタンスが停止
21Copyright (C)2016TakeshiMikami.Allrightsreserved.
Tips
バッチサーバの安全な減設方法について説明します。
EC2
Auto Scaling group
バッチ実行中 & InstanceProtection
バッチが動いていない(=InstanceProtectionされていない)インスタンスが停止
バッチ実行中 & InstanceProtection
※デフォルトでInstanceProtectionを設定していない場合は、も費用が安価になるようにインスタンスを選んで停止
takemikami’s note– http://takemikami.com/
まとめ
• AutoScalingでは、以下のことを実現出来る– 障害時にインスタンスを自動で置き換え– 需要に応じてインスタンス数を拡大縮小
• 実際にAutoScalingを使ってサーバを構成する場合は関連するAWSサービスなどの周辺知識が必要
• AutoScalingと周辺機能を利用し、アプリケーションのデプロイ/切り戻しの仕組みを作ることも出来る
22Copyright (C)2016TakeshiMikami.Allrightsreserved.