AWSを実用するために - AWSらしいコスト削減 -

JAWS-UG Osaka 第9回勉強会

<Beginners & ServiceProviders>

2013.11.02　桶谷 拓也

Who am I ?• 桶谷 拓也（おけたに たくや） • 業務系エンジニア 無職 update!! • JAWS-UG Osaka • AWS認定ソリューションアーキテクト - アソシエイト • Tw：@okeee0315　/　Fb：okeee0315 • Like：CloudFormation / SQS/Queuing Chain/Self Registration • クラウド/HTML5/Node.js

ハッシュタグ #jawsug

Original Update by stevegarfield / http://www.flickr.com/photos/stevegarfield/

アジェンダ

‣さらっとおさらい ‣AWSで必要になるコスト ‣安い？高い？ ‣仮想マシンをなんとかしよう ‣さらなるコスト削減

さらっとおさらい

Amazon Web Services

RDS

EC2

S3

Amazon Web Services

RDS

EC2

S3

Elasticity

Amazon Web Services

RDS

EC2

S3

VPC

IAM

ELB

Amazon Web Services

RDS

EC2

S3

VPC

IAM

ELB

Elasticity ＋

Information Security

Amazon Web Services

RDS

EC2

S3

VPC

IAM

ELBCloudFormation

Amazon Web Services

RDS

EC2

S3

VPC

IAM

ELBCloudFormation

Elasticity ＋

Information Security

＋ Programmable

これで AWSデビューできるぜ！

Original Update by mozillaeu / http://www.flickr.com/photos/mozillaeu/

AWSが良いのはわかった。 で、なんぼ？

続きはこちらで

http://bit.ly/JAWSO09

ということで続きです。 前回のSlideは

http://bit.ly/iegg-01

AWSで必要になるコスト

Original Update by stopnlook/ http://www.flickr.com/photos/crazyneighborlady/

What's Cost ?

‣開発

‣保守運用

‣ソフトウェア購入

‣インフラ

...etc

What's Cost ?

‣開発

‣保守運用

‣ソフトウェア購入

‣インフラ

...etc

AWSは全てに影響する

AWSの課金ポイント

‣仮想マシン

EC2, RDS

‣ストレージ

S3, EBS

‣通信

AWSの課金ポイント

‣仮想マシン

EC2, RDS

‣ストレージ

S3, EBS

‣通信

仮想マシンが総額の7,8割

AWSの課金ポイント

‣仮想マシン

EC2, RDS

‣ストレージ

S3, EBS

‣通信

ココを減らすことが最優先

仮想マシンの課金ポイント

‣数（台数）

‣稼働時間

‣インスタンスタイプ

仮想マシンの課金ポイント

‣数（台数）

‣稼働時間

‣インスタンスタイプ

$0.35 / h のインスタンスタイプを10台、1ヶ月稼働させると

　$0.35 × 10台 × (24h × 30d) = $2,520

仮想マシンの課金ポイント

$0.35 / h のインスタンスタイプを10台、1ヶ月稼働させると

　$0.35 × 10台 × (24h × 30d) = $2,520 1年間だと

$2,520 × 12m = $30,240

安い？ 高い？

Original Update by byJoeLodge / http://www.flickr.com/photos/joe57spike/

$30,240/年で何ができるか？‣約300万円

‣いいPC 10台(30万 × 10台) とか

‣それなりのサーバー 3台(100万 × 3台)

クラウドは安いんじゃないの？

Original Update by vauvau / http://www.flickr.com/photos/vauvau/

AWSは安い、という幻想

‣安くない

‣高くはないかもしれない

‣安く、出来る

AWSは安い、という幻想

‣安くない

‣高くはないかもしれない

‣安く、出来る安く、出来る

仮想マシンを何とかしよう

‣最初に行うことは分析 ‣まずは己を知る ‣本当に必要な部分を見極める

仮想マシンを何とかしよう

‣数（台数）、稼働時間、インスタンスタイプ

‣不要なインスタンスは止める

‣不要な時間は止める

‣不要な性能は減らす

分析してみる

WebServer(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

分析してみる

WebServer(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

！？

あるある その①

‣何に使用しているかわからないEC2インスタンス

‣何故か起動している

‣元々あったから

あるある その①

‣何に使用しているかわからないEC2インスタンス

‣何故か起動している

‣元々あったから

そんなインスタンスは問答無用でTerminate！

分析してみる

WebServer(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

分析してみる

WebServer(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

開発用って24/365の必要ある？

あるある その②

‣開発で使用しているインスタンスが24/365で起動

‣早朝、深夜、休みの日もしっかり起動

誰がそんな時間に開発するんだっ! 開発する時だけ起動しるっ！

あるある その②

‣開発用は9:00～18:00のみ起動するように

‣土日も起動しない

‣必要な場合は手動、他は自動がベスト

‣ 24h → 8h で コストが1/3に

あるある その②

‣時間指定でのインスタンス起動/停止はOpsWorksで提供されている

‣ AWS CLI for /F %i in ('aws ec2 describe-instances --filters "Name=tag-key,Values=Stack" "Name=tag-value,Values=development" "Name=instance-state-name,Values=running" --profile profile1 ^| jq .Reservations[].Instances[].InstanceId') do (aws ec2 stop-instances --instance-ids %i --profile profile1)

分析してみる

WebServer(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

分析してみる

WebServer(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中パターン１

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中パターン２

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

最初からWebServer2台？

あるある その③

‣最初から無駄に大きな構成

!

構成は需要に合わせて拡大して いけばいい！

あるある その③

‣クラウドなのでElasticityに

‣ Auto Scaling

‣可用性、SLAとのバランス

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

監視Server？

あるある その④

‣何でもかんでもEC2

‣オンプレミスからの”そのまま”の移行

!

オンプレミス脳を捨てよ！

あるある その④

‣ AWSで提供されているEC2以外のサービスを上手く活用する

‣必要な要件を見極める

‣ ServiceProviders に相談

‣ JAWS-UG の活用

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

CloudWatch を使う

CloudWatch

‣ AWSのリソースを監視するサービス

‣サービスごとに定義された監視項目（メトリクス）

‣メトリクスに対してアラームを設定出来る

‣アラーム時に通知を送ることが出来る

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

分析してみる

ALL Server(開発)

WebServer(開発)

DBServer(開発)

AppServer(開発)

監視Server

WebServer(本番)

WebServer(本番)

DBServer(本番)

AppServer(本番)

用途不明

全てm1.large, 24/365稼働中

この時点で 約1/3に

$30,240/年が1/3になると

‣約200万円のコスト削減

‣その分を開発に回してサービスの拡充

‣開発環境をより良く

みんなHappy!!

Original Update by dborman2 / http://www.flickr.com/photos/dborman2/

さらなるコスト削減

Original Update by dborman2 / http://www.flickr.com/photos/dborman2/

さらなるコスト削減

‣ Reserved Instance

‣ Spot Instance

‣ Region

‣ Non EC2

Reserved Instance

‣ Instance の予約購入

‣予約金を先に払うことで時間課金を軽減

0

17.5

35

52.5

70

n 月 n+1 月 n+2 月 n+3月

オンデマンド リザーブド

Reserved Instance

‣長期に渡ったInstanceの稼働に適している

‣ 1年間 or 3年間

‣サービスイン後、様子を見ながらRIを購入

Spot Instance

‣オークション形式

‣ Spot 価格 ＜ 入札価格の時にInstanceが起動

‣入札価格は上限を入力

‣ Spot 価格は変動する（最近高騰中）

Spot Instance

‣なんか試したいとき

‣いつでもいいけど実行したいバッチ処理

‣入札価格をオンデマンドと同じに

Region

‣ Region毎に時間単価が変わる

‣東京は高い

‣オレゴン、バージニアが安い

Region

‣距離が離れればサービスの応答が遅れる

‣応答性が求められない部分で使用する

Non EC2

‣ EC2(RDB)を用いないシステム構成

‣ S3による静的サイトホスティング

‣ KVS(SimpleDB、DynamoDB)の活用

Non EC2

間に合わなかったので次回！

Original Update by jlodder / http://www.flickr.com/photos/jlodder/

Original Update by stevendepolo / http://www.flickr.com/photos/stevendepolo/

Question？