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回ほど測定

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

お台場ガンダムを遠目に拝んだこともあり、タイトルが影響されてしまっていますが、まぁ気にしない。

2009年の夏は非常に忙しかった。忙しいという言葉を使うのは、パフォーマンスの低い人の良い訳になりがちなのであまり使いたくないのだけど、忙しいが一番イメージと合っているのかと思う。

2009年7月から9月にかけて何があったか、プライベートと仕事を混ぜてあげてみると、

• 7月中旬～8月下旬 : Amazon EC2 上での Web サービスのインフラ構築案件
• 7/28: はてなでBGPの話をしてきた(それ用にスライドを作った)
• 8月頭～現在 : コミュニティーエンジンからお呼びがかかって、コミュニティーサイトの立ち上げプロジェクトに参加開始
• 8月中旬 : 紹介してもらった顧客からコンタクトがあって、ヒアリング＆コンサルティングの提案書作成と提出
• 8/24-30 : 弟の結婚式参加のためハワイに一週間 完全に仕事から離れられず、ホテルでメール返したり、Skype したり
• 9/6-8 : クボケーくんと新規サービスのアイデア詰め合宿
• 9月中旬 : パートナー顧客への提案活動再開、訪問したり見積り作ったり
• 9/12 : hbstudy#3 で BGP の話をする(デモの環境つくったり)
• 9月下旬～現在 : 本書いている

こういう感じだった。

7月下旬から9月中旬くらいは自分の予測しないことが色々と起きて、平行して進んで、それぞれのリミットが少しずつずれているので1つ終わったら次に取りかかって、その間にプロジェクトやら案件やらが進行させていって、、、という感じでかなり色々なことを同時進行させていた。夏休みも体を休めるというよりかは、せっかくハワイ来たのだから予定をいかに詰め込むか。みたいなノリで終わってしまったし。今は終わったものがあるので、だいぶ気持ち的に落ち着いて、やっとちょっと先のことに取り組めるようになったので振り返るためにこのエントリーを書く気になった。

自分の予測しないことというのは、周りから突然声をかけてもらって話が舞い込んできてたようなケースなのだけど、面白いことにその内容は自分自身も望んでいるレベルだったり、やりたいことだったりしていたので、自分としては突然にビックリしつつも、ありがたくやらせてもらっている。

コミュニティーエンジンとは是非一緒に仕事をしたかったし、meet-me の立ち上げ経験を生かしてもう一度コミュニティーサイトの立ち上げをやりたかったし、Amazon EC2 の案件はやりたかったし、いつかは本は出したいと思っていたし。それらが一気に出来るようなお誘いばかりが来た。

これは不思議なことだなぁ。などと思っていたら、前に読んだ本よりこれこそが「抜擢される人脈力」なのでは？と思えた。

会社を作ったちょっと後くらいに「抜擢される人の人脈力」は読んでいて、自分のような小さい規模の会社が仕事のレベル落とすことなく上げ続けていこうとする時に、人脈力を活かしてやりたい仕事に抜擢されるシーンを作っていきたいと思っていた。

実際、会社を作った今年2月からの半年間は紹介も含め、色々な会社に会ってシェイクソウルという会社を知ってもらい、やりたいこと/やろうとしてることを話してまわった時期かと思う。

それが、今になって話した人たちからシーンにあった抜擢をされ始めているのかと思った。それだけ会社を知ってもらう人たちの数が増え、話がくるパスが多くなったことの現れだと思うし、シェイクソウルのレベルへの評価もそれなりにしてもらえていたことがあったからだと思っている。半年間はかかったが、それなりにちゃんと実ったという手応えも得られてよかったとも思っている。半年間作ってきたのは、この「抜擢される人脈力」なのだと思いたい。

今回は忙しいながらも良い状況が生まれたが、今後に対してすでに課題も感じている。

• 抜擢されるシーンが今後も継続的に生み出せるのか
• 抜擢は結局受け身なので、自分の望んだタイミングで行うにはどうしたらいいのか
  • 今回のように色々集中しすぎると1つ1つのパフォーマンスの質がどうしても悪くなってしまうから
• 抜擢されるかどうかは結局確率論になるので、パスを増やし続ける努力は必要になる
• 最終的にはランニング的な売り上げを得られるモデルにしたいが、スポット的な抜擢からどうやって移行していけるのか

これらは本にきれいに書いてあったことではないので、模索しつつ進めて行くことになるだろう。

しかし、2009年夏は今までにない1ステップ上のフィールドに立った過ごし方が出来た。来年の夏はもう1ステップ上がれるだろうか、どのような過ごし方になるだろうか。自分のちょっとした未来に対して楽しみになってきた。

hbstudy#3で話した時にデモした、Amazon EC2 上で BGP peer を張る環境の作り方をメモしておく。

構成情報

環境は以下、

• EC2 の instance は CentOS5.0(Final)
• Quagga(旧Zebra)を使う

構成は以下、

• instance 2つを立ち上げる
• Quagga 上で zebra, bgpd を起動
• AWS 内の private network 内部で BGP peering

instance 1 側の設定内容

interface ip address : 10.254.202.228
AS65001
広報するprefix: 10.1.0.0/16、10.11.0.0./16、10.111.0.0/16

instance 2 側の設定内容

interface ip address : 10.209.162.213
AS65002
広報するprefix: 10.2.0.0/16

BGP的な設定内容

2つのinstance の interface ip address が異なるネットワークになるので、EBGP multihop を設定
route-map を使って Local Preference、MED、Community を付けてみる

確認内容

peerが張れているか
広報されている経路情報が route-map で指定しているものかどうか

構築

CentOS だと yum で quagga がインストールできるので、簡単にすませる。

最近、仕事でお世話になっているコミュニティーエンジンの ringo さんと打ち合わせの帰り道での会話。

• d_sea : プロジェクトマネージャ(PM)って、今までの経験上、「この人すばらしいPMだ！！」って思った人は一人もいないんですよね～
• ringo : 僕もそうだなぁ。。。
• d_sea : そう言えば、これができれば PM としてOKという明確なものがないですね。スケジュール管理だけではないし、会議に出ていれば良い訳でもない。実は PM って、イメージだけの言葉なのかも。。。
• ringo : それはおもしろい！！PM という仕事の実体は実はないかも。

こんなことを話した訳だけど、ちょっと振り返っても実はかなり的を得ている気がしている。

ここ3年くらい前から確信していることとして、「平均的なスキルを持った人が20人いたとしてもできないことがあって、スペシャルな一人がそれをできてしまう世界が確かにある」ということ。

これは特にネットのサービス作りで顕著な気がしていて、スキルの高い最小人数ですごいパフォーマンスで作り上げるのが一番早いという結果が出ている。あまり日本では表に出ない事実かもしれないけど、結果を残せているサービスには必ずそういうスペシャルな人がいるはず。

そういう現実がある一方、この PM とか PL とか言う響きは複数人で行う際に前提とされる象徴的な言葉かと思っている。

PMとかPLだから偉い。みたいな印象が結構強くって、あとのメンバはそれに従う歩兵みたいな感じがする。本当は偉いとかはプロジェクトを取り組む際に全然意味をなさない項目なのだけど、妙にその印象が強くついてしまう現実はあるかと思う。

その偉い PM が実は何ができれば良いのかの定義がなかったことに気づけたのはすごく面白かった。

もう少し考えると、集団主義的な発想で解決する時に PM がコミットすべき TODO が実は決まってないということは、人の数はそれなりにいるが機能してない人が出やすくって、しかもそれが偉いと思われやすい PM だったりするのはかなりのクリティカルポイントだと思う。

自分の経験上、Enterprise SI の SE をやっていた時に必ず PM とか PL を立てて案件を取り組んでいたのだけど、最もパフォーマンスが悪かった(案件に対して直接的に推進する力になれていない)人は PM だったりする記憶がよみがえって、つじつまがあった。

別に集団主義を否定している訳でもなんでもなくて、ネットの世界で新しいアプローチをしようとした場合にはムダとかパフォーマンスをしないとかはいらないことなのは明らかなこと。そこで集団主義で複数名で解決する手法をとるにせよ、ちゃんと自分の役割や TODO くらいは明確化してないと、どうにでもなってしまう危険性を元々はらんでいるということを分かっておいた方が良いと思った。その原因が偉いと思われて気を良くしている PM の機能不全だったりするとプロジェクトとしては本当に不幸な自体になる。

今回は今思う自分なりの確信になったのだけど、今後自分が本当にすばらしいPMだ！！と思える方に出会えたら、この確信はまた変わるんだろう。

その前に仕事のやり方が全く変わって、オンライン上でそれぞれが流動的に関わり合いながら、完全にフラットな体制でプロジェクトを取り組むことが当たり前な世の中になっているかもしれない。

自分としてはそうなってくれる方が面白いし、実際その兆候は現れていると思っている。

ハートビーツさん主催で行われているインフラエンジニアのための勉強会 hbstudy の3回目で、BGP の話をしてきた。

私が1つ目のネタで、2つ目のネタはTOMOYO Linuxの紹介で、NTT-DATA 沼口さんだった。

タイトルは「BGPのお話」。思いっきりネットワークのみの世界の話なのと、BGP自身なじみがないと思ったので、どの程度伝わったのかはよく分からずとも、とりあえず概要から運用的な話までしてきた。

勉強会中の会場の様子は twitter で結構流れたので、そちらでも結構反応が分かる。

このスライドは以下。

質問では経路乗っ取りについてが結構多かった。統一されたシステマチックな仕組みがあるようなイメージを持っていたようだったが、「インターネット運用は性善説に基づいている」ことがもう少し説明できれば良かったかな。

デモでは Amazon EC2 上で instance 2つに Quagga 入れて bgpd 動かして peer 張るところまで見せたが、これだけだとルーティングしていることにはならないので、instance 7つくらいで AS path 長を持たせた構成を作ってみたら実践的になるかと思うので、やってみようと思う。

EC2 上での 構築と動作させてみたことについては別エントリーでこのブログでまとめることにする。

実際BGP運用をしていたのは4年以上前だから、自分の記憶が頼りだった部分もあるのだが、それなりに覚えていたし、考え方の概要は忘れていなかったことが自覚できたのは自分なりの収穫。経験したこととかを振り返ることもできたし、スライドとしてはBGPを概要からまとめられたそれなりな資料が作れたので良い蓄積ができた。

まだまだ BGP 設計とか体制作りのコンサルティングはできる感触を得られた。

勉強会には初参加の人たちも増えているようで、3回目にして hbstudy の認知が広まってきている感じがした。

今後勉強会で聞いてみたいネタとしては、

• Apaceh にすごく詳しい人</p>
  • 特に proxy とか、proxy_loadbalancer に詳しい人とか、運用ノウハウに長けている人
• MySQL にすごく詳しい人
  • tips 満載な人
• モニタリングツールとか設定内容
• たくさんのサーバの設定内容を同期させるツールとか、tips とか

かな。基本的にみんな使っているけど、あまり自信を持って動かせていないような気がするポイントかな。(自分自身がそうだったりする。。。)

hbstudy はインフラをちゃんと学ぶ場としてはおそらく他になく貴重だから、今後も濃く良い交流が生まれる勉強会であってほしいかな。

ということで、インフラを学びたい人は hbstudy へ一度ご参加ください。

今年3月のJTPAシリコンバレーカンファレンスで知り合った id:keikubo と夏合宿してきました。

目的は二人で思案中のサービスについてさらに具体化させるため。今までメールでのやり取りだけでイメージは作ってきたが、システムのアーキテクチャだけでなく悩みどころのポイントもあったので、ちょうどいいタイミングだった。合宿の提案はクボケーくんから以前にあって、必ずやりたいと思っていたこともある。

そんな自分だったのだが、合宿の直前に仕事がかなりクリティカルな状態になってしまい、考えとか議題をまとめるような準備はほとんどできなかった。しかも、逃げ切ったつもりが逃げ切れなくて、仕事の電話が何度も鳴ってしまい、本当に申し訳なかった。。。

合宿の様子をざっと紹介。

合宿に使ったのは、川崎グランドホテル。宿泊＋会議室利用のパックがあり、東京よりも全然安い。

一番小さい会議室を予約してもらったのだけど、二人には十分すぎる広さ。

なんか面接が始まるような感じの机とイスの配置。。

ホワイトボードが2つあるのがうれしい。1つは紙に印刷できるやつ。

電源タップ、HUB、無線LANターミナル、LANケーブルがそろっていて、ネットやPC向けの設備的には何も持って行かずに大丈夫でした。

ネット環境は会議室では有線と無線。宿泊部屋では有線のみ。が提供されていた。

宿泊の設備は古く、昔ながらのビジネスホテルという感じ。ここら辺は期待しては行けないし、しょうがないところ。

これは最後の夕飯で、豪勢かつおいしかった！

最後の夜はビールやらつまみやら買ってきて、飲みつつ話しつつな感じで過ごしました。

こんな感じで、、

ビールだらけw

実はこういうサービス生み出すような合宿は始めてで、どのくらい進められるのか全く未知だったけど、形になりそうなところまで見えたのは大きな収穫だった。合宿効果すごい。これは癖になりそうw

ただ、何も持ってないと何も進めない訳で、おそらく二人のサービスへのイメージとか今までメールで話し合ったことがベースにあったから考えられたし、何しろ二人のパフォーマンスのレベルも良かったことが大きいと思う。

しかし、このタイミングで合宿が持てたのは本当に良かった。宿泊先を調べたり予約もしてくれたクボケーくんに感謝！！

確実に大事にしたいプロジェクトになっているし、次のマイルストーンに向けて今後はもう少し自分のパフォーマンスをあげて望んで行きたいと思っている。

今年の夏休みは弟の結婚式に参加するためにハワイで丸々1週間すごした。嫁と娘も一緒に家族で初海外の初ハワイだった。

気づいたことをメモ

• 日本語が通じる場所と通じない場所があった
• 英語をしゃべっても通じないことが多かった。カタカナ英語のほうがいいのかな？
• ファミリー向けホテルの多く立ち並ぶエリアは空港からタクシーで30分くらい。高層な建物ばかりで、ゴミゴミしている
• リゾート地はさらにタクシーで20分くらい東側の高級エリアで、ビーチの規模はそれほど大きくないが低層な建物が多く静か
• 少し内陸に行くと土地が余っている田舎町になる
• ハワイのアロハシャツのサイズは大きい。たくさん食べてアロハ着れるくらい大きくなれよ。ということらしい
• 思ったよりも町が整備されていて、建物も多い。もっと自然があるかと思ったけど、予想よりもゴミゴミしていた。

思い出に写真をいくつか。

とりあえず、家族で海外旅行しても娘は大丈夫な年になったなぁ。いろんな国に家族でいくのも良い気がしてきた。

スポーツ選手がこの本を読んで試合に臨んだら結構良い結果が得られた。というような話を聞いて買ってみた。