はじめてのCloudFormation

はじめてのCloudFormation 
〜動的スケールをやってみた内容とその注意点〜
2017/02/10
Acroquest Technology Co., Ltd.
石田浩司
Copyright © Acroquest Technology Co., Ltd. All rights reserved.
1

View Slide

自己紹介
2
•  石田浩司（@kojiisd）
‒  Acroquest Technology Co., Ltd.
‒  IoTプラットフォーム開発エンジニア
‒ 2012/10～2015/10 ミャンマー支社赴任
‒ JavaOne 2015 スピーカー
‒ 2016/11 JAWS-UG 横浜支部
‒ 2016/12 AWS re:Invent 2016
※2017/01も滞在

View Slide

作り側の人間です
3

View Slide

4
ある日の作業中

View Slide

5
上司
XXX案件で、Logstashを複数台立てて、S3よりファイルを読み込み、
Elasticsearchにデータを投入したい。
たぶんこの辺がポイント。
・データ投入時だけ、インスタンスを立てて、投入し終わったら停止。
・インスタンスの台数は、毎回変わる。10台の日もあれば50台の日も。
・S3のデータの読み込み対象は、毎回変わる。
・データのキューとしてKafkaを使うかも。
そのため、ECSか、CloudFormationが有効ではないか、と思ってい
ますが、このあたりの構築をヘルプして欲しい。
技術解は問わないけど、
今週中（5日）くらいで検証して欲しいかな。
ElasticsearchはVer.5系ね。

View Slide

6
Logstash
Elasticsearch
S3
Kafka
ECS
CloudFormation
← OK
← OK
← OK
← たぶん大丈夫
← OK
← 知らん
4.5/6

View Slide

はい、わかりました。

View Slide

8
きちんと言われた内容を
確認しようと後で
後悔しました。

View Slide

9
・・・ということを
学べた経験の共有

View Slide

10
いったんやりたいことを整理

View Slide

11
上司

View Slide

やりたいことを整理するとこんな感じ？
12
・・・
当時Ver.5系が
AWSになかったので
EC2インスタンスを利用

View Slide

13
上司

View Slide

調査ポイントを整理
14
・・・
ECS?
CloudFormation?
必要な時に必要な分だけ
立ち上がって処理開始
アクセスパスが毎回、
インスタンス毎に変わる

View Slide

15
パッと考えた感じ
ECSより
CloudFormationかなぁ

View Slide

調査ポイントを整理
1.  インスタンスの一斉立ち上げ
①  コマンド一発で（後々立ち上げはスケジューリング）。
②  台数の指定は立ち上げ時に指定できるようにする
→CloudFormationならできそうだ。
2.  S3へのアクセスパスは毎回異なる
①  EC2インスタンスが起動時にどこにアクセスするかを理解し
ている必要がある。
– ECインスタンス立ち上げ時に自身の役割を理解させる？できる？
16

View Slide

17
ま、CloudFormationで

View Slide

ゴールイメージ
18
・・・
検証するだけなので
一旦Kafkaは構成から抜く

View Slide

ゴールイメージ
19
・・・
※最終的にはEMRを使うようになります。

View Slide

調査の流れをイメージ
20
DAY 1
•  EC2インスタンスなどの起動対象を準備
•  EC2インスタンスのユーザデータ設定
DAY 2
•  CloudFormationでインスタンス立ち上げ用スタック作成
•  EC2インスタンス数の動的変更調査
DAY 3
•  S3アクセスパス動的割り当て調査
•  全体の疎通確認
※残り2日は予備日で考える。

View Slide

21
DAY 1
DAY 1
DAY 2
DAY 3

View Slide

22
EC2インスタンスなどの起動対象を準備
EC2インスタンスのユーザデータ設定

View Slide

23
特に問題なかったので
SKIP (・ω

View Slide

24
DAY 2
DAY 1
DAY 2
DAY 3

View Slide

CloudFormationでインスタンス立ち上げ用スタック作成
25
とりあえずわからないことだらけ

View Slide

26
Webでそれっぽいサンプル探して
改修しようかな

View Slide

27
Webでそれっぽいサンプル探して
改修しようかな
都合の良いサンプルなんか大体ない

View Slide

28
エンジニアあるある

View Slide

本当にシンプルなサンプルが見つからなかった。。。
1.  VPC作成をするとか、新規にSG作るとかそういう
Too muchなものばかり。
①  VPCは最初から指定されたものを使いたい
②  SGも同様
③  画面から選択とかいらないから、まず最小構成でEC2イン
スタンスを起動するようにしたい
2.  AWS CloudFormation Designerは、使い方を学ぶだけ
で予定期間使っちゃいそう。。。
29
このあたりから少しずつ焦り始める

View Slide

必要そうな項目だけWebから引っ張ってきた
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "s3 to Elasticsearch template",
“Mappings”: {},
"Parameters": {
# 基本的にDefault値を設定しておく
“ImageId”: {},
"InstanceType" : {},
"Name": {},
"KeyName": {},
"EBSVolumeSize" : {},
"CapacitySize": {},
"S3PathPrefix": {},
"Resources": {},
"Outputs": {}
}
30
必要な項目は
こんな感じだった
ここにEC2インスタンス
の設定を書けば
OKの模様。

View Slide

31
EC2インスタンスの設定は
一つずつ記述が必要
毎回必要数分
インスタンス設定を書く必要有
動的にインスタンス数変更不可

View Slide

CloudFormationだけでEC2イ
ンスタンス数の動的変更難しい
ですね。Terraform使えば・・・
上司
CloudFormationだけで実現で
きるといいよね。

View Slide

33
CloudFormationだけで

View Slide

34
AutoScaling
AutoScalingGroup

View Slide

AutoScalingしか対応できないの？
1.  AutoScalingAutoScalingGroupのMaxSizeとMinSizeを
一緒にすれば、起動時のインスタンス数を指定可能。
35
“AutoScalingAutoScalingGroup” : {
“Type” : “AWS::AutoScaling::AutoScalingGroup”,
“Properties” : {
“DesiredCapacity” : { “Ref” : “CapacitySize” },
“LaunchConfigurationName” : { “Ref” : “AutoScalingLaunchConfig” },
“MaxSize” : { “Ref” : “CapacitySize” },
“MinSize” : { "Ref" : "CapacitySize" },
"AvailabilityZones" : []
}
}
0.5日足が出た

View Slide

36
DAY 3
DAY 1
DAY 2
DAY 3
※0.5日遅れ

View Slide

37
S3アクセスパス動的
割り当て調査

View Slide

38
これが大変だった・・・

View Slide

1回目の起動はこうでも・・・
39

View Slide

2回目はこうなるかもしれない
40

View Slide

どうやって自動起動したEC2
インスタンスに自分の役割を
認識させたらいいんだよ・・・。
無責任な
先輩Lambda信者
Lambda書けLambda。シュッ
とやればOK。

View Slide

42
せめて一斉起動時の
起動順番がわかれば
対応できるんだけど・・・

View Slide

起動順番とパスを紐づけておけば対応できる
43
1st -> 01/xxx 
2nd -> 02/xxx 
3rd -> 03/xxx 
4th -> 04/xxx 
5th -> 05/xxx 
6th -> 06/xxx
① ② ③ ④ ⑤ ⑥

View Slide

44
ami-launch-index

View Slide

ami-launch-indexとは？
45

View Slide

ユーザデータに設定して解決！
"UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash -xe\n",
“curl http://169.254.169.254/latest/meta-data/ami-launch-index > /home/
ec2-user/MyIndex.txt\n”,
（諸々初期設定スクリプト呼び出し）
]]}
},
46
下記に併せて起動時のスクリプトも修正
※さらに0.5日遅れ

View Slide

一通り通った！
47
※全体で1日遅れ

View Slide

48
プロジェクトに報告入れて
ミッション完了
※1日遅れ

View Slide

49
と、思いきや

View Slide

跳ね上がっていたコスト
1.  実施していたこと
①  ユーザデータの修正（起動
→失敗→再起動）
②  CloudFormationのテンプレ
ート修正
2.  テンプレート適用後は確実
にスタックを削除、かつEC2
インスタンスも削除されてい
ることは確認済。
50

View Slide

51
CloudFormationで
起動失敗した場合に
EBSが残っていた

View Slide

原因は「起動失敗」→「再起動」時にEBSが残ったこと
1.  度重なるCloudFormation
テンプレート修正（起動→失
敗→再起動）により、EC2
停止時にEBSが削除されて
いなかった。
①  100GB超のEBSが150以
上残っていた。
2.  即不要なEBSを削除して事
なきを得た。
52

View Slide

53
EBSの残骸に気を付けましょう
※監視するだろう普通、というのは置いておいて・・・。
　時間なかったんで勘弁してほしい。

View Slide

54
まだあった　DAY 4
DAY 1
DAY 2
DAY 3
DAY 4
※1日遅れ

View Slide

S3パスの対象が10を超えると
対象パスが重複するんだけど。
プロジェクト
メンバ

View Slide

11個目以降のアクセスパスが重複する
56
※全体で1日遅れ
① ② ③ ⑩ ⑪
・・・ ⑫

View Slide

57
調査したら確かに
11個目からパスが重複
ami-launch-indexが
11個目から”0”スタート

View Slide

58
嫌な予感

View Slide

59
助けてサポートセンター！

View Slide

60
Auto Scaling 側の挙動で、
キャパシティが10以上に指定された
場合は10台ずつインスタンスを立ち
上げるようになってるよー。
サポート
センター
無慈悲な仕様による制限

View Slide

61
ただ救いの手が！
※この相談（待ち）の間にEMRにプロジェクト方針決定
案1: DynamoDB のアトミックカウ
ンタを使って採番する
案2: SQS と組み合わせてワーカー
のようなアーキテクチャを構成する
案3: Amazon EMR を使用する
サポート
センター

View Slide

こういうのも試してみたかった
62
① ② ③ ⑩ ⑪
・・・ ⑫
・・・
←事前に処理の登録が必要
or

View Slide

今回学んだこと
1.  CloudFormationは本当に便利
2.  利用時に関連するサービスの監視（ゴミが残らないかな
ど）は必須
3.  メタデータを利用して効率的なEC2インスタンス運用
4.  何か困ったらすぐサポートセンターに助けを求めよう！
63

View Slide

64
Infrastructures Evolution
ご清聴ありがとうございました

View Slide

はじめてのCloudFormation

はじめてのCloudFormation

Koji Ishida

More Decks by Koji Ishida

Other Decks in Technology

Featured

Transcript