YAPC 2014
YAPC は BLOG にするまでが YAPC です。と言っていたので、記念に手元のメモを投稿します。 とにかく写経のつもりで目耳に入った事を無心でテキストにしたので、typo や意図が分かりずらい箇所あると思いますが、まぁ！細かいことは気にしない！
印象的だったのは、以下の本が別の発表で 2 回出てきた事。
元々持っていたけど、やっぱり良本やったんやね。
完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ
- http://yapcasia.org/2014/talk/show/4c7651e8-ed53-11e3-9faf-6ba36aeab6a4
- http://blog.kenjiskywalker.org/blog/2014/08/29/yapcasia2014-cosmo/
- https://speakerdeck.com/kenjiskywalker/yapcasia2014
- @kenjiskywalker
web サービス誕生の瞬間
２つの必要なこと
- 同じ環境をもう一度作れるという記録
- 保険を作る。冗長化。データのバックアップ
なぜ必要な
- HW は壊れるし、
- 人間はミスをする
- web サービスは継続できる！
ユーザが増えて負荷が増えてきた
- 負荷が増え閲覧困難
- 複数のサービスを一つのサーバに入れていた
- 機能毎にサーバを分ける
- レンスポンスが上がり、サービスを継続できる！
スケールアウトに必要なこと
- 再現性が必要、いつでも同じものがどこでも作れる → * 簡単にスケールアウトが可能
- 簡易性、シンプルに作る → 依存関係を作らない。疎結合。
- 変化に強いサービスが作れる
機能が増え、複雑性が増える
- 再現性が必要（AWS だけとかオンプレだけとかの縛りを作らない！）
- 簡易性、スケールアップやスケールアウトが簡単に出来る
- 機能が増える毎に大変になってくる
- → 運用負荷が多少軽減出来る
- → 変化に強いシステム
時は流れ
- 障害とかオペミスを経て...
- システムは成長していく
記録や保険の精度について
- 問題と対策。対極に存在する。時間はコスト。どれだけコストをかけるか判断は難しい
- 時間,コスト,リスクのバランスを見て、決定する
- 必要以上のものは作らない、その場その場で判断するしかない
そろそろ旅が終わる
システムも人間も世界も完璧ではない
- 変化に強くある必要がある
- Web サービスは続いていく
QA
- Q. リスクをどう考えるか
- A. ダウンタイムとの兼ね合いになるしかない
- Q. 人命とデータどっちが大事か
A. ノーコメント。でもデータのほうが優先される時代（がんばろう
Q. トークに応募しようと思ったきっかけ
A. 新しい風をふきこみたいのではと思った。とりあえずビッグウェーブにのるしかない。
Q. Web サービスは長生きする。人間が先にいなくなるケースはどう思うか
A. 記録を取ることに尽きる。完璧なドキュメントがあれば人間依存はしない。
Q. 理想でなく現実を
A. サーバに入って確認しろ
Q. 完成されたシステム or 未完成のまま膨らむシステムどちらがいいか
A. 難しい。完璧なシステムが最初にあればいいけど。
Q. この話をするにあたって頭にうかんがサービスはあるか
A. 特に無い。この世のサービスは全部素晴らしい
Q. 完璧なシステムの必要性を技術者ではない相手に伝えるには
A. ぶっ壊して見るのが早いけど...やらなかった場合とやった場合のリスクと時間について理論建てて説明すれば人間であれば伝わるはず
Q. シンプルでないシステムに対してどうするか
A. ケースバイケースだけど、全体を見渡すこと。局地的では勝ち目がない。相手を把握すること。その後、課題を一つ一つ解決していくこと。
40 分あるのに 20 分で話が終わって QA がだいぶ賑わった。 全体期にスピリチュアルな話し、要はサービス継続にあたって再現性とか冗長性大事だよね。という事。
最近のウェブサービスの検索機能やその先の話
http://yapcasia.org/2014/talk/show/2718b8f2-0331-11e4-9357-07b16aeab6a4
@yanbe hatena の人
自己紹介
- はてなの人
- はてぶ
最近はてぶについて検索機能を紹介
- 期間指定が出来る
- フォローしているブックマーから検索（お気に入りの人だからノイズが少ない）
- フォローしているユーザのグループから検索
- http:// を省略してサブドメインを横断して検索
- Presso というアプリにも使われている
- 今日はこの辺りの話し
その前にはてブの検索の歴史
Search::Elasticsearch
- Elasticsearch, Inc で公式メンテ
- 作者に変な思想がない
- 全部の機能が利用できる
- 通信部分だけ別プロトコル、拡張性が高い
- → 余計なものが無い
- Elasticseach の mapping
- 複雑なクエリを表現できる
- 自分のブックマーク且つクエリにマッチ
Presso の紹介
- 検索条件を管理画面から設定できる
- この設定画面から Elasticsearch のクエリを生成する
- Query DSL の高い記述性がある
- 検索条件を管理画面から設定できる
はてブ数カウンター
まとめ
- なぜ Elastcsearch
- Query DSL の自由度
- 企画の自由度が上がる
今後の予想される展開
QA
- Q. リインデックスをはてなではどうしているか
- A. リインデックスでは、サーバを一つ用意して、切り替える運用
作られては消えていく、泡のように儚いクラスタの運用話
http://yapcasia.org/2014/talk/show/9e3ced48-027f-11e4-9357-07b16aeab6a4 http://sssslide.com/www.slideshare.net/tsuyoshitorii5/yapcasia2014-2-public
@toritori0318 株式会社バスキュール
- 立ち位置、DevOps の真ん中にいる
- TV とスマホを同期する仕事
- 事例紹介
- スマホで投票受付してリアルタイムで TV で表示
- バックエンドhが M.I.E.S というプラットフォーム
- サーバサイドを担当
- リアルタイム同期
- 画像変換
- 視聴ログ集計/解析
- はなすこと
はなさないこと
- フロントエンド、アプリレイヤ
TV案件の特徴
アクセスパターン
- 曜日/時間帯/企画内容からユーザ規模がある程度わかる
- どこに負荷が集中しやすいか、特的出来る
- 一発勝負なので本番怖い
怖いのを軽減させるので、Punisher を作った
- NodesJS 正ベンチマーククラスタ
- Javascript で記述
- 機能
- 書いた理由 -> 状況を完璧に再現したい
シナリオ例
- 30分間に３０万人が処理
- 30万人接続した状態でブロードキャスト送信
- 上記を Javascript で記述
良い副作用
- シナリオを書くことにより、事前にあぶない部分が判明する
- 前よりは安心して本番を迎える事ができるように
監視
運用改善の話しその１
- MIES の話し
- 案件をこなしていくうちに、事前に出来上がった
- 共通化したり汎用化したりを繰り返した
- 案件をこなしていくうちに、事前に出来上がった
- ServerTeam
- 3 人
- 言語は Node.js , Python ,Perl
- 俺が SPOF じゃね！？
- サービスごとの秘伝のタレ
- 開発環境、デプロイ、構築、スケール管理
- サービスごとに運用できる人が１人
- ほかの人が手順知らない、工数もお金もかかる
- 解決したいこと
- 運用の手順は統一化しよう！
- 開発フロー/デプロイ/クラスタ構築/スケール管理
- CI しやすい
- 引き継ぎしやすい
- ミスしにくい
- 開発フロー/デプロイ
- プロビジョニング
- Cefh + Berkshelf
- クラスタ管理
- AWS CloudFomation
- スケールコントロール
- AWS AutoScaling
- 自動スケールは期待してない、スケールの管理を共通化したいという思い
- MIES-Provision-Task
- 開発フロー
- Vagrant コマンドを Rake でラップ
- イメージ保存
- vagrant-ami
- スケール管理
- CloudFomation でパラメータで指定
- Rake タスクでも用意しておく
- インフラ共通化
- Superviosr
- MIES の話し
Rake タスク
ここまでで、共通化してだいぶ改善された
運用改善の話しその２
さらに改善
まとめ
- 24/365稼働サービスは、頑張るところと、手を抜くところが違う
- 要件にあった運用改善
- まだまだ改善したい
- それでも本番怖い
自動化とかだいぶ進んでいる印象、サービスの特徴に伴って環境の形態を変えていくのが面白かった
Git を使ったツール開発
- http://yapcasia.org/2014/talk/show/a88619fc-034a-11e4-9357-07b16aeab6a4
- http://motemen.hatenablog.com/entry/2014/08/29/talked-at-yapc-asia-2014
以下宣伝
- Git のはなしだよ、ギットギト
ghq 作りました
- Go lnag
- いい感じに git を管理する
- GHQ という別の存在によりググラビリティが低い
- 今となっては後悔している
git-browse-remote
git-pr-release
- GitHub の PR をまとめる
github-commit-status-mark
- CI 通ったかどうかをひと目で確認
git unify
共通点 * .git/** 使っていない * git のサブコマンドを利用している * git help -a
暗黙の引数
- ユーザが改定しているもの
- リポイj取り内のでの実行
- HEAD（ブランチ
- 今いるブランチが想定される
- 昔はリモートブランチが全部プッシュされて事故になった
- ユーザが改定しているもの
Git
- リビジョン？オブジェクトを指す何か。
- SHA1, 名前, ほか, git が進化すると増える
- rev あれこれ
- refname (シンボリックネーム
- タグ/ブランチ/リモート
- 実体は .git/ 以下
^{n} - 何時間前とか指定できる
- DWIM
- ユーザが何を言いたいのか良しなに把握する
- git-symbolic-ref
- 元始、.git/HEAD は symlink
- 今は ref: refname とか
git foo bar
- git --exec-path
- 実行ビットが経ってない奴
- git-sh-setup からスタート
- 便利関数たち
- NONGIT_OK
- OPTIONS_SPEC
- オプションをいい感じにぱーすしてくれる
パス
- ファイルからのルートからのパス」
- git rev-parse
git config
git にここまで機能があったとは... git のバージョンによって 'いい感じ' に解釈してくれる挙動が変わってきているのは面白かった。 ドキュメントとか見るとこんな事出来るんや（解釈してくれるんや）！的な驚きがたくさんありそう。 最後のほうがだいぶ駆け足で追いつかなかった。
コマンドラインツールについて語るときに僕の語ること
- http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
- https://speakerdeck.com/tcnksm/komandorainturunituiteyu-rutokinipu-falseyu-rukoto-number-yapcasia
@deeet 楽天の方
-
- 何を実践してその差を埋めているか
一つの事に集中できる
- UNIX という考え方
- 小さいものは美しい
- 一つのプログラムにはひとつの事をさせる
- ２つ以上の事をやろうとするだけで煩雑に
直感的
他のツールと連携できること
利用を助けてくれる
- ドキュメントや Usage が存在しないツールは使いたくない。ちゃんと準備する
- ドキュメントパターン
- README.md 使うか否かを判断
- Usage で最低限の使い方
- Man 複雑な例とか
- 適切なデフォルト値を持ち設定も出来る
- ユーザに無駄なオプションを設定しない
- デフォ、設定、環境、オプション
苦痛なくインストール
直ぐに回収できる
- エラーは必ず起きる
- DEBUG opthon
- tool --debug
- export DEBUG=1 開発者向け
以下に良い CLI ツールを作り始めるか
-
- 複雑な作業を自動化、タスクの生産性を上げたい
- いきなり複雑な事はしない
- 他の言語と連携を考える
言語を選択する
コードを書く前に README を書く. readme driven
- 名前を考える、何するか考える、
- 自分が何を作りたいのか整理して始めることが出来る
- Github の README.md
- ユーザ視点で作れる
- 一番テンションん上がっている時にドキュメントを用意スルことが出来る
実際にツールをリリースする（LIVE
cli-init でオプション含め go のバイナリが作られる
hub create -d 'name'
-> リポジトリが作られる
gox でクロスコンパイルされる、プラットフォームごとに用意される
ghr v0.1 pkg/
pkg 配下にコンパイルされたツールをリリースする
個人的に一番熱かった。スクリプトを書く機会があるので今後意識していきたい。 Readme Driven!
DeNAが歩んだデプロイ自動化への道
http://yapcasia.org/2014/talk/show/fb55d99c-fde1-11e3-b7e8-e4a96aeab6a4
aoneko DeNA の人 Mobage Platfom 開発
安全工学というキーワード
- システムを以下に安全に運用するか
- アプリも同じだと思っている
time to market
Mobage について
レガシーからいかに脱却するか
- 適切なサイズとはそれだけで優れたことである
- 巨大なコンポーネントを意味のある単位に切り分けていく
- 現在進行形でやっている
自動化できるデプロイの条件
デプロイメントパイプライン
- 開発 -> ユニットテスト -> 検証環境デプロイ -> 検証環境受け入れテスト
- バージョン管理にコミットする毎に行う
- 本番リリースも信頼された繰り返しの中の一つとして考える
テストの定義
CI/CD
- 継続的インテグレーション、継続的デリバリー
- コミット単位でリリースサイクルを繰り返すこと
- リリースで問題発覚すると、大きな手戻りになる
- 細かくリリースを繰り返す事によって、問題を早期発見する
- 反復されたプロセスは信頼に足る。
- 当然。手動はむり。
Jenkins を用いた CI/CD 環境
問題
- 誰が何をしたか、
- 何がどこにアップ
- どれがテスト済みなのか
- → 解決された
とにかく push せよ
- 手元に置かない
- どんどんテスト・デプロイ・結合試験のサイクルを回す
所感
- 開発が明らかに楽
- CI だけやってた頃よりも更に
- 手戻りが減った
- 情報共有が楽
課題
- End -to End のテストケースは時間がかかりすぎて現実的でない
- 網羅性も当然完璧でない
- 人間でしか確認できない事もある
- そもそもこれに時間をかけていたら意味が無い
- End -to End のテストケースは時間がかかりすぎて現実的でない
QA Q. 負荷テストや長期間(ランニング)テストをどうするか A. パイプラインへの組み込みは必要性を感じていない
如何に、そしてなぜ CI/CD が大事かを説いた話し。
WHERE狙いのキー、ORDER BY狙いのキー
トランプの話
- 100 枚のトランプ
- スペードの A を探してくれ
- 何処に何があるか、何枚あるかわからない
- 1 枚づつひっくり返し A を探す。これがテーブルスキャン
- めんどい、だからチートシートを作る
- Club は上から 4, 5, 10
- spade は上から 6, 7, 9 → 4/1 に省略される
- これが部分的にインデックスした例
- club 且つ A は 56, 77, spade 且つ A は、100
- これがインデックスを全部使用した例
- インデックスとはソート済みのデータの複製
テーブルスキャン
Index を作成
- 配列に情報を入れる
- foreach で Index の中にある行だけにアクセスできる
Where 狙いのキー
order by 狙い
Where と orderby を両方カバーするキー
- where 句
MySQL は join が遅い
- 外側のテーブルから 1 行データをフェッチして
- 内側のテーブルから 1 行データをフェッチして
- 評価 & ソートバッファ
外部表と内部表という概念がある
- Order by をインデックスで解決するには、そのカラムが外部表にある事が必要
Where 狙いと orderby 狙いーのキー
- 両方狙えるインデックスを作るのが裁量
- 必ずしも一番いいキーで 両方狙い撃ち出来るとは限らない
まとめ
- where 句で十分絞り込める場合は wher 狙い
- where 句が殆どきのうしないような場合は、order by 狙い
愚痴
序盤の話はトランプの例とか分かりやすかったのにいつの間にか何を言ってるかよくわからなくなった。 要解読。MySQL の内部動作を元に、以下に Index を利用するか、そのためにどのようなクエリを組むかの話しだったと認識。
Mojoliciousを使ったwebアプリケーション開発 実践編
http://yapcasia.org/2014/talk/show/250b85d0-02a0-11e4-9357-07b16aeab6a4
LINE 3 年目の方
Perl でwebアプリ開発入門
- 敷居が低くなったと感じた
- アプリを作るのは簡単
- 実際にサービスに入れてみると、運用の壁にぶち当たる
- ユーザが増えたらレスポンスが惜しくなる
- フォームに変なデータを入れてくる
- 工夫が大事
具体的な対応例
- YAPC::Asia サイトで実際に動いているシステムがあるのでそれを参考に
想定
- Perl Beginner
基本k農政
- mojo generate app MyApp
- 必要なディレクトリが用意される
- それぞれのディレクトリに何を入れるかの説明。etc は設定ファイル、t はテスト等
ETC
ローカル環境構築
- perlbrew, plenv を使いましょう
- brew で入る
carton でモジュール管理
- cpanm Carton
- モジュールのバージョン固定、インストールとか
carton install
carton exec
carton を利用することによってバージョンが固定され、他のアプリでインストールしたモジュールに影響されない
環境によって読み込む config を変えよう
YAPCAPP.PM での config ファイル読み込み
- PLACK_ENV で分岐される
- dev だったら、 onfig_dev.pl など
アプリケーションの話し
- LIB ディレクトリ構成
MVC 対応表
- API/* -> Model 層
- Controller/* -> Controller層
- Renderer.pm -> View 層
MVC の Model が無い -> 自分で用意する
KVS を扱うモジュール
- Cache::Memcahed::Fast::safe がおすすめ
- Cache の方法
- user 毎に $cache_key を変えて Cache する
Container の仕組みと特性
Contaer の注意点
- インスタンスの状態によって返り値が違うのは不向き
renderer を text::xslate に変更
- 高速なのでぜひ使ってね
- テンプレートの syntax を TT に変更
- テンプレートでの注意点
- キャッシュが機能してるか
- テンプレートやッシュを意識
- View そうでは難しいことをしたら負け
SESSION と CSRF
- Mojoliciousの seccion は使いづらいという話がよくきく
- Plack::Middleware::Sesiion::simple を使おう
本番環境の話し
システム構成
daemontools でプロセス生存管理
- /service 以下のディレクトリを管理
- /servie/myapp -> $APP_HOME/misc/services/myapp に link
APP 起動用 run ファイルを用意
server::starter で hot deploy
- 再起動の時にリクエストの処理を続けながら、変更の内容を反映
- オンラインで設定反映ができる！！見かけ上落とさずに再起動出来る
- Deploy 失敗しても、start_sever が前の世代をもっているから安心
初心者が Web エンジニアのコミュニティに触れてみて感じたこと - ゆとりエンジニアの成長戦略 (20 分)
http://yapcasia.org/2014/talk/show/61b78258-026f-11e4-9357-07b16aeab6a4 http://blog.zoncoen.net/blog/2014/08/30/yapc-2014-talk/
zoncoen 新卒の方
- 学生時代にプログラミングに出会う
- OSS や勉強会の存在を知って Web エンジニアに惹かれた
- みんながいいもにしていく！いいなと思った。業界全体に良くしていくところとか
- → 優れたコミュニティの存在。自分も入りたい
- 何をしたか
- 結果
- 技術のキャッチアップに役立つ
- 名前を覚えてもらえる
- コミュニケーションコスト低下
- どんな人かわかってもらえれば優しく教えてもらえる
- 楽しい
- 使えるものは使っていく
- 知の高速道路
- 一定までは高速道路に乗ろう
- 勉強会で仲間を見つけて一緒に
- 目標となるエンジニア
- 積極的な情報発信 rebuild.fm
LT
Acme 大全の話
早口だった 大拍手で終わる
top 10 kawalitative japanese authors
CPAN モジュールの top10 10. kazeburo 09. turugina 08. motemen 07. papix 06. zigzagu 05. syagi 04. pawapawa 03. hayajo 02. yakex 01. bayashi
http://acme.cpanauthors.org/for/japanese
iMinilla を使っている方は注意 * meta.json * Spec のバージョンは 2
Relocatable Perl
- 何度も perl をビルドするのが面倒
- Perl に対してネガティブな事をよく聞く
- → だれでもすぐに使える最新 Perl を！
- そこで relocatable perl
- is nani
- 何処においても使える Perl
- みんな幸せに
- Mac 用とLinux 用を用意
perl 入学式 活動中間報告
- in 福岡が開講
- 大阪、東京、福岡
- 毎回 15 人ぐらいずつ
- スタッフが増えた
- 短期集中講座 in 釧路やった
- 運営者グループが Github に移行
- サイボウズLive から移行
- ウェブサイトがリニューアル
- ロゴも変わった！
- 黄色と緑でわかばマークをモチーフ
- JPA との連携が始まる
- まとめ
- 無事3年目を迎える
- 課題は山積み
- どんどん支援する
- 明日 8/30 やるよ！
聞き逃した
- immutable data
- use Moo
- ネストした時どう書くか
- use Lens
- co -> 反対という意味
なるほどわからん
英語 Beyond Civic Hacking
Civic Hacker
なるほどわからｎ
OSS の理想と現実
chobi_e
- Gree のインフラエンジニア
げんじつはかくもきびしい
得られた知見の紹介
今後どう活動するか
承認欲求とは違う、問題に対して自分のアイディアで解決する楽しさ
OSS はみんながそこに参加する
失敗。デート中に SEGV の原因を考えてしまう
30台、自分の時間減る。
自由時間は 3.5 h ぐらい
- 年間 960 h
- やらない選択も大事
- 睡眠時間を減らすと病院行きになる
- 増えていくのでメンテナンスコストも掛かる
- OSS を楽しくするために
- うっかり業務アプリに組み込む
- 継続的なメンテは難しい
- 英語は勉強する！
pixiv 新卒インフラエンジニアがサーバ構築に挑んだ話し
- catatsuy さん
- 去年入社
- pixiv は全部小文字
- 社内広告サーバ
- PHP5.3
- アプリは Golang
- Nginx - Circus -Go
- Circus がソケットを
- cpan の sys::pagecache を利用して削除
Web Framework Benchmarks と Perl 現状報告
RAMEN
- 技術よりラーメン好きでしょ
- 日吉はラーメン天国
- ソウルフード
- Ramen + OSS
- ラーメンを食べるか、OSS に貢献する。またはその両方。終わったら３人指名。
- CPAN モジュール作るとか翻訳するとか。github でスター付けるだけ
day2
Dockerで遊んでみよっかー
- http://yapcasia.org/2014/talk/show/97cc7bbc-ef25-11e3-b7e8-e4a96aeab6a4
http://www.slideshare.net/kazeburo/docker-yapcasia-tokyo-2014
@kazeburo, LINE Corp., ISUCON 優勝
Docker 使用経験率 -> 結構いる
Windows で動かした人はいない
本人も本番環境では動かしていない
- まだ若い技術で、ベストプラクティスが定まっていない -> 遊んでみよう
- 遊ぶと行っても基礎と実績的ノウハウ
Docer の基本
コンテな？
- 実行する環境を隔離する
- VM との違い
- 同じ独立性を確保しながら、より少ないリソースで動作(OS動く分のリソースを省略
- kernel は共有している
- Docker Engine 上で動いている
コンテナの動作
- DockerEngine が Host OS から各リソースを隔離する
- 隔離されるもの -> ファイルシステム、ネットワーク、ホスト名、プロセステーブル、ユーザ権限、CPU/メモリ等のリソース制御
- Linuxkernel の機能を使ってコンテナ管理している
Docker のインストール
Vagrnt で Docker 手作業
自動化変
- script で↑を用意
- config.vm.provision "shell", inline $script
-
- docker run ubuntu:14.04 echo hello world ## ubuntu が起動するベース Docker イメージ
bash で入る
- docker run -i -t -> -t は tty, -i は stdin の維持
- → 対話式で入れる
コンテナのライフタイム
Docker の特徴纏め
- コンテナ技術を利用した、アプリの配布・実行プラットフォーム
- 揮発性がある
- Dockerfile と階層化イメージ -> これから説明する
Dockerfile とは
イメージの作成
動画で説明...
dockerbuild のイメージは変更点差分イメージを重ねていく
docker file のy靴買うコマンド
- FROM
: - tag を省略すると latest を使用
- RUN command args args
- RUN ["bash","args","args"]
- COPY src dest
- カレント dir からコンテナへのファイルコピー
- ../src とかは出来ない
- カレントディレクトリを一時的にtmp領域にコピーしてからビルドするため
- ADD
- COPY より前からあるコマンド
- URI や tar ファイルを自動解凍できる、必要なければ使用しない。COPY を使う
- ENV KEY NAME
- $PATH とかの変数もしようか
- CMD command args args
- EXPORT PORT_NUM
- コンテナ内ｎぷrセスが Listen スルポート
- docer run -p 22122:11211 (Host側:コンテナ側) localev/memcached
- FROM
Docker で perl を使う
- centos の場合、system perl が入ってない！(ubuntu は入ってる
- 軽くするために削られた...
- perl の入ったイメージを使う
- registry.hub.docker.com で perl で検索して使う
- どれ使う？
- official repo
- docker file が公開されているもの
- Descript, Dockerfile を見て説明がちゃんと書かれているもの、ニーズにあってるもの
- Automated build repo を利用している
- Auto buid repo ?
- build の過程に人の手が入らない
- Github に push するだけで build される
- おすすめ
- kazeburo/perl
Docker で自動化
- ≒webアプリケーションの実行
- 他にも
- Docker で MySQL のテスト
- 早い起動速度と揮発性を利用
課題
- ログ
- MySQLの接続族
- 性能
- 監視
Perl Mongersのためのstrace入門
zentoo@DeNA
- 愛と勇気と缶ビール http://zentoo.hatenablog.com/
- モバゲーオープンプラットフォーム
- 元・落語研究部
strace とは
システムコールとは
- アプリが叩く OS の API
- File I/0 (open. lseek
- Networkd (socket, bind , listen
- memory (brk,sbrk
- Process(fork
SystemCall 抜きで perl で新しいプロセスも、ネットワークプログラミングも出来ない
- アプリは OS の掌の上
Web アプリの仕事とは？
- HTTP リクエストを受けて HTTP レスポンスを返すこと
- →それってどういうこと？
- accept して read して write して close
Web アプリの仕事に立ち戻る
具体的には
- int fd = accept(...);
- red(fd, ...);
- ドラマ
- write(fd, ...);
strace demo
starce を読むときの基本
- read(5, "GET / HTTP..., ) = 308
- システムコール名(引数, 内容 ) = 返り値
- fd に注目する！
- ↑の例だと 5 が fd
fd
- フィアルやネットワークソケットを抽象化した構造体へのポインタ
- 0,1,2, = stdin, stdout, stderr
- 移行は昇順にふられる
fd を追うのが捜査の基本
- ファイルの生存期間が open で返ってきたfd が close に渡されるまで
- fd が閉じてない -> そのアプリが閉じてない
web アプリの strace を読む基本
- acept
- read GET
- write HTTP 200 OK
Web アプリのお仕事（再掲
プログラムは思ったとおりに動かない
実例
嘘をつかないツールに頼る
うそつくものとは
- 人の記憶
- アプリのログ(人間が書いたものだから、想定と違うかも
- アプリのコード
starce わるいところ
- 無駄な情報多い
- たまに起こる事象には向いてない
いいところ
- 事前設定が不要
- Web アプリケーションの気持ちが分かる（何のシステムコールを使っているか
まとめ
- strace 万能じゃない
- お手軽・強力
今まで見方さっぱりだった starace だったが、足がかり的なものになりそう。個人的 2 番目に良かった。
