初めてのYAPC

perl

Perlを始めて2ヶ月が経とうとしています。

昨日はYAPC::Asia Tokyo 2011に参加してきました。


僕がYAPCに行って得たものは

  • Perlの世界に触れられたこと
  • Perlを用いたサービス運用のTips
  • 周りの先輩方の偉大さを改めて実感できたこと

です。


今の自分が恵まれた環境にいることを改めて実感、

そしてその環境を活かしきれていないことを反省しています。

積極性、これが自分に足りていないものだと感じました。


LT後のManaging A Band Of Hackersでは

若い人はコミュニティに参加してほしい
人脈は大事

ということをおっしゃっていました。

これまでコミュニティに参加するのが苦手でしたが、これからはもう少し積極的になろうと思います。

単に人脈を広げるのではなく、人望のある人間を目指して。

ものを作って結果を残す。


watch your logの発表の際に引用されていた

Shut the fuck up and write some code.

この言葉を胸に刻んでおきます。


今はまだperlでの成果物がない状態ですが、来年にはちゃんと結果を残していたい。

言葉足らずの部分が多いですが、YAPCに参加できたことに感謝しています。

Perlのことがもっと好きになれた1日でした。

スピーカーの皆様、スタッフの皆様、スポンサーの皆様、そして参加者の皆様、本当にありがとうございました。



おまけ
スイーツエリアで販売していた『Acme大全2011』をGET!!

「なんかおもしろそう」と、お土産感覚で購入しましたが、第一章は普通にPerl(Perl界隈のことも)の勉強になりました。

なんでもありのAcmeモジュールおもしろい！

「はじめてのPerl」とセットで読むと楽しくPerlを始められると思います。

以下、講演メモ

運用しやすいアプリケーション構築手法
  • ログの重要性
    • 障害発生時に最初にみる
    • ログがないと時間がかかる
  • 適切なログに含まれる情報
    • 時間
    • ログレベル
      • ログを見た人に何をしてほしいかが明確になっているように
  • ログ管理モジュール
  • 設計思想
  • DBI
    • 負荷は急上昇する
      • 原因となっているクエリを探す
        • show log
      • 何のクエリなのかアプリケーションコードを確認
        • killしていいのか？
        • チューニング、アプリケーションの変更で対処できるか？
    • ORMはSQLとコードが一致しない
      • ORM使う際にはSQL生成するモジュールが散らばらないように
        • クエリコメントを書く
  • DBIx:Sunny
    • 生DBI派向けDBIサブクラス
  • DBI接続
    • connect_cacheは接続の滞留が発生する
      • 最大接続数に達し、接続エラー
  • Scope::Container
  • memcached
    • 課題1
      • Session::Store::Memcached
        • メリット
          • 高速
          • 簡単
          • expiresの自動化
        • デメリット
          • 永続性なし
          • メンテナンスでの再起動は不可
    • 課題2
      • 特定キャッシュへの集中
    • 課題3
      • Cache thundering herd problem
        • 消えた瞬間、dbに負荷集中で落ちる
    • 解決モジュール
      • Cache::Memcached::IronPlate
        • cacheの冗長性確保
      • Cache::Isolator
        • expireの時間をずらす
  • Metrics
    • Paralell::Scoreboard
watch your log
  • 必要に応じたエンジニアリングのすすめ
  • DevOps
    • 運用を考えられるDevにならないといけない
      • Devも一時対応は行えるようにしておかないとダメ
      • 仕様変更等は簡単でもいいから情報共有を行う
    • 運用を丸受けしないOpsに
    • うまくいかないのはDevとOpsのコミュニケーション濃度の問題
      • 障害に特化したコミュニケーションを
  • 障害には監視が必要
    • 何を監視すべきか？
      • 死活監視
      • リソース監視
      • ログ監視
        • ログ監視のソリューションがあまりない
        • ログの出し方をOpsと決める
          • 開発者は数週間したら仕様を忘れる
          • Opsは日々の運用で手一杯
          • ログの出し方はWebDBPress最新号を参照
  • ログ？
    • access_log
    • error_log
      • エラーコードでエラーのレベルわけができる
    • syslog
      • DevOpsのコミュニケーションを活かすところ
      • 重要度の切り分けを行えるログを
    • mysql show log
      • 大規模でボトルネックになるのはdb
      • チューニングの際には必ず見る
    • アプリログ、dbログは日単位でローテーション
  • ログの収集方法を紹介
    • Komainu
      • accesslogの集計
      • アプリケーションログの集計
  • まとめ
    • サービスクオリティの維持
    • 問い合わせベースで障害に気付くのは情けない
    • 攻めの運用
    • Shut the fuck up and write some code.
    • コードの良し悪しはとりあえずどうでもいい、結果が全て
    • 問題意識を持って行動する
    • 密なコミュニケーションを