AWS EC2にMongoDBインストールとレプリケーション設定

MongoDBインストールとレプリケーション設定について、簡易的な抜粋メモとして書いています。
詳細に関しては、記事の最後の参考サイトを確認するようにしてください。

◆ 今日やること

  • MongoDBをEC2にインストール
  • レプリケーションの設定と確認
    • 今回せっていするレプリケーションの形式は、以下の図の通り、「Primary with Secondary Members」です。

mongorepl.png
引用元:Replication — MongoDB Manual 3.4

◆ バージョン

  • MongoDB 3.2
  • Linux 4.4.30-32.54.amzn1.x86_64 #1 SMP Thu Nov 10 15:52:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

◆ 実装編

> EC2へのインストール

sudo yum update -y
sudo vim /etc/yum.repos.d/mongodb-org-3.2.repo

[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc
sudo yum install -y mongodb-org
sudo service mongod start

sudo chkconfig mongod on

> 設定周り

  • WoredTigerストレージエンジンの主な設定

    • cacheSizeGB: システムメモリの6、7割
    • blockCompressor:デフォルトはsnappy(中間です)
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
       cacheSizeGB: 1
       journalCompressor: snappy
    collectionConfig:
       blockCompressor: snappy

> EBSボリュームをAttach

  • EBSボリュームにmongoのデータを溜めるようにする。

Amazon EBS ボリュームを使用できるようにする – Amazon Elastic Compute Cloudに従って、EBSボリュームをアタッチする

  • パーミッションを変更するのを忘れないように。
sudo chown -R mongod:mongod /data
  • /etc/mongod.conf
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data

> レプリケーションの設定

MongoDBではマスターのことをプライマリ,スレーブのことをセカンダリと呼びます。
MongoDBのレプリケーションの最小構成は,3つのノードが必要です。

  • ネットワークインターフェイスの設定で、レプリケーションを組むサーバのIPを記述しておくこと

レプリケーション設定前には、お互いに通信できることを確認しないといけません
Troubleshoot Replica Sets — MongoDB Manual 3.4

mongodb が listen するIPアドレスはデフォルトでは 127.0.0.1 に設定されており、ローカルからのみアクセスを許可するようになっています
mongod.conf の bind_ip に設定されたIPアドレスで listen するのでこれを変更することで外部からの接続を許可します
ここに 0.0.0.0 を設定すると全てのIPアドレスからの接続を許可します

/etc/mongod.conf
# network interfaces
net:
  port: 27017
  bindIp: [127.0.0.1,10.1.52.111,10.1.51.227,10.1.51.68]


  • レプリケーション名を決める
  • Oplogのサイジングと設定サイズを決める
/etc/mongod.conf
replication:
   oplogSizeMB: 500
   replSetName: testRepl

第4回 MongoDBのレプリケーションを構築してみよう:MongoDBでゆるふわDB体験|gihyo.jp … 技術評論社

OplogはCapped Collectionなので,作成時以外にサイズ変更することができません。 デフォルトのOplogのサイズは「1GBまたは,ディスクの空き領域の5%」
Staleを避けるために,Oplogのサイジングは非常に重要となります。
Oplogのサイズは,mongodの初回起動時にoplogSizeオプションで変更可能です。
Oplogの適切なサイズを見積もる方法のひとつに,本番を想定した書き込みテストを実施し,作成されたOplogのサイズを取得する方法があります。
1時間程度,本番想定と同程度の書き込みテストを行った後,以下のコマンドでレプリケーションの最新情報を取得します。

> db.getReplicationInfo()

1時間で作成されたOplogのサイズがわかれば,Oplogのサイジングの目安となります。
少なくとも8時間のセカンダリのダウンタイムに耐えられるようにしておくことが推奨されています。

  • レプリケーションの設定

どれかのサーバに入って、以下のコマンドを実行

config = {
  _id : "testRepl",
  members : [
    { _id : 0, host : "10.1.51.227:27017" },
    { _id : 1, host : "10.1.51.68:27017" },
    { _id : 2, host : "10.1.52.111:27017"} ] }

rs.initiate(config)
  • スレーブの読み取り専用動作設定

そのままだと、スレーブが読み取り専用としてアクセスできないので以下の設定を行っておく。

スレーブノードで、以下のコマンドを実行

 db.getMongo().setSlaveOk()
  • レプリケーションステータスの確認
testRepl:PRIMARY> rs.status();
{
    "set" : "connobaRepl",
    "date" : ISODate("2017-01-12T07:03:05.556Z"),
    "myState" : 1,
    "term" : NumberLong(6),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "members" : [
        {
            "_id" : 0,
            "name" : "10.1.51.227:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 100310,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "electionTime" : Timestamp(1484104344, 1),
            "electionDate" : ISODate("2017-01-11T03:12:24Z"),
            "configVersion" : 3,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "10.1.51.68:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 100245,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:04.017Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:04.020Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        },
        {
            "_id" : 2,
            "name" : "10.1.52.47:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 99751,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:05.025Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:05.022Z"),
            "pingMs" : NumberLong(2),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        }
    ],
    "ok" : 1
}

> mongoログインの時の警告メッセージを消す方法

[ec2-user@ip-10-1-52-47 ~]$ mongo
MongoDB shell version: 3.2.11
connecting to: test
Server has startup warnings:
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
testRepl:SECONDARY>

◆ 参考サイト

続きを読む

OpsWorks Instancesで起動したEC2から作成したカスタムAMIをOpsWorks Instancesで利用する際の注意点

1. はじめに


  • OpsWorks Instances で起動した EC2 をイメージ(AMI)化して、それを OpsWorks Instances のカスタムAMIとして利用する際の注意点。
  • EC2は、”Amazon Linux 2016.09″, “Amazon Linux instance Chef 12 stack”, “Amazon EBS-backed” で作成している。
  • 下記の作法の通りに作成していないカスタムAMIを利用して OpsWorks Instances で EC2 を起動すると、Status が “running_setup” 中のままとなり、作成が完了しない。

2. OpsWorks Instances で起動した EC2 から カスタムAMI を作成する

(参考:本家ドキュメント → ”To create a custom AMI from an AWS OpsWorks instance”)


  • AMI を作成する EC2 を起動した OpwsWorks Layers の “Auto healing enabled” を “No” へ変更する

  • AMI を作成する EC2 へ SSH ログインして、次のコマンドを実行する

$ sudo /etc/init.d/monit stop

$ sudo /etc/init.d/opsworks-agent stop

$ sudo rm -rf /etc/aws/opsworks/
$ sudo rm -rf /opt/aws/opsworks/
$ sudo rm -rf /var/log/aws/opsworks/
$ sudo rm -rf /var/lib/aws/opsworks/
$ sudo rm -rf /var/lib/cloud/
$ sudo rm -rf /etc/chef
$ sudo rm -rf /var/chef
$ sudo rm -rf /opt/chef
$ sudo rm -f /etc/monit.d/opsworks-agent.monitrc
$ sudo rm -f /etc/monit/conf.d/opsworks-agent.monitrc

$ sudo rpm -e opsworks-agent-ruby
$ sudo rpm -e chef
  • OpsWorks のコンパネから、AMI を作成する EC2 インスタンスを停止(Actions:stop)する

    Status が stopped となったことを確認

  • イメージ(AMI)を作成する

3. OpsWorks Instance でカスタムAMI から EC2 を起動する CloudFormation の例


"Resources": {
    "OpsWorksStack": {
        "Type": "AWS::OpsWorks::Stack",
        "Properties": {
            "Name": "example",
            "ConfigurationManager": {
                "Name": "Chef",
                "Version": "12"
            },
            "VpcId": "vpc-********",
            "DefaultSubnetId": "subnet-********",
            "DefaultInstanceProfileArn": "arn:aws:iam::************:instance-profile/**********",
            "ServiceRoleArn": "arn:aws:iam::************:role/**********",
            "DefaultOs": "Custom",
            "DefaultRootDeviceType": "ebs",
            "DefaultSshKeyName": "aws-tonishy",
            "HostnameTheme": "Layer_Dependent",
            "UseOpsworksSecurityGroups": "false"
        }
    },
    "OpsWorksLayer": {
        "Type": "AWS::OpsWorks::Layer",
        "Properties": {
            "Type": "custom",
            "Name": "example",
            "Shortname": "example",
            "StackId": {
                "Ref": "OpsWorksStack"
            },
            "EnableAutoHealing": "true",
            "AutoAssignPublicIps": "true",
            "AutoAssignElasticIps": "false",
            "CustomSecurityGroupIds": [
                "sg-********"
            ],
            "CustomInstanceProfileArn": "arn:aws:iam::************:instance-profile/**********"
        }
    },
    "OpsWorksInstance": {
        "Type": "AWS::OpsWorks::Instance",
        "Properties": {
            "AmiId": "ami-********",
            "Os": "Custom",
            "StackId": {
                "Ref": "OpsWorksStack"
            },
            "LayerIds": [
                {
                    "Ref": "OpsWorksLayer"
                }
            ],
            "InstanceType": "t2.micro"
        }
    }
}

※ AWS::OpsWorks::Instance の AmiId に、カスタムAMIの id を設定する

続きを読む

AWSでLinuxしか触ったことない人が、AWSでWindowsServerを利用するときに知っておかないといけないことまとめ

はじめに

  • AWSでLinuxばかりやってたんですがWindowsServerを触らないといけない機会が凄く増えててビビってます。
  • WindowsServer利用するときも、まぁ大体Linuxと一緒なんでしょ!?と思ってたら火傷しますのでしっかりと抑えておきましょう。
  • 他にもWindowsだと気をつけないといけない!なんてことがあればご指摘ください。

ライセンスはどうなってるのか?押さえておこう。

  • WindowsServerのライセンス

    • EC2の費用に含まれている。
    • OSにCALの料金が含まれているのでCALの購入は不要
  • WindowsServerのライセンス持ち込みについて
  • 以下の既存のマイクロソフトライセンスはAWS上に持ち込み可能。
    • 1サーバ1ライセンス、1プロセッサライセンス4コアまでの1インスタンスに対応
    • Exchange Server
    • SharePoint Server
    • SQLServer Enterpriseなど
  • Officeのライセンスについて
    • ハードウェア占有インスタンス、占有ホストで利用可能
  • その他ライセンスについて不明な点があればAWS と Microsoft に関するよくある質問 – ライセンシングを読んでおく。

サポート&トラブル

どのイメージを利用すればよいのか?

  • EC2の画面から「パブリックイメージ」「所有者:Amazonイメージ」「search:Windows_Server-2012-R2_RTM-」で検索するとたくさん出てくる。
  • 「search:Windows_Server-2012-R2_RTM-Japanese」で検索するとLocaleがJapaneseで設定済のものもあるのでこれを選んでおくと楽ですね。

EC2 Management Console 2016-10-07 14-33-05.png

  • 最新のパッチが当たったAMIを公開してくれており、10月5日現在だと6月以前のAMIは無くなっていました。どうしても元のAMIをとっておきたい場合はプライベートイメージとして保管しておく必要がありそう。(が、、、そういうケースはあるんだろうか)

AWS は、Microsoft の火曜パッチ(毎月第 2 火曜日)の 5 営業日以内に、更新されパッチが全面的に適用された Windows AMI を提供します。

  • 新しいAMIがリリースされた時や以前のAMIが非公開になった時に通知をAmazonSNSで受けることができるようです。Subscriptionの設定で以下のARNを設定すればよいようです。
arn:aws:sns:us-east-1:801119661308:ec2-windows-ami-update
arn:aws:sns:us-east-1:801119661308:ec2-windows-ami-private

インストールメディアは使えるのか?

  • 使える。
  • マネジメントコンソールでスナップショットを開いて以下の条件で検索
    • パブリックスナップショットを選択
    • 所有者:Amazonイメージ
    • 説明:Windows 2012 R2
  • あとはボリュームの作成してWindowsServerにAttachすれば利用できる

どうやってWindowsServerに接続するのか?

  • RDPで接続する。パスワードはManagementConsoleからパスワードの取得を行うことで取得できる。
  • インスタンス起動後すぐに取得できるわけではなく、「あとN分後に取得できます。」のメッセージが出てくる。
  • これは後述するEC2Configがパスワードの初期化を行っているから。

拡張ネットワーキングは有効にしておこう

インスタンスの自動復旧設定をしておこう

  • Windowsに限った話ではないが、AutoRecoveryは設定しておく。やっといて損しない。
  • AutoRecoveryはシステムステータスチェックが失敗した場合(ネットワークとか電源とかホスト側の問題でこちらではどうしようもない問題)に自動で復旧してくれる機能で無料で利用できる。
  • 利用条件
    • インスタンスタイプはC3、C4、M3、M4、R3、T2、および X1
    • VPC内で動作しEBS-Backedとなっていること
    • 占有インスタンスではないこと
  • 参考

AutoHealingの設定

  • これもWindowsに限った話ではないが1台構成でもAutoHealingの設定をしておくことを検討しておく。
  • AutoHealingとはAutoScalingGroupの起動数をmin:N,max:Nにしておくことで常にN台起動する状態を作ることを言います。
  • 詳しくは別記事にしますが簡単に触れておく。
  • AutoScalingGroupを利用する場合
    • トリガーはStateがRunningじゃなくなったとき。
    • PrivateIPが変わってしまうので上位にELBを挟むなどの考慮が必要。
    • CloudWatch→SNS→Lambda→AutoScalingGroupをUnHealthyにすることで細かい障害の検知などが可能になる。
  • OptsWorksを利用する場合
    • トリガーはOptsWorksAgentがOptsWorksに通信できなくなったとき。
    • PrivateIPを変更することなくAutoHealingが動かせるが、AutoScalingGroupのような細かい制御は無理

EC2Configの役割について知っておく

  • EC2ConfigはWindows版Cloud-initみたいなものです。EC2Configがやってくれる役割については認識しておこう。
  • AWSが提供するWindowsServerイメージを利用すると既にインストール済になっています。
    C:\Program Files\Amazon\Ec2ConfigService¥Ec2ConfigServiceSettings.exe
  • サービスも自動で起動しているので特に何かしておく必要はありません。
  • こんなことをやってくれます。
* 初回起動時のタスクには以下のものがあります。
    * 管理者アカウントに、ランダムに生成した暗号化パスワードを設定する
    * リモートデスクトップに使用されるホスト証明書を生成しインストールする
    * オペレーティングシステムパーティションを動的に拡張して、未使用の領域が含まれるようにします。
    * 指定されたユーザーデータ(および、インストールされていれば Cloud-Init)を実行します。
* EC2Config は、インスタンスが起動するたびに次のタスクを実行します。
    * 16 進数表記のプライベート IP アドレスと一致するようにコンピュータのホスト名を変更する(このタスクはデフォルトでは無効になっているので、このタスクを有効にしてインスタンスの起動時に実行する必要があります)。
    * key management server (KMS)を構成し、Windows アクティベーションのステータスを確認して、必要に応じて Windows のアクティベーションを行う。
    * すべての Amazon EBS ボリュームおよびインスタンスストアボリュームをマウントし、ボリューム名をドライブ文字にマップします。
    * イベントログエントリをコンソールに出力し、トラブルシューティングに役立てる(このタスクはデフォルトでは無効になっているので、このタスクを有効にしてインスタンスの起動時に実行する必要があります)。
    * コンソールに Windows の準備が完了した旨の通知を出力する
    * 複数の NIC がアタッチされているとき、プライマリネットワークアダプタにカスタムルートを追加して、IP アドレス 169.254.169.250、169.254.169.251、および 169.254.169.254 を有効にする。これらのアドレスは Windows ライセンス認証が使用し、またユーザーがインスタンスのメタデータにアクセスする際にも使用します。
* EC2Config は、ユーザーがログインするたびに以下のタスクを実行します。
    * デスクトップ背景に壁紙情報を表示する
  • 他の用途については以降で説明します。

AMIの作成方法は2パターンあることを知っておく

  1. マネージメントコンソールやCLIからAMIの作成を行う
  2. EC2ConfigからAMIを作成する
  • 所謂システムバックアップを取得する場合は1を利用すれば良い。
  • EC2ConfigからAMIを作成する理由は、展開用のイメージを作るときです。実行するとセキュリティ識別子(SID)、コンピュータ名、イベントログなど固有の情報が削除され、インスタンスが停止します。停止した状態でコンソールやCLIからイメージを作成すればインスタンス固有の情報が排除されたAMIの作成ができます。
  • 作成の方法についてはSysprep を使って標準の Amazon マシンイメージを作成します。を参考にしてください。

  • 参考

AWS Diagnostics for Microsoft Windows Serverは入れとけ

  • このツールを使うとWindowsServer上から様々な情報を収集し、AWSテクニカルサポートに問い合わせるときに情報を集めるのが非常に楽になるということと、既知の問題に引っかかっていないかを検査してくれるらしいです。素晴らしい。
  • いざサポートに問い合わせる必要が出た時にも慌てないようにダウンロードしておいておき、動くことも確認しておくこと!
  • 集められる情報
IP アドレスとルートテーブルなどのネットワーク情報
ドメインとコンピュータ名
ライセンスの状態、Key Management Server (KMS) の構成などのアクティベーション設定
現在の時刻と時間帯などの時間設定
インスタンス上にインストールされたドライバ
セキュリティグループのルールに沿った Windows ファイアウォールの設定
インストールされた更新
Windows が 1 週間以内にクラッシュした場合のミニダンプファイル
  • 分析ルール
アクティベーションステータスと KMS 設定のチェック
メタデータと KMS アクセスに対する適切なルートテーブルエントリのチェック
セキュリティグループルールと Windows ファイアウォールルールの比較
PV ドライバのバージョン確認(Redhat または Citrix)
RealTimesUniversal レジストリキーが設定されているかの確認
複数の NIC を使用している場合のデフォルトゲートウェイ設定
ミニダンプファイルのコードのバグチェック
  • 動かすのは非常に簡単で、こちらからダウンロードして、exeをクリックするだけです。credentialの入力を求められるますが、予めEC2にReadonlyのRoleを設定しておき利用すると良いでしょう。

10.0.0.117  2016-10-07 15-08-35.png

  • 「OpenReport」をクリックするとテキストでレポートが出力されます。Windowsがライセンスされてるか。SecurityGroupの設定とFirewallの設定が合致しているかなどです。
  • 収集されたデータは実行ディレクトリと同じディレクトリに出力されていました。
  • 10.0.0.117  2016-10-07 15-14-48.png

  • 参考

監視はどうやる?(Cloudwatch)

  • プロセス、パフォーマンス

    • パフォーマンスカウンタで取得したデータをCloudWatchにメトリクスとして登録することが出来ます。パフォーマンスカウンタを利用すると大体のデータは取れるのでpowershellでcloudwatchにput-metricsする必要は無いです。
    • ただし、すべてカスタムメトリクスになるのでガンガン登録するとそれだけコストがかかります。監視するものはカスタムメトリクスとして登録、後々みれれば良いものはパフォーマンスカウンタとして取得しておくよう選別しておこう。
  • ログ
    • イベントログ含め、任意のログデータをEC2Configを利用することでCloudWatchLogsに取り込むことが出来ます。
  • 監視

    • CloudWatchのカスタムメトリクス、CloudWatchLogsに取り込めればこちらのものですね。Cloudwatchの標準機能を使って通知まで実現出来そうですね。
  • パフォーマンスカウンタのデータや、ログをCloudWatch,CloudWatchLogsに取り込む手順は以下の通りです。

共通の設定(CloudWatch Logs の認証情報、リージョン、ロググループ、ログストリームを設定)

  • EC2インスタンスにCloudwatch,CloudwatchLogsにアクセスするためのロールを付与します。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "cloudwatch:*",
        "logs:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
  • EC2Configの設定を開きます。

C:¥Program Files¥Amazon¥Ec2ConfigService¥Ec2ConfigServiceSettings.exe

  • [Cloudwatch Logs] – [Enable CloudWatchLogs Integration]にチェックを入れます。

10.0.0.117  2016-10-07 15-27-36.png

  • 下記の設定ファイル内のリージョンを変更しておきます。今回は東京(ap-northeast-1)にしてあります。
  • ロールの設定が行われている場合は、AccessKey,SecretKeyは無視されるので空のままで良いです。

C:\Program Files\Amazon\Ec2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json

AWS.EC2.Windows.CloudWatch.json
            {
                "Id": "CloudWatchLogs",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "LogGroup": "Default-Log-Group",
                    "LogStream": "{instance_id}"
                }
            },
            {
                "Id": "CloudWatch",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": 
                {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "NameSpace": "Windows/Default"
                }
            }
  • ここまでで事前の設定はおしまいです。

イベントログをCloudWatchLogsでみえるようにしてみます

  • このあたりがイベントログの設定になります。
AWS.EC2.Windows.CloudWatch.json
{
    "EngineConfiguration": {
        "PollInterval": "00:00:15",
        "Components": [
            {
                "Id": "ApplicationEventLog",
                "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "LogName": "Application",
                    "Levels": "1"
                }
            },
            {
                "Id": "SystemEventLog",
                "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "LogName": "System",
                    "Levels": "7"
                }
            },
            {
                "Id": "SecurityEventLog",
                "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                "LogName": "Security",
                "Levels": "7"
                }
            },
  • イベントログをCloudWatchLogsに出力するには、IdをFlows加えてあげれば良いです。今回はSecurityEventLogを出力するように追記してみました。
AWS.EC2.Windows.CloudWatch.json
        "Flows": {
            "Flows": 
            [
                "(ApplicationEventLog,SecurityEventLog,SystemEventLog),CloudWatchLogs"
            ]
        }
  • EC2Configを再起動して少し待つとCloudWatchLogsにログが出力されました。

CloudWatch Management Console 2016-10-07 16-52-29.png

パフォーマンスカウンタのデータをCloudWatchカスタムメトリクスに表示してみよう

  • この設定はAvailable MBytesをパフォーマンスカウンタから抽出してCloudWatchのカスタムメトリクスに名前空間Windows/Defaultの中にMemoryというメトリクスを追加しています。
AWS.EC2.Windows.CloudWatch.抜粋.json
            {
                "Id": "PerformanceCounter",
                "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "CategoryName": "Memory",
                    "CounterName": "Available MBytes",
                    "InstanceName": "",
                    "MetricName": "Memory",
                    "Unit": "Megabytes",
                    "DimensionName": "",
                    "DimensionValue": ""
                }
            },
・・・
            {
                "Id": "CloudWatch",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": 
                {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "NameSpace": "Windows/Default"
                }
            }
・・・
        "Flows": {
            "Flows": 
            [
                "(ApplicationEventLog,SecurityEventLog,SystemEventLog),CloudWatchLogs",
                "(PerformanceCounter),CloudWatch"
            ]
        }
  • これも設定後再起動すると、このようにメモリがカスタムメトリクスに表示できます。

CloudWatch Management Console 2016-10-07 17-00-16.png

  • いやー便利ですね。

CloudWatchのメトリクスデータの保管

  • CloudWatchのメトリクスは2週間経つと自動で消えてしまいます。
  • 2週間より大きい期間のデータの保管が必要な場合は、定期的にAPIを使ってローカルに落としておくなどの工夫が必要。

CloudWatchLogsの保管期間を決めておこう

  • CloudWatchLogsも勿論お金が掛かります。
  • CloudWatchLogsのログの保管期間はデフォルトで無制限なので変更しておきましょう。
  • 参考

RunCommandの活用検討及び利用準備はしておく。

  • RunCommandはWindows,Linux共にEC2にログインせずともコマンドが実行できる機能
  • Windowsの場合はEc2Configが入っているのでOS側にエージェントのインストールは不要。
  • Javaのアプリケーションを運用していた場合、事前に準備さえしておけばJavaのThreadDumpもOSにログインしないで実行することができるわけです。
デフォルトで利用できるRunCommand
AWS-JoinDirectoryServiceDomain to join an AWS Directory
AWS-RunPowerShellScript to run PowerShell commands or scripts
AWS-UpdateEC2Config to update the EC2Config service
AWS-ConfigureWindowsUpdate to configure Windows Update settings
AWS-InstallApplication to install, repair, or uninstall software using an MSI package
AWS-InstallPowerShellModule to install PowerShell modules
AWS-ConfigureCloudWatch to configure Amazon CloudWatch Logs to monitor applications and systems
AWS-ListWindowsInventory to collect information about an EC2 instance running in Windows.
AWS-FindWindowsUpdates to scan an instance and determines which updates are missing.
AWS-InstallMissingWindowsUpdates to install missing updates on your EC2 instance.
AWS-InstallSpecificWindowsUpdates to install one or more specific updates.
  • 事前に利用できないかは検討しておこう。利用しない場合でも動かせるように準備はしておいた方が良いと思う。
  • RunCommandが利用できる条件は「RunCommandの前提条件」を参照。

おわりに

  • どうでしょうか。結構色々ありますね。何かあったときに慌てないようにNATやロールの設定は予め考えておきたいですね。

続きを読む

AWS EC2インスタンスにSSHで接続できなくなったとき

ec2_image.png

設定ミスでログインできなくなったインスタンスを復旧することになった時の作業記録です。
Unix系OSにおける一般的な起動ディスクの障害対応手順を、単にAWSならこうやる、というだけの話で恐縮ですが、何かのお役に立てれば幸いです。

症状と効能

こんな人によく効きます。

  • iptablesやTCP Wrapperの設定をミスったとき
  • キーペアを紛失したとき
  • OSの設定をミスって起動しなくなったとき

何かしらの原因で、ログインできなくなったり、インスタンスが起動しなくなったりしたときにファイルシステムにアクセスすれば糸口が掴める、といった時に使えます。

オンプレミス環境やホスティングサービスなら、ブートディスクを変更してからの復旧や、コンソールログインからの設定修正など、何かしらの手段が提供されていますが、AWSだとこのような方法になるかと思います。

なお、利用しているインスタンスはAmazon Linux、rootボリュームはElastic Block Store(EBS)ですが、LinuxのDistributionならば、ほぼ共通の手順になると思われます。

注意点

システムステータスチェックやインスタンスステータスチェックがNGのケースは、この方法では対処できない可能性が高いと思われますのであしからず。その場合は、こちらを参考に対処してください。
参考:『Amazon EC2ユーザガイド』インスタンスのステータスチェック

対応手順サマリ

  1. 障害が発生した「インスタンスA」を停止
  2. 「インスタンスA」のEBSボリュームをデタッチ
  3. 正常起動できる「インスタンスB」に対象ボリュームをアタッチ
  4. 「インスタンスB」を開始&ログイン
  5. 対象ボリュームをマウント
  6. 原因調査と対処
  7. 対象ボリュームをアンマウント&デタッチ
  8. 「インスタンスA」に対象ボリュームをアタッチ&起動

以下に順を追って内容を記します。

障害が発生したインスタンスの停止

まずはマネジメントコンソールで作業します。
対象インスタンスの「ルートデバイス」名を確認してから、インスタンスを停止します。
confirm_rootdevice.png
ルートデバイス名は、「/dev/xvda」もしくは「/dev/sda1」となっているかと思います。今回使用しているAmazon Linuxでは、「/dev/xvda」となっていました。
AWS CLIコマンドを使って調べることも可能です。この辺の詳細は『Amazon EC2ユーザガイド』Linux インスタンスでのデバイスの名前付けを参照してください。

stop_instance.png
対象デバイスを右クリックして「停止」を選択します。

EBSボリュームをデタッチ

インスタンスが停止されたことを確認してから対象のEBSボリュームをデタッチします。
detach_ebs.png
対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。

正常なインスタンスにボリュームをアタッチ

ボリュームの状態が「available」になったら、別の正常なインスタンスにアタッチします。
atach_ebs.png


対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。
atach2_ebs.png
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。今回は「/dev/sdf」を指定。


atach3_ebs.png
ボリュームの状態が「in-use」になれば、アタッチ完了です。

正常なインスタンスを開始~ログイン

通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。ちなみに、今回使用したインスタンスはCentOS6.7です。
centos_login.png

対象ボリュームをマウント

ログイン後、先ほどアタッチしたボリューム「/dev/sdf」をマウントします。
このときのデバイス名は、/dev/sdfか/dev/xvdfなど、異なる名前でアタッチされる可能性があります。
参考:『Amazon EC2 ユーザガイド』Amazon EBSボリュームを使用できるようにする

現在のマウントボリュームを確認
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  666M  6.7G   9% /
tmpfs           498M     0  498M   0% /dev/shm

ここで、ルートデバイスが/dev/xv*となっていたら、先ほどアタッチしたボリュームの名前も/dev/xv*となっています。
stop_instance.png

ブロックデバイスを確認
$ ls -la /dev |grep sd
$ ls -la /dev |grep xv
lrwxrwxrwx.  1 root root           5 Oct  8 14:47 root -> xvda1
brw-rw----.  1 root disk    202,   0 Oct  8 14:47 xvda
brw-rw----.  1 root disk    202,   1 Oct  8 14:47 xvda1
brw-rw----.  1 root disk    202,  80 Oct  8 14:47 xvdf
brw-rw----.  1 root disk    202,  81 Oct  8 14:47 xvdf1
マウントするパーティションを確認
$ lsblk -i
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
`-xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
`-xvdf1 202:81   0   8G  0 part

マウントするディレクトリを作成して、マウント実行。

マウント先のディレクトリを作成
$ sudo mkdir /mnt/vol_ebs
マウント実行
$ sudo mount /dev/xvdf1 /mnt/vol_ebs
$ mount
/dev/xvda1 on / type ext4 (rw)
...<snip>...
/dev/xvdf1 on /mnt/vol_ebs type ext4 (rw)

正常にマウントされました(マウントポイントは/)

原因調査と対処

システムログや、作業履歴などから原因を調査し、設定を修正するなどして復旧します。
今回はTCP Wrapperの設定ミスで、SSHログインができなくなっていたため、hosts.allowおよびhosts.denyを適切に修正しました(修正内容は割愛)。

アンマウント~対象ボリュームをデタッチ

念のためアンマウントして、対象インスタンスを停止してから、EBSボリュームをデタッチします。

アンマウント
$ sudo umount /mnt/vol_ebs
マウントされていないことを確認
$ mount
/dev/xvda1 on / type ext4 (rw)
...<snip>...
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

マネジメントコンソールで停止
stop_instance.png
対象デバイスを右クリックして「停止」を選択します。


インスタンスの状態が「stopped」に変わったことを確認して、EBSボリュームをデタッチします。
detach_ebs.png
対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。

対象ボリュームをアタッチ~インスタンス開始

デタッチしたボリュームは元のインスタンスにルートデバイスとしてアタッチします。
ボリュームの状態が「available」であることを確認の上、アタッチします。
atach_ebs.png
対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。


atach2_ebs.png
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。元の状態に戻すため「/dev/xvda」を指定してアタッチします。


atach3_ebs.png
ボリュームの状態が「in-use」になれば、アタッチ完了です。


通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。無事ログインできれば成功です。
login_success.png

以上です。

参考にした記事

手順をまとめるにあたり、こちらの記事を参考にさせて頂きました。ありがとうございます。
AWSサーバーにログインできなくなった場合の対処

続きを読む

「AWS is 何」を3行でまとめてみるよ

すべてのAWSのサービス3行以下でまとめました。

AWSが色々ありすぎてわからん! 3行以下で誰かまとめて!!という思いで、AWSを3行で書いてるところがなかったので自分で作りました。

掲載した金額は最小使用時のもの。無料枠や大量購入割引(Volume discount)でかなり変わるので、参考程度に。

以下からのカッコよすぎな見出しは AWSクラウド製品のページ からのそのままの引用です。「 広範かつ奥深いコアクラウドインフラストラクチャサービス」って僕が言ってるわけじゃない!

広範かつ奥深いコアクラウドインフラストラクチャサービス

なんのこっちゃ。

よーするに「基本サービスですよ」ってことらしい。基本サービス多すぎだろ・・・。
い。

コンピューティング

AWS is 何 いくら?
Amazon EC2 仮想サーバー。Linuxそのまま触れる。なんでも出来るぞ 0.01ドル/1時間〜
Amazon EC2 Container Registry Docker イメージの配布。EC2はもちろん自鯖・自PCからもdockerイメージ取得できる 月 $0.140 /GB
Amazon EC2 Container Service 保存したDocker コンテナを実行および管理。上と合わせてEC2スケールするときにdockerから起動できて楽。
AWS Elastic Beanstalk herokuのパクリと思ったが微妙に違うっぽい。
Ruby, PHP, node.js, Java, Python, .Net, Docker, Go が動くPaaS。
内部的にはEC2 + ELB ぽいね。
gitからのデプロイも(一応)可能みたい
無料
AWS Lambda ZaiperみたいにAWSのイベントで起動してコード実行。APIGatewayと連携してWebサービスにもなる 月100万リクエストまで無料
Auto Scaling EC2インスタンスを自動で増やしたり減らしたり。
負荷追従で増減や、lambdaでトリガーとか、色々設定可能。
Elastic Load Balancing 勝手に増える単機能なロードバランサ。キャッシュとかはない。キャッシュはCDNでやる。Auto Scalingと組み合わせる多分 0.027ドル/時間 + 0.008ドル/GB

ストレージとコンテンツ配信

検索しない系のデータ保存・配信

AWS is 何 いくら?
Amazon S3 ファイル突っ込むとURLが貰えてアクセスできる 0.033ドル/GB/月
Amazon CloudFront CDN。配信が超早い。S3の10倍くらい速度出る。高い 0.14ドル/1GB
Amazon EBS EC2用のハードディスク。SSDナシのEC2インスタンスには必須。1個のEBSは、一台のEC2にしか使えない
一台のEC2が複数EBS持つのはアリ。マジハードディスク
0.12ドル/GB/月
Amazon Elastic File System EC2用の共有フォルダ。複数台のEC2から使える
LANで繋がるHDD(NAS)と同じかんじ
0.3ドル/GB/月
Amazon Glacier 大容量を安く保存。S3の7割引。引き出すのに3-5時間。多分テープメディア(LTOテープ)
単価見ると120TBを2年保存したら300万…
AWS Import/Export Snowball テラ/ペタバイト級の高速回線でも時間かかる大容量データの高速転送。ディスク(物理)を郵送しようぜ大作戦。
専用HD(50TB.10GBイーサ/SFP+光端子/SFP+銅端子を有す)をAmazonが宅配/返送して巨大データの送信/受信が出来る発想…。
アイデアじゃなくて実現してんのがすげぇよ。なお東京はまだ未開設(2016年内開始予定)。
AWS Storage Gateway TCP/IP経由でSCSI規格ごしでS3にアクセス。古い機器が社内にある人用途かなぁ。全部AWSで作るとかなら不要っぽい気がする

データベース

検索する系のデータ。

AWS is 何 いくら?
Amazon RDS スケールするRDB。
MySQLから始まり、Amazon Aurora、MySQL、PostgresSQL、Oracle、SQL Server および MariaDB が起動できる。
お値段がやや分かりづらい。必要に応じてスケーリングできるDBは魅力的。
AWS Database Migration Service 自社鯖からRDSに継続的にデータのレプリケーションをすることで、RDSに乗り換えたい人がすぐ乗り換えできるようにするサービス。
Amazon DynamoDB KVS とか NoSQL な データベース。一意キー付きでJSON格納と思えばおk…だと思う。Amazon独自開発で早くて安い感じ。後から追加したインデックスは無効だとか、柔軟性に難点がありそう。
あと料金体系が謎。試算によると安そうだ
25GBまで無料。
1テーブルで0.716ドル?
Amazon ElastiCache Memcached/Redisを提供 0.026ドル/時間
Amazon Redshift 安くて速いデータウェアハウス。
SQL構文で解析できて、解析用なのでビッグデータも速い(数秒で解析)。でも1件取得も数秒かかる。インデックス等のSQL機能がなし。解析のためSQLはコンパイルして保存するので、コンパイル時間のオーバーヘッドがあるようだ。
postgresSQLを改造して作ったようだ?

ネットワーク

ネットワークエンジニアの人が設定する内容。

AWS is 何 いくら?
Amazon VPC AWSサーバ群を仮想のサブネット(LAN)にできる。ファイアーウォール、DHCP、仮想IP、NAT等の設定。
Webサーバはインターネットに公開だけど、DBは非公開(Webサーバからのみアクセス)等の設定が可能。
オンプレデータセンターとAWSデータセンターまで仮想のLAN(VPN)も可能。安全なネットワーク構築には重要ですね。
無料
AWS Direct Connect AWSのデータセンター(の接続ポイント事業者)から自宅/自社までの専用線(物理)を引くことができる。IP-VPNも可。高速回線&転送課金の割引。
Elastic Load Balancing nginxみたいな。高スケールなロードバランス。
自動で負荷追従して増えたり減ったりする設定も可能。
Amazon Route 53 DNSサーバ
サービス当初はお名前.comのドメインナビとかでも良いのかも
サービス落ちたら別の表示(e.g. twitterクジラとか)にdns転送するのとかあって良い

豊富なプラットフォームサービスによりクラウドでの成功を促進

分析計と企業向け、それとモバイル、IoT

分析 

分析系だけかと思ったら、日本語全文検索や機械学習なんかも含んでいる

AWS is 何 いくら?
Amazon EMR Hadoop専用のEC2インスタンスで、S3から入力しS3に出力する
ノード数十台でMapReduceを起動するのが楽。EC2自前だとHadoop関連で色々入れなきゃいけないし。
AWS Data Pipeline EC2からデイリーでデータを取って、S3に配置して、ウィークリーでEMR起動するとかの、データ駆動型ワークフローに対するオーケストレーションサービス
いわゆる「バッチ」を定義できる
Amazon Elasticsearch Service 日本語(もちろん英語も)の全文検索できる。
スケールするのがAWSのすごいところで、全文検索エンジン「Elasticsearch」は元々elastic社のオープンソース。
Amazon Kinesis 1時間あたり数テラのデータを、リアルタイムに分析。
回転寿司のすし皿のicタグで分析(スシローが実際やってる)…をjsonで常に投げ、ec2上でcsvに加工し、s3にアップロードし、Redshiftに格納させ分析…
24時間でデータ消えるらしい。大量に受付する仕組みが安価ってことなのかな
Amazon Machine Learning いわゆる「教師あり機械学習」。そのうち「二項分類」、「多項分類」、「回帰分析」ができる。
はやりのニューラルネットワークとかディープラーニングは対象外っぽい。
Amazon QuickSight セルフサービスBI(非技術者:経理部門や経営層 などが、自身でデータ分析する)ためのツール。
S3やRedshift上などにある生ログをGUI上で選べば、簡単に表・グラフが出来る
Amazon Redshift データウェアハウス。上に書いたので省略。

エンタープライズアプリケーション

GmailとDropBoxのパクリ。あとWindows機をリモートデスクトップで使える

AWS is 何 いくら?
Amazon WorkSpaces クラウド上でwindowsが使える。操作はリモートデスクトップ(vncとか)と同じ。内部的にはEC2のwindowsとかなのかな?? 月額25ドル〜
Amazon WorkMail Gmail,Googleカレンダーのパクリ。
他のAWSとの連携とかできたり、あとGmail(1ユーザー月額500円)より安い
1ユーザーあたり月額4ドル
Amazon WorkDocs 元Zocalo。DropBoxやGoogleDocsのパクリ。
プレビュー機能はあるけど、Googleと違いスプレッドシート編集とかはない。
S3に保存してるぽい
1ユーザーあたり200GBまで月額6ドル

モバイルサービス

スマホアプリ向けの他にも、シンプルなWebページを作るのにも使えそう。

AWS is 何 いくら?
AWS Mobile Hub いわゆるmBaaS。
機能としては、ソーシャルログイン(Cognito)、プッシュ通知(Amazon SNS)、サイト&コンテンツデリバリー(S3 + CloudFront)、ユーザーデータ保存(S3)、分析(Amazon Mobile Analytics)、REST-API(AWS Lambda Function)
この定義に従って実際に動くサンプルアプリ(Android-Java, iOS-Objective-C)のダウンロードまで可能。すごい
Amazon API Gateway REST-APIを作れる。
Lambdaにアクセスする窓口(一般的な使い方)
古い自社サービス(非AWS)へのプロキシラッパーにしたり、無限にS3バケットを作るだけのAPIも作れるみたい
公開するREST-APIじゃないなら、Cognito+Lambdaのほうがいいのかも
Amazon Cognito FB, Twitter, Amazon, Google, とかとかでログインできる。
あと同期ストアっていうデータストアもある
月に5万ユーザー未満なら無料
AWS Device Farm Cloud につながった実機の Android、Fire OS、 iOS でアプリのテストができる。
画面転送ではなく
最初の 250 分まで無料。0.17ドル/分
Amazon Mobile Analytics アプリに組み込んでユーザー数・離脱率・独自イベントetcを集計し分析。
kinesisとの違いがわからないなー。
AWS Mobile SDK Lambda、S3、DynamoDB、Mobile Analytics、Machine Learning、Elastic Load balancing、Auto Scaling、CognitoにアクセスするためのSDK
iOS, Android/FireOS, Xamarin, Unity, そしてjavascript(プレビュー版)で動くようだ
SDK使用自体は無料
Amazon SNS Simple Notification Service.
普通のプッシュ通知サービス
最初の100万件は無料

IoT

AWS is 何 いくら?
AWS IoT IoT用のSDK、MQTTSによるセキュア通信、オフラインデバイスのデータ同期などを引き受ける…。
AWS Mobile Hubと類似していて、色々IoT用に既存サービスを便利に使えるという感じだと思うのですが詳しくないのでよくわかりません。
ボタンがかわいい。

運用効率性および開発者の生産性の向上

開発者用ツール

AWS is 何 いくら?
AWS CodeCommit IAMロールで管理されるgit。残念なことにgithubのようなWeb UI は無く、ただのgitホスティングのみ 5人まで無料。以降は1人あたり月額1ドル
AWS CodeDeploy GitHubやS3バケットへのpushをトリガーとして、EC2にデプロイする 無料
AWS CodePipeline CIツール。Jenkinsのように、gitへのpushをキーに自動でビルドタスクを起動し、自動テストを起動し、レポートを送り…とやる。
CodeDeployとの違いは、CodeDeployはこれの単純版(デプロイのみ)ってことかな?
パイプライン1つにつき、月額1ドル

管理ツール

AWS is 何 いくら?
Amazon CloudWatch サーバの生き死にや使用料金や使用量をモニタ&取得&グラフ。
SNSと組み合わせてやばそうなときに通知
AWS CloudFormation EC2やRDS,S3ほか様々のAWSサービスをバッチ的に構築する。
Chefやpuppet, Ansibleがサーバ内を構築するように、AWSを一括構築できる。
EC2上ならyum install等々も書ける
無料
AWS CloudTrail AWSの操作を記録している。
EC2を消した犯人を探すときなどに使う。
7日間しか見れない
ほぼ無料(S3保存料金がかかる)
AWS Config 設定の変更履歴がログで見える。
Macのタイムマシーンや、Winの復元ポイントみたいな感じ(データは保存されてないけど)
AWS OpsWorks Chef を使った操作の自動化。レシピが食わせられる。ELBやAuto Scalingとは違う手段でのスケーリング。
AWS Service Catalog CloudFormationの保存・バージョン管理。
IAMの権限がなくても一括起動(EC2の権限なくてもServiceCatalog権限のみで起動できる)
Trusted Advisor コスト、パフォーマンス、セキュリティ、可用性と冗長性…の4観点から、自動テストの結果風に赤黄青で通知。 無料

セキュリティと ID

AWS is 何 いくら?
AWS Identity and Access Management (IAM) アクセス権の管理。
まともにAWS使うときは必ず設定する。開発者・BOT・Jenkins・アプリ…とたくさんIAM作りまくるのが主流なのかな?
無料
AWS Directory Service Microsoft Active Directory(AD)がAWSでホストできる。 0.08ドル/時間〜
Amazon Inspector EC2のセキュリティ・ホールを見つけ出す自動分析ツール
AWS CloudHSM キー管理に対する米国政府標準規格に準拠した、ハードウェアベースキーストレージ。
HSMで検索すると動作原理が出てくる。鍵の保存及び暗号化・署名と復号化・署名検証の機能だけを持つサーバアプリとして動作するみたい
初回5千ドル+月2千ドル(2.82ドル/時間)
AWS Key Management Service キー管理。CloudHSMとの違いは複数リージョンでの使用ができることや、AWSのSDK経由で暗号・復号のリクエスト投げれることなど(HSMだとSafenetAPI経由)。
値段もこっちのが圧倒的に安いし、もしかしてCloudHSM要らないのでは。。。
追記:米国ではコンプライアンスや契約上の問題で、HSM必須なことがあるようだ
1ドル/鍵1個/月
AWS WAF AWSへの外部からのアクセスに対するファイアーウォール。
構成的にはEC2やELBよりも前に立つ。CloudFrontの場合は協調動作CloudFrontのアドオンとしてWAFが入る。
6ドル/月

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

Software As A Service のようなものから、「アプリを使うときに必要になるアプリ」まで

AWS is 何 いくら?
Amazon API Gateway 前述。REST-APIを作れる
Amazon AppStream G-cluster のようなクラウドゲームや、シンクライアントシステムの提供。
内部的にはアプリはEC2上のWin2008 R2で起動し、操作を受付け画面をストリーミング配信。要はリモートデスクトップですね。
GoogleEathで試した人の話だと、超グリグリサクサク動くらしい…
1.20ドル/時間+別途EC2料金
Amazon CloudSearch 検索サービス。
Elasticsearch Serviceとの違いは、CloudSearchのほうが楽ですぐ使える。Elasticsearchのほうがカスタマイズ性は高い。
内部エンジンは同じようだ。
Amazon Elastic Transcoder AWS上で動画エンコーディングが行える
Amazon SES Eメール送受信サーバ。メルマガ一括送信など。受信は実際には転送なので、WorkMail等に投げたり、S3に保管したり、Lambdaに投げて解析させたり
Amazon SNS プッシュ通知サービス。前述済み
Amazon SQS メッセージキューサービス。時間のかかる処理を行うサービスが一旦キューで受けて…と使う。
kinesisと似るが、データ入れるだけのkinesisと、データ+命令のSQS、か
Dropbox, NETFLIX, nextdoor等が活用。Dropboxはファイル格納するとサムネ画像/Officeプレビューや検索インデックス作るのにSQSを利用
Amazon SWF SQSのタスク制御するコーディネーターとしてふるまう。
処理状態が取れ同期できるSQSを作ることで、非同期並列にSQSを作り、動画サムネ作成・低解像度化・違法動画検出…等々を並列に行い、全部OKなら動画サイト上で公開、などの処理が作れる。

AWS Game Dev

ゲーム開発者のための Amazon に紹介がある。

AWS is 何 いくら?
Amazon Lumberyard フルソース提供の無料3Dゲームエンジン。UnityやUnrealEngineみたいなもの。
ソース提供だがオープンソースではない(改変はOKだが再配布禁止)。
PC、Xbox One、PlayStation 4 そしてiOSおよびAndroidのサポート。MacとLinux対応も予定。
無料。レベニューシェア等もなし
Amazon GameLift FPSやMOBA等のマルチプレイヤーのバックエンドをEC2上で。
独自のサーバ作ったり、Unityから利用したりはまだ難しいようだ。”現在Lumberyard しかサポートしてない”と明記してある。
中身はwinサーバで、.exe形式のサーバ本体とinstall.bat、依存ファイル(dll)を含んでいる必要があるみたい
1000人につき1.5ドル/日

その他気になったので調べたこと

  • 「AWS間の通信は?」:

    • 同一リージョンだと900Mbpsくらいのようだ。物理LANと同等以上。
    • 別リージョンだと、CLOUD CONNECTで地球の裏側(シドニー〜サンパウロ)20-40Mbpsくらい
  • 「S3/Glacierは安いのか?」:
    • 2年使用時で120TB保存すると、S3で6万ドル=720万円。Glacier でも 2万ドル=240万円くらい
    • 3.5インチHDDが3TBで8500円くらいだったから、120TB構築すると34万円。まともに使えるように構築する手間賃は考えてない。
    • 超高い。安く見えるのは月割だから。でもオンラインストレージ&障害耐性はアリっちゃアリなのか…?
  • 「EC2とBeansTalkとLambdaはどれ使えばいいの?」:
    • EC2 : サーバの詳細設定できる&したいとき
    • Beanstalk : 単にWebサービスを作りたいとき(中身はEC2)
    • EC2 Container Service : Dockerで作ったサーバを大量コピー
    • Lambda : 次の3つのとき ※ かつコピペ or zip化が可能な程度に小さいコード。
      • 他のAWSサービスの変更通知(S3にファイル置いた時とか)をきっかけとして動かす
      • とにかく安く簡単にコードが動けばいいや
      • Amazon API Gatewayと組み合わせてEC2レスでWebアプリ作る(S3やDynamoDBと連携)
  • 「xxxってサービスはEC2のなかでも立てれるのでは?」:
    • たとえば、ec2内でmysql立てれるから、Amazon RDSは不要では?

      • 費用が倍くらい違う
      • 初期設定も不要だし
      • あと自動でスケールしてくれるし
  • SimpleDBは?:
    • なんか一覧ページに無かったので書いてません。DynamoDB使えってことで、売り止めなのかなー。

雑感

基本的にはEC2とかS3がコア機能で、 「内部的にはEC2だけど、こっち使ったほうが安いよ」とか、「EC2+S3+SNSを一括管理できるよ」とか、そういうのがごっちゃにフラットに並べられてるので理解しづらいですね。

似たようなサービスもたくさんあるし。こういう早見表をAmazonさんのほうで用意してほしいですね。Data PipelineとSQSとKinesisとか、最初違いがよくわからなかった。

値段は個々のサービスのほうが安いのと、恐らく安定はしているだろうから、個別サービスがあるものは使ったほうがよさそうですね API等を理解するコストもデカイけど
自前でEC2上でmemcachedを動かすよりは、ElastiCacheを使うべし、とかね。

謝辞

今回の記事を作成させていただくにあたり、 Developpers.IO/クラスメソッド株式会社さまの記事をとくにたくさん参照させていただきました。良質なAWSについての日本語記事を書いていただき、ありがとうございます。

まとめ

AWS種類多いですねー。主観でガンガン書いたので、間違いがあったらコメントください。

続きを読む

AWS認定ソリューションアーキテクト アソシエイト勉強法について

今月、AWS認定ソリューションアーキテクト-アソシエイトに合格したので、記念に記事にします。
よかったら参考にしてみてください。

1.書籍での勉強

以下の書籍を一通り読みました。
Amazon Web Services パターン別構築・運用ガイド NRIネットコム株式会社
Amazon Web Services実践入門 (WEB+DB PRESS plus) 舘岡 守

ただ読むだけではなく、実機を動かしながら勉強することをオススメします。

2.模擬問題

AWS公式の模擬問題を受けました。50%でした。まだまだ勉強が足らないようです…orz

3.AWS Black Belt Online Seminar

AWSからわかりやすいスライドが公開されていたので、読みました。
特に、以下のものは呼んでおいたほうが良いと思います。
EC2、VPC、AutoScaling、Elastic Load Balancing、Amazon Route 53、
Amazon S3、Amazon EBS、Amazon RDS、Amazon SQS、AWS Identity and Access Management(IAM)
Amazon CloudWatch

4.よくある質問

「3.AWS Black Belt Online Seminar」で読んだサービスについては、よくある質問も熟読しました。
ものすごく参考になるので、必見です。

5.qiitaで「aws 資格」で検索する

多くの方が参考になる記事を書かれています。色々読んでモチベーションを保ちつつ勉強してください。

6.クラスメゾットさんのブログを読む

クラスメゾットさんのブログで、AWSのサービスについて分かりやすく説明されていたので、
毎日チェックしていました。

http://dev.classmethod.jp/

7.受験

本番です。無事合格しました。ただ、模擬問題より少し難易度が高く感じました。

さいごに

本投稿は以上です、参考にしてみてください。

続きを読む