AWS関連用語まとめ

個人的に今勉強中のAWS関連の用語をなるべく簡単にまとめてみました。(語弊がある部分もあるかもしれませんが個人的に理解できる形で落とし込んでみました)。今後も随時追加予定

EC2

仮想サーバ

S3

Amazon Simple Storage Service。オンラインストレージサービス

EBS

Amazon Elastic Block Store。オンライン外付けストレージ

ELB

Elastic Load Barancing。ロードバランサー

EIP

Elastic IP。固定のグローバルIP

RDS

Relational Database Service。クラウド型RDBMS

AMI

Amazon Machine Image。ソフトウェア構成(オペレーティングシステム、アプリケーションサーバー、アプリケーションなど)を記録したテンプレート

IAM

AWS Identity and Access Management。AWSへのアクセスを安全に制御するための仕組み

VPC

Virtual Private Cloud。仮想プライベートクラウド。

CloudFormation

環境設定に関してソースコード化したものを読み込んでAWS上に環境構築してくれるサービス(インフラをコード化してくれるなんてすごいね)

CodePipeline

システムのリリースにおけるプロセスを監視し、自動化・視覚化してくれるサービス。GitHubでMasterブランチへのマージを検知し→ビルド→デプロイ作業を自動で行ってくれる、みたいな事ができる

CodeBuild

CodePipelineで連携している機能の一部。自動でビルドしてくれる

CodeDeploy

CodePipelineで連携している機能の一部。自動でデプロイしてくれる

続きを読む

EC2のインスタンスタイプを変えて経費削減

はじめに

EC2の料金が高かったので、EC2のインスタンスタイプを変えることによって、安くした体験談です。
実際に対応したのは2017年8月で、awsでは、頻繁に値段が変わるので注意してください。

元の環境のインスタンスタイプ

m3.medium(200台ぐらい)

変更後の環境のインスタンスタイプ

m4.large(100台ぐらい)

スペック比較

タイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Linux/UNIX 料金
m3.medium 1 3 3.75 1 x 4 SSD $0.096 /1 時間
m4.large 2 6.5 8 EBS のみ $0.129 /1 時間

スペックは倍以上にもかかわらず価格は1.3倍!!

結果(1時間あたりの単純計算)

元の料金
$0.096×200=$19.2

変更後の料金
$0.129×100=$12.9

結果
約33%削減

注意点

インスタンスのスペックを倍にしたところでCPUを使いきれないアプリケーションだと、意味がないので気を付けてください。
(アプリケーションの設計やautoscaleのルール等を見直た方が良いです)
今回実施したアプリケーションではマルチプロセスで動いておりCPUも使い切っていたので上手く行きました。
インスタンスタイプを変えることによって思わぬことが起きたりもするので、十分テストしてから移行して下さい。

最後に

検証は必要だったとはいえ、インスタンスタイプを変えるだけで、経費削減できたのは大きかったです。
台数が減ったことにより運用負荷や他のサービスへの負荷も減っていて経費削減以外のメリットもありました。

続きを読む

AWS EC2のCentOSをPVからHVMへ移行する

(2年前の下書きを発見したので、時期を外していると思いつつ投稿します)
この記事では、昔から使われていたParaVirtualのEC2インスタンスをHVM対応とし、旧タイプのインスタンスから脱出するための手法を記します。
特に t1.micro で CPU steal に悩んでいる方は早めに t2.micro への移行をおすすめします。CPUクレジットに注意する必要がありますが、早い(CPU/network/storage)安い/うまい(メモリ1GB)と使わない理由がありません。
何度か作業をし、出来るだけ手順化をしてみたのでみなさんと共有します。
可能な限りコマンドライン一撃で終了できるようにしています。

先人の知恵

http://qiita.com/cs_sonar/items/21dbb3462708e146a426
実際の作業手順は上記のエントリーそのままですが、出来るだけsedなどのコマンドを利用しコピペで片付くような手順になっています。

作業用インスタンスを準備する

t2.micro/Amazon Linux(CentOSなどでも問題ないでしょう)でEC2を起動します。
このインスタンスIDが i-IIIIIIII として進めます。

EBSを準備する

作業用のインスタンスにアタッチするためのEBSが必要になります。
必要なEBSは二種類です。

出力先となるEBSを準備する

以下の例では作業の安定性を考慮してio1/PIOPS1000/100GBのEBSを準備します。
移行元のEBSのサイズより大きなものにしましょう。(でないと収まらない)

aws ec2 create-volume --size 100 --availability-zone ap-northeast-1a --volume-type io1 --iops 1000

ここで作成されたEBSボリュームIDを vol-DDDDDDDD として次に進みます。

出力先EBSをアタッチする

aws ec2 attach-volume --instance-id i-IIIIIIII --device /dev/sdo --volume-id vol-DDDDDDDD

元となるEBSを準備する

元となるEBSですが、以下の順序で作成します。
以下の例では作業の安定性を考慮してio1/PIOPS1000/100GBのEBSを準備します。
– 移行元のEBSからスナップショットを作成します。
– 作成したスナップショットから作業用EBSを作成します。

aws ec2 create-snapshot --volume-id vol-OOOOOOOO

ここで作成されたスナップショットのIDを snap-OOOOOOOO として次に進みます。

aws ec2 create-volume --size 100 --availability-zone ap-northeast-1a --volume-type io1 --iops 1000 --snapshot-id snap-OOOOOOOO

作成されたEBSボリュームIDを vol-SSSSSSSS として次に進みます

元となるEBSをアタッチする

aws ec2 attach-volume --instance-id i-IIIIIIII --device /dev/sdm --volume-id vol-SSSSSSSS

作業用インスタンスでの作業

作業用インスタンスには以下の状態でEBSがマウントされている(はず)です。

デバイス名 利用用途
/dev/xvdm 移行元EBS
/dev/xvdo 移行先EBS

移行先データ用EBSを準備する

yum -y install parted resize2fs
parted /dev/xvdo --script 'mklabel msdos mkpart primary 1M -1s print quit'
partprobe /dev/xvdo
udevadm settle

移行元データの検査とディスクサイズの(見かけ上の)縮小

e2fsck -f /dev/xvdm
resize2fs -M /dev/xvdm

移行元EBSから移行先EBSへのデータ移設と縮小したディスクサイズの復元

dd if=/dev/xvdm of=/dev/xvdo1 bs=4K count=1747941
resize2fs /dev/xvdo1

移行先EBSのマウントとchrootによる作業準備

mount /dev/xvdo1 /mnt
cp -a /dev/xvdo /dev/xvdo1 /mnt/dev/
chroot /mnt

grub導入と設定の調整

yum install -y grub
ln -s /boot/grub/menu.lst /boot/grub/grub.conf
ln -s /boot/grub/grub.conf /etc/grub.conf
rm -f /boot/grub/*stage*
cp /usr/*/grub/*/*stage* /boot/grub/
rm -f /boot/grub/device.map
cat <<EOF | grub --batch
device (hd0) /dev/xvdo
root (hd0,0)
setup (hd0)
EOF

menu.lstの調整

menu.lstでの root kernel を調整します。
– (hd0)ではなく(hd0,0)とする必要があります。
– デバイス名ではなくラベル名でrootを認識させます。
– シリアルコンソールとHVM対応を明示します。

sed -i.bak -e 's:root(.*)(hd0):root1(hd0,0):;s:root=.*:root=LABEL=/ console=ttyS0 xen_pv_hvm=enable:' /boot/grub/menu.lst 

以下のような形になっているか確認して下さい。 root kernel あたりが要確認項目です。

default=0
timeout=0
hiddenmenu
title SUZ-LAB CentOS 6
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.1.2.0.1.el6.x86_64 ro root=LABEL=/ console=ttyS0 xen_pv_hvm=enable
initrd /boot/initramfs-2.6.32-431.1.2.0.1.el6.x86_64.img

fstabの調整

fstabでのroot(/)をラベルで認識するように変更します。

sed -i.bak -e 's:.*(s)/s(.*)defaults(.*):LABEL=/1/2defaults,noatime3:g' /etc/fstab 

以下のような形になっているか確認して下さい。 LABEL=/ / あたりが要確認項目です。

LABEL=/ /        ext4    defaults,noatime        1 1
none             /proc     proc    defaults        0 0
none             /sys      sysfs   defaults        0 0
none             /dev/pts  devpts  gid=5,mode=620  0 0
none             /dev/shm  tmpfs   defaults        0 0
/mnt/swap/0.img  swap      swap    defaults        0 0

ディスクラベルの調整

e2label /dev/xvdo1 /
tune2fs -l /dev/xvdo1 |grep name

chrootを退出して後片付け

chroot状態から元のOSへ戻ります。

exit

一時的に必要とされたデバイス関連ファイルを削除し、マウントを解除します。

rm -f /mnt/dev/xvdo /mnt/dev/xvdo1
sync
umount /mnt

AMIの作成

AMI作成のもととなるスナップショットを作成する

aws ec2 create-snapshot --volume-id vol-b7f1e741

作成したスナップショットからAMIを作成する

続きを読む

[入門] AMIのコピーでエラーが出たら [EBS Encryption]

こんにちはこむろです。本日もどこにも需要がなさそうな気がする記事をあげていく所存。プログラミングはどこへ。 EBS暗号化の作業に伴い、様々なオペレーションを実行してます。その中でAMIのコピーでいくつか躓いたのでこちらに […] 続きを読む

VPCフローログを Amazon Elasticsearch Service に取り込んで Kibana で分析する

はじめに

VPCフローログ (VPC Flowlogs) はVPCを運用する上でシンプルで強力な情報です。
VPCユーザーガイド – VPCフローログより

VPC フローログは、VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。フローログのデータは、Amazon CloudWatch Logs を使用して保存されます。フローログを作成すると、そのデータを Amazon CloudWatch Logs で表示し、取得できます。

この記事では、マネジメントコンソールとKibanaのUIを用いてAmazon Elasticsearch ServiceKibanaによるVPCフローログのシンプルな分析ができるまでの手順をご紹介します。コーディングは必要なく、30分もかからずに実施できます。

VPCフローログの作成

まず、VPCフローログの格納先となるCloud Watch Logsのロググループを準備しましょう。

ロググループの作成

CloudWatchサービスに移動し、左側のメニューからログを選択します。初めてだと次のような画面になっているので、「ロググループの作成」を選択します。既にロググループを作られているのであれば新たにもう1つ作成して下さい。

スクリーンショット 2017-10-05 15.01.56.png

ロググループ名の入力を求められるので「flowlogs/defaultvpc」など、わかりやすい名前を付けておきます。なお、VPC毎にロググループは分けることもできますし、同じロググループにまとめることもできます。1秒間5回までのPutLogEventsスロットリングがあることを考えると、VPC毎にロググループを作成すべきでしょう。

フローログの作成

VPCサービスのVPCメニューにおいて、フローログを取得したいVPCを選択して「フローログの作成」を実行します。

スクリーンショット 2017-10-05 14.52.32.png

フィルターではキャプチャしたい方向(すべてを選択すると送受信両方をキャプチャします)を選択します。送信先ロググループは先の手順で作成したロググループを選択します。また初めて作成する場合は、フローログのためのIAMロールを作成する必要がありますので、「アクセス権限の設定」というリンクをクリックします。
スクリーンショット 2017-10-05 15.21.19.png

すると次のような画面が表示されます。特に何も変えずに「許可」をクリックすることでフローログ作成用の「flowlogsRole」が作成されます。
スクリーンショット 2017-10-05 15.24.30.png

元の画面に戻ると、次のように「flowlogsRole」が選択できるようになっていますので選択し、「フローログの作成」をクリックします。
スクリーンショット 2017-10-05 15.26.35.png

作成したフローログのステータスがアクティブになっていればOKです。
VPC Management Console 2017-10-05 16-03-47.png

Amazon Elasticsearch Serviceドメインの作成

Amazon Elasticsearch Serviceに移動し、「新しいドメインの作成」をクリックします。ドメイン名を入力し、「次へ」をクリックします(バージョンはそのままでOKです)。
スクリーンショット 2017-10-05 16.10.30.png

「クラスタの設定」画面では主に1インスタンスあたりのボリューム、インスタンスタイプ、そしてインスタンス数などを指定します。とりあえず試すのであればデフォルトのまま(m4.xlarge, EBS 10GB, 1台)で問題ありませんが、継続的に運用するのであれば、こちらの記事などを参考にサイズを算出して下さい。

「アクセスポリシーの設定」において、とりあえず試すのであれば「ドメインへのオープンアクセスを許可」を選択することができます。本来はIPアドレスなどでフィルタリングする必要があり、オープンアクセスが許可されたドメインにセキュアなデータはアップロードすべきではないことに注意して下さい。
スクリーンショット 2017-10-05 16.26.55.png

最後に確認を押せばドメインが作成開始されます。ステータスが「黄色(またはグリーン)」になるまで10分ほどかかりますので待ちます。

CloudWatchログからAmazon ESへのストリーミング

CloudWatchサービスのログから、先に作成したロググループを選択し、アクションメニューから「Amazon Elasticsearch Serviceへのストリーミングの開始」を実行します。
スクリーンショット 2017-10-05 16.33.25.png

Amazon ESクラスターで先ほど作成したESクラスターが選択可能になっていますので選択します(ESクラスターがまだ作成中であればキャンセルしてもう一度ストリーミングの開始をやり直します)。選択すると下段にLambda IAM実行ロールの選択が表示されますので、予め作成していなければ「新しいIAMロールの作成」を選択します。

スクリーンショット 2017-10-05 16.47.16.png

表示されているロール名で特に問題なければ「許可」をクリックし、元の画面に戻って次の画面に進みます。
スクリーンショット 2017-10-05 16.49.29.png

ログ形式は「Amazon VPC フローログ」を選択し、次の画面に進みます。
スクリーンショット 2017-10-05 16.52.21.png

レビューの画面で確認して次の画面に進み、「ストリーミングの開始」をクリックすればESクラスタへのログ送信が開始されます。
スクリーンショット 2017-10-05 16.55.22.png
スクリーンショット 2017-10-05 16.56.44.png

Kibanaでの可視化

取り込まれたログの索引名を確認します。Amazon Elasticsearch Serviceから作成したESドメインのインデックスを見ると、「cwl-日付」のようなインデックスが新たに作成されていることが確認できます。もし「.kibana」しか存在しなければ待ちます(念のため:通信が行われていないと当然フローログは生成されませんので注意して下さい)。
Amazon Elasticsearch Service Management Console 2017-10-05 17-24-12.png

上の画面にも表示されている「Kibana」のリンクをクリックします。Index Patternの設定画面となりますので、Index name or patternの欄に先ほど確認した「cwl-*」を入力し、Createをクリックします。
スクリーンショット 2017-10-05 17.28.22.png

これでログを可視化することができるようになりました。左側のメニューのDiscoverからデータを見たり、Visualizeで色々なチャートを作成するなどを試してみて下さい!
スクリーンショット 2017-10-05 17.31.28.png

続きを読む

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

続きを読む

[入門] 稼働中のEC2インスタンスのEBS Volumeを暗号化する [EC2インスタンス]

はじめに 突然ですが、稼働中のEC2インスタンスのEBSを暗号化したくなりませんか?今すぐに。 通常何もしていなければ稼働しているEC2インスタンスのEBS Volumeは特に暗号化されていません。セキュリティ要件によっ […] 続きを読む

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)

続きを読む

EC2でプロビジョニングしたインスタンスをAMIにする

目的

ケチなのでEC2でこまめにGPUノードを作ったり消したりしたい。毎回ファイルをインストールし直すのは時間がもったいないし、既存のAMIは一長一短でどうも気に入らない。自分でインスタンスをプロビジョニングして、AMIを作る。

手順

  1. プロビジョニング対象のインスタンスを用意する。”Ubuntu Server 16.04 LTS (HVM), SSD Volume Type – ami-6e1a0117″を”g2.2xlarge”1でスポットインスタンスを要求する2。なお、インストール容量が必要なため、”EBS volumes”にて”Root”は20GBとした。

  2. Ansible playbookを使ってインスタンスをプロビジョンニングする。なお、上記AMIには pythonがインストールされていないので、事前にsshで入ってインストールする。

  3. インスタンスを止める3。ボリューム選びスナップショットを作成する。

  4. スナップショットを選び”Create Image”でイメージを作成する。 “Virtualization type”を”Hardware-assisted virualization”にすること (GPUを使うために必要)。

以上


  1. GPUをプロビジョンするのにGPUノードである必要があったかは不明。 

  2. “EBS volumes”で”Root”の”Delete”オプションをオフにしたほうがよかった。後述。 

  3. 今回は”EBS volumes”で”Delete”を入れ忘れたので、とめずにやってしまった。 

続きを読む