aws-sam-localだって!?これは試さざるを得ない!

2017-08-11にaws-sam-localのベータ版がリリースされました。
単に「早速試したで!」と言う記事を書いても良かったのですが、少し趣向を変えてサーバレス界隈の開発環境のこれまでの推移を語った上で、aws-sam-localの使ってみた感想もお話しようかと思います。

サーバレス開発環境の今昔

サーバレス自体がかなり最近になって生まれた風潮なので昔とか言うのも問題はあるかと思いますが、とにかくサーバレスなるものの開発環境について私にわかる範囲でお話しようと思います。誤りや不正確な点については編集リクエストやコメントを頂けると幸いです。

なお、サーバレスという言葉は一般的な名詞ですが、私がAWS上でしかサーバレスに触れていないため、AzureやGCPなどには触れず、もっぱらLambdaの話になってしまうことをあらかじめご了承ください。

Lambdaのデプロイは辛かった

Lambdaの基本的なデプロイ方法はZIPで固めてアップロードです。
直接ZIPをLambdaに送るか、あらかじめS3に置いておいてLambdaにはそのURLを教えるかといった選択肢はありましたが、手動でZIPに固めてAWSに送るという手順は不可避でした。なんかもうすでに辛い。

さらに言うとLambdaに送りつけられるのはLambdaで実行するコードだけ。性質上Lambdaは単体で使われることはほとんどなく、他のサービスと連携することがほとんどなのにその辺は自分で管理するしかありませんでした。辛い。

CloudFormationで管理することは可能でしたが、CloudFormationテンプレートを書くのがかなりダルいことと、CloudFormationの更新とZIPのアップロードを別途行う必要があって手順が煩雑化しやすいため、「もうええわ」と手動管理してることが多かったと思われます。

また、ローカル環境で実行するには一工夫必要でした。

颯爽登場!Serverlessフレームワーク

そんな時に颯爽と現れたのがServerlessフレームワークでした。
ServerlessフレームワークにおいてはLambdaファンクション及び関連するリソースを独自のyamlファイルで管理します。結局は一度CloudFormationテンプレートに変換されるのですが、CloudFormationテンプレートよりも単純な形式で記述できたのが流行った一因かと思います。また、sls deployコマンドでLambdaのコードのアップロードおCloudFormationスタックの更新を一括で行ってくれたため、デプロイの手順は従来よりもはるかに簡略化されたかと思われます。

Lambdaテストしづらい問題

デプロイに関する問題はServerlessフレームワークや、ほぼ同時期に現れたSAMによって改善されましたが、開発プロセスにおいて大きな課題がありました。

テストし辛ぇ…

上記の通りLambdaは性質上他のサービスと連携することが多いため、その辺をローカル環境でどうテストするかに多くの開発者が頭を抱えました。対策として

  1. モッククラスを作って、実際のサービスのような振る舞いをさせる
  2. プロダクションとは別のリージョンに環境を再現して、そこで実行する

といった方法がありましたが、それぞれ

  1. モッククラスの実装がすこぶるダルい 下手したらロジック本体より時間かかる
  2. クラウドにデプロイしないとテストできないため、時間がかかる

といったデメリットがありました。

LocalStackとaws-sam-local

サーバレス開発者の嘆きを聞いたAtlassianがローカル環境でAWSのサービスのエンドポイントを再現するなんとも素敵なツールを作り上げました。それがLocalStackです。
再現されているサービスの数が物足りなく感じられたり、サードパーティ製であることに一抹の不安を覚えたりする人もいるかと思いますが、これ以上を求めるなら自分で作るぐらいしかないのが現状かと思います。

そしてaws-sam-local。こちらはLocalStackと少し趣が異なります。LocalStackが連携するサービスのエンドポイントを再現して提供するのに対して、aws-sam-localは実行環境の提供という意味合いが強いです。そして重要なことはAWSの公式がサポートしているということです。公式がサポートしているということです。大事なことなので(ry
「実行するのはローカルでNode.jsなりPythonなりで動かせばええやん」と思いがちですが、ランタイムのバージョンなどを本番環境と確実に揃えられるのは大きな利点です。
まだベータ版が出たばっかなので今後に期待といったところでしょう

aws-sam-local触ってみた

それでは実際に触ってみましょう。
ちなみに当方環境は

  • OS: macOS Sierra 10.12.6
  • Docker for Mac: 17.06.0-ce-mac19

です。

事前準備とインストール

公式のInstallationの項目を読み進めますが、事前にDockerを使えるようにしておく必要があります。

Macだったら普通にDocker For Macをインストールしておけば問題ありません。
一方Windowsだと

スクリーンショット 2017-08-16 14.48.18.png

まさかのDocker Toolbox推奨。 Docker For Windowsェ…
そしてaws-sam-localのインストールですが、私は-gオプション排斥論者なのでローカルインストールします

npm install aws-sam-local

実装

今回はこちらを参考にAPIゲートウェイから呼び出すLambdaを実装します。
ほぼ丸パクリですが一部アレンジしてますのでソースものっけます。

template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: SAM Local test
Resources:
  HelloWorld:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs6.10
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /resource/{resourceId}
            Method: put

ランタイムをnodejs6.10に変更してます。
新しく作る場合にわざわざ古いバージョンを使う必要もありませんので。

余談ですが、WebStormのCloudFormation用のプラグインは今の所SAMには対応してないのか、Type: AWS::Serverless::Functionのところにめっちゃ赤線を引かれます。

index.js
/**
 * Created by yuhomiki on 2017/08/16.
 */

"use strict";

const os = require("os");
console.log("Loading function");


const handler = (event, context, callback) => {
  return callback(null, {
    statusCode: 200,
    headers: { "x-custom-header" : "my custom header value" },
    body: "Hello " + event.body + os.EOL
  });
};

exports.handler = handler;

完全に書き方の趣味の問題です。
内容は参考ページのものと全く同じです。

package.json
{
  "name": "sam_test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "invoke-local": "sam local invoke HelloWorld -e event.json",
    "validate": "sam validate",
    "api-local": "sam local start-api"
  },
  "author": "Mic-U",
  "license": "MIT",
  "dependencies": {
    "aws-sam-local": "^0.1.0"
  }
}

aws-sam-localをローカルインストールしているので、package.jsonのscriptsに追記しています。

実行

それでは実行してみましょう

上記のpackage.jsonに記載した

  • invoke-local
  • validate
  • api-local

を実行していきます。

invoke-local

Lambdaファンクションをローカル環境で実行します。
Lambdaファンクションに渡すevent変数はワンライナーで定義することも可能ですが、あらかじめJSONファイルを作っといた方が取り回しがいいです。

json.event.json
{
  "body": "MIC"
}

実行結果はこんな感じ

スクリーンショット 2017-08-16 15.25.42.png

まず最初にdocker pullしてランタイムに応じたDockerイメージをダウンロードします。
その後はコンテナ内でLambdaファンクションを実行し、最後にcallbackに与えた引数を出力といった流れです。
ログの形式がすごくLambdaですね。あとタイムゾーンもUTCになっていますね。
メモリの使用量をローカルで確認できるのは嬉しいですね。

-dオプションをつけることでデバッグもできるようです。
公式のgithubにはご丁寧にVSCodeでデバッグしてる様子がgifで上げられてます。

validate

テンプレートファイルのチェックをします。
デフォルトではカレントディレクトリのtemplate.yamlファイルをチェックしますが、-tオプションで変更することが可能です。

失敗するとこんな感じに怒られます。

スクリーンショット 2017-08-16 15.33.47.png

成功した時は「Valid!」とだけ言ってきます。きっと必要以上に他人に関わりたくないタイプなのでしょう。

api-local

sam local start-apiコマンドはローカル環境にAPIサーバを立ち上げます。
ホットリロード機能がついてるので、立ち上げっぱなしでもソースを修正したら自動で反映されます。いい感じですね。

スクリーンショット 2017-08-16 15.40.58.png

立ち上がるとこんなメッセージが出るので、あとはCURLなりPostManなりで煮るなり焼くなり好きにしましょう。

CURLの結果はこんな感じ
スクリーンショット 2017-08-16 15.51.39.png

所感

Lambdaのローカル実行環境を公式が用意したことに大きな意義があるかと思います。
Dockerさえあればすぐに使えることと、SAMテンプレートを書かざるをえないのでInfrastructure as Codeが自然と根付いていくのも個人的には好感を持てます。

ただし、まだベータ版なこともあって機能的にもの足りない部分があるのも事実です。
具体的にはやはりDynamoDBとかもテンプレートから読み取ってDockerコンテナで用意してくれたらなーと思います。LocalStackやDynamoDB Localでできないこともないでしょうが、DynamoDB Localに関してはテンプレートからテーブル作ったりするの多分無理なのでマイグレーション用のコードを書くことになりますし、LocalStackに関しては実はあまり真面目に使ったことないのでわかりませんが環境構築に一手間かかりそう。ていうかできれば一つのツールで完結させたい。

SAMしかりaws-sam-localしかり、AWS側としてもより開発がしやすくなるような環境づくりをしていくような姿勢を見せているので、今後のアップデートに期待したいところですね。

続きを読む

クラウドの力を借りて無限収入システムを構築する(はずだった)

目的

 ビットコイン等の仮想通貨の採掘をして不労所得チャリンチャリンというのは夢がありますよね。私もチャレンジしようと思ったのですが、手元の貧相な PC では電気代すらペイできないのは明らかです。
 ではクラウドの力を借りて、GPU でやってみたらどうなのか。スポット価格をうまく使えば、もしかしてクラウド利用料を賄えて夢の無限収入システムを構築できるのではないか、というチャレンジをしてみたので、その記録です。
 なお、実際に稼げるとは思ってなくて、AWS スポットインスタンス使ってみる、GPUインスタンスを使ってみる、ブロックチェーンに触れてみる、など一石三鳥なお勉強をすることが目的です。

概念図

 インスタンス利用料が安いときに仮想通貨をマイニングすれば黒字転嫁するのでは、というアイデアです。
image.png

結果

 すごい赤字になる。スポットインスタンスを活用しても インスタンス利用料の半分まかなえる程度の採掘量にとどまり利益が生まれることはなかった、通貨マイナーの世界はきびしい。
 FPGA 使えれば結果は変わるのかなー。

構築の流れ

採掘環境構築~試しに採掘まで

環境情報

  • 採掘対象

    • Ethereum
  • OS 1
    • Ubuntu Linux 16.04 / 64bit
  • インスタンスタイプ
    • g3.4xlarge or p2.xlarge
  • リージョン
    • us-east-1(インスタンス費用がたぶんいちばん安いので)
  • マイナークライアント
    • Claymore’s Dual GPU Miner 9.7
  • ウォレット
    • coincheck

ウォレットの準備

  • Coincheck にアカウント作成

    • その他、大手のbitFlyer、Zaif 等なんでもよさそうです、手数料や取り扱い通貨が違います
  • 身分証明書を送り取引可能な状態にする
    • 最大2営業日必要との記載ですが、今回は数時間で本人確認が完了しました
  • Ether入金用のアドレスを作成 する

    • アドレス:0x0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X

マイニング用AMIを作成する

Ubuntu インスタンスを作成、Calymore9.7 を導入する。

console
$ wget https://github.com/nanopool/Claymore-Dual-Miner/releases/download/v9.7/Claymore.s.Dual.Ethereum.Decred_Siacoin_Lbry_Pascal.AMD.NVIDIA.GPU.Miner.v9.7.-.LINUX.tar.gz
$ mkdir Calymore9.7
$ tar xvzf Claymore.s.Dual.Ethereum.Decred_Siacoin_Lbry_Pascal.AMD.NVIDIA.GPU.Miner.v9.7.-.LINUX.tar.gz -C ./Calymore9.7/
$ cd Calymore9.7/

不足しているライブラリをインストール

console
sudo apt-get install ocl-icd-opencl-dev
sudo apt-get install libcurl3

nvidiaのドライバをインストール

console
sudo apt-get install -y nvidia-367

以下のshを作成

Claymore9.7/miningStarter.sh
#!/bin/sh

workername1=`hostname`
workername2=`date +"%y%m%d%H%M%S"`

#export GPU_FORCE_64BIT_PTR=0 # must be comment out for amdgpu-pro
export GPU_MAX_HEAP_SIZE=100
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100

export ETH_ADDR=0x0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X0X # Ether入金アドレス
export ETH_WORKER_NAME=$workername1$workername2 # ワーカーの名前=ホスト名+起動日時
export ETH_POOL_HOST=us1.ethermine.org:4444 #AWSリージョンと同じusを指定

cd /home/ubuntu/Claymore9.7/ #SHおいたとこ

./ethdcrminer64 
  -epool $ETH_POOL_HOST 
  -ewal $ETH_ADDR.$ETH_WORKER_NAME 
  -epsw x 
  -mode 0 
  -ftime 10 
  -etha 2 
  -allpools 1 
  -wd 0 
  -eres 4 
  -gser 2

で、sh 起動、なんかうごく。

console
sudo bash miningStarter.sh

image.png

こちらで Ethereum入金アドレス で検索すると、進捗が確認できる。
ethermine.org – The fastest way to mine Ether

ためしに採掘&オンデマンドでの結果

数時間後…
image.png

ちゃんと掘れてるみたいですが、いくらになったんでしょう…

  • AWS利用料(g3.xlarge@us-east-1)

    • $1.14 / H = $27.4 / Day
  • マイニング結果 23
    • 0.002659 ETH/Day (10 MH/s) = $0.8 / Day
  • 収支
    • -98%($-26.56/Day)の赤字

 オンデマンドインスタンス価格では赤字を垂れ流す結果となりました。自動起動設定をしたあと、AMI をとっておきます。

/etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

bash /home/ubuntu/Claymore9.7/miningStarter.sh #SHのありか

exit 0
  • AMI-ID

    • ami-0X0X0X0X

スポットインスタンスで起動まで

 バージニア北部のここ一週間のスポットインスタンスの価格設定履歴より、スポットの最安値とオンデマンド比の割引率を求めました。4

インスタンスタイプ オンデマンド($/H) スポット最安($/H) 割引率
g3.4xlarge 1.14 0.23 80%
g3.4xlarge 2.28 0.4 82%
g3.4xlarge 4.56 1.04 77%
p2.xlarge 0.9 0.1 89%
p2.8xlarge 7.2 1 86%
p2.16xlarge 14.4 2.2 85%

 g3とp2はどちらがマイニングに適しているのか計測しないとわかりませんが、とりあえず「p2.xlarge」でいいかなと感覚で決め、自動入札とAutoScaleの設定をします。この割引率を見る限り、負けが見えていますが。。。

  • 起動設定:MiningLaunchConfig

    • インスタンスタイプ

      • p2.xlarge
    • スポット価格
      • $ 0.1
    • AMI ID
      • ami-0X0X0X0X
  • AutoScalingGroup設定:MiningAutoScaleGroup

    • 起動設定

      • MiningLaunchConfig
    • 希望
      • 3
    • 最小
      • 3
    • 最大
      • 3

 これで、スポットインスタンスが 0.1 以下の場合自動で入札し、その価格帯であれば常時3台 起動する設定ができました。

勝手に起動する!
image.png

勝手に採掘する!
image.png

無限にお金が、、、!!

最終結果

  • AWS利用料(p2.xlarge@us-east-1)

    • $0.098 / H = $2.35 / Day
  • マイニング結果(1台あたり)
    • 0.003244 ETH/Day (12.2 MH/s) = $ 0.97 / Day
  • 収支
    • -59%($-1.38/Day)の赤字

 無限にお金が減っていく!
 残念ながら、スポットインスタンスでも無限の収入は実現できませんでした。もっと値下げしてくれれば黒字転換するんですが、そんなうまい話ないですよね。
 無念!!

参考リンク

イーサリアムを効率良くマイニングできるClaymore’s Dual Minerの使い方・設定 | トレードステーションと株・FX自動売買で暮らす
技術者向け Ethereumの基礎知識 (イーサリアム、エセリウム) – Qiita
【2017年度版】イーサリアム(ETH)でお金を稼ごう! ~マイニング編~ | デジモノ達人
イーサリウムを GPU マイニングしてみる(2017/04/21 時点) – Qiita
GPU関連でよく使うコマンドまとめ – Qiita
ETH-USD電卓:ETH/USD Ethereum Price Calculator | CoinGecko
Mining収支電卓:Ethereum Mining Profitability Calculator
採掘量確認:Balances – ethermine.org – The fastest way to mine Ether

構築時エラー集

ocl-icd-opencl-dev ないとエラー

ethdcrminer64
./ethdcrminer64: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory

libcurl3 ないとエラー

ethdcrminer64
./ethdcrminer64: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory

nvidiaのドライバ ないとエラー

ethdcrminer64
ETH: 1 pool is specified
Main Ethereum pool is asia1.ethermine.org:4444
DCR: 4 pools are specified
Main Decred pool is pasc-eu2.nanopool.org:15555
AMD OpenCL platform not found 
No NVIDIA CUDA GPUs detected.
No AMD OPENCL or NVIDIA CUDA GPUs found, exit

補足


  1. GPU は Windows に最適化されているものが多く、マイナーの世界では Windows を使うのがメジャーみたいです 

  2. 1 ETH = $ 299.96 で計算しています 

  3. 数時間しか稼働させていないので、インスタンスタイプにおける MH/s は正しい平均値が取れていません 

  4. 2017/8 時点 

続きを読む

AWS SystemsManagerを使ってみたメモ

(WIP)まだ修正中なのでどんどん追加していく

AWS SystemsManagerを使用してみた

脆弱性検知、自動パッチ当て、構成管理などなど幅広く使用できるAWSマネージドサービスと聞いて使ってみた。
とりあえずAWSマネジメントコンソールのEC2のサイドバーの上から実施していく。

サマリ

  1. コマンドの実行
  2. ステートマネージャー
  3. 自動化
  4. Patch Compliance
  5. パッチベースライン

コマンドの実行

ここではランコマンドなるものの実行ができるらしい
ただし前準備が色々必要そうなのでまとめてみる…
1. IAMロール作成(EC2インスタンス用、ユーザー用)
まずはEC2インスタンス用から作成
IAMロール作成画面から作成する
  image.png

  image.png

image.png

次に現在サインインしているIAMユーザーに設定されているロールに対して下記ポリシーをアタッチする
– AmazonSSMFullAccess
– AmazonSSMReadOnlyAccess

  1. SSMエージェントのインストール
    インストールコマンドを実行していく(AmazonLinux201703)
mkdir /tmp/ssm
cd /tmp/ssm
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
  1. ドキュメント選択
    適当なドキュメントを選択する
    今回はansibleでyum updateとかしてみようと思ったので、ansibleのplaybookを実行できるドキュメントを使用する
    image.png

playbookを書いていざ実行してみると、、、
ansibleがインストールされていないとのこと(笑)
image.png

なのでansibleをインストールして再度実行してみる、すると、、、
image.png

無事成功!

ステートマネージャー

自動化

Patch Compliance

パッチベースライン

参考

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-setting-up.html?icmpid=docs_ec2_console

続きを読む

AWS上でHoloLensのSharingServiceを動かす

HoloLensで東京⇔大阪間でシェアリングしたい!ってことで、
こちらを参考にしながらAWSに環境を構築してみました。
まずはAWSの設定です。

AWSの設定

VPCの作成

vpc100.png

vpc101.png

項目
名前タグ vpc_HoloLens_Sharing
IPv4 CIDR ブロック 10.0.0.0/16

サブネット作成

vpc102.png

vpc103.png

項目
ネームタグ subnet_HoloLens_Sharing
VPC vpc-xxxxxx vpc_HoloLens_Sharing
AZ ap-northeast-1a
IPv4 CIDR block 10.0.1.0/24

インターネットゲートウェイ作成

vpc104.png

vpc105.png

項目
名前タグ GW_HoloLens_Sharing
  • VPCにアタッチする
    vpc106.png

vpc107.png

vpc108.png

ルートテーブル作成

vpc109.png

  • 編集クリックして別のルートを追加をクリックしてください
    vpc110.png
送信先 ターゲット
0.0.0.0/0 igw-xxxxxxxx
  • サブネットの関連付け
    vpc111.png

vpc112.png

EC2の作成

EC2_100.png

  • Windows Server 2016 Baseを選択
    EC2_101.png

  • インスタンスタイプの選択
    EC2_102.png

EC2_103.png

項目
ネットワーク vpc-xxx vpc_HoloLens_Sharing
サブネット subnet_HoloLens_Sharing
  • ストレージの追加

特に何もすることはありません
EC2_104.png

  • タグの追加
    EC2_105.png

  • セキュリティグループの設定
    EC2_106.png

項目
セキュリティグループ名 SG_HoloLens_Sharing(任意)
説明 SG_HoloLens_Sharing(任意)
カスタムUDP(ルールの追加) 20600-20604(ポート範囲)
  • 作成ボタンクリック
    EC2_107.png

  • キーペアのダウンロード

超重要ファイルです!失くさないように気をつけましょう!
EC2_108.png

Elastic IPの作成

EC2にパブリックIPを設定します。

elip100.png

elip101.png

elip102.png

elip103.png

elip104.png

リモートデスクトップからアクセス

rmt100.png

rmt101.png

rmt102.png

rmt103.png

rmt104.png

rmt105.png

Windowsサーバーでの処理

リモートデスクトップにアクセスした後、
インターネットエクスプローラーを起動して SharingService.exe をダウンロードします
ダウンロード後は適当なフォルダに保存しましょう

※最新のSharingService.exeだとうまく動きませんでした。。。
2016年8月のSharingService.exeをオススメします。

rmt106.png

  • ファイアウォールの設定

コントロールパネルを起動してください
rmt107.png

rmt108.png

Windowsファイアウォールを介したアプリまたは機能を許可をクリック
rmt109.png

別のアプリの許可をクリック
rmt110.png

rmt111.png

パブリックにチェックを入れてください
rmt112.png

サービスを起動して、Sharing Serviceを選択し、右クリックしてプロパティを開きましょう
rmt113.png

これで自動的に起動時にサービスが立ち上がります
rmt114.png

コマンドプロンプトを起動して、SharingService.exeをインストールします
rmt115.png

UnityでSharing StageのServer Addressを設定します

rmt116.png

無事に東京⇔大阪にあるHoloLensとシェアリングできました
ほぼ遅延はありませんでした。シェアリングは夢が広がりますね。
holo100.png

まとめ

EC2でサーバー構築からHoloLensシェアリング実行まで1時間もかからず
実現できました。とても手軽にシェアリングが出来ました。
しかしHoloLensを揃えるだけでもお金が大変ですがw

続きを読む

CloudBerry Explorer for Amazon S3でAmazon S3にアクセスしてみた

S3とCloudBerry ExplorerでEC2 + Samba + Windowsエクスプローラに似た操作感をだす

Amazon S3Amazon EC2 + Sambaを用いて業務でファイルサーバーの設置をすることになった。
windowsのエクスプローラからアクセスしたいとのことでEC2 + Sambaを採用することになったけど、個人的にはS3を利用したかったのでいろいろと調べてみてS3でも似たような操作感でファイルを保存する方法を見つけたので手順を残しておくことにした。

前提

  • AWSのアカウントも持っていること

環境

  • Windows10
  • Chrome

参考サイト

手順

  1. Amazon S3でバケットを作成する
  2. Amazon IAMでユーザー・グループを作成する
  3. CloudBerry Explorerをダウンロードする
  4. CloudBerry ExplorerからS3にアクセスする

おおまかにはこんな感じの手順で進めていきます。

1. Amazon S3でバケットを作成する

①まずはAWSのコンソールにログインをする。

②S3を選択する。

AWSコンソール1.png

③「バケットを作成する」を選択する。

  • バケット名:一意のものにしましょう
  • リージョン:東京
  • 既存のバケットから設定をコピー:とりあえず省略

バケット作成.png

あとは【次】を押していき最後に【バケットを作成】で作成したバケットがリストに追加される。

新規バケット.png

2. Amazon IAMでユーザー・グループを作成する

①AWSサービス一覧からIAMを選択する。

AWSコンソール2.png

②メニューの【グループ】をクリックし、【新しいグループの作成】をクリックする。

  • グループ名:任意
  • ポリシータイプ:とりあえずスルー

IAMグループ作成.png

最後に【グループの作成】をクリックするとメニュー【グループ】に新しく作成したグループが追加される。

IAMグループ作成2.png

③ユーザーをグループに追加する。グループ作成時と同様にメニューの【ユーザー】をクリックし、【ユーザーを追加】をクリックする。

  • ユーザー名:任意
  • 別のユーザーを追加で複数ユーザーを同時に作成できる

IAMユーザー追加.png

  • アクセスの種類:好み
  • パスワード:自動生成が楽でしょう
  • パスワードのリセットの必要性:好み

IAMユーザー追加2.png

アクセス権限の設定はなにもせず【次のステップ:確認】、最後に【ユーザーの作成】をクリックするとユーザーが作成されます。
アクセスキーIDシークレットアクセスキーは.csvでダウンロードしておきましょう。

キー.png

④もう一度メニューの【グループ】をクリックし、先ほど作成したグループをクリックする。

【グループにユーザーを追加】ボタンをクリックする。

ユーザー追加.png

追加したいユーザーにチェックをいれ【ユーザーの追加】をクリックする。

ユーザー追加2.png

ユーザーが追加される。

ユーザー追加3.png

⑤【アクセス許可】のタブをクリックし、【インラインポリシー】をクリックし表示された【ここをクリックしてください】をクリックする。

アクセス許可1.png

【Policy Generator】の【選択】をクリックする。

許可の設定1.png

  • 効果:許可
  • AWSサービス:Amazon S3
  • アクション:すべてのアクション
  • Amazon リソースネーム(ARN):arn:aws:s3:::バケット名

IP制限などを設けたい場合は条件の追加(オプション)をクリック

  • 条件:IpAddress
  • キー:aws:SourceIp
  • 値:許可するIPアドレス

【条件の追加】【ステートメントを追加】をクリックする。
アクセス許可の編集.png

【次のステップ】をクリックしてAWSの操作は完了

3. CloudBerry Explorerをダウンロードする

こちらのリンクからダウンロードする、インストールしましょう。
CloudBerry Lab

無償だと時折「寄付」をねだられるらしいが無償で使えます。

4. CloudBerry ExplorerからS3にアクセスする

①CloudBerry Dxplorerを開きいて、メニュー左の【ファイル(F)】をクリック、【Amazon S3アカウント】をクリックする。

berry1.png

②埋める。

  • 名前表示(N):任意の名前
  • Use Access and Secret keys
    • Access key:AWS IAMでユーザーを追加したときのアクセスキー
    • Seacret key:AWS IAMでユーザーを追加したときのシークレットキー

最後に【OK】をクリックし、【close】をクリックする。

berry2.png

③マイコンピュータを先ほど追加したアカウント名に変更し、ルートの個所に【バケット名】を入力してエンターを叩いてエラーがでなければ終了。

berry3.png

続きを読む

ホワイトペーパー『企業アプリケーションのクラウド化を検討している方必見! AWS 上で Microsoft …

企業アプリケーションの多くが Microsoft Windows Server、Microsoft SQL Server 上で構築されており、従来のオンプレミス環境上に構築された企業 … 続きを読む

AWSのチュートリアル 〜Analyze Big Data with Hadoop編〜

AWSのチュートリアルの日本語メモ

はじめに

最近業務でAWS上に構築したHiveを利用するのですが、より理解を深めたいと思い、今回はAWSのチュートリアルを利用して、Hadoop + Hive環境を1から構築してみました。

チュートリアルの内容

Step1: Set Up Prerequisites for Your Sample Cluster

Sign Up for AWS

以前登録していたため、今回はスキップ

Create an Amazon S3 Bucket

S3とは、データを保存するサービス、詳しい内容はここ
以前に利用したことがあったのでここもスキップ

Create an Amazon EC2 Key Pair

EC2とは、Amazonが提供してくれているWEBサーバ、詳しくはここ
sshでログインするために、key pairを発行する必要がある。
今回はここのサイトを参考に、以前作成したkey-pairを利用。

  • EC2のコンソールページのネットワーク&セキュリティタブのキーペアをクリック
  • 上のキーペアのインポートをクリック
  • key-pairの名前とkey-pair.pubの中身をペーストして登録

Step2: Launch Your Sample Amazon EMR Cluster

Launch the Sample Cluster

EMRのクラスタを作成する。EMRとは、AWS上でHadoopを使用するためのサービス。
詳しくはここを参照

  • EMRのコンソールページに移動
  • クラスターの作成をクリック
  • EC2キーペアの部分で、先ほど登録したkey-pairを指定する
  • クラスターの作成をクリック

Step3: Prepare Your Sample Data and Script

ここでは提供されているサンプルログデータとサンプルhiveコードの説明

Sample Data Overview

サンプルのログデータは、s3://[region].elasticmapreduce.samplesに格納されているらしい。
ただし、[region]には自分が使用しているリージョン名が入る。

Sample Hive Script Overview

Hiveのサンプルコードはs3://[region].elasticmapreduce.samples/cloudfront/code/Hive_CloudFront.qにある。
記録されているコードは以下の通り

Hive_CloudFront.q
-- Summary: This sample shows you how to analyze CloudFront logs stored in S3 using Hive

-- Create table using sample data in S3.  Note: you can replace this S3 path with your own.
CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs (
  DateObject Date,
  Time STRING,
  Location STRING,
  Bytes INT,
  RequestIP STRING,
  Method STRING,
  Host STRING,
  Uri STRING,
  Status INT,
  Referrer STRING,
  OS String,
  Browser String,
  BrowserVersion String
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  "input.regex" = "^(?!#)([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+[^(]+[(]([^;]+).*%20([^/]+)[/](.*)$"
) LOCATION '${INPUT}/cloudfront/data';

-- Total requests per operating system for a given time frame
INSERT OVERWRITE DIRECTORY '${OUTPUT}/os_requests/' SELECT os, COUNT(*) count FROM cloudfront_logs WHERE dateobject BETWEEN '2014-07-05' AND '2014-08-05' GROUP BY os;

CREATE EXTERNAL TABLE table-name ... LOCAL data-pathはdata-pathにあるファイルを新しく作成したテーブルtable-nameにinsertするコード。

INSERT DIRECTORY path SELECT ...は、s3上のpathにselect以下の結果を出力するコード。

Step4: Process Your Sample Data By Running a Hive Script

ここからは作成したEMR上でhiveのコードを実行していく。

Submit the Hive Script as a Step

  • EMRのコンソール画面を開く
  • クラスターリストの中から、先ほど起動したクラスターを指定する。
  • ステップの追加をクリックする。
  • ステップタイプをhive programにする
  • スクリプトs3の場所に、s3://[region].elasticmapreduce.samples/cloudfront/code/Hive_CloudFront.qを指定する。
  • S3 の場所の入力に、s3://[region].elasticmapreduce.samplesを指定
  • 引数に-hiveconf hive.support.sql11.reserved.keywords=falseを記述(予約語と同じ列名を許可するためのオプション)
  • 追加をクリック

実行されたsqlはSELECT os, COUNT(*) count FROM cloudfront_logs WHERE dateobject BETWEEN '2014-07-05' AND '2014-08-05' GROUP BY osで、2014-07-05から2014-08-05期間のosの種類を集計するというもの。

出力されたファイルは

Android 855
Linux 813
MacOS 852
OSX 799
Windows 883
iOS 794

Step5

最後はシャットダウンするための処理、これを忘れると永遠に課金され続ける・・・

To terminate your Amazon EMR cluster

  • EMRのコンソール画面を開く
  • コンソールリストから起動中のコンソールを選択
  • 上の削除ボタンを押す

最後に

今回はAWSのチュートリアルページの内容をそのまま実行しました。

自分でhqlファイルを書いて、s3上にアップロードして実行すると自分のしたい処理が出来たり、sshでemrのマスタノードに入り、hiveを実行することでインタラクティブに操作することもできます。

時間のある時に、AWSの勉強を続けていきたいと思います。

続きを読む