AWSのAutoScalingでインスタンスを起動する際にコマンドを実行したい

タイトルの通り、AWSのAutoScalingでスケールアウトさせる際に、起動するインスタンス上でコマンドを実行したい場合についてです。
インスタンスを起動する際に、ソースコードを最新にしたいとか、webサーバーのプロセスを立ち上げたいと言う時ありますよね。
以下の前提のもと、ここでは最もシンプルであろうという方法を記載していきます。

前提

  • 既に利用可能なAMIを作成済み
  • AutoScalingグループも作成済み
  • ブラウザ上のマネジメントコンソールから設定

では、AWSのEC2サービスの中の起動設定の作成を行います。
1.AMIの選択、2.インスタンスタイプの選択を済ませ、3.詳細設定まで進みます。

スクリーンショット 2017-08-16 0.28.36.png

ここのユーザーデータの項目にインスタンス起動時に渡してあげたいコマンドを記載すればOKです。
気を付けなければいけない点は

  • 渡されたコマンドはrootユーザーとして実行される
  • インタラクティブな操作をコマンドの実行途中ではさむようなものは実行できない

です。
このユーザーデータのテキストボックス内に下記のような感じで記述してしまえば完了です。

#!/bin/bash
cd /path/to/myproject
sudo -u ec2-user /usr/bin/git pull origin master
sudo -u ec2-user /usr/local/bin/gunicorn myproject.wsgi -D

ユーザーデータは様々な形式で渡せるようです
https://cloudinit.readthedocs.io/en/latest/topics/format.html

続きを読む

dynamodb-autoscaling検証

概要

先日のアップデートでdynamodbでautoscalingの機能が実装されました。
https://aws.amazon.com/jp/blogs/news/new-auto-scaling-for-amazon-dynamodb/

NoSQLデータベースのベンチマークツールであるycsbを用いてdynamodb-autoscalingの動作を検証できます。
今回は新規に追加された項目「ターゲット使用率」がどのような影響を及ぼすかについて検証します。

環境準備

環境準備に伴い、下記を参考にさせていただきました。

http://qiita.com/noralife/items/35a956f682b1aca475f6
http://dev.classmethod.jp/cloud/aws/attack_to_dynamodb_using_ycsb/
http://imai-factory.hatenablog.com/entry/2013/04/05/010858

amazon linux version

[ec2-user@dynamo-ec2 ycsb-0.12.0]$ cat /etc/system-release
Amazon Linux AMI release 2017.03

openjdk-develインストール

$ sudo yum -y install java-1.7.0-openjdk-devel

ycsb導入

・ダウンロード
$ wget https://github.com/brianfrankcooper/YCSB/releases/download/0.12.0/ycsb-0.12.0.tar.gz

・展開、移動
$ tar xfz ycsb-0.12.0.tar.gz
$ cd ycsb-0.12.0/

・ファイル用のディレクトリ準備
$ mkdir -p dynamodb/conf/

・ベンチマーク対象テーブル(testtable)のプライマリキーを確認しておく
$ aws dynamodb describe-table --table-name testtable | jq -r '.Table.AttributeDefinitions[].AttributeName'
name

YCSB概要

テストデータをdynamodbに読み込ませて

./bin/ycsb.sh load dynamodb -P workloads/dyamodb -P dynamodb/conf/dynamodb.properties

テストデータを使って負荷をかける。

./bin/ycsb.sh run dynamodb -P workloads/dyamodb -P dynamodb/conf/dynamodb.properties

設定ファイルは下記の3つ

■dynamodb/conf/dynamodb.properties
対象のDynamoDBの情報を設定。変更する部分はプライマリキーくらいかと。
クレデンシャル情報が記載されたファイルもこの中で指定する。

$ cat dynamodb/conf/dynamodb.properties
dynamodb.awsCredentialsFile = dynamodb/conf/AWSCredentials.properties
dynamodb.primaryKey = name
dynamodb.endpoint = http://dynamodb.ap-northeast-1.amazonaws.com

■dynamodb/conf/AWSCredentials.properties
クレデンシャル情報を記載。

$ cat dynamodb/conf/AWSCredentials.properties
accessKey = XXXXXXXXXXXXXXXXXXXX
secretKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

■workloads/(任意のファイル名)
投入するデータ、実施するベンチマークのステータスを設定。
値はテンプレートworkloads/workload_templateを参考。
※operationcountは1,000,000以上が良いかと。10,000で実行したらスケーリングする前に終わってしまいました……

$ cat workloads/dyamodb
workload=com.yahoo.ycsb.workloads.CoreWorkload #デフォルト

recordcount=1000 #テーブルにセットするレコード数
operationcount=2000000 #load時のオペレーション数

insertstart=0 #デフォルト
fieldcount=10 #フィールド数、デフォルト
fieldlength=100 #レコードの長さ、デフォルト

readallfields=true #デフォルト
writeallfields=false #デフォルト

table=testtable #テーブル名

fieldlengthdistribution=constant #デフォルト

#load時のオペレーション比率(read80%, update15%, insert5%)
readproportion=0.8
updateproportion=0.15
insertproportion=0.05

#以下テンプレートの値のまま設定
readmodifywriteproportion=0
scanproportion=0
maxscanlength=1000
scanlengthdistribution=uniform
insertorder=hashed
requestdistribution=zipfian
hotspotdatafraction=0.2
hotspotopnfraction=0.8

measurementtype=histogram
histogram.buckets=1000
timeseries.granularity=1000

検証開始

初期のdynamodbキャパシティ設定

1000レコード書き込むので、書き込み容量ユニット(以下WCU)を10確保。
WCU1だとスロットルが発生して時間がかかります……。

初期設定.PNG

テーブルにテストデータを読み込ませる

1回だけ。10分ほどかかります。

$ ./bin/ycsb.sh load dynamodb -P workloads/dyamodb -P dynamodb/conf/dynamodb.properties

auto-scaling設定

いよいよauto-scaling設定です。
RCU/WCUを下げるオペレーションは最大9回/日になっていますが条件があります。
↓の記事を参考にさせていただきました。
http://qiita.com/mokrai/items/6864b8a723a2728565fc
検証する場合は無駄に下げないように初期値を考慮しましょう。

as1.PNG

・ターゲット使用率
スケーリングの基準になる値です。以降で検証します。

・IAMロール
[新しいロール]を選択すれば問題ありません。
下記の管理ポリシーが付与されたロールが作成されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeTable",
                "dynamodb:UpdateTable",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:DescribeAlarms",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:SetAlarmState",
                "cloudwatch:DeleteAlarms"
            ],
            "Resource": "*"
        }
    ]
}

ロールからもわかるように、auto-scalingはcloudwatchの値を評価の基準としています。
auto-scaling設定中は動的なcloudwatchメトリクスが作成され、auto-scaling設定解除後に削除されます。

ターゲット使用率70%の場合

下記設定でcloudwatchの推移を確認します。

auto-scaling設定 RCU WCU
ターゲット使用率(%) 70 70
min(ユニット) 10 10
max(ユニット) 10000 10000

キャパシティの推移

推移は下記の通り

RCU
70rcu.PNG

WCU
70wcu.PNG

ターゲット使用率20%の場合

下記設定でcloudwatchの推移を確認します。

auto-scaling設定 RCU WCU
ターゲット使用率(%) 20 20
min(ユニット) 10 10
max(ユニット) 10000 10000

20rcu.PNG

20wcu.PNG

終わりに

負荷のかけ方が一定の場合はキャパシティーの増減が安定したら変化しないので、
そのあたりの調整が必要だと感じました。
cloudwatchメトリクスが動的な値で作成され、それらが基準になってスケーリングされています。
サポートに確認したところ、閾値を超えてのキャパシティ設定もできるとのことですが、その場合は次のタイミングでスケーリングされてしまうとのことです(未検証)。

続きを読む

terraformでASGを作る時の注意点

概要

起動設定を更新した際に相関関係にあるASGで起動しているインスタンスが作り直されてしまうので、これを回避する。

方法

EC2Resourcesaws_launch_configurationを使用時、引数にnameではなく name_prefixを使用する。

launch_configuration.tf
resource "aws_launch_configuration" xxxxxxxx-autoscaling-conf" {
  name_prefix                 = "xxxxxxxx-autoscaling"
  image_id                    = "ami-xxxxx"
  instance_type               = "t2.medium"
  iam_instance_profile        = "xxxxxxxx"
  key_name                    = "xxxxxxxx"
  security_groups             = ["sg-xxxxxxxx"]
  associate_public_ip_address = true
  user_data                   = "${file("xxxxxxxx.sh")}"
  root_block_device  {
    volume_type           = "gp2"
    volume_size           = "50"
    delete_on_termination = "true"
  }
  lifecycle  {
    create_before_destroy = true
  }
}
  • IDのみがユニークなものに置換され、ASGは影響を受けない
aws_launch_configuration.xxxxxxxx-autoscaling-autoscaling-conf:
  id = xxxxxxxx-autoscalingxxxxxxxxxxxxxxxx

続きを読む

ターゲットトラッキングポリシーを利用した、EC2のオートスケール設定を実施してみた

はじめに AWSチームのすずきです。 2017年7月のアップデートにより、「ターゲットトラッキングポリシー」を利用したEC2のオートスケール設定が可能になりました。 新機能 – EC2 Auto Scalingのターゲッ […] 続きを読む

AutoScaleを設定し、lambdaでAMIとAutoScaleの設定を自動更新する

今回はAuto Scaleの設定のまとめです。

・概要

負荷分散のためにAutoScaleを検討することはよくあることです。

ゲームのイベントなどでは負荷がかかる時間帯が決まっているので、常時起動しているサーバーを減らしAutoScaleのスケージュールで設定することで費用を抑えることが出来ます。

※AutoScaleは起動に時間がかかるので、スケーリングポリシーでは突発的な負荷に対応できないのでスケジュールを使っています。

・問題点

AutoScaleを設定した場合、設定しているAMIのassetやsourceが起動中のインスタンスと違うといった事が起こります。

そういった場合にAMIを更新し、自動的AutoScaleに割り当てる設定を行います。

・AutoScaleグループの作成

今回の設定は元々あるAutoScaleグループの設定を置き換えるので先にAutoScaleグループを作成しておきます。

・AWSコンソールの[AUTO SCALING]→[起動設定]→[起動の作成]

※ここの起動設定は最終的に使わないので適当でOKです

・AWSコンソールの[AUTO SCALING]→[AUTO SCALINGグループ]→[AUTO SCALINGグループの作成]

上記の起動設定を選択、下記を設定

ネットワーク
グループ名
ロードバランシング

※今回はスケジュールなのでスケーリングポリシーは設定しない
※通知を使用するとauto scaleの情報をlambda等に引き渡して色々出来ます。
※タグを使いauto scaleで作成されたインスタンスに適用できます。

※ここで作成したAUTO SCALINGグループの名前を控えておきます。

lambdaを設定

・[Blank Function]→リストから[CloudWatch Events]を選択
・ルール:新規のルール
・ルール名:任意
・ルール説明:任意
・ルールタイプ:スケジュール
・スケジュール式:cron(0 * * * ? *)
※cronの設定と同じ、上記は1時間毎
・トリガーの有効化にチェック

・名前:任意
・説明:任意
・ランタイム:python

・ロール:[カスタムロールの作成]を選択、IAMに下記をアタッチし作成、再度[既存のロールを選択]で作成したIAMを選択

・コード:下記を貼り付けて***の部分を自分の環境に置き換える

import boto3
import time
from botocore.client import ClientError
from datetime import datetime, timedelta, tzinfo
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)

ec2 = boto3.client('ec2')
autoscaling = boto3.client('autoscaling')

instance = "***" #コピー元のec2インスタンスID(例:i-22a9edc2ted27d2a1)
device_name = "***" #コピー元のec2のブロックデバイス(例:/dev/sda1)
image_prefix = "***" #amiの名前の識別子(任意※他のAMIで使っていない文字)
launch_prefix = "***" #auto scaleの起動設定の名前の識別子(任意※他の起動設定で使っていない文字)
ec2_volume_size = *** #ebsのボリュームサイズ(単位:GB)
ec2_volume_type = "***" #ebsのボリュームタイプ(例:gp2)
secrity_group = [***] #ec2インスタンスのセキュリティグループ
ec2_instance_type = "***", #ec2インスタンスタイプ(例:c4.2xlarge)
ec2_key_name = "***", #ec2インスタンスのキーペア名
auto_scaling_group_name ="***",#作成したAutoScaleGroup名


def lambda_handler(event, context):
    try:
        dstr = datetime.now().strftime('_%Y-%m-%d-%H-%M-%S_') + instance
        logger.warning("create ami:%s" % (dstr))
        new_ami = ec2.create_image(Name=image_prefix + dstr ,InstanceId=instance,NoReboot=True,DryRun=False)
        recv = ec2.describe_images(Owners=['self'])
        list=[]
        target = image_prefix
        for img in recv['Images']:
            if target in img['ImageLocation']:
                list.append(img)
        s_list = sorted(list,key=lambda h: h['CreationDate'])
        if len(s_list) > 0:
            del_target = s_list[0]
            logger.info("delete ami:%s" % (del_target['Name']))
            ec2.deregister_image(ImageId=del_target['ImageId'],DryRun= False)
        dstr = datetime.now().strftime('_%Y-%m-%d-%H-%M-%S')
        logger.info("create auto scale launch config:%s" % (dstr))
        device = {}
        device['DeviceName'] = device_name
        ebs = {}
        ebs['VolumeSize'] = ec2_volume_size
        ebs['VolumeType'] = ec2_volume_type
        ebs['DeleteOnTermination'] = True
        device['Ebs'] = ebs
        device_mapping = [device]
        launch_name = launch_prefix + dstr

        res = autoscaling.create_launch_configuration(
            LaunchConfigurationName = launch_name,
            ImageId = new_ami['ImageId'],
            InstanceType = ec2_instance_type,
            SecurityGroups = secrity_group, 
            KeyName = ec2_key_name,
            BlockDeviceMappings = device_mapping,
            AssociatePublicIpAddress = True
        );
        logger.info("update auto scale group name:%s" % (launch_name))
        res = autoscaling.update_auto_scaling_group(
            AutoScalingGroupName=auto_scaling_group_name 
            LaunchConfigurationName = launch_name
        );  
        target = launch_prefix
        recv = autoscaling.describe_launch_configurations()
        list=[]
        for launch in recv['LaunchConfigurations']:
            if target in launch['LaunchConfigurationName']:
                list.append(launch)
        s_list = sorted(list,key=lambda h: h['CreatedTime'])
        if len(s_list) > 2:
            del_target = s_list[0]
            logger.info("delete launch config:%s" % (del_target['LaunchConfigurationName']))
            autoscaling.delete_launch_configuration(
                LaunchConfigurationName=del_target['LaunchConfigurationName'],
            )
        logger.info("end ami update")

    except ClientError as e:
        logger.error( e )
    return 'end'

・auto scaleのスケジュールを登録する

負荷の時間に合わせて自由に

・注意事項

※最初はelbのhealthチェックだけじゃなくwebサーバーのログやawsコンソールで正常な起動を確認すること

※デプロイがAMIの更新と被らないようにすること

続きを読む

実務経験がなくても2ヶ月でAWSソリューションアーキテクトに合格するためにやったこと

ゴールデンウィークくらいからAWSを趣味で触り始めてちょっと面白そうだったので、ソリューションアーキテクトの試験を受けてみようかと思い立ちました。
2017年7月12日になんとかギリギリ69%で合格できていたのでどういう風に勉強していったのかを残してみます。
なお、Qiitaには初投稿になります。

まずAWSに触り始める前事の自分自身の知識としては

  • 普段はエンプラ系の製品開発に従事
  • IPAのネットワークスペシャリストとデータベーススペシャリストを保持
  • AWSの主要サービスがなんなのかくらいはうっすらとわかる
  • たまにAWS関連のニュースを見てる
  • 実務でのAWSの経験は今まで全くない(そしてこれからもなさそう…

という感じでした。

自分としてはネットワークやデータベース周りの基本的な知識はある方だと思っています。
しかし、実際のお仕事ではクラウドのクの字にもかすりもしない、全く縁がない分野の人間です。

また、平日はあまり勉強することはなく(Evernoteに記録したノートを読み返す程度)、主に土日のみ勉強していました。実際には休みの日に4~5時間程度だったと思います。

アカウントを作成する

なにはともあれまずは無料枠を全力で駆使するためにアカウントを作成しました。とはいえ最初は何からやって良いのかわからないので、ざっとチュートリアルを触ってみました。

AWS 10分間チュートリアル

ほんとに10分だけでいろいろと体験できるのでありがたいです。
チュートリアルでは途中でつまづくことものほぼありませんでした。
チュートリアルとしてはとても役に立ったと思います。

試験ガイドを見てみる

AWSソリューションアーキテクトの右側にある試験ガイドのダウンロードからダウンロードして試験の範囲などを確認しました。特に製品名が明示的に書かれているものは重点的勉強する必要があると感じました。

セキュリティの基本的な考え方を知る

セキュリティプロセスの概要を読んで共有責任モデルを始めとする考え方を知っておきます。ページ数が結構あります。

サンプル問題をやってみる

AWS 認定ソリューションアーキテクト – アソシエイトの右側にある[サンプル問題のダウンロード]からダウンロードして解いて見ました。最初には全然わかりませんでした…

AWSのドキュメントを見てみる

基本的には勉強といってもAWS ドキュメントをひたすら読むということが大半でした。あとはAWS用語集も割と目を通しました。
さらに、AWSクラウド活用資料集も必要そうな製品のものについては一通り目を通しました(その内リンク切れしそう…)。
また、よくある質問は確実に目を通しておいたほうが良いと思います(特にページの上の方にある質問。下の方はより細かい質問に対する解答になっている気がしてあまり読みませんでした)。
以下のドキュメントはだいたい目を通しましたが、応用っぽい使い方などについてはあまり深追いはしませんでした。

重要そうな項目や説明はEvernoteの方に残してマーカなどで印をつけていきました(上記だけでも結構な分量になりました)。
上記の製品をいかに組み合わせて問題を解決するのかといった視点が重要になるようです。

AWS Summit 2017に参加してみる

1日だけでしたが、入門系のセッションだけ参加してきた。過去の分も含めて後からPDFでも動画でも確認できるのは非常にありがたいです。モチベーションも上がりました。

AWS Summit Tokyo 2017 セッション資料・動画一覧

また参加していて思ったこととしては、最新情報はある程度キャッチアップしておく必要があると思いました。例えば、「既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました」のように、今までできていなかったものができるようになったのはよくチェックした方が良いと思います。

書籍関連

書籍としては以下のものを読んで、その内のいくつかは実際に書籍の従って動かしてみたりもしました。
たまたまKindle版が半額になっていたものやポイントが多かったりすることもあって購入もしています(運が良かった…)。
購入していないものは図書館で借りて2週間(図書館の期限が2週間なので)で隅から隅まで熟読してました。
実務経験がない以上、とにかく手を動かしていくことが重要だと考えました。

いろいろなリンクを回ってみる

クラスメソッドさんのブログは情報も早くてよく見てました。他にもAWS公式ブログやqiitaの記事なども目を通していました。特にQiitaのソリューションアーキテクトに合格した系の記事は大変参考に、かつモチベーションの維持に効果がありました!

Amazon Web Services ブログ
Developers.IO
Qiita -ソリューションアーキテクト-

また、以下のサイトでは実際に試験のような問題を解くことができます。有料なところもあるので、やるかどうかは自己判断になります。

AWS Web問題集で学習しよう

あまり深く勉強しないものを知っておく

「この製品はなんですか?」「この製品で何ができますか?」くらいの知識でも大丈夫そうなものについては、あまり深く勉強しないようにしました。例えばRedShiftやKinesis、OpsWorkなどがそれに当たるかと思います。
また、SDKやコマンドラインツールなどについては範囲外だと思うので一切見ていません。

模擬試験を受けてみる

1週間前くらいに模擬試験を受けてみた結果、70%でした。
模擬試験は本試験の半分くらいのボリュームでしたが、それでも結構難しく感じました。
マークをつけることで後から見直すことができるので、ちょっとでも不安な問題にはマークをつけて復習できるようにメモっておきました(試験が終わると問題文などに確認はできなくなります)。
この時点ではちょっとまだ本番に自信がなかったので、ここから本試験まではあまり手を動かさずに、ここまで勉強したことの復習をメインに、Evenoteを読み返したりドキュメントの再確認をやり始めました(この時点で書籍はほぼ読了済みの状態)。

実際の試験のときの心構え

試験は午前中にして朝早めにおきて、現地には早めにいき近くの喫茶店で最終確認をしておきました。
本試験では、とにかく問題文をしっかりと読むこと大切だと感じました。
また、ちょっと引っ掛けのようなものも混じっていたりして、うろ覚えではなくキチンと理解することが重要だと感じました。

最後までやってみたところで時間は結構余ったので、読み返しに結構時間が使えました。
採点結果としては実務経験がないこともあって、トラブルシューティングの得点はやはりよくありませんでした(なんと33%…)。
ここはやはり経験が生きるところなのだと思いますが、ドキュメントのトラブルシューティングをもっと読み込んでおけば良かったと後悔しています。

今後

趣味で終わらせるには勿体無い分野だと思うので、クラウド絡みのお仕事したいけど今のところじゃまずそんな仕事はないという…
でもプロフェッショナルもいずれはとってみたいので、やはり実務経験が欲しいところです。

続きを読む

【お知らせ】1クリックで毎日スナップショットを自動取得 〜 ソンナコトモアロウカト v1.5 リリース

はじめに こんにちは植木和樹@上越妙高オフィスです。 このエントリは『アドベントカレンダー2013:AWS CloudFormationビッグバンテンプレート』14日目でご紹介した『毎日定時刻にEC2スナップショットを自 […] 続きを読む

AWS CodeDeploy の Auto Scaling対応

以前、 AWS CodeDeployを使ってPHPアプリケーションをデプロイしてみた
という記事でAWS CodeDeployの一連の流れについてまとめましたが、
今回はAWS CodeDeployをAuto Scalingと連動させてみようと思います。

Auto Scaling is 何?

Auto Scalingとは、ざっくりいうとCPU使用率などの閾値や、あらかじめ指定したスケジュール等に起因してインスタンス数を自動的に増減する仕組みの事です。

Auto Scaling対応のデプロイ

Auto Scalingに対応したデプロイを実現するためには、

A: Auto Scaling起動時のAMIを、常に最新ソースコードがデプロイ済みのものになるよう管理する
B: Auto Scalingによって起動されたインスタンスに対して、起動時に最新のソースコードが自動でデプロイされるようにする

等の仕掛けが必要となります。

A の場合、日々の運用の手間が増える事となります(デプロイイベントをフックして、Packer等でAMI化とAuto Scallingの起動設定修正を自動化する等しとかないと辛い)。
B の場合、自前でデプロイ処理を書いて起動時に呼び出す。または CodeDeployを利用する等の方法が考えられます。

CodeDeployでやる場合

CodeDeployでやる場合、以前紹介したEC2に指定したタグを元にデプロイ対象を特定する方法でやろうとすると、

  • 新規起動したデプロイ対象のインスタンスだけを対象とするタグを付与する必要がある
  • 複数インスタンスが同時に起動されることを考慮すると、2重でcodedeployを起動できなくする排他制御を入れる または インスタンス毎に単一のタグが振られるようにする必要がある

など考慮する必要があり、とても面倒な事が予想されます。
そこでCodeDeployでは別の方法として

AWS CodeDeployをタグではなくAuto Scalingと連動させるという方法を取ることができます。

AutoScalingと連動させることにより、新規起動したインスタンスだけを対象に最新のソースを自動でデプロイしてくれるようになります(*1)。

Q: AWS CodeDeploy は Auto Scaling とどのように連動しますか?
Auto Scaling Group をデプロイグループと関連付けることで、新しく開始したインスタンスに常にアプリケーションの最新のリビジョンがデプロイされるようにできます。Auto Scaling Group に新しい Amazon EC2 インスタンスが追加されるたびに、まず状態が Pending になり、前回デプロイグループで成功したリビジョンのデプロイが新しい Amazon EC2 インスタンスに対して開始されます。デプロイが正常に完了すると、Amazon EC2 インスタンスの状態が InService に変更されます。デプロイに失敗した場合、その Amazon EC2 インスタンスは終了し、新しい Amazon EC2 インスタンスが Pending の状態で開始されます。その後新しい Amazon EC2 インスタンスに対してデプロイが開始されます。

AWS Codedeployのよくある質問より引用

CodeDeployのAuto Scaling対応

細かい部分はほぼ前エントリと同じなので割愛し、変更点のみを記載します。

Auto Scalingの設定

事前にデプロイ対象のAuto Scalingグループと起動設定を作成しておきます。
ググればたくさん情報が出てくるので詳細は割愛します。

CodeDeployの設定

基本的には前エントリの設定と同じなので、変更点のみを記述します。
インスタンスの追加時に、タグタイプを Amazon EC2 ではなく Auto Scaling group にします。

c40f30f3-ef4f-62a3-59e8-24d736cbce09.png

これだけ!とても簡単ですね!

これで手動デプロイ対象が、オートスケールにより起動中のインスタンス全てとなり、
オートスケールによりインスタンス数が増えた際は、新規インスタンスに対してのみ自動的にデプロイが実行されるようになります。
※新規インスタンスに対して自動デプロイを成功させる為には、最低1回手動デプロイを実行しておく必要があります。

まとめ

オートスケール対応のデプロイはCodeDeployを使うことでとても簡単に実現できますね!
CodeDeployを使って快適なDeployライフをお楽しみください!

続きを読む

AmazonECRとEC2を使って手元でビルドしたDockerイメージをAWS上でサクッと動かす

ECR(EC2 Container Registry)に登録したDockerイメージをEC2上でコンテナとして起動するまでの一通りの流れを書いてみた
ECSも一通り検証終わっていて、サービスではそちらを使う予定だが、基礎を振り返るという意味でのまとめ。

Docker

ここ一ヶ月ひたすらdockerを触っているが、やはり手元の開発環境で動いたものが、別の環境でそのまま動くというのは他にないメリット。
これまでだと、開発環境でOK→STでまた一から作る→本番でも同じくみたいなことしてたけど、ホスト側にDockerエンジン入れるだけで、実際のプロセスは開発環境のものをそのまま移植出来るというところはかなり熱い。といった印象。

やること

  • ECRを使う準備
  • ECRへのDockerイメージの登録
  • EC2作成
  • EC2上にECRからpullしたDockerコンテナを立てる

ECRとは

正式名称 EC2 Container Registry
Amazonが提供するフルマネージドのDockerコンテナレジストリ。
Dockerイメージを管理して、ECS(EC2 Container Service)やEB(Elastic Beanstalk)に簡単にデプロイすることが出来るソリューション

ECR使うと何がうれしい

  • EC2インスタンスにIAMroleを付与するだけ、EC2側で面倒な認証をせずにdockerイメージを使える
  • S3がバックエンドなので、可用性高い
  • 自動的に暗号化されたり、https通信されるのでセキュリティも安心

ECRを使う準備(ローカルマシンで実施)

AWS Command Line Interface のインストール を参考にAWS CLIを手元のマシンにインストールしておく。

基本的には、AWS CLIで操作する。

1.リポジトリの作成&確認

$aws ecr create-repository --repository-name tst-shnagai
{
    "repository": {
        "registryId": "xxxxx",
        "repositoryName": "tst-shnagai",
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxx:repository/tst-shnagai",
        "createdAt": 1496229520.0,
        "repositoryUri": "xxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai"
    }
}

リポジトリは、GUIから見ると、ECSサービスの中の[リポジトリ]に出来る

Amazon_EC2_Container_Service.png

2.ecrにログイン

セッションは12時間なので、感覚的に翌日には切れてる感じ。

## これで一発

$ $(aws ecr get-login --region ap-northeast-1)
Flag --email has been deprecated, will be removed in 17.06.
Login Succeeded

## $()の式展開を使わない場合

$ aws ecr get-login --region ap-northeast-1
docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
### 標準出力の結果を貼り付けてログイン
$ docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
Login Succeeded

ECRへのDockerイメージの登録(ローカルマシンで実施)

手元にある何かしらのDockerイメージをECRにpushする手順
手元で、Dockerイメージに対して、ECR用のタグづけを行ってから、ECRにpushする

1.docker tagコマンドでタグづけをする

今回は例として元々手元にある[apache_td]というdockerイメージに対して、ECRのルールに沿った名前でタグ付け(aliasつけるようなもの)する

## 元々のイメージ
$ docker image list |grep apache_td
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

## タグ付けを実施
$ docker tag apache_td:latest  xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## imageIDは変わらないので、下記のような検索するとapache_tdがECRに対応したイメージとしてタグ付けされたことがわかる
$ docker image list |grep 2c42dd
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai     latest              2c42dd3f5e5c        13 days ago         1.4GB
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

2. 1でタグづけしたDockerImageをECRにpushする

$ docker push xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
The push refers to a repository [xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai]
47d1cbb6b480: Layer already exists
...
latest: digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1 size: 2411

GUIで、タグ名とプッシュされた日時を確認して無事イメージがアップされていることを確認する

Amazon_EC2_Container_Service.png

ここまでで、ECRへのDockerイメージの登録は完了!!

EC2インスタンスの作成

1.通常通りEC2インスタンスを作成する(OSはデフォルトでawscliが入っているamazon linuxだと楽)

ポイントは、IAMRoleに[AmazonEC2ContainerRegistryReadOnly]ポリシを付与しておくことのみ

IAM_Management_Console.png

2. dockerのインストール

AWSの公式ドキュメントに沿ってやるだけなので、コマンドだけ羅列
Docker のインストール

ec2-userでdockerコマンドがsudoなしでうてるとこまでやっておく。

$ sudo yum update -y
$ sudo yum install -y docker
$ sudo service docker start
### ec2-userでsudoなしでdockerコマンドを打てるようにするため
$ sudo usermod -a -G docker ec2-user
###再ログイン
$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce

EC2上にECRからpullしたDockerコンテナを立てる(EC2上で実施)

1. ECRへのログイン

IAMRoleがついていない場合は、ログインで弾かれる

$ $(aws ecr get-login --region ap-northeast-1)
Login Succeeded

2. ECRからDockerイメージをpullする

## ECRにアップロードしたイメージをpull
$ docker pull xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
latest: Pulling from tst-shnagai
996fe98f55d8: Pull complete
...
e6b377ddca6e: Pull complete
Digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1
Status: Downloaded newer image for xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## 手元のイメージとして登録されたことを確認
$ docker image ls
REPOSITORY                                                      TAG                 IMAGE ID            CREATED             SIZE
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai   latest              2c42dd3f5e5c        13 days ago         1.4 GB

3. dockerコンテナを起動する

pullしてきたイメージからコンテナを起動する

## ホストの8080ポートにマッピングするtestという名前のコンテナを起動する
$ docker run -d --name test -p 8080:80 xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
dbbb74b6ebe95666d356250de8310c19403078f53e020069e9a6d10e479b2873

## -lオプションで最後に起動したコンテナを表示
$ docker ps -l
CONTAINER ID        IMAGE                                                                  COMMAND                  CREATED             STATUS              PORTS                  NAMES
dbbb74b6ebe9        xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest   "/bin/sh -c '/bin/..."   4 seconds ago       Up 4 seconds        0.0.0.0:8080->80/tcp   test

## 動作確認として、ホストの8080に対してcurlでリクエストしてみる
$ curl localhost:8080
version 1.2

まとめ

オーソドックスな、AWSでECRを使ってdockerコンテナを起動する一通りの流れをやってみた。dockerを手元で触ってる人だったら、特に躓くことなくやれる内容だと思う。
ECSは、基本オペレーション(この投稿でいうEC2以降の話)を抽象化して、クラスタというEC2集合体の上で、ELB,AutoScaling等を付加して使えるサービスなので、ココら辺をちゃんと理解してやるとやらないでは進みがだいぶ違うという印象を受ける。
裏で何が行われてるのかなという道理を理解することは大事。

続きを読む

AWS Summit Tokyo 2017 参加レポート Day3 (6/1)

会社の外部研修として『AWS Summit Tokyo 2017』に6月1日(木)~2日(金)の計2日間参加して来ました。

当エントリでは6月1日(Day3)に聴講した内容をレポートします。(Day4のレポートはこちら
※注)記事には個人的なメモや感想が含まれています。予めご承知ください。


基調講演(Key Note) (10:00 ~ 11:30)

ホストトーク:オープニング

by Werner Vogels 氏 (Amazon.com CTO)

  • AWSは急速に成長している

    • 成長率はIT企業の中でもTOP
    • 毎月のユーザー増加数 = 日本では10万以上
    • 各国のリージョン、AZ、エッジロケーションも随時拡大中
  • 本イベントを通してAWSを色々学んで行って欲しい。

気になったワードメモ

  • AWS Activate
  • One Amazon
  • Osaka リージョン開始

ゲストトーク:株式会社ソラコム

by 安川 健太 氏 (株式会社ソラコム 最高技術責任者)

SORACOMのサービス展開

IoTはネットワークセキュリティが課題
>3G/LTE網でInternetに出ないIoTネットワーク(デバイスとクラウドの直接接続)を提供

SORACOM Funnel
>デバイスからクラウドへのデータ転送を疎結合に管理
 利用例:デバイス>Funnel>Kinesis>Lambda>AWS IoT
  ⇒Funnelから先の切り替え(=新サービス追加など)が容易

ホストトーク:AWS – SUPER POWERS 1

by Werner Vogels 氏 (Amazon.com CTO)

「AWSは開発者に『SUPER POWERS※』を与える。」 (※ネタ元:スーパーマン)

SUPER POWER – ‘SPEED’ (超音速)

  • EC2新インスタンス:F1(FPGA利用可)
  • 今の時代 検索は必須>Elastic Search等ですぐに実装可
  • CloudはInfraへの関心を省き、Productに集中させてくれる>開発を加速
  • AWSは色々な選択肢を提供>ビジネスに合わせて適切なものを

ゲストトーク:NTT東日本

by 中村 浩 氏 (東日本電信電話株式会社 取締役)

CloudGateway re:connect
>FLETS光の高速・閉域網でAWSと再接続

社内で開発・利用して便利だったものを社外にも利用してほしい
クラウドと企業間の距離が一番近い国に

ホストトーク:AWS – SUPER POWERS 2

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘INVISIBILITY’ (目に見えない)

⇒開発者がインフラを気にしなくていい ⇒サーバーレス機能群紹介

  • AWS Lambda

    • サーバーレスコンピュート
  • AWS Step Functions
    • ビジュアルワークフローで分散アプリケーションのコンポーネント管理
  • AWS X-Ray
    • 分散アプリケーションの分析とデバッグ
  • Amazon DynamoDB Accelerator(DAX) :new:
    • 完全マネージド型インメモリキャッシュクラスタでクエリ超高速化

ゲストトーク:ソニーモバイルコミュニケーションズ

by 川西 泉 氏 (ソニーモバイルコミュニケーションズ株式会社 取締役 EVP)

SonyモバイルのIoTへの取り組み:『カーリングビジネスの実現』

製品紹介
– XPERIA Ear
– XPERIA Touch
– XPERIA Agent
  >http://av.watch.impress.co.jp/docs/news/1018278.html

スマートホームシステム
 AWS IoTを活用
 製品例:自宅のLED照明>センサーで子供の帰宅感知>仕事(外出)中の親に通知>LED付属のスピーカで会話

ホストトーク:AWS – SUPER POWERS 3

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘FLIGHT’ (飛び立つ)

IoTデバイスはサーバを必要としない

  • AWS Greengrass
     ⇒サーバ側の役目だった処理をローカルで構築可能に

これまでのデータベース=実機やベンダー由来の様々な制約や障害があった
クラウド+オープンソースのDBで”制約”から飛び立とう

  • AWS Database Migration Service
  • Amazon Aurora
    • 完全MySQL互換のRDB
    • PostgreSQL互換も提供開始

ゲストトーク:グリー株式会社

by 藤本 真樹 氏 (グリー株式会社 開発・人事統括 取締役 執行役員常務 CTO)

オンプレで10年運用してきた環境をクラウドへ移行した話

技術選択の判断は難しい、基準には色々な軸がある
敢えて上げるならば、”is that faster?”
>速さは裏切らない(コンピュータが速くて困ることは絶対にない)

⇒ AWS(の機能やサービス展開速度)はこれらに応えられる

ホストトーク:AWS – SUPER POWERS 4

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘X-RAY VISION’ (透視)

⇒ データの集計・可視化

  • Amazon Athena

    • S3に保存されたデータを標準SQLで簡単に分析
  • Amazon EMR
    • Hadoopなどのビッグデータフレームワークを手軽に実行・分析可能
  • Amazon Redshift
    • 複雑なクエリ・超高速パフォーマンスを提供するペタバイト級データウェアハウス
  • Amazon Redshift Spectrum :new:
    • S3のデータを直接クエリ可能
    • エクサバイト規模のクエリ>Hiveで5年想定の処理を155秒で完了

SUPER POWER – ‘PRECOGNITION’ (予見)

⇒ Amazon AI – 人工知能サービス

  • Amazon Machine Learning

    • カスタム予測モデルの学習
  • Amazon Rekognition
    • 画像から顔と感情を認識
  • Amazon Polly
    • 文章をリアルな音声に変換(感情付加など)
  • Amazon Lex
    • 自動音声認識・自然言語理解

SUPER POWER – ‘IMMORTALITY’ (不朽)

⇒ スタートアップ企業生き残りの鍵 =『デジタルトランスフォーメーション』

AWSは『イノベーション』を続ける


AWS 認定試験 (12:30 ~ 13:50)

Summit特設会場でソリューションアーキテクトアソシエイト試験を受験(特典の50%OFFクーポン目当てです ^^; )

試験終了後すぐに認定者限定ラウンジに行ってみましたが、ノベルティの折り畳み傘はとっくに品切れでした;;
やはり一日数量限定は午前中に行かないと無理な模様。( ⇒ Day4で無事GET!!)

限定ラウンジではお菓子や飲み物が無料、座ってPCなどの充電が出来て中々快適でした。
モニタなど設置して講演中のセッションを視聴できればいいなと考えましたが、逆に人が溢れて寛げなくなりそう?


Session:『AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション』 (14:20 ~ 15:00)

スピーカー:Prasad Kalyanaraman 氏 (Vice President, AWS Edge Services)

セッション概要(タイトルリンク先より引用)

AWS Edge Services では、Amazon CloudFront に加え、AWS Shield、 AWS Lambda@Edge などの革新的な新サービスを発表しています。本セッションでは、AWS Shield の DDoS 防御機能と、AWS Lambda@Edge の CDN 上でのスクリプト実行により、セキュリティを担保しつつ柔軟でカスタマイズ性の高いアプリケーションの実現方法をご紹介します。

エッジでのセキュリティ活用

セキュアコンテンツ配信にCloudFrontが使える
 >エンドユーザー付近をセキュア通信の終端にする

Lambda@Edge

=Lambda関数のデリバリーサービス
 ・Bot 判定
 ・バリデーション
 ・認証処理
  ⇒エンドユーザ付近で実行できる
 ・ユーザ毎にコンテンツカスタマイズ可能
  e.g.
   ・PC/モバイル判定>アクセス先分岐
   ・エッジでHSTSヘッダを埋込み

DDoS対策 (スクラビングセンター)

 >AWS Shield (全Edgeロケーションで使用可)
  >Standard
   ・エッジで攻撃を検知し、遮断
   ・リアルタイムで悪意のあるトラフィックを検出
   ・無料で自動適用
  >Advanced
   ・攻撃データの可視化、およびイベント後の分析と調査を容易に
   ・DDoS攻撃で請求金額が跳ね上がるのを防ぐ「DDoS コスト保護」
   ・専門サポート
   ・有料

AWS WAF

 >L7(アプリケーションレイヤー)防御
 >Lambdaで独自のセキュリティチェック可 (e.g. 特定のIPを一定時間ブロック等)


Session:『Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム』 (15:20 ~ 16:00)

スピーカー:松田 和樹 氏 (株式会社インティメート・マージャー 開発本部)

セッション概要(タイトルリンク先より引用)

インティメート・マージャーではビジネスの都合上、50 種類ものジョブワーカーを運用しております。増え続けるビジネス要件に対応するため、Amazon ECS と SpotFleet を軸に Amazon S3、Amazon SQS、Autoscaling を組み合わせることで、低コストかつスケーラブルな docker 基盤を構築致しました。本セッションでは、その docker 基盤を中心にお話しします。

公演に使用されたスライドが公開されてます。

構築背景

  • 20以上の社外システムとデータ受渡し

    • 異なるデータ形式
    • 異なる接続方式
  • データ肥大化
    • スケールする仕組みが必要
    • 特定のジョブのみスケールさせたい

第一世代

処理フロー

S3ファイルUP>イベントをSQS通知>Cloud Watchでキュー数監視>EC2のワーカーをAutoScaling (Spot)
 >SQSキュー&S3ファイルを取得し処理>後続処理は別のS3へ

課題

  • スポット高騰時など特定のワーカーが起動不可となる
  • リソース(InstanceType)効率が悪い
  • 待機時間が長い
  • スケーリング設定多く、運用負荷高い

第二世代

変更点

  • 全ワーカーの実行環境をコンテナに
  • docker基盤共用
  • ECS採用
  • spot fleet採用
  • ワーカー毎にコンテナをスケール

Amazon ECS

  • 52のサービスが稼働 ( 50種のワーカー + Mackerel(監視) + Fluentd(ログコレクタ) )
  • コンテナレジストリ ⇒ Amazon ECR

Spot fleet

  • 168 vCPU
  • 自動入札(一つ一つ設定も可能だが手間)
  • InstanceType:7種 主にC4、M4系

運用のポイント

ログのハンドリング

  • 目的で集約先使い分け

    • 常時監視 ⇒logdna
    • 長期分析 ⇒BigQuery
    • 直近データ分析、参照 ⇒Aurora

環境構築・デプロイ

  • Terraform採用
  • CircleCIからAPIでデプロイ
     ⇒docker対応CIサービスがおすすめ

強制ターミネート(Spotインスタンス)

  • コンテナ強制終了
  • 検知する仕組み必要
    • メタデータをポーリング⇒クラスタから退役

AMI

  • ECS-Optimized AMI 使用
  • AMIのカスタマイズはしない
  • 設定はcloud-initで

ECSの課題

  • クラスタ管理

    • agent方式⇒ラグが多々
    • ゾンビワーカー
  • docker全機能は使えない
  • コンソール画面がまだまだ
  • 学習コストそこそこ

ECSの強みは他AWSサービスとの連携


Session:『AWS で実現するセキュリティ・オートメーション』 (16:20 ~ 17:00)

スピーカー:桐山 隼人 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

クラウドは、今までやってきたことを効率的にするだけでなく、今までできなかったことを可能にします。本セッションでは、セキュリティをクラウド環境で実現することで可能となる、運用統合と自動化(オートメーション)をご紹介します。セキュリティ・オートメーションは、貴社の運用が変わるだけでなく、セキュリティ戦略そのものを見直すきっかけにもなります。オートメーションによる次世代のセキュリティを考えてみませんか?

※スライドは公開されていないようですが、ほぼこれと同じだったかと思います。

クラウド移行に関するアンケート

日:クラウドに移行しない理由 1位 ⇒セキュリティ
米:クラウドに移行した理由 1位 ⇒セキュリティ
 ⇒まだ正確な認識が普及していないせいと思われる

クラウドだからできるセキュリティ

オートメーションとは=戦略策定の基盤
AWSはセキュリティオートメーション前提に設計されている ⇒基盤として活用してほしい

  • 戦略策定

    • SFA、マーケティングに活用
    • やること やらないこと を決められる
  • 何を自動化すべきか? (考える主軸 ⇒)

    • 対策主体(人、組織、技術)
    • 対策対象(サーバ、ネットワーク、クライアント)
    • 対策場所(入口、内部、出口)

ガートナーの『適応型セキュリティアーキテクチャ』

サイクルを回す:
 防御⇒検知⇒対応⇒予測⇒~

 防御:CloudFront、WAF ~
 検知:VPC Logs、Auto Scaling ~
 対応:SNS、Lambda ~
 予測:EC2 Config、3rd party レピュテーション、Inspector ~

実用例

CloudFrontアクセス⇒WAF⇒LambdaでレピュテーションリストDL&判定
 ⇒Lambdaでセキュリティ評価⇒Amazon Inspector⇒SNS⇒LambdaでNACL/SG変更
 ⇒攻撃検知⇒ブロックログ⇒EBSなどsnapshot⇒CloudTrail(操作ログ)
全レイヤー、ノードのログが取れるので
 ⇒VPC Flow Logs/Elastic Search/Kibanaなどで可視化
攻撃者のドメイン生成は自動化されている:Domain Generation Algorithm(DGA)
 ⇒AWS WAF + Amazon MLで怪しいドメインを学習
Machine Learningでリスク分析
 ⇒設定変更などの意思決定まで自動化


Session:『Machine Learning on AWS』 (17:20 ~ 18:00)

スピーカー:志村 誠 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

AI や機械学習という言葉が話題になる遥か前から、Amazon では機械学習技術を活用したさまざまな取り組みを行ってきました。本セッションでは AWS の上でご利用いただける機械学習サービスについてご紹介するととともに、それらをどのように使い分けるか、また機械学習をどのように皆さまのサービスに役立てて行くかについてご紹介します。

どんなサービスで機械学習を活用するか?

ビジネス主体で考える(使いたい技術から考えない)

  • 良質なデータが継続的に入るか
  • 自動化の価値ある予測か
  • 費用対効果

機械学習はあくまでツール
需要に反し解決していない問題に対して検討する

代表的な活用例>
– レコメンド
– 異常検知
– 画像認識
– クラスタリング(ユーザの分類分けなど)

AWSで提供する機械学習サービス

グルーピング>

  • Service
  • platform
  • Engines
  • Hardware

AI Hardware

  • EC2:P2 instance

    • GPU特化
  • Greengrass
    • デバイスに学習モデル
    • エッジで推論処理

AI Engines

典型的な機械学習フレームワークをインストール済みのAMIを提供

AI platform

  • Amazon Machine Learning
  • Amazon EMR

AI Service

  • Polly
  • Rekognition
  • Lex

その他

Kinesis Analytics >異常検知
Elastic Search >検索を機械学習に利用
Data Pipeline >EMRのジョブをスケジューリング

ゴールを明確に

  • 解決すべき課題
  • アウトプット

続き⇒Day4

続きを読む