IIJ Technical WEEK 2014 1日目 #iij_tw2014

堂前@IIJ @IIJ_doumae

OSスレッド: 直線的なコードをそのまま再利用できる。複数のコアを自動的にOSが活用してくれる。しかし、コンテキストスイッチが発生するため、遅くなる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

イベント駆動: 今までのプログラムは捨てる。イベントハンドラに処理を分割。プロセスが切り替わらないので速い。そのままでは複数のコアを活用できないので、プロセスのpreforkしを併用することで複数コアを活用。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

イベント駆動のデメリット。コードの見通しが悪い。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

Haskellでは軽量スレッドが提供されている。見通しのよいコードを再利用しつつ、コンテキストスイッチを最小限に抑え、コアの性能をひい出すことができる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

ファイルのオープンはlockを伴うので遅い。ファイル記述子をキャッシュして再利用したい→Haskellは軽量スレッドで共有メモリ中にキャッシュを持てるので、これを活用することができる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

探索木を高速な辞書として利用する。ファイル名がキー、ファイル記述子を値として利用する。Haskellでは木構造は不変(書き換えできない)の安全に利用できる。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

Haskellでは不変データが一般的。こういう型があるからこそ、Haskellでは軽量スレッドを作ることができた。他の言語では軽量スレッドを作ろうとして断念しているケースが多い。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

Haskellで可変データを作る場合は、参照を使う。データ自身は不変だが、参照先を張り替えることにより、可変データを実現することができる。参照自体はスレッド間の競合ポイント。安全を確保するためにはロックする #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

ロックを減らすために工夫していたのに、木構造を守るためにロックしていたのでは意味がない。HaskellではそこでCASを使う。CASはCPUが提供する命令。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

遅延評価との併用。「あとでやる」という命令だけを発効しておくことで、CASの成功率を高める。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

ロックの問題点。粒度が小さいと必要な場所のロックが漏れがち。粒度が大きいと速度が出ない。 デッドロックの発生。デッドロックの古典的な解決方法は、ロックに優先順位をつけることだが、面倒で間違えやすい。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

Haskellではどうする？STMを使う。複数のロックを一つに見せる技術。デッドロックが起こらない。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

翻訳しました「Haskellによる並列・並行プログラミング」oreilly.co.jp/books/97848731… #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

このあと20分の休憩に入ります。再開は15:50。会場ではコーヒーブレイク中です。 #iij_tw2014 bit.ly/iij_tw2014

Tetsuya Morimoto @t2y

言葉と概念の定義は大事、とても分かりやすかった #iij_tw2014

Tetsuya Morimoto @t2y

軽量スレッドのような仕組みは、命令型言語では難しくて諦めたというのはそんな風にみえるけど、stm は haskell に限った話じゃなくてまだまだ命令型言語もがんばってるんじゃないのかな？時間がなかったからちょっと消化不良で終わっただけだと思うけど #iij_tw2014

山本和彦 @kazu_yamamoto

時間は余る予定だったのですが、足りなくなって、最後は駆け足になってしまいました。すいません。 #iij_tw2014

堂前@IIJ @IIJ_doumae

次のセッションは「IIJ社内におけるアジャイル開発、DevOpsへの取り組み IIJプロダクト本部　基盤プロダクト開発部　応用開発課　弓山 彬」です。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

サービスの開発の流れ。分析(要求定義)→設計・開発→テスト→リリース。これを「繰り返し」実行する。従来IIJはこの流れをウォーターフォール的に行うことが多かった。短いものでは2〜3ヶ月のサイクル。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

2〜3ヶ月のペースで繰り返していると、ユーザーからのフィードバックを反映するのにそれだけの期間がかかってしまう。フィードバックを速やかに反映するため、開発サイクルを短くしたい。アジャイル開発を参考に実践 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

ウォーターフォールを容易に変更することは難しい。4つのフェーズについて、様々な工夫を行うことで理想の開発を目指してきた。 #iij_tw2014 bit.ly/iij_tw2014

堂前@IIJ @IIJ_doumae

バージョン管理システムの変更。従来はSVN。多人数の開発には向いていない。同じファイルを複数人が編集すると正しく反映されない。規模が小さければ頑張って修正すればよいが、規模が大きくなると大変。修正時にバグが混入することも #iij_tw2014

眼力 玉壱號 @objectxplosive

Subversion、3way merge 入ったの結構最近で、それまでは『分岐元を自分で指定してねー』という厳しい仕様だったからなあ #iij_tw2014

堂前@IIJ @IIJ_doumae

SVNで共同で開発するためには、コミュニケーションを密にする必要がある。マージのコストが高い。できるだけマージしないように一つのブランチを共有すると、試行錯誤がやりにくくなる。 #iij_tw2014 bit.ly/iij_tw2014