プログラマでありたい

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

Bees with machine gunsを使って負荷テスト

 静的サイトの運用であれば、現状ではS3 Web Hosting機能が最適と考えています。OSやミドルウェアのアップデートも不要で、かつ仮想サーバを起動するより圧倒的に安価です。一方で、ほぼ無敵のS3といえども、一定時間で過剰なアクセスがあった場合はスロットリング(throttling)といって、規制されてアクセス制限が掛かる可能性があります。しかし、その閾値がどれくらいなのか、謎です。(全体のリソース状況によるので、一定ではないとのこと)
 ちょっと試してみたかったので、負荷テストをおこなってみました。S3に対する負荷テストの場合、そんじょそこらの負荷では太刀打ち出来ません。そこで、複数のサーバから負荷を掛けてみることにしてみました。と言っても、複数のサーバをコントロールするのは面倒臭いので、Bees with machine gunsを使ってみました。

Bees with machine gunsとは?



 Python製の負荷テストツールです。Bees with machine gunsをインストールしたマシン(親機)から、Beeとよばれる子機(EC2 micro instance)を操作します。子機は、任意の数を起動可能です。複数のBeeから一斉に負荷を掛けて、最後に親機で集計します。負荷テスト自体は、Apache Benchを利用しているようです。
f:id:dkfj:20140728051149p:plain

Bees with machine gunsのインストール



Bees with machine gunsは、以下のモジュールに依存しています。

  • Python 2.6
  • boto
  • paramiko

 特別なものが無いので、楽勝と思いきやハマりました。Amazon Linuxを利用してたのですが、手順通り進めていくと、下記のようなエラーにぶち当たります。

/usr/lib64/python2.6/site-packages/Crypto/Util/number.py:57: PowmInsecureWarning: Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.
_warn("Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.", PowmInsecureWarning)

Traceback (most recent call last):
File "/usr/bin/bees", line 3, in
from beeswithmachineguns import main
File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 27, in
import bees
File "/usr/lib/python2.6/site-packages/beeswithmachineguns/bees.py", line 36, in
import paramiko
File "/usr/lib/python2.6/site-packages/paramiko/__init__.py", line 69, in
from transport import SecurityOptions, Transport
File "/usr/lib/python2.6/site-packages/paramiko/transport.py", line 32, in
from paramiko import util
File "/usr/lib/python2.6/site-packages/paramiko/util.py", line 32, in
from paramiko.common import *
File "/usr/lib/python2.6/site-packages/paramiko/common.py", line 98, in
from Crypto import Random
File "/usr/lib64/python2.6/site-packages/Crypto/Random/__init__.py", line 29, in
from Crypto.Random import _UserFriendlyRNG
File "/usr/lib64/python2.6/site-packages/Crypto/Random/_UserFriendlyRNG.py", line 38, in
from Crypto.Random.Fortuna import FortunaAccumulator
File "/usr/lib64/python2.6/site-packages/Crypto/Random/Fortuna/FortunaAccumulator.py", line 39, in
import FortunaGenerator
File "/usr/lib64/python2.6/site-packages/Crypto/Random/Fortuna/FortunaGenerator.py", line 36, in
from Crypto.Cipher import AES
File "/usr/lib64/python2.6/site-packages/Crypto/Cipher/AES.py", line 50, in
from Crypto.Cipher import _AES
ImportError: /usr/lib64/python2.6/site-packages/Crypto/Cipher/_AES.so: undefined symbol: rpl_malloc

 暗号化あたりのモジュールの問題のようで、GNU MPとMPIRを入れ替えた上で、再ビルドが必要のようです。この辺りを参考に、設定します。
The Bug Charmer: Building PyCrypto on Amazon EC2

# yum groupinstall "Development Tools"
# yum install python-devel
# 
# ./configure
# make
# make check
# make install
# wget https://ftp.gnu.org/gnu/gmp/gmp-6.0.0a.tar.bz2
# bzip2 -dc gmp-6.0.0a.tar.bz2 | tar xvf -
# cd gmp-6.0.0
# ./configure
# make
# make check
# make install
# wget http://www.mpir.org/mpir-2.6.0.tar.bz2
# bzip2 -dc mpir-2.6.0.tar.bz2 | tar xvf -
# cd mpir-2.6.0
# ./configure
# make
# make check
# make install
# yum reinstall python
# wget http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.tar.gz 
# tar xzvf pycrypto-2.6.tar.gz 
# cd pycrypto-2.6
# vi configure
if test $ac_cv_func_malloc_0_nonnull = yes; then :

$as_echo "#define HAVE_MALLOC 1" >>confdefs.h

#else
#  $as_echo "#define HAVE_MALLOC 0" >>confdefs.h

#   case " $LIBOBJS " in
#  *" malloc.$ac_objext "* ) ;;
#  *) LIBOBJS="$LIBOBJS malloc.$ac_objext"
# ;;
#esac


$as_echo "#define malloc rpl_malloc" >>confdefs.h

# pip uninstall PyCrypto
# python setup.py build
# pyton setup install
# pip install beeswithmachineguns

インストール後に、botoの設定を行ないます。.botoファイルとpemの用意をします。

vi ~/.boto
[Credentials]
aws_access_key_id = 'your access key'
aws_secret_access_key = 'your secret access key'

Bees with machine gunsの利用



 設定が全て終わっていれば、次のようなコマンドでBee(子機)の起動できます。

bees up -s 4 -g セキュリティグループ名 -k pemファイル名

 -sが起動するサーバ数、-gがセキュリティグループ名です。注意点としてはNon-VPCのネットワークで起動するので、Non-VPCのセキュリティグループを作成しておく必要があります。そして、親機からsshでアクセス出来るようにしておく必要があります。

 負荷テストは、次のような形です。
nが負荷リクエストの総数。cが同時接続数です。少ない台数で同時接続数を上げ過ぎると、処理しきれずにエラーがでます。注意点としては、/で終わるURLでないとテストできません。

# bees attack -n 10000 -c 250 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 4 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 4 bees will fire 2500 rounds, 62 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 3 is firing his machine gun. Bang bang!
Bee 2 is firing his machine gun. Bang bang!
Bee 0 is firing his machine gun. Bang bang!
Bee 1 is firing his machine gun. Bang bang!
Bee 1 is out of ammo.
Bee 0 is out of ammo.
Bee 2 is out of ammo.
Bee 3 is out of ammo.
Offensive complete.
     Complete requests:		10000
     Requests per second:	406.720000 [#/sec] (mean)
     Time per request:		621.828500 [ms] (mean)
     50% response time:		544.250000 [ms] (mean)
     90% response time:		804.250000 [ms] (mean)
Mission Assessment: Target successfully fended off the swarm.
The swarm is awaiting new orders.

 上記の結果をみると、毎秒406リクエストをこなしていたのが解ります。念の為、アクセスログを見てみると、全て200 O.K.でした。

 では、S3の限界に挑戦する為に、台数を増やしてみます。追加でBeeを増やせないようなので、一度落とします。

# bees down

 10台立ててみました。Beeが一杯です。
f:id:dkfj:20140728051259p:plain

# bees attack -n 100000 -c 250 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 10 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 10 bees will fire 10000 rounds, 25 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 4 is joining the swarm.
Bee 5 is joining the swarm.
Bee 6 is joining the swarm.
Bee 7 is joining the swarm.
Bee 8 is joining the swarm.
Bee 9 is joining the swarm.
Bee 5 is firing his machine gun. Bang bang!
Bee 6 is firing his machine gun. Bang bang!
Bee 3 is firing his machine gun. Bang bang!
Bee 0 is firing his machine gun. Bang bang!
Bee 2 is firing his machine gun. Bang bang!
Bee 8 is firing his machine gun. Bang bang!
Bee 4 is firing his machine gun. Bang bang!
Bee 4 is out of ammo.
Bee 6 is out of ammo.
Bee 0 is out of ammo.
Bee 5 is out of ammo.
Bee 2 is out of ammo.
Bee 8 is out of ammo.
Bee 3 is out of ammo.
Offensive complete.
     3 of your bees didn't make it to the action. They might be taking a little longer than normal to find their machine guns, or may have been terminated without using "bees down".
     Complete requests:		70000
     Requests per second:	330.450000 [#/sec] (mean)
     Time per request:		529.952571 [ms] (mean)
     50% response time:		523.142857 [ms] (mean)
     90% response time:		548.285714 [ms] (mean)

 3台のBeeが行方不明になってしましました。親機の性能不足でしょうか?それとも、子機の性能不足でしょうか?念の為、親機をc3.largeに変更しておきます。

 同時接続数を減らして、再度実行します。

# bees attack -n 10000 -c 200 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 10 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 10 bees will fire 1000 rounds, 20 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 4 is joining the swarm.
Bee 5 is joining the swarm.
Bee 6 is joining the swarm.
Bee 7 is joining the swarm.
Bee 8 is joining the swarm.
Bee 9 is joining the swarm.
No handlers could be found for logger "paramiko.transport"
Traceback (most recent call last):
  File "/usr/bin/bees", line 5, in <module>
    main.main()
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 127, in main
    parse_options()
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 119, in parse_options
    bees.attack(options.url, options.number, options.concurrent)
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/bees.py", line 325, in attack
    results = pool.map(_attack, params)
  File "/usr/lib64/python2.6/multiprocessing/pool.py", line 148, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/usr/lib64/python2.6/multiprocessing/pool.py", line 422, in get
    raise self._value
AssertionError: PID check failed. RNG must be re-initialized after fork(). Hint: Try Random.atfork()

 paramiko.transportのエラーがでました。

感想



 この後も、何度もパラメータや起動台数を変更しながら試してみました。どうも台数や接続数が多いと安定しない模様です。もう少し、調べてみる必要があります。S3 WebHositingに関して言えば、秒間400接続くらいであれば、余裕でこなせる模様です。流石!!


参照:
newsapps/beeswithmachineguns · GitHub
The Bug Charmer: Building PyCrypto on Amazon EC2

62nd Ruby/Rails勉強会@関西に参加してきた

 ここ半年ほど、Rubyでクローラーを作る本を書いていました。そんなこともあり、前回JAWSUG三都物語に参加した時に、アジャイルウェアの川端さんにRuby関西で話さないかとお誘いを受けました。もともとRubyのコミュニティに興味あったので、参加させて貰いました。
http://rubykansai.doorkeeper.jp/events/1316062nd Ruby/Rails勉強会@関西 #rubykansai - Ruby関西 | Doorkeeper

他の方の発表



RailsGirlsOsakaに参加して思ったこと
 RailsGirlsにスタッフとして参加した@to_uedaさんの感想。RailsGirls面白そうです。次は京都の企画があるので、興味がある人はチェック。
Rails Girls - Japanese


【LT】ちょっとしたTipsの提案をします
 @pinzoloさんのLT。デバッグツールなど個々人が独自で使うGemは、Gemfile.localを使おうという話。最初はGroupじゃダメなのと思ってたけど、自由な環境を使いたいという前提が解った時にしっくりきました。

【LT】るびまの告知
@muryoimplさんのLT。るびまが10周年で、記念メッセージ募集中のこと。併せて、るびまの編集・発行フローの紹介。るびまの中の人、初めてみました。もうちょっと話聞いてみたかったです。
Rubyist Magazine 十周年へのメッセージ


Railsで実装されているGitLabのGit Flow | GitLab実践入門 - Merge Requestによる開発
 GitLabを使って、GitHubチックにGit Flowを使う話。かなり参考になりました。会場からも、かなり具体的な質問が出てきて勉強になりました。リポジトリもCVS⇒SVN⇒Gitと進化してきているので、開発フローも改めて考えなおした方が良いですね。

「develop ブランチなんてオワコン」説
develop ブランチなんてオワコン - Togetterまとめ

Ruby初級者向けレッスン 50回 ブロック
@higakiさんによるRubyレッスン。毎回恒例のようで、今回はblockについて。言語の基本的な所をちゃんと勉強したことが無かったので、かなり勉強になりました。
higaki/learn_ruby_kansai_62 · GitHub

@IT Rails4入門記事をツッコもう
 時間が余ったので急遽追加されたコンテンツ。@agilekawabataさんがモデレータとなって、アジャイルウェアさんが連載している「開発現場でちゃんと使えるRails4入門」について話しあおうという企画。私も発表者の一人として、壇上にあがったもののRails4はまだ使っていないので特に突っ込めることは無かったです。すんません。テーマとして挙がったのは

  • rvm派 or rbenv派。

  壇上は、rbenv派多数。rvm派は川端さんと私だけ。rbenvが軽量なのが人気の理由とのこと

  • 利用するエディタ、開発環境は?

  意外なことにvim派とemacs派が多数で、それぞれ半々くらい。その次が、sublimetext。他にはAtomとNetBeans。みんな軽い環境が好きなんですね。(私もVim派)

  • Rails4の新機能つかってる?

  8つくらいの機能について、軽い解説と使っているかどうか。端末ごとのテンプレートは良いねという話と、config/secrets.ymlは必須だねという結論。Module#concerningは、どう使うのが良いか中々難しいとのことです。後は、CSRFプロテクションの変更は対応必須。

 全般的には、記事へのツッコミというより、川端さんへのツッコミになっているのが面白かったです。

感想



 初参加でしたが、かなり楽しかったです。参加者のレベルは、本当の初心者から上級者まで様々です。間違ったことを言っても直ぐにマサカリが飛んできて訂正してもらえるので、発表する方としても安心して話せるのではという感じでした。また、最後の告知で知ったのですが、町ごとにRuby勉強会が立ち上がっていて、気軽に勉強できる下地ができているようです。なかなか見習うべき所が多かったです。


See Also:
Rubyで作るクローラー Ruby crawler

賃貸でも工事なしで付けられるワイヤレスドアモニタ パナソニックのドアモニ VL-SDM110

 お家の防犯グッズの1つに、ドアモニタがあります。最近の物件だと当たり前のようについてたりしますが、ちょっと古い物件だと付いていないことが殆どです。この前まで住んでいた所にも付いてませんでした。賃貸だと工事できないので、ドアモニタは付けれないかなぁと思ってたのですが、ワイヤレスなこのご時世だと簡単に付けれました。


 私が使っていたのは、パナソニックのVL-SDM100という機種です。3ミリくらいの隙間があれば付けられるという代物なので、結構な確率で取り付けられるとおもいます。取り付けた様子は下の写真の通りですけど、殆ど違和感なかったです。

外から見た写真
f:id:dkfj:20140113113939j:plain

横から見た写真
f:id:dkfj:20131104140815j:plain

部屋の中から見た写真
f:id:dkfj:20131104140819j:plain

 かなりスッキリしていますよね。そして、画面は専用のモニタで見るのですが、ボタンを押して数秒くらいで見えます。操作もボタンを押すだけで、簡単です。息子が2歳くらいの時から、ピンポンとチャイムがなるとトコトコ歩いて行って、教えてもいないのにモニターを操作して見ていました。それくらい簡単です。電池の持ちもよくて、半年に1回くらいの交換で充分です。
 賃貸なのでドアモニタ諦めてるという人は、是非セキュリティの向上に検討してみてはいかがでしょうか?後は、不動産を貸している人も、ちょっとした付加価値向上に良いのではないのでしょうか?1万円くらいです。

「クラウドソーシングの衝撃」は、誰にとって衝撃なのか?

 先日の日替わりセールで買っていたクラウドソーシングの衝撃 (NextPublishing)を読みました。流し読みなので、後でゆっくり読むつもりだけど、頭に残ったの点は2つです。

  • 個人的に仕事を頼んでみたい
  • スキルをもった暇人の暇つぶしと比較されるプロはたまらんなぁ

個人的に仕事を頼んでみたい



1点目については、自分の苦手の分野のところを数万円くらいの金額でこなしてくれるのであれば、個人的にも仕事を頼んでみたいですね。最近はあまりしていませんが、個人的に自分が使うiOSアプリを作ったりします。自分用なのでアイコンやアプリ内のボタン等は、デザインもへったくれもないようなものになっています。クラウドソーシングが、その辺りいい感じのものが安価で発注できるのであれば、お願いした上でiTunes Storeとかに並べるのも面白いなぁと思います。また、もっと言うと、作りたいけど時間が取れずに取り掛かっていないものは山ほどあるので、プログラミングをお願いするのも今となってはありかもしれません。

スキルをもった暇人の暇つぶしと比較されるプロはたまらんなぁ



 この本を読んで、一番衝撃を受けたのが下記の1節です。

 ランサーズにコンペティション型の仕事として発注した。応募期間がわずか1週間であったにもかかわらず、152件の応募作品が集まり、その中の1件が記念ロゴとして採用された。この採用された記念ロゴは、実際に使用されており、同社のウェブサイトでみることができる。日活がこの採用されたロゴの製作者に報奨金として支払ったのは、わずか7万円であった。業界関係者の証言によると、この仕事を従来のように大手広告代理店やデザイン会社に発注した場合は、152件の候補デザインを出してもらうためには1000万円以上の予算と、3ヶ月以上の時間がかかったであるとのことであった。

 既存の広告代理店やデザイン会社に発注したら1,000万円掛かるはずだけど、クラウドソーシングだと7万円で済んだということです。それもそのはずです。仮に1作品7万円と仮定すると、クラウドソーシングでも、実際は152個×7万円で1,000万円程度の制作活動があったのです。それを採用されたものだけに支払うという方式を取ることにより、残りのコストが無かったことになっているだけです。
 これは、既存のルールで戦っている会社は勝てません。あとクラウドソーシングに参加している人たちも、勝てません。利益があるのは、システムを作っている胴元と発注者だけです。システム設計として著しく不均衡ですが、世の中には暇を持て余した高スキルの人というのは沢山いるということで成り立っているのでしょう。儲けは二の次で、評価されれば良いという動機の人も多々いると思います。そうなると、元々それで生計を立てていた人はたまらんやろなぁというのが感想です。


 一方で我が身を省みると、本業の仕事としてAWSの導入コンサルやトレーニングをする一方で、JAWSUGでは無償でハンズオンの手伝いとか設計相談しています。両者について自分の中で整合性を考えたこともなかったですが、この辺りの動きがクラウドソーシングなどの動きと似ているのかもと少し考えました。そもそもオープンソースの成り立ちも同じですね。

まとめ

 クラウドソーシングの定義自体は、ずっと前からしっていました。しかし、身近なものとして考えることがなく別世界のものだと思っていました。どうやら、そうではなさそうですね。この手のものを理解するには、使ってみるのが一番なので何か試してみようと思います。

クラウドソーシングの衝撃 (NextPublishing)

クラウドソーシングの衝撃 (NextPublishing)

夏のJAWS-UG 三都物語 2014でCDP道場に入門してきました

f:id:dkfj:20140708075033j:plain
(西島さん、撮影の写真)


 7/5に開催された夏のJAWS-UG 三都物語 2014で、もう1つのネタです。一度はやってみたいと思っていた、CDP道場に初めて参加してきました。もともとスタッフとしての参加でしたが、JAWS−UG沖縄の西島さんの尽力のお陰で、当日まで何もせず手ぶらで参加してチームリーダするだけで済みました。ありがとうございます&役に立たずにすいません。

CDP道場について



 お題とチームの回答については、今後も使い回しをする可能性があるので省略します。(正直言うと、お題のURLも結果のアーキテクチャの写真も残しておくのを忘れてました。)私のチームには、AWSを普段使いしている人はいなかったものの、オンプレミスでのアーキテクチャ設計が豊富な人がいたので、やりたいことをAWSでどう実現するかを翻訳するだけで、ほぼアーキテクチャが完成しました。その点、非常にチームに恵まれていました。チームメンバーの皆さん、ありがとうございました。
 ちなみに初めて参加だったのですが、経験者としてCDP道場に参加するのは、どこまで引っ張って良いか非常に悩ましいです。今回の場合は、アーキテクティングの時間が、1時間と非常に短かかったです。AWSに関しては初心者の方が殆どなので、調べながらではタイムアウトになることは目に見えていました。となると、AWS難しいという印象だけ残して帰っていくことになるかもしれません。一方で、私が主体となってやると、恐らく置いてけぼり感が満載で、面白くないでしょう。そう言った点で、非常にさじ加減が難しかったです。最後の方は、時間がなくてちょっと答えを出し過ぎてしまいました。
 初心者向きであれば、AWSの各サービスのチートシートを作って、30分で説明して2時間くらいあれやこれやが出来ればなぁと思いますが、全体の尺が非常に長くなるので中々難しいですね。アーキテクチャの選択ごとに、関係するサービスの説明をしていたのですが、短い時間でどこまで伝えられたか自信がないです。

セッションストアと外接について



 最後に、AWSの堀内さんを始めJAWSUGのコアメンバーの猛者に色々とツッコミを頂きました。印象に残ったのが2点。1つ目は、セッションストアにElastiCacheという選択に対して、MultiAZをどう対応させるかという指摘です。これは、ElastiCacheのMemcachedがAZを跨いでCache Clusterを構築できないことに起因します。セッションストアにMemcachedを使うというアイデアに、それならElastiCacheがあるよという脊髄反射をして、その辺りの考慮を完全に失念していました。
 会場でのディスカッションでは、DynamoDBをセッションストアに使ってはというアイデアなどが出てきました。自分ならどうするかなという所を、改めて考えてみました。まず基本方針としては、以下3点です。

  • セッションストアは、必ずアプリケーション・サーバから別だしにする(ローカルのサーバのメモリにセッションを格納しない)
  • レプリケーション機能は、過信しない(セッション用途で使うのであれば、準リアルの同期(≒レプリケーション)では不足)
  • ELBのスティッキー設定は、補助的に使う(例え同じサーバに割り振られなくても、セッションがある状態にする)

 上記考慮の上で、セッションストアに何を使うかの優先順位です。

  1. アプリケーションがAPIの類であれば、ステートレスにしてセッションを使わない
  2. ミドルウェア/フレームワークで、セッションストアとしてDynamoDBを利用できるのであれば、それを利用する
  3. EC2上にKyotoCabinetを構築して、マルチマスタ構成にする。ただし、アプリ側からはマスタスレイブ構成として、どちらかのAZを優先して接続するようにする。(マスタに接続できない場合は、アプリ側でスレイブに倒す)
  4. 選択肢がない場合は、DBをセッションストアとして利用する
  5. ELBの方でスティッキー設定をした上で、ミドルウェアのセッションのレプリケーション機能を使う
  6. セキュリティ上問題にならないのであれば、署名付きでCooki Storeも検討する

 正直、使うミドルウェアやフレームワーク次第なのですが、みんなどうしているのでしょうか?各言語・フレームワークごとのベストプラクティスをまとめてみたいものですね。(1年ほど前に、考えていました。)
アプリケーション・サーバのセッションの保存先の話


 2点目の指摘事項は、外部システムの接続をサーバから直接で良いのかという点です。要は、外部のシステムと密結合にする危険性についてです。この指摘については、100%同意です。基本的にはSQSをかまして、システム間を疎結合にします。場合によっては、SWFが使えないか考えます。この辺りは、密結合の危険性とSQS,SWFが何ぞやという説明が必要なので、時間切れになってしまいました。

感想



 やってみて解ったのですが、CDP道場は上手くやればどんなレベルの人にも勉強になります。初心者の人は、中級者以上の人がどう考えるのか。また中上級者の人は、AWSやJAWSUGのコアメンバの指摘やディスカッションを通して、別の見方に触れられます。中々、効率的な学習の仕方だと思うので、機会があれば臆せずに積極的に参加すると良いですね。
 ちなみに個人的には、悩む機会が多い共有ストレージやコンテンツ同期の方法でCDP道場やって、色々なパターンを見てみたいと思いました。


See Also:
アプリケーション・サーバのセッションの保存先の話
アプリケーション・サーバのセッションの保存先の話


参照:
CDP道場とは?その1 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その2 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その3 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その4 | 夏のJAWS-UG 三都物語 2014


Amazon Web Servicesクラウドデザインパターン設計ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド

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

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

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



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

感想



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


See Also:
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き


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

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インスタンス