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

takemikami’s note– http://takemikami.com/

三上威 (フリーランスITエンジニア)twitter:@takemikami

AWSAutoScalingによるWebAPサーバ/Batchサーバの構成例

AutoScalingでサーバを構成するために必要な周辺知識

1

AWS AutoScaling

2016.1.26

Copyright (C)2016TakeshiMikami.Allrightsreserved.


アジェンダ

• 自己紹介• AWSAutoScalingとは• 想定するサーバ構成• 実現に必要な周辺知識

– どのように処理を分散するか…ELB,SQS– どこにデータを保持するか…RDS,S3– どこにログを出力するか…CloudWatch Logs– どのようにサーバを起動/構成するか…LaunchConfiguration,cloud-init– 何をきっかけにScalingするか…CloudWatch,Alarm

• Tips– アプリケーションのデプロイと切り戻し– バッチサーバの安全な減設

• まとめ

2Copyright (C)2016TakeshiMikami.Allrightsreserved.


自己紹介

• 三上威 (@takemikami)• フリーランスITエンジニア

– マーケティングデータ分析基盤のシステム開発運用• 略歴

– 情報通信ネットワークの研究@甲南大学理学部応用数学科– Web系システムの開発・構築@NEC系SIer– 旅行系ECサイトのマーケティングデータ分析@DeNA

• 近扱っている技術領域– Spark,Scala,Akka,Hadoop,AWS,Redshift,docker,embulk,fluentd



AWSAutoScalingとは

EC2のインスタンス群をグループとして管理し、①障害が生じたノードを検出して自動で置き換え

②需要に応じてインスタンス数を拡大・縮小

を実現するための仕組み

但し、実現するためには、AutoScalingだけで無く、関連するAWSのサービスなど、周辺知識が必要になります。



EC2

AWSのAutoScalingとは何かについて概要を示します。

Auto Scaling group


AutoScalingを構成するために考えるべきこと



AWSのAutoScalingを構成するために考えるべきことについて整理します。

考えること関連サービス説明

どのように処理を分散するか

ELBSQS

各サーバへのリクエストをどのように分散すべきか仕組みを検討

どこにデータを保持するか

RDSS3

EC2にデータを保持できない(動的に起動/終了するため)ため、保持先を検討

どこにログを出力するか

CloudWatch Logs EC2にログを保存できない(動的に起動/終了するため)ため、出力先を検討

どのようにサーバを構成するか

LaunchConfigurationcloud-init

動的にEC2を起動する際のミドルウェア/アプリケーションの構成方法を検討

何をきっかけにScalingするか

CloudWatchAlarm

Scalingする条件を設定


想定するWebAPサーバの構成


想定するサーバ構成

本スライドで想定するWebAPサーバの構成図を示します。

CloudWatch

ELB

EC2

CloudWatchLogs

LaunchConfiguration S3

Auto Scaling group

EC2

EC2

RDS,S3

Alarm

WebAPサーバへの要求を分散

監視によるAlarmに応じてScaling

LaunchConfigurationによってサーバを構成

CloudWatchLogsにログデータを集約

RDS,S3にデータを保持


想定するBatchサーバの構成


想定するサーバ構成

本スライドで想定するBatchサーバの構成図を示します。

CloudWatch

SQS

EC2

CloudWatchLogs


Auto Scaling group

EC2

EC2

RDS,S3

Batchサーバへの要求をQueueに保持各EC2からpolling

(実行パラメータはRDS)


RDS,S3にデータを保持

LaunchConfigurationによってサーバを構成

RDS

Alarm監視による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,S3RDS,S3にデータを保持

• EC2インスタンスは動的に起動/終了するためデータを保持することは出来ない→RDSやS3にデータを保持

EC2のDisk上のデータはインスタンス終了時に消える

データはEC2のDisk上に持たず、RDSやS3に保存する


どこにログを出力するか

• EC2インスタンスは動的に起動/終了するためログを保存出来ない→CloudWatch Logsにログを転送


実現に必要な周辺知識:どこにログを出力するか

どこにログを出力するかについて説明します。

EC2

CloudWatchLogsAuto Scaling group

EC2

EC2


EC2のDisk上のデータはインスタンス終了時に消える

※awslogsパッケージをinstallし、設定ファイルに転送するログファイルを記載すれば転送設定できる。

ログは逐次、CloudWatchLogsに転送


どのようにサーバを構成するか〜インスタンスのスペック等


実現に必要な周辺知識:どのようにサーバを構成するか

構成するサーバのスペックなどの情報の設定方法を説明します。

EC2

LaunchConfiguration

EC2

EC2

Auto Scaling group

• ベースとするAMIやInstanceTypeなどはLaunchConfigurationに設定

設定する主な項目：・ベースとするAMI・InstanceType・SecurityGroup・BlockDeviceのサイズ


どのようにサーバを構成するか〜インストールするパッケージ



構成するサーバにインストールするパッケージの設定方法を説明します。

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セットアップ


どのようにサーバを構成するか〜設定ファイル・アプリケーション



構成するサーバに設定ファイル・アプリケーションをセットアップする方法を説明します。

EC2


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からダウンロード②ダウンロードしたファイルを適切なパスに配置③必要なサービスを起動


何をきっかけにScalingするか〜AlarmによるScaling


実現に必要な周辺知識:何をきっかけにScalingするか

何をきっかけにScalingするか(AlarmによるScaling)について説明します。

CloudWatch

EC2

Auto Scaling group

EC2

EC2

Alarm

監視による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

EC2Launch

Configuration S3

Auto Scaling group

EC2

EC2Auto Scaling group


切り替え前

①新アプリケーションをビルドし、バイナリをS3に配置

②LaunchConfigurationとAutoScalingGroupを作成


EC2

EC2

EC2

EC2

EC2

アプリケーションのデプロイと切り戻し〜切り替え中


Tips


ELB

EC2Launch

Configuration S3

Auto Scaling group

Auto Scaling group


切り替え中

新アプリケーションのAutoScalingGroupのEC2インスタンスを起動HealthCheckが通り次第ELBに接続


EC2

EC2

EC2

EC2

EC2

EC2

アプリケーションのデプロイと切り戻し〜切り替え後


Tips


ELB


Auto Scaling group

Auto Scaling group


切り替え後

旧アプリケーションの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サーバの構成例

Technology