debiancdn

AWS, Content Delivery Network and Debian

カテゴリーアーカイブ: AWS

オブジェクトストレージのベンチマークツール、COSBench

AWS Advent Calenderの12月22日分です。

COPSBenchとは

世の中、ベンチマークソフトウェアであふれています。その目的は様々ですが、S3に代表されるオブジェクトストレージのベンチマークソフトウェアは、POSIXなファイルシステムのベンチマークとちがってほとんど普及していません。

Amazon S3のパフォーマンスをあげるコツという記事にあるとおり、S3は使い方によってパフォーマンスが異なります。そのため、実際のワークロードを模擬することで初めて意味のある性能指標を得ることが出来ます。

COSBenchは万能ではありませんが、様々なワークロードをXMLで記述することで、模擬実行できるApache2ライセンスのソフトです。Intelの中国の方を中心に開発がすすめられています。http://www.slideshare.net/ben_duyujie/cosbench-apac に概要があるので、時間があるかた、興味のあるかたはこちらをご覧ください。

構成は、Controllerが複数のDriverに対して測定対象に負荷をかけるように指令する作りです。

つかってみる

本記事では、そのごちゃごちゃした話はさておき、COSBenchを使って、結果を得るところまでみてみることにしましょう。

下準備

cosbenchはubuntu12.03 LTSがメインサポートなので、まずはubuntsu12.03を用意します。

$ sudo apt-get update && sudo apt-get install openjdk-7-jre unzip curl

$ java -showversion
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
.(以下略)

という具合で、openjdkがはいればOKです。

入手とインストール

入手先はgithub上にあります。

$ wget https://github.com/intel-cloud/cosbench/releases/download/0.3.3.0/0.3.3.0.zip
$ unzip 0.3.3.0.zip
$ ln -s 0.3.3.0 cos
$ cd cos
$ chmod +x *.sh

展開した結果は

とりあえず動作確認

まずは、start-allをしてみます。

私の場合は、Vagrantfileをポートフォワードするように修正したので、いったん、vagrant haltしてから、vagrant upします。

~/playground/vagrant-place/ubuntu1204$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] -- 19088 => 19088 (adapter 1)
[default] -- 18088 => 18088 (adapter 1)

ここまでくれば、ポートが動いているかどうかをcurlかなにかで試します。

動いていれば、ワークロードファイルを登録してみます。

vagrant@vagrant-ubuntu:~/cos$ sh cli.sh submit conf/workload-config.xml
Accepted with ID: w1
vagrant@vagrant-ubuntu:~/cos$ sh cli.sh info
Drivers:
driver1 http://127.0.0.1:18088/driver
Total: 1 drivers

Active Workloads:
w1 Sun Dec 22 03:22:03 BRST 2013 PROCESSING
Total: 1 active workloads

さらに、http://127.0.0.1:19088/controller/index.html にアクセスしてみる。

Active Workloadsにw1がみえているはずなので、適当にいじってみるといいです。

sh stop-all.sh で停止します。

実際に使ってみる

Controllerの設定を確認する。

Controllerの設定はcontroller.confで行います。中身は一目瞭然かと。
そして、制御対象のdriverのURLも忘れずに。

vagrant@vagrant-ubuntu:~/cos$ cat conf/controller.conf
[controller]
drivers = 1
loglevel = INFO
logfile = log/system.log
archive_dir = archive

[driver1]
name = driver1
url = http://127.0.0.1:18088/driver

はDriverを動かす

Controllerを動かす前に、Driverを動かします。start-driver.shを走らせるだけ。

vagrant@vagrant-ubuntu:~/cos$ sh start-driver.sh
Launching osgi framwork ...
Successfully launched osgi framework!
Booting cosbench driver ...
.
Starting cosbench-log0.3.3.0 [OK]
Starting cosbench-tomcat0.3.3.0 [OK]
Starting cosbench-config0.3.3.0 [OK]
Starting cosbench-http0.3.3.0 [OK]
Starting cosbench-core0.3.3.0 [OK]
Starting cosbench-core-web0.3.3.0 [OK]
Starting cosbench-api0.3.3.0 [OK]
Starting cosbench-mock0.3.3.0 [OK]
Starting cosbench-ampli0.3.3.0 [OK]
Starting cosbench-swift0.3.3.0 [OK]
Starting cosbench-keystone0.3.3.0 [OK]
Starting cosbench-s30.3.3.0 [OK]
Starting cosbench-librados0.3.3.0 [OK]
Starting cosbench-scality0.3.3.0 [OK]
Starting cosbench-driver0.3.3.0 [OK]
Starting cosbench-driver-web0.3.3.0 [OK]
Successfully started cosbench driver!
Listening on port 0.0.0.0/0.0.0.0:18089 ...
Persistence bundle starting...

Persistence bundle started.
!!! Service will listen on web port: 18088 !!!

というようになれば、OKです。

http://127.0.0.1:18088/driver/index.html にアクセスします。
つくりたてのほやほやなので何も登録はありませんが。。

続いてControllerの起動

これも start-controller.shでOKです。

vagrant@vagrant-ubuntu:~/cos$ sh start-controller.sh
Launching osgi framwork ...
Successfully launched osgi framework!
Booting cosbench controller ...
.
Starting cosbench-log0.3.3.0 [OK]
Starting cosbench-tomcat0.3.3.0 [OK]
Starting cosbench-config0.3.3.0 [OK]
Starting cosbench-core0.3.3.0 [OK]
Starting cosbench-core-web0.3.3.0 [OK]
Starting cosbench-controller0.3.3.0 [OK]
Starting cosbench-controller-web_0.3.3.0 [OK]
Successfully started cosbench controller!
Listening on port 0.0.0.0/0.0.0.0:19089 ...
Persistence bundle starting...

Persistence bundle started.
!!! Service will listen on web port: 19088 !!!

http://127.0.0.1:19088/controller/index.html にアクセスすると、

矢印の先に、submit new workloadsとありますが、ここから負荷ルールファイルを登録します。

これは、オレゴンのS3に対して、64KBのファイルを複数回、80%readでのテストしてみるときのルールです。cprefix= には該当のバケットを指定します。

あとは結果を待つ!

ルールを登録すると、すぐに測定が始まります。数分後には次のような結果をみることになるでしょう。

Final Result

General Report

Op-Type Op-Count Byte-Count Avg-ResTime Throughput Bandwidth Succ-Ratio
init-write 0 ops 0 B N/A 0 op/s 0 B/S N/A
prepare-write 20 ops 1.28 MB 772.45 ms 1.29 op/s 82.76 KB/S 100%
read 177 ops 11.33 MB 1042.37 ms 6.07 op/s 388.55 KB/S 100%
write 41 ops 2.62 MB 1180.12 ms 1.41 op/s 90.2 KB/S 100%
cleanup-delete 40 ops 0 B 365.75 ms 2.73 op/s 0 B/S 100%
dispose-delete 0 ops 0 B N/A 0 op/s 0 B/S N/A

ResTime (RT) Details

Op-Type 60%-RT 80%-RT 90%-RT 95%-RT 99%-RT 100%-RT
init-write N/A N/A N/A N/A N/A N/A
prepare-write < 710 ms < 720 ms < 730 ms < 1,490 ms < 1,490 ms < 1,520 ms
read < 1,480 ms < 1,490 ms < 1,510 ms < 1,620 ms < 2,360 ms < 2,760 ms
write < 1,510 ms < 1,540 ms < 1,550 ms < 1,560 ms < 1,580 ms < 1,580 ms
cleanup-delete < 340 ms < 340 ms < 340 ms < 370 ms < 920 ms < 1,020 ms
dispose-delete N/A N/A N/A N/A N/A N/A

 
となったので、次にアイルランドでも試してみる。

General Report

Op-Type Op-Count Byte-Count Avg-ResTime Throughput Bandwidth Succ-Ratio
init-write 0 ops 0 B N/A 0 op/s 0 B/S N/A
prepare-write 20 ops 1.28 MB 1031.1 ms 0.97 op/s 62.07 KB/S 100%
read 308 ops 19.71 MB 376.57 ms 10.48 op/s 670.73 KB/S 100%
write 71 ops 4.54 MB 1686.62 ms 2.4 op/s 153.9 KB/S 100%
cleanup-delete 40 ops 0 B 346.02 ms 2.89 op/s 0 B/S 100%
dispose-delete 0 ops 0 B N/A 0 op/s 0 B/S N/A

ResTime (RT) Details

Op-Type 60%-RT 80%-RT 90%-RT 95%-RT 99%-RT 100%-RT
init-write N/A N/A N/A N/A N/A N/A
prepare-write < 890 ms < 900 ms < 930 ms < 2,390 ms < 2,390 ms < 2,470 ms
read < 310 ms < 320 ms < 330 ms < 900 ms < 1,690 ms < 2,110 ms
write < 1,640 ms < 2,430 ms < 2,720 ms < 3,060 ms < 3,360 ms < 3,400 ms
cleanup-delete < 300 ms < 310 ms < 310 ms < 330 ms < 1,360 ms < 1,480 ms
dispose-delete N/A N/A N/A N/A N/A N/A

ついでに東京も。

ID: w6 Name: s3-tokyo Current Statefinished
Submitted At: 2013/12/22 4:39:57 Started At: 2013/12/22 4:39:57 Stopped At: 2013/12/22 4:41:00
more info
Final Result
General Report

Op-Type Op-Count Byte-Count Avg-ResTime Throughput Bandwidth Succ-Ratio
init-write 0 ops 0 B N/A 0 op/s 0 B/S N/A
prepare-write 20 ops 1.28 MB 88.95 ms 11.22 op/s 718.29 KB/S 100%
read 2.83 kops 181.06 MB 53.83 ms 94.52 op/s 6.05 MB/S 99.93%
write 702 ops 44.93 MB 122.86 ms 23.45 op/s 1.5 MB/S 100%
cleanup-delete 40 ops 0 B 29.45 ms 33.87 op/s 0 B/S 100%
dispose-delete 0 ops 0 B N/A 0 op/s 0 B/S N/A

ResTime (RT) Details

Op-Type 60%-RT 80%-RT 90%-RT 95%-RT 99%-RT 100%-RT
init-write N/A N/A N/A N/A N/A N/A
prepare-write < 90 ms < 100 ms < 120 ms < 130 ms < 130 ms < 130 ms
read < 50 ms < 60 ms < 70 ms < 80 ms < 250 ms < 2,390 ms
write < 120 ms < 140 ms < 160 ms < 190 ms < 280 ms < 1,140 ms
cleanup-delete < 30 ms < 30 ms < 40 ms < 60 ms < 80 ms < 90 ms
dispose-delete N/A N/A N/A N/A N/A N/A

おわりに

「パフォーマンス計測」という意味で「ベンチマーク」という言葉が使われる事自体に違和感を感じるのは私だけでしょうか。ベンチマークは比較の対象があってはじめてベンチマークであるはずなのですが、巷では比較対象がなくてもその言葉が使われることが多いようです。

本記事では巷で使われる「ベンチマーク」のほうがキャッチーで、ググラビリティ高いためにこの言葉を使いました。

via http://arakinotes.blogspot.com/2013/12/cosbench.html

広告

2013年のAWSアップデートを料理にたとえるという難題へのチャレンジ。

2013.12にCookpadで行われたクラウド女子会。2013年のAWSアップデート10個を料理にたとえてみました。

異論、反論があることは承知しておりますので、ぜひご意見ください。

「俺ならもっとカッコイイたとえするぜ」というシリーズもいいかもしれません。

via http://arakinotes.blogspot.com/2013/12/2013aws.html

OpsWorksで動かすルールをvagrant+chef soloを使ってローカルでも試せるようにする

 

OpsWorksで動かすルールをvagrant+chef soloを使ってローカルでも試したい!
と思いませんか?

OpsWorksそれ自体はお金はかからないとはいえ、OpsWorksから起動されるec2と付随するいくつかのサービスにはお金がかかります。それを vagrant を使ってローカルで試行錯誤できればお金はかかりません。

OpsWorksはchefで作られていることは周知の事実です。
http://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html にも以下の通り書かれています。

AWS OpsWorks uses its own Chef recipes to configure the instances on a stack. Chef Solo runs on every instance, and AWS OpsWorks sends commands to each instance to run recipes that set up, configure, and shut down the instance. You can extend these actions with your own custom recipes. You can also run your custom recipes on a specific instance or on all instances in your stack.

というわけで、ちょっとやってみましょう。

chefむけにかかれたルールはgitで管理するのが、よくある楽な方法です。そのため、一番ラクなのは「全てのシステム記述を一つのgitに書く」こと。
全てのシステム記述を同じgitに書いていれば、chef soloをopsworksの代わりに使うことでほぼテストはローカルでできる。

と、言いたいところですが、OpsWorksのGUIで設定する部分と、chef soloむけの設定には差異があるので、ちょっとしたコツが必要になります。

  1. ec2の代わりとしてvagrantの中でUbuntuを動作するようにする。
  2. OpsWorks代わりのchef solo環境をlocalに用意する
  3. 設定(site-coolbooks)はbitbucketに配置する

ここでのポイントは、手元につくったChef SoloはあくまでもOpsWorks代わりをさせるためであり、手元のChefSoloには最低限の設定ですませること。

ちなみに、bitbucketは無料でも秘密レポジトリを作れるので、OpsWorksむけにはgithubよりも楽だと思います。

これから書くことはこんなかんじ。OpsWorksの進化はきっととまらないので、今の時点での私のおすすめってことで!

vagrantのインストール

vagrantは
http://downloads.vagrantup.com/
から、自分の環境にあったものをインストール。

昔はRubyGemをつかってインストールしていたが、今は違うので素直にパッケージを使うべきでしょう。

boxでubuntuを用意

vagrant box コマンドをキメる

$ sudo vagrant box add ubuntu-1204-server  http://goo.gl/8kWkm

initしてログインしてみる

問題なくログインできるはず。

$ vagrant init ubuntu-1204-server
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'ubuntu-1204-server'…

$ vagrant ssh
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64)

ここまでできてればひとまずOK。

vagrant ssh-configの出力を .ssh/configに登録し、vagrant-ubuntuという名前でログイン可能にする

vagrant ssh-config すると、ラップしている情報を確認できるので、.ssh/configにつっこむ。ここでは hostパラメータvagrant-ubuntu という名前で登録しておく。

後で
ssh vagrant-ubuntu でログインできればOK。

Chef Solo環境の用意

install

どんな方法でもOKだと思う。

$ sudo gem install chef chef-solo

あたりでOK。

Chef SoloでOpsWorks代わりのレポジトリ作り

ここでのポイントは、手元につくったChef SoloはあくまでもOpsWorks代わりをさせるためであり、手元のChefSoloには最低限の設定ですませること。

まずは手元にchef soloの環境を作る。ここではcdn-dns-v2という名前。
これが大本のchef soloであり、

$ knife solo init cdn-dns-v2

つくったディレクトリに移動して

rm -rf site-cookbooks/

いったんgit登録。して、commit.

git add .
git status
git commit

設定(site-coolbooks)の用意

手元のChefSoloとOpsWorksの両方で共通で使う設定(site-cookbooks)は
bitbucketに配置させる。

まずは site-cookbooks作り。

共通で使う設定 であるため、可能な限りこのsite-cookbooksに詰め込むことになる。

knife cookbook create dnsbalance -o dnsbalance
** Creating cookbook dnsbalance
** Creating README for cookbook: dnsbalance
** Creating CHANGELOG for cookbook: dnsbalance
** Creating metadata for cookbook: dnsbalance

$ tree
.
└── dnsbalance
└── dnsbalance
├── CHANGELOG.md
├── README.md
├── attributes
├── definitions
├── files
│ └── default
├── libraries
├── metadata.rb
├── providers
├── recipes
│ └── default.rb
├── resources
└── templates
└── default

12 directories, 4 files

dnsbalance/dnsbalanceと、二段に深くなったディレクトリ構成だが、これはそういうもんだと諦めることにする。

共通で使う設定 であるため、可能な限りこのsite-cookbooksに詰め込むと

$ tree
.
└── dnsblance
├── .git/config (ここは略)
└── dnsbalance
├── CHANGELOG.md
├── README.md
├── attributes
│ └── default.rb
├── metadata.rb
├── recipes
│ └── default.rb
└── templates
└── default
├── dns_balance.sbin.erb
├── init.erb
├── ssh-config.erb
├── td-agent.conf.erb
└── td-agent.conf.erb~

という具合になる。このレポジトリをbitbucketに追加する。

bitbucketに登録

追加の仕方はいろいろだが、
git remote add origin ssh://git@bitbucket.org/ar1/chef-cookbook-dnsbalance.git
といった具合。このときの .git/configを抜粋すると

[remote "origin"]
url = ssh://git@bitbucket.org/ar1/chef-cookbook-dnsbalance.git
fetch = +refs/heads/*:refs/remotes/origin/*

親レポジトリのサブモジュールとして追加

親レポジトリ(OpsWorksの代理として動作するレポジトリ)のディレクトリに移動。
そこのトップで、
submoduleとして、追加する。

git submodule add git@bitbucket.org:ar1/chef-cookbook-dnsbalance.git site-cookbooks

その結果

$ tree
.
├── Berksfile
├── Berksfile.lock
├── cookbooks
├── data_bags
├── nodes
│ └── vagrant-ubuntu.json
├── roles
└── site-cookbooks ((ここより下が追加されている))
└── dnsbalance
├── CHANGELOG.md
├── README.md
├── attributes
│ └── default.rb
├── metadata.rb
├── recipes
│ └── default.rb
└── templates
└── default
├── dns_balance.sbin.erb
├── init.erb
├── ssh-config.erb
└── td-agent.conf.erb

10 directories, 12 files

という具合になる。

vagrantでつくったubuntuにデプロイさせる

run_listに追加、実行

vagrantの中にデプロイするためにrun_listに追加

cdn-dns-v2/nodes$ cat vagrant-ubuntu.json
{"run_list":[
"dnsbalance"
]}

これを加えれば、site-cookbooksの下にあるdnsbalanceの中にある recipes/default.rb を実行させることができる。

あとは
knife solo prepare vagrant-ubuntu

  1. vagrant-ubuntuの中にchefが用意され、

後に
knife solo cook vagrant-ubuntu
を実行すれば、

  1. 親レポジトリの nodes/vagrant-ubuntu.json が読み込まれ、
  2. その結果、recipes/default.rb を実行させることができる。

submodule内容変更時にやること

submoduleで書いたコードに変更があれば

git submodule foreach 'git pull origin master'
を行う

できあがりました!あとはやるだけ!

via http://arakinotes.blogspot.com/2013/12/opsworksvagrantchef-solo.html

AWSバッドノウハウカンファレンスの必要性を訴えて来ました

多く人がすでにAWSクラウドデザインパターン(CDP)を活用しています。CDPこそがAWSを使う目的とまでは言わないにしても、パターンとしてまとめられた体系の上であれば安心してシステムを作れると考えている人は多いのではないでしょうか。

それが証拠に、AWSのCDP関連書籍は、Webデザインのカテゴリで1位(平成25年8月6日現在)でした。

CDPがそのwikiで整備され、公開されてから1年半近くがたちました。日進月歩のこのクラウドの世界で、CDPが生き残っていることは、CDPがそれだけ良く練られた、万人受けするものである故であることは先ず間違いないでしょう。

一方で、CDPは多くの前提知識を必要とする形でまとめられています。CDPがAWSを使う目的だとしたら、AWSを使うために勉強せざるを得なかったことは、沢山あるのではないでしょうか。それらをまとめることはCDPほどの意義はないかもしれませんが、利用者の底辺を広げ、より洗練されたCDPを生み出す原動力となると考えました。

そこで必要になるのは、キャッチーなフレーズです。私はあえて、「AWSバッドノウハウ」と呼ぶことにしました。

「バッドノウハウ」という言葉を聞いたことはあるでしょうか。だれが言い始めたかには諸説あるのですが、最初にきちっと言語化されたものは、高林氏の次の定義でしょう。

計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。

http://0xcc.net/misc/bad-knowhow.html
2003-03-30、高林哲

繰り返しになりますが、「AWSを使うために勉強せざるを得なかったこと」がバッドノウハウであるならば、それらをまとめることには価値があるでしょう。CDPとバッドノウハウの関係を絵にするとこんな具合です。

CDPばかりが注目されていますが、CDPはそれだけで成り立つものではありません。その下にはアンチパターンがあり、バッドノウハウがあり、さらに次々とあらわれるAWSのサービスやユーザの要件などの広大な海の上にある、氷山の一角といえるものです。

それらを集める一つの方法として、「AWSバッドノウハウカンファレンス(仮称)」を開催したいと思っています。現時点では思いつきの段階ですが、皆様のご協力をいただけると幸いです。また、オンラインでアイデアを集める方法も模索しようと思っています。

最後に、この記事を書いたきっかけは、JAWSUG東京が大崎のフューチャーアーキテクトさんで開催され、そのLTでした。会全体の概要はしんやさんのレポートをご覧いただくとして、私の発表について説明することにしました。何しろ今回の私の発表は資料を見ただけではさっぱりわからないので。

via http://arakinotes.blogspot.com/2013/08/aws.html

AWSに関する書評:ITアーキテクトになるためのシステム設計・開発・運用 ミス撲滅ガイド

クラウドアンチパターン研究家の荒木です。ITアーキテクトになるためのシステム設計・開発・運用 ミス撲滅ガイド (日経BPムック)を購入したので、早速読んでみた。

136頁から141頁迄の間に、「【第8章】 クラウドアンチパターン」のAmazon Web Servicesの節があった。この頁の出典は2012年11月の日経SYSTEMSのものだった。

S3-backedのEC2の場合にデータが消えることがあるという記事に関しては、EBSから起動するEC2を選ぶ「EBS-backed」のEC2がデフォルトになってから随分経つのに、いったんついたイメージは消えないのだなという感想。記事中ではEBSのことも触れてはあるのだが、EBSから起動できるEC2についてはあえて触れていないように見える。

このように記事が古いだけなのか、「書きやすい」ので意図して残したのかはわからない。率直な私の感想としては、「昔のデフォルトは人々の脳裏からなかなか消えない」ということを改めて感じた。今は「あえてその設定しないかぎり関係ない」と言いたい。

ELBの増強に時間がかかるという記述は中身については私のコメントの通り、ELBの負荷急増が予測されるのであれば、サポートおよびセールスに相談していただきたい。しかしながら、急増するトラフィックのほとんどはCloudFrontやS3へのオフローディングで対応できることを実感している。良い事ずくめなので、構成の見直しを行うのがいいと思う。

本自体はさくさくと読めるものばかりだし、あちこちに散りばめられたそこは違うだろーというところもなくはないのだが、それもふくめて「議論のネタ」となるのは間違いないので、日経システムズを購読していない私のような人は一読の価値があると思う。

via http://arakinotes.blogspot.com/2013/05/awsit.html

CloudFrontのオリジンフェッチは10秒以内のレスポンスを期待している

まずはCloudFrontのFAQページを見てほしい。ここではそれ以外のことを。

最近立て続けに複数のルートで聞かれたCloudFrontのオリジンフェッチ(オリジンサーバーからエッジロケーションへのデータ転送)の細かな点を折角なので書いておくことにする。

ミスした場合は3回リトライする。詳細は、AWS Developer Forums: Cloudfront timeout pulling contents? …を読んでほしいが、まとめるとこんな具合。

  • CloudFrontはオリジンサーバへのリクエストが無反応のときのために3回繰り返す。
  • 二度目,三度目のオリジンフェッチのときはIPアドレスも引き直す。サーバがDNSラウンドロビンを使っているような場合に一台死んでてもこれでカバーする。
  • オリジンサーバが何も返さないならば、CloudFrontも何も返さない。逆ににいえば、503などをオリジンサーバが返すならば、それはキャッシュされる。

レイテンシベースで誘導される。CloudFrontには世界で現在40箇所にエッジロケーションが存在する。日本では東京二箇所、大阪一箇所。場合によっては韓国ソウルやUSのエッジロケーションのほうが近いユーザもいるだろう。

キャッシュはエッジロケーション毎に共有される。エッジロケーションが違えばキャッシュは共有されない。厳密なことを言えば、エッジロケーション内で一定時間内にキャッシュが掘り起こせないときはオリジンフェッチを行う。一旦エッジロケーションにキャッシュされればほぼ待たされることなく共有される。

質問は随時。

via http://arakinotes.blogspot.com/2013/05/cloudfront10.html

EC2およびS3の価格をプログラマブルで計算したい人はJSONをたたこう

AWS の月額費用をシミュレーションする AWS Simple Monthly Calculator は初登場が2007年の6月(たしかそのあたり)。かれこれ6年近くになる。

当初はこんな超すっきりページだったらしい。(白状すると、このバージョンは使ったことがない。2008年夏のUpdateは使った記憶がある)

ということなので情報提供。EC2およびS3の価格は次のURLから取得可能です。

http://aws.amazon.com/ec2/pricing/pricing-on-demand-instances.json

http://aws.amazon.com/ec2/pricing/pricing-reserved-instances.json

http://aws.amazon.com/s3/pricing/pricing-storage.json

 


via http://arakinotes.blogspot.com/2013/05/ec2s3json.html

奥沢さんインタビュー、ナレコムクラウドのスポンサートーク [[JAWS DAYS 2013 Araki room]] #jawsug

2013年春、東京ビッグサイトへ集結せよ!という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group)が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。

荒木が進行した「荒木の部屋・AWSサポート出張所(松井の部屋)」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。

ナレッジコミュニケーションズの奥沢さんにいらしていただきました(youtube)。

ナレッジコミュニケーションズさんでは、受託開発始め、様々な目的でサーバを使っているうちに、管理コストなどを考えてクラウドを使うようになったそうです。2010年に東京リージョンがなかったので一度はAWSを使うのをあきらめたものの、現在はAWSを使ってオールインワンのサービスを提供しています。

ナレッジコミュニケーションズさんは、サイジングの決定も実際に負荷をかけたテストをjmeterなどを組み合わせて測定し、提案しています。また、見積もりの時間が2,3日で求められるような相談も増えてきていて、実際に対応しています。

最後は「AWSが大好きなあなたをお待ちしております」という求人話でしめくくっていただきました。

via http://arakinotes.blogspot.com/2013/04/jaws-days-2013-araki-room-jawsug_23.html

小松さんインタビュー [[JAWS DAYS 2013 Araki room]] #jawsug

2013年春、東京ビッグサイトへ集結せよ!という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group)が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。

荒木が進行した「荒木の部屋・AWSサポート出張所(松井の部屋)」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。

アットウェアの小松さん、JAWS-UG函館支部長(fb/tw/github/hatena: comutt) の登場です(Youtube)。AWSで構築するCouchbase Clusterという話ではじまりました。

DynamoDBじゃないの?と言う話ですが、CouchbaseはAWSとの相性抜群だそうで、問題なしです。Couchbase performance benchmarking by @Altorosによるm1.xlarge上のEC2上ベンチマークを引用し、その解説をしていただきました。99precentileの時でもレイテンシがMongoDBやCassandraと比べ圧倒的に性能が高い結果でした。

もちろん、それぞれ一長一短あるので必ずしもどれが勝者という話ではないのですが、検討の価値はあるものでしょう。このあと、レプリとクラスタリングの解説に行きました。

小松さんには最後にAWSへの注文として、リザーブドインスタンスの6ヶ月版が欲しい、そのせいでRIを使うのを躊躇することがあるとのことでした。

via http://arakinotes.blogspot.com/2013/04/jaws-days-2013-araki-room-jawsug_22.html

小島さんインタビュー、JAWSをどう設計し、そして次の手は [[JAWS DAYS 2013 Araki room]] #jawsug

2013年春、東京ビッグサイトへ集結せよ!という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group)が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。

荒木が進行した「荒木の部屋・AWSサポート出張所(松井の部屋)」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。

JAWS-UGはこの人からはじまった!という小島さんの登場です(Youtube

小島さんの「日本のAWSは個人名を知られてる人が多いんですが、最近ボクのことを知らない人が多いんじゃないですか」「実は3年前一人だけだったんですが」という一言からはじまりました。

当時は今でいう都市伝説が多く、組織がなく、パートナーがゼロ。データセンタが日本にないのもアカンとよばれていました。

そんな状況なか考えた戦略はビジネスのベースを支えていただく器のためにコミュニティを作り、「エコシステム万歳」とばかりにJAWS-UGを立ち上げるにいたりました。

次にJAWSのデザイン秘話が語られました。

JAWSは「ジョーズ」という音を大事にしたことと、ロゴとして日本がすぐに思い浮かぶ北斎の絵をモチーフにコミュニティの方に作成していただいて、結果としてアメリカでもかなり仕事がやりやすくなったそうです。

たしかにこのロゴはすばらしく、支部ロゴも様々なバリエーションができています。

JAWS-UGはツイッターをうまく活用したコミュニティの一つなのは自他共に認めるところです。そんな小島さんがツイッターを活用したのは、どうやってリーチするのか考えたところ、東京以外の方ともうまくコミュニケーションできることとが気にいったからだそうです。そして、ハッシュタグでゆるくコミュニュケーションすることが当時の状況に合致したことがさらに幸いだったという分析でした。

小島さんは、JAWS-UGで人生が変わった人にも話がすすみます。私もその一人ですが、「一歩ふみだすきっかけとしてJAWSにきていただければ」とのことでした。

今JAWSみたいな団体を立ち上げるとしたら何をつかいますか?という質問に対しては、「これはシークレットです!」ということで、小島さんのしかける次の手に注目していきたいと思います。

via http://arakinotes.blogspot.com/2013/04/jaws-jaws-days-2013-araki-room-jawsug.html