メーリングリストの仮想化友の会は入っていたのですが、勉強会には行ったことがなかったのとネタが 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 最初はクローズド、リブバートに持っていく構想あり
  • 今はリブバートに対応していない

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

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

事前情報

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

• Amazon CloudWatch
• Auto Scaling
• Elastic Load Balancing

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 をすすめられた。前から 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 を触ってみた。調べつつ行うのは時間がもったいなかったので本に頼ってしまった。

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

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

準備

• ログインは 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>

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

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

• 現状

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

シリコンバレーとの関わり

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

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

中期的な戦略

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

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

長期的/将来的なゴール

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

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

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

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

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

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

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

</div>

花粉症が4月後半になっても少し出ていて、今までちゃんと調べたことなかったのでアレルギー検査してその結果が出た。

結局、スギとヒノキの花粉症が標準的にあるくらいだった。

もっと色々あると思ったんだけどな。。。

結果 クラス(判定)

アレルゲン	クラス	ARU/ml
スギ	3	12.5
ヒノキ	2	1.79
その他		0.34L

エバステルを飲んでいたけど、この時期になってもなかなかくしゃみと鼻水に悩まされているので耳鼻科に行って出してもらった。エバステルよりかは効くし、状況がひどいときの一次処置用の薬も出してもらった。

ここまでもらえれば万全か。

• クラリチンレディタブ錠</p>
  • アレルギー性疾患の治療薬
  • 朝食後1錠
• ナゾネックス点鼻液
  • アレルギー性鼻炎などの症状を抑える
  • 鼻腔内噴霧用
  • 外用点鼻
  • 1日1回
• トーク点鼻液
  • 鼻の血液を収縮させて鼻づまりを抑える
  • 外用点鼻
  • つらい時のみ
• ポララミン錠
  • アレルギー性疾患の治療薬
  • つらい時のみ

とりあえずクラリチンレディタブだけでもそれなりに症状が抑えられているのでしばらくこれで行ってみる。