Hatak::Techlog

Verba volant, scripta manent.

YAPC::Asia Tokyo 2011 (2日目) に行ってきた

昨日に引き続いて、 YAPC::Asia に参加してきました。

個人的な視点で、今回の YAPC から感じた Perl とそれを取り巻く Web サービス系の世界の現状をいくつかまとめると、

  • 前回参加した 2 年前に発表された PSGI はもはや標準
  • プラットフォーマーを中心に大規模サービスのノウハウが溜まってきている
  • アプリケーションの設計・実装でも、ミドルウェアやハードウェアも含めた視点がより大事になっている
  • 組織が大きくなった会社では、開発者と運用者の良い関係づくり (DevOps の考え方) に取り組んでいる

といったところかなと思います。 会社で標準的に使われている開発言語が違っても、根底の考え方や Web サービス系全般での動きは同じだなと痛感しました。

続 Unix Programming with Perl

※講演資料 [No Title] DeNA の kazuho (@kazuho) さんの講演。前回に引き続いて、Unix 環境で正しく動くコードを作るための Tips 紹介のトークでした。Unix の知識が足りずまだ理解が追いついていないので、調べて試さないとと感じた発表でした。

正しいコードを書くために

  • テストだけでは足りない
  • 常に正しく動くコードを書くためには知識が必要 – Perl の知識 – OS の知識

IPC::Open3 によるプロセス間通信

  • pipe したときにブロックしてしまうケースがある – 子プロセスが STDIN 待ちになる場合 – 子プロセスが大量のエラーを吐く場合 — pipe が制限を持っている —- MacOSX : 16 Kbyte —- Linux2.6 : 64 Kbyte
  • deadlock とならないためには？ – クローズしてもうまくいかない – 標準出力全部読んでもうまくいかない – IPC::Open3 のオプションとして、標準エラー出力に undef いれる – pipe を使わず temporary file 使えばいい

Unix signals と race condition (競合状態)

  • POSIX::pselect – pselect の外で SIGHUP — 多くのディストーションでの実装がバグっているため、実際には解決しない – eval & die — これでもうまく解決しない – call syswrite on signal

まとめ

  • buffesize は無限大ではない
  • shell invocation は危険なので system か IPC::Open3 を使う
  • Unix signals のハンドリングでは競合に気をつける

運用しやすいWebアプリケーションの構築方法

※講演資料 [No Title] Livedoor の kazeburo (@kazeburo) さんの講演。これまでの運用経験を基に、運用しやすい Web アプリケーションとなるためのログや DBI / cache の使い方・Tips をまとめて紹介されていました。確かに、と思うポイントが多く、とても参考になるトークでした。

運用しやすいとは？

  • 耐障害性を考慮に入れた設計
  • アプリケーションからの情報発信
  • 処理単位の明確化

ログ

  • 「アプリからの情報発信」 – 障害発生の際に最初に見る – 障害の検知、原因の特定
  • 適切なログに含まれる情報 – 時間 – ログレベル — 基準を決めて “DEBUG”/”INFO”/”WARN”/”ERROR” を使い分ける – 環境 — pid や uid、引数など – caller / stacktrace – 読み取る人に伝わるメッセージ
  • Log::Minimal – 上記の適切なログ基準に沿ってログを出せるようにした – シリアライズ / カラーリング なども可能

DBI (SQL)

DB 負荷が急上昇するケース

  • 原因クエリ探す
  • なんのクエリかアプリで確認
  • ORM を使っていると調べにくいこともある – SQL とコードが一致しなく鳴るため、SQL 生成を避けたい
  • DBIx::Sunny – caller 情報を SQL に埋込みクエリコメントにできる – SQL::Maker と組み合わせて利用できる

接続が滞留するケース

  • 最大接続数に達して接続エラー – メンテナンス時に timeout まで待つ – SHOW INNODB STATUS が見れない
  • 接続滞留対策 – Scope::Container — DB 接続部の処理単位を短く、わかりやすく – Scope::Container::DBI — 上記を簡単に実現するために便利機能を追加したモジュール

cache / memcached

  • 課題 – Session::Store::Memcached — 簡単で高速、Expires 処理も自動化できる — 一方でストレージ永続性がないのは困ることもある – 特定キャッシュへの集中 — 分散アルゴリズム上でも特定サーバに集中してしまうことがある – cache thundering herd problem — memcache 上で exipre した瞬間に DB にアクセスが集中してしまう
  • Cache::Memcached::IronPlate – 冗長して保存することで cache の冗長性確保 – cache の負荷分散も行える
  • Cache::Isorator – ゆっくり expire させることができる

Metrics

  • プロセスのステータスを取得できるようにしてグラフ化する – Plack::Middleware::ServerStatus::Lite – Parallel::Scoreboard

まとめ

  • 耐障害性を考慮に入れた設計 – cache – memcached
  • アプリケーションからの情報発信 – DBI – ログ – Metrics
  • 処理単位の明確化 – DBI connection

watch your log

DeNA の nekokak (@nekokak) さんの講演。社内 DevOps の観点から基準を決めてログ出力し、それを監視するためのツールを作成したというお話。”DevOps” と “ログ監視” については各社でかなり試行錯誤しているところかもしれません。 ログ監視は最近色々考えていて自分で実装しようかなと思っているところだったので、Komainu も試してみます。あと、「必要に応じたエンジニアリング」というスタンスはいいなと思います。

DevOps

  • Dev と Ops 相互に協力する事が必要 – 自社 Dev は運用を考えられなければならない – 自社 Ops は Dev から渡される運用を丸受けしてはダメ
  • Dev Ops の垣根取り払って密なコミュニケーションを
  • 運用を考えられる Dev – 障害は一次対応が Ops のことが多い – 運用したことないミドルウェアを導入する場合は、事前に互いに調べて共有 – 仕様変更 / 新機能のリリースタイミングで共有を行う
  • 丸受けしない Ops – サービス仕様・アーキテクチャを理解 – 障害発生時に何を対応する必要があるか理解 – 必要な情報は Dev に提出 – 「お母さん役みたいなもの」

コミュニケーション濃度の問題

  • お互いしっかりコミュニケーション取る
  • コミュニケーションもレベル・粒度ある
  • 「お互い言い分あるだろうが gdgd 言う前に行動しろ」

障害そして監視

  • 障害検知の仕組みとして監視必要 – 死活監視 – リソース監視 – ログ監視

ログ

  • お互いで取り決めたフォーマットに沿ったログ出力 – Dev と Ops が面倒みるにあたって取り決めるといい
  • accesslog / errorlog – 監視する項目の取り決めをしておく – ステータスコード監視でサービスがどのような状況か分かる
  • applog (syslog) – フォーマットの取り決めが重要なところ – 障害レベルの分類をログレベルで出力するなどの取り決め — 携帯にメールか、会社のメールかでレベルか
  • mysql slow log – だいたいボトルネックは DB のことが多い
  • ログ収集方法 – ログを良い感じで監視できるソリューションがない

Komainu

  • 設定に応じて集計 – accesslog 集計 – applog 集計 – mysql slow log 集計
  • アーキテクチャ – fork model – notify は IRC と Email – データは database に保存 — サマリ集計し、前回からどれくらい増えたか知りたい — グラフ化する — プロセス間通信せずにデータを受け渡す
  • 何が重要か – サービスクオリティ維持のため – 利用者からの問い合わせベースで障害に気づくのは情けない – 攻めの運用 – ログ情報を通知することでエラーに向きあう

Shut the fuck up and write some code

  • 行動こそすべて
  • 誰かが始めないと何も始まらない
  • 問題意識を持った人が率先して行動 – コードの良し悪しなどはどうでもいい

Managing A Band Of Hackers

DeNA の hidek (@hidek) さんの基調講演。Perl ハッカーを束ねるマネージャーとしての考え方や経験のお話でした。 とてもいい話でした。DeNA には優秀で著名な方が集まっているイメージがありますが、このようなコミュニティというか、仲間の魅力が根底にはあるのだろうなと感じる内容でした。途中、何度もチームを褒めているところが、率直に褒めているように感じられて印象的でした。

management

  • なぜマネージャーが必要？ – 一人では規模の限界
  • 集団で物事を作るということ – バラバラに動くと個人個人のプレーになってしまう – 誰かが指揮する – これがマネージャー
  • “The whole is more than the sum of its parts.” – 1 + 1 が 2 以上になるようにしなければならない

tasks of the manager

  • マネージャーの業務にはエンジニアとしての経験が必要 – 大規模なほど広いレイヤの知識が必要

project management

  • プロダクトのライフサイクルを維持する – エンジニアリング未経験だと無理
  • 計画を立てる
  • 開発中の進捗・マイルストーン管理

personal matters

  • 人事も大事
  • 採用面接 – 見極める力が求められる
  • 配属 – 仕事を与えるということ – その人の持ってる力などを見極めることが大切 – コミュニケーション能力も必要 — その人が何をしたいのかを聞く
  • 評価 – どんな仕事をしたか、を見るためにもエンジニア経験が必要

etc

  • 事務仕事
  • 会議 – 無駄なものもあるが、最近必要と感じることもある — 海外支社とのテレビ会議など、図を書いたりすることで理解が早くなる – Face to Face も重要

the manager of hackers

  • 少しとんがった人たちのマネージャーとして
  • Platform System Group – プロジェクト開始時は 3 名、現在 20 名 – CPAN Author が 6 名

hackers はどういう人達か

  • “no man is an island” – 一人だと寂しくて死んじゃう
  • get bored easily – 飽きっぽい – 餌を与え続ける
  • priority < interest – つまらない仕事を与えつつも、先に楽しい仕事を用意しておく
  • late morning, late nite – 働いている時間は一緒 – 裁量労働なので良いが、相談したいときにいつ来るかわからないのは困ることも
  • KY – 読めない事自体は仕事に影響しないので、悪いことではない – 悪ノリする

what should I do ?

  • これはハッカーのマネージャーだけでなく、一般でも通じるところはある

delegation

  • 仕事を任せる – 失敗もするけど、任せると成長する
  • 自分でやっちゃおう、と思うこともある
  • 「任せる」と「丸投げ」は違う – 任せるための準備はする – バックアッププランは作る – 失敗したらマネージャーが責任を持つ

bad news first

  • 悪い報告を先にするようにしてもらう

TMTOWTDI

  • やり方は一つではない – これはマネジメントだけではない
  • 多様性を許容する

マネージャが少ない会社は大変

  • マネージャは優秀なエンジニアじゃないとできない – 選択肢として考えて欲しい

コミュニティに参加して欲しい

  • 技術的な刺激を受けられる
  • 人脈を作る – マネージャとして重要 – 最終的には経験の糧になる

このほか、LT なども面白く刺激的なものが多く、とても良いカンファレンスでした。

次回がどのようになるかはまだ未定とのことでしたが、次回が YAPC::Asia どこで行われても参加したいと思っています。同時に、これまではカンファレンスやセミナーに参加しつつもずっと聞く側でしたが、今後は YAPC に限らず、もっとコミュニティ全般に対して積極的に貢献できる活動をしたいと思った 3 日間でした。

発表者、スタッフ、参加者、そしてスポンサー企業のみなさま、お疲れ様でした。