Aws auto scalingによるwebapサーバbatchサーバの構成例

takemikami’s note – http://takemikami.com/
三上威 (フリーランスITエンジニア) twitter: @takemikami
AWS AutoScalingによる
WebAPサーバ/Batchサーバの構成例
AutoScalingでサーバを構成するために必要な周辺知識
1
AWS AutoScaling
2016.1.26
Copyright (C) 2016 Takeshi Mikami. All rights reserved.

アジェンダ
• 自己紹介
• AWS Auto Scalingとは
• 想定するサーバ構成
• 実現に必要な周辺知識
– どのように処理を分散するか … ELB, SQS
– どこにデータを保持するか… RDS, S3
– どこにログを出力するか… CloudWatch Logs
– どのようにサーバを起動/構成するか… LaunchConfiguration, cloud-init
– 何をきっかけにScalingするか… CloudWatch, Alarm
• Tips
– アプリケーションのデプロイと切り戻し
– バッチサーバの安全な減設
• まとめ
2Copyright (C) 2016 Takeshi Mikami. All rights reserved.

自己紹介
• 三上威 (@takemikami)
• フリーランスITエンジニア
– マーケティングデータ分析基盤のシステム開発運用
• 略歴
– 情報通信ネットワークの研究 @ 甲南大学理学部応用数学科
– Web系システムの開発・構築@ NEC系SIer
– 旅行系ECサイトのマーケティングデータ分析 @ DeNA
• 最近扱っている技術領域
– Spark, Scala, Akka, Hadoop, AWS, Redshift, docker, embulk, fluentd

AWS Auto Scalingとは
EC2のインスタンス群をグループとして管理し、
①障害が生じたノードを検出して自動で置き換え
②需要に応じてインスタンス数を拡大・縮小
を実現するための仕組み
但し、実現するためには、AutoScalingだけで無く、
関連するAWSのサービスなど、周辺知識が必要になります。
EC2
AWSのAutoScalingとは何かについて概要を示します。
Auto Scaling group

Auto Scalingを構成するために考えるべきこと
AWSのAutoScalingを構成するために考えるべきことについて整理します。
考えること関連サービス説明
どのように処理を
分散するか
ELB
SQS
各サーバへのリクエストをどのように分散す
べきか仕組みを検討
どこにデータを保
持するか
RDS
S3
EC2にデータを保持できない(動的に起動/終
了するため)ため、保持先を検討
どこにログを出力
するか
CloudWatch Logs EC2にログを保存できない(動的に起動/終了
するため)ため、出力先を検討
どのようにサーバ
を構成するか
LaunchConfiguration
cloud-init
動的にEC2を起動する際のミドルウェア/アプ
リケーションの構成方法を検討
何をきっかけに
Scalingするか
CloudWatch
Alarm
Scalingする条件を設定

想定するWebAPサーバの構成
想定するサーバ構成
本スライドで想定するWebAPサーバの構成図を示します。
CloudWatch
ELB
EC2
CloudWatch
Logs
Launch
Configuration S3
Auto Scaling group
EC2
EC2
RDS, S3
Alarm
WebAPサーバへの
要求を分散
監視によるAlarm
に応じてScaling
LaunchConfigurationに
よってサーバを構成
CloudWatchLogsに
ログデータを集約
RDS,S3に
データを保持

想定するBatchサーバの構成
想定するサーバ構成
本スライドで想定するBatchサーバの構成図を示します。
CloudWatch
SQS
EC2
CloudWatch
Logs
Launch
Configuration S3
Auto Scaling group
EC2
EC2
RDS, S3
Batchサーバへの
要求をQueueに保持
各EC2からpolling
(実行パラメータはRDS)
CloudWatchLogsに
RDS,S3に
データを保持
LaunchConfigurationに
よってサーバを構成
RDS
Alarm
に応じてScaling

どのように処理を分散するか〜WebAPサーバの場合
実現に必要な周辺知識:どのように処理を分散するか
どのように処理を分散するか(WebAPサーバの場合)について説明します。
ELB
EC2
Auto Scaling group
EC2
EC2
WebAPサーバへの
要求を分散
• ELB(LoadBalancer)で処理を分散
AutoScalingGroupに対応するELBを指定
→(HealthCheck成功後)自動でELBに接続される

どのように処理を分散するか〜Batchサーバの場合
実現に必要な周辺知識:どのように処理を分散するか
どのように処理を分散するか(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投入
実行パラメータ
投入

どこにデータを保持するか
実現に必要な周辺知識:どこにデータを保持するか
どこにデータを保持するかについて説明します。
EC2
Auto Scaling group
EC2
EC2
RDS, S3
RDS,S3に
データを保持
• EC2インスタンスは動的に起動/終了するためデータを保持することは出来ない
→RDSやS3にデータを保持
EC2のDisk上のデータは
インスタンス終了時に消える
データはEC2のDisk上に持たず、
RDSやS3に保存する

どこにログを出力するか
• EC2インスタンスは動的に起動/終了するためログを保存出来ない
→CloudWatch Logsにログを転送
実現に必要な周辺知識:どこにログを出力するか
どこにログを出力するかについて説明します。
EC2
CloudWatch
LogsAuto Scaling group
EC2
EC2
CloudWatchLogsに
EC2のDisk上のデータは
インスタンス終了時に消える
※awslogsパッケージをinstallし、設定ファイルに転送するログファイルを記載すれば転送設定できる。
ログは逐次、
CloudWatchLogsに転送

どのようにサーバを構成するか〜インスタンスのスペック等
実現に必要な周辺知識:どのようにサーバを構成するか
構成するサーバのスペックなどの情報の設定方法を説明します。
EC2
Launch
Configuration
EC2
EC2
Auto Scaling group
• ベースとするAMIやInstanceTypeなどはLaunchConfigurationに設定
設定する主な項目：
・ベースとするAMI
・InstanceType
・SecurityGroup
・BlockDeviceのサイズ

どのようにサーバを構成するか〜インストールするパッケージ
構成するサーバにインストールするパッケージの設定方法を説明します。
EC2
Launch
Configuration
EC2
EC2
Auto Scaling group
• インストールするパッケージの情報は
cloud-initで設定
LaunchConfigurationの
UserDataにcloud-initの
設定を記載
#cloud-config
# user and groups
groups:
- admin
users:
- default
- name: admin
primary-group: admin
groups: wheel
# repository and packages
repo_upgrade: security
packages:
- awslogs
- nginx
cloud-initの例→
・Adminユーザ作成
・awslogs/nginxセットアップ

どのようにサーバを構成するか〜設定ファイル・アプリケーション
構成するサーバに設定ファイル・アプリケーションをセットアップする方法を説明します。
EC2
Launch
Configuration S3
Auto Scaling group
EC2
EC2
• 設定ファイル・アプリケーションはS3に置き、cloud-initのruncmdでインストール
以下を配置
・インストール用スクリプト
・設定ファイル
・アプリケーションのバイナリ
EC2にはS3 bucketがRead出来るよう
IAM InstanceProfile(IAM Role)を設定
※実際にはLaunchConfigurationに設定
Cloud-initのruncmdで
インストール用スクリプトを実行
# run commands
runcmd:
- aws s3 cp s3://xxxx-bucket/install.sh- | bash > /var/log/xxxx-install.log
※「s3://xxxx-bucket/install.sh」にインストール用スクリプトを置く場合
インストール用スクリプト内では、以下の処理を実施。
①設定ファイル・アプリケーションバイナリをS3からダウンロード
②ダウンロードしたファイルを適切なパスに配置
③必要なサービスを起動

何をきっかけにScalingするか〜AlarmによるScaling
実現に必要な周辺知識:何をきっかけにScalingするか
何をきっかけにScalingするか(AlarmによるScaling)について説明します。
CloudWatch
EC2
Auto Scaling group
EC2
EC2
Alarm
に応じてScaling
• CloudWatchでAlarmを設定、Alarmに応じてインスタンス数の拡大縮小を実行
※AutoScalingのきっかけとして考えられるAlarmの例：
・ELBへのリクエスト数
・ELBのLatency
・SQSのキューの長さ

何をきっかけにScalingするか〜指定時間でのScaling
実現に必要な周辺知識:何をきっかけにScalingするか
何をきっかけにScalingするか(指定時間でのScaling)について説明します。
• 指定時間になったらインスタンス数の拡大縮小を実行することも可能
EC2
Auto Scaling group
EC2
EC2
指定時間になったら
インスタンスを増減
※2016/1/26現在、ManagementConsoleから設定でき
ないようですが。
aws-cliの「aws autoscaling put-scheduled-update-
group-action」で設定が可能。
トラフィック増が事前に予測可能ならば、
Alarmより、指定時間でのScalingの方が
扱いやすいと思います。

アプリケーションのデプロイと切り戻し
Tips
アプリケーションのデプロイ方法と切り戻し方法について説明します。
• アプリケーションのデプロイ/切り戻しを、
新旧のAutoScalingGroupとLaunchConfigurationを用意して実施出来る
• アプリケーションは切り替え前後で以下の状態になる
– ①旧アプリケーションが稼働 (切り替え前)
– ②新旧アプリケーションが両方稼働 (切り替え中)
– ③新アプリケーションが稼働 (切り替え後)
→以降のスライドで切り替えの流れを説明

EC2
EC2
EC2
アプリケーションのデプロイと切り戻し〜切り替え前
Tips
ELB
EC2
Launch
Configuration S3
Auto Scaling group
EC2
EC2
Auto Scaling group
Launch
Configuration S3
切り替え前
①新アプリケーションをビルドし、
バイナリをS3に配置
②LaunchConfigurationとAutoScalingGroupを作成

EC2
EC2
EC2
EC2
EC2
アプリケーションのデプロイと切り戻し〜切り替え中
Tips
ELB
EC2
Launch
Configuration S3
Auto Scaling group
Auto Scaling group
Launch
Configuration S3
切り替え中
新アプリケーションのAutoScalingGroupのEC2イン
スタンスを起動
HealthCheckが通り次第ELBに接続

EC2
EC2
EC2
EC2
EC2
EC2
アプリケーションのデプロイと切り戻し〜切り替え後
Tips
ELB
Launch
Configuration S3
Auto Scaling group
Auto Scaling group
Launch
Configuration S3
切り替え後
旧アプリケーションのAutoScalingGroupのEC2インス
タンスを停止
※旧アプリケーションの
AutoScalingGroup/LaunchConfigurationを残しておけ
ば切り戻しが可能

EC2
EC2
バッチサーバの安全な減設
• バッチサーバでバッチ実行中はAutoScalingのInstanceProtectionを設定
→ScaleIn時にバッチを実行していないインスタンスが停止
Tips
バッチサーバの安全な減設方法について説明します。
EC2
Auto Scaling group
バッチ実行中 & InstanceProtection
バッチが動いていない
(=InstanceProtectionされていない)
インスタンスが停止
バッチ実行中 & InstanceProtection
※デフォルトでInstanceProtectionを設定していない場合は、
最も費用が安価になるようにインスタンスを選んで停止

まとめ
• AutoScalingでは、以下のことを実現出来る
– 障害時にインスタンスを自動で置き換え
– 需要に応じてインスタンス数を拡大縮小
• 実際にAutoScalingを使ってサーバを構成する場合は
関連するAWSサービスなどの周辺知識が必要
• AutoScalingと周辺機能を利用し、
アプリケーションのデプロイ/切り戻しの仕組みを作ることも出来
る

Aws auto scalingによるwebapサーバbatchサーバの構成例

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Aws auto scalingによるwebapサーバbatchサーバの構成例

Semelhante a Aws auto scalingによるwebapサーバbatchサーバの構成例 (20)

Mais de Takeshi Mikami

Mais de Takeshi Mikami (20)

Último

Último (10)

Aws auto scalingによるwebapサーバbatchサーバの構成例