EC2のEBSボリュームをresize2fsせずに拡張する

概要

EC2のEBSボリュームを拡張する(10G -> 90G)
EC2はすでに起動済みのものとする。

背景

EBSのボリュームを拡張したので、ファイルシステム拡張のコマンドを実行!

$ sudo resize2fs /dev/xvda1
The filesystem is already 8972864 blocks long.  Nothing to do!

パーティションの容量が少ないためディスクの拡張ができず、怒られてしまいました・・・。
Linux パーティションの拡張が必要そうですが、ちょっと手順が多い。

しかし、サイズをEBSのサイズをあらかじめ拡張し、スナップショットから新規作成することで
コマンドを実行せずともwebコンソールからディスクを拡張できたので手順をメモ。

事前準備

  • EC2で使用してるEBSのID、ルートデバイスの名前を控える。

スクリーンショット 2017-04-19 20.14.28.png

  • EC2のインスタンスID、アベイラビリティーゾーンを控える。

手順

EBSボリュームサイズを拡張する

※EC2を停止しなくても拡張できますが、拡張中は不安定になります。

ELASTIC BLOCK STORE > ボリューム > アクション > Modify Volume
Sizeの値を変更します。

スクリーンショット 2017-04-19 21.38.05.png

EBSボリュームのスナップショットを作成する

※EC2を停止しなくてもスナップショットを作成できますが、停止したほうが安全です。

ELASTIC BLOCK STORE > ボリューム > アクション > スナップショットの作成

EC2を停止する

以降の作業はEC2を停止しないと行えません。

EBSボリュームをEC2からデタッチする

ELASTIC BLOCK STORE > ボリューム > アクション > ボリュームのデタッチ

既存のEBSをデタッチします。

EBSボリュームのスナップショットから新しいボリュームを作成する

ELASTIC BLOCK STORE > スナップショット > アクション > ボリュームの作成

EC2と同じアベイラビリティゾーンにする必要があります。

スクリーンショット 2017-04-19 20.11.33.png

新規作成したEBSボリュームをEC2にアタッチ

ELASTIC BLOCK STORE > ボリューム > アクション > ボリュームのアタッチ

アタッチしたいEC2のインスタンスを選択します。
事前に控えておいたデバイスを入力します。

スクリーンショット 2017-04-19 20.24.48.png

EC2を起動

これで作業完了です!

ディスクボリュームが拡張されているか確認する

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

$ df -h
ファイルシス       サイズ  使用  残り 使用% マウント位置
/dev/xvda1            89G   84G   5G   18% /

最後に

使用していないEBSは削除しましょう!
EC2にアタッチしていなくても、料金がかかってしまいます。

続きを読む

EC2をAnsibleで管理する

はじめに

AnsibleにはAWSのリソースを操作できるモジュールが豊富に用意されています。

今回は、定番のEC2をAnsibleで管理してみます。

やること

  • EC2インスタンス作成

ポイント

ec2モジュールは、セキュリティグループについては名前で指定できるのですが、サブネットはIDで指定する必要があります。

しかし、サブネットIDをAnsibleのYAMLに書きたくないので、サブネット名からIDを取得する実装とします。

前提

AWS関連のモジュール実行にはbotoが必要です。
credential情報は環境変数かaws configureでセットしてある必要があります。

下記リソースを前提に進めます。

  • VPC

    • AnsibleVPC
  • キーペア
    • keypair
  • サブネット
    • public-a
    • public-c
  • セキュリティグループ
    • common
    • web_server

sample

以下のようなEC2インスタンスを作成します。

  • testinstance1

    • AmazonLinux
    • アベイラビリティゾーンA
    • セキュリティグループ
      • common,web_server
  • testinstance2
    • AmazonLinux
    • アベイラビリティゾーンC
    • セキュリティグループ
      • common

ディレクトリ構成

ディレクトリ構成
site.yml
roles/
|--ec2/
|  |--tasks/
|  |  |--main.yml
hosts/aws    #inventory
host_vars/
|--localhost.yml

inventory

AWSリソース関連モジュールはすべてlocalhostで実行するので、下記のようなインベントリファイルを用意します。

hosts/aws
[aws]
localhost

vars

こんな感じに変数を定義します。今回はhost_varsで定義しました。

host_vars/localhost.yml
---
my_vars:
  aws:
    common:
      region: ap-northeast-1
    vpc:
      name: AnsibleVPC    # ターゲットのVPC名
    ec2:
      testinstance1:
        ami_image: ami-56d4ad31 # Amazon Linux
        key_name: keypair # キーペア名
        security_group:
          - common
          - web_server
        instance_type: t2.micro
        device_name: /dev/xvda
        device_type: gp2
        volume_size: 8 # EBSのディスクサイズ(GB)
        subnet: public-a # サブネット名
        assign_public_ip: yes
        tags:
          Name: testinstance1
          Role: test
      testinstance2:
        ami_image: ami-56d4ad31 # Amazon Linux
        key_name: keypair # キーペア名
        security_group:
          - common
        instance_type: t2.micro
        device_name: /dev/xvda
        device_type: gp2
        volume_size: 8 # EBSのディスクサイズ(GB)
        subnet: public-c # サブネット名
        assign_public_ip: yes
        tags:
          Name: testinstance2
          Role: test

Role

まずVPCを特定するためにidが必要ですが、こちらと同様、VPC名でidを取得します。

今回はリストではなくディクショナリとしてEC2インスタンスを定義しましたので、with_dictでループさせます。

前述のように、サブネットはIDで指定する必要があるので、ec2_vpc_subnet_factsモジュールでIDを取得します。

定義されたEC2インスタンスの全てのサブネット名とIDのディクショナリを作成し、後続taskで参照します。

あとはec2モジュールで作成しますが、exact_count: 1を指定することで重複作成を防止します(stop状態だと作成されてしまいますが)。

roles/vpc/tasks/main.yml
---
- name: vpc_id取得
  ec2_vpc_net_facts:
    region: "{{ my_vars.aws.common.region }}"
    filters:
      "tag:Name": "{{ my_vars.aws.vpc.name }}"
  register: vpc_net_fact

- debug: var=vpc_net_fact

- name: subnet id取得
  ec2_vpc_subnet_facts:
    region: "{{ my_vars.aws.common.region }}"
    filters:
      vpc_id: "{{ vpc_net_fact.vpcs[0].id }}"
      "tag:Name": "{{ item.value.subnet }}"
  with_dict: "{{ my_vars.aws.ec2 }}"
  register: subnet_fact
  when: my_vars.aws.ec2 is defined

- name: subnet dict作成
  set_fact:
    subnet_dict: >-
      {%- set dict = {} -%}
      {%- for i in range(subnet_fact.results|length) -%}
      {%-   set _ = dict.update({subnet_fact.results[i].subnets[0].tags.Name: subnet_fact.results[i].subnets[0].id}) -%}
      {%- endfor -%}
      {{ dict }}
  when: my_vars.aws.ec2 is defined

- name: EC2インスタンスを作成
  ec2:
    image: "{{ item.value.ami_image }}"
    instance_type: "{{ item.value.instance_type }}"
    region: "{{ my_vars.aws.common.region }}"
    key_name: "{{ item.value.key_name }}"
    group: "{{ item.value.security_group }}"
    vpc_subnet_id: >-
      {%- set id = subnet_dict[item.value.subnet] -%}
      {{ id }}
    instance_tags: "{{ item.value.tags }}"
    assign_public_ip: "{{ item.value.assign_public_ip }}"
    private_ip: "{{ item.value.private_ip }}"
    wait: yes
    wait_timeout: 300
    volumes:
      - device_name: "{{ item.value.device_name }}"
        device_type: "{{ item.value.device_type }}"
        volume_size: "{{ item.value.volume_size }}"
        delete_on_termination: true
    count_tag:
      Name: "{{ item.value.tags.Name }}"
    exact_count: 1
    user_data: |
      #!/bin/bash
      # 初期設定スクリプトなど
  with_dict: "{{ my_vars.aws.ec2 }}"
  register: ec2
  when: my_vars.aws.ec2 is defined

- debug: var=ec2

site.yml

site.yml
---
- name: ec2
  hosts: localhost
  connection: local
  roles:
    - role: ec2

実行

Command
$ ansible-playbook -i hosts/aws -l localhost site.yml

まとめ

ネット上のサンプルでもサブネットIDを指定している例がほとんどですが、実際YAMLで管理する場合、IDではなく名前の方が分かりやすいと思います。
参考になれば幸いです。

参考

続きを読む

AWSでSSH接続できなくなってしまったときの復旧方法

AWSでEBSを追加したらSSH接続できなくなってしまった事案があり、復旧にちょっとハマったので備忘も兼ねて記載していきます。
オンプレサーバーと違って、クラウドだとSSH接続できないと何もできなくなっちゃいますからね。

手順

  1. 対象インスタンスのEBSのスナップショットを取得(バックアップ用)
  2. 作業用インスタンスを作成
  3. 作業用インスタンスに、対象インスタンスのEBSをアタッチ&マウント
  4. SSH等の設定を見直し&修正
  5. 対象インスタンスに、元のEBSをアタッチ

SSH接続できなくなっちゃう原因

以下のような時に、この方法は役立ちます。

  • ファイアーウォールの設定ミス
  • キーペアの紛失
  • OS設定ミスで起動しなくなっちゃった

1. 対象インスタンスのEBSのスナップショットを取得(バックアップ用)

現状のバックアップをとっておくために、対象のEBSを右クリックしてスナップショットを取得しましょう。EC2_Management_Console.png

2. 作業用インスタンスを作成

SSHできなくなっちゃったインスタンスと同様のインスタンスを作ります。
対象インスタンスを右クリックして出てくる、「同様のものを作成」で簡単にできちゃいます。
EC2_Management_Console.png

3. 作業用インスタンスに、対象インスタンスのEBSをアタッチ&マウント

対象のインスタンスをストップしてEBSをデタッチします

EC2_Management_Console.png

作業用インスタンスに、先程デタッチしたEBSをアタッチします

  • ボリュームのアタッチを選択
    EC2_Management_Console.png

  • 作業用インスタンスIDを選択
    EC2_Management_Console.png
    デバイスは def/sdf で問題ないはず。(エラーが出る場合は環境に合わせて変更してください)

作業用インスタンスにSSH接続して先程アタッチしたEBSをマウントします

  • 作業用インスタンスにSSH接続します
  • ディスクの状態を確認
[centos@ ~]$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  30G  0 disk 
└─xvda1 202:1    0  30G  0 part /
xvdf    202:80   0  30G  0 disk 
└─xvdf1 202:81   0  30G  0 part 
  • マウントポイントを作成
sudo mkdir /mnt/xvdf
  • ディスクをマウント
mount -t xfs /dev/xvdf /mnt/xvdf/ -o nouuid
  • マウントすると中身のファイルが見えるようになるので、SSHやファイアーウォールの設定を見直す。
  • 作業用インスタンスからEBSをデタッチ
  • 対象インスタンスにEBSをアタッチ

続きを読む

AWS EBSのリサイズをシェルスクリプトにまとめてみた

はじめに

AWSのストレージサービスならばとりあえずS3を選んでおけば間違いはないのでしょうけど,既存サービスを短期間でAWSに移行する場合にはEBSを使うことがあるかと思います.以前はEBSの容量を変更できませんでしたので,事前に余裕を持って確保するか,都度容量を割り当ててデータを移行するか悩ましいところでした.

2017年2月にAWSよりEBSの新機能について発表があり,EBSの容量やタイプ,IOPSなどがオンザフライで変更できるようになりました.そこで,EBSの空き容量が閾値を下回ったときに拡張するシェルスクリプトを用意し,定期的に実行することでお財布への負担と管理運用作業を軽くしてみました.

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

書いてみた

  • スペシャルデバイス名とEBSボリューム名(Nameタグに割り当てた文字列)を指定して実行します.
  • 使用容量が95%に達したら,80%弱になるくらいに拡張します.
  • Amazon Linuxでroot権限で実行することを前提としています.
  • 2017年4月の時点でのAmazon Linuxにプレインストールされているaws-cliではaws ec2 modify-volumeに未対応なため,アップデートが必要でした.
  • JSONのパースにjqが必要なので,事前にインストールしてください.
#!/bin/sh
#
# $ sudo yum install jq
# $ sudo pip install -U awscli
# # sh ./ebs-resize.sh -d /dev/xvdf -v ebs-volume-name
#

usage() {
  echo "Usage: $0 -d device-name -v ebs-volume-name" 1>&2
  exit 1
}

while getopts d:v:h OPT
do
  case $OPT in
    'd')
      DEVICE_NAME=$OPTARG
      ;;
    'v')
      VOLUME_NAME=$OPTARG
      ;;
    'h')
      usage
      ;;
    ?)
      usage
      ;;
  esac
done

shift $((OPTIND - 1))

if test ${#DEVICE_NAME} -eq 0 -o ${#VOLUME_NAME} -eq 0; then
  usage
fi

df -k $DEVICE_NAME 1> /dev/null
if test "$?" -ne 0; then
  echo "$DEVICE_NAME is not found."
  exit 1
fi

export THRESHOLD_PERCENT=95
export EXPAND_RATE=1.25
export USED_PERCENT=`df -k $DEVICE_NAME | grep -v Filesystem | awk '{print $5}' | awk -F% '{print $1}'`
export CURRENT_SIZE=`df -k $DEVICE_NAME | grep -v Filesystem | awk '{print $2}'`
export NEW_SIZE=`echo "scale=0;$CURRENT_SIZE * $EXPAND_RATE / 1024 / 1024 + 1" | bc -l`
export AWS_DEFAULT_REGION=`curl --silent http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'`
export INSTANCE_ID=`curl --silent http://169.254.169.254/latest/meta-data/instance-id`
export VOLUME_ID=`aws ec2 describe-volumes --filter "Name=attachment.instance-id,Values=$INSTANCE_ID" "Name=tag:Name,Values=$VOLUME_NAME" |  jq -r '.Volumes[].VolumeId'`

if test ${#VOLUME_ID} -eq 0; then
  echo "$VOLUME_NAME is not found."
  exit 1
fi

if test $USED_PERCENT -ge $THRESHOLD_PERCENT; then
  aws ec2 modify-volume --volume-id $VOLUME_ID --size $NEW_SIZE
  resize2fs $DEVICE_NAME
fi

exit 0

おわりに

crontabに登録して1日1回程度動かすようにしましょう.なおaws ec2 modify-volumeは1度実行すると6時間は変更できないようです.ご利用は計画的に.

リンク

https://gist.github.com/stoshiya/4cafa50b34223aaa2a70c588abbede89

続きを読む

AWS WEBサーバー検証用のTerraform

EC2でWEBサーバーを構築し、さっと検証したいときのTerraform

作成するもの

iamRole
vpc
subnet
ec2
security group

AWS access_key secret_key ec2のkey_nameの設定を各環境ごとにおこなう。

設定

provider "aws" {
  access_key = "******"
  secret_key = "******"
  region     = "ap-northeast-2"
}

data "aws_availability_zones" "available" {}

resource "aws_vpc" "sample-test-vpc" {
  cidr_block           = "10.1.0.0/16"
  instance_tenancy     = "default"
  enable_dns_support   = "true"
  enable_dns_hostnames = "true"

  tags {
    Name = "sample-test-vpc"
  }
}

resource "aws_iam_instance_profile" "base_profile" {
  name  = "BaseIAMRoleProfile"
  roles = ["${aws_iam_role.base_role.name}"]
}

resource "aws_iam_role" "base_role" {
  name = "BaseIAMRole"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
}

resource "aws_iam_role_policy" "instance_role_policy" {
  name = "BaseIAMRolePolicy"
  role = "${aws_iam_role.base_role.id}"

  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
{
      "Effect": "Allow",
      "Action": ["organizations:DescribeOrganization"],
      "Resource": "*"
    }
  ]
}
EOF
}

//subnet とりあえず1つ作る
resource "aws_subnet" "sample-test-subnet" {
  count                   = 1
  vpc_id                  = "${aws_vpc.sample-test-vpc.id}"
  cidr_block              = "10.1.${count.index}.0/24"
  availability_zone       = "${data.aws_availability_zones.available.names[count.index]}"
  map_public_ip_on_launch = true

  tags {
    Name = "sample-test-vpc.sample-test-subnet-${count.index}"
  }
}

resource "aws_internet_gateway" "sample-gw" {
  vpc_id = "${aws_vpc.sample-test-vpc.id}"

  tags {
    Name = "sample-gw"
  }
}

resource "aws_route_table" "sample-route-table" {
  vpc_id = "${aws_vpc.sample-test-vpc.id}"

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_internet_gateway.sample-gw.id}"
  }
}

resource "aws_route_table_association" "sample-test-subnet-route-table-association" {
  count          = 2
  subnet_id      = "${element(aws_subnet.sample-test-subnet.*.id, count.index)}"
  route_table_id = "${aws_route_table.sample-route-table.id}"
}

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インスタンス作成 
resource "aws_instance" "sample-ec2" {
  ami                         = "${data.aws_ami.amazon_linux.id}"
  instance_type               = "t2.micro"
  key_name                    = "your-keyname"
  associate_public_ip_address = true
  iam_instance_profile        = "${aws_iam_instance_profile.base_profile.name}"
  subnet_id                   = "${aws_subnet.sample-test-subnet.0.id}"
  vpc_security_group_ids      = ["${aws_security_group.sample-sec.id}"]

  tags {
    Name = "TEST"
  }
}

//セキュリティグループ 80 443 22 を許可 ip制限は各自で。 
resource "aws_security_group" "sample-sec" {
  name        = "sample-sec"
  description = "test-sg for tf test"

  vpc_id = "${aws_vpc.sample-test-vpc.id}"

  //アウトバウンド

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  /*インバウンド*/
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}




続きを読む

AWS ServiceCatalogまとめ

この記事の目的

  • ServiceCatalogでの環境構築を組織内に展開するためにやったことの個人的な整理
  • ServiceCatalogの情報が圧倒的に少ないので
  • ServiceCatalogを利用するにあたってのつまづきどころなど、わかったことを記載

はじめに

  • ServiceCatalog自体の細かい説明は割愛

  • 2017/03時点の情報

  • 筆者が使い始めたのが2016/12ぐらいからなので、それ以降のお話

  • アップデートはこまめにあるようなので、今後は解消されている可能性は高い

ServiceCatalogの概要

  • 「管理者」と「ユーザー」に別れる
  • 「ユーザー」は管理者が用意した「ポーフォトリオ」にある「製品」を通じてAWSリソースの作成が可能
    • 製品(Product):CloudFormationテンプレートに対応
    • ポートフォリオ(Portfolio):製品の集合
  • 課金は”ポートフォリオにユーザーを割り当てたタイミングで1ヶ月分発生”
    • ポートフォリオにはIAMユーザー、IAMロールを割り当てられる
    • ロールにだけ割り当てて、Switchロールで使うと課金されないみたい
  • リソース作成を「製品の起動(Launch Product)」と呼び、パラメータ変更は「製品の更新(Update Product)」、リソース削除は「製品の終了(Terminate Product)」

ServiceCatalogのいいところ

  • オンラインドキュメントの説明

    • エンタープライズな組織内での利用において「標準化」は1つのポイント
  • ユーザーに直接EC2作成(RunInstance)権限を与えずに、インスタンス作成をさせることができる
    • リソースタグ付けを強制させることができるのでその後の操作はタグを条件にIAMポリシーで制御できる
    • リソース作成時にどのIAMロールで行うかを管理者が指定できる(起動制約)
  • EC2インスタンスタイプの変更もServiceCatalog経由で行うことで不用意に巨大なインスタンスを作成してしまうこともない
    • ユーザーごと(正確にはポートフォリオごとに、製品ごと)にパラメータ値を制限できる(テンプレート制約)
    • 製品ではすべてのインスタンスタイプを指定できるようにしてあるが、ユーザーAにはlargeまで、ユーザーBには4xlargeまで、といった具合

などなど。

使ってみた”つかいどころ”

  • EC2にCloudWatchAlermのAutoRecoveryを必ずセットで作成
  • EBSボリュームは1つだけ必ず付けて、KMSキーで暗号化
  • RDSも暗号化強制
  • RDSにはセキュリティグループを必ず付けて、セットで作ったEC2からのみ通信許可
  • 管理者が割り当てたSubnet内にのみリソース作成可能に
  • RDSのライセンスタイプにBYODは使わせない(ライセンス違反があると危ない)

などなど。

ServiceCatalogの最近のアップデート

ServiceCatalogの困ったところ

製品(Product)のCloudFormationテンプレート

  • CloudFormationで使えてもServiceCatalog製品としては使えないことがある

    • YAML対応したものの、CloudFormationのYAML短縮形(!Ifとか)は使えない。無視されるので構文エラーになる。。
    • そして製品起動後にエラー。(通常の文法エラーであれば、製品登録時にエラーになる)
  • ManagementCosoleから製品の古いバージョンを削除する方法がない
  • ParameterのDescriptionに<br>,<h1>,<strong>,<font>タグが使える
    • <script>タグなどはさすがにサニタイジングされる
    • CloudFormationでは単にすべてテキストとして解釈される
    • 今後も使えるかというと、使えなくなるのではないかと思われる

製品(Product)起動時の挙動

  • CloudFormationと違って、AllowedPatternでの精査は製品起動後に行われる

    • これにより失敗した製品は削除するしかない
    • が、何故か製品の更新(Update Provisioned Product)ができてしまい、かつ即時成功となりAvailableとなってなんだかわからなくなる
  • テンプレート制約で、Stringパラメータの未入力チェックが設定できるが、これも起動後にチェックされる
    • 未入力でなく、入力値の組み合わせなどの制約は起動前にチェックされるのに。。
  • テンプレート制約条件の属性値として、VPCやSubnet、SecurityGroupのタグ値を使える、とされているが、動かない
    • 具体的には、ManagementConsoleでは製品起動時のパラメータ入力画面で項目が表示されない、次に遷移もしない
    • CLIから製品起動するとできるらしい

まとめ的な所感

  • 製品テンプレートのメンテナンスをやり続けられるのかという課題は別途あり

    • ServiceCatalogおじさんができあがるかもしれない
  • AWS環境を自治できる組織には個別のアカウントを作成して、Organizationsで大枠制御しつつ、標準化されたCloudFormationテンプレートを提供するというガバナンスの方がフィットしそう

続きを読む

AWS上でMongoDBを動かす

MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたまとめサイトの抜粋です。
AWS上でMongoDBを動かす

AWSであれば、MongoDB環境を容易に構築できる

AWS MarketPlaceには、MongoDB環境を構築するために必要なミドルウェアがプリインストールされたOSイメージが多数あります。
※MongoDBの開発元である 10gen (現MongoDB Inc.)もMongoDB入りイメージを無償提供中

基本的に、それらのイメージをもとにAWSのインスタンスを立ち上げればMongoDB環境ができあがります。英文ですが、下記に具体的な構築手順があります。
http://www.mongodb.org/display/DOCS/AWS+Marketplace

AWSの複数ゾーンとレプリカを組み合わせればDRも容易

MongoDBは、マスタ/スレープ方式のレプリケーションに対応しています。

世界中のデータセンターから選択できる、AWSのさまざまなリージョンやアベイラビリティゾーンを複数選択してMongoDBのレプリカ機能を使用すれば、DR (Disaster Recovery)対応も可能です。

AWSは12のリージョンに、合計で33のアベイラビリティゾーンで運用されています (2016年5月現在)
https://aws.amazon.com/jp/about-aws/global-infrastructure/
AWSのリージョンは、最低でも2つのAZ(アベイラビリティゾーン)をもっていて、それぞれのAZはお互いに地理的・電源的・ネットワーク的に分離されつつも、AZ間は高速専用線で接続されています。

一方のゾーンにMongoDBおよびMongoDBのArbiterインスタンスを立ち上げ、もう一方のゾーンにMongoDBインスタンスを立ち上げれば、片方のゾーンで地震等の災害があっても、データが残り、そのままMongoDBは機能し続けます。

シャードとレプリカを組み合わせたMongoDBクラスタ構成

MongoDBでは、基本的に、シャードを増やすことにより水平スケールさせ、レプリカにより可用性を実現します。各シャードをレプリカセットにすることにより、高い可用性を実現しながら、水平スケールさせた大規模なデータベースを構成することができます。

開発段階では、1 つのレプリカセットから始めることもできますし、本稼働中に 3 つのレプリカセットに移行することもできます。下記URLに、AWS上でMongoDB環境を構築するアーキテクチャ例が示されています。
http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/architecture.html
・図1: レプリケーション係数 3 の MongoDB リファレンスデプロイ
・図2: 3つのレプリカセット2方向シャーディングを使用するAWSのMongoDBクラスター

MongoDBをAWS上で動くようにするまでの手順

AWSにて、MongoDBを動くようにするまでの手順は、概略、下記の通り:

・EC2インスタンスおよびEBSボリュームを用意

・Amazon VPC をセットアップ

*Amazon VPC 内のプライベートサブネットとパブリックサブネット、NAT インスタンス、
セキュリティ グループ、IAM ロールなど、MongoDB のデプロイ中に必要な様々な
ネットワークリソースを作成

・Amazon EBS をセットアップして MongoDB を保存。

・MongoDB 設定をカスタマイズするオプションを指定した後、MongoDBを起動。

MongoDB のバージョン番号 (2.6 または 3.0)、レプリカセットの数 (1 または 3)、シャード数
(0、1、2、または 3)、インスタンスあたりのマイクロシャード数を選択することができます。

※より詳細は、下記を参照ください。
[AWS上の MongoDB] http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/deployment.html

続きを読む

AWSのEC2でマイクラの鯖建てした時のメモ

先駆者の方々のおかげで無事できましたとさ。
というわけで自分用のメモ。

参考したところ

AWSでminecraftサーバーを立てたお話
Minecraft サーバーを Amazon EC2 上に構築
Amazon EC2にMinecraftサーバーを構築する方法

自分の作業環境

・mac OSX capitan(ターミナルから接続するため)
・windows10(ゲーム本体がこっちに入っている)
・お菓子(モチベ維持のため)

windowsだけでもawsに接続して設定できるけどもなんかインストールだとかがめんどくさかったのでmac選びました。
結果的に、両方起動させてることになっちゃったけど、私は特に無問題。

使っているサービス

AWSのEC2
一年間の無料枠があるので今回はそれを利用。
スクリーンショット 2017-03-24 16.30.28.png
を使っています。無料枠が確かマイクロなのでこれ
3人でプレイしてて1時間か2時間に一回落ちるかな?って感じ。
でもネザー入ったときは落ちなかった。ちょっと落ちる原因探し中。
インスタンスは停止、再起動するとデータが消えるうんぬん出るんですけど、EBSに保存されてる感じだから気にしなくてイイノカナー
多分大丈夫、確認したらデータ保存されてるし…?

流れ

詳しい作り方は上の参考にしたものをご参照ください。
私は一から作った方法とりましたが簡単な方法もあるみたい。
流れ的には
AWS登録

EC2で無料枠を選ぶ

インスタンス生成

設定する。ちょっと多い

キーペア作ってダウンロード

作成したインスタンスにターミナルから接続

awsの文字が出たらマイクラマルチ用クライアントとか落とす

設定ちょっと触ってマイクラマルチのクライアント?を起動する

っていう感じ。めちゃ端折ってる

ターミナルから接続する時は、ダウンロードしたキーペアでssh通して接続。ssh接続するためのキーペアて感じだっけ

キーペアの場所(自分はdownload)に移動→chmodで400でキーペアの名前叩いて→ログイン
みたいな。ログイン後マイクラするためにはマイクラ公式に書いてある

java -Xmx1024M -Xms1024M -jar minecraft_server.1.11.2.jar nogui

を入れたら立ち上がります。すごーい

おわり

ゲームを終えたらインスタンスを停止させよう!じゃなきゃなんか怖いぞ!
1時間ごとに課金のようなのでずっとつけっぱなしだと怖い。大変なことになった人もいるみたいだし。
今確か6時間ほど遊んでるけど、請求ダッシュボードみたら$0.62だった。

いろいろ条件下で無料枠の範囲超えちゃったりするみたいなのでちゃんと説明を読んで楽しくゲームしよっ!

ぶっちゃけ自分のパソコンを鯖にするより簡単だった。

AWS興味あったけどどうやって使うか悩んでたから、こうやって使ってみて試すのもありだなって思ったり。

続きを読む

AWSの各サービスを雑に紹介する

えー、投稿しておいて何ですが、本稿本当に雑ですので、ご利用にあたってはあくまで自己責任ということで、よろしくお願いします。

コンピューティング

  • Elastic Compute Cloud (EC2)
    仮想専用サーバ、従量課金制 ≫公式

  • EC2 Container Registry (ECR)
    DockerHubみたいなやつ ≫英語公式 / Google翻訳 ≫Developers.IO

  • EC2 Container Service (ECS)
    Dockerオーケストレーション(デプロイ、起動停止制御) ≫公式 ≫@IT

  • Lightsail
    仮想専用サーバ、定額制 ≫公式

  • AWS Batch
    ECS対応バッチジョブスケジューラ ≫公式 ≫公式 ≫Developers.IO

  • Elastic Beanstalk
    プログラム実行環境 (Java, PHP, .NET, Node.js, Python, Ruby)、EC2を使用 ≫公式 ≫YouTube

  • AWS Lambda
    プログラム実行環境 (Node.js, Java, C#, Python)、サーバレス ≫公式

  • Auto Scaling
    EC2対応オートスケール制御 ≫公式

  • Elastic Load Balancing
    負荷分散、BIG-IPとかその手のヤツのクラウド版 ≫公式 ≫@IT

ストレージ

  • Amazon Simple Storage Service (S3)
    オブジェクトストレージ。ファイルサーバとしても一応使える ≫公式

  • Amazon Elastic Block Store (EBS)
    ブロックデバイス ≫CodeZine

  • Elastic File System (EFS)
    ファイルサーバ ≫公式

  • Glacier
    バックアップストレージ ≫公式

  • Snowball
    HDDをFedExで送るオフラインデータ転送

  • Storage Gateway
    バックアップデバイスはお客様各自のオンプレミスにてご用意下さい、AWSは対向するインターフェースを提供します、というもの ≫CodeZine ≫Developers.IO

データベース

ネットワーキング & コンテンツ配信

移行

  • Application Discovery Service
    オンプレミスサーバの構成管理情報を収集する ≫公式

  • Database Migration Service (DMS)
    RDBをオンプレミスからAWSへ乗り換えるときに使う支援ツール

  • Server Migration Service (SMS)
    サーバをオンプレミスからAWSへ乗り換えるときに使う支援ツール

開発者用ツール

  • CodeCommit
    GitHubみたいなやつ

  • CodeBuild
    従量課金制ビルド

  • CodeDeploy
    コードデプロイ

  • CodePipeline
    Continuous Integration (CI) オーケストレーション。ビルド→デプロイの自動実行フロー定義。

  • AWS X-Ray
    分散アプリケーションのトレース ≫Serverworks

管理ツール

セキュリティ、アイデンティティ、コンプライアンス

  • AWS Identity and Access Management (IAM)
    AWSの認証、権限管理単位 ≫Developers.IO

  • Inspector
    脆弱性検出 ≫公式

  • Certificate Manager
    X.509証明書の管理 ≫公式

  • AWS Cloud Hardware Security Module (HSM)
    秘密鍵の保管(暗号、署名) ≫公式

  • AWS Directory Service
    Active Directory ≫Developers.IO

  • AWS Web Application Firewall (WAF)
    ファイアーウォール ≫公式

  • AWS Shield
    DDoS対策 ≫公式

分析

人工知能

IoT

ゲーム開発

モバイルサービス

  • Mobile Hub
    AWSのいろんなmBaaS系サービスを統合的に使えるコンソール画面 ≫Qiita

  • Cognito
    ソーシャル認証+データ同期。FacebookログインとかTwitterログインとか ≫Cookpad

  • AWS Device Farm
    テスト環境。Android, iOSの実機にリモートアクセスしてテストができる ≫公式

  • Mobile Analytics
    アプリの使用データの測定、追跡、分析 ≫公式 ≫Developers.IO

  • Pinpoint
    プッシュ ≫Qiita

アプリケーションサービス

  • Step Functions
    フローチャートみたいなビジュアルワークフローを画面上に描いて分散アプリケーションを構築する、というもの ≫公式

  • Amazon Simple Workflow (SWF)
    旧世代サービス。現在はStep Functionsを推奨 ≫公式

  • API Gateway
    HTTP API化 ≫公式

  • Elastic Transcoder
    動画、音声のフォーマット変換。つんでれんこaaSみたいなヤツ ≫Serverworks

メッセージング

  • Amazon Simple Queue Service (SQS)
    メッセージキュー ≫公式

  • Amazon Simple Notification Service (SNS)
    プッシュ ≫公式

  • Amazon Simple Email Service (SES)
    E-mail配信。メルマガとか ≫公式

ビジネスの生産性

デスクトップとアプリケーションのストリーミング

  • Amazon WorkSpaces
    仮想デスクトップ ≫impress

  • Amazon WorkSpaces Application Manager (WAM)
    Amazon WorkSpaces端末にアプリを配信するツール ≫serverworks

  • AppStream 2.0
    Citrix XenAppみたいなやつ ≫Developers.IO

参考文献

AWS ドキュメント
https://aws.amazon.com/jp/documentation/

AWS re:Invent 2016 発表サービスを三行でまとめる
http://qiita.com/szk3/items/a642c62ef56eadd4a12c

続きを読む