読者です 読者をやめる 読者になる 読者になる

夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

QconTokyo2012に行ってきました!(概要編

こんばんは。

本日去年に引き続き、QconTokyoに行ってきました。

とりあえず、詳細は次回以降の投稿にまわすとして、
今回はQConTokyo全体のテーマと、後参加した各セッションのポイントについてまとめます。

・・・尚、当然ながら理解できたレベルでしか書けないため、
阿呆なことを書いていたらコメントください。
落ちこぼれ三流エンジニアである現状のため、踏み外している気もします^^;

1.今回のメインテーマは?

個人的な意見としては、今回のQConTokyo全体を通して一番強かったテーマは、
アマゾンの玉川 憲さんがセッションでも話していた、
「インフラは(クラウドによって)ソフトウェアになった」という一言だと思います。

AWS(に限らず、OpenStack等のOSSIaaSでもそうですね)はAPIが公開されているため、
様々な言語からインフラ自体を制御するプログラムを記述することができます。
つまり、
『サーバ、ネットワークといったインフラをソフトウェアから制御できる』わけです。

結果、ソフトウェアのAPIを呼びだすようにインフラを操作し、
ソフトウェアのパーツの一つのように扱ってシステム/サービスを提供することが可能になりました。

そのため、インフラをソフトウェアと同列の存在として扱う時代が来たわけです。

とりあえず、この1年、AndroidやBigData、リアルタイム分散処理にかまけて
クラウドの勉強をあまりしてこなかったので、再度調べようと思います。
・・・ええ、何故かクラウドを使わずに自宅に小規模クラスタを組んでいる現状ですので(汗

というわけで、以後は参加したセッションのポイントを。
あくまで今回はポイントのみです。もう1段階詳しい内容は次回以降の投稿で。

2.怪しい都市伝説 - Mission Cloud Computing @ NASA

Jamie Kinneyさんによる、クラウドに対する怪しい都市伝説を一つ一つ検証するセッション。

ポイントは、
クラウドに対する都市伝説は大体誤りです』ということ。

ちなみに都市伝説として挙げられていたのは下記の点

A.クラウドはセキュアじゃない

 → ニーズに合わせてセキュリティは確保できる。心理的な障壁が大きい。
   故に誤り。

B.クラウドは落ちる!

 → オンプレミスクラウドでもデータセンターが吹っ飛べば落ちる。
   クラウドは上記の状況でも冗長化の策によって稼働を継続できる。
   故に誤り。

C.クラウドはスタートアップ企業のためだけのもの

 → NASAのような巨大プロジェクトでも活用している。
   故に誤り。

D.クラウドのリソースは無限

 → 無限ではないが、必要に応じて事実上無制限に確保できる。
   検証不可。

2.Androidに関わるエンジニアの視点

バイドゥの足立 昌彦さんによるセッション。AndroidのSimejiの作者といえばわかりやすいですね。

ポイントは下記。

完璧よりまずは終わらせる。失敗して学べ。
挑まなければ何も得られない。
熟考するより、少し考えて動いて試せ。実際に動いた経験から得られるものの方が大きい。
お客様/ユーザの考えることはよーわからん。人間に先を見通す力なんてない。なら、まずはやってみるしかない。

#後は皆がほしいものは大きいところが出す、なら、自分は自分がほしいものを出す。

多分ほぼ同年代のため、
こうまで先に進んでいる人がいるのを見ると頑張らないと、という気持ちになるセッションでもありました。

3.Heroku Inside

セールスフォースの相澤 歩さんのセッション。
Herokuの内部構造を説明する内容でした。

ちなみに、Herokuを今まで私は「ヘイロク」と読んでましたが、
相澤さんは「ヘロク」と読んでました。
その時点で色々間違っていたようです(汗

Herokuは優れた開発者の生産性を最大化するプラットフォーム。
サーバの存在/スケーラビリティを考慮する必要はない。
上記2点の達成のために考え得る工夫をつぎ込んでいる。

4.クラウドデザインパターン

アマゾンの玉川 憲さんのセッション。
クラウドを扱うためのシナリオ/パターンを示す内容でした。

一番のポイントは、今回のテーマである下記の一言だと思います。

インフラは(クラウドによって)ソフトウェアになった

ただ、もう数ポイント。

AWSの扱いは基本的に暗黙知だった。それを形式知に落とし込むのがCDP(Cloud Design Pattern)
机上実験より実証実験
スモールスタートからはじめ、スケールアウト
変化に対しては全レイヤで対応
故障のための設計を盛り込む
インフラレイヤも最初だけではなく、継続的に改善する。

5.Big Dataを支える大規模並列分散技術の現状と今後の方向性

マイクロソフトの萩原 正義さんによるセッション。
現状の大規模並列分散技術を俯瞰した内容でした。

・・重要な話なのはよくわかるんですが、私が阿呆なので理解度が追い付かなかったんですよね(汗
とりあえずのポイントを書きます。

RDBの処理コストの大半は本筋の処理とは直接関係ないコスト。そのため、直接関係ないコストをいかに削るかが重要。
現状の分散システムで、スケーラビリティは確保できた。だが、レイテンシが問題となっている。
ソフトウェアの扱うレイヤによって、不要な要素は隠ぺいして扱うべき。

6.Twitterの最新アーキテクチャ

Twitterの山本 裕介さんによるセッション。
Twitterアーキテクチャに関する内容でした。

Twitterの処理特性は下記の3点

同時接続数は膨大
大量のIOが発生
永続化すべきデータはわずか。大半がRead。

上記3点に対処するために、必要なのは下記の3点。
下記を満たすためにはRubyよりJVMの方が優れた特性を持っているというのが現状の結論。
ただし、あくまで現状の解であり、より優れた技術解があればそちらに代える。

サーバ負荷を適切にさばく
言語対応の柔軟性
成熟したコンカレンシーモデル

最後が駆け足のため、前半の一段階浅いポイント(上記)が目立ってしまうのがちょっと残念でした。

7.現場で使えるドメイン駆動設計

グロースエクスパートナーズの和智 右桂さんによるセッション。
DDDを現場で使うための内容でした。

業務を理解しよう。
適切な方式とプロセスで実装しよう。ウォーターフォールの手堅さと、アジャイルの柔軟さを組み合わせよう。
理想的なアーキテクチャではなく、チームで実装できるアーキテクチャを選択しよう。

8.ソーシャルゲームにおけるAWS/MongoDB利用事例

サイバーエージェントの松下 雅和さんのセッション。
AWSとMongoDBを使って、実際にソーシャルゲームを開発した際の事例。

AWSはスタートアップに最適で、サーバの変更にも対応しやすい。
どんどん機能改善されている。
多少の障害は見込んだ上で使うこと。
MongoDBは学習コストが低い。
使いどころがあっていれば開発も運用も楽
絶賛開発中で、不具合もまだ多い。

9.買った本

で、今回買った本ですが、下記の2冊。

マーカス・チャウンの太陽系図鑑


お前はITのイベントに行って何買っているんだ、と怒られかねない本ですね(^^;
なんですが、元々私自身幼稚園の頃に太陽系創成の番組を見て
理科→技術者の世界に飛び込んだ人間なので、こういうのを見せられると我慢できないんです。ハイ。

アジャイルマインド


アジャイルプロセス協議会の本です。
アジャイルサムライの次は何を読もうか。。。と考えていたところ、
他では手に入らなさそうな本があったので買いました。


・・と、何にしてもためになったし、楽しかったです。
来年もいけるといいですね。

後は次回以降の投稿で他のセッションについてもう1段階深めた内容のものを投稿しますね。