無印吉澤

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

YAPC::Asia Day 2 レポート 〜 Mackerelの開発言語、ペパボのデプロイ高速化など

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

引き続きDay 2も参加してきました。昨日のDay 1のレポートはこちらをどうぞ。

Day 2に聴講したセッションはこちら（↓）。ベストトーク賞（1日あたり2件、計4件投票できる）は、★付きの講演に投票しました。

全体通しての感想

YAPCは今回初参加だったのですが、Perlは全然使ってない僕のような人間でも十分楽しめました。講演の採択率が非常に低いということもあって、どのセッションもレベルが高かったですね。

全体を通して、ソフトウェアを活用した効率改善・自動化を全力でしている、という事例が多くて、とても刺激になりました。最近、自分が担当した業務では、引き継いだシステムをなんとか解析して、手順書を作るくらいで力尽きてしまっていたのですが、もっと自動化していかないとダメだなあ、と。特にペパボの事例は、既にあるシステムをガンガン改善していく事例として、見習わなきゃいけない、と思いました。

あと、YAPCで一番驚いたこととしては、Consulってこんな普及してたんですか？　いや、完成度の高いツールだとは思っていたんですが、利用する場面ってもっと限られたツールだと思い込んでいました。一度使ってみたほうがよさそうです。

以下、個人的に興味を持った講演中心のメモです。

講演内容

[★]Mackerel開発におけるScalaとGo、そしてPerl (Masayuki Matsuki, @songmu)

スライド: Mackerel開発におけるScalaとGo、そしてPerl

Mackerelで複数のプログラミング言語を、どのような基準で使い分けているか、という講演。タイトルからして大人気講演だと思うけど一番狭い部屋か……と思って行ってみたら、案の定大混雑でした。

  • Mackerel

    • はてなの社内ツールを前身に、作りなおしたツール
    • エンジニア6人、デザイナー1人、インフラ1人、スクラム開発（1スプリント2週間）

  • 技術スタック

  • Scala

    • サーバサイドにPlay! Framework (Scala)
      • ゲームほど頻繁にリリースするわけではないので問題ない（それでも毎週リリースはしてる）
      • Javaも良いと思うが、社内で関数型を書きたい人がいた
    • Optionは便利
    • コンパイルは遅くて、だいぶストレスはある。ただ、クリティカルなバグは混入してないので、固いものを作れるのでは
    • テストが遅い。型チェックがあるので、小さいテストを書き過ぎない、マインドチェンジが必要
    • 仕様が膨大すぎて破綻しかかっているのが可愛い → 無限に勉強できる
      • 例：アンダースコアを省略できる箇所とできない箇所
    • 大きい物をかっちり作るには向いている（はてブもリニューアル部分はScala）

  • Go

    • シングルバイナリが吐ける → セットアップが簡単
    • マルチプラットフォーム対応が比較的容易
    • フットプリントが小さく、監視対象のパフォーマンスへの影響小さい
    • 事例
      • mackerel-agent（ユーザのホストにインストールする常駐プロセス）
      • mkr（Mackerel操作のためのコマンドラインツール）
      • URL外形監視ワーカー（URL外形監視用のジョブキューシステム。キューにはRedisを使用）
      • blogsync（はてブロ用のクライアント。はてブロの記事をMarkdownしてgitで管理）
    • 利用しているモジュール
      • Graceful Restart: 2つのモジュールの組み合わせで、perlアプリと同様の運用ができる
      • Goの常駐プロセスの監視: golang-stats-api-handler
    • 開発中に、Perlモジュールの思想を受け継いだモジュールをいくつか書いた
    • 型がありつつ、コンパイルが早いので嬉しい。LL的なリズムで開発できる
    • 並行・並列処理が言語組み込み
    • クロスコンパイルが良いと言われる → 実際ちゃんとやろうとすると大変
      • 特にWindows
      • パッケージングが大変（rpm/deb/msi）
    • Goの使いドコロ
      • コマンドラインツール
      • microservicesを実現するコンポーネント
      • 大きすぎるものにはマッチしない。書き捨てにも向いてない印象

  • JavaScript

    • (スライドすっとばし)

  • Haskell

    • 入社していきなりJavaScriptのプロファイラ書いたitchyny++

  • Perl

    • 事例
      • mackerel-agentのリリースの自動化
        • GitHub, Travis, AppVeyor（msiのコンパイルに使用）
      • Mackerelに関するCPANモジュール
        • MackerelのAPIクライアント、Mackerelのwebhookを受け付けるWebサーバ
    • プロジェクトの渋い脇役：だいたいどこでも入っている
      • シェルスクリプトで書くくらいならperlでやりたい
    • 自動化スクリプトにツールを同梱できる
    • 柔らかいアプリケーションサーバレイヤとしても使える（はてブの顧客向けAPサーバ部分に使おうとしてる）
      • 全部Scalaでやるのは大変。修正からデプロイまでに時間がかかってしんどい

  • 自動化機構は負債になりやすい

    • 肥大化してブラックボックス化 → メンテ不能
    • 1枚のperlスクリプトの中にテストも書く（perlから起動したら実行、proveから起動したらテスト）
    • ツールの責務を分ける（1個のツールは1個のことを）

  • リリース自動化の解説

    • GitHubのtoken（権限大きすぎる）を使う代わりに、Deploy Keyを使った

  • OSSにするときに気をつけていること

    • ユーザーがハックする余地を残す
    • pull requestは公平に扱う
    • レビュー体制、CIやリリースをオープンにする

  • Ruby

    • 事例
      • fluent-plugin-mackerel
      • cookbook-mackerel-agent
      • Capistrano
      • git-pr-release
    • fluentdやChefなどのエコシステムに乗っかるときに使う

  • We are hiring

    • 東京オフィスのエンジニアがここ1年で 1人(songmu) → 6人 に。

我々はどのように冗長化を失敗したのか (Kenji Naito, @kenjiskywalker)

  • 挑戦したこと：式年遷宮インフラストラクチャ
  • ACT/SBY → いざというときに入れ替えても動かないことが多い
    • 普段から定期的に入れ替えておけばどうか？
  • RedisのMaster/Slave構成で式年遷宮
    • Redis Sentinel：3台必要
    • マシン3台用意したくない → Masterに1プロセス、Slaveに2プロセス動作させて回避
    • Redisが遷移したことをWebサーバに知らせるには？ → ConsulでDNSレコードを返すルールを設定
  • MySQL: MySQL 5.6(GTID) + mysqlfailover
    • mysqlfailoverで、遷移実行前後に処理実行 + Consul
  • Consulに重要な情報が集まりすぎてSPOFに → consul-template でConsulが管理する情報をhostsに書き出し
  • 失敗
    • ステージング環境で発生せず、本番環境のみ発生した問題いくつか → ステージング環境と本番環境は同一にしよう
    • 開発スケジュールがタイトだったこともあり、自動切り替えの仕組みは止めてからリリース（いざとなったら手作業で切り替え）

MySQLで2億件のシリアルデータと格闘したチューニングの話(斉藤 健二, @saiken3110)

  • DNPデジタルコムに3年ほど所属
  • システムの概要
    • 商品を買うとシリアルコードがついてきて、それをWebから入力するとポイントが付く
    • CPU 2コア、メモリ 8GBのマシンで2億件（顧客要望で、マシン増強はできず）
  • データ登録、負荷テストは70分で終わったが、本番は75時間かかった
    • 負荷テストのときは主キーはシーケンスで連番、本番はランダムな数字
    • innodb_buffer_poolが枯渇した時点からinsertが大幅に遅延
    • 本番でも、主キーをシーケンス、ユニークキーをシリアルに変更してみた。75時間 → 30時間 に短縮
  • update（ステータスの更新）も遅かった
    • indexの再構築がかかるため、遅くなったと思われる
    • ステータス管理をやめ、管理テーブルを作成し、update自体を不要にした。60分 → 45秒に改善
  • まとめ
    • 負荷テスト大事（実際のデータに近いデータで）
    • 負荷テストは開発のなるべく早めにやっておいたほうがよい

[★]3分でサービスのOSを入れ替える技術 (SHIBATA Hiroshi)

  • 自己紹介

  • 2014-11-xx

    • @antipop: 3ヶ月後に某サービスでCM打つのでバーンとやってほしい
    • Railsでできたサービス。当時はAPサーバ6台。用途不明のサーバもあるような状態。
    • 元々担当者じゃなかったけど、なんとかしてほしいと頼まれた。
    • Golden ImageからVMを作り、設定変更すればVM増やせるが、1台あたり4〜6時間かかる状態
      • 刺身たんぽぽ
    • 課題：これをスケールアウトできるように
    • チームメンバ： hbst, udzura, yano3（全員フルスタックエンジニア）

  • 最初はPuppet化

    • Puppetを使い始めていたが、本番投入されてなかった
    • まず、Puppetを本番投入できるように、サーバマニフェストを全部書き換えた。ppファイル約5500行。
    • puppetmasterdを構築
      • ペパボでは7〜8割のサービスでPuppetを利用中

  • Check point 0

    • ここまで実施して、状態をコードで表現できるようになった
    • この時点では bootstrap time = 4-6hr

  • SSHを使わない（No SSH）

    • SSHを使わない、という方針にすることで、自動化が進む
    • 無駄が起こりうる作業を一旦やめてみることで、イノベーティブな方法が思いつく

  • cloud-init

    • AWS、OpenStackなどを使っている人は、絶対使っているはず
    • ドキュメントが非常に少ない。コードを読んだりして対応。
    • cloud-initでできることはなるべくここに入れる
    • ただし、runコマンドは使わない（runコマンドでやりたいことはpuppetでやる）

  • Rails

    • Rails 3から4にアップグレード
    • キャンペーンを打ってからではアップグレード難しいため、準備段階でアップグレード（アップグレードだけで30分話せるくらい話題がある）
    • Railsのコードから、IPアドレスやホスト名が埋め込まれている箇所は、IaaSが提供するAPIから取得するように変更

  • Check point 1

    • まずは目の前にある手作業を、自分たちの使えるツールに置き換えて自動化する（いきなりDockerとか入れたりしない）
    • bootstrap time = 1hr

  • Capisrano 2をCapistrano 3に書き換え

    • rails bundle。これを使いたいからCapistrano 3にした。
    • build serverで作ったtarballをS3にアップロードし、アプリケーションサーバはS3からダウンロード

  • cloud-initのなかで、ダウンロードしてインストール

  • Consul + consul-alertで死活監視

    • 元々Nagiosを使って死活監視をしていた。Nagiosは人間が入力した設定に基づいて動作する前提。オートスケールに向かない。

  • Mackerel

    • muninはdynamic scaleに対応していない
    • ペパボはmackerelを全社で使っている
    • 開発時には、Mackerelから自動でleaveする機能がなかった。initscriptのなかに、shutdown時にleaveするAPIを呼び出すようにしていた。
      • 2015-07-31にmackerel-agentにauto-retire実装された。

  • td-agent

    • access_logの収集

  • thor

    • メインコマンド、サブコマンド、引数、という構造のCLIを簡単に作るためのライブラリ

  • Check point 2

    • cloud-oriented architecture
    • 手作業でやりそうになったら、それをすべてコードに落とす
    • Bootstrap time = 20-30min

  • bootstrapを遅い作業と早い作業に分類して並列化

    • フェーズを分ける: Minimal image (phase 1), Role specified (phase 2)

  • Packerを使った

    • JSON形式でインスタンスの設定
    • cloud-initも入れられる
    • provisionerというシェルスクリプトも
    • 工夫した点：provisionerを複数実行できるので、最後にserverspecの実行を入れている

  • Infra CI

    • Drone CIというものを使って実現している
    • "nyah"で構築したOpenStack環境上で、Drone CIを動作

  • Puppet manifestのリファクタリング

    • serverspecで自動化されているので、不要なパッケージを削除したりできるようになった

  • Scientific Linux 6からCentOS 7への移行

  • Check point 3

    • Bootstrap time = 3-5min

  • Blue-Green Deployment

    • 超つよいルータの下にぶら下がる→超重要→ELB
    • データベースはまだBlue-Greenにしてない

  • Check point 4

    • Bootstrap time < 3min

  • 次のステージ

    • イメージ作成の全自動化
    • mutableなサーバをどうするか？
    • イメージ作成にはどうしても15分くらいかかるが、10分間隔など頻繁にリリースする場合はどうするか？
    • ここまで来たらDockerを使ったほうが良い？

  • Q: データベースをBlue-Green Deploymentにするアイディアについて

    • A: ノーアイディア。開発者が開発しやすい環境にするほうを重視したほうが良いかと考えている。

  • Q: スケールアウトの指標は？

    • A: 人間が判断して、余裕のある台数まで増やしている。将来的には自動化したい。

ソーシャルゲームにおける AWS 移行事例 (@tkuchiki)

  • 事例1：冒険クイズキングダムの移行

    • RDS for MySQLの検証に一番時間がかかった
      • タイムゾーン設定
      • failover
    • レプリケーションは、time関数を使っていると9時間ずれる→mysqldumpで対応
    • レプリケーションが遅かった。209分。これを90分まで時間短縮

  • 事例2,3：僕らの甲子園！熱闘編のMobage版とiOS/Android版の移行

    • Kyoto Tycoonをyrmcdsに移行
      • yrmcds(よるまくど)はサイボウズが作っているセッションストレージ
    • Consul lockを活用したフェイルオーバーシステムを作った
      • ネットワークの問題かなにかで、Consulが数秒Leader lostすることがあった
      • 移行後2日連続でfailoverした → 現在この機能は使っていない
    • ZabbixとJenkins Slaveの話は時間の都合でスキップ

  • 知見

    • 10数台規模のシステムであれば、2〜3名程度で1ヶ月程度あれば移行できることがわかった
    • AWS移行は、構成を見直す良い機会になる

辛いことをやめる！から始まる業務改善とInfrastructure as Code (Yuichiro Saito, @koemu)

個別具体のツールに関する話ではなくて、組織内で新しいツールを導入する際の、アプローチに関する話でした。

  • 自己紹介

    • ハートビーツのなかで、組織全体の効率向上する仕事を担当
    • 大企業で言うと、標準化部門のようなところ

  • 背景

    • 2012年、AWSなどのIaaSを使う案件が増えてきた
    • リードタイムがほぼ0になり、サーバの調達が劇的に変わってしまった
    • それでも手作業で構築していた → 残業時間がこの時期はとても長くなっていた
    • 日々の仕事に忙殺されて、新しい仕事もできなくなってきた

  • 改善に向けた活動

    • まずは、現状と理想のギャップを認識する（"goal-reality" pairs）
    • 敵を作ってでも問題解決しよう、という態度は取らない
    • "Inner Work Life": 知的労働者はモチベーションによってパフォーマンスが左右される
    • 作業の種類：頻繁に繰り返す短い作業、1回だけ行う長い作業
    • ストレス（難易度）とコストの2軸で、作業を分類
      • アンケートやヒアリングの結果を元にまとめた
      • 例えば、監視設定はストレスもコストも高い

  • 必要な人を巻き込む

    • hb-agent, hb-gendoc, Cacti bulk configuration tool, hb-acnsを作っている
      • 今日はhb-acnsの話をする
    • Nagios, Cactiに設定を自動登録するツール
    • 設定はpythonスクリプトとして書くように、わざとしている。プログラム経験が低い人に、プログラムに慣れさせるため
    • CTOの了解をもらって、パイロットプロジェクトを開始。お墨付きがあることをCTOから全社に宣言してもらう
    • 少しでも動かない、「あれっ」という声が聞こえたら飛んで行く
    • ドキュメントを残す、Tipsを大量に書く（Sphinxで書いている）
    • ハンズオンを何回もやる

  • 効果測定する

    • 開発3ヶ月
    • 監視設定のリードタイムは、10分の1以下に下がった
    • 自分の毎月の残業は10時間以下 → 新しい案件、新しい技術に向かえる → モチベーションが上がる
    • プログラミングによって業務効率を向上できることを、作業者に実感してもらう

Lightning Talks (Aug 22) | 8月22日のLT

  • 吉祥寺.pmというイベントを作った話〜聞きたいトークが有れば自分でイベントを作ろう！〜

    • @magnolia_k_

  • 命名の話をします

    • @studio3104
    • 名前以上の機能を持たせない → 「◯◯するやーつ」という名前を日本語で付けてから英訳

  • botになる技術

    • id:debility
    • 自分の発言を記録していた後輩がbot作った

  • モダンなクライアントサイド JavaScript に追い付くためのための小さな（しかし大変な）一歩の話

    • JSのリファクタリング

  • Evaluating your stylesheets

    • @t32k, Kaizen Platform
    • こいつは良いCSSを書けているのか？ → StyleStatsというツールを作った。Web版もある

  • Thank you for ${^ENCODING} variable

  • 本物の "ロック" ってやつを魅せてあげますよ - 分散排他ロック篇

    • @moznion
    • 電話 = 排他
    • Twillo, 使いすぎて expire してデモできない

  • コミュ力あげてこ

    • cho45
    • モールス信号 → 情報量少ない → 伝わると嬉しい → コミュニケーションの喜びを取り戻す

  • CONBUの道具箱

    • 舞台上でいきなり設営〜撤収

  • Vim script静的解析の光と闇

    • kuniwak
    • 闇しかない

クロージング