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からインスタンス切り離して対応後に再接続って形でオンラインでできちゃいますね!

続きを読む

Amazon WorkMail – WEBインフラに不要な穴を開けないために

概要

Amazon EC2 でインターネット向けにWEBサーバーを運用している場合、よくある仕様追加「このドメイン名でメール送受信したい」に対応。
Amazon EC2 からのメール送受信は公式では非推奨 1
「安いは正義」に「WEBインフラにメールサービスを上乗せするなんて」で立ち向かう方への処方箋。

前提

  • ドメイン名(例えば example.tld)は既に取得済み、利用可能状態と仮定します。
  • 実現までのプロセスはすべて AWS リソースを使います。
  • ディレクトリーサービスの既存利用なしと仮定します。(お金なくて検証できてない)

AWS リソース

AWS 製品

既存のディレクトリーサービスが存在せず Amazon WorkMail をミニマムスタート、かつ、AWS サービス内で完結する場合には以下が必要になります。
1. Amazon VPC
2. AWS Directory Service
3. AWS Identity and Access Management (IAM)
4. Amazon WorkMail
5. Amazon Route53

AWS リージョン

Amazon WorkMail は、2017年8月現在、以下のリージョンで提供されています。

Code Name
us-east-1 US East (N.Virginia)
us-west-2 US West (Oregon)
eu-west-1 EU (Ireland)

Amazon WorkMail を利用するリージョンで Amazon VPC ならび AWS Directory Service を利用開始する必要があります。

費用計算

請求金額見積もり

  1. Amazon VPC
    今回のケースでは費用発生しません。
  2. AWS Directory Service
    Amazon WorkMail にて Simple AD を利用する場合に限り無料となります。2
  3. AWS Identity and Access Management (IAM)
    今回のケースでは費用発生しません。
  4. Amazon WorkMail
    1ユーザーあたり1ヶ月につき 4 USD。
  5. Amazon Route53
    1ホストゾーン(ドメイン名)につき 0.50 USD/月
    100 万クエリにつき 0.400 USD

損益分岐点

Amazon WorkMail と Amazon EC2 (t2.medium) を12ヶ月運用で比較してみます。(US East (N.Virginia))

Products type price
Amazon EC2 t2.medium のリザーブドインスタンス(1年全額前払) 約 22.91 USD/月
Amazon EBS gp2 50GB 5 USD/月
Amazon WorkMail 6ユーザー 24 USD/月
Amazon WorkMail 7ユーザー 28 UDS/月

6ユーザーより大きなユーザー数で運用は Amazon EC2 リザーブドインスタンスの方が費用的に安価になりますが、これには冗長性等、考慮されていません。
耐障害性、可用性から考えても、この要件が発生した際には Amazon WorkMail を選択がベストプラクティスと言えます。

オペレーション

ドメイン名 example.tld によるメール送受信を実現するために以下を行います。

  1. Amazon VPC
    • Simple AD 稼働のための Subnet を用意
  2. AWS Directory Service
    • Simple AD によるディレクトリー作成
  3. AWS Identity and Access Management (IAM)
    • 保管メールデータ暗号化に使用するキー管理のために AWS Key Management Service (KMS) を設定
  4. Amazon WorkMail
  5. Amazon Route53
    • ドメイン名 example.tld のDNSレコード管理

Amazon VPC

デフォルトで用意されている VPC と Subnet でも開始可能ですが、Simple AD で利用する Subnet は public subnet である必要はありません。
private subnet (Route Table に Destination: 0.0.0.0/0 が存在しない、またはそれ以外)で可能です。
以下成果物です。要望あればキャプチャー添付。TBC。

Name IPv4 CIDR Availability Zone
simplead-a 10.0.0.0/28 us-east-1b
simplead-b 10.0.0.16/28 us-east-1e

AWS Directory Service

AWS Management Console より AWS Directory Service を選択し、Simple AD をセットアップします。
年々 Simple AD と AD Connector の取り扱いがざつにn……

セットアップ情報は例えば下記です。要件に合わせて読み替えます。

Directory details

Name Value remarks
Directory type Simple AD 固定値
Directory DNS ad.example.tld
NetBIOS name オプション・未記入
Default administrative user Administrator 固定値
Administrator password ********
Description オプション・未記入
Directory size Small

VPC Details

Name Value
VPC 10.0.0.0/16
Subnets simplead-a, 10.0.0.0/28, us-east-1b
simplead-a, 10.0.0.16/28, us-east-1e

Access URL

セットアップ完了後、Status: Creating から Active になれば利用可能です。
この時、Access URL を定義します。
これは Amazon WorkMail の Web メールのURLで利用します。
例えば example.awsapps.com です。

AWS Identity and Access Management (IAM)

保存されるメール暗号化のため、暗号キーを指定します。
ここではデフォルトの aws/workmail を使います。

Amazon WorkMail

上記までに事前準備が完了しているはずですので、ここでは Standard setup でセットアップします。

Organizations

セットアップ情報は例えば下記です。要件に合わせて読み替えます。

Name Value remarks
Available Directories ad.example.tld セットアップした Simple AD
Master keys aws/workmail セットアップした KMS

Create 押下後、Status が Creating から Active に変われば利用可能です。

Domains

セットアップした Organization のドメイン名を定義します。
Organization のナビゲーション Domains を押下してドメイン名を定義します。
ここで先に設定した Access URL(example.awsapps.com)も確認できます。

Amazon SES と同様、ドメイン名の確認(Verify domain)が必要になります。
次項の Amazon Route53 の Hosted Zone (example.tld)に表示される下記のDNSレコードを追加します。

Recode type Hostname Value remarks
TXT _amazonses.example.tld. (指定された文字列) Domain verification で利用します
MX example.tld. 10 inbound-smtp.us-east-1.amazonaws.com. 3
CNAME autodiscover.example.tld. 3
CNAME (指定された文字列)._domainkey.example.tld. (指定された文字列) DKIM セットアップ4

Users

同じく Organization のナビゲーション Users よりユーザー定義を行います。
ユーザー名、パスワード、メールアドレスを入力してセットアップします。
特記する箇所はないため、ここでは割愛します。

Amazon Route53

Amazon WorkMail のセットアップ、Domains で得たDNSレコード情報を Hosted Zone example.tld に登録します。
割愛します。

上記にて username@example.tld によるメール送受信が可能です。

クライアント

デスクトップ、モバイル

Microsoft Exchange ActiveSync プロトコルをサポートするので、以下のデスクトップ、モバイルのクライアントに対応。
– Mac Mail.app
– iPhone
– Outlook
その他要検証。TBC。

ウェブアプリケーション

AWS Management Console, Amazon WorkMail のナビゲーション Organization settings で用意されている Web Application https://(文字列).awsapps.com/mail よりログイン可能。5

その他留意事項

申請関連

サービス上限

以下、気をつけるべき箇所の抜粋です。

  • 1ユーザーのメールボックスは 50GB
  • 送信・受信ともに1メールは 25MB
  • 1 日のユーザーあたりのメッセージ送信数 宛先に関係なく、1,000 件のメッセージ
  • ユーザーのエイリアス(アドレス)は 100(ハードリミット)

Amazon SES

メール送信は Amazon SES 経由で送信されますが、WorkMail からの送信は課金対象となりません。
また API 経由では必要な送信制限解除申請(サンドボックスから取り外す)も必要ありません。

未記入事項

以下の機能については記載してません。to be continued.

  • 移行
  • ジャーナリング
  • フロールール
  • グループ、リソース
  • 既存AD連携

出典

いつの日も AWS ドキュメントと FAQ は最強説。

続きを読む