SlideShare a Scribd company logo
1 of 59
Download to read offline
Copyright gedow.net All Rights Reserved.
財布の紐を限界まで締める!
AWSスポットインスタンスの真髄
外道父@GedowFather
2015/06/17
#2 市ヶ谷Geek★Night
Copyright gedow.net All Rights Reserved. 2
自己紹介
■私は
外道父@GedowFather
■所属
ドリコム
■職種
インフラエンジニア
■ブログ
外道父の匠
Copyright gedow.net All Rights Reserved. 3
ま
だ
オ
ン
デ
マ
ン
ド
で
お
布
施
し
て
る
の
?
そ
ら
ウ
ハ
ウ
ハ
で
売
上
高
を
公
開
し
ち
ゃ
い
ま
す
わ
Copyright gedow.net All Rights Reserved. 4
目次
1. 基本と目的
2. 深イイ話
3. アーキテクチャ
4. その他の工夫
Copyright gedow.net All Rights Reserved.
基本と目的
Copyright gedow.net All Rights Reserved. 6
スポットインスタンスを三行で
1. 費用が超安い!
2. 起動が少し遅い!
3. 強制削除されるリスク!
Copyright gedow.net All Rights Reserved. 7
安い理由は入札式
 余っているリソースを使ってもらうため
 需要と供給により価格が変動する
 入札価格が変動価格を上回れば起動を継続
でき、下回れば強制削除される
入札価格
変動価格
起動できない
起動できる
強制削除
起動できる
$0.1
$0.2
$0.01
$0.05
$1.0
Copyright gedow.net All Rights Reserved. 8
費用の比較
オンデマンド 100%
リザーブドインスタンス 55~75%
スポットインスタンス 最小 14%
最大 1000%
 リザーブドは事業規模の変化度合いに合わ
ないし、1年経てばc3=>c4のような上位
互換が期待できるのでメインにはしない
 スポットのワクワク感
Copyright gedow.net All Rights Reserved. 9
価格変動の度合い
 予測は不可能
 xlarge以下は比較的 落ち着いている
 それ以上は無慈悲な急騰が常
c3.4xlarge の平和な24時間
$0.15 ~ $0.25
c3.4xlarge のよくある一週間
最大 $5.0
Copyright gedow.net All Rights Reserved. 10
高スペックの価格変動
 c3.8xlarge は1ヶ月間に数十回も高騰
 オンデマンドの 2~5倍
 おまえらは誰と闘っているんだ状態
このオンデマンドは $1.68
Copyright gedow.net All Rights Reserved. 11
起動時間が少し遅い
 オンデマンドはポチッてから
約3~4分
で起動が完了する
 スポットはまず入札処理が入り、入札が
成功してから起動に入るため
約7~8分
を必要とする
Copyright gedow.net All Rights Reserved. 12
強制削除
 入札価格 ≧ 変動価格 = セーフ
 入札価格 < 変動価格 = アウト
一度でもアウトの条件を満たすと、
1~2分で強制的にTerminateされる
1分経過
スポット
入札価格
AWS神
Copyright gedow.net All Rights Reserved. 13
基礎知識から導き出される結論
リスクを排除して
スポットだけで
運用したら激安じゃない
Copyright gedow.net All Rights Reserved.
深イイ話
Copyright gedow.net All Rights Reserved. 15
リソースは全く同じ
 オンデマンドのインスタンスも、スポッ
トインスタンスも、元となるサーバーの
リソースは全く同じ
 スポットだからCPUやストレージの品質
が劣っているということは一切ない
オンデマンド オンデマンド スポット
ホストサーバー
Copyright gedow.net All Rights Reserved.
価格ルール
Copyright gedow.net All Rights Reserved. 17
変動/入札価格の最大値
 変動価格はオンデマンド価格の10倍
まで跳ね上がる
 入札価格も10倍までとなる
オンデマンドが $0.294 なので
最大で $2.94 まで跳ね上がる
Copyright gedow.net All Rights Reserved. 18
2015年4月中旬までの価格ルール
 最大入札価格はオンデマンドの4倍まで
 それ以上は申請して上限を引き上げる形式
 価格の継続的な異常高騰を和らげるために
改定された
企業(A) 企業(B)
スポットの存在意義にそぐわない利用状況にメスが入った
変更が入った瞬間、
オンデマ10倍以上の
LaunchConfiguration
では起動できなくなる
というトラブルが発生
(外道式青天井界王拳20倍施策より)
Copyright gedow.net All Rights Reserved. 19
強制Terminateを避けるテクニック
最大変動価格
= 最大入札価格
= オンデマの10倍
すなわち
オンデマンドの
10倍で入札したら
落とされない!!
基本的にTerminate
Copyright gedow.net All Rights Reserved.
安全な停止
Copyright gedow.net All Rights Reserved. 21
入札価格超過以外の落とし穴
 需要と供給の関係で成り立っているので、
需要が急増した場合は入札や変動価格の高
低に関わらず強制Terminateが走る可能性
がある
 変動価格MAXでよく起こる
 発動時に削除されるかは運
Copyright gedow.net All Rights Reserved. 22
強制Terminateをインスタンス自身が知る
ローカルのメタデータで、神様による無慈悲
なTerminate発動予定時間を取得できる
http://169.254.169.254/latest/meta-data/spot/termination-time
 普段は 404 Not Found を返す
 価格超過やリソース不足によるTerminate確定か
ら数秒後に200 OKと停止時刻を返すようになる
 5秒間隔でのチェックを推奨されている
 検知したら、新規リクエストの受け付けを停止す
るなど、必要な処理を済ませる
AWS
Copyright gedow.net All Rights Reserved. 23
通常のインスタンス破棄前に任意の処理を行う
 AutoScaleにおける起動完了前や削除実行
前に、任意秒を待機し、任意の処理を行う
ための LifecycleHook という機能がある
 削除前に待機することで、安心安全に落と
すための処理を入れることができる
ココで止まってもらい
ココで必要な処理を行い
自身でシステムに通知するか、
任意秒が過ぎたら、
次のプロセス(削除処理)へ移る
Copyright gedow.net All Rights Reserved.
制限値
Copyright gedow.net All Rights Reserved. 25
入札数の制限
 アカウントごとの設定に、EC2インスタン
ス数の上限数が 20 といった制限値がある
 入札数にも制限があり、デフォルトで 20
となっている
 各種設定と同様、申請で引き上げ可能
 入札数のカウントはインスタンスを削除し
たらすぐ減るわけではないので、短時間で
起動と削除を繰り返すと入札できなくなる
Copyright gedow.net All Rights Reserved.
アーキテクチャ
Copyright gedow.net All Rights Reserved. 27
メインをスポットにする覚悟を決める
 入札価格をオンデマンドの10倍にす
ることで強制Terminateを避ける
 スポットの仕様変更や機能追加に追随
し続ける 『
コ
ス
ト
を
抑
え
る
』
『
安
全
に
運
用
し
続
け
る
』
「
イ
ン
フ
ラ
エ
ン
ジ
ニ
ア
」の
Copyright gedow.net All Rights Reserved. 28
制限値を上げる申請をする
デフォルト値 申請値(例)
EC2インスタンス数 20 400
入札数 20 400
AutoScalingGroup数 20 100
 AutoScalingGroupは構築時に気づけるが、イ
ンスタンス関連は運用に入ってから引っかかる可
能性があるので注意する
 申請は1営業日もあれば通るので焦らなくてOK
 多すぎず少なすぎず、気持ち多目に
Copyright gedow.net All Rights Reserved.
AutoScalingGroup
Copyright gedow.net All Rights Reserved. 30
AutoScalingGroupを作成する
Availability Zone [1a]
Spot
c3
1~100台
Spot
c4
1~100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Availability Zone [1c]
Spot
c3
1~100台
Spot
c4
1~100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
Copyright gedow.net All Rights Reserved. 31
AutoScalingGroupを細かく分ける理由
Availability Zone [1a]
Spot
c3
1~100台
Spot
c4
1~100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Availability Zone [1c]
Spot
c3
1~100台
Spot
c4
1~100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
 変動価格がインスタンスタイプ/AZ単位のため
 複数のインスタンスタイプを併用し、高騰による
強制Terminateのリスクを減らすため
 監視用グラフを永存したり、アプリログのサンプ
リングを送信するため
10 グループ!
Copyright gedow.net All Rights Reserved. 32
オンデマンドも併用する理由
スポットが不調な時に予備のスケールアウト
となる
急激なスケールアウトが必要になった時、ス
ポットより素早く起動できる
監視用インスタンスはホスト名やIPアドレス
を固定で据え置きたい
Copyright gedow.net All Rights Reserved. 33
スポットメインのスケール条件
スポット オンデマンド 監視用
min 1 1 1
max 100 100 1
CPU条件 増減率 CPU条件 増減率
increase(1) 40% 20%↑ 70% 20%↑
なしincrease(2) 80% 80%↑ 90% 80%↑
decrease 20% 20%↓ 40% 20%↓
 平時はスポットだけが増設され、有事はオンデマンドも増設
 落ち着けばオンデマンドから削減される
 (スポット1~100✕4グループ)+(オンデマンド1✕6 グ
ループ) が平時の台数となる
Copyright gedow.net All Rights Reserved. 34
高騰したスポットは破棄する
type AZ min max desired
スポット c3 1a 1 100 25
1c 1 100 28
c4 1a 1 100 22
1c 1 100 25
オンデマ c3 1a 1 100 1
1c 1 100 1
c4 1a 1 100 1
1c 1 100 1
監視用 c3 1a 1 1 1
c4 1c 1 1 1
min max desired
1 100 25
0 0 0
1 100 22
1 100 25
1 100 1
1 100 1
1 100 1
1 100 1
1 1 1
1 1 1
高騰
 グループ単位で価格を監視し、高騰と判断したらインスタン
スを破棄してグループの稼働を停止する
 残る3グループの負荷は上がるが平常運転の範囲内
 価格が落ち着いたら、またスケールアウトを開始する
Copyright gedow.net All Rights Reserved. 35
高騰と平常の判断条件
 直近1時間平均を比較値とする
 1時間に数十ある履歴の、価
格と割当時間から計算する
 わずか数分の突発高騰でのイ
ンスタンス破棄を防ぐため
16時に比較する値は
$3.0 ではなく
$0.5 程度になる
1時間平均の変動価格 = 比較値
高騰 if 比較値 ≧ オンデマンド価格✕1.2
平常 if 比較値 < オンデマンド価格✕0.8
※条件を離すことで自動処理の連続発動を回避
Copyright gedow.net All Rights Reserved. 36
高騰リスクの低減
 c3だけだと1a&1cが同時に高騰する可能性が高く、最悪
リソースがゼロになるため、c4を併用することで最悪でも
リソース半減に抑えられる
 さらに m3/m4/r3 を併用という選択もありうる
Spot
c3
100%
Spot
c4
100%
1a
Spot
c3
100%
Spot
c4
100%
1c
Spot
c3
133%
Spot
c4
1a
Spot
c3
133%
Spot
c4
133%
1c
価格高騰により
1グループ死亡しても
残るグループの負荷は
4/3倍になるだけ
Copyright gedow.net All Rights Reserved.
通常停止対策
Copyright gedow.net All Rights Reserved. 38
LifecycleHookで安全にシャットダウン
ココで3600秒止まってもらい
インスタンス自身がLifecycleHookに
入ったと認識したら必要な処理を行い
Complete通知を送って終了する。
完了までの時間はサービスの性質次第
 スケールインや高騰時のグループインスタンス破棄において、
安全かつ必要な処理を済ませる
 ELBから外す、ユーザー切断を待つ、タグを付ける、監視
サーバーから自ホストのデータを削除する
 処理が完了したらAWSに通知を送ってTerminate
Copyright gedow.net All Rights Reserved. 39
LifecycleHookの通知と問題点
 LifecycleHookの通知はインスタンスが直接受けるのではな
く、SNS/SQSを通して受け取る
 メッセージ内にCompleteを送るためのトークンがある
 SNSだと余剰サーバーが必要になるので却下
 SQSだとインスタンス自身で取りにいけるが、キューは任
意のメッセージを受け取ることができない
SNS 管理
サーバー
削除対象
サーバー
SNSの場合
PUSH?
PULL?
SQS
削除対象
サーバー
SQSの場合
こんなことで複雑な仕組みにしたくない
キューから自身宛のメッセージを取得しづらい
何度も取得処理をして時間がかかる可能性がある
Copyright gedow.net All Rights Reserved. 40
LifecycleHookの通知を取得する仕組み
 10秒毎に全インスタンスでキューをチェック
 あれば必ず1通は取得できるので、インスタンスIDとトーク
ンを抜き出し、該当のインスタンスにタグを登録
 さらにインスタンス自身のタグをチェックし、該当タグがあ
れば削除前処理を行い、Complete通知をして完了する
SQS 削除対象
サーバー
(B)
サーバー
(C)
サーバー
(A)
Send Message
Get & Delete Message
Create Tags
 LifecycleTransition
 LifecycleActionToken
Copyright gedow.net All Rights Reserved. 41
Linuxのinitシステム管理では挙動が不確か
 正常なシャットダウン処理の場合、initスクリプト
に sleep を仕込むことでTerminateを遅らせるこ
とができそうだが無理
 Terminateによるshutdown実行後は、sleepで耐
えていても数分後にインスタンスを強制削除される
 LifecycleHookが確実な手段だし、便利なのでオス
スメ
 だがトークンの受け取りが厳しい。メタデータに埋
め込んでくれ
Copyright gedow.net All Rights Reserved.
強制停止対策
Copyright gedow.net All Rights Reserved. 43
強制Terminateに備える
http://169.254.169.254/latest/meta-data/spot/termination-time
 入札価格超過によるTerminateはないが、需要/供
給のリソース不足で落とされるので仕込む
 Bashデーモン
 5秒間隔で監視し、検知したらLifecycleHookと
同じ削除前処理を実行する
Copyright gedow.net All Rights Reserved. 44
唯一の弱点
 1回1回の処理時間が短いHTTPは問題ない
 1つの処理に数分数十分以上の持続接続が必要な場
合は、クライアントやジョブの処理終了に間に合わ
ず落とされてしまう
 WebSocket / MQTT や 集計処理 など
 切断時にクライアント再接続やジョブ再実行する仕組み
 Terminateを検知した時点でそれを促す仕組み
Terminate検知 Terminate実行1~2分間
HTTP
長時間の持続接続サービス
この間に処理を安全に終えられるか
が分かれ目となる
過ぎるとユーザーに
不利益が生じるため
工夫が必要になる
クライアントが強制切断される
Copyright gedow.net All Rights Reserved.
費用効果
Copyright gedow.net All Rights Reserved. 46
オンデマンドのみと併用の比較
 オンデマンドのコストを 100 とする
 好調スポットのコストを 15 とする
 最小台数と大規模台数でそれぞれ、同台
数におけるオンデマンドのみのコストと、
スポット構成のコストを比較する
Copyright gedow.net All Rights Reserved. 47
最小台数の場合
Availability Zone [1a]
Spot
c3
1台
Spot
c4
1台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Availability Zone [1c]
Spot
c3
1台
Spot
c4
1台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
Spotコスト = 1台✕4グループ✕15 = 60
Ondemandコスト = 1台✕6グループ✕100 = 600
Spot + Ondemand = 660
Ondemandのみ = 1000>34%削減
Copyright gedow.net All Rights Reserved. 48
大規模台数の場合
Availability Zone [1a]
Spot
c3
30台
Spot
c4
30台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Availability Zone [1c]
Spot
c3
30台
Spot
c4
30台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
Spotコスト = 30台✕4グループ✕15 = 1800
Ondemandコスト = 1台✕6グループ✕100 = 600
Spot + Ondemand = 2400
Ondemandのみ = 12600>81%削減
Copyright gedow.net All Rights Reserved. 49
1時間平均の価格変動グラフ(1ヶ月間)
Ondemand価格
Ondemand価格
c3.xlarge
c4.xlarge
ほぼオンデマンドの
20~25%をキープ
一時荒れるも避難し、
大半を最低価格の
14%でキープ
Copyright gedow.net All Rights Reserved. 50
インスタンスタイプの選択
 希望は 2xlarge あたりだった
 最初に採用したのは c3/c4.xlarge
 c4がご乱心 & m3が安定したので
c3/m3.xlarge に避難
 m2 は安定しているがHVM非対応
 新しい m4 は多分、数カ月後に荒波
 CC2/CR1 もわりとブルーオーシャン
 高スペック+Dockerという手も……
Copyright gedow.net All Rights Reserved. 51
オンデマンドいる?
 いざ運用してみると、思いの外スポットのス
ケールアウトだけで稼働できてしまう
 オンデマンドがいらない気になるけど、そこ
までスポットは信用するべきものでもない
 最終防衛ライン
 1セットにつき6つのオンデマンドが確定な
ので、リザーブドインスタンスを適用すると
さらに削減できる
Copyright gedow.net All Rights Reserved.
その他の工夫
Copyright gedow.net All Rights Reserved. 53
AutoScalingGroup管理の簡略化
 LaunchConfigurationが多い
 production / staging
 spot / ondemand
 c3 / c4
 AutoScalingGroupが多い
 同上
 1a / 1c
 監視用
 CloudWatchが多い
 Increase (peace / pinch)
 Decrease
 監視用は除く
>合計8件
>合計20件
>合計48件
自動化した
作成・削除・更新など全て
Copyright gedow.net All Rights Reserved. 54
独自TimeBasedスケールアウト
12時 23時
 サービスの性質上、12時と23時がピークタイムであり、
12~23時の間はイベントやメンテナンスによる急激な
増減がある。特にメンテ明けの台数は危険
 11:30 にMinSizeを、その時点のInService✕N倍の台
数に強制増設する(1.5~3倍)
 23:30 にMinSizeを元に戻す
 日中の台数節約放棄の代わりに運用し易さと安定を得る
強制Increase
自然な増減に
切り替え
最低台数を
キープ
Copyright gedow.net All Rights Reserved. 55
AZ間のレイテンシ差に対応する(1)
AZ [1a]
EC2
AZ [1c]
EC2
RDS
速い 少し遅い
 RDSやElastiCacheが同じAZにあるとレイ
テンシが低い
 違うAZからだと遅くはないが、同AZより
はレイテンシが高い
AZ [1a]
Spot
c3
10台
Spot
c4
9台
AZ [1c]
Spot
c3
3台
Spot
c4
2台
 レイテンシが低いほど多くCPU
処理をできるためスケールアウ
トされやすい
 CPU性能が低いほどスケールア
ウトされやすい
 AZとインスタンスタイプで台
数に偏りが出ると、リスクも偏
ることになる
Copyright gedow.net All Rights Reserved. 56
AZ間のレイテンシ差に対応する(2)
AZ [1a]
Spot
c3
6台
Spot
c4
6台
AZ [1c]
Spot
c3
3台
Spot
c4
2台
Max 6 Max 6 Max 100 Max 100
グループごとの台数を監視
最低台数より+4台以上の
グループはMax値を抑える
Max = Desired
差が狭まったらMaxを戻す
この仕掛による挙動とリスク
抑えつけたグループの分、スケールアウトの全体増加率が
減少するため、1グループあたりの増加率で調整する
Increase条件がCPU 40%だとすると、抑えつけたグルー
プはCPU60%前後にまで上がる
 AZを分けなくても、実はそもそもこうなっているはず
 リソースを多目に消費することは台数節約でもある
Copyright gedow.net All Rights Reserved. 57
スクリプトで AWS CLI を使わない
 AWS CLIは重い(CPUをメチャ喰う)
 手動や数時間に1回の実行ならば問題ない
 数十秒単位だとCPU利用率のグラフが常に10%前
後など無駄すぎる消費
 重いのは認証処理
 シェルのコマンドベースだと毎回この処理が入る
 軽量プログラミング言語+SDKで書けば、認証
を確保したままループ処理をできるため軽い
 最初はBashで書いたがRubyに書きなおした
 手動実行 管理スクリプト
 自動実行 ジョブスクリプト
 監視アラート/グラフ用 値出力スクリプト
Copyright gedow.net All Rights Reserved. 58
AWS Japan と同じ社屋に入る
アルコタワー
アネックス
Amazon Japan
アルコタワー
19F
AWS Japan
17F
ドリコム
他の階も
Amazonが
徐々に侵食中
 相談や新着情報を伝えに天上界から降りてきてくれ、終
わると天上界にお帰りになられる
 天上界にお伺いし、USチームと電話会議したり、来日し
ているとディープな情報交換できる(完璧な通訳付き)
Copyright gedow.net All Rights Reserved. 59
俺
の
コ
ス
ト
が
高
騰
し
ち
ま
う
か
ら
な
!
で
も
……
で
も
で
も
ス
ポ
ッ
ト
は
怖
い
し
や
め
た
ほ
う
が
い
い
と
思
う
よ
!
fin

More Related Content

What's hot

AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)Trainocate Japan, Ltd.
 
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAmazon Web Services Japan
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)NTT DATA Technology & Innovation
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)NTT DATA Technology & Innovation
 
AWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMail
AWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMailAWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMail
AWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMailAmazon Web Services Japan
 
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Masahito Zembutsu
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」Masahito Zembutsu
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
クラウドでも非機能要求グレードは必要だよね
クラウドでも非機能要求グレードは必要だよねクラウドでも非機能要求グレードは必要だよね
クラウドでも非機能要求グレードは必要だよねYoshioSawada
 
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)NTT DATA Technology & Innovation
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAkihiro Kuwano
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean ArchitectureAtsushi Nakamura
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #1320210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13Amazon Web Services Japan
 

What's hot (20)

AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
 
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
 
AWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMail
AWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMailAWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMail
AWS Black Belt Techシリーズ Amazon WorkDocs / Amazon WorkMail
 
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
 
Docker Tokyo
Docker TokyoDocker Tokyo
Docker Tokyo
 
20211109 JAWS-UG SRE keynotes
20211109 JAWS-UG SRE keynotes20211109 JAWS-UG SRE keynotes
20211109 JAWS-UG SRE keynotes
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
クラウドでも非機能要求グレードは必要だよね
クラウドでも非機能要求グレードは必要だよねクラウドでも非機能要求グレードは必要だよね
クラウドでも非機能要求グレードは必要だよね
 
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
Consistent hash
Consistent hashConsistent hash
Consistent hash
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #1320210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
 

Viewers also liked

AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンスAWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンスAmazon Web Services Japan
 
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例外道 父
 
AnsibleによるHWプロビジョニング -OneViewの連携-
AnsibleによるHWプロビジョニング  -OneViewの連携-AnsibleによるHWプロビジョニング  -OneViewの連携-
AnsibleによるHWプロビジョニング -OneViewの連携-Takahiro Kida
 
Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)Taro Hirose
 
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Shingo Kitayama
 
運用のためのPlaybook (Playbook for Operation)
運用のためのPlaybook (Playbook for Operation)運用のためのPlaybook (Playbook for Operation)
運用のためのPlaybook (Playbook for Operation)Shingo Kitayama
 
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)さくらインターネット株式会社
 
はじめての UWP アプリ開発
はじめての UWP アプリ開発はじめての UWP アプリ開発
はじめての UWP アプリ開発hiyohiyo
 
リブセンスのインフラで使ってるAnsibleのお話
リブセンスのインフラで使ってるAnsibleのお話リブセンスのインフラで使ってるAnsibleのお話
リブセンスのインフラで使ってるAnsibleのお話Shohei Koyama
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾外道 父
 
Ansible はじめてみました
Ansible はじめてみましたAnsible はじめてみました
Ansible はじめてみましたTakeshi Kuramochi
 
ほんとうはこわいAnsible
ほんとうはこわいAnsibleほんとうはこわいAnsible
ほんとうはこわいAnsibleTakahiro Nakayama
 
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみたShuntaro Saiba
 
Ansible Playbookの短時間デバッグ方法
Ansible Playbookの短時間デバッグ方法Ansible Playbookの短時間デバッグ方法
Ansible Playbookの短時間デバッグ方法Kishin Yagami
 
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu AsanoInsight Technology, Inc.
 
Ansibleで味わうHelion OpenStack
Ansibleで味わうHelion OpenStackAnsibleで味わうHelion OpenStack
Ansibleで味わうHelion OpenStackMasataka Tsukamoto
 
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。hiyohiyo
 
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!hiyohiyo
 

Viewers also liked (20)

AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンスAWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
 
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
 
AWS Black Belt Online Seminar Amazon EC2
AWS Black Belt Online Seminar Amazon EC2AWS Black Belt Online Seminar Amazon EC2
AWS Black Belt Online Seminar Amazon EC2
 
AnsibleによるHWプロビジョニング -OneViewの連携-
AnsibleによるHWプロビジョニング  -OneViewの連携-AnsibleによるHWプロビジョニング  -OneViewの連携-
AnsibleによるHWプロビジョニング -OneViewの連携-
 
Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)
 
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-
 
運用のためのPlaybook (Playbook for Operation)
運用のためのPlaybook (Playbook for Operation)運用のためのPlaybook (Playbook for Operation)
運用のためのPlaybook (Playbook for Operation)
 
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
 
はじめての UWP アプリ開発
はじめての UWP アプリ開発はじめての UWP アプリ開発
はじめての UWP アプリ開発
 
リブセンスのインフラで使ってるAnsibleのお話
リブセンスのインフラで使ってるAnsibleのお話リブセンスのインフラで使ってるAnsibleのお話
リブセンスのインフラで使ってるAnsibleのお話
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾
 
Ansible はじめてみました
Ansible はじめてみましたAnsible はじめてみました
Ansible はじめてみました
 
ほんとうはこわいAnsible
ほんとうはこわいAnsibleほんとうはこわいAnsible
ほんとうはこわいAnsible
 
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
 
Ansible Playbookの短時間デバッグ方法
Ansible Playbookの短時間デバッグ方法Ansible Playbookの短時間デバッグ方法
Ansible Playbookの短時間デバッグ方法
 
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
 
Ansibleで味わうHelion OpenStack
Ansibleで味わうHelion OpenStackAnsibleで味わうHelion OpenStack
Ansibleで味わうHelion OpenStack
 
What is an Ansible?
What is an Ansible?What is an Ansible?
What is an Ansible?
 
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
 
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
 

Similar to AWSスポットインスタンスの真髄

Automation with SoftLayer and Zabbix
Automation with SoftLayer and ZabbixAutomation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbixsoftlayerjp
 
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Masaya Aoyama
 
クラウドのなかみ
クラウドのなかみクラウドのなかみ
クラウドのなかみSatoshi Hirata
 
おすすめインフラ! for スタートアップ
おすすめインフラ! for スタートアップおすすめインフラ! for スタートアップ
おすすめインフラ! for スタートアップKoichiro Sumi
 
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」Serverworks Co.,Ltd.
 
ニフティクラウドを使った安定運用のススメ
ニフティクラウドを使った安定運用のススメニフティクラウドを使った安定運用のススメ
ニフティクラウドを使った安定運用のススメNIFTY Cloud
 
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learnedエンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons LearnedDaiki Kawanuma
 
NHNグループ合同勉強会 ライブドア片野
NHNグループ合同勉強会 ライブドア片野NHNグループ合同勉強会 ライブドア片野
NHNグループ合同勉強会 ライブドア片野livedoor
 
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)シスコシステムズ合同会社
 
サーバー初心者のためのWordPressサイト構築手順
サーバー初心者のためのWordPressサイト構築手順サーバー初心者のためのWordPressサイト構築手順
サーバー初心者のためのWordPressサイト構築手順IDC Frontier
 
Webアプリケーションは難しい
Webアプリケーションは難しいWebアプリケーションは難しい
Webアプリケーションは難しいTakafumi ONAKA
 
JAWS-UG クラウド専業SIer(CIer)になってみた結果
JAWS-UG クラウド専業SIer(CIer)になってみた結果JAWS-UG クラウド専業SIer(CIer)になってみた結果
JAWS-UG クラウド専業SIer(CIer)になってみた結果Serverworks Co.,Ltd.
 
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...whywaita
 
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015Toru Yamaguchi
 
AWSオンリーで実現するIoTクラウド基盤
AWSオンリーで実現するIoTクラウド基盤AWSオンリーで実現するIoTクラウド基盤
AWSオンリーで実現するIoTクラウド基盤Godai Nakamura
 
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1Yasuaki Matsuda
 

Similar to AWSスポットインスタンスの真髄 (20)

Automation with SoftLayer and Zabbix
Automation with SoftLayer and ZabbixAutomation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbix
 
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
 
クラウドのなかみ
クラウドのなかみクラウドのなかみ
クラウドのなかみ
 
おすすめインフラ! for スタートアップ
おすすめインフラ! for スタートアップおすすめインフラ! for スタートアップ
おすすめインフラ! for スタートアップ
 
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
 
ニフティクラウドを使った安定運用のススメ
ニフティクラウドを使った安定運用のススメニフティクラウドを使った安定運用のススメ
ニフティクラウドを使った安定運用のススメ
 
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learnedエンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
 
NHNグループ合同勉強会 ライブドア片野
NHNグループ合同勉強会 ライブドア片野NHNグループ合同勉強会 ライブドア片野
NHNグループ合同勉強会 ライブドア片野
 
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
 
ドリコムのインフラCI
ドリコムのインフラCIドリコムのインフラCI
ドリコムのインフラCI
 
サーバー初心者のためのWordPressサイト構築手順
サーバー初心者のためのWordPressサイト構築手順サーバー初心者のためのWordPressサイト構築手順
サーバー初心者のためのWordPressサイト構築手順
 
Webアプリケーションは難しい
Webアプリケーションは難しいWebアプリケーションは難しい
Webアプリケーションは難しい
 
Stac2014 石川
Stac2014 石川Stac2014 石川
Stac2014 石川
 
A1-6 ドメイン乗っ取られた!!
A1-6 ドメイン乗っ取られた!!A1-6 ドメイン乗っ取られた!!
A1-6 ドメイン乗っ取られた!!
 
JAWS-UG クラウド専業SIer(CIer)になってみた結果
JAWS-UG クラウド専業SIer(CIer)になってみた結果JAWS-UG クラウド専業SIer(CIer)になってみた結果
JAWS-UG クラウド専業SIer(CIer)になってみた結果
 
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
 
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
 
AWSオンリーで実現するIoTクラウド基盤
AWSオンリーで実現するIoTクラウド基盤AWSオンリーで実現するIoTクラウド基盤
AWSオンリーで実現するIoTクラウド基盤
 
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
 
ゆるかわPhp
ゆるかわPhpゆるかわPhp
ゆるかわPhp
 

Recently uploaded

スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムsugiuralab
 
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。iPride Co., Ltd.
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略Ryo Sasaki
 
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directoryosamut
 
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdfUPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdffurutsuka
 
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ       2024/04/12の勉強会で発表されたものです。新人研修のまとめ       2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。iPride Co., Ltd.
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000Shota Ito
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Danieldanielhu54
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxAtomu Hidaka
 

Recently uploaded (9)

スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
 
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
 
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
 
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdfUPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdf
 
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ       2024/04/12の勉強会で発表されたものです。新人研修のまとめ       2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
 

AWSスポットインスタンスの真髄

  • 1. Copyright gedow.net All Rights Reserved. 財布の紐を限界まで締める! AWSスポットインスタンスの真髄 外道父@GedowFather 2015/06/17 #2 市ヶ谷Geek★Night
  • 2. Copyright gedow.net All Rights Reserved. 2 自己紹介 ■私は 外道父@GedowFather ■所属 ドリコム ■職種 インフラエンジニア ■ブログ 外道父の匠
  • 3. Copyright gedow.net All Rights Reserved. 3 ま だ オ ン デ マ ン ド で お 布 施 し て る の ? そ ら ウ ハ ウ ハ で 売 上 高 を 公 開 し ち ゃ い ま す わ
  • 4. Copyright gedow.net All Rights Reserved. 4 目次 1. 基本と目的 2. 深イイ話 3. アーキテクチャ 4. その他の工夫
  • 5. Copyright gedow.net All Rights Reserved. 基本と目的
  • 6. Copyright gedow.net All Rights Reserved. 6 スポットインスタンスを三行で 1. 費用が超安い! 2. 起動が少し遅い! 3. 強制削除されるリスク!
  • 7. Copyright gedow.net All Rights Reserved. 7 安い理由は入札式  余っているリソースを使ってもらうため  需要と供給により価格が変動する  入札価格が変動価格を上回れば起動を継続 でき、下回れば強制削除される 入札価格 変動価格 起動できない 起動できる 強制削除 起動できる $0.1 $0.2 $0.01 $0.05 $1.0
  • 8. Copyright gedow.net All Rights Reserved. 8 費用の比較 オンデマンド 100% リザーブドインスタンス 55~75% スポットインスタンス 最小 14% 最大 1000%  リザーブドは事業規模の変化度合いに合わ ないし、1年経てばc3=>c4のような上位 互換が期待できるのでメインにはしない  スポットのワクワク感
  • 9. Copyright gedow.net All Rights Reserved. 9 価格変動の度合い  予測は不可能  xlarge以下は比較的 落ち着いている  それ以上は無慈悲な急騰が常 c3.4xlarge の平和な24時間 $0.15 ~ $0.25 c3.4xlarge のよくある一週間 最大 $5.0
  • 10. Copyright gedow.net All Rights Reserved. 10 高スペックの価格変動  c3.8xlarge は1ヶ月間に数十回も高騰  オンデマンドの 2~5倍  おまえらは誰と闘っているんだ状態 このオンデマンドは $1.68
  • 11. Copyright gedow.net All Rights Reserved. 11 起動時間が少し遅い  オンデマンドはポチッてから 約3~4分 で起動が完了する  スポットはまず入札処理が入り、入札が 成功してから起動に入るため 約7~8分 を必要とする
  • 12. Copyright gedow.net All Rights Reserved. 12 強制削除  入札価格 ≧ 変動価格 = セーフ  入札価格 < 変動価格 = アウト 一度でもアウトの条件を満たすと、 1~2分で強制的にTerminateされる 1分経過 スポット 入札価格 AWS神
  • 13. Copyright gedow.net All Rights Reserved. 13 基礎知識から導き出される結論 リスクを排除して スポットだけで 運用したら激安じゃない
  • 14. Copyright gedow.net All Rights Reserved. 深イイ話
  • 15. Copyright gedow.net All Rights Reserved. 15 リソースは全く同じ  オンデマンドのインスタンスも、スポッ トインスタンスも、元となるサーバーの リソースは全く同じ  スポットだからCPUやストレージの品質 が劣っているということは一切ない オンデマンド オンデマンド スポット ホストサーバー
  • 16. Copyright gedow.net All Rights Reserved. 価格ルール
  • 17. Copyright gedow.net All Rights Reserved. 17 変動/入札価格の最大値  変動価格はオンデマンド価格の10倍 まで跳ね上がる  入札価格も10倍までとなる オンデマンドが $0.294 なので 最大で $2.94 まで跳ね上がる
  • 18. Copyright gedow.net All Rights Reserved. 18 2015年4月中旬までの価格ルール  最大入札価格はオンデマンドの4倍まで  それ以上は申請して上限を引き上げる形式  価格の継続的な異常高騰を和らげるために 改定された 企業(A) 企業(B) スポットの存在意義にそぐわない利用状況にメスが入った 変更が入った瞬間、 オンデマ10倍以上の LaunchConfiguration では起動できなくなる というトラブルが発生 (外道式青天井界王拳20倍施策より)
  • 19. Copyright gedow.net All Rights Reserved. 19 強制Terminateを避けるテクニック 最大変動価格 = 最大入札価格 = オンデマの10倍 すなわち オンデマンドの 10倍で入札したら 落とされない!! 基本的にTerminate
  • 20. Copyright gedow.net All Rights Reserved. 安全な停止
  • 21. Copyright gedow.net All Rights Reserved. 21 入札価格超過以外の落とし穴  需要と供給の関係で成り立っているので、 需要が急増した場合は入札や変動価格の高 低に関わらず強制Terminateが走る可能性 がある  変動価格MAXでよく起こる  発動時に削除されるかは運
  • 22. Copyright gedow.net All Rights Reserved. 22 強制Terminateをインスタンス自身が知る ローカルのメタデータで、神様による無慈悲 なTerminate発動予定時間を取得できる http://169.254.169.254/latest/meta-data/spot/termination-time  普段は 404 Not Found を返す  価格超過やリソース不足によるTerminate確定か ら数秒後に200 OKと停止時刻を返すようになる  5秒間隔でのチェックを推奨されている  検知したら、新規リクエストの受け付けを停止す るなど、必要な処理を済ませる AWS
  • 23. Copyright gedow.net All Rights Reserved. 23 通常のインスタンス破棄前に任意の処理を行う  AutoScaleにおける起動完了前や削除実行 前に、任意秒を待機し、任意の処理を行う ための LifecycleHook という機能がある  削除前に待機することで、安心安全に落と すための処理を入れることができる ココで止まってもらい ココで必要な処理を行い 自身でシステムに通知するか、 任意秒が過ぎたら、 次のプロセス(削除処理)へ移る
  • 24. Copyright gedow.net All Rights Reserved. 制限値
  • 25. Copyright gedow.net All Rights Reserved. 25 入札数の制限  アカウントごとの設定に、EC2インスタン ス数の上限数が 20 といった制限値がある  入札数にも制限があり、デフォルトで 20 となっている  各種設定と同様、申請で引き上げ可能  入札数のカウントはインスタンスを削除し たらすぐ減るわけではないので、短時間で 起動と削除を繰り返すと入札できなくなる
  • 26. Copyright gedow.net All Rights Reserved. アーキテクチャ
  • 27. Copyright gedow.net All Rights Reserved. 27 メインをスポットにする覚悟を決める  入札価格をオンデマンドの10倍にす ることで強制Terminateを避ける  スポットの仕様変更や機能追加に追随 し続ける 『 コ ス ト を 抑 え る 』 『 安 全 に 運 用 し 続 け る 』 「 イ ン フ ラ エ ン ジ ニ ア 」の
  • 28. Copyright gedow.net All Rights Reserved. 28 制限値を上げる申請をする デフォルト値 申請値(例) EC2インスタンス数 20 400 入札数 20 400 AutoScalingGroup数 20 100  AutoScalingGroupは構築時に気づけるが、イ ンスタンス関連は運用に入ってから引っかかる可 能性があるので注意する  申請は1営業日もあれば通るので焦らなくてOK  多すぎず少なすぎず、気持ち多目に
  • 29. Copyright gedow.net All Rights Reserved. AutoScalingGroup
  • 30. Copyright gedow.net All Rights Reserved. 30 AutoScalingGroupを作成する Availability Zone [1a] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台
  • 31. Copyright gedow.net All Rights Reserved. 31 AutoScalingGroupを細かく分ける理由 Availability Zone [1a] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台  変動価格がインスタンスタイプ/AZ単位のため  複数のインスタンスタイプを併用し、高騰による 強制Terminateのリスクを減らすため  監視用グラフを永存したり、アプリログのサンプ リングを送信するため 10 グループ!
  • 32. Copyright gedow.net All Rights Reserved. 32 オンデマンドも併用する理由 スポットが不調な時に予備のスケールアウト となる 急激なスケールアウトが必要になった時、ス ポットより素早く起動できる 監視用インスタンスはホスト名やIPアドレス を固定で据え置きたい
  • 33. Copyright gedow.net All Rights Reserved. 33 スポットメインのスケール条件 スポット オンデマンド 監視用 min 1 1 1 max 100 100 1 CPU条件 増減率 CPU条件 増減率 increase(1) 40% 20%↑ 70% 20%↑ なしincrease(2) 80% 80%↑ 90% 80%↑ decrease 20% 20%↓ 40% 20%↓  平時はスポットだけが増設され、有事はオンデマンドも増設  落ち着けばオンデマンドから削減される  (スポット1~100✕4グループ)+(オンデマンド1✕6 グ ループ) が平時の台数となる
  • 34. Copyright gedow.net All Rights Reserved. 34 高騰したスポットは破棄する type AZ min max desired スポット c3 1a 1 100 25 1c 1 100 28 c4 1a 1 100 22 1c 1 100 25 オンデマ c3 1a 1 100 1 1c 1 100 1 c4 1a 1 100 1 1c 1 100 1 監視用 c3 1a 1 1 1 c4 1c 1 1 1 min max desired 1 100 25 0 0 0 1 100 22 1 100 25 1 100 1 1 100 1 1 100 1 1 100 1 1 1 1 1 1 1 高騰  グループ単位で価格を監視し、高騰と判断したらインスタン スを破棄してグループの稼働を停止する  残る3グループの負荷は上がるが平常運転の範囲内  価格が落ち着いたら、またスケールアウトを開始する
  • 35. Copyright gedow.net All Rights Reserved. 35 高騰と平常の判断条件  直近1時間平均を比較値とする  1時間に数十ある履歴の、価 格と割当時間から計算する  わずか数分の突発高騰でのイ ンスタンス破棄を防ぐため 16時に比較する値は $3.0 ではなく $0.5 程度になる 1時間平均の変動価格 = 比較値 高騰 if 比較値 ≧ オンデマンド価格✕1.2 平常 if 比較値 < オンデマンド価格✕0.8 ※条件を離すことで自動処理の連続発動を回避
  • 36. Copyright gedow.net All Rights Reserved. 36 高騰リスクの低減  c3だけだと1a&1cが同時に高騰する可能性が高く、最悪 リソースがゼロになるため、c4を併用することで最悪でも リソース半減に抑えられる  さらに m3/m4/r3 を併用という選択もありうる Spot c3 100% Spot c4 100% 1a Spot c3 100% Spot c4 100% 1c Spot c3 133% Spot c4 1a Spot c3 133% Spot c4 133% 1c 価格高騰により 1グループ死亡しても 残るグループの負荷は 4/3倍になるだけ
  • 37. Copyright gedow.net All Rights Reserved. 通常停止対策
  • 38. Copyright gedow.net All Rights Reserved. 38 LifecycleHookで安全にシャットダウン ココで3600秒止まってもらい インスタンス自身がLifecycleHookに 入ったと認識したら必要な処理を行い Complete通知を送って終了する。 完了までの時間はサービスの性質次第  スケールインや高騰時のグループインスタンス破棄において、 安全かつ必要な処理を済ませる  ELBから外す、ユーザー切断を待つ、タグを付ける、監視 サーバーから自ホストのデータを削除する  処理が完了したらAWSに通知を送ってTerminate
  • 39. Copyright gedow.net All Rights Reserved. 39 LifecycleHookの通知と問題点  LifecycleHookの通知はインスタンスが直接受けるのではな く、SNS/SQSを通して受け取る  メッセージ内にCompleteを送るためのトークンがある  SNSだと余剰サーバーが必要になるので却下  SQSだとインスタンス自身で取りにいけるが、キューは任 意のメッセージを受け取ることができない SNS 管理 サーバー 削除対象 サーバー SNSの場合 PUSH? PULL? SQS 削除対象 サーバー SQSの場合 こんなことで複雑な仕組みにしたくない キューから自身宛のメッセージを取得しづらい 何度も取得処理をして時間がかかる可能性がある
  • 40. Copyright gedow.net All Rights Reserved. 40 LifecycleHookの通知を取得する仕組み  10秒毎に全インスタンスでキューをチェック  あれば必ず1通は取得できるので、インスタンスIDとトーク ンを抜き出し、該当のインスタンスにタグを登録  さらにインスタンス自身のタグをチェックし、該当タグがあ れば削除前処理を行い、Complete通知をして完了する SQS 削除対象 サーバー (B) サーバー (C) サーバー (A) Send Message Get & Delete Message Create Tags  LifecycleTransition  LifecycleActionToken
  • 41. Copyright gedow.net All Rights Reserved. 41 Linuxのinitシステム管理では挙動が不確か  正常なシャットダウン処理の場合、initスクリプト に sleep を仕込むことでTerminateを遅らせるこ とができそうだが無理  Terminateによるshutdown実行後は、sleepで耐 えていても数分後にインスタンスを強制削除される  LifecycleHookが確実な手段だし、便利なのでオス スメ  だがトークンの受け取りが厳しい。メタデータに埋 め込んでくれ
  • 42. Copyright gedow.net All Rights Reserved. 強制停止対策
  • 43. Copyright gedow.net All Rights Reserved. 43 強制Terminateに備える http://169.254.169.254/latest/meta-data/spot/termination-time  入札価格超過によるTerminateはないが、需要/供 給のリソース不足で落とされるので仕込む  Bashデーモン  5秒間隔で監視し、検知したらLifecycleHookと 同じ削除前処理を実行する
  • 44. Copyright gedow.net All Rights Reserved. 44 唯一の弱点  1回1回の処理時間が短いHTTPは問題ない  1つの処理に数分数十分以上の持続接続が必要な場 合は、クライアントやジョブの処理終了に間に合わ ず落とされてしまう  WebSocket / MQTT や 集計処理 など  切断時にクライアント再接続やジョブ再実行する仕組み  Terminateを検知した時点でそれを促す仕組み Terminate検知 Terminate実行1~2分間 HTTP 長時間の持続接続サービス この間に処理を安全に終えられるか が分かれ目となる 過ぎるとユーザーに 不利益が生じるため 工夫が必要になる クライアントが強制切断される
  • 45. Copyright gedow.net All Rights Reserved. 費用効果
  • 46. Copyright gedow.net All Rights Reserved. 46 オンデマンドのみと併用の比較  オンデマンドのコストを 100 とする  好調スポットのコストを 15 とする  最小台数と大規模台数でそれぞれ、同台 数におけるオンデマンドのみのコストと、 スポット構成のコストを比較する
  • 47. Copyright gedow.net All Rights Reserved. 47 最小台数の場合 Availability Zone [1a] Spot c3 1台 Spot c4 1台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 1台 Spot c4 1台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台 Spotコスト = 1台✕4グループ✕15 = 60 Ondemandコスト = 1台✕6グループ✕100 = 600 Spot + Ondemand = 660 Ondemandのみ = 1000>34%削減
  • 48. Copyright gedow.net All Rights Reserved. 48 大規模台数の場合 Availability Zone [1a] Spot c3 30台 Spot c4 30台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 30台 Spot c4 30台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台 Spotコスト = 30台✕4グループ✕15 = 1800 Ondemandコスト = 1台✕6グループ✕100 = 600 Spot + Ondemand = 2400 Ondemandのみ = 12600>81%削減
  • 49. Copyright gedow.net All Rights Reserved. 49 1時間平均の価格変動グラフ(1ヶ月間) Ondemand価格 Ondemand価格 c3.xlarge c4.xlarge ほぼオンデマンドの 20~25%をキープ 一時荒れるも避難し、 大半を最低価格の 14%でキープ
  • 50. Copyright gedow.net All Rights Reserved. 50 インスタンスタイプの選択  希望は 2xlarge あたりだった  最初に採用したのは c3/c4.xlarge  c4がご乱心 & m3が安定したので c3/m3.xlarge に避難  m2 は安定しているがHVM非対応  新しい m4 は多分、数カ月後に荒波  CC2/CR1 もわりとブルーオーシャン  高スペック+Dockerという手も……
  • 51. Copyright gedow.net All Rights Reserved. 51 オンデマンドいる?  いざ運用してみると、思いの外スポットのス ケールアウトだけで稼働できてしまう  オンデマンドがいらない気になるけど、そこ までスポットは信用するべきものでもない  最終防衛ライン  1セットにつき6つのオンデマンドが確定な ので、リザーブドインスタンスを適用すると さらに削減できる
  • 52. Copyright gedow.net All Rights Reserved. その他の工夫
  • 53. Copyright gedow.net All Rights Reserved. 53 AutoScalingGroup管理の簡略化  LaunchConfigurationが多い  production / staging  spot / ondemand  c3 / c4  AutoScalingGroupが多い  同上  1a / 1c  監視用  CloudWatchが多い  Increase (peace / pinch)  Decrease  監視用は除く >合計8件 >合計20件 >合計48件 自動化した 作成・削除・更新など全て
  • 54. Copyright gedow.net All Rights Reserved. 54 独自TimeBasedスケールアウト 12時 23時  サービスの性質上、12時と23時がピークタイムであり、 12~23時の間はイベントやメンテナンスによる急激な 増減がある。特にメンテ明けの台数は危険  11:30 にMinSizeを、その時点のInService✕N倍の台 数に強制増設する(1.5~3倍)  23:30 にMinSizeを元に戻す  日中の台数節約放棄の代わりに運用し易さと安定を得る 強制Increase 自然な増減に 切り替え 最低台数を キープ
  • 55. Copyright gedow.net All Rights Reserved. 55 AZ間のレイテンシ差に対応する(1) AZ [1a] EC2 AZ [1c] EC2 RDS 速い 少し遅い  RDSやElastiCacheが同じAZにあるとレイ テンシが低い  違うAZからだと遅くはないが、同AZより はレイテンシが高い AZ [1a] Spot c3 10台 Spot c4 9台 AZ [1c] Spot c3 3台 Spot c4 2台  レイテンシが低いほど多くCPU 処理をできるためスケールアウ トされやすい  CPU性能が低いほどスケールア ウトされやすい  AZとインスタンスタイプで台 数に偏りが出ると、リスクも偏 ることになる
  • 56. Copyright gedow.net All Rights Reserved. 56 AZ間のレイテンシ差に対応する(2) AZ [1a] Spot c3 6台 Spot c4 6台 AZ [1c] Spot c3 3台 Spot c4 2台 Max 6 Max 6 Max 100 Max 100 グループごとの台数を監視 最低台数より+4台以上の グループはMax値を抑える Max = Desired 差が狭まったらMaxを戻す この仕掛による挙動とリスク 抑えつけたグループの分、スケールアウトの全体増加率が 減少するため、1グループあたりの増加率で調整する Increase条件がCPU 40%だとすると、抑えつけたグルー プはCPU60%前後にまで上がる  AZを分けなくても、実はそもそもこうなっているはず  リソースを多目に消費することは台数節約でもある
  • 57. Copyright gedow.net All Rights Reserved. 57 スクリプトで AWS CLI を使わない  AWS CLIは重い(CPUをメチャ喰う)  手動や数時間に1回の実行ならば問題ない  数十秒単位だとCPU利用率のグラフが常に10%前 後など無駄すぎる消費  重いのは認証処理  シェルのコマンドベースだと毎回この処理が入る  軽量プログラミング言語+SDKで書けば、認証 を確保したままループ処理をできるため軽い  最初はBashで書いたがRubyに書きなおした  手動実行 管理スクリプト  自動実行 ジョブスクリプト  監視アラート/グラフ用 値出力スクリプト
  • 58. Copyright gedow.net All Rights Reserved. 58 AWS Japan と同じ社屋に入る アルコタワー アネックス Amazon Japan アルコタワー 19F AWS Japan 17F ドリコム 他の階も Amazonが 徐々に侵食中  相談や新着情報を伝えに天上界から降りてきてくれ、終 わると天上界にお帰りになられる  天上界にお伺いし、USチームと電話会議したり、来日し ているとディープな情報交換できる(完璧な通訳付き)
  • 59. Copyright gedow.net All Rights Reserved. 59 俺 の コ ス ト が 高 騰 し ち ま う か ら な ! で も …… で も で も ス ポ ッ ト は 怖 い し や め た ほ う が い い と 思 う よ ! fin