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のほうがリードしていそうなので、今後の展開に注目していこうと思う。
JTF2015参加レポート
まえおき
今年もJTFに参加してきた。
去年はJuly Tech Festaといいつつ6月だった気がする。
個人的には、開催時期は6月のほうがうれしい。
7月後半は子供たちが夏休みということもあり、6月に比べて世間で他にもいろいろ魅力的なイベントがやっているので。
まぁまた来年もやるなら7月でも行きますが。
簡単にレポートを書く。
ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから(@horiuchi)
資料
感想
- 「AWSの堀内さん」しか知らなかったので、堀内さんのこれまでの経験を踏まえて、これからのエンジニア像を語ってくれた本セッションは面白かった。
- 堀内さんがAWSのエバンジェリトだった頃、AWSの新サービスが登場する度にそのサービスの概要やメリットを分かり易くユーザ伝えている堀内さんを見て、何故こんなに幅広い分野のサービスを理解できるのだろう、と不思議に思っていた。
この発表を聞いて、それを可能にしていたのは、ベンチャーCTO時代に様々な技術に触れた経験が大きかったんだろうな、と思った。 - なので、最後にスタートアップCTOがお薦め、という話が出てきた時、それまでの話の流れからガラっと変わった印象を持ちつつ、妙に納得した。
マイクロサービスで、一歩先行くImmutable Infraを目指そう(@sho7650)
資料
ざっくり要約
稼動したシステムには変更を行わない"Immutable Infrastructure"という考え方が出てきた。
mmutable Infrastructureを実現するときは、ステートレスなサーバ(Web, App)とステートフルなサーバ(DB)でやり方を変えよう、というのが今の流れ。
上記のようなシンプルな図を眺めている分にはそれで良さそうに思えるが、実際にImmutable Infrastructure実現しようとしたら、話はそう単純ではない。
エンプラなシステムなどは接続先がたくさんある。あるサーバ切り替えて周りのサーバが落ちる可能性がある。これは課題。
この課題の解決策としてマイクロサービスが出てきた。
マイクロサービスのポイント
コンポーネント化する。
コンポーネント化とは、インタフェイスを明確にすること。ロジックに変更があってはいけない。
- メモリをコンポーネントと考えると、速くなった、容量が大きくなったはOK。機能が削減されて、今まで通ってたロジックが通らなくなったはNG。
上図ではブルーとグリーンでインタフェイスが変わってなければ、どんな複雑はシステムでも、ブルーグリーンデプロイメントできる。
作ったプログラムはプロジェクトとして扱うのではなく、プロダクトとして扱える。
- プロジェクトとして扱うと、始まりと終わりができる。そうではなく、プロダクトとして捉え、開発者が最初から最後までやる。
- 同期はREST, 非同期はMQなどシンプルな構造にする。
最近のマイクロサービスの文脈では、「どうやって？」という部分の話はあまり出てきていない。
そこは、これからみんなの知見が集まっていかないと話ができない部分。
=> SOAの知見が役に立つのでは？
SOA
- マイクロサービスでcomponentといっているものを、SOAだとサービスと言っている。サービスは一番小さな単位。
- サービスの規約は何でもいいと言っている。REST、MQなど手段具体的な実装方法については言及していない。
- だから、SOAはマイクロサービスに比べると、自由度が高い。
- プログラムの考えで言うと、構造体→オブジェクト指向→SOAという流れ。
- Service Repository。サービスを登録しておくところ。サービスのHUBみたいな。
マイクロサービス vs SOA
SOA ロードマップ
- 基礎段階: 保守性の向上
- ネットワーク化段階: カプセル化。中継層に担わせる。中継層･･･技術的に難しいことを担わせる。
プロセス制御段階: 俊敏性の向上。
- SOAのプロセス制御は、普通のセッションより長くセッションを保とうとする。普通ログアウトしたらセッションは切るが、SOAだとログアウトした後も保とうとする。
まとめ
- 新しいものと古いものを組み合わせて使う。
- 車輪の再開発はしない。
- Re-usable not Re-cycle
- もともと再利用可能しておいてそれを使うのと、あるから使うというのは全然違う。後者は辛くなる。
感想
去年会社の勉強会でマイクロサービスって考え方が流行りつつあるらしい、という話をしたら、「それSOAと何が違うの？」と言われて、SOAを知らなかった自分は「？？？」となった。
RebuildでもマイクロサービスとSOAについて言及してた気がするけど、「SOAはエンプラ臭がする」とかそんな程度の話だった気がする。
そんな感じでマイクロサービスとSOAについてはかなりもやっとした理解しかなかったのだけど、この発表を聞いて、マイクロサービスとSOAの違い、何故マイクロサービスの文脈でSOAを出す必要があるのか、といったあたりを理解することができた。参加してよかった。
MONITORING DOCKER(@jhotta)
資料
なし
ざっくり概要
- datadogで働いている。
- datadogのblogで、監視についての連載を始めた。Monitoring 101: Collecting the right data
- monitoringをDIYしていると、機能追加なんてできない。
- monitoringツールを作ることが、競合との差別化に繋がるのか？というところは考えて欲しい。
- Docker監視で「コレだ！」というのはまだない。
- WHY DOCKER USERS MONITOR
- ステータスみたい
- Docker Engineが壊れているの？特定のコンテナ？それとも周辺ツール？というのが知りたい。
- タグや正規表現によってグループ化できる監視ツールでないと、コンテナの監視は辛い。
- dockerのメトリクス取れる場所(後者２つは正しくない。）
- cgroups
- docker api
- in-container agent direct monitoring
- kernel hacking
- NewReric - eventとmetricsを紐付ける機能が弱い。
- SYSDIG･･･カーネルハッキングしている。
- SIGNALFX･･･今後注目。メトリクスの関連性の取り方とかいい。後発で、勉強してきたイメージ。 メトリクスの測り方は他と違う。
- LIBRATO･･･fluentd
- PROMETHEUS
感想
- コンテナの監視を設計する日が来たらとりあえずdatadogのblogを読んでみようと思った。
最前線で戦う若手インフラエンジニアたちが語る「技術トレンド」と「数年後の未来」(@y_uuk1, @catatsuy, @hfm, @deeeet, @rrreeeyyy)
資料
概要
- ブロッコリーのブログによくまとまっている。
感想
- プロビジョニングツールの話のところで、サーバ設定の"設計の難しさ"とプロビジョニングツール自身の扱いの難しさが混同されることが多いから、そこは話解き分けたほうがいいという話があって、それは確かに気をつけたほうがいいと思った。
- プロビジョニングツールやコンテナなど技術的な話も参考になったが、それよりもチームとして成果を出すためにどんな取り組みをしているかという話が参考になった。特に@hfmさんの研修の話やチームメンバのアウトプットが共有される仕組みづくりの話など。
運用に自動化を求めるのは間違っているだろうか(@zembutsu)
資料
概要
資料を読めばOK。
感想
発表中に出てきた次の2つの考え方がすごくしっくりきた。
- 働いたら負けでござる。刺身タンポポ業や写経文化の中で働いたら負けでござる。
- DockerやHashiCorpのプロダクトが流行っているが、一つのツールが全ての課題を解決できる銀の弾丸になるはずはない。
なのでそれらを手札と捉えて、使えるツールを増やしていき、最強のカードデッキを作るようなイメージを持つ。
おわりに
- 今年もいろいろな話が聞けて楽しかった。来年の参加したい。
- 電源が欲しい、電源が欲しい、電源が欲しい。
- 休憩時間にやっているスポンサーのハイアリングセッションが面白かった。
