最近の投稿
人気のページと投稿
アーカイブ
| 月 | 火 | 水 | 木 | 金 | 土 | 日 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | |
debiancdn
AWS, Content Delivery Network and Debian
マルチクラウド戦略と私の新たな挑戦
投稿者: : 2025/02/01
「AWSが大好きで、大好きすぎるのに日本にないものだからクラウドをつくる」
というようなことを2009年に Lightning Talks (2009-07-18) – 日本Ruby会議2009 に参加したときに懇親会で話をしたことを思い出しました。
そんなわけで、 超絶久しぶりにブログに記事を書くことに。なんと10年ぶりだなんて驚きです！ こんにちは、あらき(X: @ar1)です。
経歴は、LinkedInにほぼ載っていますのでご興味ある方はコチラをどうぞ。
知っている人は知っていたかもしれませんが、AWSで13年と8ヶ月働いたことをお伝えします。 AWSのSAとして、まだまだやれることがあると思う中での決断となりました。そして、さくらインターネットに来てから半年が経ちました。その区切りとしてこの記事を書きます。
冒頭に書いたように、自分は過去に2回ほどクラウド作りを試みたことがあります。
1度目は、3社めの研究所にいたときで 、このときはAWSに正面から挑んだものの、ビジョンと実行力に負けてしまいました。 2度目は、会社でAWSを使うことを止めた(その事業は終了した)ので始めたこと。 そんな大層なものではなく、数ラック規模のプライベートクラウドのようなもの。VLAN+VRF+iSCSI+KVM+Anaconda+Puppet..みたいなものであった。 正確にはこの大まかな設計をしたところで、AWSからオファーをもらって転職しました。
AWSでの仕事について
AWSのソリューションアーキテクトは多くのアーキテクチャに触れることができます。 特に初期のころは一期一会のお客様が多いこともあり、すべてのミーティングで新しいアーキテクチャ設計をしていました。 さすがにこれは極端ですが、AWS社内では定期的にインダストリーを跨ったさまざまなお客様の構成を共有する会があり、社外ではJAWS-UGなどもあります。
自分は、ネットワーク、コンテナのスペシャリストSAとしても活動をしていました。 そこまでではなくても、興味のあるサービス領域にフォーカスして、準スペシャリスト的な活動をすることもできます。
そんなこんなことは、「元祖SAとしての荒木さんのクラウドとの出会い、クラウドがお客様のサービスにもたらすメリット、そして荒木さん考える今後のクラウドについて」、と言う記事(とビデオ)が
クラウド人図鑑 エピソード 7 – アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 荒木 靖宏さん – Momentoにあるので、時間が許せばみてほしいです。
すくなくとも、AWSのソリューションアーキテクトは楽しく、意味のある仕事だと確信しています。
興味のある人は求人ページとかをみてほしいです。
荒木はなぜAWSをやめることにしたのか
AWSでやることはやったんだろ、ということをいわれることもありましたが、正直そんなことはないというのが正直なところです。そして、さくらインターネットの話を聞く機会を得て、本気度を感じました。 (失礼ながら、それまではスルーしていました)開発計画や、技術要件を越えた話、営業戦略なども含めて話をすることができました。 そして、自分のギアを変える機会だと感じました。
おわりに： マルチクラウドをつなぐサービスをつくっています
さくらインターネット、デジタル庁より「ガバメントマルチクラウドネットワーク（GMCN）の設計開発等業務」を受注 というニュースが昨年末に発表されました。
様々なチャンスがあり、案件を取りましたので、メインメンバとして実装している最中です。 入札案件だったわけですが、他社ならもっと大人数だろうなあと思いつつ、本気でメインで仕事中です。
他にも様々やってますし、やることは多岐にわたります。そしてやりたいことも溢れています。 新サービスの企画書を、Amazon っぽくPR/FAQを書いていたりもします。
大変なことも多いのは間違いありませんが、また一つ成長できるだろうと確信しています。
いろいろあって、半年たってしまいました！
最後までお読みいただき、ありがとうございました！
SCSKのPrimeCloud Controllerのオープンソース版。VA Linuxが噛んでる割にはライセンス記述がお粗末な件
投稿者: : 2014/02/25
複数クラウドを統合管理可能な「PrimeCloud Controller」のオープンソース版を提供開始｜SCSK株式会社という記事がでていた。http://bit.ly/1fzc6bM
それはいいのだが、GPLとは書いてあるのにGPLのバージョン番号すら書いてない。
メールアドレスと名前を登録しないと情報にアクセスできないらしいので、アクセスボタンをおしてみたら、Google docsだった。
ご提供いただきました内容は、SCSK株式会社からの「PrimeCloud Controller」に関するご連絡およびサポート並びに新製品のご案内のために
利用させていただき他の目的には利用いたしません。
また、ユーザ様の個人情報は、VA Linux Systems Japan株式会社との間で個人情報保護のための
秘密保持契約を締結のうえ提供いたします。
GPLなのにGoogleの規約をOKにしないと情報にタッチできないっておかしくないですかね。普通ならスルーですが、VA Linuxが絡んでるので残念感。
http://bit.ly/1gxPCWt に瀧澤さんの収録論文がある。
オブジェクトストレージのベンチマークツール、COSBench
投稿者: : 2013/12/22
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 State: finished
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 |
おわりに
「パフォーマンス計測」という意味で「ベンチマーク」という言葉が使われる事自体に違和感を感じるのは私だけでしょうか。ベンチマークは比較の対象があってはじめてベンチマークであるはずなのですが、巷では比較対象がなくてもその言葉が使われることが多いようです。
本記事では巷で使われる「ベンチマーク」のほうがキャッチーで、ググラビリティ高いためにこの言葉を使いました。
オブジェクトストレージのベンチマークツール、COSBench
投稿者: : 2013/12/22
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 State: finished
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 |
おわりに
「パフォーマンス計測」という意味で「ベンチマーク」という言葉が使われる事自体に違和感を感じるのは私だけでしょうか。ベンチマークは比較の対象があってはじめてベンチマークであるはずなのですが、巷では比較対象がなくてもその言葉が使われることが多いようです。
本記事では巷で使われる「ベンチマーク」のほうがキャッチーで、ググラビリティ高いためにこの言葉を使いました。
2013年のAWSアップデートを料理にたとえるという難題へのチャレンジ。
投稿者: : 2013/12/17
2013.12にCookpadで行われたクラウド女子会。2013年のAWSアップデート10個を料理にたとえてみました。
異論、反論があることは承知しておりますので、ぜひご意見ください。
「俺ならもっとカッコイイたとえするぜ」というシリーズもいいかもしれません。
OpsWorksで動かすルールをvagrant+chef soloを使ってローカルでも試せるようにする
投稿者: : 2013/12/06
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むけの設定には差異があるので、ちょっとしたコツが必要になります。
- ec2の代わりとしてvagrantの中でUbuntuを動作するようにする。
- OpsWorks代わりのchef solo環境をlocalに用意する
- 設定(site-coolbooks)はbitbucketに配置する
ここでのポイントは、手元につくったChef SoloはあくまでもOpsWorks代わりをさせるためであり、手元のChefSoloには最低限の設定ですませること。
ちなみに、bitbucketは無料でも秘密レポジトリを作れるので、OpsWorksむけにはgithubよりも楽だと思います。
これから書くことはこんなかんじ。OpsWorksの進化はきっととまらないので、今の時点での私のおすすめってことで！
vagrantのインストール¶
vagrantは
http://downloads.vagrantup.com/
から、自分の環境にあったものをインストール。
昔はRubyGemをつかってインストールしていたが、今は違うので素直にパッケージを使うべきでしょう。
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環境の用意¶
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
- vagrant-ubuntuの中にchefが用意され、
後に
knife solo cook vagrant-ubuntu
を実行すれば、
- 親レポジトリの nodes/vagrant-ubuntu.json が読み込まれ、
- その結果、recipes/default.rb を実行させることができる。
できあがりました！あとはやるだけ！
via http://arakinotes.blogspot.com/2013/12/opsworksvagrantchef-solo.html
喫煙対応レストランにはJTからお金だしたら？
投稿者: : 2013/11/03
レストランにおいて、喫煙者は優遇されている。タバコの持ち込み代かからないことが先ずものすごい既得権益だと思う。
過去にはタバコは成功者であり、金を消費するアイコンとして機能していたんだと思う。その流れで現在でも喫煙者に便宜をはかる店が多いんだと思う。それはいい。
しかし、タバコを吸わない人がもはや主流であることを考えると喫煙しない人の財布から所得移転しているように思えるのがいただけない。
そこで、こんな対応できないだろうか。
- 喫煙する人からキッチリお金をとる。タバコの持ち込み代をもらうか、タバコを堂々と売る。
- 喫煙対応している店には、JTから店舗改装費用を支出させる。JT推奨の店として、ミシュランガイドみたいなのを作る。
タバコを吸える自由のないような国には住みたくないので、法律で禁止するようなことはあって欲しくないが、その自由を維持するためにほかの客や、店側に一方的に責任を添加するのには賛成できない。
エンジニア採用ってむずかしい。
投稿者: : 2013/11/03
見つからないエンジニアを探し出す技術：なぜ，エンジニアの採用は難しいのか？｜gihyo.jp … 技術評論社というWeb連載が私の周囲だけかもしれないが、軽く話題になっている。この連載は「エンジニア出身の採用担当者」ならわかることだけど、そうでない人事部の人にはわからないことを教えてあげる、というスタンスで書かれているように見える。定義とターゲットがはっきりしないのでなんとも言えないけれども。
実のところ、エンジニアがあきらかに採用に関わっている会社でも実際は悩みまくっているのが本当のところ。自分も下手すると週に10回くらいは普通に面接して、最後のジャッジにも関わっているので関心のあること。まだ３回目なのでどのように発展するか楽しみである。
一方で、採用される側として見ると、それはそれで面白いことが書いてある。第3回には、勉強会を開こうにも場所を貸してくれない話が書かれている。「次にどういう行動をとるでしょうか」というのがあるあるネタがありました。また、第２回にはこんなことが書いてあった。
CodeIQのプロデュースを始めて驚いたのは，エンジニアの間では勉強会が盛んなことです。エンジニアはとにかく勉強会やカンファレンスやミーティングやセミナーや，あれこれ理由をつけ，集まり，そして学ぶということを繰り返していることに気がついて，とても感心したものです。
たとえば，営業マンが集まってセールススキルを磨き合うという勉強会はゼロだとは言いませんが，とても少ないと思います。総務の担当者たちが集まってスムーズにレイアウト変更をするためのセミナーを頻繁に開いている，という話も耳にしません。そう考えると，エンジニアの皆さんは，他人と触れ合うことで，自分のスキルを客観視する機会に恵まれている，と言っても良いでしょう。
これらを見て思い出したのは、同僚の松尾さんの寄稿。
非エンジニアCEOのためのエンジニア採用５つの鉄則【AWSアーキテクトが教える採用・マネジメント術】 | Find Job ! Startup
エンジニア採用の５つの鉄則を教えて頂けるのはアマゾンデータサービスジャパンの松尾康博さん。 松尾さんは現在、アマゾンウェブサービス（AWS）のソリューションアーキテクトとしてエンジニア採用に携わっていますがスタートアップの経験もあり、元々マイネットジャパンでCTOを務めていました。スタートアップの採用で悩んでいた松尾さんに、５つの鉄則を教わってきました。
■ 優秀なエンジニアを採用するための５つの鉄則
１．欲しいエンジニア像を明確にしよう ２．エンジニアを理解しよう ３．採用方針を決めよう ４．エンジニアと出会える勉強会に行こう ５．採用後はきちんとマネジメントしよう
この連載が意味ある形で深堀りされていくことを願ってます。
AWSバッドノウハウカンファレンスの必要性を訴えて来ました
投稿者: : 2013/08/06
多く人がすでにAWSクラウドデザインパターン(CDP)を活用しています。CDPこそがAWSを使う目的とまでは言わないにしても、パターンとしてまとめられた体系の上であれば安心してシステムを作れると考えている人は多いのではないでしょうか。
それが証拠に、AWSのCDP関連書籍は、Webデザインのカテゴリで１位（平成25年8月6日現在）でした。
CDPがそのwikiで整備され、公開されてから１年半近くがたちました。日進月歩のこのクラウドの世界で、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でした。会全体の概要はしんやさんのレポートをご覧いただくとして、私の発表について説明することにしました。何しろ今回の私の発表は資料を見ただけではさっぱりわからないので。
cdn.debian.netの中身と開発計画を大統一Debian勉強会でしゃべってきた
投稿者: : 2013/06/29
cdn.debian.netの中身をきちんと説明したことがなかったのでやってみたのだが、５分では短かすぎた。
- 多くの人に興味をもってもらえそうなことを前に持ってきたのはいい（たぶん）
- 開発協力者に対してちゃんと説明しなければならない後半が飛ばしまくりになった。
今日はcdn.debian.netのRuby2.0対応をしていて微妙に時間をつかった。しかも途中。。
via http://arakinotes.blogspot.com/2013/06/cdndebiannetdebian.html
debiancdn 