Infrastructure as LL Memo. (LL まつり)


http://ll.jus.or.jp/2013/program.html#infra_ll


なにか予定があったんだけどな...と思いながら、六本木のスタバで暇をつぶしている最中に、そうだ錦糸町に行こうと、当日券で、LL に参加してきました。（いい意味で）予想通りの面白いセッションで、普段の自分の業務からは離れているレイヤの良い勉強になった。
もし、間違いなどがあれば、ご指摘ください。


1. 伊藤 直也さん

    • @Nifty
      • 当時は、オラクル(DB)、ゼウス(web) を使っていた
      • 自動化は無かった
    • はてな
      • サーバ台数 : 1000台くらい
      • 2006年、2007年は、自動化が入ってきた
      • 2008年にパペットを導入した
    • GREE
      • インフラの仕事はしていなかった
    • 入門 chef solo
      • 当時、AWS で、メンテナンスしようとしたとき、毎回インフラの構成を変更する時が面倒だった
      • chef は情報が多すぎるので、重要なところだけピックアップして作った本
      • 本は、5000部くらい売れている
    • (株)じげん
      • 自分が取締役をしている会社
      • 実験的にいろいろなものを導入している
      • chef をいれて github でコードを管理している
    • なんで DevOps なのか？
      • 構成・運用に時間を割くのがもったいない
      • すぐ構成忘れちゃう
      • クラウドと自動化


2. 黒田 良さん ＠ paperboy&co.

    • 所属
      • paperboy&co.
        • インフラエンジニア
    • 経歴
      • 30歳までは、郵便局職員
    • やってきた事
      • データセンタに常駐して、サーバ (数千台) の監視運用
      • 途中から Perl って便利じゃん！ってなる
      • たんぽぽタスクを自動化
      • subversion とシェルスクリプトで構成管理、プロビジョニングツールを自作
      • Perl でサービス監視フレームワーク作ってみる
    • ペパボ期
      • 概要
        • いろいろなサービスのインフラを担当
        • 入社すぐから今に至る
      • 30days Album
        • 主に MogileFS、MySQL と格闘
        • オンプレと EC2 のハイブリット化とか
        • もちろん Puppet も
      • ヘテムル (直近のお仕事)
      • Sqale
        • PaaS on AWS
        • AWS API、Perl、Puppet でいろいろ頑張りました
      • THE INTERVIEWS
      • LOGPI
    • 技術基盤チーム (自分の所属とは別のチーム)
      • 全社横断でお役立ちなものを作っている人たち
        • 自分はインフラ回り (AWS) をお手伝いしたりした
      • このチームの人に Puppet を教えたら、このチームの人が本を書いた (すごい)
    • 趣味、特技
      • 自動化


3. 成田 一生さん ＠ クックパッド

    • 経歴
      • 2008: ヤフー
        • メールサービスのバックエンド開発 (Perl、C、PHP)
        • 画面の無い開発なんて...と最初は思っていたが、面白くなり、徐々にインフラエンジニアになっていった
      • 2010: クックパッド
        • サービス開発エンジニアとして入社
        • 開発基盤チームを経てインフラチームに。
        • 画像配信システムの開発や Rails アプリのパフォーマンス改善
        • オペレーションの自動化
        • 運用ツール開発などに取り組み中
        • Ruby、C
    • クックパッドの体制の変遷
      • 入社当時 (2010年くらい)
        • サービス開発系エンジニア : 約10名
        • 開発基盤エンジニア : 1名
        • インフラエンジニア : 3名
      • いま (2013年)
        • サービス開発系エンジニア : 約40名
        • 技術部エンジニア : 12名
        • インフラ部エンジニア : 5名
    • よくある事から自分が担当に
      • みんながサービスに新機能をどんどん追加したら、いつの間にかサービスが重くなる！
        • ↓
      • 誰かが、常にパフォーマンスを気にしていないとやばい！
        • ↓
      • 自分がやります！
    • 自分のミッション
      • インフラの問題をコードで解決する
    • サーバが重いという事象が発生した時...
      • 二つの方向性
      • 両方できると便利
      • インフラの人はインフラだけを見ていて、開発の人は開発だけを見ているともったいない
    • 開発、デプロイ
      • Github Enterprise (GHE) を利用
        • pull-request でコードレビュー
    • サーバ＆プロビジョニング
    • Infrastracture as LL
      • AWS はすべてのオペレーションが HTTP(S) API 経由
        • つまり LL
    • imon (Infra monitor)
    • autoscale
      • 負荷状況に合わせて、サーバの台数を増やしたり、減らしたりする


4. ディスカッション

    • なぜ流行っているのか？
      • Puppet
        • 2008年から名前はあったが、最近、すごく使われてくるようになってきた
      • クラウドと関係がある？
      • おとなの事情 (バスワード) もある
        • アジャイル ⇒ クラウド ⇒ DevOps
          • ある日、突然、上司が自社でも DevOps をしようと言ってくる
        • インフラといっしょにやっていきましょう
      • 直也さんの本
        • 前から気になっていたが、どうやって使っていいか分からなかった
        • 本が出て、自分でも使えるようになった
      • 東京リージョンが出来た時に、AWS を使うようになった
        • AWS だと、Puppet・chef を使わないと、AWS が使いづらい
      • シェルスクリプトだと、構造化と言う面で、脆弱
      • 運用の人が cvsup をするのも効率が悪い
    • DevOps の目的とは？
      • 開発エンジニアと運用エンジニアを仲良くさせるツール
    • ツールの運用はどうやる？
      • ツール特有の話ではなく、どうやって、サーバ構成 (Puppet マニフェスト) を分けるのかが重要
    • LL と言うか、言語内 DSL を使う事の是非
      • Ruby を知らない人は Puppet の方がとっつきやすい
        • chef は Ruby が分かれば (そのまま Ruby の記法が使える) 、新しく覚えなきゃいけない事は無い
    • 自動化しづらい事って？
      • AWS なので、自動化できない部分はほとんど無いが、自動化するとあぶないと感じる事は自動化はしづらい (あえて、自動化はしない)
      • autoscale を使っているので、サーバの増減を自動化している
      • 既に存在している環境に対して、自動化するのは難しい
    • 現状の課題と問題点
      • デプロイしようとしたら (コードに、bug なり typo なりがあってトラブルが発生し、何度も何度もデプロイを運用担当者にお願いしていたので)、運用の担当者を怒らせてしまったと言うのが、そもそも解決しないといけない問題点として存在していた
      • Puppet を導入したらコードの人たちに、インフラを説明するのが楽になった
      • クックパッドでは、インフラ部の人が Puppet のマニフェストを書いている
        • Puppet は chef とは違って、ぱっと見は Ruby だけど、よく見ると Ruby ではないので、コードの人たちは、Puppet マニフェストを書くのを敬遠しがち
          • コードの人たちにもマニフェストを書けるようにして、責任を全体に広げていく方向は間違いで、責任分界点はきちんと作っておいた方が良い
          • whitesnake のように、コードの人がツールを動かしたら、自動的にいろいろな環境をいい感じにデプロイ出来るようにすると言う環境が理想 (PaaS 的にインフラを提供出来るのが理想)
      • コードの人たちに、開発環境を渡して、いつでも開発環境にコードを置けるようにしても、これを置いたというメモを残しておいてほしい
      • 見たい人が運用環境 (本番サーバ) を見れるようにしておくべき
        • 開発者からも運用環境 (本番サーバ) を見れるようにすべき
        • 新人にも運用環境を見れるべき
          • 人が育たなくなってしまう （人を育てる意味でもサーバーは見えるに越したことはない）