Spot Fleetを使ってEC2を1/4の料金で運用する

はじめに

普段EC2でサーバーを運用してるのですが、スポットインスタンスを使うことで約1/4の料金で利用できてます。

スクリーンショット 2018-01-08 13.40.58.png

スポットインスタンスについて

スクリーンショット 2018-01-08 13.11.12.png

  • 基本的にオンデマンドインスタンスに比べてかなり安いがオンデマンドインスタンスより値段が高くなる場合もある
  • 設定した最高価格の値段より高くなった時にデフォルトの動作だとインスタンスが削除される

停止にする設定もあります。

https://aws.amazon.com/jp/about-aws/whats-new/2017/09/amazon-ec2-spot-can-now-stop-and-start-your-spot-instances/

容量が指定料金内で利用不可能になりイベントが中断された場合に、Amazon EC2 スポットで Amazon EBS-backed インスタンスを終了する代わりに、それを停止することが可能になりました。

  • 同じインスタンスタイプでもavailability zoneで値段が違う
  • 上位のインスタンスタイプのほうが安くなる場合もある

最高価格

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-spot-instances-history.html

スポットインスタンスをリクエストするときは、デフォルトの上限料金 (オンデマンド料金) を使用することをお勧めします。

スポットインスタンスのインスタンスの価格がオンデマンドインスタンスの価格より高くなる場合があるので、オンデマンドインスタンスの上限に設定にしておいたほうがいいということだと思われます。

Spot Fleet

Spot Fleetを使うことで、予め最高価格と復数のインスタンスタイプとAvailability Zoneを設定しておくことでその中で一番安いスポットインスタンスをn個用意するということを自動で出来るようになります。

また動かしてるスポットインスタンスのインスタンスタイプの価格が高騰して停止した場合に、設定した他の安い条件のものがあった場合にそちらが新規で立ち上がるようになります。

Terraformを使ったECSで使う場合の設定例

user_data/ecs.sh.tpl
#!/bin/bash

echo ECS_CLUSTER=${ecs_cluster} >> /etc/ecs/ecs.config
aws_default_subnet.tf
resource "aws_default_subnet" "1a" {
  availability_zone = "${data.aws_region.current.name}a"
}

resource "aws_default_subnet" "1c" {
  availability_zone = "${data.aws_region.current.name}c"
}
aws_spot_fleet_request.tf
data "template_file" "aws_instance_app_user_data" {
  template = "${file("user_data/ecs.sh.tpl")}"

  vars {
    ecs_cluster = "app"
  }
}

data "aws_ami" "ecs_optimized" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "name"
    values = ["amzn-ami-*-amazon-ecs-optimized"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "block-device-mapping.volume-type"
    values = ["gp2"]
  }
}

resource "aws_spot_fleet_request" "app" {
  iam_fleet_role  = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/aws-ec2-spot-fleet-tagging-role"
  spot_price      = "0.1290"
  target_capacity = "2"
  valid_until     = "2019-11-04T20:44:20Z"
  terminate_instances_with_expiration = true

  launch_specification {
    ami = "${data.aws_ami.ecs_optimized.id}"
    instance_type = "t2.large"
    iam_instance_profile = "${aws_iam_instance_profile.app.name}"
    vpc_security_group_ids = ["${aws_security_group.app.id}"]
    user_data       = "${data.template_file.aws_instance_app_user_data.rendered}"
    subnet_id       = "${aws_default_subnet.1a.id}"
    associate_public_ip_address = true

    tags {
      Name = "app"
    }
  }

  launch_specification {
    ami = "${data.aws_ami.ecs_optimized.id}"
    instance_type = "m4.large"
    iam_instance_profile = "${aws_iam_instance_profile.app.name}"
    vpc_security_group_ids = ["${aws_security_group.app.id}"]
    user_data       = "${data.template_file.aws_instance_app_user_data.rendered}"
    subnet_id       = "${aws_default_subnet.1a.id}"
    associate_public_ip_address = true

    tags {
      Name = "app"
    }
  }

  launch_specification {
    ami = "${data.aws_ami.ecs_optimized.id}"
    instance_type = "m4.large"
    iam_instance_profile = "${aws_iam_instance_profile.app.name}"
    vpc_security_group_ids = ["${aws_security_group.app.id}"]
    user_data       = "${data.template_file.aws_instance_app_user_data.rendered}"
    subnet_id       = "${aws_default_subnet.1c.id}"
    associate_public_ip_address = true

    tags {
      Name = "app"
    }
  } 
}

この設定の場合t2.largeのap-northeast-1a、m4.largeのap-northeast-1a, m4.largeのap-northeast-1cの中で一番安いもので、かつその料金が$0.1290以下の場合の時にEC2インスタンスを2つ動いてる状態にするという動作になります。
$0.1290はm4.largeのオンデマンドインスタンスの価格です。

またSpot Fleetの有効期限は2019-11-04T20:44:20Zで有効期限が切れた場合にインスタンスを停止するという設定になります。

最後に

一時的にサーバーが止まっても問題ない用途に使う場合は問題ないですが、ダウンタイムをないように運用するのはオンデマンドインスタンスと併用するなど工夫が必要です。

続きを読む

TerraformでAWS AMIの最新を常に使うようにする

TerraformとAWSに同時入門する
の続きで、

最新のAMIが常に指定されるようなami設定にする

を行えるようにします。

確認環境

$ terraform version
Terraform v0.11.1
+ provider.aws v1.5.0

取得するAMIのスペック

今回は2017/12/10時点でのAmazon Linuxの下記スペックにおける最新AMI ID(ami-da9e2cbc)を取得します。
最新AMI IDはこちらで確認できます: Amazon Linux AMI ID

  • リージョン: アジアパシフィック東京
  • 仮想化タイプ: HVM
  • ルートデバイスタイプ: EBS-Backed
  • アーキテクチャ: x86_64
  • ボリュームタイプ: gp2

:warning: 注意点
AMI IDはリージョン毎に異なるようなので複数リージョンにまたがった環境の場合は注意が必要かもしれません

結論

簡易版

フィルタ条件はAMI Image名の条件のみ

aws_ami.tf
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn-ami-hvm-*-x86_64-gp2"]
  }
}

詳細版

フィルタ条件として今回の指定スペックをすべて指定

参考: Terraformでもいつでも最新AMIからEC2を起動したい

aws_ami.tf
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "name"
    values = ["amzn-ami-hvm-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "block-device-mapping.volume-type"
    values = ["gp2"]
  }
}

EC2側の設定

ec2.tf
resource "aws_instance" "web-server" {
  ami                    = "${data.aws_ami.amazon_linux.id}"
  instance_type          = "t2.micro"
}

確認

$ terraform plan

  + aws_instance.web-server
      id:                           <computed>
      ami:                          "ami-da9e2cbc"
      ...

AWS CLIでAmazon Linux AMI image名を取得してみる

準備

AWS Command Line Interface のインストール

簡易版のフィルタ条件の説明

AWS CLIで最新のAmazon LinuxのAMI IDを取得する
上記でのシェルを参考に今回取得したい条件に変更します

get-aws-ec2-image.sh.sh
...

describe_images(){
    echo $timestamp > $timestamp_file
    aws ec2 describe-images 
-       --owners self amazon 
+       --owners amazon 
        --filters 
+         Name=name,Values="amzn-ami-hvm-*" 
          Name=virtualization-type,Values=hvm 
          Name=root-device-type,Values=ebs 
          Name=architecture,Values=x86_64 
-         Name=block-device-mapping.volume-type,Values=standard
+         Name=block-device-mapping.volume-type,Values=gp2
}

...

実行結果

$ zsh ./get-aws-ec2-image.sh

amzn-ami-hvm-2014.03.2.x86_64-gp2: ami-df470ede
amzn-ami-hvm-2014.09.0.x86_64-gp2: ami-45072844
amzn-ami-hvm-2014.09.1.x86_64-gp2: ami-4585b044
amzn-ami-hvm-2014.09.2.x86_64-gp2: ami-1e86981f
amzn-ami-hvm-2015.03.0.x86_64-gp2: ami-cbf90ecb
amzn-ami-hvm-2015.03.1.x86_64-gp2: ami-1c1b9f1c
amzn-ami-hvm-2015.09.0.x86_64-gp2: ami-9a2fb89a
amzn-ami-hvm-2015.09.1.x86_64-gp2: ami-383c1956
amzn-ami-hvm-2015.09.2.x86_64-gp2: ami-59bdb937
amzn-ami-hvm-2016.03.0.x86_64-gp2: ami-f80e0596
amzn-ami-hvm-2016.03.1.x86_64-gp2: ami-29160d47
amzn-ami-hvm-2016.03.2.x86_64-gp2: ami-6154bb00
amzn-ami-hvm-2016.03.3.x86_64-gp2: ami-374db956
amzn-ami-hvm-2016.09.0.20160923-x86_64-gp2: ami-1a15c77b
amzn-ami-hvm-2016.09.0.20161028-x86_64-gp2: ami-0c11b26d
amzn-ami-hvm-2016.09.1.20161221-x86_64-gp2: ami-9f0c67f8
amzn-ami-hvm-2016.09.1.20170119-x86_64-gp2: ami-56d4ad31
amzn-ami-hvm-2017.03.0.20170401-x86_64-gp2: ami-859bbfe2
amzn-ami-hvm-2017.03.0.20170417-x86_64-gp2: ami-923d12f5
amzn-ami-hvm-2017.03.1.20170617-x86_64-gp2: ami-bbf2f9dc
amzn-ami-hvm-2017.03.1.20170623-x86_64-gp2: ami-3bd3c45c
amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2: ami-4af5022c
amzn-ami-hvm-2017.03.rc-0.20170320-x86_64-gp2: ami-be154bd9
amzn-ami-hvm-2017.03.rc-1.20170327-x86_64-gp2: ami-10207a77
amzn-ami-hvm-2017.09.0.20170930-x86_64-gp2: ami-2a69be4c
amzn-ami-hvm-2017.09.1.20171103-x86_64-gp2: ami-2803ac4e
amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc
amzn-ami-hvm-2017.09.rc-0.20170913-x86_64-gp2: ami-d424e7b2

最新AMI ID(ami-da9e2cbc)が取得できているのがわかります。

amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc

取得結果からわかるようにImage名にはスペック名も含まれていることがわかります。

よって今回のスペックのAMI IDはImage名でのフィルタ条件のみで取ることができるため、簡易版ではImage名の値が"amzn-ami-hvm-*-x86_64-gp2"とするフィルタ条件1つで最新のAMI IDを取得していました。

また、aws_ami.tfではmost_recent = trueという設定により取得した中で最新のAMI IDが取得されます。

:warning: Image名の命名規則が変更された場合に指定スペックの最新が取得できなくなるので注意ください

フィルタ条件をnameのみにしてAWS CLIでも確認

AWS CLI側でも一応確認

get-aws-ec2-image.sh
describe_images(){
    echo $timestamp > $timestamp_file
    aws ec2 describe-images 
        --owners amazon 
        --filters 
          Name=name,Values="amzn-ami-hvm-*-x86_64-gp2" 
-          Name=virtualization-type,Values=hvm 
-          Name=root-device-type,Values=ebs 
-          Name=architecture,Values=x86_64 
-          Name=block-device-mapping.volume-type,Values=gp2
}
$ zsh ./get-aws-ec2-image.sh | grep ami-da9e2cbc

amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc

最新AMI ID(ami-da9e2cbc)が取得できているのがわかります。

その他の参考

続きを読む

re:Invent 2017 TUESDAY NIGHT LIVEまとめ

Fusic Advent Calendar 2017 の3日目の記事です。

re:Invent 2017では下記の3つの基調講演で様々なサービスや新機能が発表されました。
・TUESDAY NIGHT LIVE
・KEYNOTE DAY1
・KEYNOTE DAY2

本日はTUESDAY NIGHT LIVEについてまとめました。

TUESDAY NIGHT LIVE

大きく下記の3テーマが語られます。
・COMPUTING AT SCALE
・LOAD BALANCING AT SCALE
・SECURIRY AT SCALE

「SCALE」という言葉が強調されてますね。

ANATOMY OF AN AWS REGION

https://www.youtube.com/watch?time_continue=124&v=dfEcd3zqPOA#t=7m23s

・AWSは最初の5年で4リージョン、次の5年で7リージョンを開設してきました。(10年で11リージョン)
・そして、2016年、2017年、2018年でさらに11リージョンを開設します。
・これらのリージョン間のネットワークを強化してグローバルなよりネットワークにしていく

COMPUTING AT SCALE

https://www.youtube.com/watch?time_continue=124&v=dfEcd3zqPOA#t=14m01s

・ここ数年でGPU & FPGAの利用が急成長している
・P3インスタンスの利用方法についての説明
 -> 機械学習
  -> 自動運転に関する企業の紹介

 1. ハードウェアの進化
 2. 機械学習フレームワーク
 3. 急成長するコミュニティ(GLUON)

AMAZON EC2 INSTANCES

https://www.youtube.com/watch?time_continue=124&v=dfEcd3zqPOA#t=27m33s

・Amazon EC2の基本的なアーキテクチャの説明
・EC2の進化
 1. EC2 Hosts
 2. EC2 Managment Services
 3. Amazon EBS
 4. Nitro System(AWS独自開発のクラウド基盤)

・EC2の目標
1. セキュリティ
 AWSの最も大事な品質はセキュリティとも語っている
2. パフォーマンス
 EC2インスタンスパフォーマンスは、他のパフォーマンス全てに関わる重要事項
3. 親しみやすさ

・Nitro System
1. C3インスタンス
 -> ネットワークパケットのプロセスをNitro Systemに移行
 -> レイテンシーの50%向上
2. C4インスタンス
 -> ストレージのプロセスをNitro Systemに移行
 -> EBS最適化がデフォルト化
 -> 12.5%計算力向上
3. C5インスタンス
 -> Custom Nitro ASICを選択
 -> Annapurna labsが開発
 -> Custom Nitro ASICを導入したのがC5インスタンス(Nitro Hypervisor)
  -> コアの技術はKVM
4. Bare Metal Instances

例) AUTODESK

https://www.youtube.com/watch?time_continue=124&v=dfEcd3zqPOA#t=48m44s
・機械学習による設計
・GENERATIVE DESIGN
・GENERATIVE DESIGNによって飛行機のドアなどを設計

https://www.autodesk.co.jp/solutions/3d-design-software?referrer=%2Fsolutions%2F3d-design-software

LOAD BALANCING AT SCALE

https://www.youtube.com/watch?time_continue=124&v=dfEcd3zqPOA#t=1h04m32s
・AWS最初のLOAD BALANCING紹介(32MB)

THE GOLDEN AGE PF HARDWARE LOAD BALANCIERS

・GOOD
・信頼性、スケーラビリティ、俊敏性を実現する簡単な方法
・プロバイダの増加、パフォーマンスの向上、機能の向上、コストの削減

・BAD
・ロードバランサーのコストの割合が増加している
・運用上の課題

ロードバランサーの問題点① BLACK BOX

・ハードウェアがブラックボックス化しており、問題を課題を解決できない
・他のユーザの真ん中ぐらいで利用して最初に問題に直面しないようにしていた

ロードバランサーの問題点② Virtual IPの数

・設定が煩雑
・10年前のVIP数 6,000
・現在のVIP数 600,000

Hyperplane

HARDWARE LOAD BALANCIERS
・2Nアーキテクチャでは最大で50%の利用率になる

S3 LOAD BALANCIERS
・Hyperplane(S3 分散型 ロードバランサー)

下記のサービスで利用されている
1. Amazon Elastic File System(EFS)
2. AWS Managed NAT
3. AWS Network Load Balancer(NLB)
4. AWS PrivateLink

PrivateLink (個人的に大注目)

・インターネットを介さずにサービスにアクセス可能
・複数アクセス間のVPCに対してサービス提供が可能
・APNはもっと簡単にサービス提供が可能

SECURIRY AT SCALE

https://www.youtube.com/watch?time_continue=124&v=dfEcd3zqPOA#t=1h22m50s
・自動化とツール化
・機械学習
・ベストプラクティス
・パートナー

・開発者もセキュリティエンジニアでもある
・AWSはセキュリティ対策を自動化している

AMAZON MACIE

・データアクセスアクティビティのモニタリング

AMAZON GuardDuty

・AWSアカウント全体の監視

※ セキュリティのポイント:人をデータから引き離す
※ AWSの文化はセキュリティを非常に大切にする

参考サイト
https://aws.amazon.com/jp/about-aws/events/reinvent2017-1128/
https://dev.classmethod.jp/cloud/aws/aws-reinvent-tuesdaynightlive-engineers-eye/
https://dev.classmethod.jp/cloud/aws/aws-reinvent-2017-keynote-day-1/
https://dev.classmethod.jp/cloud/aws/aws-reinvent-2017-keynote-day-2/
https://www.youtube.com/playlist?list=PLhr1KZpdzukfZxFGkA796dKaUufAgnU4c

続きを読む

CentOS 7でAmazon EBSのボリュームを拡張する

Amazon EC2インスタンスとしてCentOS 7を選んだ場合にAmazon Elastic Block Store(EBS)のボリュームを拡張する方法です。

本稿では以下の手順に従ってその方法を説明します。

  1. Amazon EBSボリュームを拡張する
  2. ブロックデバイス(/dev/xvda1)のサイズを拡張する

確認した動作環境

  • OS(EC2インスタンス): CentOS Linux release 7.3.1611 (Core)

前提条件

ファイルシステムは CentOS 7標準の「XFS」 であることを前提とします。

ファイルシステムの種類は以下のコマンドを入力することで確認することができます。

$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     xfs        16G   16G   0G  99% /
...
...
...

dfコマンド

df コマンドは、システムのディスク領域の使用量についての詳しいレポートを表示します。

18.4. ブロックデバイスとファイルシステムの表示 – Red Hat Customer Portal

-Tはファイルシステムの種類を表示するオプションです。

Amazon EBSボリュームを拡張する

Amazon EBSボリュームの料金体系を確認する

Amazon EBSボリュームを拡張した場合、どれくらいの費用がかかるのかを事前に確認しておきましょう。

リージョンが「アジアパシフィック(東京)」の場合(2017年11月27日現在)

ボリューム 料金(ドル) 料金(円) 単位
Amazon EBS 汎用 SSD (gp2) ボリューム $0.12 12.6円(105円/ドルとした場合) 1 か月にプロビジョニングされたストレージ 1 GB あたり

「Amazon EBS 汎用 SSD (gp2) ボリューム」の場合、I/Oはボリュームの料金に含まれているため、 プロビジョニングした各ストレージのGBに対してのみ課金されます。

最新の料金体系は「料金 – Amazon Elastic Block Store(ブロックストレージ)|AWS」から確認することができます。

「Amazon EC2 コンソール」からEBSのボリュームサイズを変更する

コンソールからEBSのボリュームサイズを変更する手順は
コンソールからの EBS ボリュームの変更 – Amazon Elastic Compute Cloud」から確認することができます。

これまでの手順でEBSのボリュームサイズを変更することができますが、続いてブロックデバイスのサイズを拡張する必要があります。

ブロックデバイス(/dev/xvda1)のサイズを拡張する

ブロックデバイスのサイズを確認する

以下のコマンドを入力してブロックデバイスのサイズを確認しましょう。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  32G  0 disk
└─xvda1 202:1    0  16G  0 part /

上記の例ではxvda1のサイズが16Gであることが分かります。

lsblkコマンド

lsblk コマンドを使用すると、利用可能なブロックデバイスの一覧を表示できます。

一覧表示された各ブロックデバイスについて lsblk コマンドが表示するのは次のとおりです。デバイス名 (NAME)、メジャーおよびマイナーデバイス番号 (MAJ:MIN)、リムーバブルデバイスかどうか (RM)、そのサイズ (SIZE)、読み取り専用デバイスかどうか (RO)、そのタイプ (TYPE)、デバイスのマウント先 (MOUNTPOINT) です。

18.4. ブロックデバイスとファイルシステムの表示 – Red Hat Customer Portal

ブロックデバイスを拡張する

それでは以下のコマンドを入力してブロックデバイスを拡張しましょう。

$ sudo xfs_growfs /dev/xvda1

xfs_growfsコマンド

xfs_growfs コマンドを使用すると、マウント中の XFS ファイルシステムを拡大することができます。

-D size オプションでファイルシステムを指定の size (ファイルシステムのブロック数) まで大きくします。 -D size オプションを指定しない場合、xfs_growfs はデバイスで対応できる最大サイズにファイルシステムを拡大します。

6.4. XFS ファイルシステムのサイズの拡大 – Red Hat Customer Portal

もう一度以下のコマンドを入力してブロックデバイスのサイズを確認しましょう。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  32G  0 disk
└─xvda1 202:1    0  32G  0 part /

xvda1のサイズが16Gから32GBに変更されたことが分かります。


クリエイティブ・コモンズ・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。

続きを読む

【AWS】EC2のディスクI/Oを確認する【EBS】

はじめに

ITシステムを開発していく中で、システムのパフォーマンスが問題になるケースは多々あると思います。
PoC、開発、負荷試験、本番運用のいずれのフェイズであってもこのような課題は発生し、そのたびにボトルネックの分析と解決は必要になります。

大体において最初は原因がつかめないため、サーバであればCPU利用率、メモリ利用量、ネットワーク帯域、ディスクI/Oなど、およそ考えられうる個所を一通りチェックする必要があります。

AWSのEC2を利用している場合、単純に「念のためEC2のディスクI/Oも確認しといて」と指示しただけでは、十中八九、「EC2のディスクI/Oの値が取れてないんですが」と返ってきます。

毎回口頭で説明するのも効率が悪いので、「これ読んどいて」で済ませるためにこの記事を書きました。

TL;DR

  • 殆どの環境において、EC2のディスクとしてEBSが使われている
  • CloudWatchにおいて、EBSはEBSとしてのメトリクスが記録される。EC2のメトリクスには含まれない
  • ※重要:「[AWSマイスターシリーズ] Instance Store & Elastic Block Store」1はとても良くまとまっているのでちゃんと読もう

EC2で利用できるディスク

EC2ではローカルディスク領域として以下の2種類のものが利用できます。

  • Ephemeral Volume
  • EBS(Elastic Block Store)

EC2リリース当初はEphemeral Volumeしか利用できなかったのですが、その後EBSが利用できるようになりました。
そしてEBSがルートボリューム(つまり「/」)として利用できるようになり、現在ではEphemeral Volumeは限られた用途でしか使われなくなりました。

Ephemeral Volume

一部のインスタンスサイズでのみ利用できる領域です。
AWS公式ドキュメントでは、“Instance Store”(インスタンスストア)とも呼ばれることもあります。

仮想サーバであるEC2が稼働している物理サーバの、ローカルディスクの一部を間借りするようなイメージです。
EC2インスタンスを停止するとデータは消えます。
詳細は「[AWSマイスターシリーズ] Instance Store & Elastic Block Store」1に詳しいです。

これを利用するためには以下の条件を満たす必要があります。

  • InstanceのLaunch時に、Instance Storageが利用できるものを選択する
  • “Step 4: Add Storage”の際に、明示的に”Instance Store”を追加する

具体的な画面イメージは下記の通りです。

Step 2: Choose Instance Typeにて、「Instance Storage」に「? x ?? (SSD)」と表示されているものを選択します。
2017-11-27_01h58_29.png

Step 4: Add Storageにて、「Add New Volume」を押してパーティションを追加した後、「Instance Store 0」を選択します。
2017-11-26_22h47_14.png

EBS(Elastic Block Store)

通常、デフォルトで利用される領域です。

詳細は末尾のリンクにある「[AWSマイスターシリーズ] Instance Store & Elastic Block Store」に詳しいです。
本稿では詳細は割愛します。

CloudWatchから確認する

CloudWatchのメトリクス上、Ephemeral VolumeはEC2のメトリクスの一部として記録されますが、EBSはEC2とは別のNamespaceで記録されます。
それぞれ下記から参照することができます。

  • Ephemeral Volume:

    • EC2->Per-Instance Metrics
  • EBS:
    • EBS->Per-Volume Metrics

両方のディスク領域に負荷をかけ、どちらのメトリクスに変化が表れるか確認していきます。

検証した環境

Instance Size: m3.medium
OS: Amazon Linux AMI 2017.09

dfとmountの実行結果は下記の通りです。

dfコマンド
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G   60K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvda1      7.8G 1021M  6.7G  14% /
/dev/xvdb       3.9G  8.1M  3.7G   1% /media/ephemeral0
mountコマンド
$ mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1918920k,nr_inodes=479730,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime)
/dev/xvda1 on / type ext4 (rw,noatime,data=ordered)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/xvdb on /media/ephemeral0 type ext3 (rw,relatime,data=ordered)

事前準備

以下の2つの作業を実施します。

  • Bonnie++をインストールする
  • メモリ消費スクリプトを作成する

今回は、ディスクに負荷をかけるためにBonnie++を利用します。
操作するディスク容量に対して空きメモリ容量が大きいと、キャッシュが利用されてしまい、ディスクに最大負荷をかけることができません。

通常、物理メモリの2倍の容量のファイルに対して操作を行う必要がありますが、Ephemeral Volumeでは小さすぎます。
# m3.mediumの物理メモリは4GB、Ephemeral Volumeも4GBです。

そこで今回は、強制的にメモリを消費した状態でBonnie++を実行させます。
メモリ消費スクリプトは下記に載せておきました。

https://qiita.com/tmiki/items/314103598ba192c26528

上記スクリプトを実行し、メモリを大量に消費している状態にしておきます。
freeコマンド、/proc/meminfo等から確認しておきましょう

freeコマンド例
$ free
             total       used       free     shared    buffers     cached
Mem:       3855812    3361812     494000         60       9196      98832
-/+ buffers/cache:    3253784     602028
Swap:            0          0          0

Ephemeral VolumeのディスクI/Oを確認

Bonnie++の実行(Ephemeral Volume)

以下のコマンドでEphemeral Volumeに負荷をかけます。
ローカルのSSDはパフォーマンスが良く、すぐに終わってしまうので、10回連続で実行することにします。

bonnie++
# bonnie++ -u root -d /media/ephemeral0 -r 1536

CloudWatchメトリクスの確認(Ephemeral Volume)

以下の操作で、Ephemeral VolumeのディスクI/Oを確認することができます。2

  • AWS Management ConesoleからCloudWatchを開く。
  • 「Metrics」→「EC2」→「Per-Instance Mertrics」をたどり、対象のInstanceIdでフィルタをかける。
  • 以下の4つの項目をにチェックを入れ、グラフを表示させる。なお、*Opsは左軸、*Bytesは右軸に表示させると見やすい。
    • DiskReadOps
    • DiskWriteOps
    • DiskReadBytes
    • DiskWriteBytes

2017-11-27_01h33_57.png

EBSのディスクI/Oを確認する

Bonnie++の実行(EBS)

以下のコマンドでEphemeral Volumeに負荷をかけます。
これも10回連続で実行することにします。
今回検証した構成ではそれほどパフォーマンスが良くないので、しばらく時間がかかると思います。

bonnie++
# bonnie++ -u root -d / -r 1536

EBS ID(EBS Volume ID)を確認する

まず、対象のEBSのEBS IDを調べます。
この例では、EC2にアタッチしているEBSは1つであり、またこれがルートデバイスとなっています。

  • AWS Management ConesoleからECを開く
  • 「Instances」から、対象のEC2インスタンスを選択する
  • 「Root device」のリンクをクリックし、ポップアップを表示させる
  • EBS ID(vol-?????????????????)が確認できる

2017-11-26_22h56_54.png

CloudWatchメトリクスの確認(EBS)

EBS IDを確認したら、CloudWatchメトリクスから確認できます。3
ここでは取り急ぎ主要な項目のみ確認します。

  • AWS Management ConesoleからCloudWatchを開く。
  • 「Metrics」→「EBS」→「Per-Volume Mertrics」をたどり、上記で確認したEBS IDでフィルタをかける。
  • 以下の4つの項目をにチェックを入れ、グラフを表示させる。なお、*Opsは左軸、*Bytesは右軸に表示させると見やすい。
    • VolumeReadOps
    • VolumeWriteOps
    • VolumeReadBytes
    • VolumeWriteBytes

2017-11-27_01h34_04.png

まとめ

Ephemeral VolumeおよびEBSに負荷をかけた時間帯と、CloudWatchメトリクスで確認できるグラフの時間帯が一致していることが確認できたかと思います。
殆どのケースではEC2のローカルディスクとしてEBSを利用していると思います。
CloudWatchメトリクスを確認する際は、間違えないように気をつけましょう。

参考URL

続きを読む

[アップデート] Amazn EC2のサービスレベル契約が変更されました

AWS will use commercially reasonable efforts to make Amazon EC2 and Amazon EBS each available with a Monthly Uptime Percentage (defined below) of at least 99.99%, in each case during any monthly billing cycle (the “Service Commitment”). 続きを読む

AWS EC2 スナップショットの作成

スナップショットの作成

インスタンスの停止

スナップショット作成時にはインスタンスの停止が推奨されます。
AWSのコンソールもしくは、OSからインスタンスを停止させます。

使用中のアタッチ済みボリュームのスナップショットを取ることができます。
ただし、スナップショットでは、スナップショットコマンドを実行した時点で Amazon EBS ボリュームに書き込まれているデータのみがキャプチャされます。
そのため、アプリケーションやオペレーティングシステムによってキャッシュされたデータは除外される可能性があります。スナップショットを取る間、ボリュームへのすべてのファイルの書き込みを停止できれば、完全なスナップショットを取ることができます。
ただし、ボリュームへのすべてのファイルの書き込みを停止できない場合は、一貫した完全なスナップショットを取ることができるように、インスタンス内からボリュームをアンマウントし、スナップショットコマンドを実行して、ボリュームを再マウントします。
スナップショットのステータスが pending の間は、ボリュームを再マウントして使用できます。

Amazon EBS スナップショットの作成

AWS EC2 コンソールから停止する場合

Image 1.png

OSから停止する場合

sudo shutdown -h now

など

EBSの選択

AWS EC2 コンソールで画面下部に表示される「説明」からインスタンスに紐づくEBSを選択します。

Image 2.png

スナップショット作成

対象のEBSのスナップショットを作成します。
Image 3.png

Image 6.png

Image 7.png

Image 8.png

t2.small 8GiB で 5分強で作成完了でした。
開始直後に少し、進捗状況を確認したのですが0%のままで気づいたら完了していました。

復元

スナップショットをもとにイメージを作成を作成し、新規インスタンスを立ち上げます。

イメージ作成

Image 10.png

Image 11.png

作成したイメージをもとに立ち上げれば復元完了です。

引用元

Amazon EBS スナップショットの作成 – Amazon Elastic Compute Cloud
スナップショットによるEC2インスタンスのバックアップとレストア | Developers.IO

続きを読む

EBS学習メモ

この文書について

AWS EBSに関する学習メモ

https://aws.amazon.com/jp/ebs/details/

EBS

簡単なまとめ

  • SSD(io1,gp2)とHDD(st1,sc2) に大別される
  • 読み書きの瞬発力(IOPS)がほしいなら io1
  • そこそこで良いなら gp2
  • 安さと最大スループットを求めるなら st1sc1
  • io1でないEBSを使っていて、IOPSで問題が発生したら BurstBalance を確認
    • Burstしていなければ、EBS以外に問題がある
    • Burstしていれば、EBSをio1に変え、EC2もEBS最適化インスタンスにする

性能比較

ボリューム当たりの最大IOPS

io1(2万) > gp2(1万) >>> st1(500) > sc1(250)

ボリューム当たり最大スループット

st1(500MB/s) > io1(320MB/s) > sc1(250MB/s) > gp2(160MB/s)

I/O サイズとボリュームのスループット制限

  • EBSにはスループット制限がある
  • 小さいデータのI/O操作が原因で、スループット制限よりも低いデータ量でも制限が発動することがある
    • 特にSSDの場合、単一I/O とみなされるデータ量が小さい
  • スループット制限を超えてもバーストバケットを使ってカバーされる
    • バーストバケットがなくなると本当に制限される

      • CloudWatchなどでBurstBalanceを見ると状況がわかる
  • EC2 インスタンスの帯域幅が制限要因になることがある
    • 対策はEBS最適化インスタンスの利用

IPOS

  • IOPS = 1 秒あたりの入出力操作数を表す測定単位
  • 操作は KiB 単位で測定される
  • 単一I/O とみなされるデータ量はEBSがSSD/HDDによって異なる
    • 最大I/Oサイズ

      • SSD: 256 KiB
      • HDD: 1,024 KiB
    • SSDでは1つのIOとみなさるサイズが小さい
      = I/O やランダム I/O の処理が HDDより効率が良い

EBS最適化EC2インスタンス

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

  • io1 は EBS最適化EC2との併用が推奨
  • EBS最適化EC2インスタンスの特徴
    • Amazon EC2 と Amazon EBS の間の専用スループットがある

      • Amazon EBS I/O と EC2 インスタンスからの他のトラフィックとの競合を最低限に抑える
      • 専用スループットは500Mbps~10,000 Mbps
        • インスタンスタイプに応じて変化
  • EBS最適化インスタンスが使えるEC2 (2017年10月現在)
    • c系 (c1, c3, c4)
    • d系 (d2)
    • f系 (f1)
    • g系 (g2, g3)
    • i系 (i2, i3)
    • m系 (m1, m2, m3, m4)
    • p系 (p2)
    • r系 (r3, r4)
    • x系 (x1, x1e)

続きを読む

EBS新機能エラスティックボリュームをすぐに本番反映をトライしてみたらダメだったけど、AMI使えばできたのでストーリー仕立てで書く

これをやった理由

  • 本番のWEBサーバやバッチサーバで、Full Data Diskアラートが頻発するため

    • 頻度は週に1度
    • 原因は、担当システムで登録時にアップロードされたファイルのS3からのダウンロードとサムネイルの生成を大量にやるため

参考資料

対応方法

  • 下記の参考資料のまんまです。
  • やってみて経過を追ってみようと思ったけど、、、うちで使っているインスタンスがEBSが古すぎて対応してないみたい・・・ :sweat_smile:

8196b955-dfa0-4843-1bca-a02ed0a40d67.jpeg

おわりw

AMIからインスタンス再作成してやってみた

AMIから作り直してからだと、怒られなかったよー

8ed3b9e0-cbde-722e-e1cf-5a274aad39b7 jpeg.jpg

ってことでやってみます。とりあえず変更前が下記。

before
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.9G  5.8G  2.1G   75% /
devtmpfs         7.4G   44K  7.4G    1% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm

OK押したら、こんなん出てきた。。。けど、とりあえず「Yes」押す。
変更中は、一時的にパフォーマンス落ちるよってことだと思われます。

b5dd5bb4-7384-a197-4ba2-03e8c0759d26 jpeg.jpg

んで、ポチったらこうなるみたい。

7b76b2a5-5fc8-9ef8-5f21-74dd7042ecf2 jpeg.jpg

約5分から7分程度待ちましたら、こうなりました。

7efacdbc-6a32-9d36-aad8-a07b72d8e627 jpeg.jpg

ってことで、もっかいストレージ見てみます。
が、、、あれ、変わってない・・・

after
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.9G  5.8G  2.1G   75% /
devtmpfs         7.4G   44K  7.4G    1% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm

ここを見るとまだ何か必要っぽい、、、
Amazon EBSのアップデート – 新機能エラスティックボリュームが全てを変える | Amazon Web Services ブログ

次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。
作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。
ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。>新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。>コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。

ストレージ領域は変更かかったけど、ファイルシステムを拡張する必要があるとのことでした。
なので、下記のページを見て、コマンド打つみたい。
Linux ファイルシステムを拡張するのとこを参照。
Linux で EBS ボリュームのストレージ領域を拡張する – Amazon Elastic Compute Cloud

ファイルシステム確認
$ sudo file -s /dev/xvda1
/dev/xvda1: Linux rev 1.0 ext4 filesystem data, UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (needs journal recovery) (extents) (large files) (huge files)

次に、Linux ファイルシステムを拡張するにはのとこを見て、ファイルシステム拡張すると、できました!
おーーー!結構簡単でうれしい :smile:

ファイルシステム拡張
$ sudo resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5242880 (4k) blocks long.

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1        20G  5.8G   14G   30% /
devtmpfs         7.4G   44K  7.4G    1% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm

以上。これなら、一時的にELBからインスタンス切り離して対応後に再接続って形でオンラインでできちゃいますね!

続きを読む