無印吉澤

Site Reliability Engineering（SRE）、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

YAPC::Asia Day 1 レポート 〜 Miiverseのデプロイ手法、HTTP/2、Electronなど

Event Report
f:id:muziyoshiz:20150822194424j:plain

YAPC::Asiaの2日チケット（Tシャツあり）を購入して、1日目参加してきました。僕が聞いたセッションはこちら。

ベストトーク賞（1日あたり2件、計4件投票できる）は、★付きの講演に投票しました。この2講演を中心に、メモしていた内容を共有します。

ちなみに、大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかた (Kazuhiro Osawa)（スライド） も聞きたかったんですが、立ち見も含めて満席で入れませんでした。残念……。

講演内容

メリークリスマス！ (Larry Wall)

  • Perlの生みの親であるLarry Wallが、Perl 5〜Perl 6の開発にかかったこれまでの15年について、J. R. R. トールキンがHobbitのプロットを一部踏襲・一部改善してLord of the Ringを執筆したことになぞらえて話したセッション。
  • セッションの最後には、Perl 6が、「今年の」クリスマスまでにはかなりの確度でリリースできると発表し、会場の喝采を浴びていた。

世界展開する大規模ウェブサービスのデプロイを支える技術

  • Miiverseのインフラを担当するはてな社員、アプリを担当する任天堂社員による共同発表

    • 中澤亮太(はてな)： これまでにはてなブログ、はてなブックマーク、Miiverseを担当
    • 灘友良太(任天堂)： Miiverseを担当

  • Miiverse

  • 今日の講演は、Miiverseをデプロイする、主に「成果物配布」の部分

  • 従来の成果物配布方法

    • Capistrano2系＋Gitを利用。いわゆるPull型の手法
    • 複数リージョン：海を超えたgit pullつらい問題
      • 対策：各リージョンにgit slaveを立てる
    • デプロイ対象が数百台規模：Gitサーバがgit pullに耐えられない問題
      • 対策：ロールごとにデプロイ、かつホストごとにランダムスリープ。MackerelとCapistranoで同じロールを設定し、デプロイ対象はMackerelのAPIで取得
    • それでも残る問題
      • lsyncdのディレクトリ監視数上限
      • rsync途中でgit fetchしてしまい、ホストごとにリビジョンが異なる

  • 2つのGitリポジトリ

    • Redmine＋GitHub Enterprise (GHE)（主にコードレビューと、一部のタスク管理）
    • デプロイ用とコードレビュー用、2つのリポジトリを使っている
      • git push先が2個
        • git push ghe master
        • git push origin master
      • GHEのmerge pull requestは使わない運用
    • 不便なので、2つのGitリポジトリを同期したい

  • 既存の同期ツールの検討

    • google/hesokuri
      • Google製のGit同期ツール。リリース時に同期を止めたい、などのMiiverseでのニーズに合わない
    • ghm
      • 3年くらい前からはてな社内で開発・運用しているツール（第2回 GREE Tech Talkで紹介）
      • ghmの導入を当初検討したが、問題あり。Miiverse開発チームで使うには、並列化されていなく、遅い。同期が終わる前にデプロイして、古いリビジョンがデプロイされたことがあった
    • そして、新リポジトリ同期システムを開発することに

  • 新リポジトリ同期システムの開発

    • JSON over HTTPなAPI群
    • 改善された同期アーキテクチャ
      • スケーラビリティ
      • 保守性
    • masterからgit pullし、その結果をslaveにgit pushするシンプルなツール
    • GHEのWeb Hookで、同期開始。どのリポジトリを同期するかは、DBから取得
    • 同期ジョブは、複数リポジトリに対して同時に実行可能

  • これから採用しようとしている新しいデプロイ手法

    • Git によるPull型の一般的な問題
      • リリースするものをすべてcommitする → リポジトリの肥大化
      • 各マシンでコンパイルする → 細かい環境の差異で成果物が異なる、ビルドが長くなる
    • Consul + stretcher
      • Amazon S3経由で成果物を配布し、そのイベントをconsulが拾って、stretcherがデプロイ
      • Gitサーバの負荷が解決すると共に、Gitリポジトリには成果物を含めなくて良くなる
      • 成果物の作成〜S3へのアップロードはJenkinsで実行
      • 従来 1142秒 → 29秒に短縮（carton installありで210秒）

  • Q: 新同期システムの言語は？

    • A: Perl5。MiiverseおよびサブシステムもPerl5で開発されているため。手慣れた言語を選択。
  • Q: デプロイの頻度
    • A: 基本的に2週間に1回の頻度。バグがあればhotfix。
  • Q: 新同期システムで、1台だけ失敗した場合の検出はどうする？
    • A: stretcherでは、成功時に実行するコマンド、失敗時に実行するコマンドをマニフェストに書ける。評価時は失敗したらikachanを通じてIRCに通知していた。
  • Q: AWSのCodeDeployを検討した？
    • A: してない。開発時にはまだリリースされてなかった。時期的な問題。

[★]HTTP/2時代のウェブサイト設計 (奥 一穂)

DeNAで、HTTP/2対応のWebサーバ "H2O"を開発している奥 一穂さんによる講演。

  • 背景：バンド幅を増やしてもページロード時間は短くならない。しかし、レイテンシが短いほど短くなる。

    • その裏付けとなるデータ
    • バンド幅の時代は終わった。今はレイテンシが問題
    • HTTP/1.1は多重性がない。同時6本のTCP接続を使うのが一般的だが、それでも遅い。
    • HTTP/1.1パイプラインがある→問題があって使われていない
    • 国内で東京につなぐだけなら10msくらいのレイテンシだが、LTEだと50msくらいのレイテンシ。アメリカまで光ファイバーで往復して80ms。遅くなっている。というのが背景知識

  • HTTP/2の技術要素

    • バイナリプロトコル
    • 多重化
    • ヘッダ圧縮
    • 優先度制御
    • サーバプッシュ

  • バイナリプロトコル

    • 第1の目標は脆弱性を防ぐこと。パーサによる解釈の差（プロクシとサーバで違う、など）を突く攻撃がいっぱいあった。
    • 転送データ量の低減。ヘッダ圧縮する→ボディも圧縮していいのでは。
    • h2iコマンドを使ったデモ（HTTP/2を手で試すことができる）

  • 多重化

    • 同時に100以上のリクエストを発行可能。
    • DATAのstream ID

  • ヘッダ圧縮

  • 優先度制御

    • 重み付け、依存関係をクライアントが指定する。
    • Firefoxの場合：first-paintが大幅短縮。headタグにあるCSS、JSを優先取得したあとで、画像などを取得。body末尾のJS（Google Analyticsなど）は別の優先度で取得。
    • Chromeの場合：依存関係を使っていないので、あまり速くならない。
    • Edge、Safariは優先度制御を全くしていない。サーバ側でなんとかしないと速くならない。
    • サーバ側のreprioritize-blocking-assetsオプションで、優先度制御対応。
    • 実装が悪いために、パイプラインのように実用にならない可能性がある。

  • サーバプッシュ

    • サーバ側から事前にプッシュすることで0 RTTに。H2O, nghttpxが対応。
    • 問題：CSSやJSをプッシュしたい。しかし、ブラウザキャッシュにある場合はプッシュしたくない（プッシュしたら却って遅くなる）。
      • cache-aware server-push: H20 1.5の新機能。fingerprint（キャッシュしてそうか）をクッキーに添付。

  • HTTP/2ではレイテンシではなく、バンド幅が再びボトルネックになる → Webサイトの作り方が変わる。

  • HTTP/2でオワコンになる最適化

    • アセットの結合（asset pipeline）
    • expiresの利用
    • ドメインシャーディング
      • 優先度制御できなくなるので、かえってfirst-paintが遅くなる。
      • CDNを使う場合→最近はHTTPレスポンスもCDN経由で送れるようになっている。

  • HTTP/2にするとクリック数が増える→収益が上がる！

  • H2OはHTTP/2が一番速いWebサーバ

    • HTTP/2はHTTPS前提。Let's Encryptが11月16日からサービス開始予定（無料でサーバ証明書をもらえるようになる）
    • Forward Secrecy
      • session ticketをオフにしないと、forward secrecyにならない
      • H2OはWebサーバクラスタでのresumptionに対応。session ticketの秘密鍵の自動更新機能を実装。

  • Q: REST APIなどのサーバ間通信のためにHTTP/2を使うなら、クライアントライブラリは何を使えばいい？

    • A: HTTP/2に対応したクライアントライブラリは、現状1個しかない。libcurl。
  • Q: first-paint timeの計測方法。Chromeについては計測機能がないのでは。
    • A: timing chartで、最後のCSS、JSを受信した時刻をfirst-paint timeとみなした。
  • Q: HTTP/2はいつ頃普及するか？
    • A: Webブラウザ、Firefox、Chrome、Edgeは対応済み。Safariも秋には対応する。サーバ側も秋にはNginxが出る。HTTPSにならないと恩恵が得られない。LetsEncryptが出てこないと。今はHTTP/2が（なにの？）1割。うまくいけば、年末までに3〜4割に上がるのではないか。

Conway's Law of Distributed Work (Casey West)

  • PivotalおよびCloud Foundryに所属。10年ほどリモートワークをしている。

  • Effective Communication Saves Time

    • リモートワークでは透明性がデフォルトで必要
    • 意思決定の理由を記録する必要がある
      • 例えば、boolean型を使うべきと思われるところで、なぜboolean型を使っていないのか？　意思決定されたときの当時の情報が必要になる。

  • Tools

    • Text Chat
      • 4 primary aspects: archive, group chat, private chat, full participation
      • Slack, HipChat, IRC, Google Hangout
    • ChatOps
      • lita (ruby), hubot (nodejs)
    • audio/video communication
      • headphones, microphone, camera: よい設備重要
      • HipChat, Google Hangouts, appera.in, sqwiggle
    • screen sharing
      • Screenhero (for Slack), HipChat, join.me, WebEx

  • Development Tools

    • Commit Messages
      • critically important
    • Code review
      • Pull Requests, Gerrit, ReviewBoard, Code Collaborator
      • 一時的に開発のスピードを落とすが、欠陥を見つける、などの理由で結果的に早くなる
    • Digital Progress Board
      • Pivotal Tracker, Trello, GitHub Issues, waffle.io for GitHub Issues
      • カンバンスタイルが好き。Jiraは好きじゃないのでリストに入ってない。
        • 質疑応答の時間に、個人的な経験上、Jiraを使う場合はワークフローをカスタマイズしすぎないほうがよい、という話があった。
    • Collaborative Writing
      • Etherpad, Hackpad, Google Docs, GitHub Wiki
      • 共同編集できて、編集結果を誰でも見られるツール
    • File Storage
      • Dropbox, Box.net, Google Drive, NFS
    • Shared Calendar
      • Google Calendar, Exchange
    • Email
      • collaborationのための良いツールではない。非同期。テキストチャットのほうが良い選択肢。

  • Techniques

    • Everyone should experience remote work. 経験してみないと、リモートワークする人の気持ちはわからない
    • Have on-site meetups.
    • Invite remote workers into hallway conversations.
      • 難しい。ビデオチャットなどで。
    • Over communicate.
      • 情報を定期的に共有することが必要
    • Share your personality.
      • テキストチャットでoff topic areaを作って、そこでやりとりする。音楽を共有する、など。
    • Exhibit a "visible pulse."
      • リモートワークでは、自分の状態を知らせる必要がある
    • Pick a timezone. Standard Operating Time (SOT)
      • チャレンジング。打合せの設定などが困難。

  • Sociotechnical Theory

    • リモートチームにもCAP定理が成り立つ。2つしか選べない。

  • Conway's Law

    • Organizations produce designs which are copies of the communication structures of these organizations.
    • The health and quality of your product will be a direct reflection of the health and quality of your organization.
    • 組織構造がプロダクトデザインに反映される、というコンウェイの法則。組織の健康や品質も、同様にプロダクトに反映される。

[★]Electron: Building desktop apps with web technologies (Ben Ogle)

  • GitHubでAtomを担当。最近Atom 1.0をリリースした。

  • Atomはデスクトップアプリ

    • 操作は通常のデスクトップと同様だが、Web技術のうえに作られている。
    • AtomはWebブラウザで出来ないことができる。ファイルアクセスやクリップボードアクセスなど。これは、Electronの上に作られているから。
    • Electron = Chronium + io.js (node.js)

  • Electronで作られているアプリ

    • GitHub Atom, VS Code, Facebook Nuclide
    • JIBO: 家庭用知能ロボ
    • Slack (for Windows)
    • Mojibar （絵文字を検索するツール）
    • その他の事例は http://electron.atom.io/ にあり

  • Electronアプリの構成

    • コマンドでひな形を作成できる
    • Browser Process, Render Process, Entry Pointから構成される
    • KittyDetect: 猫の顔を検出するアプリ。既存のライブラリ(kittydar)を流用して、2時間で書いた。
    • Curve App: ベクタ描画のアプリ。

  • perlでElectronアプリを作ることもできるはず。perlをJavaScriptに変換するツールがあるので、これでできるか試してみてほしい。

    • すでにPerl challengeでやってみた人がいる？

esa.io - 趣味から育てたWebサービスで生きていく (Atsuo Fukaya)

  • esa.io - Expertise Sharing Archives for motivated teams.
  • Qiita Teamのトライアル期間が終了して、有料になったのをきっかけに開発開始
  • 自分のプロジェクトや、知人のプロジェクトで使ってもらって手応え。去年の11月にesaの運営会社を作った。
  • esaじゃない方の会社を今年2月にやめた。有料で使ってくれる人が思ったより増えたので。
  • weekly active members(1週間に何かしらの編集をしたユーザ): 1583

Lightning Talks (Aug 21)

  • Norikraで作るPHPの例外検出システム (Masahiro Nagano)
    • (※TODO: スライド公開されたらリンク張る)
    • PHPではエラーと例外は別物
    • 補足が難しい例外がいくつかあり、設定が必要
    • 発表者の環境では、最終的に4つのログファイルにエラー出力されるようになった
    • ログファイルを fluentd → Norikra → Slack で表示