2014-07-06

夏のJAWS-UG 三都物語 2014でElasticity の話をしてきました

　7/5に開催された夏のJAWS-UG 三都物語 2014で、初心者向けセッションでElasticityというテーマで話してきました。中身は、Elastic Load Balancer（ELB）とAutoScaling、Elastic IP（EIP）についてです。
　最初にアンケートをとったところ、40人くらいの参加者で、EIPを使ったことがある人が２割程度。ELBが数人で、AutoScalingは0という状況でした。AWSがギーク層だけでなく、一般的に広がってきているのが実感できて、中々うれしい瞬間でした。

発表資料

JAWS-UG三都物語2014 初心者向け Elasticity ELB/AutoScaling/EIP from Takuro Sasaki

伝えたかったことと反省点

　ELBとAutoScalingについては、資料作成時に設定の仕方を説明するか構造を説明するか悩んでました。結局、全体像が解からないと、設定の仕方を知っても仕方がないかと思い構造を中心にしました。当日話してみて、その選択で間違いはなかったと思いましたが、一方で失敗したという点があります。そもそも負荷分散装置（ロードバランサー）が何ぞやという説明が一切なかったので、置いてけぼりの人がそれなりにいたと思います。その辺、資料がなくても臨機応変に説明出来るようになりたいですね。
　ちなみにElasticityというお題だったのですが、これを発音するのが非常に難しかったです。カタカナにすると、「イラステシティー」。噛みまくりました。

感想

　今月1日から東京転勤になった為、大阪在住者としてのJAWSUG大阪参加はこれが最後になります。初めて勉強会で発表したのが2013年のJAWS-UG三都物語でした。それ以来、何回か登壇の機会を頂いて、自分自身かなり勉強させて貰いました。三都で始まって三都で一旦区切りがついたので、感慨深いものがあります。
　もちろん、これからも関西のイベントには積極的に参加するつもりなので、これからもよろしくお願い致します。

参照：
夏のJAWS-UG 三都物語 2014
[AWSマイスターシリーズ]Amazon Elastic Load Balancing (ELB)
[AWSマイスターシリーズ]Amazon CloudWatch & Auto Scaling
AWS-CloudDesignPattern

2014-07-02

AWSで新タイプのインスタンス発表。バースト可能なマイクロインスタンスの後継機

aws

f:id:dkfj:20140702220713p:plain

　どこぞの公式ブログっぽいタイトルになりましたが、AmazonのクラウドであるAWSの仮想サーバのec2に新タイプのインスタンスが追加されました。T2タイプです。その名の通り、t1.microの後継です。t1.microは、全インスタンスタイプの中で唯一CPUのバースト特性を持ったインスタンスです。バースト特性とは、短期的（十秒程度）に本来のCPU性能以上のリソースを利用できる機能です。サーバの用途として、普段のCPU使用率は10%以下でたまに跳ね上がるというものは割りと多いので、バースト特性は割りと面白いサービスです。しかし、t1.micorは、メモリが0.613GBです。21世紀になって14年という時を考えると、余りにストイック過ぎました。

T2シリーズとは

　そこで登場したのが、今回のT2シリーズです。ラインナップは、microだけでなくsmall,mediumもあります。当然、メモリも増量です。1GB,2GB,4GBと、それなりのミドルウェアをインストールできるレベルです。価格もm1,m3シリーズより安いです。以下、東京リージョンでの参考価格です。

名前	vCPUs	ベースライン性能	RAM (GiB)	1時間あたりのCPUクレジット	1時間あたりの料金	Price / Month
t2.micro	1	10%	1.0	6	$$0.020	$14.60
t2.small	1	20%	2.0	12	$0.040	$29.20
t2.medium	2	40%	4.0	24	$0.080	$58.40

　ベースラインやCPUクレジットの考え方は、バースト特性に深く関わります。どれだけバースト期間が続き、性能がどれくらいでるのかということです。私自身も、まだ深く検証していなので、そのうち試してみたいです。

旧シリーズとの性能・コスト比較

　一般的な話をすると常にCPUの利用率が50%以上を上回っているような使い方をしている場合は、かなり効率的に利用できていると思います。Webサーバ用途などであれば、可用性のために冗長構成を基本とすると、割りと低いCPU利用率になることが多いのではないでしょうか。そんな際に、T2シリーズを利用するとコスト削減効果が高いと思います。参考のために、m1.smallとt2.small、m3.mediumとt2.mediumの対比を見てみましょう。

名前	比較対象	m*シリーズとのCPU	m*シリーズとのメモリ比	m*シリーズとのコスト比
t2.micro	t1.micro	-	1.62倍	0.77倍
t2.small	m1.small	1vCPU	1.18倍	0.66倍
t2.medium	m3.small	1vCPU	1.07倍	0.79倍

　バースト特性をどう評価するか難しいところがありますが、m1.smallに対してt2.smallのコスト効果が高いことが解ります。

注意点

　t2インスタンスは、r3と同様にHVMタイプのAMIのみ利用できます。HVMは、Hardware Virtual Machineの略で日本語訳が完全仮想です。何に対して完全かというと、もうひとつの仮想化方式であるparavirtual（準仮想）です。旧来のAMIはparavirtual方式で作られていて、最近はHVM形式で提供されることが多いです。色々な所で、いつHVMベースに変えるか議論されていますが、そろそろ新規のインスタンスについてはHVMを使い、旧来のAMIも可能であればHVMに変更するという方向に舵を切ったほうがよさそうですね。

まとめ

　可能であれば、m1.smallはt2.smallに乗り換えた方が良いですよという話です。AMIのHVMからparavirtualへの再構築も、Chefのような仕組みを使っていれば簡単にできるんでしょうね。

参照：
Amazon Web Services ブログ: 【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス

2014-06-27

周回遅れで、SSDベースの新しいAmazon EBSの話

aws ガジェット

　少し前ですが、AWSのサービスに重大なアップデートがありました。ストレージサービスであるEBSに新しいサービスラインナップが追加され、General PurposeというSSDベースのサービスが利用できるようになりました。すでにyoshidashingoさんが色々考察しているので改めてまとめる必要もないですが、自分の中の整理のためにまとめてみます。

EBSのラインナップと価格体系　2014/06～

　今回追加されたのは、General Purpose(gp2)です。従来のスタンダードEBSはMagneticという名前になり、Provisioned IOPSは、io1という略称になりました。

　東京リージョンで利用例

サービス名	ベースラインIOPS	Max IOPS	価格体系
General Purpose (SSD)	3(IOPS)×GB	3,000(burst)	$0.12 1 か月にプロビジョニングされたストレージ 1 GB あたり
Provisioned IOPS (SSD)	100～4,000の間で指定したIOPS	4,000	0.142 : 1 か月にプロビジョニングされたストレージ 1 GB あたり 0.114 : 1 か月にプロビジョニングされた IOPS あたり
Magnetic 旧スタンダードEBS	40～200IOPS	?	$0.080 : 1 か月にプロビジョニングされたストレージ 1 GB あたり $0.080 /100 万 I/O リクエスト

選択のポイント

　今回追加されたGeneral Purpose（gp2）を考える上で一番のポイントは、IOPSの性能が確保したEBSの容量×3IOPSとなっている点です。100GBの場合は、100×3で300IOPSです。EBSの最大サイズである1TBの場合は、1,000×3で3,000IOPSになります。これ以外にも、gp2にはバーストという考え方があります。例えば、gp2で100GBの場合は、300IOPSがベースラインになります。バーストは、短期的（最大30分）に3,000IOPSまで利用できる機能です。この2つの前提で、gp2とProvisioned IOPS（io1）のどちらを使えば良いのか、ケースごとに考えてみます。

ケース１　1,000IOPS利用したい場合
gp2　334GB以上を選択すると、ベースラインが1,000IOPS。金額は、月額$43.12。4,500円弱
io1　GB×$0.142+1,000(IOPS)×$0.114。334GBと仮定したら、金額はGB×$47.42+$114。15,000円超。
gp2の方がお得

ケース２　3,000IOPSを利用したい場合
gp2　1,000GBを選択すると、ベースラインが3,000IOPS。金額は、月額$120。12,000円強
io1　GB×$0.142+3,000(IOPS)×$0.114。1,000GBと仮定したら、金額は$142+GB+$342。50,000円弱。

結論

　io2がコスト的にメリットが出るケースは非常に少ないです。少ないストレージ容量で、高IOPSが必要なケースのみです。今後の価格改定にもよりますが、gp2を使った方が有利なケースが殆どです。何か価格設定が間違っているようで、非常に気になります。バーストについては、別途検証してみたいです。

参照：
Amazon Web Services ブログ: 【AWS発表】新しいSSDベースのElastic Block Storage
料金 - Amazon Elastic Block Store (EBS ) EC2用ブロックストレージ | アマゾンウェブサービス（AWS 日本語）
Amazon EBSのGeneral Purpose(SSD)雑感→3000PIOPSの100GB(io1)より3000IOPS Infiniteの1000GB(gp2)のほうがおトク！ - yoshidashingo

2014-06-26

RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京

crawler プログラム

　ちょっと間が空きましたが、第1回Webスクレイピング勉強会@東京に参加して、LT枠でRubyでWebスクレイピングの話をしてきました。

Rubyで始めるWebスクレイピング from Takuro Sasaki

　今まで全く参加したことがないレイヤーの勉強会だったので、新しい発見があり非常に勉強になりました。スクレイピングのAPIであるkimonoやimportioなど、全く知らないサービスに出会えました。私は趣味でスクレイピングをしているのですが、本職としてやっている方のノウハウや悩みどころを聞けて参考になりました。

　また、資料中に書いているのですが、現在Rubyでクローラーを作る本を書いています。一応全編書き終えてるので、夏頃に出ればなぁという状況です。そして、東京に異動することになりました。勉強会に参加しやすくなるので、色々な所に顔をだしてみたいと思っています。

　ちなみに第2回Webスクレイピング勉強会@東京にも登壇予定です。ブログやサイトから、ヘッダーやフッター、サイドバーなどを除いて本文だけ抽出するにはどうするのというテーマで、20分ほど話す予定です。

参照：
第1回Webスクレイピング勉強会@東京（全3回） - Qiita
2014/06/22 第1回Webスクレイピング勉強会@東京 #東京スクラッパー - Togetterまとめ
 第1回Webスクレイピング勉強会@東京に参加してきました - 夜はいよいよ冴えたのだ。

発表者資料
オープンデータのためのスクレイピング
 Webスクレイピング勉強会@東京オープニングトーク (第1版) #東京スクラッパー
 ScrapyとPhantomJSを用いたスクレイピングDSL
Webスクレイピングの基礎知識 #東京スクラッパー
 CasperJSを使って任意のWebサイトを電子書籍化する方法
 渡る世間は自然言語ばかり #東京スクラッパー
 オープンデータのためのスクレイピング

Rubyによるクローラー開発技法

作者: るびきち,佐々木拓郎
出版社/メーカー: SBクリエイティブ
発売日: 2014/08/25
メディア: 大型本
この商品を含むブログ (1件) を見る

Spidering hacks―ウェブ情報ラクラク取得テクニック101選

作者: Kevin Hemenway,Tara Calishain,村上雅章
出版社/メーカー: オライリー・ジャパン
発売日: 2004/05
メディア: 単行本
購入: 52人クリック: 904回
この商品を含むブログ (103件) を見る

2014-06-04

新幹線のWifiは、どうやってつながるのか？或いは、なぜ遅いのか？

f:id:dkfj:20140604102324j:plain

　東海道新幹線の東京～大阪間で提供されているWifiサービス。スマフォのテザリングが規制によって使えない時に、今でも使っています。しかし、御存知の通り遅いのです。あと、何故、東京～大阪間しか使えないのか。微妙に疑問に思っていました。答えは、すべて通信方式にありました。

　ずばり、LCX(同軸漏洩ケーブル)の余った帯域を、客用に開放しているだけだからです。同軸漏洩ケーブルとは、同軸ケーブルを使った通信方式です。同軸ケーブルから意図的に信号を漏らすことにより、ケーブルの周辺だけ通信できるという方式です。その方式ゆえにトンネル内でも通信できます。実際、もともとの用途は、新幹線の業務用の通信用です。それ以外にも、新幹線内の公衆電話等でも利用していたようです。
　そして、東海道新幹線では、そこを通る通信をデジタル化しています。デジタル化に伴い、ある程度帯域が余ったの、Wifiサービスとして提供しているのです。

　しかし、無限の帯域が余っている訳ではありません。新幹線1編成あたり最大2MBpsとのことです。1両ではないです。1編成です。のぞみであれば、16両編成で700席くらいあるわけです。そのうち％の人が使っているか解りませんが、2MBpsを分け合う訳ですよ。遅いのはあたりまえです。

　ということで、新幹線の中ではネットを使わない時間の過ごし方をするのが吉でしょう。

電波とアンテナが一番わかる (しくみ図解)

作者: 小暮裕明,小暮芳江
出版社/メーカー: 技術評論社
発売日: 2011/10/25
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

2014-05-19

Rubyのtwitterライブラリで、Twitter Streaming APIが扱えるようになっていた

プログラム

　久々に@sferikによるTwitterのAPIを使ってみると、いつの間にかTwitter Streaming APIも取得できるようになっていました。Twitter Streaming APIは、APIの中でも異色のもので、ひたすらパブリック・タイムラインを取得するといったものです。4年ほど前に出た当初は、かなり話題になって色々な人がタイムラインを取得して分析していました。かく言う私も、AWSのEC2上で動かして、1年ほどTwitterの呟きを取得して遊んでいました。ちょうど4年前はワールドカップがあり、日本の試合がある度にTweet量が爆発して、プログラムも爆発していました。細かい数字は忘れましたが、無料で使える数%に絞ったAPIのうち日本語だけに絞っても、月数千万件レベルでデータがあったと思います。
　そんなこんなのTwitter Streaming APIですが、当時はサードパーティ製のライブラリもなく自前でNet::HTTPやEventMachineを組み合わせて取得しました。それが、ライブラリ1つで簡単に出来るようになっているんですね。ありがたい限りです。

Twetter Streaming APIのサンプルコード

　一番簡単なTwetter Streaming APIのサンプルコードです。APIキーを取得して、環境変数にセットしておけば使えます。

require 'twitter'

config = {
  :consumer_key => ENV['TWITTER_API_KEY'],
  :consumer_secret => ENV['TWITTER_API_SECRET'],
  :access_token => ENV['TWITTER_ACCESS_TOKEN'],
  :access_token_secret => ENV['TWITTER_ACCESS_TOKEN_SECRET']
}
client = Twitter::Streaming::Client.new(config)
client.sample do |tweet|
  if tweet.is_a?(Twitter::Tweet)
    #日本語の呟きだけ表示
    puts tweet.text if tweet.lang == "ja"
  end
end

Twetter Streaming APIのデモ

まとめ

　これだけでは面白くないので、次はAWS Kinesisと組み合わせてみようかと思います。当時も、突発的に大量のデータが飛んできた時の処理能力などで困っていました。今だとKinesisとバックエンドのサーバを組み合わせたら何でもできそうですね。

参照：
sferik/twitter · GitHub

2014-05-17

RubyのHTTPS通信で、OpenSSL::SSL::SSLErrorが出たら？

プログラム

　Mac OSのバージョンアップする度に出しているような気がするのが、RubyのHTTPS通信でのエラー。ルート証明書が見つからなくてエラーがでます。

/.rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/net/http.rb:918:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

　そんな場合は、まずはRubyの慌てず騒がずNet::HTTPがどこに証明書を探しにいっているかを確認します。

$ ruby -ropenssl -e "p OpenSSL::X509::DEFAULT_CERT_FILE"
"/etc/openssl/cert.pem"

　指し示された場所に、あるのでしょうか？　

$ ls /etc/openssl/cert.pem
ls: /etc/openssl/cert.pem: No such file or directory

　ないですね。OSをバージョンアップすると、何故か消えるっぽいです。

　フォルダ作って、証明書をダウンロードします。

$ sudo mkdir /etc/openssl
Password:
$ cd /etc/openssl/
$ sudo wget http://curl.haxx.se/ca/cacert.pem
--2014-05-17 17:10:23--  http://curl.haxx.se/ca/cacert.pem
Resolving curl.haxx.se... 80.67.6.50, 2a00:1a28:1200:9::2
Connecting to curl.haxx.se|80.67.6.50|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 250283 (244K)
Saving to: 'cacert.pem'

100%[======================================>] 250,283      214KB/s   in 1.1s   

2014-05-17 17:10:25 (214 KB/s) - 'cacert.pem' saved [250283/250283]
$ sudo mv cacert.pem cert.pem

　解決！！

OpenSSL::SSL::SSLError

　このエラーは、当然ながらWindowsでも起こりえます。Macの場合と同様に、デフォルトパスの場所にファイルを配置すれば、問題は解決します。それでは、Windows rubyの場合は、デフォルトの証明書のパスは、どこでしょう？RubyInstallerで入れた場合は、次のようになっていました。

>ruby -ropenssl -e "p OpenSSL::X509::DEFAULT_CERT_FILE"
"C:/Users/Luis/Code/luislavena/knap-build/var/knapsack/software/x86-windows/openssl/1.0.0l/ssl/cert.pem"

　ダメだ。このフォルダは作れない。誰だよ、Luisって！！そういう場合は、環境変数でしています。

>set SSL_CERT_FILE=C:\Ruby200\cacert.pem

　解決！！

プログラマでありたい

おっさんになっても、プログラマでありつづけたい

夏のJAWS-UG 三都物語 2014でElasticity の話をしてきました

発表資料

伝えたかったことと反省点

感想

AWSで新タイプのインスタンス発表。バースト可能なマイクロインスタンスの後継機

T2シリーズとは

旧シリーズとの性能・コスト比較

注意点

まとめ

周回遅れで、SSDベースの新しいAmazon EBSの話

EBSのラインナップと価格体系　2014/06～

選択のポイント

結論

RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京

新幹線のWifiは、どうやってつながるのか？或いは、なぜ遅いのか？

Rubyのtwitterライブラリで、Twitter Streaming APIが扱えるようになっていた

Twetter Streaming APIのサンプルコード

Twetter Streaming APIのデモ

まとめ

RubyのHTTPS通信で、OpenSSL::SSL::SSLErrorが出たら？

OpenSSL::SSL::SSLError

発表資料

伝えたかったことと反省点

感想

T2シリーズとは

旧シリーズとの性能・コスト比較

注意点

まとめ

EBSのラインナップと価格体系 2014/06～

選択のポイント

結論

Twetter Streaming APIのサンプルコード

Twetter Streaming APIのデモ

まとめ

OpenSSL::SSL::SSLError

EBSのラインナップと価格体系　2014/06～