ネットに関わっていると言っても internal/external で全く違うと意識した方がいい

あるサーバメーカの方に聞いたお話の内容が、結構現状のネットを中心としたビジネスの特徴を明確化している気がしたのでまとめてみる。

そのメーカではインターネットを使ったシステムは internal と external の2つの特徴に分けられて、その2つは全く考え方とアプローチが異なるためにそれぞれに対してマッチするサーバを開発しているということだった。

それぞれの特徴をまとめると、

  • internal とは</p>
    • ITを業務で利用する企業内IT、業務ASP的なシステム
    • 利用者はその会社の社員でシステム責任者は情シス担当者
    • SIer にお金を払って作らせるケースが多い
    • 信頼性やセキュリティの意識が強くそのためのコストはいたし方ないという考え方
  • external とは
    • みずからサービスなりを提供している形態、サービスプロバイダやインターネットサービス運営会社
    • 利用者は不特定多数のコンシューマで会社としてサービス提供している
    • 自分たちで開発、自分たちで作っちゃうスタンス
    • なるべくベンダ異存のないプラットフォームを好む
    • なるべくお金はかけたくないしそもそも最初はお金持ってない

というお話で、external 側の消費電源やスペースへの要求レベルが高く、今までちゃんと提供できていなかったので、そこをターゲットとしたサーバを作ってますとのことだった。

自分としては internal は社内で使うシステムのサーバを IDC に置いて、firewall をきつめに設定して社内からのみアクセスできるネットワークを作って業務中はアクセスあるけど、お休みの日は使われないような運用をイメージした。一方、external ははてな、Yahoo!やGoogleなどいわゆるコンシューマを相手に24時間ネットサービスを提供し続けているところとイメージした。

自分の中では何気なく分けていたのだけどそれを明確化していて、しかもすでに戦略を打っているところはさすがメーカ、手堅いな。と思ったところだった。

その後、自分なりに反芻してみるとこの分け方はシステムの特徴だけにとどまらず、作ることに対する文化そのものも異なることに気づいた。結構肝なのがこの2つは同じ IT というジャンルにまとめられてしまって、働いている人たちも混同していて「ITやってます」とか言ってしまっていて、分ける意識がなく過ごしてしまっていることがあるかと思う。

この internal/external は大事にしたいポイントなど考え方や文化からして全く異なる別ものだと思った方がいい。仕事の回し方や考え方とビジネスのスタンスの面から自分なりにまとめてみると、

  • internal</p>
    • 信頼性、確実性を重視
    • 工数主義 : 数の論理で問題解決する
    • スピード遅い
    • スキルよりも調整能力が必要
    • しっかりした雇用形態と緩やかな給料上昇率
  • external
    • スピード重視
    • パフォーマンス主義 : いいパフォーマンスする人はすごいと思われる
    • スキルがない人はいりません
    • 小さくたって世界を変えられるぜと思える
    • いつ辞めるか/辞めさせられるか分かりません

これくらい違うと思う。法人営業のSEをしていた時に internal 側にいて、サービスを立ち上げた時に external 側にいて両方を見てきた自分にとっては internal をやっている人と external をやっている人とは根本的な考え方が違うので一緒に仕事をするのは難しいというか、そもそもスタンスが違うのでそのギャップから問題が出るケースがほとんどだと思っている。振り返ってみるとベンチャーのスピードを大手のメーカや法人顧客を多く抱えるIDCに求めても実際ついて来れなかったし、その会社のシステム上そもそも無理だったりしている。

で、自分はどちらでプレイしているのか分かっているのも結構大事で、internal な世界の中で external やってみようと言うのはそれは難しく、自宅に帰ってから個人レベルでやるか、本当に仕事としてやりたいなら external をやっているところに転職してしまうのがいいのだろう。自分のやっている仕事が実際どちらなのか分かっていれば自分のキャリアを描きやすくなるだろうし、転職するにしてもその会社がどちらかを見極められれば無駄な面接は減るだろう。

同じように会社を作るなりして自分でビジネスを展開する時にどちら側に立つかというのも結構大事で、どちらもやるというのはやはり難しいことだと思う。

そういう意味では、ShakeSoul は external で生きていく会社にしたくて、そのフィールドにどっぷり浸かるために作った訳で、最初は internal で直近の売り上げを短期的に、、、なんて考えていたことが矛盾していることに気づかされた。具体的にどういう理想を描いて追求していくかは別エントリーにまとめたいと思うが、これからも external な世界で生きていくための模索とチャレンジを続けていこうとやっぱり思うのだった。

INTEROP Tokyo 2009 に行ってきました もうネットワークは完全に成熟産業化したと思った

f:id:d_sea:20090611134602j:image

f:id:d_sea:20090611134619j:image

f:id:d_sea:20090611134624j:image

おそらく7年前から毎年、INTEROP に行っている。やはりネットワークに関する最大級の見本市だし、web 全盛の前時代はネットワークがコアテクノロジだった訳で行くのは必須くらいなものだった。

しかし、最近は web 開発の時代になってネットワークはあって当たり前なものにますます位置づけられて、新しい技術も生まれることなく高速化だけがホットトピックスになる状況だった。衰退ぶりが実感できたのは展示ホールの広さで、ここ最近は年々縮小していて、7年前は1~8ホールまですべて埋まっていたのに、3年前では6ホール分に減っていた。

今年はどうなのだろう?レイヤの上の方に幅を広げてきた自分にとっては、最近のネットワークだけの状況はあまり分からないながらも、このイベントの変化が現状を知る良い機会だと思って行ってみた。

なんと、今年は展示ホールは3ホール分。IMC や RSA など付属的な展示物を含めて3ホール分しか展示されていない。あー、ついにここまで来たのだなと現実を実感する。

確実にネットワークの産業は成熟化したと言っていい。新しいイノベーションは非常に起きにくくなっているし、高速化へ邁進するプレイヤーは体力のある一部のルータメーカにしぼられた。レイヤ1~4の幅の中での新しいことはほとんどなくなっている。

なぜかというと、

  • 高速化してもその帯域を必要としているところはごく一部であり、おおむね 1Gbps の物理帯域があれば十分なところがほとんど
  • 標準化によって異メーカ間接続が可能になり、つなぐことに関しては安定性、信頼性が高い環境が提供しやすい
  • ネットワーク機器を使う人たちのノウハウが時間とともにたまり、新しい技術や機器を習得しなくてもすんでしまう環境がある
  • ネットワークのレイヤで制御できることは非常に少なく、ソフトウエア側のアプローチでレイヤの高い部分も網羅した制御プロトコルやミドルウエアが多く開発されている

という状況があるからかと思っている。

展示をいくつか見て気づいたことメモ

  • Cisco が展示を出していなかった</p>
    • みんなが知っている存在になっているし、もうネットワーク業界にブランドを提示する必要はないからか
    • サーバに進出していることよりネットワークはもうOKと判断しているのかも
  • 人だかりが割とできていたところ
    • Palo Alto Networks : L4レベルどまりでなく、アプリケーションの振る舞いを可視化して制御する Firewall 製品を提供している
    • TippingPoint : 不正侵入や攻撃、ハッキングを防御する製品を提供している
    • ネットワークレイヤを超えてくるものまたは単純なセキュリティ機能からトレンドを追うような動的な制御を行う製品が注目されている
  • Juniper の 100G FPC の展示を興味深く見る人がほとんどいなかった
    • 高速化の興味を持つ人が少なくなったのか
    • そもそも Juniper の FPC を使うような大きめなルータを使う人が少なく気づかなかったのか

クラウドコンペを見て

今年の INTEROP に行く目的のもう一つはクラウドコンペの発表内容を聞くためだった。クラウドについてすでに取り組んでいる人たちがどんなことを実際行っているのか、どんなアイデアを持っているのか非常に興味を持って聞きに行った。

実際は全10ある中の2つのプレゼンテーションしか聞くことができなかったが、その2つはクラウドというよりかはクラウドに無理矢理こぎつけて、独自のネットワークの距離を測ったり、MapReduce のようなすでにあるものを使ってちゃんと動きました的な内容を発表していた。おそらくこのコンペに合わせてというよりかは今まで研究、検証してきた内容を発表する機会として発表者は利用したのかと思う。

発表内容のレポートはすべてではないが IT Pro の記事 にまとまっている。

そいういう意味では優勝チームの発表は是非聞いてみたかったが、内容を見るに自分たちでクラウドを作るためのアーキテクチャを確立し、開発したという点で真正面からクラウドに取り組んだ結果だけに優勝は当然かと思った。

期待して聞きにいってみたが、クラウドに対して真っ正面から取り組んでいるプレイヤーはほとんどいなかったし、まだ少ない状況だということがよく分かった。

そういう意味では ShakeSoul で Amazon EC2 フルサポートパック を展開していることは市場の中で結構なイニシアティブを持っていると思っている。

来年の INTEROP はどうなっていくのだろう?US の INTEROP は成り立っているのかどうか?

ネットワークレイヤしか、知らない/やってこなかったエンジニアはどうなっていくのだろう?

この大きな流れはもう戻ることはないと思いつつ、何とも言えないむなしさを抱えて予定よりも早く見終わってしまった幕張を後にした。

仮想化友の会 第9回 5月勉強会に参加してきました

メーリングリストの仮想化友の会は入っていたのですが、勉強会には行ったことがなかったのとネタが KVM らしいので聞いてみたい&どんなもんか見てみたいということで、初参加してみた。

2008年のOSCの仮想化系のセッションを聞いた時に会場にいらっしゃった方々が多くみられていた。内容は Red Hat の方々による KVM の技術概要と Red Hat としての取り組み予定紹介。

資料は仮想化友の会webより入手できます : http://sites.google.com/site/kasotomo/study

参加者は Unix/Linux をいじってきましたと言う世代の方々と思われるので、web 開発系なコミュニティに比べれば平均年齢は+5したくらいか。2002年くらいにいた IRI のエンジニアたちが FreeBSD をいじり倒していた時代に軽くフラッシュバックする。

思ったのは、仮想化といっても完全ソフトウエアの話にはならず、必ずハードウエアとの絡みも出てくるので、ハードも含めて検証なりを進める敷居は高く、お手軽さはないので自然とちゃんとできるプレイヤーも少なくなる分野なのかと思う。

特に KVM は CPU でフォローする仕組みなので、ハードウエア依存が強い。ハートウエアに依存しないサーバ環境を作るための仮想化なのだけど、やはり大事なところでハードウエアがしっかり絡んできてしまうのはなんともしょうがないことなのだろうか。

何にせよ、仮想化は1つの手法であって目的ではないのだけどツールの一つとして利用する場合、仮想化するメリットやパフォーマンスを分かっておくことは大事なことなのだろう。

ということで、そろそろ仮想化環境についてもう少し詳細な技術情報なりノウハウなりを貯めたいと軽く思った次第。

以下、当日メモ

20090528

仮想化友の会 5月勉強会

19:00-20:40

KVM 技術解説

Red Hat 森若

  • QEMU : Windows/Mac/Linux 対応 便利だった</p>
    • dynamic なので遅い
    • 色々使えた ia64 使えた
  • KVM : QEMU を工夫して早くしてみた
    • ゲスト OS が I/O したい場合は仮想 I/O に対して、一度 QEMU に渡して
    • KVM-Linux 経由で実際の I/O する
  • 新しいモード Guest mode
    • センシティブ命令は実行できない
  • virtio
  • 共有メモリがあるから早くなる
  • シャドウページテーブル
    • ゲストの仮想アドレス=>ホストの物理アドレスのテーブル
    • MMU の仮想化の問題を助ける
      • ゲストの物理アドレス=>ホストの物理アドレスの変換がない
    • EPT の CPU だとすごく早かった
  • viroio について
    • virtio_ring のスライドの絵がすべて
  • virtio_pci
    • 仮想 PCI バス上に仮想デバイスが並んでいる
    • I/O命令は仮想環境がフックする
    • virtio_ring での virtqueue を作成して共有する処理もここで行う
  • virtio_balloon
    • 共有するバッファは virtio_baloon 構造体1つだけ
    • 仮想化側がいろいろやってくれるだろう前提とした仕組み
  • block/virtio_blk
    • 仮想ブロックデバイスを提供
    • リクエスト用の1つの virtqueue を使う
    • read, write, SCSI cmd を発行できる
    • リクエスト完了 used リングに追加のみ
  • net/virtio_net
    • 仮想ネットワークでバイスを提供
    • 送信、受信、コマンド送信用の3つの virtqueue を使用
    • 送信処理終了後に送信できなかったデータの送信、送信済みのskbの回収
    • block より工夫されている
  • char/virtio_console
    • 仮想コンソールでバイスを提供
    • 送信用、受信用の2つの virtqueue を利用
    • 一度のやり取りは PAGE_SIZE まで

Red Hat の仮想化戦略

Red Hat マーケティング 中井

  • Red Hat と MS 仮想化の相互運用制で合意</p>
    • 合意内容</p>
      • Red Hat 仮想化上で Windows 2000/2003/2008 サポート
      • Windows Hyper-V 上で Red Hat Enterprise Linux5.2/5.3 が動きます
  • KVM について
    • Qumranet イスラエルの会社を Red Hat が買収
    • SolidCE/SPICE も買収した 管理テクノロジ次世代仮想化
  • 今後
    • KVM は OS に統合、Xen は継続サポート
    • GUI ベースの管理ソフトを出す VMware Virtual Center みたいなもの
      • .Net でできている Windows で動くよ
      • ライブマイグレーション機能もあり
      • HA機能、イメージ管理の機能
    • Desktop の仮想化も提供
    • Hypervisor : VMware ESX みたいなもの
  • Qumranet はもともとクライアントデスクトップの仮想化用のソフトだった
    • Solid ICE VDI サービス名
    • 仮想化のエンジンは Linux, 管理のソフトとデスクトップの表示は Windows
    • デスクトップの表示は IE で ActiveX 利用
    • 早いのは独自のプロトコルを持っている SPICE? windows remote desktopより早い
  • Hypervisor
    • KVM : みる角度によって Linux と Hypervisor
    • ホスト 96コア、1TBメモリ # Linux そのもののスペックが適用される
  • 今後 3ヶ月から18ヶ月にわたって製品提供予定
  • 価格まだ秘密 でも VMware よりかは安くなるかも

QA

  • KVM は API 公開するの?</p>
    • VDSM 最初はクローズド、リブバートに持っていく構想あり
    • 今はリブバートに対応していない

Amazon EC2 新機能 Monitoring, Auto Scaling and Elastic Load Balancing を一通り触ってみた

5/18に Amazon AWS から発表になった Amazon EC2 の新機能は Auto Scaling や Load Blanacing など、今までユーザ側でなんとかしていた or 提供事業者が飯の種にしていた部分に Amazon がカバーしてしまった。と言う点で結構注目が集まっていた。

細かな点はさておき、ひとまず触ってみないことにはどこまでカバーされているかも分からないので触ってみた。以下、触ってみたときのメモ。

事前情報

設定の仕方やコマンドはそれぞれのページを参考にした。

3機能概要
  • CloudWatch は instance と Elastic Load Balancer 両方のモニタリングが行える</p>
    • それぞれ取得できるパラメータは異なる
  • Auto Scaling が動作するためには、CloudWatch が instance 上で有効になっていることが条件
  • Elastic Load Balancing は起動している instance を指定して分散対象に加えることができる
  • beta版ということで、すべてコマンドラインでの操作方法しか提供されていない
    • Elasticfox 上だと今回の機能に対する情報は見えない

動作環境

  • すでに EC2 コマンドが実施できる環境があることを前提
  • mac 上でオペレーションしています

事前準備

  • Amazon AWS web へログイン
  • Amazon EC2 API Tools をダウンロードして、ローカルにて解凍
  • EC2 コマンドへの PATH が通っている既存ディレクトリと置き換える
    • 今回の3機能追加にともなうもろもろのコマンドが増えている

CloudWatch を触る

事前準備

README.TXT をみつつ

  • Amazon CloudWatch API Tools をダウンロードローカルに配置
  • .bash_profile に PATH を追加
  • credential-file-path.template をコピーして好きな名前に変える
    • 今回は credential-file とした
  • このファイルに必要な情報を書く
    • key.id と secret key の情報は AWS web の my page よりコピペする
  • .bash_profile に追記した中身

BP Study#21 に参加してきました

技術的にコアで刺激になるような勉強会はないかなと思っていていたら、BP Study をすすめられた。前から BP Study の存在は知っていて気にはなっていたけど、機会がなくて行ったことがなかった。

今回時間もあったこともあって初参加。

内容は OpenID Authentication 2.0 protocol の解説と XMPP and AMQP の紹介

資料の紹介は BP Study の web にリンクされています : http://beproud.jp/bpstudy/?p=31

どちらも技術的にはニッチかつコアな内容で専門ではないので概略くらいしか理解できなかったが、それだけコアなものに触れられてよかった。細かくはなんだか分からないけど技術的に先端的だったりニッチだけどすごいことが世の中にはあるんだなぁ思うこと、それを感じるのが結構大事なのかと思う。

個人的には後半の AMQP みたいな大量な処理をひたすら効率的にさばくための仕組みは結構興味深かった。Google 内部でもこんなようなひたすら高速に処理するためのシステムが作られて web で紹介されているのはごく一部なんだろう。

全体的な雰囲気としては懐かしの IRI でやっていたエンジニア勉強会に近い感じを受けた。そこそこで技術的コアな情報を知っているエンジニアが集まることでエンジニア集団全体としての幅と厚さが出る。この技術の幅と厚さが価値になる。そう考えると BP Study は結構な幅と厚さのある勉強会になっているので価値は高いな。

# この技術に対する価値の見いだし方がちゃんと理解できている人はなかなか少ない。シリコンバレーではベースとなる考え方になっている

懇親会でも色々な方と面識を作れたのもよかった。ShakeSoul として何か一緒にやれることを見いだせればラッキーだろう。

継続的に参加したい勉強会になりそうだ。

以下、当日とったメモ

090521 BPstudy #21

19:00-21:30

Introduction OpenID Authenticasion 2.0 Revival

  • OpenID tech night やった もうちょっと分かりやすくした初心者向け
  • OpenID Authentication 2.0 protocol がある
  • ケーススタディ smart.fm
    • smart.fm のアカウントあり
    • openIDとの関連付け済み
    • OpenID アカウント入れると myopenid.com のサイトにユーザ側でのリダイレクトされた
      • これは smart.fm のサーバがクライアントにリクエストしている
  • 用語
    • Claimed Identifier クライアント側の所属情報
    • Relying party 使おうとしているサービス smart.fm
    • User-Suppolied Identifier
      • Claimed Identifier と OP Identifier をひとくくりにしたもの
  • コマンド myopenid にアクセスする時 Yadis Discovery
    • lwp-request -S -e- d http://zigorou.myopenid.com/ | grep -i xrds
    • X-XRDS-Location: http;//zigorou.myopenid.com/?xrds=1
    • http;//zigorou.myopenid.com/?xrds=1
    • # 色々出てくる
    • XRDS 文章を見つけるやりとり
自分メモ
  • 大まかに言えば</p>
    • smart.fm がクライアントにリダイレクト要求
    • クライアントが openid.com にリダイレクト
    • 認証をする
    • openid.com よりクライアントへリダイレクト要求
    • クライアントが最初の smart.fm にリダイレクトする
  • という感じの流れのようだ
QA
  • Q1 A1 OpenID ライブラリが出ているようだ</p>
    • セキュリティホールがあるようだ バージョン上げる必要があるとのこと
  • Q2 return-to-url が書き換えられる場合は
    • どの OP も安全という訳ではない verification でチェックされて促すくらいのやり方
  • Q3 いろいろな OP があって開発めんどい
    • めんどいので Google は画一的な画面を出して共通化する動きもある

XMPP and AMQP

  • 両方を知っている人少ないのでは、、、
  • XMPP
    • XML 実装
    • Google Talk のプロトコル
    • 非同期な通信
  • AMQP
  • Erlang
    • 並列処理指向言語、分散処理指向言語、Open Telecom Platform(OTP)
    • facebook Online chat, AWS SimpleDB, Apache CouchDB, 分散ハッシュDB Kai / scalaris で使っている
    • はてなダイヤリ higepon/20090509/1241863278
    • 井上 武 たけまるさんの資料公開されている プログラミング言語 Erlang の動向
XMPP
  • RFC にもなっている
  • XMLベースのプロトコル
  • 動きはメールサーバと一緒
  • TCPコネクション張りっぱなし
  • XMPP Server 接続、友人、状態を管理
    • クライアント間は直接メッセージ通信する
  • 基本的には NAT を通らない
    • Google は UDP Hole panching をするライブラリを適用している
    • プッシュ型のメッセージ交換 張りっぱなし
XMPP サーバの動き
  • ログイン、IDとIP情報を伝える
  • 相互認証になる ブロックしたい相手には情報を送らない
セキュリティ
  • SSL/TLSm DNSの逆引きチェック、SASL。。(シンプルな認証のようだ)
  • 複数チャットも可能
ejabberd
  • Erlang による XMPP 実装
  • Group Chat も実装済み、部屋が作れる
  • 大量のコネクションが来ても大丈夫
Ejabberd Cloud Editon
  • AWS の SDB と S3 においてしまう
  • スケールすることを
AWS import/Export
  • HDD を Amazon へ送る
  • S3 にインポート
  • 1TB HDD 1TB転送して 1万円くらい
  • バックアップ HDD を送ってもらう
AMQP
  • Advanced Message Queue Protocol
  • 今年中に 1.0 が公開されるはず
  • メッセージ指向ミドルウエア
  • アプリケーション間の通信プロトコル
  • 5億くらいのメーッセージをさばく
  • 非同期なのにトランザクション
  • TCP であることを利用
  • マルチキャスト
  • ルーティングキーが一致するところに送る
  • 大規模向けすごい負荷がかかるところを抜けるためのソリューション
RabbitMQ
  • Erlang による AMQP 実装
  • 130万/sec リクエスト可能
  • 3億メッセージ/日
  • AMQP 0.8 まで実装済み
  • ニュース配信、ラジオとか 情報がとにかく出すところが使っている
Kay
  • Google App Engine Python 専用フレームワーク作ってます
AMQP サイトがある
  • 送る側とクライアントの作り込で設けているようだ
  • 送る部分はオープンソースにしている

etc

  • アーラン
  • Tokyo キャビネット
etc : Google libjingle
  • Google Code より
  • techtalk もある コアエンジニアが話しているらしい
  • xmpp.org にも libjingle
  • 95%は Google 社外に出てないらしい

Amazon EC2/S3をいじってみた

Amazon EC2/S3 を触ってみた。調べつつ行うのは時間がもったいなかったので本に頼ってしまった。

学びingさんの以下の本を読みつつ進めれば、問題なく行えた。

Amazon EC2/S3クラウド入門

Amazon EC2/S3クラウド入門

本には記述されていなかったことや自分で気づいた点もあったのでまとめておく。

準備

  • ログインは Amazon.com のショッピング IDと同じでログインできた</p>
    • クレジット情報も事前に登録済みならそれで決済される
  • ブラウザ上で privatekey と x509証明書 を生成&ダウンロード可能
    • コマンドラインでオペレーションする EC2 API tools を使う際にこの2つのファイルを指定する
  • firefox アドオンの xpiファイルがダウンロードされるだけで firefox にインストールできない
    • firefox メニューから ファイル>ファイルを開く>xpiファイルを指定>インストール開始でできた</p>
      • windows/mac 両方で同じ現象だった
  • web の Your account 情報から
    • Your Access Key ID と Your Secret Access Key を確認
    • firefox addon elasticfox のアカウント情報に設定する

E2を触る images 選択から instance 起動まで

firefox addon operation (GUIな操作)
  • images 一覧より選択</p>
    • 最初なかなか表示されなかった
  • Fedora を選択してみて起動 起動ボタンを押してから2分くらいで running status になる
api tools operation (コマンドラインな操作)
  • なかなか ssh login できなかった</p>
    • よく分からんけど root でログインしたらノーパスワードで入れた
    • 一部の AMI はパスワードを聞かれて入れなかった
      • そうか知っている人だけ入れるにしてしまうことがこれでできるのか
  • OKだったやり方

$ ssh -i [keyname] root@ec2-67-202-43-106.compute-1.amazonaws.com

  • root@ を付けないと

Permission denied (publickey,gssapi-with-mic).

と言われてログインできない

  • 基本的に作ったばかりの instance は root でログインしてからということだった

S3を触る

  • ユーザごとに割り当てたファイルサーバのイメージ</p>
    • 自分のローカルPC上のファイルをコピーできる
    • ここに AMI の元となる bundle された image ファイルを保存できる
  • firefox addon S3fox を入れる
  • 起動後ログイン情報を入力 manage account
    • elasticfox のときと同じ情報
    • Your Access Key ID と Your Secret Access Key を適用
  • ログイン完了
    • ローカルのファルだ構成とS3側の構成が左右に配置されている
    • 見た目は WinSCP みたいなイメージ
ディレクトリを作ってみる
  • create directory して作る
  • Edit ACL でそのフォルダのパーミッションが変更できる
    • 設定できる user は</p>
      • Everyone, Authenticated Users, [自分のAmazon.comアカウント]
      • Linuxのアクセス権とは若干違い独自のパーミッション管理ができるようだ
      • Shareしたいユーザを追加できる Email or UserID で指定できる
    • 権限は Read/Write/FullControl
立ち上げたinstanceのAMI をS3までもってくる on Fedora
  • まず 立ち上げた instance に privatekey, certificationkey を /mnt まで持ってくる
  • 立ち上げた instance 上で ec2-bundle-vol コマンドを実行
    • あらかじめ各instance(Linux)には既にec2コマンドが実行できるようになっているということか
    • image* ファイルがたくさんできる
  • 終わったらS3にコピーするコマンドを実施 instance 上で実行
    • S3 上で image* がいっぱいできている
  • ami に登録する 手元のPCから ec2-register コマンドを実行
    • これでいつでも 自分用 AMI が起動できるようになる
    • private な登録なので他のひとには見られない
まとめ
  • EC2 => EC2 /mnt => S3 => AMI 登録 の流れ
  • AMI登録するにはS3に持ってこないとできない
  • AMI登録されると private なので自分の ID(keypair) でないと見れない
    • public にするためにはどうすれば良いんだろう [Q]

その他

  • Security Group(簡易firewall) は destinasion ごとに設定できない</p>
    • アドレスが変わってしまうから
  • そのかわり instance を group 化して group ごとに filter できる
  • 作業手順は security groups を作っておいて instance を起動して group 属性を変更する順番になる

windows instance の立ち上げ方

  • keypair を指定して起動
  • status が running になってしばらくしたら
    • ec2-get-password i-**** -k ec2_instance_key.id と入力</p>
      • elasticfox 上でも右クリックで行える
  • password が表示される
  • Administrator login 時に使用する
windows instance の AMI 登録方法
  • elasticfox 上でオペレーションが完結する方法</p>
    • windows OS 上での方法は分からず Linux とは違ってできないのかもしれない
  • elasticfox で instance を右クリックして “bundle windows AMI”
  • bundle 終了後 右クリックで “register as an AMI” を選択で完了

基本的な操作はこんなところ。今後はもう少し他の付加的機能についても触っていってみたい。

</div>

ヒューマン2.0 web新時代の働き方(かもしれない)

シリコンバレーカンファレンスに参加して、渡辺千賀さんのセッションがあって初めてお目にかかったのだが、それまでは何となくブログを読んでいただけであったが、もう少し考え方に触れたいと思い本を買ってみた。

ヒューマン2.0―web新時代の働き方(かもしれない) (朝日新書)

</div>
</div>

内容はシリコンバレーでの暮らし、仕事やライフスタイルなどなど多角的に紹介している。

肩肘張らずシリコンバレーの楽観的な雰囲気のなかで暮らしている筆者のキャラクターがよく出ている文章が一貫して展開されているので、スラスラ読める。

確かに自分が見てきたシリコンバレーの様子はそんな感じで、自分が svc09++ カテゴリで書いてきたことと同じような視点や書き方になっていると思う。こちらの本の方が若干執筆されてから2年以上経過しているが情報量が多い分、シリコンバレーの様子がよく分かるだろう。

シリコンバレーのベンチャーの定義や様子、失敗が汚点にならないシステムやシリコンバレーでの仕事の仕方や必要な要素などについても解説している。

シリコンバレーは先端的かつハイレベルな特別な世界なので、ある意味正解がない中でみんなものすごいレベルでものすごい早さで走る。正解がないから正解を求めると言うよりかは、この先よく分からないんだけどとにかくやってみれば大きな成功にあたるかもしれない。と言う考え方で過ごしているし、その考え方がここで生きている人たちのベースになっていると思う。

そんな やってみなきゃ分からない人生 をエンジョイしつつ、ハイレベルで厳しい場所が確かにあるので、それがキラキラと輝く魅力的な場所に思える方でまだシリコンバレーという地を体感したいことのない方にはお勧めな本です。

</div>

メガネのレンズ情報

どうにも右目が強く感じてレンズ交換をした。

  • 現状
- PD V S C AX
70 0.5 -4.00
70 0.5 -3.75 -0.75 180

両目で0.7。家の中でテレビを遠くから見るには厳しいが、見えすぎるのも良くないのでこれくらいで。

  • ちなみに一つ前 07.08.27作成
- PD V S C AX
70 -4.50
70 -3.75 -0.75 180
  • さらにその前 07.03.18作成
- PD V S C AX
70 -5.00
70 -3.50 -0.75 180

右目がすごく強かったのね。右が良くなったのか左が悪くなったのかはよく分からない。

引越してから初の診療

3月に引っ越したので、矯正歯科に行くには引越し元の近くまで通わねばならない。車で行っても結局1時間弱かかった。

引越してから1ヶ月ほどしかたっていないが妙に懐かしい感覚になる。自分の家はもうここにはないことが分かっているとそう思うのかもしれない。

最近はリテーナーを洗浄してもらっている間に、助手の人に研磨剤でブラシのようなもので磨いてもらってからフッ素をコーティングしてもらい、その後先生が見て特に問題ないですね。という感じで30分もあれば終わる。

特に大きな問題なく、スムーズに進むことは良いが、本当はもう少し歯が動いてしまうのをなんとかできないか相談したいところ。

今のところリテーナーを食事の時以外はずっと付けているので、動かなくならないように出来ているけれども、この分だとリテーナーをやめるのはかなり先になりそう。

本日の精算:チェック料 ¥5,000

今後の自分に何を生かすか 何をしていくか

# 本当は4月中のエントリーにしたかったので、back date しています。

このエントリーを書くのにすごく時間をかけてしまった。書けなかった理由は、シリコンバレーから帰ってきてすぐには自分なりに意志を決めるまでにいたらず、決めるまでの時間が必要だったことが大きい。

結局、今回シリコンバレーで色々見てきて話してきたことが考え方や視点に大きな影響を与えた訳だけども、これが自分の今後の行動に反映できなくては全く行った意味がなくなってしまうので大事にしたいエントリーでもあり、これを書くことで自分自身へのコミットをすることになるのである程度慎重になってしまったところもある。

このエントリーを書くために今までの [svc09++] カテゴリのエントリーがある。

この間色々な人と話す中で言葉にしながら自分自身で明確にして行ったところもあるので、やはり時間は必要だったのだと思う。

短期的な行動計画と中長期的な自分の戦略をまとめた結果を示す。

基本的な流れ

  1. 株式会社シェイクソウルを初年度自分の満足できる内容と売り上げ数字の実績をつくる
  2. シリコンバレーとの人脈を保つと同時に拡大する
  3. サービスアイデアを継続的に考え続け、客観的評価をもらう
  4. 来年2月以降ワールドワイドに勝負できるサービスアイデアをシリコンバレーへ持ち込み、ベンチャーとしてのゲームに乗り exit 目指して大きな成功を目指す

短期的な振る舞い

株式会社シェイクソウルで行うこと

現状としてはまだ日本で株式会社シェイクソウルを作って3ヶ月しか経過してないので、最低でも初年度が終わる1年間は自分の会社を作ってやってみたかったことを追求して、結果を残すことをメインにする。

  • 自分の会社を作った目的は自己実現の最終形だと思っている</p>
    • 自分の考え方にそった内容/スタンス/レベルを求めてパフォーマンスした結果、世の中からどう評価されるか
    • 自分の価値を世の中で最大化するための実験
    • 形態としてはパフォーマンスを最大化するために時間を無駄に使わないライフカンパニーをこれからも続ける
    • 梅田望夫氏の「ウェブ時代をゆく」内の「けもの道」を歩むことに当てはまる
  • 会社規模ではなく小さくてもスキルを持っていること、ウェブの力を借りて実行力/実現力を最大化してアプローチする
  • 受託に埋没して単なる歯車に甘んじることはせず、自分だからできるパフォーマンス/レベルを求められるところにリーチする
  • 日本の中で提供されていない部分の小さな規模ののサービス企画開発を続ける
  • 優良で志を同じにするパートナーを多く作りお互いの補完関係でクリエイトして生きて行くのが理想
シリコンバレーとの関わり

ビジネスとしてシリコンバレーを直接のフィールドにはできないので、緩やかにシリコンバレーの情報や人脈を保持することにする

  • 今回 SVC09 で作れたシリコンバレーで働く方々と作れた人脈をこれからも保持する</p>
    • できれば人脈を拡大する動きにつなげたい
  • 具体的には2009年度中に1~2回はシリコンバレーに行って、直接話す機会を設ける
    • この時に win-win の関係が作れていないと成り立たないので、日本で行ってきているサービス企画開発したものの意見交換やこれからに向けたアイデアに対する評価をもらう
  • やはりシリコンバレーの流動速度は速いので、現状を確認してどういう変化が生まれているかを感じる
  • 単純に日本にいると日本だけの視点に陥ってしまうので、ワールドワイドな視点になるために行く

中期的な戦略

シリコンバレーとの関わりを徐々に深めて行く。サービスアイデアは継続的に考え続け、その視点は日本に埋没することなくワールドワイドで通用するものにする。

  • 徐々にシリコンバレーに行く頻度を上げる
  • そのための強い理由を作って行く
    • 現状の仕事の発展として行けることが理想
    • 日本~シリコンバレーの橋渡し的なことが少し始められるといい
  • シリコンバレーの人脈にはこのワールドワイド視点でのサービスの意見交換を求める
    • もう少し具体的に絡めることがあるといいが、今後考える
  • この時、海部美知氏の「パラダイス鎖国」内の「軽やかなグローバル化」のイメージで行けたら
  • シリコンバレーで過ごすための必要なスキルセット(英語、生活するための知識など)はこの時期に十分にしておく

長期的/将来的なゴール

やはり大きな成功を手に入れるためのゲームに1度は参戦すべきだと思っているので、シリコンバレーでベンチャーを立ち上げることを長期的な目標にして、exit して大きな成功を手にすることをゴールとする。

  • ワールドワイドで行けると思ったアイデアに対して、シリコンバレーに持ち込んでベンチャーを立ち上げる
  • 進出する時にはそれまでに作ったシリコンバレーでの人脈をフルに行かして、立ち上げ初期のリスクの高い状態をなるべく短期にする
    • そのためには進出する事前に体制や頼る人を整えておくことが必要
  • シリコンバレーに住んでいることが必須
  • シリコンバレー大企業への就職は自分のやりたいことと一致してないので選択肢にしない
  • ダメだったとしても汚点にはならないし、本当に可能性がなくなったら日本に戻っても良いので失敗のリスクはない
    • それまでのシリコンバレーで作れた人脈力で痛手にならずにリトライできるチャンスがもらいやすい環境にしておくことも重要
    • その時に日本ではシェイクソウルが何もせずとも継続的な売り上げをあげられる状況になっていれば理想的だが、これにはこだわらずにシリコンバレー進出のタイミングマターで行く
  • 自分の勝手な感覚だと、今から1.5年~2.5年以内には実現したい

シリコンバレーカンファレンスの旅の最も大きな収穫は今後の自分の生き方として目標とするポイントが定められたことかと思う。

日本で大企業、ベンチャー、スタートアップサービスを経験して、やはりすべて自分の判断で動いてみたいと思ったので独立を選択したが、おそらくある程度の売り上げを得られた時点でこのチャレンジは成功となって、その先のもっと大きな展望が描き切れていなかった。スキルの低い大人数の組織を作ることはやりたくないし、ある程度の人数のプロフェッショナル集団が理想だが今の日本では上場が必ずとも成功にはならないのでこれはやりにくい。そう思っていた時にシリコンバレーのベンチャーがチャレンジできる充実したシステムと実際会社がうごめく姿を見て、ここで勝負してみたいとシンプルに思えた。

年齢的にも環境的にも留学は選択肢にならず、ベンチャーとしてチャレンジできる時間もあまり残されていない気がしているので、長期的と言いつつも残された時間は最長3年かと思っている。

どれくらいここで書いたことが実現できるかは全く未知でできる保証はどこにもないが、今まで自分自身でチャレンジをしてきたように今回も自分を信じて模索しながら時に大胆に歩んで行きたい。

少なくとも日本だけの文化やパイだけで埋没しないことと、シリコンバレーで得たシンプルさと圧倒的なパワーと気持ちのいいお天気はいつも忘れないでおきたいと思っている。

</div>