ひさびさにブログを書く。やっぱり2009年は会社設立という新しいチャレンジをしたという意味で、大きなターニングポイントになるのでちゃんと振り返っておきたい。

仕事とプライベートが混ざるけどもつらつらと残しておく。

1月

• 1/7 立ち上げから運用まで関わった meet-me のインフラ面、運用面の引継ぎ資料づくり(wiki)を行ってから有給取得スタート
• 1/16 年末から探していた家をついに決めて契約する
• 1/17 2月頭の会社設立に向けて名刺を作り、懇親会に招いてもらい配る
• 1/20 会社設立に必要な定款を作成し提出する
• 1/22-29 紹介してもらったり、懇親会で出会った方々に設立する会社の紹介を行う
• 1/31 トランスコスモス退職

2月

• 2/2 株式会社シェイクソウル(ShakeSoul inc)設立
• 2/3 iPhone 3G 購入 感動する
• 2/4- 今までの人脈を使って会社紹介しに訪問する Maxで4件/日
• 2/11 JTPA シリコンバレーカンファレンス 東京参加者による2回目ミーティング参加
• 2/15 娘の7歳の誕生日 学生時代にバイトしていた割烹料理屋で祝う
• 2/21 オープンソースカンファレンス参加
• 2/25 学びing 講師のクラウドセミナーを聞く この時はじめて Amazon Web Service の存在を知る
• 2/28 iPhone Developer Japan 懇親会に参加 数名の方々と知り合う

3月

• 引き続き人脈のあるところに会社紹介する meet-me時代に関わりのあった CE、ウノウ、ウタゴエ にもリーチ
• 3/15 新居に引越し 神奈川県横浜市から東京都世田谷区へ
• 3/19-23 JTPA シリコンバレーカンファレンス 参加
  • はじめてシリコンバレーを体感する カルチャーショック、日本語圏/英語圏の差の大きさ、シリコンバレーの1つのシステムに対して驚く
  • 具体的なことは svc09++ カテゴリー にまとめている
  • シリコンバレーで働く方々とのパスも作れる VC, Google, Adobe, RockYou, etc…
• 3/28 伊藤忠主催の Puma Family Sale へ行く RUDOLF DASSLER ものが ￥15,000 で買えてしまうことにびっくり もう、店頭で買うことはなくなった
• シリコンバレーで見たこと感じたことを聞きたいという方々に会う 新しく紹介してもらうケースもあり人脈がじわっと広がった

4月

• 4/2- 徐々に具体的案件に声をかけてもらうようになる 受注はなし
• 4/3 仕事がまだ無いことをいい理由に平日ゴルフに行く 数年ぶりにもかかわらず一度も練習に行かず結局、スコアは120以上
• 4/7 シリコンバレーで出会った方と日本で飲む
• 4/11 伊藤忠主催の ADIDAS Sale へ行く puma の時と打って変わってまったく買いたいものがなくすぐ退場する もう行かないと決める
• 4/13- 面識のある人の先にいる人を紹介してもらうような動きになっていく 人脈の拡大につながった
• 4/6- 誘われてシェイクソウル第1号の案件を取り組む
  • 結果的にこの案件と同じような案件は2度とやらないことに決めた シェイクソウルが求める質と内容を満たしてないものは何かが分かったことが収穫
• 4/17 学びing, ハートビーツと顔合わせ Amazon EC2 フルサポートパック の企画をまとめる
• 4/21 IRI-CT と一緒に案件開拓に動く
• 4/22 Amazon EC2 フルサポートパック リリース
• 4/26 やっとテレビが映る 引越してから1ヶ月間テレビを見なかった

5月

• 5/7- 具体的案件がちらほら出始める
• 5/15 CE の社内勉強会で inside meet-me について話してくる 利用者側の情報が作っている側に伝えられてよかった
• 5/19 Amazon EC2 のアプリケーションレベルでのスケーリングを可能にする WAKAME の説明を受けにあくしゅに平野さんと訪問する
• 5/21 会社のWebからコンタクトしてきたある日本のVCの話しを聞きにいってみる
  • 投資を受けてうまく行かなかった場合、最後には VC 買った株を創業者が買い戻す話しを聞いてかなり幻滅した
  • シリコンバレーでの力強い VC とはスタンスも金額のボリュームも全くちがうことを実感した
• 5/22 BPstudy に初参加 技術レベルの高い濃い話しに刺激を受ける 今後定期的に行く勉強会に位置づける

6月

• 6/7 meet-me メンバで豚の丸焼きバーベキューする 嫁と娘も一緒に行く 家族を meet-me のメンバに紹介したのは初めてかも よく焼けていない豚を食べてしまったようで、その夜は大変な事になる。。
• 具体的案件の紹介を受けて、打ち合わせに出たり顔合わせしたり
• 6/26 iPhone 3GS 発売日 Docomo を解約して、予約していたものを取りに行く 以前の iPhone 3G は嫁に渡す
• 6/28 10年ぶりくらいに TOEIC を受けてみる 結果はひどかった。。

7月

• 7/4 弥生会計を買って会計をつけてみる
• 7/8 NTT時代の上司に声をかけてもらって、大学向けクラウド導入プロジェクトを促進してみることを始める
  • 大学のWebシステムに対するコンサルティングを行っている人と知り合う
• 7/10 学びing の mixi アプリゲームの Amazon EC2 でのインフラ構築を手伝う 2つ目の案件
  • この時 boto、rsyslog とかを試せたのはのちのノウハウとして生きている
• 7/14 Amazon EC2 3社共同セミナー開催 シリコンバレーカンファレンス参加者と懐かしの再開 参加いただきありがとうございました
• 7/21 フリービットに日本で立ち上げるクラウドサービス企画に対するご意見伺うを求められる
  • Amazon EC2 のノウハウを持つシェイクソウルとして認知され始めたことを感じる
• 7/22 ネットワーク系SIer に対して Amazon EC2 の説明会を実施
• 7/24 CEに呼ばれて打ち合わせする
  • これが後の長期プロジェクト参加につながる
• 7/28 念願でもあった はてな への対面を行う BGP の話しがメインで結局その時やっている Amazon Web Service についても紹介した
• 7/30 Amazon EC2 の書籍の話しをもらう

8月

• 8/4 CE に誘われたコミュニティサイトの立ち上げ案件に本格的に参加する</p>
  • シェイクソウルとしては3つ目の案件で、半常駐型の時間拘束が長い案件は断っていたが受ける</p>
    • コミュニティサイトの立ち上げはもう一度やりたかった ＋ CEとシェイクソウルとして一緒に仕事したかったことが理由
• 8/5 誘われて皇居1周ランニングに参加してみる まともに走るのは10年ぶりくらいだったので3km走ってギブアップ
  • シューズも買ったし、今後続けてみようと思う
• 8/7 新卒で入社した最初の会社 NTT の研修時代の同期と会う 10年くらいの付き合いだが、自分が変わりすぎていて考え方のギャップが激しいことを自覚する 多分あの頃の自分では無くなっているだろうし、これからも戻ることは決してないと思った
• 8/8 弟家族の家で花火を見る 品川の高層マンションというものに初めて入った
• 学びing の案件で作業しつつ、CE のプロジェクトもハイペースで回して行く 2つ並行は初めてだったが、なんとか時間をうまく使うようにした
• 8/24-30 弟家族の結婚式のためにハワイへ しかし、仕事が区切れずにホテルで有料無線LANを利用しながらSkypeしたり

9月

• 9/6-8 keikubo と開発合宿 だいぶ進んだ、時間を割いてセッティングしてよかった
• Amazon EC2 本の原稿を書く なかなか時間が捻出できずに朝5時起きした
• CE とのプロジェクトは1システムの開発フェーズに入る チームを作って顧客とエンジニアの間に入る動きになる
• 9/12 hbstudy#3 で BGP の話しをする
• 9/16 35歳の誕生日

10月

• CE とコミュニティサイトの立ち上げを継続して取り組みつつ、サービス企画を進める
• 10/24 ハートビーツと新サービスの検証作業実施
• 10/27 Amazon EC2 LAMP スケーラブルパックを3社でリリース RBBTODAY にのり、そこからYahooニュースにものった

11月

• 国内ベンダに Amazon Web Service の利用者としてのコメント伺いに呼ばれたりする
• 11/14 putico(休みの日に集まってそれぞれ思い思いのコーディングをする、Google Waveで進捗とか成果とかを報告する会)#1 自宅で実施
• 11/16 元インテルジャパン CEO 新岡さんと出会う
• 11/18 PACNET の陸揚げパーティーに呼ばれる 5年ぶりくらいに岡田さんとお話する 懐かしかった シリコンバレーでの人脈の接点が作れた
• 11/20 BPstudy#27 で Amazon Web Service について話す
• 11/25 mixi アプリを Amazon EC2 構築する案件をスタート

12月

• 12/3 ポスモを初めて体験する CE の所属チームで実施
• 12/8 学びing の取り計らいで、Amazon Web Service の方に出会う
• 12/12 putico#2 を自宅で実施 ひさびさに自宅で大人数で家族も交え食事をした 楽しかったなぁ
• 12/21-25 mixi アプリ用 Amazon EC2 構築を駆け込みで実施 時間の捻出が難しかったが午前中を活用
• 12/23 初めて会社の年賀状をデザインして印刷会社に発注する
• 12/25 JETRO にコンタクトしてみる
• 12/28 CE にて仕事納め なんとなくスタッフの一員になれている気がする
• 12/30 家族で叙々苑に行く 1年間のねぎらいを込めて
• 12/31 資料を作りが残っていたので、この宿題をやりながら＋twitter の #kouhaku タグを見ながら過ごす
  • それだけでは面白くないものが、twitter を使うとこんなにも楽しくなるのは新しい実感だった

まとめると、

• どうなることかと思った会社は人脈の拡大と会社の紹介を続けてきた結果、ひとまずな規模(だいたい100万/月ちょっと)の売上を上げれるようになった
• 案件の対応は実質3本平行に取り組むくらいが、Maxであることが体験的に分かった
• 理想的には案件は1つの状態＋不定期に1つのパターンが一番安定して時間が作れる
• 詰め込みすぎて時間の捻出が難しいことを経験した
• プライベートで何かを楽しむ時間は少なかったが、それぞれいいリフレッシュになった
• Amazon Web Service をいろいろ触ってみたことが結果として、サービスを企画してリリースしたり、勉強会でしゃべったり、案件になって売上になったり、本を書いたりできてよかった
• 会社を作ったときにやりたいと思っていたことが一通りできてしまった
  • やりたい分野(SIerが好むようなEnterprise案件は行わず、ネットサービスに近いところ)、やりたいレベル(単純な作業実施ではなく、コンセプトの抽出、設計、運用、コスト含めた総合的なスキルが求められる)の条件が揃った案件を取ること
  • 稀少性の高い技術スキルを体得すること 今年は Amazon Web Service が該当した
  • CE と一緒に仕事をすること
  • コミュニティサイトの立ち上げをもう一度やること 1回だけではノウハウと言えないので、2回やってみた共通項をノウハウにしたかった
  • 勉強会のスピーカーをすること
  • 本を書くこと
• 嫁と娘が一年中元気な姿を見せてくれて、それが自分のエネルギーになっていたのがとてもありがたかった
• 来年に向けて大きな動き出しと決断ができたこと 来年に邁進すべき目標が明確になった

というところだろう。

色々あったし、新しい経験もあったけども、自分なりに積極的に動いてみたことは良い結果になっていると思う。逆に意志が薄く少しでも他人の意図に流されてしまうと、良い結果にはならないことを経験した。

全般的には新しい出会いと経験が多くてとても楽しい1年だった。

2010年はひとつ大きなチャレンジをしようとしているので、その手前のステップとしては2009年にやれたことは十分だったと思う。

2010年に何をチャレンジするかについては、状況が固まったらこのブログで報告したいと思う。

ringoさんに「超整理法の極意は新しいもの順なんですよ」と教えてもらったけど、いまいちピンと来ていなくて、読んで理解してみようと思って読んだ。

別に誰のためという訳ではないが、自分の確信を持ったことについてメモしておく。

仕事をする上でどういう人材になりたいか。というようなことを考えることはあると思う。就職活動や転職のとき、最近ではご丁寧にNHKが企業の人事を招いて就職活動ぽいことをする番組があったりして、誰が欲しい人材か。みたいなままごとをしている。

誰しもお金を稼ぐ立場にいれば働けるよう必要な人材と思われたい。という気持ちはあるだろう。

この「必要な人材」とはどうなっている人のことだろうと自分なりに考えて出した答えは、単純明快「必要な人材と思われる人になっていること」だった。

ちょっとこれには解説がいるので説明してみる。

例えば100名くらいの会社があるとしてあなたは属している。会社全体がイメージしづらい時は自分の所属している部署を思い浮かべてみる。

あるとき突然、この組織を半分の人数にする必要が出たとする。今までの仕事内容は維持しなくてはいけない。で、人選して半分にしてみる。さて、その半分の中にあなたはいるだろうか？ん～、入ってそうだな。では、半分ではなくて1/3にする場合はどうだろうか？なんとか入っていそうだ。では、1/4にする場合はどうだろうか？ちょっと厳しいと思うかもしれない。この範囲をどんどん狭くしていって、1/10に入れていればかなりコアな人材になっている人だと思う。

で、結局何が言いたいかというと、この残った人材に入るようになっていれば良いということ。入るためには小手先のテクニックや表面的な振る舞いは意味をなくして、その組織で何を行っているかにフォーカスされる。実際自分が人選する側に立った時には容易に想像出来るけども、とられる側視点でどうしても細々したことにこだわってしまう。

結局、組織で必要かどうかというのは俯瞰して必要な人材と思われるよう振る舞い、スキル、人間性などが総合評価されて判断されるはず。それぞれの割合は均一である必要はなく、技術スキルが飛び抜けて高い人は絶対残る人になるだろう。

この視点は経営者そのものだけど、すごく単純明快だ。

なので、テレビで人事担当者が「熱意が伝わることが大事です」などと言ったりしているが、熱意だけでは残れないのは明らか。組織から見た時の必要な人材のイメージができていないからそういう精神主義的な発言をしているだけに過ぎない。

実際、今は1/10に残っていなくても、1/10に入っていそうな人がメージ出来たらその人のスキルに追いつくように目標にすればいい。で、実力をチェックする時は自分の組織を1/10にして入っていればOK。

人を急激に減らすとかは実際ベンチャーくらいしかないかもしれないけど、大企業で埋没してしまっている人にとって大企業病に染まらないうちにイメージしてみると、自分のスキルアップへの目標が作りやすいのではないかと思う。

この話は、スティーブ・ジョブスのスタンフォード大学でのスピーチのように、今まで行ってきた点と点が結びついて線になってつながっていくように、今まで転職を繰り返して、色々な会社組織に属していた時の経験がつながったような内容かと思う。

今まで何度か参加している BPstudy で Amazon EC2 について話してくれませんか。というリクエストを受けて、BPstudy#27 で話してきた。

持ち時間は90分で大学の講義並みのたっぷりな時間だった訳ですが、なんとかおさめました。

話す範囲はあまり隠すのも変だし、部分的にとどめるのもいやらしいので、素直に自分が今まで AWS を触ってきて知っていることをいろいろ出していこうと思い、対象は広範囲に、でも実践的に動く様子を示すことにしました。

機能説明の後には必ずデモを行い、時間稼ぎ＆実際を見せるようにしました。デモがこけるとすると時間が足りずに最後まできれいに行かない懸念もありましたが、とりあえず全てのデモがつまるところなく見せれたのは個人的に満足でした。

当日の様子は twitter の #bpstudy タグ で見れます。

その時のスライドは以下。

会場の質問内容や様子を見る限り、EC2 でインスタンス起動はさせてみたけどもそこまでの方が多かったのかと思えた。今回、Elastic Load Balancing, Cloud Watch, Auto Scaling など、EC2 の新機能も実践的に紹介出来たので AWS のサービスの幅広さから可能性の大きさを感じて、おもしろがってくれればいいなと思います。

実は、今回のスライドを準備する途中で新たに発見したことが2つあった。

• Auto Scaling に —load-balancers のオプションを付けるとスケールアウトさせたインスタインスを自動的に Elastic Load Balancing の分散対象に追加してくれる
• Elastic Load Balancing の分散対象のインスタンスへのヘルスチェックは、転送先となるポート番号が空いているかどうか。が、デフォルトの内容になっているようだ

今まで不明な点だったので、これは見つけられてよかった。

自分のレベルを一つ上げるのは外的要因の方が起こりやすい。というのを感じてしまった。本当は自分自身の意志で行ければいいけど、甘えが出るからな。

今後も BPstudy は時間があえば行きたい勉強会なので、技術的に濃い刺激を受けたい人は是非 BPsudy へどうぞ。お会いしましょう～

いつ読み終わったのか忘れてしまったのだけど、この日だということでレビューを書く。

兄貴に「これサイコーに面白いよっ！」と勧められた本だった。買う前にアマゾンのレビューを見るとベンチャーとしての文化や考え方が記してあることも読んでみたい部分だった。(ここで言うベンチャーは日本での、ではなくて、シリコンバレーにおけるexitを目指すバリバリのベンチャーのこと)

いつも通り、定期チェックをしにいく。引っ越後だったので、矯正歯科へ行くまでに1時間以上かかる。ちょっと行き来がつらい。

リテーナーを外しても、前ほど動かなくなったと報告したが、先生としてはもう動かなくていい時期と思っているようだ。一般に比べて歯への圧迫が大きいのだろう。

いつも通りでそのまま終了か、と思っていた時に先生から「あと2回で定期チェックも終わりになります」と言われた。リテーナーになってからあと6ヶ月で、まる2年間になるかららしい。どうやら器具を外してリテーナーにに移行したら2年間は見るとしているみたい。

その後は自分でリテーナー続けてもいいし、外しちゃってもいいし決めてください。と言われた。これはなかなか判断が難しい。今は明らかにリテーナーを外すと歯が動いてしまう。あと6ヶ月経ってもそれほど状況は変わらないだろう。

今歯が動いているのは多分2つあって、上の左の歯の間が右に比べて空いているので横方向に動こうとすることと、上の前歯間がきついので前に出ようとする。横に動いてくれるのは隙間を均一にしてくれるので良いし、上下の歯の中心線がそろう方向に動いてくれることになるのでそういう意味でも良い。でも、前に出てしまうのは絶対避けたい。そもそも前歯が出ていたのを直すために矯正を始めたのだから。

今後どう動くかは予想もできないが、リテーナー生活ももう飽きたのでいっそ自分の歯の動くがままに信じてみてもいいかもしれないと、急に寛容に考え始めた帰り道だった。

本日の清算 : チェック料 ￥5,000

ある大企業の人事担当者と話した時にちょっとした笑い話を聞いた。

毎年大量に採用する新入社員の研修は泊まり込みで、男女の宿泊施設は別にしているのだが、まぁ若いということもあって女子の部屋に男子が行ってxxxするみたいなことは毎年起こるらしい。

新人育成の担当者としては、そういうことは起こってはいけないっ！ということで、部屋を見回って見つけた場合は鬼のような形相で引きはがして、女子を帰した後に裸の状態の男子を説教するらしい。

そんなことしなきゃいけないんだねぇ～。とおもしろおかしく聞いた訳だが、その後にそれを自分がやらなきゃいけない立場だったとしたらやれるんだろうか。。と思った。

そんな振る舞い方が自分にできるかなぁ。と考えたらそれは無理だなと思った。そんな状態の男子に正座させてまともに怒る前にその姿を見て笑ってしまう気がした。いや、絶対そんな状況は面白すぎるので笑ってしまうだろう。無理無理。

確かに、新人育成担当としての振る舞い方としては正しいとその会社の中では思われるだろうし、現にそれが仕事になっている。でもそれは本当に自分のやりたいことではないはず。じゃあ、それは何のためになるんだろう？

確かなのは、少なくとも自分のためではない仕事があるということ。会社としての振る舞い方をするために自分を抑えて演技する。

それができるとしたら、素の自分を殺して演技することになるんだろう。そう考えると、仕事のやり方として「自分のやりたいことをやる」の真反対は「自分を抑えて演技する」になると思えた。

いま、会社を作って「やりたいことをやって生活していく」実験をしている自分にとっては「演技する」必要がない。それは、やる/やらないの判断の一つに「自分のやりたいことかどうか」があるから。

サラリーマンを辞めて、一番思ったのはこの「素直な判断」ができていると、余計なストレスがかからない健康的な仕事の仕方ができる。ということ。

この実感が得られたことは、自分の働くという認識を大きく変化させて、確信にできたという意味で、すごく大きい。

ただ、「やりたいことをやる」のは楽ではない。判断の基準が全て自分になるので、自分の責任が全てになる。逆に演技は振る舞い方のお手本があったり、演技できているかどうかは最終判断が他人だったりするので責任がない。特に、大企業はリスクを負わないようにする性質があるので、そもそも大きなリスクは仕事としてない。

大企業に勤めることがステイタスだった時代は、「演技すること=仕事すること」だったのだと思う。現にNTTをいた頃を思い返すと年功序列や組織間など環境に制限があるので、常に演技しなきゃいけない状態だったかと思う。

今はやりたいことが仕事としてやれる環境が確かにある。今というより、本来仕事をするということは「やりたいことをやる」が基本だった、と言ってしまっていいと思う。

日々、演技することに一生懸命になっているとしたら、それをやめて、本当に自分のやりたいことはどんなことだろうと考えを巡らす時間を作ることをした方がより健康的だし、発展的になれる。自分が組織に埋没していると思う人は是非やっていいと思う。

一つの話から、そんなことを考えてしまった。その他にも、そもそも新人だから、新入社員だから何かを与えなきゃという発想すら必要なくてよいではないか。ということとかも思っていたのだけど、それはそれとして別の機会に書いてみることにする。

Amazon EBS の特徴はマウントしたボリュームに対するスナップショットが取れることだろう。boto を使って簡単にバックアップ環境を以前に作業したメモを残しておく。

boto は python のライブラリで、Amazon EC2 のインスタンス上から AWS の API を操作できる。boto の機能は多種であるが、今回は EBS の API を操作して、毎日1回スナップショットをとって5世代分保存する設定をしてみる。

• botoのページ: http://code.google.com/p/boto/
• 参考にしたURL
  • http://2606-36j.blogspot.com/2009/03/amazon-ebs-snapshot.html
  • http://emutyworks.com/?Amazon%20EC2%2FEBS%E3%81%AESnapshot%E3%82%92%E5%AE%9A%E6%9C%9F%E7%9A%84%E3%81%AB%E5%8F%96%E3%82%8B

構築手順

1. boto インストール

• pythonで動作するのでインストール

あるパネルディスカッションを聞いた時にどうも面白くないと思った。話している人たちは知識も豊富で、それなりな地位の人たちらしいが、どの人が話す中身にも興味をそそられない。

話しているテーマは決して古くなく、先端的でチャレンジングであるのだが、なぜ自分がそこまではっきり思ったのか、もう少し具体的に理由を明確にしたいと思った。

少し考えてみていくつか理由を見つけてみた。

個人が見えない

事情の説明が多く、その人自身が何を実践して、何をつかんできたかが分からなかった

チャレンジしていない

チャレンジングなことをしているのに小さな視点で難しいですね。みたいな結論になっていた。もっと大きな夢を実現しようといているのに、その夢に邁進する意義があまり見えていないようだった

組織を主体にしている

組織は個人の集まりなのに、組織に主体があるような言い回しをして人としての主体性がぼやけていた

客観的視点の説明が多い

事例の説明だけはどうでもいい。その上でその人が何をしたのかが大事なはず

優等生過ぎる発言

良く言えば無難、悪く言えば何も生み出せない

日本inside

ワールドワイドな視点が薄い。海の向こう側で起きていることにもっと焦っていいはずなのに、事情が自分の身に受け入れられていない

Open への信頼が足りない

Open になることを未だに信頼し切っていない

これらの理由から、自分が何を求めているのかもう少し考えてみた。

人の話を聞く時に気にしていたのは、「その人自身がどんな経験をして、それを通じてどんな考え方を主張するか。」だけかと思う。

その人自身にフォーカスすることが重要で、地位や組織というのはほとんど意味がなくなる。結局組織と言っても人の集まりなのだから、その人が何を思うかに依存すると割り切っている。

客観性を持つのはある程度重要だが、情報の収集は Google がやってくれるので、状況報告だけを話すというのは全く価値がなくなるし、それに時間を割くのは全くのナンセンスだと思っている。

昔は自分も学生時代には優等生発言をまねて振る舞うことが良しとされていたので、昔であればその発言を聞けたかもしれない。でも、時代は変わり考え方も大きく変わった今思うのは、その人自身の経験、主張がちゃんと伝えられることだけで良いと思っている。

自分の考え方は大きく変わった。自分の会社をやるようになってますますこの主体性へのフォーカスと実績主義の傾向は強まっていると自覚する。

何をしてきたか、何を生み出せるのか。はっきり自分を語ることを当たり前のようにしたい。

Amazon EC2系の記事を書く際にちゃんと動く内容を示さないといけないと思い、実際動作させながら確認していった。その中でも Amazon CloudFront のスループット測定はデータとしてちゃんと取れたので、導入効果が分かりやすかった。

実際どれくらいパフォーマンスに差が出るのか、ファイルのダウンロードのスループット結果は以下。

• ダウンロードに使ったファイルは “Office2004-1154UpdateJA.dmg” で 9.8MB ほどのファイル
• Amazon S3 上の “test” bucket 上にファイルを保存
• “test” bucket を CloudFront に適用させる
• 割り当てられたダウンロード可能なサーバのそれぞれの FQDN は以下
  • オリジンサーバ : hironobu-bucket.s3.amazonaws.com</p>
    • Region: Us-East なので、日本からだと太平洋を渡って、アメリカをwestからeastまで横断する経路になるはず
  • キャッシュサーバ : dql6mokzq0d1p.cloudfront.net
  • オリジンは ****.s3.amazonaws.com, キャッシュサーバは ****.cloudfront.net という名前になるのが特徴
• Mac からそれぞれのサーバの URL に対して curl コマンドでダウンロードする
• 3回ほど測定

オリジンサーバからのダウンロード