iperfでAWSのEC2インスタンスの速度を測定した

自己紹介

最近本腰を入れて技術の勉強をするようになりました、dtd root と言います。
私の投稿では、主に私の勉強の過程を記録し、可能ならば皆さまに知識を分けていただこうという趣旨の元投稿を行います。
至らない点や間違いが数多くありますが、どうぞご容赦ください。

AWSでTCPの最大レートを測定

環境は以下

測定リージョン
東京-東京間
東京-ソウル間

インスタンスタイプ
t2.micro

OS
Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type

入力コマンド

クライアント側
iperf -c -t 60 -p

※宛先IPはパブリックIPです。

サーバー側
iperf -s -p

実行結果
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.2 sec 235 MBytes 32.8 Mbits/sec
[ 5] 0.0-60.0 sec 3.37 GBytes 482 Mbits/sec

Qita1.png

所感
ソウルを跨いだ方が帯域幅が低くなるのは当然の結果かと思われますが、理論値の算出方法がどうにもわかりませんでした。
ググってみてもうまくAWS-EC2の理論帯域が出てこないので、そちらとの比較が出来なかったのが残念だと思っています。
そしてこの値はどうすれば良くなるのか、どうすれば悪くなるのか、といったところも全く分からない状況なので、
今後手探りで知識を得ていければいいなと思っています。

参考文献

[1]Amazon Web Services 基礎からのネットワーク&サーバー構築
[2]ネットワーク測定ツールiperfの使い
https://qiita.com/takish/items/bff7a1df712d475432df
[3]EC2でiperfを使ってネットワークスループットを計測してみた。
https://dev.classmethod.jp/etc/ec2-iperf/

続きを読む

HDP 2.6.3をAWSにインストール 乞食版

ゴール

AWSの超安いインスタンスに、HDPをインストールして遊ぶ。

インスタンス初期化

Ambari

t2.nano

[ec2-user@ip-172-31 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:            990          80         731          12         179         739
Swap:             0           0           0

AWS Amazon Linux スワップファイル作成によりSwap領域のサイズを増やす
https://qiita.com/na0AaooQ/items/278a11ed905995bd16af

現在は1GBあるので、8GBのSwapメモリを追加

grep Mem /proc/meminfo
grep Swap /proc/meminfo
free
uname -a
# /swapfile1 に保存
sudo dd if=/dev/zero of=/swapfile1 bs=1M count=8192
grep Swap /proc/meminfo

ll /swapfile1
sudo chmod 600 /swapfile1
sudo mkswap /swapfile1
ll /swapfile1
swapon -s
free
sudo swapon /swapfile1
free
grep Swap /proc/meminfo

メモリ追加しました。

[ec2-user@ip-172-31 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:            990          77          64          12         848         731
Swap:          3083           0        3083
[ec2-user@ip-172-31 ~]$

t2.micro instance作成

Ambari:1台
Master:1台
Slave:3台

image.png

注意事項

RHEL 7.4

Red Hat Enterprise Linux 7.4 (HVM), SSD Volume Type – ami-26ebbc5c

AWS setting

t2.micro instance

Storage setups —

Ambari: EBS 15G
NN/DN: EBS 20G

image.png

image.png

セキュリティ設定

All Traffic, Allow, HDPのセキュリティグループID指定(内部通信を全部許可)
All Traffic, Allow, MyIP (管理者のIPを許可)
これでOK

ssh private key

scp -i amuisekey.pem amuisekey.pem ec2-user@ec2-54-234-94-128.compute-1.amazonaws.com:~/.ssh/id_rsa
# 全部サーバーにアップロード

hosts

自分のMBP /etc/hosts

    127.0.0.1 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6

#外部IP
    10.110.35.23 hdpmaster1.hdp.hadoop hdpmaster1
    10.191.45.41 hdpmaster2.hdp.hadoop hdpmaster2
    10.151.94.30 hdpslave1.hdp.hadoop hdpslave1
    10.151.87.239 hdpslave2.hdp.hadoop hdpslave2
    10.70.78.233 hdpslave3.hdp.hadoop hdpslave3
    10.151.22.30 ambarimaster.hdp.hadoop ambarimaster

AWSサーバーの /etc/hosts

    127.0.0.1 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6

#外部IP
    10.110.35.23 hdpmaster1.hdp.hadoop hdpmaster1
    10.191.45.41 hdpmaster2.hdp.hadoop hdpmaster2
    10.151.94.30 hdpslave1.hdp.hadoop hdpslave1
    10.151.87.239 hdpslave2.hdp.hadoop hdpslave2
    10.70.78.233 hdpslave3.hdp.hadoop hdpslave3
    10.151.22.30 ambarimaster.hdp.hadoop ambarimaster

Install

https://community.hortonworks.com/articles/14512/ambari-on-ec2.html

image.png

続きを読む

AWS ARNまとめ

資格勉強向けにARNの構文をメモ
Amazon ARN

基本形式

arn:partition:service:region:account-id:resource
arn:partition:service:region:account-id:resourcetype/resource
arn:partition:service:region:account-id:resourcetype:resource
  • パーティション: 基本的にAWS
  • サービス: AWS製品名
  • リージョン: リソースがあるリージョン。リージョン関係ないものは省かれている
  • リソース,リソースタイプ: サービスによって異なる。スラッシュやコロンなどで書いてある

覚え方
アランとパーティでサービス受けたらリケジョにアカンと(リ)ソースかけられた。

EC2構文例

arn:aws:ec2:region:account-id:instance/instance-id
arn:aws:ec2:region:account-id:volume/volume-id

arn:aws:ec2:us-east-1::image/ami-1a2b3c4d
アカウントが省略されて::となる。
arn:aws:ec2:us-east-1:123456789012:instance/*

S3構文例

arn:aws:s3:::bucket_name
arn:aws:s3:::bucket_name/key_name
s3はリージョン、アカウントは不要。故にバケット名が一意である必要があるのか

S3例

arn:aws:s3:::my_corporate_bucket/*
ポリシーのARNを指定する場合は、ワイルドカード「*」文字を使用できる。

RDS構文例

arn:aws:rds:region:account-id:db:db-instance-name
arn:aws:rds:region:account-id:cluster:db-cluster-name

AWSCLI,RDS APIを使用する時に使う。その際にはタグと共に使用する。

AWS サービスの名前空間
AWSサービスの識別をNamespaceを使用して AWSのサービスを識別する。
IAMポリシーを作る時などにアクションとリソースを識別するときに使用する。

そういえば関係ないけどサービス名のプレフィックスでAmazonとAWSの違いは

  • Amazon: 単体のサービスとして利用出来る。
  • AWS: 他のAWSのサービスと組み合わせて利用する。

と,どこかで聞いた気がする。公式のどこかに書いてあったけな?

続きを読む

Ubuntu 16.04 on AWSでリモートデスクトップを実現する(Macから接続)

前置き

Ubuntu 16.04 on AWSでリモートデスクトップ接続を実現しようとしたらハマったのでメモ。
Mac <-> UbuntuなのでVNCとかでやる方が普通そうなので需要あるかわかりませんが。。

以下のようなページを彷徨い、色々と試したが結果的にうまくリモートデスクトップが動かなかった。(ハマった箇所は色々あったが最後はssh接続は問題なくできているのにリモートデスクトップからだと「Connection Refused」で先に進めない。権限周りなどを色々と確認したがうまくいかなかった。)

https://cryptotrader.muragon.com/entry/56.html
http://akira.matrix.jp/archives/972

環境

サーバー
– Ubuntu Server 16.04 LTS (HVM), SSD Volume Type on AWS EC2

クライアント
– MacOSX 10.12.6

解決方法

しかし以下のページのコマンドで一発で行けた。ありがとう。
https://qiita.com/tmikada/items/be27df3affc56eeffd8b

インストール
$ sudo apt install xrdp xfce4 xfce4-goodies tightvncserver

ただし、以降の部分は実行したらうまくいかなかった(接続はされてるが、グレーの画面が表示されてデスクトップが表示されない。Xウィンドウの設定なんだと思うが、時間がないので調査は割愛)。

実行したらうまくいかなかった箇所
$ sudo vi /etc/xrdp/xrdp.ini
# 以下のように編集
---------
...
#. /etc/X11/Xsession
---------

実施した手順

最終的に実行した一連の流れは以下の通り。

xrdpのインストール
$ sudo apt install xrdp xfce4 xfce4-goodies tightvncserver
$ sudo service xrdp restart

AWSコンソールのセキュリティグループの設定(インバウンド)で以下を追加。

image.png

クライアントからログイン

Macのリモートデスクトップ接続で設定。

image.png

無事にデスクトップに接続。

image.png

続きを読む

[AWS][Terraform] Terraform で Amazon Inspector を導入する

TerraformAmazon Inspector を導入して、CloudWatch Events で定期実行させるための手順。
Terraform は v0.11.2 を使っています。

Inspector の導入

Inspector を導入するには、Assessment targets (評価ターゲット) と Assessment templates (評価テンプレート) を設定する必要があります。

Assessment targets の設定

Terraform で Assessment targets を設定するには、aws_inspector_resource_group, aws_inspector_assessment_target リソースを使用します。
こんな感じです。

inspector_target.tf
variable "project" { default = "my-big-project" }
variable "stage"   { default = "production" }

resource "aws_inspector_resource_group" "inspector" {
    tags {
        project   = "${var.project}"
        stage     = "${var.stage}"
        inspector = "true"
    }
}

resource "aws_inspector_assessment_target" "inspector" {
    name               = "my-inspector-target"
    resource_group_arn = "${aws_inspector_resource_group.inspector.arn}"
}

aws_inspector_resource_group では、対象となるインスタンスを特定するための条件を記述します。
上記の例だと、以下のタグが設定されているインスタンスを対象にします。

Name Value
project my-big-project
stage production
inspector true

aws_inspector_assessment_target では、aws_inspector_resource_group で定義した条件を元に Assessment targets を作成します。

Assessment templates の設定

Terraform で Assessment templates を設定するには、aws_inspector_assessment_template リソースを使用します。
こんな感じです。

inspector_template.tf
variable "inspector-rule" = {
    type = "list"
    default = [
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-bBUQnxMq",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-gHP9oWNT",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-knGBhqEu"
    ]
}

resource "aws_inspector_assessment_template" "inspector" {
    name       = "my-inspector-template"
    target_arn = "${aws_inspector_assessment_target.inspector.arn}"
    duration   = 3600

    rules_package_arns = [ "${var.inspector-rule}" ]
}

output "assessment_template_arn" {
    value = "${aws_inspector_assessment_template.inspector.arn}"
}

rules_package_arns では、利用可能な Inspector rule package の ARN を設定します。
variable にしておくと、後で rule package を変更したい時に楽ですね。
こんな感じで、使用する rule package を変更できます。

terraform.tfvars
"inspector-rule" = [
    "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
    "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-bBUQnxMq"
]

使用できる rule package は、aws-cli で取得してください。

# パッケージ一覧の表示
$ aws --region ap-northeast-1 inspector list-rules-packages
{
    "rulesPackageArns": [
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-bBUQnxMq",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-gHP9oWNT",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-knGBhqEu"
    ]
}
# 詳細を確認
$ aws --region ap-northeast-1 inspector describe-rules-packages 
  --rules-package-arns "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu"
{
    "rulesPackages": [
        {
            "description": "The CIS Security Benchmarks program provides well-defined, un-biased and consensus-based industry best practicesto help organizations assess and improve their security.nnThe rules in this package help establish a secure configuration posture for the following operating systems:nn  -   Amazon Linux version 2015.03 (CIS benchmark v1.1.0)n  n    ",
            "version": "1.0",
            "name": "CIS Operating System Security Configuration Benchmarks",
            "arn": "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
            "provider": "Amazon Web Services, Inc."
        }
    ],
    "failedItems": {}
}

参考URL: Terraform v0.8.5でAWS Inspectorに対応します

これで terraform apply すれば Assessment targets, templates が作成されます。

動作確認

実際に Inspector が実施されるか確認して見ましょう。

$ aws inspector start-assessment-run 
  --assessment-template-arn arn:aws:inspector:ap-northeast-1:************:target/0-xxxxxxxx/template/0-xxxxxxxx
{
    "assessmentRunArn": "arn:aws:inspector:ap-northeast-1:************:target/0-xxxxxxxx/template/0-xxxxxxxx/run/0-7WNjqgGu"
}

実行状況の確認は aws inspector describe-assessment-runs

$ aws inspector describe-assessment-runs 
  --assessment-run-arns arn:aws:inspector:ap-northeast-1:************:target/0-QOvPswHA/template/0-uCIUy636/run/0-n9nnWOem

CloudWatch Events Schedule による定期実行

当初は CloudWatch Events で定期実行するには Lambda から呼び出すようにしなければいけませんでした。
しかし、CloudWatch Event から直接 Inspector を実行できるようになったため、Lambda を使用しなくても aws_cloudwatch_event_targetaws_cloudwatch_event_rule だけで定期実行設定が可能です。

CloudWatch Events で使用する IAM ロールの作成

まずは、CloudWatch Events で使用する IAM ロールを作ります。

cloudwatch-events-iam-role.tf
esource "aws_iam_role" "run_inspector_role" {
    name               = "cloudwatch-events-run-inspector-role"
    assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_policy" "run_inspector_policy" {
    name        = "cloudwatch-events-run-inspector-policy"
    description = ""
    policy      = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "inspector:StartAssessmentRun"
            ],
            "Resource": "*"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "run_inspector_role" {
    role       = "${aws_iam_role.run_inspector_role.name}"
    policy_arn = "${aws_iam_policy.run_inspector_policy.arn}"
}

CloudWatch Events への登録

CloudWatch Events に登録するために aws_cloudwatch_event_target リソースと aws_cloudwatch_event_rule を作りましょう。

cloudwatch-events.tf
variable "schedule"    { default = "cron(00 19 ? * Sun *)" }

resource "aws_cloudwatch_event_target" "inspector" {
  target_id = "inspector"
  rule      = "${aws_cloudwatch_event_rule.inspector.name}"
  arn       = "${aws_inspector_assessment_template.inspector.arn}"
  role_arn  = "${aws_iam_role.run_inspector_role.arn}"
}

resource "aws_cloudwatch_event_rule" "inspector" {
  name        = "run-inspector-event-rule"
  description = "Run Inspector"
  schedule_expression = "${var.schedule}"
}

schedule_expression の cron() は UTC で設定する必要があるので注意してください。
記述方法は、以下を参考に
参考URL: Rate または Cron を使用したスケジュール式

EC2 への IAM Role の設定と、ユーザーデータによる Inspector エージェントのインストール

評価ターゲットとなる EC2 には、Inspector エージェントがインストールされていて、適切なインスタンスロールが設定されている必要があります。
導入するには、こんな感じ

インスタンスロール

inspectora エージェントを使用するために必要なポリシーをアタッチしたインスタンスロールの作成はこんな感じです。

ec2-instance-role.tf
resource "aws_iam_role" "instance_role" {
    name               = "my-ec2-role"
    path               = "/"
    assume_role_policy = <<POLICY
{
"Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_instance_profile" "instance_role" {
    name = "my-ec2-role"
    role = "${aws_iam_role.instance_role.name}"
}

resource "aws_iam_policy" "inspector" {
    name        = "my-ec2-iam-policy-inspector"
    description = ""
    policy      = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeCustomerGateways",
                "ec2:DescribeInstances",
                "ec2:DescribeTags",
                "ec2:DescribeInternetGateways",
                "ec2:DescribeNatGateways",
                "ec2:DescribeNetworkAcls",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribePrefixLists",
                "ec2:DescribeRegions",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcEndpoints",
                "ec2:DescribeVpcPeeringConnections",
                "ec2:DescribeVpcs",
                "ec2:DescribeVpn",
                "ec2:DescribeVpnGateways",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeRules",
                "elasticloadbalancing:DescribeTags",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth"
            ],
            "Resource": "*"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "inspector" {
    role       = "${aws_iam_role.instance_role.name}"
    policy_arn = "${aws_iam_policy.inspector.arn}"
}

ユーザーデータによる inspector エージェントのインストール

OS は Amazon Linux を想定してます。
ユーザーデータに書いておけば、インスタンス起動直後に inspector エージェントインストールできますね。
参考URL: Amazon Inspector エージェントをインストールする

ssh-key.pemssh-key.pem.pubssh-keygen で適当に作っておきましょう。

ec2.tf
## AMI
##
data "aws_ami" "amazonlinux" {
    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"]
    }
}

## SSH Key Pair
##
resource "aws_key_pair" "deployer" {
    key_name   = "ssh-key-name"
    public_key = "${file(ssh-key.pem.pub)}"
}

## EC2
##
resource "aws_instance" "ec2" {
    ami                         = "${data.aws_ami.amazonlinux.id}"
    instance_type               = "t2.micro"
    key_name                    = "${aws_key_pair.deployer.key_name}"
    iam_instance_profile        = "${aws_iam_instance_profile.instance_role.name}"

    user_data                   = <<USERDATA
#!/bin/bash
# install inspector agent
cd /tmp
/usr/bin/curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
/bin/bash install -u false
/bin/rm -f install
USERDATA

    tags {
        project   = "${var.project}"
        stage     = "${var.stage}"
        inspector = "true"
    }
}

現場からは以上です。

続きを読む

AWS と Azure と自宅の PC で NVIDIA GPU Cloud (NGC) のコンテナを動かしてみた

こんにちは。エヌビディアの佐々木です。

NVIDIA GPU Cloud (NGC) というサービスをご存知でしょうか。端的に書けば 「NVIDIA が公開している Docker コンテナリポジトリ」 です。CaffeChainerTensorFlow 等の各種ディープラーニング フレームワークや、GAMESSGromacsLAMMPS といった HPC アプリケーションのコンテナが揃っており、もちろん GPU 実行に最適化されています。このコンテナを使えば、計算環境構築の手間をかなり削減することができます。

「Cloud」とあるので、クラウドで GPU を使うためのサービスと思われることがあるのですが、NGC は「コンテナを提供するクラウドサービス」であって、そのコンテナはクラウドに限らず、オンプレミスのコンピューターでも利用できます。

今のところ、コンテナの利用環境としてエヌビディアが正式にサポートするのは AWS の P3 インスタンス と、NVIDIA TITAN V を搭載するコンピューターのみですが、それ以外の環境でも Pascal 世代以降の GPU であれば動作するはずです。

というわけで、次のような3つの環境で試してみました。

  • AWS の P3 インスタンス (Tesla V100 搭載)
  • Microsoft Azure の ND インスタンス (Tesla P40 搭載)
  • 私の自宅 PC (GeForce GTX 1050 Ti 搭載)

※ 私の PC だけちょっと弱めですが、ロープロファイルのカードしか付かないんです…

NGC のアカウントを作る

まず、 NGC のサインアップページでアカウントを作成します。無料です。
2018-01-28_205005.png

NGC の API キーを生成する

アカウントができたらログインして、画面右上の “Get API Key” をクリックしてください。
2018-01-28_205552.png

次に、”Generate API Key” をクリックして API キーを生成します。これは後ほど NGC からコンテナを pull する際に使用します。
2018-01-28_210946.png

生成されたキーは必ずどこかに控えておいてください。”This is the only time your API Key will be displayed.” とあるとおり、二度と表示されません。
2018-01-28_211158.png

さて、アカウントと API Key ができたら、あとは実行環境の準備です。要件は次の通り。

  • Pascal 世代以降の GPU (と、そのドライバ)
  • NVIDIA Docker

では、AWS, Azure, 自宅 PC のそれぞれで試していきます。

実行環境を作る (AWS で)

AWS は NGC の正式サポート環境なので、準備も簡単です。NVIDIA Volta Deep Learning AMI という AMI をエヌビディアが提供していますので、これを使って P3 インスタンスを作れば OK です。ドライバも NVIDIA Docker もインストール済み。別途セットアップする必要はありません。(なお、G2, G3, P2 は、GPU が Kepler や Maxwell 世代なので NGC 非対応)

早速作ってみます。
2018-01-28_212822.png
東京は高いのでオレゴンで、インスタンスタイプは p3.2xlarge (Tesla V100 を1基搭載)を選びました。

インスタンスが動き始めたらログインしてみます。シェルのプロンプトが出る前にこんなことを聞いてきます。

Welcome to the NVIDIA Volta Deep Learning AMI. This environment is provided to
enable you to easily run the Deep Learning containers from the NGC Registry.
All of the documentation for how to use NGC and this AMI are found at
  http://docs.nvidia.com/deeplearning/ngc
Initializing nvidia-docker volume...

Please enter your NGC APIkey to login to the NGC Registry:

ここで、先ほど生成した API キーを入力(ペースト)します。

Logging into the NGC Registry at nvcr.io...Login Succeeded

こうなれば NGC 利用準備完了です。コンテナを動かす前に、 GPU を確認してみます。

$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.81                 Driver Version: 384.81                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:00:1E.0 Off |                    0 |
| N/A   32C    P0    19W / 300W |     10MiB / 16152MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

本当に Tesla V100 SXM2 だ!テンション上がりますねー

では、コンテナを動かしてみます。NGC サイトの AWS のチュートリアルにある、PyTorch での MNIST 手書き文字認識が動作確認には手軽です。

$ nvidia-docker run --rm -ti nvcr.io/nvidia/pytorch:17.10
17.10: Pulling from nvidia/pytorch
f5c64a3438f6: Pull complete
51899d335aae: Pull complete
<略>

初回なのでいろいろとダウンロードする必要があり、少し時間がかかりますが、うまくコンテナが動き出しました。

=============
== PyTorch ==
=============

NVIDIA Release 17.10 (build 192702)

Container image Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.

Copyright (c) 2016-     Facebook, Inc            (Adam Paszke)
Copyright (c) 2014-     Facebook, Inc            (Soumith Chintala)
Copyright (c) 2011-2014 Idiap Research Institute (Ronan Collobert)
Copyright (c) 2012-2014 Deepmind Technologies    (Koray Kavukcuoglu)
Copyright (c) 2011-2012 NEC Laboratories America (Koray Kavukcuoglu)
Copyright (c) 2011-2013 NYU                      (Clement Farabet)
Copyright (c) 2006-2010 NEC Laboratories America (Ronan Collobert, Leon Bottou, Iain Melvin, Jason Weston)
Copyright (c) 2006      Idiap Research Institute (Samy Bengio)
Copyright (c) 2001-2004 Idiap Research Institute (Ronan Collobert, Samy Bengio, Johnny Mariethoz)
All rights reserved.

Various files include modifications (c) NVIDIA CORPORATION.  All rights reserved.
NVIDIA modifications are covered by the license terms that apply to the underlying project or file.

NOTE: The SHMEM allocation limit is set to the default of 64MB.  This may be
   insufficient for PyTorch.  NVIDIA recommends the use of the following flags:
   nvidia-docker run --ipc=host ...

root@b3d044efeae1:/workspace#

コンテナの中で、サンプルスクリプトを動かしてみます。

root@b3d044efeae1:/workspace# cd /opt/pytorch/examples/mnist && python main.py
Train Epoch: 1 [0/60000 (0%)]   Loss: 2.390087
<中略>
Train Epoch: 10 [58880/60000 (98%)]     Loss: 0.272635
Train Epoch: 10 [59520/60000 (99%)]     Loss: 0.082086

Test set: Average loss: 0.0553, Accuracy: 9804/10000 (98%)

root@b3d044efeae1:/opt/pytorch/examples/mnist#

1分半ほどで10エポック完了しました。環境構築の手間いらずで、実に簡単ですね。

実行環境を作る (Azure で)

Microsoft Azure の仮想マシンで、Pascal 以降の GPU を搭載しているのは次の3種類です。

  • NCv2 (Tesla P100)
  • ND (Tesla P40)
  • NCv3 (Tesla V100: ただし、2018年1月時点ではプレビュー提供中)

今回は ND シリーズの一番小さいやつ(ND6s)をData Science Virtual Machine for Linux (Ubuntu)で作りました。これは AWS の NVIDIA Volta Deep Learning AMI のように、GPU ドライバや NVIDIA Docker があらかじめインストールされた仮想マシンイメージです。楽ちんです。

2018-01-28_221052.png

ログインしたら GPU を確認。確かに、Tesla P40 が搭載されていますね。こいつの GPU メモリサイズは 24GB と、P100 や V100 よりも大きいのです。

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.111                Driver Version: 384.111                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla P40           Off  | 00008B49:00:00.0 Off |                    0 |
| N/A   25C    P8    11W / 250W |     10MiB / 22912MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

では、動作確認を。Azure の場合、 AWS の NVIDIA Volta Deep Learning AMI のようにログイン時に NGC のキーを入力していませんので、まずは NGC へのログインが必要です。

下記コマンドの ‘$oauthtoken’ の部分は「環境に応じて適切に置き換えてください」という意味ではなく、「そのまま」入力してください。シェルに変数展開されないようにシングルクォートで括る必要があります。

$ docker login -u '$oauthtoken' --password-stdin nvcr.io <<< 'API キー'
Login Succeeded

あとは、AWS の場合と同じです。こちらでも PyTorch の MNIST を試してみました。同じことをやっても面白くありませんが、「同じものがどこでも動く」というのがコンテナの便利なところなので。

$ nvidia-docker run --rm -ti nvcr.io/nvidia/pytorch:17.10

=============
== PyTorch ==
=============

NVIDIA Release 17.10 (build 192702)

Container image Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.

<略>

root@84835550d223:/opt/pytorch/examples/mnist# cd /opt/pytorch/examples/mnist && time python main.py

<略>

Train Epoch: 1 [0/60000 (0%)]   Loss: 2.390087
Train Epoch: 1 [640/60000 (1%)] Loss: 2.350225

<略>

Train Epoch: 10 [58880/60000 (98%)]     Loss: 0.307370
Train Epoch: 10 [59520/60000 (99%)]     Loss: 0.081178

Test set: Average loss: 0.0546, Accuracy: 9813/10000 (98%)

root@84835550d223:/opt/pytorch/examples/mnist#

(当たり前ですが) 無事に動きました。簡単ですね。

実行環境を作る (自宅の PC 等で)

さて、2種類のクラウドを試しましたが、次に自宅の PC でも試してみました。環境は次の通りです。

  • OS: Ubuntu 16.04.3 LTS
  • GPU: GeForce GTX 1050 Ti (Pascal 世代)

Deep Learning AMI のような便利なものはないので、GPUのドライバと NVIDIA Docker は自分でインストールする必要があります。

GPU ドライバのインストール

NVIDIA のドライバダウンロードページから、自分の GPU に対応したドライバのインストーラーをダウンロードしてインストールします。なお、NVIDIA Docker さえ動けば良いので、CUDA Toolkit のインストールは不要です。

NVIDIA Docker のインストール

NVIDIA Docker のインストールには前提条件として Docker が必要です。私はこちらのページを参考にして、Docker CE をインストールしました。実行したコマンドは次の通りです。

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install docker-ce

次に、 NVIDIA Docker をインストールします。こちらのページに手順がまとまっています。実行したコマンドは次の通りです。

curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/ubuntu16.04/amd64/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt update

sudo apt install nvidia-docker2
sudo pkill -SIGHUP dockerd

あと、sudo なしで Docker を実行できるように、自分を docker グループに追加しました。

sudo gpasswd -a 自分 docker

コンテナの動作確認

「またか」という感じですが、PyTorch で MNIST してみます。

$ docker login -u '$oauthtoken' --password-stdin nvcr.io <<< 'API キー'
Login Succeeded
$ nvidia-docker run --rm -ti nvcr.io/nvidia/pytorch:17.10

=============
== PyTorch ==
=============

NVIDIA Release 17.10 (build 192702)

Container image Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.

<略>

root@2dc683eff1b2:/opt/pytorch/examples/mnist# cd /opt/pytorch/examples/mnist && python main.py

<略>

Train Epoch: 1 [0/60000 (0%)]   Loss: 2.390087
Train Epoch: 1 [640/60000 (1%)] Loss: 2.350225

<略>

Train Epoch: 10 [58880/60000 (98%)]     Loss: 0.288593
Train Epoch: 10 [59520/60000 (99%)]     Loss: 0.084271

Test set: Average loss: 0.0529, Accuracy: 9821/10000 (98%)

root@2dc683eff1b2:/opt/pytorch/examples/mnist#

無事に動きました!

まとめ

NVIDIA GPU Cloud のコンテナを、2種のクラウドと自宅の PC で動かしてみました。
AWS と Azure は GPU ドライバと NVIDIA Docker インストール済みの仮想マシンイメージが使えるのでとても簡単。それ以外の環境でも、NVIDIA Docker の環境さえ作ってしまえば、あとは毎月更新される最新のコンテナを活用することで、環境構築とメンテナンスをかなり効率化できます。是非お試しを!

関連情報

続きを読む

Amazon Linux 2 で Rails アプリケーションのサーバーを構成してみる

Amazon Linux 2 の特徴

  • AWS INTEGRATION

    • AWS tools (e.g. AWS CLI) と cloud-init が入った
  • LONG TERM SUPPORT
  • EXTRAS REPOSITORY FOR SOFTWARE PACKAGES
    • amazon-linux-extras で nginx などのパッケージを管理できる
  • ON-PREMISES USE
    • オンプレ利用用途に VM Image などが用意されている
  • SYSTEMD SUPPORT
  • TUNED LTS KERNEL AND NEW TOOLCHAIN
  • SECURITY CONFIGURATIONS
  • SECURITY UPDATES

インスタンスの作成

AMI 選択画面で Amazon Linux 2 LTS Candidate AMI 2017.12.0 (HVM), SSD Volume Type (ami-c2680fa4) を選択してインスタンスを立てる.

公開鍵の追加

vi ~/.ssh/authorized_keys

ユーザーの追加

sudo adduser deploy

ライブラリのインストール

sudo yum -y install 
git make gcc-c++ patch 
openssl-devel 
libyaml-devel libffi-devel libicu-devel 
libxml2 libxslt libxml2-devel libxslt-devel 
zlib-devel readline-devel 
mysql mysql-server mysql-devel 
ImageMagick ImageMagick-devel 
epel-release protobuf-devel

デプロイ先フォルダの用意

sudo mkdir /var/www
sudo chown deploy /var/www/
sudo mkdir /var/www/deploy
sudo chown deploy /var/www/deploy/

nginx のインストール

Amazon Linux 2 では amazon-linux-extras で入れる.

# 確認する
amazon-linux-extras
# install する
sudo amazon-linux-extras install nginx1.12
# ついでに emacs も入れる
sudo amazon-linux-extras install emacs

nginx の起動

# 起動
sudo systemctl start nginx.service
# ステータスの確認
sudo systemctl status nginx.service
# systemd を有効化
sudo systemctl enable nginx.service
# 有効になっているか確認
systemctl is-enabled nginx.service

nginx の設定

# nginx の設定ファイル
sudo vi /etc/nginx/nginx.conf
# 設定再読込
sudo nginx -s reload

ffmpeg

sudo rpm --import http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro
sudo rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-1.el7.nux.noarch.rpm
mkdir ~/tmp
cd ~/tmp
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum -y localinstall epel-release-latest-7.noarch.rpm
sudo yum -y install ffmpeg ffmpeg-devel

wkhtmltoimage

https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.4/wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
tar -xvf wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
sudo mv wkhtmltox/bin/wkhtmltoimage /usr/bin/wkhtmltoimage

NodeJS

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
source ~/.bashrc
nvm install v8.9.4
nvm use v8.9.4
nvm alias default v8.9.4

Ruby

sudo git clone https://github.com/sstephenson/rbenv.git /usr/local/rbenv
sudo git clone https://github.com/sstephenson/ruby-build.git /usr/local/rbenv/plugin/ruby-build
sudo /usr/local/rbenv/plugin/ruby-build/install.sh
sudo vi /etc/profile.d/rbenv.sh
sudo su -
source /etc/profile.d/rbenv.sh
rbenv install 2.4.3
rbenv global 2.4.3
gem install bundler --no-ri --no-rdoc

タイムゾーン, host の修正

timedatectl, hostnamectl を利用する.

sudo timedatectl set-timezone Asia/Tokyo
sudo hostnamectl set-hostname deploy.dot.com
sudo reboot

New Relic Infrastructure の追加

https://rpm.newrelic.com/accounts/813076 でライセンスキー確認

echo "license_key: YOUR_LICENSE_KEY" | sudo tee -a /etc/newrelic-infra.yml
sudo curl -o /etc/yum.repos.d/newrelic-infra.repo https://download.newrelic.com/infrastructure_agent/linux/yum/el/7/x86_64/newrelic-infra.repo
sudo yum -q makecache -y --disablerepo='*' --enablerepo='newrelic-infra'
sudo yum install newrelic-infra -y

公開鍵

sudo su - deploy
mkdir ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
# デプロイするサービスの公開鍵を追加
vi ~/.ssh/authorized_keys

refs

続きを読む

AWS Batchで固定されたEC2インスタンスのGPUを使う

背景

AWS Batchでは、Jobの定義とAMIの指定を行うことで、
1. 自動でEC2インスタンスを立ち上げ
2. Dockerコンテナを起動
3. コンテナ終了時にEC2インスタンスの自動削除
を行ってくれます。

しかし、EC2インスタンスの料金体系では、毎回インスタンスを立ち上げ・削除するのはコスパが悪いため、Jobが実行されるEC2インスタンスを固定して、実行中以外は削除ではなく、「停止」にしたい!

ということで、その手順をまとめました。
AWS Batch、あるいはAmazon ECS(Elastic Container Service)でGPUを使うための設定も含まれていますので、インスタンスの固定はいいや、という方にも参考になれば、と思います。

AWS Batchの設定

Compute environments(=ECS Cluster)

AWS Batch > Compute environments > Create environment から、AWS BatchのJobを実行する計算環境を作成します。この計算環境は、ECSのClusterとして保存されます。(ECS Clusterが自動で生成され、Compute environmentsに紐付けされます。)

  • Managed:
    AMIを指定しておくことで、Jobの実行時にそのAMIで新たにEC2インスタンスを立ち上げてくれます。
  • Unmanaged:
    Compute environmentsに紐付いたECS Clusterを生成します。EC2インスタンスは、自分でそのClusterに登録する必要があります。

作成されたClusterをECSコンソールから確認しましょう。後ほど使います。
<EnvironmentName>_Batch_<ランダムっぽい文字列> のような名前担っているはずです。

Job Queue

Job Queueは、上記で作成したEnvironmentを選択してください。

Job Definition

Volumes

Name Source path
nvidia /var/lib/nvidia-docker/volumes/nvidia_driver/latest

Mount points

Container path Source volume Read only
/usr/local/nvidia nvidia false

ECSで使える(Dockerが動かせる)EC2インスタンスを用意する

ECS用に最適化されたAMIはAWSから提供されていますが、GPUが載ったものでECS用に最適化されたAMIは提供されていません。

用いるAMIを決める

AWS Batchのドキュメント GPU ワークロードの AMI の作成 にある例では Deep Learning AMI with Source Code (CUDA 9, Amazon Linux) を使用していますが、今回は Deep Learning Base AMI (Amazon Linux) を使用することにしました。
(AWS Batchを用いる = Dockerを用いるので、Hostマシンに機械学習ライブラリは不要。 & Cuda, CuDNNのバージョンが複数あるので、動かすDockerImageが変わった時に助かりそう。)
ここは、必要に応じてaws marketplaceでいろいろ探してみるとよいかと思います。

インスタンスを起動する

IAM

インスタンスからECSに向けたIAM Roleが必要です。Roleの設定がない場合は、EC2コンソールから設定をしましょう。

UserData

UserData
#!/bin/bash
echo "ECS_CLUSTER=<ClusterName>" >> /etc/ecs/ecs.config

Dockerが使えるようにする

上記のAMIのままでは、Dockerが使えないので、ドキュメントを参考に、ECSで使える状態のインスタンスを作成していきます。

configure-gpu.sh
#!/bin/bash
# Install ecs-init, start docker, and install nvidia-docker
sudo yum install -y ecs-init
sudo service docker start
wget https://github.com/NVIDIA/nvidia-docker/releases/download/v1.0.1/nvidia-docker-1.0.1-1.x86_64.rpm
sudo rpm -ivh --nodeps nvidia-docker-1.0.1-1.x86_64.rpm

# Validate installation
rpm -ql nvidia-docker
rm nvidia-docker-1.0.1-1.x86_64.rpm

# Make sure the NVIDIA kernel modules and driver files are bootstraped
# Otherwise running a GPU job inside a container will fail with "cuda: unknown exception"
echo '#!/bin/bash' | sudo tee /var/lib/cloud/scripts/per-boot/00_nvidia-modprobe > /dev/null
echo 'nvidia-modprobe -u -c=0' | sudo tee --append /var/lib/cloud/scripts/per-boot/00_nvidia-modprobe > /dev/null
sudo chmod +x /var/lib/cloud/scripts/per-boot/00_nvidia-modprobe
sudo /var/lib/cloud/scripts/per-boot/00_nvidia-modprobe

# Start the nvidia-docker-plugin and run a container with 
# nvidia-docker (retry up to 4 times if it fails initially)
sudo -b nohup nvidia-docker-plugin > /tmp/nvidia-docker.log
sudo docker pull nvidia/cuda:9.0-cudnn7-devel
COMMAND="sudo nvidia-docker run nvidia/cuda:9.0-cudnn7-devel nvidia-smi"
for i in {1..5}; do $COMMAND && break || sleep 15; done

# Create symlink to latest nvidia-driver version
nvidia_base=/var/lib/nvidia-docker/volumes/nvidia_driver
sudo ln -s $nvidia_base/$(ls $nvidia_base | sort -n  | tail -1) $nvidia_base/latest

スクリプトの実行(Step 4.)

bash ./configure-gpu.sh

これで環境は完成していますが、念のため動作確認(Step 5. )

sudo docker run –privileged -v /var/lib/nvidia-docker/volumes/nvidia_driver/latest:/usr/local/nvidia nvidia/cuda:9.0-cudnn7-devel nvidia-smi

DockerからGPUが使えることを確認できたら(以下のような $ nvidia-smi の結果が見られれば) OKです。

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.81                 Driver Version: 384.81                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  Off  | 00000000:00:17.0 Off |                    0 |
| N/A   43C    P0    42W / 300W |     10MiB / 16152MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

ECS Clusterにインスタンスを登録する

Check 1
インスタンスからECSに向けたIAM Roleが必要です。Roleの設定がない場合は、EC2コンソールから設定をしましょう。

Check 2
Clusterにインスタンスを登録するには、インスタンス側での設定が必要です。インスタンス起動時のユーザデータで下記ファイルがきちんと作られていることを確認。できていなければ作りましょう。

/etc/ecs/ecs.config
ECS_CLUSTER=<ClusterName>

ドキュメント のStep 6., 7.的なことをしてあげると、Clusterにインスタンスが登録されます。(しばらく時間がかかります)

sudo docker rm $(sudo docker ps -aq)

sudo docker rmi $(sudo docker images -q)

sudo restart ecs

Submit Job

お好きなフックでどうぞ

EC2インスタンスを停止する

Managedであれば自動でインスタンスを削除してくれますが、Unmanagedの場合、インスタンスの停止も自分で行わなければなりません。
今回は、Jobの成功、失敗にかかわらず停止したいので、以下のpythonスクリプトを自作し、AWS Lambda x CloudWatchEventsで走らせることにしました。

  • [‘SUBMITTED’, ‘PENDING’, ‘RUNNABLE’, ‘STARTING’, ‘RUNNING’] のいずれかの状態のJobがあればそのまま。
  • いずれの状態のJobもなければ、停止。
import os
import boto3

JOB_NAME = os.environ['JOB_NAME']
JOB_QUEUE = os.environ['JOB_QUEUE']
INSTANCE_ID = os.environ['INSTANCE_ID']


def is_running():
    batch = boto3.client('batch')

    check_status = ['SUBMITTED', 'PENDING', 'RUNNABLE', 'STARTING', 'RUNNING']
    for s in check_status:
        list = batch.list_jobs(
            jobQueue=JOB_QUEUE,
            jobStatus=s
        )['jobSummaryList']
        if list:
            print(f"{[j['jobId'] for j in list]} are still {s}.")
            return True
    else:
        return False


def ec2_stop():
    ec2 = boto3.client('ec2')

    response = ec2.describe_instances(
        InstanceIds=[INSTANCE_ID]
    )
    if response['Reservations'] and response['Reservations'][0]['Instances']:
        state = response['Reservations'][0]['Instances'][0]['State']['Name']

        if state in {'pending', 'running'}:
            print(f"Start to stop the instance: {INSTANCE_ID}")
            response = ec2.stop_instances(
                InstanceIds=[INSTANCE_ID]
            )
        else:
            print(f"The instance {INSTANCE_ID} is not running.")
    else:
        raise ValueError(f'No Such Instances: [{INSTANCE_ID}]')

def lambda_handler(event, context):
    if not is_running():
        ec2_stop()

最後に

こんなことするくらいなら、最初からBatchじゃなくて、ECSにしとけばよかったんちゃうか、と思いながら。
ただ新しいものに触れて、上記以外の学びも得たので、それはまた別の時に。

続きを読む

AWS EBS勉強まとめ

2017年新しい機能追加
==
・起動ボリュームの暗号化をサポート

スループット最適化HDD
高スループットを必要とするワークロード(MapReduce、Kafka、ETL処理、ログ処理、データウェアハウスなど)向けのタイプ; 1GBあたり月額0.054ドル
コールドHDD
同様のワークロードでアクセス頻度が低いユースケース向け; 1GBあたり月額0.03ドル
プロビジョンドIOPS SSD
I/O性能に依存するNoSQLデータベースやリレーショナルデータベース
汎用SSD
起動ボリューム、低レイテンシを要求するアプリケーション、開発・テスト環境
マグネティック
アクセス頻度の低いデータ
参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-cold-storage-and-throughput-options/

・汎用SSDボリュームのバーストクレジットの残高がCloudWatchで確認可能(残高はパーセンテージ)

・稼働中のEBSをオンラインのまま、ダウンタイムなく、変更することを可能にするエラスティックボリューム機能をリリース

・現行世代のインスタンスに関しては下記可能
①容量の拡張
②IOPS値の変更(PIOPSボリュームのみ)
③ボリュームタイプの変更(汎用SSD→コールドHDDなど)
→CloudWatchとCloudFormationやAWS Lambdaなどで自動化も可能

参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-elastic-volumes-change-everything/

・EBSスナップショットにコスト配分タグをサポート
→コスト集計ができるようになった
==

・EBSスナップショットはS3に保存
・AZごとに独立。同一AZのインスタンスのみから利用可能
→しかし、Snapshotから任意のAZに復元可能
・EC2に複数のEBSを接続可能だが、反対は不可

・EBSはレプリケートされているので、冗長化は不要
・セキュリティグループによる制御の対象外。全ポートを閉じてもEBSは利用できる

・インスタンスストアVSEBS
インスタンスストア:揮発性。EC2のローカルディスク。仮想マシンが止まるとデータ消去。一時的なデータの置き場所などに利用。
EBS:永続化ストレージ。OSやDBのデータなど永続化のデータ用。

・スペックは下記の順
プロビジョンドIOPS→汎用SSD→スループット最適化HDD→コールドHDD→マグネティック

SSDの種類は下記2種類
汎用SSD
I/O機能を一時的に3000IOPSまで上げるバースト機能付き
→I/O Creditが必要。CloudWatchで監視可能。上限(540万I/Oクレジット)に対するパーセント
容量:1GB~16TB
IOPS:ベースは100IOPS。最大10000IOPS
スループット:128MB/秒~160MB/秒

プロビジョンドIOPS
容量:4GB~16TB
IOPS:50IOPS/1GB。最大20000IOPS
スループット:最大320MB/秒

HDDの種類は下記2種類
→小さいデータのランダムアクセスになりがちな処理、起動ボリューム、データベース、ファイルサーバー等への利用は非推奨
→ログ処理などのシーケンシャルアクセス用途。アクセス頻度が低いもの

スループット最適化HDD
容量:500GB~16TB
IOPS:最大500IOPS
スループット:40MB/秒がベース

コールドHDD
容量:500GB~16TB
IOPS:最大250IOPS
スループット:12MB/秒がベース

マグネティック
磁気ディスクタイプ
容量:1GB~1TB
IOPS:100IOPS
スループット:40MB/秒~90MB/秒
I/Oリクエスト回数による課金が唯一ある

EBS最適化インスタンス
EC2とEBSの独立した帯域を確保し、I/O性能の安定化

事前ウォーミング
Snapshotから復元したボリュームへの初回アクセス時に設定

・EBSのパフォーマンス改善
①EC2インスタンス側のスループット
EBS最適化を有効にする
EBSからのスループットの上限値に到達していないかをCloudWatchのVolume Read/Write Bytesの合計値で確認

②EBSが処理できるIOPS
CloudWatchのVolume Read/Write Opsを参照

③各EBSボリュームのスループット
CloudWatchのVolume Read/Write Bytesの合計値で確認

・Snapshot
EBSのバックアップ機能
S3に保管。2世代目以降は増分バックアップ。1世代目を削除しても復元可能
ブロックレベルで圧縮して保管するため、圧縮後の容量に対して課金
データ整合性を保つため、静止点を設けることを推奨
別AZに移動したい場合や、容量変更などもSnapshot経由で行う

・バックアップと静止点
EBSへのI/O停止→Snapshot作成指示→作成指示レスポンス→EBSへのI/O再開
※Snapshotの作成完了前にEBSへのI/O再開してよい

・Snapshotの削除
1世代目を削除しても、1世代目にしかないデータは削除されない

・リージョン間コピーをサポート
リージョン間でのコピーも可能

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-elastic-block-store-ebs

続きを読む

Cronから実行するEC2スナップショットスクリプト

実行条件

  • awscliがインストールされている
  • IAMロールなどでEC2周りの権限を解放しておく
#!/bin/sh

# 取得したインスタンスのidを並べる
INSTANCE_ID=(i-xxxxx1 i-xxxxx2 i-xxxxx3)

SHELLDIR=`dirname ${0}`
SHELLDIR=`cd ${SHELLDIR}; pwd`
SHELLNAME=`basename $0`

LOG_DIR="/var/log"
LOG_SAVE_PERIOD=14
LOG_FILE="${LOG_DIR}/${SHELLNAME}.log"
echo $LOG_FILE

REGION=ca-central-1
SNAPSHOTS_PERIOD=2

AWS="/usr/bin/aws --region ${REGION}"


rotate_log() {
    (( cnt=${LOG_SAVE_PERIOD} ))
    while (( cnt > 0 ))
    do
        logfile1=${LOG_FILE}.$cnt
        (( cnt=cnt-1 ))
        logfile2=${LOG_FILE}.$cnt
        if [ -f $logfile2 ]; then
            mv $logfile2 $logfile1
        fi
    done

    if [ -f $LOG_FILE ]; then
        mv ${LOG_FILE} ${LOG_FILE}.1
    fi
    touch $LOG_FILE
}

print_msg() {
    echo "`date '+%Y/%m/%d %H:%M:%S'` $1" | tee -a ${LOG_FILE}
}

create_snapshot() {
    for ID in `echo $@`
    do
        print_msg "Create snapshot Start"
        VOL_ID=`${AWS} ec2 describe-instances --instance-ids ${ID} --output text | grep EBS | awk '{print $5}'`
        if [ -z ${VOL_ID} ] ; then
            echo ${VOL_ID}
            print_msg "ERR:ec2-describe-instances"
            logger -f ${LOG_FILE}
            exit 1
        fi
        print_msg "ec2-describe-instances Success : ${VOL_ID}"
        ${AWS} ec2 create-snapshot --volume-id ${VOL_ID} --description "Created by SYSTEMBK(${ID}) from ${VOL_ID}" >> ${LOG_FILE} 2>&1
        if [ $? != 0 ] ; then
            print_msg "ERR:${SHELLDIR}/${SHELLNAME} ec2-create-snapshot"
            logger -f ${LOG_FILE}
            exit 1
        fi
        print_msg "Create snapshot End"
    done
}

delete_old_snapshot() {
    for ID in `echo $@`
    do
        VOL_ID=`${AWS} ec2 describe-instances --instance-ids ${ID} --output text | grep EBS | awk '{print $5}'`
        print_msg "Delete old snapshot Start"
        SNAPSHOTS=`${AWS} ec2 describe-snapshots --output text | grep ${VOL_ID} | grep "Created by SYSTEMBK" | wc -l`
        while [ ${SNAPSHOTS} -gt ${SNAPSHOTS_PERIOD} ]
        do
            ${AWS} ec2 delete-snapshot --snapshot-id `${AWS} ec2 describe-snapshots --output text | grep ${VOL_ID} | grep "Created by SYSTEMBK" | sort -k 11,11 | awk 'NR==1 {print $10}'` >> ${LOG_FILE} 2>&1
            if [ $? != 0 ] ; then
                print_msg "ERR:${SHELLDIR}/${SHELLNAME} ec2-delete-snapshot"
                logger -f ${LOG_FILE}
                exit 1
            fi
            SNAPSHOTS=`${AWS} ec2 describe-snapshots | grep ${VOL_ID} | grep "Created by SYSTEMBK" | wc -l`
        done
        print_msg "Delete old snapshot End"
    done
}

rotate_log

print_msg "INF:$SHELLDIR/${SHELLNAME} START"
create_snapshot ${INSTANCE_ID[@]}
delete_old_snapshot ${INSTANCE_ID[@]}
print_msg "INF:$SHELLDIR/${SHELLNAME} END"

exit 0

続きを読む