インフラエンジニア討論会に行ってきました

初めに

運用・監視ツールはあまり知らない領域だったので初めて聞く名前が多数（せいぜいNagiosくらい）で、ちょっとメモが付いていけなかった。というか、普通にメモをするのが追いつかなかったので、間違っている部分があると思います。間違いがあればご指摘下さい。
ふだん、運用はさっぱり業務外なアプリ開発の人間ですが、参加してきました。
自分が作ったシステムを運用するのは、自分でだってできるようになりたいじゃん。っていうのが動機。

パネラー自己紹介

• 和田さん(id:wadap)
  • イケメン
  • 学生のころはバンドやってた
  • インフラエンジニアになっちゃった
  • OSとミドルウェア込みの勉強会をやりたいなぁ
• 越川さん
  • 個人事業主から会社の設立を行った
  • 仕事は個人事業主から引き続き、受託開発や運用
  • データセンター移設の物理設計
  • サービスに適切なサーバの選定
  • ソフトウェアの運用
  • OSSの運用ツール
    • BigBroter(?) で監視
    • Unixサーバの管理
    • 急なアクセス増加に対応
    • 24時間、何かあればメールや電話がくる
  • ターミナルやviで対応する
  • 最近、興味を持っている事
    • 個人のスキル依存した運用
    • 運用担当者は手順書通りの作業を求められ、ものを考えない風潮がある
    • もっと自分で考えられるような仕事の進め方をできるようにしたい
• 長野さん（id:kazeburo）
  • Blogを通じてPerlエンジニアと知り合う事が出来た
  • shibuya.pmなどに参加
  • インフラエンジニアとしての仕事
  • 負荷分散やスケーラビリティ
  • memcachedについて
  • Q4M
  • なんでアプリ開発じゃないの？
    • Perlでの運用コストの高さ
    • CPANの利用には知識がある人でないと大変
    • メディアの中の人になりたかった
• 石原さん
  • アセンブラとかやってきた
  • 人生を左右した先輩の一言
    • 回線やってれば食いっぱぐれはしないよ！（23年前）
  • 責任の重さを思い知らされた顧客のひと言
    • システム（回線）を止めたんだから賠償しろ！
  • そこから学んだ教訓
  • ユースケースを網羅し、そこをいかに攻略するかがカギ
  • 当たり前の事をお当たり前にやる
  • 最近の気になる技術トレンド
    • ウォーターフォールからアジャイルへ
• 宮下さん（ペパボの人）
  • http://mizzy.org/
  • エンジニアとしてのモットー
    • 広く浅く、ところどころ深く
    • 昔から器用貧乏だった
    • 「できないから、やらない」ではなく「やらないから、できない」

パネルディスカッション

• インフラエンジニアの定義とは
  • 運用、サーバ管理
  • ミドルウェア設定(Apache,MySQLなど)
  • DCでの実施作業
  • トラフィックの計測など
• 大規模サイトの運用　スケールアップ・スケールアウト
  • mixiでは１０名程度で運用を行っている
    • サービスインした直後はアクセス数が多くなるので、余剰のサーバを追加して耐えられるようにしておく
      • アクセスが落ちつてきたらサーバを減らしていく
    • 1月1日の0:00はとてもアクセスが多くなるので対策が必要。
  • 楽天では・・・
    • サービスを「停止させるな」が基本ポリシー
      • とにかく落とさない
      • ひと月20分の停止時間を目標とする（計画停止を覗く）
    • 手順や作業内容のレビューは必須
    • 数十人体制で運用を行う
    • テレビ対応
      • 「あるある大辞典」とかで商品が紹介されると一気にアクセスが増える
      • topとかで見てるとアクセスの延びがわかるwww
  • ペパボでは
    • ホスティングでは、あるユーザがリソースを使いすぎて他のユーザに迷惑をかけないようにしている
    • ３交代で正月もがっちりやります
    • スケールアップのコツや経験からくる方式は
    • mixiでは、DBサーバのメモリを32G積んで、データがすべてキャッシュに収まるようにしている
  • インフラエンジニアを実感した瞬間
    • （かいてない＞＜）
  • 一流、二流の違いとは
    • 和田さん
    • ファイルのバックアップをしているか
    • プロセスの起動後に確認しているか
    • そういった「当たり前」のことを当たり前にできるよう差
  • 宮下さん
    • なるべくrootにならない
    • 起動したら必要な作業は終わっている、障害があってもある程度自動で復旧できるような仕組みを作っていく
    • 業務時間外にUnix勉強会を開催してりして、ディレクター等にも来てもらって興味を持ってもらう
    • サービスやサーバが停止したら「ほっとけば良いじゃん」とは思えない性分
  • オススメ運用管理ツール
    • OSSが多い
    • NAGIOSを使ってるよ
      • 設定が面倒だけど・・・
      • 見た目はとても良い
    • Hobit
      • 小規模向けだけど、簡単に導入できる
  • 楽天の台湾でのシステムについて
    • ザビックス（綴りがわからん）
      • 設定は大変だけど、そこそこ使える
      • aptで入れられる
    • Monit（プロセス監視）
      • プロセスが落ちたら起動
  • mixi
    • NAGIAS
      • 設定用の簡単なプログラムを作って導入コストを減らす
      • 自作の性能監視ツール（CPUã‚„memcachedの動きをトレース）
  • ペパボ
    • puppet（rubyで実装）
      • プロセス監視等
    • ネットワークの設定以降のサーバセットアップのタスクをすべて設定するようにしている
    • SVNでパペット設定を管理しているので、変更のトレースができる
  • Archer
    • SVNからパペットサーバへパペットの定義ファイルを取得して、各サーバへパペット定義を実行していく
    • 野良スクリプトの管理ってどーする（和田さん）
    • できるだけ、野良は作らないようにする。必要であればSVNで管理して野良スクリプトは出来る限り管理するようにする（宮下さん）
• 気になるあのサービス（使ってるサービス等）
  • CiFTR(シフター)「おかんでも使える！」
  • mixiエコー
• 会場から質問：クラウドコンピューティングや仮想化は今後増えていく？（会場からのid:malaみたいな人の質問）
  • 増えると思う（和田さん）
  • 仮想化で運用コストは減らせる
  • 少人数で対応できるようになる
  • 少数のエキスパートと数人の”そこそこのエンジニア”でやっていけるような感じになるのではないだろうか
• ワークスタイルの勘所　インフラエンジニアの働き方とは？（一言で）
  • 宮下さん：楽
    • 良い意味で、いかに手を抜いて運用できるか、楽にできるようになるか
    • 後で楽をするために最初の苦労をいとわない
    • 大変だけど、そこを楽しめるような人物が重要
  • 石原さん：ネットワークの酸素
    • 常に情報をフィードバックできるように
    • フロント側とあわせて、コミュニケーションをとって方向を決めていけるように

（ここから電源不足になり記載できずorz）

総括

個人的には、もう少し運用・監視ツールをどうやって使っているかと言ったところを深く掘り下げてほしかったなーと思ったりしたのだけど、インフラエンジニアという括りで話にはちょっと細かい所に入りすぎてしまうか。。。
あと、インフラエンジニアの給与等の評価についてどのように取り組んでいるのか？　という質問が会場から上がっていたのだけど、やはりみなさん苦労しているようだった。確かに、何か作業が発生したとき（＝トラブル発生時）の方が給料が良いというのはなんとなく間違っている気がするのだけど、簡単な定量化は難しい。アプリ開発だって、創意工夫して8Hで仕事を終わらせる人とダラダラ10H仕事している人で、残業代の分だけ損するのはどーなのよ？　ってのはあるし。。。
あと、おそらく「落とせない」サービスだとどこでもそうなのだろうけど、「徹底した手順化」をして、誰でも出来る反面、それ以外はやらないという作業になりがちで、そうなってしまうと個人の技量を発揮する場面もなくなってしまうんですよね（手順外の事をやった方がおこられちゃう）。そうなってしまうと、作業者のモチベーション的にも上がらないし、評価も上がりにくくなるんじゃないかな。
今回のイベントは普段、あまり接する事の無い世界に触れる事が出来て、色々と刺激になりました。
もし運用・監視系ツールに特化したLTとか勉強会とかあったら、参加してみたいですね＞＜