会社の人に誘われたので、Qcon2012(http://qcontokyo.com/)に行ってきました。
カンファレンスもよく考えたらYAPCくらいしか行ってないので、そこそこ不思議な気分でした。
多分参加者は150人くらい。さすがに知り合いの人はいませんでした。。
クラウドがテーマの１つ、ということでそれ系の話が多かったかなと。自分がそういうセッションを選んだからかもしれませんが・・・
以降はだーっとメモったものが基本。要所を編集しました。
よくあるカンファレンスの流れなのか、みんな淡々とセッションを聞き・移動する。ということで淡々と過ぎて行きました。
席から電源が取れなくて、休憩時間の度に充電する必要があったのがちょっとマイナス。。でも、周りの人もノートPCより紙のノートの人のが多かった。
あとはお菓子と少しの飲み物が提供されて、同時通訳が凄かった。とかが印象。
Keynote 1 怪しい都市伝説
cloudのメリット
小規模でも使える
NASAではギガピクセルデータをhadoopで分析して、ipadで確認 なんてのができる
火星->S3->みたいな流れ
機密のためにはaws double cloud
NASAはamazon,google,MSあたりを使ってるよ
amazonの財務をどう見てる？
2000年30億ドル規模だったものを今は毎日提供してる
安定して提供してるよね。
クラウドから別クラウドへ、データはどこででも保存されるべき
情報漏洩で工夫した点
データが漏れてないことの確認のしかた
暗号化によって対応。鍵はクラウド側には投げない。
クラウドに投げる前に暗号化。
======感想=========
途中から参加だったので、乗り遅れる
===================
Keynote 2 Androidに関わるエンジニアの視点
simeji買われたバイドゥの足立さん
◎androidの歴史
2007.11 android登場 Open handset aliance
2007.12 blog書く。ターニングポイントだった
2008.09 実機登場
野良アプリ入れて動かしてもらう
この時点でblog44本くらい
2008.11 inJap登場 日本語入力機能
この時からユーザビリティを考えていた
2008.11 Simeji登場（翌日）
スピード感が一番大事
ニーズを検証するより、ニーズそのものがあるかわからない
※アプリ開発の壁
３位：技術力の欠如
やり続ける。調べる。わからないけど動く、でとめない
２位：モチベーションの減退
休憩大事。俺俺ミッションを作る。
１位：ユーザーフィードバック
正直キツい。お客こわい。
個人のアプリ開発で大事な事
技術／リード・マネジメント／デザイン／メンタルコントロール／語学力／その他
2009.04 IMF Input Mehotd Framework
2009.04 android1.5リリース
2009.05 ハードウェアキーボード対応、フリック対応、ポケベル対応
2009.06 iWnn登場
ここから自分路線に切り替える
2009.06 NDK登場 Native Development Tools AndroidでNativeコード開発ツール群
2009.06 デザイナ矢野さんjoin
※デザイナーと働く
お互いの認識の差を理解することから
マッシュルーム
インテント。アプリ間の連携。RPC的なこと。
地図から住所の文字情報を引っ張ってくる
2009.09 マッシュルーム公開
2009.09 OpenWnn公開
2009.09 冬眠
2009.11 脱もっこり
2009.12 WiFi経由でPCから入力
2010.03 Android MIPS対応
2010.05 上海
2010.09 KDDI America NY講演
2011.05 渡米
2011.05 ADK Android open accessary kit
2011.09 android x intel Multi-platform
2011.12 売却
◎大事なこと
完璧を目指すよりまず作る
人間は先を見通す能力なんてない
要するに、ちょっと考えて動いて試す
考えすぎた想像より、経験から導かれる予測の方が精度が高い
（Q）android以外のプラットフォーム開発について
マルチプラットフォーム開発あるので、プラットフォームたくさんあるのでandroidにとらわれないほうがいいよ。
マルチ開発は開発者のエゴ。ユーザーの要望実現が重要
（Q）考え方はリーンスタートアップ？
本は先週注文しました！
======感想=========
androidとsimejiの歴史の話。
とにかくスピードが早い、というのが印象的。機能リリース翌日に対応など。
自分が欲しいもの、というコンセプトを崩さずに進めているのが理由とポイントなのだろうと感じた。
逆に「冬眠」してたというのも大事なことなんだなと思った。
リーンスタートアップは自分も先週注文しました！
===================
美しさは見る人の目の中に宿る
いけてないコード
略しすぎるコード
タトゥーにいれたコード
いけてない定義
コードは芸術ではない。工芸的な職人ではない。機械の一部
コードの見かけはどうでもよくて、ソフトが低コストで動くことが求められる
開発は氷山の一角。あとはたくさんのメンテナンス。
メンテしにくい、複雑、変更に弱い。いけてないのはリスクの高いコード
いけてないのにはいくつか種類がある
ぼろいコード。コメントで変更履歴がたくさんのコード
複雑とぐちゃぐちゃは違う。
maddening mishmash.ごちゃ混ぜなコード。依存が複雑。
破滅的にかき乱れた状態。これも依存が複雑
comprex & convoluted. 意味の分からない遠回りな処理
いけてないのと古いのは違う。古いのはアリ
freakishly foreign. 知らない珍しい言語とか。
いけてない原因
・悪意はないけど、無知なエンジニア。本もblogも読まない人。関心がない。
・上司の親友。カウボーイコーダー。
・賢いエンジニア。マイケル・ジャクソン（という人が書いた本）が言ってる。
いけないコードが現れない理由
・アジャイルもウォータフォールも関係ない
・テストの有無でもない
・言語でもない
現れないために
・無知に知恵を授ける。昼飯をただで用意して、学ばせる。
・カウボーイにはプロセスで囲い込む。手順を踏ませる。
・賢い人、ソリューションが目の前にあるのに複雑化しようとする。セカンドオピニオンを求める。
いけてないコードをなくすために
・ホントにいいのか？ホントにいいのか？見難いだけで？
・いけてないのはマイナスの一部。将来のメンテが楽になる「かも」。リスク導入を肝に銘じる
コードは依存している。
依存レベル
プライベートメソッドとパブリックだと違う
呼ばれ側を書き換えるのではなく、再実装する。
deprecated,oboleteなどの警告を出す。移行を促す。
（Q）どうやったら良いコードを書き吸収できるのか？
こういうMTGに出るのも重要。勉強も重要。やる気がない奴らにはピザおごれ。昼飯来ないならMTG形式ですかねー
パフォーマンスとコードの美しさの関連性
コメントでhack , warningとか注意書きするといい
======感想=========
コードの質とはメンテナンス性。
ダメな人のコードも良すぎる人のコードも課題があるっていうのは、凡人として激しく同意。でも誰にも悪気はないんですよねー
古いだけなのは悪い事じゃないけど、たくさんの人がいじってたり、その積み上げ方が悪かったりするといけてない、というのも納得。
古いけど安定して動いててそんなに触る機会ないんなら放っておく、っていうのは現実解だと強く思う
とりあえず取るべき策は
・deprecated警告しつつ、新しい方への移行促す。コンパチ大事。
・昼飯にピザをおごる余裕はないけど、勉強会に食事を持ち込むのは考えてみようと思った
===================
クラウドデザインパターン -AWSを用いたシステム設計のベストプラクティス-
インフラストラクチャはソフトウェアになった
APIでコントロールできる
日本でAWSを使いこなしている人は少ない。世界に比べても。
なのでノウハウを形式知化したい。CDP。cloud design pattern。48個。近々総選挙予定。
froatingIPパターン
IP のつけかえが簡単
clone serverパターン
初期のサーバーの設定値やデータをコピーする手法
job observerパターン
キューの処理もシステム化されてる
実装シナリオ
５個ある
CGMシナリオ
動画をあげたい。→S3を使う。 dropboxも使ってる
アクセス増えた。入力を仮想サーバー -> 出力をS3から
cache distributionパターン。CDN化して海外対応
Eコマース
route53で独自ドメイン
ソフト更新->floatingIPパターンでテストインスタンス立ち上げ、テストがOKだったらIPつけかえる
multiserverパターン。冗長化。DBもLBも設定可能なUI。
DBrepricationパターン。DBのレプリも設定でやってくれる
multidatacenterパターン。web+dbサーバのセットで１つのDC。
nfsreplicaパターン
クラウドアーキテクティング
できるだけサービスを利用
机上実験よりも実証実験
スモールスタートからスケールアウト
変化に対し全レイヤで対処
故障のための設計
（Q）見積もりしにくいんだけど？
SMC simple monthly calcurator というのがある。データ量やIOの違いは誤差。
（Q）ELBがよくわからないよ
複数のDCに振り分けられるLBになってる
======感想=========
AWS48。
デザパタを用意するというのはクールだなーと思った。
業務で運用している色んな手法がデザパタに採用されてて、網羅性に説得力があった。
言った通り、インフラをソフトにした。という説明がしっくり来た。
各所でプレゼンされている資料がたくさんあがっているようです。
===================
ソーシャル・コンピューティングをスケールさせるには（facebook)
700万人->８億人
フェイルオーバー、エラーハンドリングの話をします
ソーシャルアプリ、ソーシャルデータとは
繋がっているユーザーとやりとりをする＝ソーシャル
スケーリングはつながりのスケーリング
容姿などの客観情報よりも興味＝人のソーシャル性
faceの写真アプリ、できは良くない。リサイズできない、順番替えられなかった。
でもfaceが世界最強の写真サイト。なぜか、ソーシャルだから。タグづけができる。
クラスタリングとパーティショニング
友達のデータをどのクラスタにのせるかっていうのは制御不能
小さなオブジェクト
メッセージの小ささは対話に繋がる。
高い更新頻度
対話が繋がるので
データの一貫性
銀行や宇宙船じゃないけど、一貫性は必要。対話が成立しなくなる
エンターテイメントでもいい加減なものではなく、大事なものであるという認識を我々は持ってる
全てのデータは暖かい
ホットなデータは人と時によって、違う。どれも重要。
リアルタイムでオブジェクトを扱う
パーミッションも同期処理。シンクロナスコールがたくさん。
水平スケーリング
システムのオブジェクト全てをマシンにのせる
LB->AppServer->Cache->DB
ユーザーが友達とインタラクションすると、キャッシュが膨らむ
App
Cache
memcachedに注力してる。秒間１０億read
NWのボトルネック
DB
DBではなくストレージだと思う
インデックス効かないと話にならない
NoSQL
いいか悪いかの宗教論ではない
NoSQLもMySQLも使ってる
スケーリング
ボトルネックを取り除く
エラーハンドリング
NWボトルネック
起こりやすい
帯域の問題ではない。
１つのAppからたくさんのCacheにリクエストをたくさん投げる。レスポンスで失敗するので、リトライを短くする。失敗するってことは多分過負荷。そんな時にリトライを短くすると助長する。
ー＞解決策は全てのキャッシュサーバーに同時にリクエストを投げない。分散する。
「ミスをゼロにするのではなく、それにかけるコストを減らす」
ミスをしないのはなにもしないこと。facebookはトライしてみる精神。
スタートアップ企業の性質と一緒。
小さな問題が大きな問題にかわるとき
SPOF
ソフト自体がSPOFという問題はあまりでてこないが、結構ある
ハードの問題点という方が言われがち。
ソフトのリリースを段階的にしていくことが重要
increaseing load under load
リトライをし続けないこと
funnneling badness
ある問題によって、別の問題が顕在化してしまうこと？
問題のパーセンテージをトラッキングして、しきい値以上だったら対処する。
everyone waitng
一台が遅くなると、他のものも全部遅くなる？
既に待っている状態で、行列を増やさない
◎大事なこと
・失敗をテストする。「夜も寝られない心配があるなら、そのソフトウェアは壊せ」
・全てを監視する
平均値は無意味。分布を見る。故障は少数のマシンで起こる
・事後解析。何が起きたのかを十分時間かけて解析する。
post-mortems
MySQLの分散
数学的なマッピング。たくさんのバケツを用意する。
（要はマネージャ分散っぽい）
全てのマシンにキャッシュがある
細かくシャッフルしてるけど、問題ない
（Q）ユーザーのアクティビティ性に応じて特殊対処してる？
友人数の上限があるのでパンピーは一緒
有名人アカウントは色々やってる
更新頻度が高いので
（Q）意図的になんかを壊すとは？
IPテーブルルールを用意して、NWをおかしくする。電プチするとか。
ツールがあったとかわけではない
カーネルがおかしいとか起こる
======感想=========
SNSを作られているFacebookさんのセッション。
ソーシャルの説明もその通りですねと。
＞「ミスをゼロにするのではなく、それにかけるコストを減らす」
＞事後解析。何が起きたのかを十分時間かけて解析する。
とにかくミスは起きるもの、と捉える。同意。検証と再発防止も大事。
業務経験上、ミスの透明性が重要だと思っているけど、そこら辺の共有・周知のルールや考え方などどうしているのか気になった。
ソフトウェアがSPOFはなるほど！そういうものを自分達は扱っているし、作っている。新しいハードはテスト検証しながら導入するくせに、自分のコードは豪快にリリースする、っていうのは確かにおかしいなぁと思った。段階リリース大事。
NWのテストのために、電プチしてみるとか凄い。しかし、避難訓練としてやった方がいいかもしれないと感じた。お客のデータに障害が起きないようなレイヤならいいのかなと思う。
===================
Twitterの最新アーキテクチャ
ツイッターのミッション。
ツイッターはSNSではない。リアルタイムコミュニケーションネットワーク
7196tps なでしこ優勝時。tweet per second
25088tps バルスの時。
バルス準備は特に何もしてない
1.4億アクティブユーザー。1日3.4億ツイート。約70％のアカウントは米国外
◎アーキテクチャ
timelineDB、tweetDB,social graphDB,userDB
最初はRailsでどかっと。
問題点：１カ所に固まりすぎ。Rubyがそこまで爆速なわけではない。
Modelを分割化。user service , tweet serviceなど。プロセスが別。実装が別。
各serviceはJVM。scalaで動いてる。
SOA的なアプローチ。
SPOFにならない
リバースプロキシ -> Rails -> DB
ハードウェアバランシング。だった。
今：HTTP Proxy -> API -> service -> DBのルートも。Railsルートもまだある。
HTTP Proxy -> WebI -> service -> DBのルートも構築中。
JVM化 = Off the Rails.
膨大な同時接続数
多量のIO
ごく少量の永続化対象データ
ほとんどは読み込みデータ99%以上。readが鍵。
※「ツイッターはinterest graph」
必要なのは
サーバー負荷を適切にさばく。
言語対応の柔軟性。現時点ではJava,Scala.
成熟したコンカレンシーモデル
javaのコンポーネント
検索周りでたくさん使ってる
トレンド／キーワードクラスタリング
javaによりもたらされるもの
拡張可能な開発エコシステム
成熟したJIT
管理されたメモリモデル
finagle
非同期にRPCを実行できるフレームワーク
タイムラインのトラフィック
20万クエリ／秒
レイテンシー
中央値1ms
99パーセンタイル4ms
秒間4kツイート
ピーク時10kツイート／秒
配信： 秒間1800万ツイート
100万のフォロワーに対して、3.5ms
ツイート書き込みの流れ
HTTP Proxy -> tweetAPI -> Queue -> tweet Daemon-> fanout =>delivery
-> timeline cache -> redis
fanout : 4000人のフォロワーずつにわけて配信
レディーガがレベルだと、RTのが早いとか
ツイート読み込み
Proxy -> timelineAPI -> timeline service -> timeline cache -> redis
======感想=========
「twitterはSNSではない、インタレストなぐラフ」を複数回繰り返していた。なるほど、そうですか。
Railsでえいやで作ったものを、徐々に疎結合・別システム化していったとのこと。この辺は負荷とサービス規模が
予想を遥かに超える感じで大きくなるサービスでよく進めていけているなぁと強く関心しした。
サービスそのものの変化がそれほどない分リファクタ感覚が近いのかもしれないが。。
1個前のfacebookのプレゼント比較して、技術者集団っぽいなという印象。良い意味でベンチャー気質があって、
エンジニア主導で進めていそうな雰囲気を感じた
===================
現場で使えるドメイン駆動設計
casandraのコミッタのエリックエヴァンスとは別人
2003年出版の本。原著は。javaにgenericsがない時代。
顧客の仕事を理解すること
顧客の言葉で理解する事
モデルを共有すること
モデルを基にソフトウェアを作る
設計思想と実装方式
実装方式としてのDDD
ユーザーインターフェースを通じて、ユーザーとデータをやりとりする
ユーザー-> UI -> ロジック -> 永続データ
ロジック構成方針
トランザクションスクリプト
ユーザーの要求を満たす手続き
ドメインモデル
複雑なロジックをオブジェクト指向で解決する
ロジックが複雑化すると、トランザクションスクリプトのメンテコストが増大する
分岐点はどこなのか
慣れた人に任せるしかないよね
手続きとは？
入力チェック、DBアクセス、演算、編集処理
どういう時に使う？
ドメインモデルが論理データモデルで表現しきれる場合、ロジックはほぼSQLで表現できる
->SQLを気持ちよく使う
ドメインモデルが論理データモデルで表現しきれない場合とは？
「暗黙的な概念」 制約・プロセス・組み合わせがあるルール
制約
制約は論理データモデル上に表現されず、手続きとけ込んで見えなくなる
オーバーブッキングの概念がif文の条件に入る
ただし、制約をすべてオブジェクトとして実装する必要はない
設計思想としてのDDD
ハイレベルのドメインモデル 業務の境界と関係を明確化
各ドメインのモデルを詳細化し、実装方針を策定する
トランザクションスクリプトが基本とする
複雑化は囲い込み、適切なモデリングパラダイムを選択する
Big Upfront design?
考える事は重要。期限と予算
実装方式と開発プロセス
トランザクションスクリプトを基本にする理由
基本設計をかきやすい
ほとんどの開発者にわかりやすい
ウォータフォール
手戻りが許容範囲に収まればアジャイルよりも安いし早い
３つの真実<->仕様変更した方が早い場合もある
プロトタイプは当然作る、CIも重要
複雑なドメインに対してはそれなりの戦術が必要
基本設計が書き難い 要件が整理しにくい
イテレーティブ、インクリメンタル
シナリオはモデルに目的を与え、モデルはシナリオを実現させる
実装方式の策定はメンバの力量や期間と相談
まとめ
業務を理解しよう
業務を表現したモデルを共有しよう
適切な方式とプロセスで実装しよう
ウォータフォールの手堅さ、アジャイルの柔軟さ
チームで実現できるアーキテクチャを
======感想=========
ホントは、いかにしてドメイン駆動設計を行うかを聞きたかったのですが、内容としては
「まぁまぁ落ち着いて。身の丈・状況にあった時だけ使いましょう」というものだった。
確かにSIの現場を考えたら、現実解というか非常に的を射た答えだと思った。
アジャイルと同様、言葉が先行してしまうのは確かに良くない。
===================
ソーシャルゲームにおけるAWS／MongoDB利用事例
MongoDB
ドキュメント指向
フルインデックスサポート
レプリケーション
replicaset セカンダリの自動昇格。その間自動リカバリ
auto-sharding
指定したshard keyで水平分割
Animal Land
町づくりゲーム
S3 htmlや画像の配信
CloudFront 海外対応
Ehcache - javaプロセスでキャッシュする
RestFB facebookにアクセスのため
======感想=========
このまとめを書いていたので、軽く聞く程度で。。
資料はサイトからDL可です。
===================
まとめると、オフィシャルというか大人な内容の発表が多かった。
聞く方も大人で、業務に活かせる部分があるかマッチングにしに来ている感じでした。
懇親会でほとんど絡めなかったのが反省点。
