YAPC::Asia2015参加レポート（Day1）
8月21日(金), 22日(土)に、YAPC::Asiaに参加してきた。
YAPC::Asiaは今年で最後ということで、会場はなんと東京ビッグサイトだった。
参加セッション一覧
私が参加した8/21のセッションは次の通り。
- 8/21
- メリークリスマス！ by Larry Wall
- Managing Containers at Scale with CoreOS and Kubernetes by Kelsey Hightower
- Consulと自作OSSを活用した100台規模のWebサービス運用 by fujiwara
- Perlで学ぼう！文系プログラマのための、知識ゼロからのデータ構造と計算量 by Shinpei Maruyama
- Electron: Building desktop apps with web technologies by Ben Ogle
- esa.io - 趣味から育てたWebサービスで生きていく by Atsuo Fukaya
セッションの感想＆内容
参加したセッションの感想や内容を書く。
なお「内容」は、理解し切れていない部分や誤解もあるはずなので、参考程度に見て欲しい。また誤りを指摘できる人は指摘して欲しい。
メリークリスマス！ by Larry Wall
感想
- スピーカーはPerlを作った方。英語めっちゃ聞きやすかった。
- Perl5, Perl6はホビット, Load of the Ringと似てるみたいな話をしていた。LotRネタわかったので、ニヤニヤしながら聞いてた。
- Perl6を今年のクリスマスに出せるように頑張ると言っていた。
Managing Containers at Scale with CoreOS and Kubernetes by Kelsey Hightower
感想
- デモを交えたKubernetesの解説。
- 8/19のDocker Meetup #5で同じプレゼンを聞いてはいたんだけど、そのときは同時通訳がなくてほぼ理解できなかったので、もう一回聞いた。今回は同時通訳のおかげで、概要は何となく理解できた。
- デモが良かった。コンテナ時代のアプリ管理はこうなっていくんですよ、と概念的に説明されていたところを、実際にデモしてくれたという印象。
- Kubernetesのダッシュボードがかっこよかった。
内容
- 「Ansibleなどの構成管理ツールは、"マシンの管理"というところに重きを置いているため、物理サーバ、VMの管理には向いていても、アプリの管理には向いていない。それではアプリがスケールしないので、アプリの管理はスケジューラでやる。」という導入の後に、スケジューラとしてKubernetesが紹介された。
- 続いてKubernetesの構成要素として以下が紹介された。
- node: CPU, メモリなどのリソース
- pod: コンテナを束ねる単位。1つのpodの中ではnamespaceを共有する。
- scheduler
- replication controller: podの数を1つから3つに増やすときに使う。自己回復機能がある。
- service
- その後のデモでは、pod内のコンテナの増減やバージョンアップの様子がデモされた。canaryパターンというものが紹介されていたが、何なのかよくわからず。
- 質疑応答
- Q 様子がおかしなコンテナのトラシューはどうするのか？
- A トラシュー用のpodを作ってそこでトラシューするのが良い。
- Q Immutableの文脈では、開発環境で試験したコンテナをそのまま商用環境に持っていくという話があるが、Kubernetesもそうするべきか？
- Q パーシステントデータの扱いは？
- A (Kubernetesの)Schedulerではパーシステントデータを持つPostgreSQLのようなDBは扱えない。etcdを使う。
- Q 様子がおかしなコンテナのトラシューはどうするのか？
Consulと自作OSSを活用した100台規模のWebサービス運用
資料
感想
- Consulは気になりつつ触ったことなかったので、実運用で得たノウハウを聞けて大変参考になった。とくにConsul導入の目的が聞けてよかった。Consulの機能は何となく知っていたが、使いどころがわかっていなかったので。
内容
- Consul導入の目的
- Serverは3台以上推奨で、1台がleaderとして選出される。(Raftアルゴリズム)
- 使いやすいKVS機能がある。デフォルトでは、問い合わせに応答できるのはleaderノードだけ。なので負荷はleaderノードに集中する。stale modeにすると他のノードでも応答できるようになる。
- メモリフットプリントは20MBくらい。省リソース。ディスクIOhは少ないところに入れるべき。
- leaderノードがクラスタはずれた際の次のleaderノードの選出は2～3秒で終わる。その間DNS引けなくなる。それが挙動できないならstale modeを使う。
- クラスタは一度動かしたら基本は止められない。
- オペミスでクラスタが崩壊するとKVが消えるので要注意。定期的にバックアップを取っておく。
Perlで学ぼう！文系プログラマのための、知識ゼロからのデータ構造と計算量
資料
感想
- 期待していた内容を聞けた。2日間で一番満足度が高いセッションだった。
- データ構造、計算量、DBのアクセス方法のそれぞれは知っていたが、自分の中でそれらが全然繋がってなかった。このセッションがその部分を繋げてくれた。
- 何かの書籍の内容をそのまま講演にしたのではないかというくらい、体系だっていてわかりやすかった。
- 2日目の「ISUCONの勝ち方」で早速B+木の話が出てきて、この発表聞いておいて良かったって思った。
- オススメ参考書籍はないということだったが、自分が知る限り、データ構造についてはこの本が分かりやすかった。C言語ポインタ完全制覇
内容
- スピーカーはprocess-book書いた方。
内容
当日のメモそのまま貼り付けただけ。。。
事前知識
- shortは2byte。だけどメモリの番地はintだから、short*は4byte使う。
- じゃあshortって何なん？→メモリの番地読みいったとき、先頭の番地は分かっても、
そこから何byte読めばいいかわからん。ここでshortというデータ型が必要。
データ構造
- 値そのものと指し示す値
No.1 配列
- Cの配列って面白くて、必ず連続したメモリ領域に配列を確保する。
- 問題もある。追加で要素が欲しいとき、次に配列領域伸ばせるかって言うと、分からない。
もう使われているかもしれない。
No.2 単方向連結リスト
- 配列は連続したメモリ空間でないといけなかったが、連結リストは飛び飛びでOK。
- 配列は計算して目的の変数に一発アクセスできたけど、連結リストだと
じゅんぐりじゅんぐり計算しないと一発アクセスはできない。
計算量の話
- オーダー法。n回の計算も2n+1回の計算も、オーダー法的にはO(n)。
- 配列はO(1)？かな。
- 連結リストはO(n)。悪くないけどO(log n)だと嬉しいよね。
２分木
- 2分木で探索するとき、全部見なくていい。O(log n)で済む。
- 意味ないとき→最初が1で次に1→2→3→4となっている場合。
いやこれって連結リストじゃん、ていう。
B木
- 勝手にバランスしてくれる木。
- 満員になったら真ん中のやつを上にしていく。
- 木の枝を降りていく計算は基本O(log n)
- 問題: シーケンシャルアクセスやりにくい。
B+木
- DBのインデックスとかに使われているやつ。
- B木は値をmoveしているところ、B+木はcopyする。
するとリーフの部分はシーケンシャルに並んでいる。
Electron: Building desktop apps with web technologies by Ben Ogle
感想
- このあたりHPが底をついてしまって、発表が頭に入ってこなかった。
- Electronという名前と、AtomがElectronの上に構築されているということだけわかった。
esa.io - 趣味から育てたWebサービスで生きていく
資料
感想
- esa.ioというサービスはこの発表を聞くまで知らなかった。
- 端的に観想を言うなら、「カジュアルだな。。。」と。この一言に尽きる。
- 情報共有ツールとしてQiita:Teamを使っていたが、有料になったので、同じようなものを自分で作った。それでいけそうな手ごたえがあったので、会社作ってそちらに専念することにしたと。
- いくつもサービスを作って経験を積み、いけそうなサービスで勝負する、というのは素晴らしいと思った。
- スピーカーがサービス開発において取り組んでいることは、既にWebなどで「こんな風に開発するといい」といわれていることが多くて、斬新なことをやっているという印象は持たなかった。これは、今「こんな風に開発するといい」とされていることをきっちりやれば、食べていけるようなWebサービスを作ることができる、ということを証明してくれているので、他の開発者にとっては希望になると思った。
- 情報共有ツールの現状のシェアでいえばQiitaのほうがリードしていそうなので、今後の展開に注目していこうと思う。
