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

なみひらブログ

学んだことを日々記録する。~ since 2012/06/24 ~

「Developers Summit 2014」に行ってきました。【1日目】

Chef Web 運用 品質 インフラ セミナー 書籍 リンク プレゼン 開発プロセス プログラミング チームビルディング

日本最大級のソフトウェア開発者の集い「Developers Summit 2014」に行ってきました。

Developers Summit 2014:開発者のためのITカンファレンス

開催概要

  • 2014/02/13(木)、14(金) 10:00-18:00
  • 目黒雅叙園
  • 参加者数 約1000人/日
  • 発表資料はこちら。

デブサミ2014、講演関連資料まとめ:CodeZine

会場雰囲気

f:id:Namihira:20140213095916j:plain

セッションメモと雑記

サーバプロビジョニングのこれまでとこれから

  • 以下の本をざっくり説明した内容。

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

  • たまたま今読んでいる本だったので、理解が進みました。
  • Orchestration
    • 複数のサーバを管理するレベル。各サーバが自律協調する。今、サーバが簡単に増減できる時代になったから必要になった要件。
  • Configuration
    • 単体のサーバを管理するレベル。Chefなどはこちらを対象としている。←自社はこちらのレベル。
  • Infrastructure as Code
    • サーバ構築のワークフローに変革をもたらすもの。※もうもたらしている?
    • 以前は秘伝の手順書に沿ってコマンドでサーバ構築する時代だったが、これからはその構築をコードをして蓄積し、構成管理の対象とする時代。
  • Immutable Infrastructureという運用が流行っているらしい。※AWSなどでサーバ構築・管理のコストが減ったため。
    • 動いているサーバには手を加えない。
    • 変更したい場合は新規で作る。その後、ロードバランサで切り替え。
    • 新しい環境が正常に動いているなら、古いモノは破棄する。
  • Container Base Infrastructure
    • 「Container」とは、ざっくり言うと軽量化VM。サーバ部品のコンポーネント化。個別差し替えして運用する。
  • インフラ構築もコードベースでできるなら、テスト駆動で作業しなければいけない。
  • 以下はあとで調べる。
    • Test Kitchen:Chefのテストツール
    • serverspec:ChefでもPuppetでもテストできるツール
    • Docker:最近日記でよくみる。食べ物?
    • Serf:サーバが新規追加されたら、上流のロードバランサに存在を通知する仕組み。自律協調の実現ツール。
  • 所感
    • 「ウェブオペレーション」をたまたま今読んでいたので、理解が進みました。
    • AWSのようなものの誕生(2002~)で仮想サーバ構築が低コストになった昨今、構築・運用に大きなパラダイムシフトが起きているようだった。日進月歩。
    • 「インフラ構築もコードベースでできるなら、テスト駆動で作業しなければいけない。」の言葉はなるほどだと思いました。ツールもいろいろ出てきているようなので、触ってみたいです。
    • 「Chef」のテストツール「Test Kitchen」のネーミングセンスに脱帽。

グリーにおけるChef導入事例~既存の資産を活かし新しい技術を導入する~

  • GREEの中にヒトの発表
  • GREEはChef Soloを使っている。
    • Chef Serverを選択しなかった理由
      • 単一障害点になる。(※無償版の場合)
      • 既存のサーバ管理があったので。情報管理が重複するから。
      • Chef Serverは運用のために多くのソフトウェアを必要とされるから。Erlang使える人がいない。
  • Chef Soloを使う上での工夫。
    • 既存でサーバ管理のサーバがあって、Chefの設定共存しないといけなかったので、「Chef Bridge」を内製した。
    • 「Chef Bridge」:サーバ管理サーバ内の情報を取得できるAPIを提供する。
  • 「世間的にChefは知名度があるが、Chefを仕事で使っているヒトは少ないし、使えるヒトは少ない。」※そうなんですね。
  • この発表でも、「Test Kitchen」「serverspec」が出てきた。
  • サーバ構築の際に打っているコマンド・実行ログを保存したいとき。
    • 昔はscriptコマンドを使っていた。今はChefのReport Handlerを使って、MongoDBに自動で入れるようにしている。
  • 以下はあとで調べる。
    • Chefのロールの概念
    • chefspec
    • foodcritic:Chefの記法チェックツール。※また食べ物っぽいツール

テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする

  • 障害対応時、担当者を決めないだけで、対策期間が30パーセント伸びる。
  • 優先度の指標として、新しく追加されたコードをテスト/障害対応を行うとよいという傾向がある。
  • テストの自動化は4回実行するとペイできる。
  • 以下はあとで調べる。
    • Coverity Scan

社内システムの構造と設計、実装のはなし

  • 発表はLINEのヒト。
  • 社内向けシステムの構築で気をつけるべきこと。
  • 社内システムであっても、モジュール化、API提供をちゃんと考えるべき。
  • フォーマットはJSONを選んだ。「長期運用できる」が一番大切な要件。
    • 自分の目で確認できるから。
    • データ更新が用意にできるから。
  • プロトコルはHTTPを選んだ。
    • テストの容易にできるから。※curlとか?
  • とりあえず動くことを目指せ。
  • 使われない機能はリリースするな。使われているのかを調べること自体がコスト。
  • 機能の優先度をちゃんと管理しろ。「優先度ハック」。
  • 機能は細かく1つ1つで動くもので定義すべき。そうすれば、単機能になり疎結合にできる。
  • 今いらない機能は後で作ればよい。だって、それはいつでもリリースできるから。
  • 「積極的にサボる」
  • 社内システムほど試しやすいものはない。顧客は自分。

事例から学ぶDevOps実現のためのプラクティス

フロントエンド開発者になるための切掛と行動

  • 「仕事=保守的な技術」と「趣味=最先端の技術」のギャップ。
  • コミュニティに参加し、一皮向けた。「同じ意識をもって、議論すること」が大切。
    • 以前は自分で情熱的に勉強していたが、それは「独りよがり」なやり方だった。
    • ReadOnlyな勉強だった。ただ読んでいただけだった。知識を借りているだけだった。
    • 噛み砕いで人に説明できないといけない。
  • 「仕事」に最先端の技術を入れるためには。
    • 実績と実用性を出し続ける。
    • 他のヒトにやらせてみる。
    • 継続的な活動を通して、いつか手札として見せる。「何が欲しいの?」「何ができるの?」という会話の時に出す。
  • 「楽」:”らく”から”たのしい”へ
  • 所感
    • 自分はヒトより本を読んでいることを自負していますが、それが「知識を借りている」だけになっていることははっきり言われました。。。
    • 知識をちゃんと噛んで、手を動かす、脳を動かして、自分のモノにしてアウトプットとしていきたいと思います。

ソフトウェア開発を勉強し始めて3年間でやったこと~After~

  • bleis-tiftさんへのあこがれ。ブログ:ぐるぐる~
  • わかったこと、わかんないことを、ちょっとでもいいから書き出す。
  • 「考えないこと」はダメだし、「考えたことを表現しない」こともダメ。
  • 思いがあれば実現できる。

快適さはWebサービスの生命線!Webアプリのパフォーマンスを最高にするために心がけること

  • 「ザ・スポンサーセッション」って感じで、後半聴く気ほぼなかった。
  • アカマイ製品の説明
  • 画面描画が早いと、サイトからの離脱率が低下する。
  • 最近はモバイルユーザでも画面遷移時間を待ってくれない時代。
  • 現在多くのサービスはクライアントにデータを全て送っている(~1.3MB)。しかし、クライアントは画面描画に200KBぐらいしか使っていない。
  • 画面遷移を高速にするための工夫。
    • クライアントを識別し、接続回線情報を識別し、最適なデータサイズで返却することが大切。
    • 高速化のために見える部分だけ、先に送る。描画にいらない情報は送らない。

何故クックパッドのサービス開発は日々進化しているのか

  • 一番面白い発表でした。
  • この会場にクックパッドの開発者は居ない。クックパッドはバレンタインが一番忙しいから。
  • クックパッドの他の資料も参照。発表資料 | クックパッド開発者ブログ
  • クックパッドの組織
    • インフラ部:インフラやるヒト。
    • サービス開発部:サービス開発するヒト。
    • 技術部:足回りをやるヒト。ミッション「全てのCIビルドを10分以内にする」など。
  • 開発ツール「chanko」:cookpad/chanko · GitHub
    • 概要:一部のユーザだけ機能を見せる。その機能についてエラーが発生したら、デフォルトを見せる。「絶対にユーザに迷惑はかけない」というポリシー。
  • 徹底的なGitHub駆動開発。
    • マージは本人がする。チーム内のレビューは必ず必要。HTML内の用語変更などはレビューなしでも可、自己判断。
    • 設計行為もGitHubのissuesで行う。
    • デザインさんもGitHubを使っている。デザイン変更の際、デザインさんがPull Requestを出してくる。
    • サポート区もGitHubを使っている。
      • サポートは依頼を投げたら心配する。開発区は進捗を見せるべき。
  • LGTM=“looks good to me.(私はいいと思うよ)”
  • デプロイ時間できる時間は決めたほうがいい。定時ギリギリや休日前にコミットさせない。クックパッドは月~木の9:30~17:00まで。
  • インフラが権威的にならない。
  • 「hipchat」を使っている。
  • クックパッドの文化
    • 正しいと思ったら行動。自分で文化を作る。
    • 社員一人一人にユーザがいることを意識すべき。
      • サービス開発部、インフラ部→お客さん
      • 技術部→サービス開発部、インフラ部
      • バックオフィス系→サービス開発部、インフラ部、技術部
    • 社員は社外の開発者へ貢献すべき(それが社内の評価項目にもなっている)。
    • 会社で作成したライブラリを個人名で出すなど。会社の経営陣はその行為を「許可」しているのではなく、「推奨」している。
    • なるべくルールを作らない。ルールにしない。
    • 許可を取るより謝罪せよ。ユーザのことを思ってとった行動なら、誰も責めない。
    • 文化を共有、信頼し実行する。
  • 所感
    • クックパッドってこれまで「開発一筋で進めー!!」といった感じで人間の体温が感じなかったが、この発表でそれが勘違いであったことが分かった。
    • GitHubで全てが回っており、デザイン・サポートさんに使っていることが驚いた。「うちの会社の関連区は使えないなあ~」と思っていたら、発表者がすぐに「彼らには使えないと思うのは失礼ですよ。30分教えればちゃんと使えるようになりましたよ。」と言われた。すいません。
    • 社外への発信能力も高く、社外の開発者にとって魅力的に見えるんだろうなと思いました。また、その発信が開発者のモチベーションも高めていると思います。

所感と雑記

  • 去年もデブサミに来ましたが去年聞かなかったツールの名前が今年は聞こえてきて、改めて進歩が早い業界だと感じました。
  • デブサミはこういった情報が得られる場としてありがたいです。
  • また他社の雰囲気も感じることができ、それを通して自社と比較が出来ました。※自社はやっぱり決まったことはちゃんとできるが、それが変化のない保守的な会社だと感じました(;´Д`)←正に自分のこと。