読者です 読者をやめる 読者になる 読者になる

ちくわ

ちくわにきゅうりを入れるとうまい

YAPC 2014 でメモりまくった

Linux

YAPC 2014

http://yapcasia.org/2014/

YAPC は BLOG にするまでが YAPC です。と言っていたので、記念に手元のメモを投稿します。 とにかく写経のつもりで目耳に入った事を無心でテキストにしたので、typo や意図が分かりずらい箇所あると思いますが、まぁ!細かいことは気にしない!

印象的だったのは、以下の本が別の発表で 2 回出てきた事。

元々持っていたけど、やっぱり良本やったんやね。

完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ

  1. web サービス誕生の瞬間

  2. 2つの必要なこと

    • 同じ環境をもう一度作れるという記録
    • 保険を作る。冗長化。データのバックアップ
  3. なぜ必要な

    • HW は壊れるし、
    • 人間はミスをする
    • web サービスは継続できる!
  4. ユーザが増えて負荷が増えてきた

    • 負荷が増え閲覧困難
    • 複数のサービスを一つのサーバに入れていた

      • 機能毎にサーバを分ける
    • レンスポンスが上がり、サービスを継続できる!
  5. スケールアウトに必要なこと

    • 再現性が必要、いつでも同じものがどこでも作れる → * 簡単にスケールアウトが可能
    • 簡易性、シンプルに作る → 依存関係を作らない。疎結合
    • 変化に強いサービスが作れる
  6. 機能が増え、複雑性が増える

    • 再現性が必要(AWS だけとかオンプレだけとかの縛りを作らない!)
    • 簡易性、スケールアップやスケールアウトが簡単に出来る
    • 機能が増える毎に大変になってくる
    • → 運用負荷が多少軽減出来る
    • → 変化に強いシステム
  7. 時は流れ

    • 障害とかオペミスを経て...
    • システムは成長していく
  8. 記録や保険の精度について

    • 問題と対策。対極に存在する。時間はコスト。どれだけコストをかけるか判断は難しい
    • 時間,コスト,リスクのバランスを見て、決定する
    • 必要以上のものは作らない、その場その場で判断するしかない
  9. そろそろ旅が終わる

  10. システムも人間も世界も完璧ではない

    • 変化に強くある必要がある
    • Web サービスは続いていく
  11. 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 の人

  1. 自己紹介

  2. 最近はてぶについて検索機能を紹介

    • 期間指定が出来る
    • フォローしているブックマーから検索(お気に入りの人だからノイズが少ない)
    • フォローしているユーザのグループから検索
    • http:// を省略してサブドメインを横断して検索
    • Presso というアプリにも使われている
    • 今日はこの辺りの話し
  3. その前にはてブの検索の歴史

    • 2007年 MySQL LIKE 検索

      • DB のレコード屋リクエストが少なければ問題ない
    • 2008年 サービス規模↑ 1100万エントリ/3300万ブックマーク到達

      • 蓄積されたデータを有効活用したい!
      • 全文検索、過去の関連記事の自動抽出
      • 分散検索ミドルうぇあ Sedue をリリース
    • 2009 年

    • 2011

      • yanbe 入社
      • 検索機能が不調になる
      • PFI との保守契約が必要なのか、社内検討
      • 代替案で Solr が出てくる
      • Twitter の検索サービスを個人で公開していた
      • スケール出来そう *2012
      • Sedue -> Solr 移行
      • しばらくは安定して稼働
    • 2013

      • Solr でも力不足
      • ユーザ好みのコンテンツを返す、が難しい
      • WebService::Solr

        • 非公式だけど事実上標準の Perl クライアント
        • エラーハンドリングが不完全
        • 複雑なクエリは生成できない
        • 検索結果が Moose オブジェクト(値が取り出しにくい、オーバーヘッドある
      • Elasticsearch 検討

        • ドキュメントが親子関係で表現できる
        • 実際に使ってみたというエントリーが増えてきた
        • 後発なので JSON API /JSON レスポンスで設計がモダン
        • アプリ側から使いやすい
  4. Search::Elasticsearch

    • Elasticsearch, Inc で公式メンテ
    • 作者に変な思想がない
    • 全部の機能が利用できる
    • 通信部分だけ別プロトコル、拡張性が高い
    • → 余計なものが無い
    • Elasticseach の mapping
    • 複雑なクエリを表現できる
    • 自分のブックマーク且つクエリにマッチ
  5. Presso の紹介

    • 検索条件を管理画面から設定できる

      • この設定画面から Elasticsearch のクエリを生成する
      • Query DSL の高い記述性がある
  6. はてブ数カウンター

    • 初期は、SQL クエリだった
    • 今は Elasticsearch の API で実現
  7. まとめ

    • なぜ Elastcsearch
    • Query DSL の自由度

      • 企画の自由度が上がる
  8. 今後の予想される展開

    • 集約系の機能(Aggregation API)の強化
    • 検索・集約機能を基盤にしたデータマイニング機能
    • 今後利用が見込まれる分野

      • APIJSON なことをイカス
      • リアルタイムな検索・集約機能を活用した to B 向けサービス
  9. 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 株式会社バスキュール

  1. 立ち位置、DevOps の真ん中にいる
  2. TV とスマホを同期する仕事
  3. 事例紹介

    • スマホで投票受付してリアルタイムで TV で表示
  4. バックエンドhが M.I.E.S というプラットフォーム

    • サーバサイドを担当
    • リアルタイム同期
    • 画像変換
    • 視聴ログ集計/解析
  5. はなすこと
  6. はなさないこと

    • フロントエンド、アプリレイヤ
  7. TV案件の特徴

    • 1週間前にティザーサイト公開
    • ロールごとに最小インスタンス数で構築
    • 放送前日 - 当日
    • 数10数100インスタンスを起動
    • バックアップ

      1. TV 連動運用

      • 基本は放送時間
      • 想定ユーザ数バラバラ、数千 - 数万
      • コストシビア
      • 放送時南中の変更はない。そもそも稼働時間短い。変更もない。

        1. 負債回収
      • 期末期初/年末年始 忙しい時期は決まっている
      • 作ったものは本番終了後に削除
  8. アクセスパターン

    • 曜日/時間帯/企画内容からユーザ規模がある程度わかる
    • どこに負荷が集中しやすいか、特的出来る
    • 一発勝負なので本番怖い
  9. 怖いのを軽減させるので、Punisher を作った

  10. シナリオ例

    • 30分間に30万人が処理

      • ログイン、APIサーバに情報取得、 API 実行、Socket サーバに接続
    • 30万人接続した状態でブロードキャスト送信
    • 上記を Javascript で記述
  11. 良い副作用

    • シナリオを書くことにより、事前にあぶない部分が判明する
    • 前よりは安心して本番を迎える事ができるように
  12. 監視

    • Nagos/Mnin
    • 自動でコンフィグを生成する自前ツール
    • sensu つかいたけど検討段階
    • 負荷のタイミングが分かっているので張り付き監視
    • 全体的な監視

    • ロールごとの個別監視

      • top とか
    • Proteus-Monitor

      • リアルタイムで各サーバのリソースが分かる
      • サーバ一覧で確認できる
      • 設定が楽
      • Node が動的に追加/削除
    • ソケットクラスタ管理ツール

      • ソケットサーバの状態監視したいので作った
      • コネクション確立できたらグリーンに表示
      • 全体のコネクション数を表示
  13. 運用改善の話しその1

    • MIES の話し

      • 案件をこなしていくうちに、事前に出来上がった

        • 共通化したり汎用化したりを繰り返した
    • ServerTeam

      • 3 人
    • 言語は Node.js , Python ,Perl
    • 俺が SPOF じゃね!?
    • サービスごとの秘伝のタレ

      • 開発環境、デプロイ、構築、スケール管理
      • サービスごとに運用できる人が1人
      • ほかの人が手順知らない、工数もお金もかかる
    • 解決したいこと

      • 運用の手順は統一化しよう!
      • 開発フロー/デプロイ/クラスタ構築/スケール管理
      • CI しやすい
      • 引き継ぎしやすい
      • ミスしにくい
    • 開発フロー/デプロイ

    • プロビジョニング

      • Cefh + Berkshelf
    • クラスタ管理

      • AWS CloudFomation
    • スケールコントロール

      • AWS AutoScaling
      • 自動スケールは期待してない、スケールの管理を共通化したいという思い
    • MIES-Provision-Task

    • 開発フロー

      • Vagrant コマンドを Rake でラップ
    • イメージ保存

    • スケール管理

      • CloudFomation でパラメータで指定
      • Rake タスクでも用意しておく
    • インフラ共通化

      • Chef の base-cookbook を用意
      • ユーザ、ssh 周り、カーネルパラメータとか
    • Superviosr

      • Python 正デーモン管理ツール
      • 一度に複数デーモンを操作/自動リスタート出来る!
  14. Rake タスク

    • Vagrant のコマンドと殆ど一緒 rake local:up とか
    • rake local:provision [deploy=1] プロビジョニングだけするとか
    • AWS Task

    • タスク Tips

      • 任意のクックブックを指定
      • 差分実行
      • 複数タスク実行
      • rake vms (独自

        • いろいろ一覧表示
  15. ここまでで、共通化してだいぶ改善された

  16. 運用改善の話しその2

    • 同時並行案件が増えてきた
    • アプリはいいけどインフラは考える必要が出てきた
    • 問題

      • 案件による規模の違い
      • 単発とレギュラー番組、レギュラー番組の環境に影響させたくない
    • 解決案

      • AWS アカウント自体を案件毎に分けて、別クラスタを構築できるようにする
      • 1 アカウントで管理しない理由

        • オペレーション混ざるのがこわい
    • 手順共通化したしいける...?
    • 現実

      • AMI 移動、Keypaire 設定、AWS キー更新、アプリケーションの改修、... -> めんどい
    • Omniscient

      • サービス全体の config を管理
      • 管理軸 -> 案件ごと・環境ごと
      • インフラコンフィグ

        • AWS 情報
        • ワーカープロセスの数
        • 自社製の今フィル
      • 移行コスト削減!
    • Serf も検討したが

      • 複数案件軸で見ると逆に複雑になった
  17. さらに改善

    • Docker 化

      • 開発環境配布
      • サービス環境配布
    • MIES サービス統合管理
    • Omniscent ゲートウェイ計画
    • Rake タスクのGolang
  18. まとめ

    • 24/365稼働サービスは、頑張るところと、手を抜くところが違う
    • 要件にあった運用改善
    • まだまだ改善したい
    • それでも本番怖い


自動化とかだいぶ進んでいる印象、サービスの特徴に伴って環境の形態を変えていくのが面白かった

Git を使ったツール開発

以下宣伝

  • Git のはなしだよ、ギットギト
  • ghq 作りました

    • Go lnag
    • いい感じに git を管理する
    • GHQ という別の存在によりググラビリティが低い
    • 今となっては後悔している
  • git-browse-remote

  • git-pr-release

    • GitHub の PR をまとめる
  • github-commit-status-mark

    • CI 通ったかどうかをひと目で確認
  • git unify

    • sh
    • 複数のローカルクローンの .git 以下を共有
    • 漬かったらリポジトリが壊れるかもね(笑

共通点 * .git/** 使っていない * git のサブコマンドを利用している * git help -a

  1. 暗黙の引数

    • ユーザが改定しているもの

      • リポイj取り内のでの実行
    • HEAD(ブランチ

      • 今いるブランチが想定される
      • 昔はリモートブランチが全部プッシュされて事故になった
  2. Git

    • リビジョン?オブジェクトを指す何か。
    • SHA1, 名前, ほか, git が進化すると増える
    • rev あれこれ

      • refname (シンボリックネーム
      • タグ/ブランチ/リモート
      • 実体は .git/ 以下
      • ^{n}
      • 何時間前とか指定できる
    • DWIM

      • ユーザが何を言いたいのか良しなに把握する
    • git-symbolic-ref

      • 元始、.git/HEAD は symlink
      • 今は ref: refname とか
  3. git foo bar

    • git --exec-path
    • 実行ビットが経ってない奴
    • git-sh-setup からスタート
    • 便利関数たち
    • NONGIT_OK
    • OPTIONS_SPEC

      • オプションをいい感じにぱーすしてくれる
  4. パス

    • ファイルからのルートからのパス」
    • git rev-parse
  5. API octoki/ go-github があれば大丈夫

  6. git config

    • あくまで個人設定
    • -f でファイル指定できるので、共通したければ
    • git config -get-urlmatch

      • ghq.vcx URL → github と GHE で設定を分けたい時とかに使用
    • help -w でブラウザが開く


git にここまで機能があったとは... git のバージョンによって 'いい感じ' に解釈してくれる挙動が変わってきているのは面白かった。 ドキュメントとか見るとこんな事出来るんや(解釈してくれるんや)!的な驚きがたくさんありそう。 最後のほうがだいぶ駆け足で追いつかなかった。

コマンドラインツールについて語るときに僕の語ること

@deeet 楽天の方

  1. コマンドラインツールを幾つか作っている

  2. コマンドラインツールについて語る

    • 個人的思想入ってる
    • perl の話しでてこないけど、どんなツールでもでてくる話し
  3. いいツールとくそなツールの差

    • 何を実践してその差を埋めているか
  4. いい CLIツールとは

  5. 一つの事に集中できる

    • UNIX という考え方
    • 小さいものは美しい
    • 一つのプログラムにはひとつの事をさせる
    • 2つ以上の事をやろうとするだけで煩雑に
  6. 直感的

    • CLI ツールにも UI/UX
    • 慣習に従う

      • オプションの持ちかたや引数
      • short / long オプション
      • long オプション大事

        • 可読性を高める
    • GNU 標準ドキュメントがあるよ
    • 最もやりたい事を最も簡単に
    • 破壊的操作はロングオプションで
    • 対話インタフェースを避ける

      • 自動化を避ける
  7. 他のツールと連携できること

  8. 利用を助けてくれる

    • ドキュメントや Usage が存在しないツールは使いたくない。ちゃんと準備する
    • ドキュメントパターン

      • README.md 使うか否かを判断
      • Usage で最低限の使い方
      • Man 複雑な例とか
  9. 適切なデフォルト値を持ち設定も出来る

    ユーザに無駄なオプションを設定しない

    • デフォ、設定、環境、オプション
  10. 苦痛なくインストール

  11. 直ぐに回収できる

    • エラーは必ず起きる
    • DEBUG opthon

      • tool --debug
      • export DEBUG=1 開発者向け

以下に良い CLI ツールを作り始めるか

  1. CLI ツールの初期衝動

    • 複雑な作業を自動化、タスクの生産性を上げたい
    • いきなり複雑な事はしない
    • 他の言語と連携を考える
  2. 言語を選択する

    • 苦痛なくインストールしてもらう事を考える
    • Go -> あらゆるプラットフォームで動きたい, ruby , perl
  3. コードを書く前に README を書く. readme driven

    • 名前を考える、何するか考える、
    • 自分が何を作りたいのか整理して始めることが出来る
    • Github の README.md

      • ユーザ視点で作れる
      • 一番テンションん上がっている時にドキュメントを用意スルことが出来る

    1. ツール名前を考える
    2. 頻度が高いなら短く、低いなら長く
    3. 説明、どんなツールなのか
    4. 使い方を書く、直感的に使えるように
    5. VS 比較、他のツールとの比較、同じものを作っても意味が無いので、何が優れているのか考える
    6. バッジの準備、はじめからテスト環境を準備する

実際にツールをリリースする(LIVE

  1. CLI ツール作成、tcnksm/cli-init
  2. ロスコンパイル mitchellh/gox
  3. リリース, tchksm/ghr

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 開発

  1. アジェンダ

    1. なぜ deploy
    2. Mobage アーキテクチャ
    3. デプロイ自動化導入の実例
  2. 安全工学というキーワード

    • システムを以下に安全に運用するか
    • アプリも同じだと思っている
  3. time to market

    • 早く安全に届ける(ユーザまで
    • スピード x 品質 x コストはトレードオフの関係にある
    • スピードと品質は矛盾するのか

      • ある意味 YES であり NO
    • NO とは

    • 全ては出荷プロセスに現れる

      • 悪いシステムほど後になって発見される
      • 出荷を見直すと全体的に良くなる
    • リリースに困難さを感じるかが、そのシステムの安全性の指標となる
    • リリースプロセウスの自動化がシステムに自浄作用が働く
  4. Mobage について

    • 大規模サービス
    • 2006 モバゲータウンをから始まる
    • 2008 1000万人を突破
    • 2009 ソーシャルゲームコンテンツを配信
    • 2010 オープンプラットフォーム

      • 最初は1人出始めてた。一つのコンポーネントが徐々に規模が大きくなる
      • 使われいてるのか漬かってないのかよくわからないコード
      • 開発と本番環境で動作が違う
      • → 開発スピードが上がらない
  5. レガシーからいかに脱却するか

    • 適切なサイズとはそれだけで優れたことである
    • 巨大なコンポーネントを意味のある単位に切り分けていく
    • 現在進行形でやっている
  6. 自動化できるデプロイの条件

    • ソースがバージョン管理
    • CI 環境が構築sれ、ユニットテスト、受け入れテストが自動化されちえる
    • いつでもクリーンな動作環境を作れること
    • 環境を問わない簡易なデプロイスクリプトであること <- 重要!!
  7. デプロイメントパイプライン

    • 開発 -> ユニットテスト -> 検証環境デプロイ -> 検証環境受け入れテスト
    • バージョン管理にコミットする毎に行う
    • 本番リリースも信頼された繰り返しの中の一つとして考える
  8. テストの定義

  9. CI/CD

    • 継続的インテグレーション、継続的デリバリー
    • コミット単位でリリースサイクルを繰り返すこと
    • リリースで問題発覚すると、大きな手戻りになる
    • 細かくリリースを繰り返す事によって、問題を早期発見する
    • 反復されたプロセスは信頼に足る。
    • 当然。手動はむり。
  10. Jenkins を用いた CI/CD 環境

    • ビルドパイプラインの構築
    • git push の検知から始まって、全タスクの成功を実行条件に指定
    • スクリプトには引数としてビルドパラメータ等の指定
    • IRC によるフィードバック

      • 誰が何をした。結果はどうだった。
  11. 問題

    • 誰が何をしたか、
    • 何がどこにアップ
    • どれがテスト済みなのか
    • → 解決された
  12. とにかく push せよ

    • 手元に置かない
    • どんどんテスト・デプロイ・結合試験のサイクルを回す
  13. 所感

    • 開発が明らかに楽
    • CI だけやってた頃よりも更に
    • 手戻りが減った
    • 情報共有が楽
  14. ジョブ及びビルドパイプラインオン構築を一発スクリプト化した

  15. 課題

    • End -to End のテストケースは時間がかかりすぎて現実的でない

      • 網羅性も当然完璧でない
    • 人間でしか確認できない事もある
    • そもそもこれに時間をかけていたら意味が無い

QA Q. 負荷テストや長期間(ランニング)テストをどうするか A. パイプラインへの組み込みは必要性を感じていない


如何に、そしてなぜ CI/CD が大事かを説いた話し。

WHERE狙いのキー、ORDER BY狙いのキー

  1. トランプの話

    • 100 枚のトランプ
    • スペードの A を探してくれ
    • 何処に何があるか、何枚あるかわからない
    • 1 枚づつひっくり返し A を探す。これがテーブルスキャン
    • めんどい、だからチートシートを作る

      • Club は上から 4, 5, 10
      • spade は上から 6, 7, 9 → 4/1 に省略される
      • これが部分的にインデックスした例
    • club 且つ A は 56, 77, spade 且つ A は、100

      • これがインデックスを全部使用した例
    • インデックスとはソート済みのデータの複製
  2. テーブルスキャン

    • explain

      • 1 ぎょうずつデータをフェッチして
      • where 区のカラムで評価し
      • ソートバッファに入れ
      • ソートバッファの中をクイックソート
      • ソート済みの上から5行を取り出す → perl でも書いた、そりゃ遅いよという話し
  3. Index を作成

    • 配列に情報を入れる
    • foreach で Index の中にある行だけにアクセスできる
  4. Where 狙いのキー

    • explain

      • where 区のレンジをインデックスから取り出し
      • ソートバッファに詰め込み
      • クイックソートして
      • 先頭から5件取り出す → perl で書く
  5. order by 狙い

    • インデックスはソート済みなので、先頭から順番に取り出すだけで良い
    • クイックソートが不要になる
    • explain

      • インデックスに沿って行を取り出し
      • where 句にマッチするか判定
      • 5 件データが揃ったらループから抜ける → perl でも書く
  6. Where と orderby を両方カバーするキー

    • where 句
  7. MySQL は join が遅い

    • 外側のテーブルから 1 行データをフェッチして
    • 内側のテーブルから 1 行データをフェッチして
    • 評価 & ソートバッファ
  8. 外部表と内部表という概念がある

    • Order by をインデックスで解決するには、そのカラムが外部表にある事が必要
  9. Where 狙いと orderby 狙いーのキー

    • 両方狙えるインデックスを作るのが裁量
    • 必ずしも一番いいキーで 両方狙い撃ち出来るとは限らない
  10. まとめ

    • where 句で十分絞り込める場合は wher 狙い
    • where 句が殆どきのうしないような場合は、order by 狙い
  11. 愚痴


序盤の話はトランプの例とか分かりやすかったのにいつの間にか何を言ってるかよくわからなくなった。 要解読。MySQL の内部動作を元に、以下に Index を利用するか、そのためにどのようなクエリを組むかの話しだったと認識。

Mojoliciousを使ったwebアプリケーション開発 実践編

http://yapcasia.org/2014/talk/show/250b85d0-02a0-11e4-9357-07b16aeab6a4

LINE 3 年目の方

  1. Perl でwebアプリ開発入門

    • 敷居が低くなったと感じた
    • アプリを作るのは簡単
    • 実際にサービスに入れてみると、運用の壁にぶち当たる

      • ユーザが増えたらレスポンスが惜しくなる
      • フォームに変なデータを入れてくる
      • 工夫が大事
  2. 具体的な対応例

    • YAPC::Asia サイトで実際に動いているシステムがあるのでそれを参考に
  3. 想定

  4. 基本k農政

    • mojo generate app MyApp
    • 必要なディレクトリが用意される
    • それぞれのディレクトリに何を入れるかの説明。etc は設定ファイル、t はテスト等
  5. ETC

  6. ローカル環境構築

    • perlbrew, plenv を使いましょう
    • brew で入る
  7. carton でモジュール管理

    • cpanm Carton
    • モジュールのバージョン固定、インストールとか
  8. carton install

    • $ vi cpanfile
    • $ carton install
    • cpnam でたと問えると

  9. carton exec

    • $ vi etc/app.psgi
    • $ carton exec -l lib -- plackup etc/app.psgi
  10. carton を利用することによってバージョンが固定され、他のアプリでインストールしたモジュールに影響されない

  11. 環境によって読み込む config を変えよう

  12. YAPCAPP.PM での config ファイル読み込み

    • PLACK_ENV で分岐される
    • dev だったら、 onfig_dev.pl など
  13. アプリケーションの話し

    • LIB ディレクトリ構成
  14. MVC 対応表

    • API/* -> Model 層
    • Controller/* -> Controller層
    • Renderer.pm -> View 層
  15. MVC の Model が無い -> 自分で用意する

    • Teng がおすすめ
    • SQL::Maker + DBI 系で自作も OK
  16. KVS を扱うモジュール

    • Cache::Memcahed::Fast::safe がおすすめ
    • Cache の方法

      • user 毎に $cache_key を変えて Cache する
  17. Container の仕組みと特性

    • よく使う道具を一箇所に用意しておくための箱
    • Object::Container
    • 例) object::container 作成

  18. Contaer の注意点

  19. renderer を text::xslate に変更

    • 高速なのでぜひ使ってね
    • テンプレートの syntax を TT に変更
    • テンプレートでの注意点

      • キャッシュが機能してるか
    • テンプレートやッシュを意識

      • View そうでは難しいことをしたら負け
  20. SESSION と CSRF

    • Mojoliciousの seccion は使いづらいという話がよくきく
    • Plack::Middleware::Sesiion::simple を使おう
  21. 本番環境の話し

    • 本番の perl 架橋を構築する -> xbuild おすすめ
    • 指定したバージョンの perl をインストール
    • Path を通すだけなので怖いなくし楽
    • Perl だと Carton や Server::Starter も一緒に入る
    • Ruby, Node.js,PHP,Python にも対応
  22. システム構成

  23. daemontools でプロセス生存管理

    • /service 以下のディレクトリを管理
    • /servie/myapp -> $APP_HOME/misc/services/myapp に link
  24. APP 起動用 run ファイルを用意

  25. 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 新卒の方

  1. 学生時代にプログラミングに出会う
  2. OSS や勉強会の存在を知って Web エンジニアに惹かれた
  3. みんながいいもにしていく!いいなと思った。業界全体に良くしていくところとか
  4. → 優れたコミュニティの存在。自分も入りたい
  5. 何をしたか

    • twitter
    • 勉強会の参加 -> 東京に住んでないとツライ
    • perl の場合

    • 技術 Blog

      • ハマったり便利だと思うこと
      • なんでもいいから書く
    • エンジニア寿司好きだから鮨かいとくといい
    • OSS in Github

      • なんか書いてみる
      • OSS の開発やプロダクトへの PR から
      • Merge されると嬉しい
      • Github 便利
    • 勉強会等での発表

      • なんでもいいから発表
      • 今やってる
  6. 結果

    • 技術のキャッチアップに役立つ
    • 名前を覚えてもらえる
    • コミュニケーションコスト低下

      • どんな人かわかってもらえれば優しく教えてもらえる
    • 楽しい
  7. 使えるものは使っていく

    • 知の高速道路
    • 一定までは高速道路に乗ろう
    • 勉強会で仲間を見つけて一緒に
  8. 目標となるエンジニア
  9. 積極的な情報発信 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 入学式 活動中間報告

  • in 福岡が開講

    • 大阪、東京、福岡
    • 毎回 15 人ぐらいずつ
  • スタッフが増えた
  • 短期集中講座 in 釧路やった
  • 運営者グループが Github に移行

  • ウェブサイトがリニューアル

    • ロゴも変わった!
    • 黄色と緑でわかばマークをモチーフ
  • JPA との連携が始まる
  • まとめ

    • 無事3年目を迎える
    • 課題は山積み
    • どんどん支援する
  • 明日 8/30 やるよ!

聞き逃した

  • immutable data

    • use Moo
    • ネストした時どう書くか
    • use Lens
    • co -> 反対という意味

なるほどわからん

英語 Beyond Civic Hacking

Civic Hacker

なるほどわからn

OSS の理想と現実

chobi_e

  • Gree のインフラエンジニア
  • PHP, MySQL ,KVS 得意

  • げんじつはかくもきびしい

  • 得られた知見の紹介

  • 今後どう活動するか

  • 承認欲求とは違う、問題に対して自分のアイディアで解決する楽しさ

  • 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 現状報告

  • ソースコードGithub に公開されてる
  • ベンチマークは EC2 で実行
  • Perl で実行されているけど動いてない部分もあり
  • 大きく改善した
  • 実践的な設定_コードのショーケースとして貢献

RAMEN

  • 技術よりラーメン好きでしょ
  • 日吉はラーメン天国
  • ソウルフード
  • Ramen + OSS
  • ラーメンを食べるか、OSS に貢献する。またはその両方。終わったら3人指名。
  • CPAN モジュール作るとか翻訳するとか。github でスター付けるだけ

day2

Dockerで遊んでみよっかー

  1. Docer の基本

    • コンテナ管理ツール wiki より
    • 説明足りない
    • アプリの開発・配布・実行のためのプラットフォーム
    • Docker Hub - Dockerfile - DockerEngine (三角の関係)
    • ↑を支えるのがコンテナ技術
  2. コンテな?

    • 実行する環境を隔離する
    • VM との違い
    • 同じ独立性を確保しながら、より少ないリソースで動作(OS動く分のリソースを省略
    • kernel は共有している
    • Docker Engine 上で動いている
  3. コンテナの動作

    • DockerEngine が Host OS から各リソースを隔離する
    • 隔離されるもの -> ファイルシステム、ネットワーク、ホスト名、プロセステーブル、ユーザ権限、CPU/メモリ等のリソース制御
    • Linuxkernel の機能を使ってコンテナ管理している
  4. Docker のインストール

    • Linux kernel が必要なので VirtualBox とか必要
    • 1) boot2docker を導入し、Mac 上の docker コマンドから API 経由で操作

      • 30M ぐらい、軽い
      • インストール楽
      • Mac から透過的に使える
      • x ) ファイル共有に難あり
    • 2) vagrant で任意のディストリを起動(おすすめ)

      • ファイル共有がしやすい
      • GuestOS の機能を活用
      • ×) Guest OS にログインする必要ある
  5. Vagrnt で Docker 手作業

    • chef/centos-6.5 を使って vagrant init/up
    • VM 上で

      • epel を入れる
      • yum inst docker-io
      • srevice docker start
      • usermod -a -G docker vagrant
      • 再ログイン
      • docker -v
  6. 自動化変

    • script で↑を用意
    • config.vm.provision "shell", inline $script
  7. Hello world

  8. bash で入る

    • docker run -i -t -> -t は tty, -i は stdin の維持
    • → 対話式で入れる
  9. コンテナのライフタイム

    • 上記で bash 起動して exit すると、プロセスもコンテナも終了となる
    • コンテナは OS ではない!プロセスとかんがえる
    • ファイルシステムへの変更も破棄される -> 揮発性の有るコンテナ
  10. Docker の特徴纏め

    • コンテナ技術を利用した、アプリの配布・実行プラットフォーム
    • 揮発性がある
    • Dockerfile と階層化イメージ -> これから説明する
  11. Dockerfile とは

    • ベースイメージの指定 FROM centos:centos6
    • build 時に実行するコマンド RUN hoge
    • docker run 時に実行するコマンド -> CMD sl とか
  12. イメージの作成

    • Dockerfile を自動でマウント(Vagrant の機能
    • VM で、 docker build -t localdev/sl (イメージ名)
  13. 動画で説明...

  14. dockerbuild のイメージは変更点差分イメージを重ねていく

  15. 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

      • コンテナ内nぷrセスが Listen スルポート
      • docer run -p 22122:11211 (Host側:コンテナ側) localev/memcached
  16. 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 される
    • おすすめ

      • perl
      • jmmills/plenv
      • kazenburo/perl
      • 自分で作る
    • kazeburo/perl

      • docker run -i -t kazeburo/perl:v5.18 perl -v
      • RUN cpanm -n Plack -> cpanm も導入済み!
  17. Docker で自動化

    • ≒webアプリケーションの実行
    • 他にも

      • Docker で MySQL のテスト
      • 早い起動速度と揮発性を利用
  18. 課題

    • ログ
    • MySQLの接続族
    • 性能
    • 監視

Perl Mongersのためのstrace入門

zentoo@DeNA

  1. strace とは

  2. システムコールとは

    • アプリが叩く OS の API
    • File I/0 (open. lseek
    • Networkd (socket, bind , listen
    • memory (brk,sbrk
    • Process(fork
  3. SystemCall 抜きで perl で新しいプロセスも、ネットワークプログラミングも出来ない

    • アプリは OS の掌の上
  4. Web アプリの仕事とは?

    • HTTP リクエストを受けて HTTP レスポンスを返すこと
    • →それってどういうこと?
    • accept して read して write して close
  5. Web アプリの仕事に立ち戻る

    1. HTTP リクエストを受ける
    2. MySQL のアクセス、memcached へのアクセス、log の書き込み
    3. HTTP レスポンスを返す1
  6. 具体的には

    1. int fd = accept(...);
    2. red(fd, ...);
    3. ドラマ
    4. write(fd, ...);
  7. strace demo

    • $ strace plackup demo1.psgi
    • $ accept で止まる
    • -> リクエスト待ちの状態(Block している
    • curl でリクエストを投げると、starce が進むのが分かる
  8. starce を読むときの基本

    • read(5, "GET / HTTP..., ) = 308
    • システムコール名(引数, 内容 ) = 返り値
    • fd に注目する!
    • ↑の例だと 5 が fd
  9. fd

    • フィアルやネットワークソケットを抽象化した構造体へのポインタ
    • 0,1,2, = stdin, stdout, stderr
    • 移行は昇順にふられる
  10. fd を追うのが捜査の基本

    • ファイルの生存期間が open で返ってきたfd が close に渡されるまで
    • fd が閉じてない -> そのアプリが閉じてない
  11. web アプリの strace を読む基本

    • acept
    • read GET
    • write HTTP 200 OK
  12. Web アプリのお仕事(再掲

    • 何か問題がある場合

    • で問題になる事が多い
    • strace では port 番号を見て推測する(パッと見分からない
  13. プログラムは思ったとおりに動かない

    • 同じクエリを複数回発射している
    • 無駄に retry している
    • TCP Connecton 使いまわせてない、ちゃんと切れてない
  14. 実例

    • ある API のレスポンスが、リリース後に 180mx 劣化
    • 50ms or dir
    • Cache::Memcached::fast のラッパーモジュールに更新差分があったので容疑者
    • strace -p $pid -e 'trace=sendmsg'

      • sendmsg を使うのはわかっていた
    • 原因判明、retry 機能が悪影響
    • time stanmp を見ると、retry 間隔毎に記録されていることが分かる
  15. 嘘をつかないツールに頼る

  16. うそつくものとは

    • 人の記憶
    • アプリのログ(人間が書いたものだから、想定と違うかも
    • アプリのコード
  17. starce わるいところ

    • 無駄な情報多い
    • たまに起こる事象には向いてない
  18. いいところ

    • 事前設定が不要
    • Web アプリケーションの気持ちが分かる(何のシステムコールを使っているか
  19. まとめ

    • strace 万能じゃない
    • お手軽・強力


今まで見方さっぱりだった starace だったが、足がかり的なものになりそう。個人的 2 番目に良かった。