続・インフラエンジニア討論会2008
昨日のエントリの続きです。メモの転記に加えて、自分の意見も少しずつ挟んでいますので、かなり長いです。敬称略です。
パネルディスカッション
インフラエンジニアとしてのやりがい
(和田) rootという絶対権限をもてる。誰よりも大きな権限を持てる。
(長野) WEBサービスの負荷などが自分たちが予測したとおりに動いたときにやりがいを感じる
和田さんの意見にはあまり賛同できないですね。というのも、自分は上に立つということでモチベーションがあがるということがないから。
長野さんの意見は大きなサービスであるほど実感できることですよね。うちの会社のレベルのサービスだと、WEB+DBを1台ずつで十分まかなえてしまうレベルのものが多い。でも、負荷が上がったときに簡単な対策をうってみて、うまく流れるようになったときにはやりがいを感じられるかな。
インフラエンジニアって何？
(宮下) ミドルウェアから下のサーバ管理
(和田) データセンター作業、ネットワーク、ミドルウェア、DBエンジニア
(越川) 何でもやる(ネットワーク、DB、監視) → システム全体を見渡す
(石原) トラフィックを以下に通すかの設計・構築〜制御・運用。(交通でいうと、土台となる道を作って、信号などで流量制御を行うこと)
うちの会社だと、宮下さんの言ってるのと同じ感じですかね。サービスとしてもホスティングサービスという部分で共通してると思いますし(規模は違いすぎますが)。決して表には出てこないけど、エンドユーザや顧客に見えない安心感を与えることがインフラエンジニアの役割なんじゃないのかなと考えています。
大規模サイトの運用：スケールアップ・スケールアウト
(長野)
インフラ運用＆アプリ運用：10人ちょっとで回している。
新機能の追加などイベント時：あらかじめサーバを余分に投入しておき、落ち着いてきたら適切な台数に減らす。
・サービスインなどの最初は多めにアクセスがあるので余計に投入。
・1月1日が日記の最多投稿日で、対応が難しい。 → 来年の対策は考案中。
ユーザに損害がでるようなクリティカルな機能でない部分には余裕を持ちながらも、チャレンジングなこともやっていく。
ユーザデータはスケールアウトでの対応しかできない。
メモリが安くなっているので、MySQLのデータがすべてメモリに載せられるようならスケールアップで対応。IOを減らせる。(和田)
チャレンジングなことよりも、絶対にサービスを落とすな。
自由よりも手順を重視：必ず手順をチェックする
(100人未満の)数十人規模で運用。
お中元やお歳暮の季節はシステムを増強する。
テレビ番組で紹介されたときのアクセス増への対応が難しい。(宮下)
ホスティング(ロリポップ)は、一人ひとりのサイトの集合なので、何がおきるか予測できない。
1サイトへのトラフィックが増大した場合は、他サイトに影響が出ないように、高トラフィックサイトへのトラフィックを絞ったりして対応。
ミドルウェア・OSに影響する負荷をいかに減らすかを考える。(石原)
NHKオンデマンドはユニキャストなので高トラフィックには耐えられない。
P2PかCDNで検討しているという話もあるが、たぶんCDNになるであろう。
mixiでも10人くらいなのだから、うちなんかは1.5人くらいで問題はないのだろうなと思ってしまいますね。
mixiのような自社サービスであれば、チャレンジングなことをしやすいでしょうね。逆に楽天のような他社サービスの集合となっている場合には絶対にサービスを落とさない(落とせない)という考えになることは自然なのでしょうね。うちの場合もペパボさんのように、1サイトへの高トラフィックをいかに他サイトに影響させないかってことを考えています(なかなか起きないですけど)。
日ごろのシステムの動向(特性)を監視して、何がネックになりうるのかを予め予測しておいたり、予測に基づいて対策となる手法がすぐに実行できるようにしておくことが大切なんだろうなと思います。それがまだできていないので、これからは少しずつ考えていけるようにしたいです。
新規サービスなどへの対策はどのようにおこなっているか？
(長野)
トラフィック予測(広告) ←ここ、曖昧です。。。
モバイルは、ギガ単位でのトラフィックの伸びが発生することはあまりないので、PCほど対策をしていない。(和田)
負荷テスト。
予測PV数、キャパシティ要望から予算を出して、それに見合った対策を行う。
新規サービスは、本当に読めないですね。特にうちの場合は、負荷テストをまともにやっていないし、キャパシティ要望やSLAのような非機能要件がまともに出てくるわけでもないので、ものすごくなぁなぁです。そんなことじゃだめだと思いつつも、顧客側にそこまで予算があるわけではなかったりするので、難しいところです。ひとつだけ必ずアクセスが増大するイベントがあって、それだけはWEBサーバの負荷分散をして対策を打ってますね。
一流のrootと二流のrootの違い
(越川) 特に定まっていないルールの中でどうやるか。基本はトライ＆エラーの繰り返し。自己流(歩いた跡に道ができる)
(和田) 当たり前のことが身体に染み付いている人。 → あせってしまうような状況でも、しっかり確認作業などができること。
(宮下) 一流はrootにならない。 → 対象サーバにログインしなくて身対応できるように、自動化を極める。
私の意見は、和田さんの意見に近いかな。どんな状況でも冷静に判断し作業できる人というのが良いrootだと思います。そして、今後は宮下さんの言うように、できるだけ人の作業を減らす方向で、自動化できる部分は極力人に作業させないというのがいいのでしょうね。Puppetなんかは使うようにしたいんですけど、考えているだけでまだ何もできていません。
インフラの重要性を社内の人にわかってもらうには？
(越川) 何もしなくてもいいのがベストな状態なので、何もしていないように見せて、対外的な発信をしていくことで評価してもらうようにする。
(和田) インフラ勉強会(業務時間外)：新卒や技術者以外の人を対象に。インフラエンジニアから働きかけていくようにする。
勉強会は開催してみたいとは思うのですが、やるネタとか資料作りの時間を考えると億劫になってしまうんですよね、これがまた。対外的な発信の重要性も感じていますが、筆不精なところがあるので、なかなかできないですね。だからこそ、ここで書き始めたわけで。。
インフラエンジニアを実感した瞬間
(越川) 飼っている魚の稼働率を考えてしまう。
(宮下) 30DaysAlbumの社内プレゼン中からシステム構成を考えてしまった。(まだサービス化も決まっていない段階で)
(長野) 復旧した直後に一息ついたらまた落ちた、などの理不尽なことへの対応を「しょうがないな」と思いつつもやっているとき。
これはやっぱり、早朝に障害で叩き起こされたときと、サーバ構成の変更をするときに深夜作業をしているときかな。
お勧め運用ツールは？
(越川) Hobbit：Nagiosは設定が面倒。手軽に使える。
(和田) (楽天台湾では)ZABBIXとMonit
(長野) Nagios：テンプレート化とスクリプトで半自動化すれば初期コストは高いが便利。
自作：RRDToolを使った性能監視
(宮下) Puppet：OSインストールとネットワーク設定以外は一発設定。シェルスクリプトなどで自動化するより見通しが良い。設定ファイルはSubversionで管理して、Archer(CapistranoのPerl版)で連携する。30DaysAlbumのサーバ設定はこれで。
先ほども言ったとおり、Puppetは使いたいツールのひとつです。うちは監視ツールとしてMuninを使っています。グラフ表示と、閾値を超えた項目をメールで通知なんてこともできて、導入も簡単なので重宝しています。
気になるあのサービスについて
(宮下) 30 Days Albumについて説明
社内プレゼンからサービス化。
宮下さんが始めて1からかかわったペパボのサービス。
・バックにはPerlを大量に採用：perlbal(リバースプロキシ)を使った独自プラグインなど。
・フロントはRoRを採用
・ストレージはMogileFS
・画像のアーカイブやリサイズ：ギヤマン、シュワルツ(名前が不確か)
・ほとんどのサービスがPHPの中で、珍しいサービス。(社長がPHPエンジニアなのでそのながれがある)
・サービスイン時はtopとにらめっこをしていたｗ
・インタフェイスはなるべくシンプルにしようと心がけた
→ 自分たちの親でも使えるくらいシンプルに。画像の先読みでJSを利用。
(和田) WIRED社のShifterが気になる。
サービス自体よりも、その裏側のシステム構成のほうが気になりますねｗ
サービスから見たインフラエンジニアの立ち位置
(宮下) フロント側とのつなぎを如何にスムーズにするか。
(和田) 楽天はメールが多い → RSSにしたらどうかという意見もあるが、ユーザ層の広さからできない面もある。JSやFlashの多用もしないようにしている。
縁の下の力持ちって言葉が一番しっくりきます。でも、別の言い方をすれば、安心感の提供者なんじゃないかなと思います。
マイクロブログについて
(長野) mixiエコーについて
今までの経験を生かして、いろいろな対策を打ってサービスインをした。
→ メモリを潤沢につんでおくなど
Q4Mを採用
負荷対策などはしてあるが、1月1日0:00は、やはり心配。
マイクロブログは、クリティカルなサービスではないようで、落ちてしまうとものすごく不便だったりするよねって話だったと思います。私もTwitterを使っていますが、つぶやきたいのにアクセスできないときなんかはガックリしてしまいますね。でも、それで使うのをやめるということはないです。ちょっとしたつぶやき程度のトラフィックもチリが積もって山となるわけですよね。
仮想化やクラウドコンピューティングに対しての考えや準備していることは？(会場からの質問)
仮想化やクラウドでインフラエンジニアの働き方は変わるか？
(和田)
インフラエンジニアは減る → 運用が今よりも簡単になるから(宮下)
変わらない → 要素技術は変わらないから。
働く場所は変わるかもしれない → 自社からクラウド持っているところへ
プライバシーの問題などもあるので、すべてをクラウド上に持っていくことはない。
私は、仮想化は今後も使われていくが、クラウドは一時の流行なんじゃないかという見方です。宮下さんも言っていますが、データを持っておくべき場所としては不適な場合もあるわけで、機密データや個人情報を自分たちで完全に管理できない場所におくようなことはしたくないと思います。仮想化は、サーバの物理的な数を減らしたり、電源効率などを考えると有用な技術ですので、今後も進化し利用されていくでしょう。ただ、サービスの提供形態によっては仮想化の適用も難しいこともあると思います。
ワークスタイルの勘所 (インフラエンジニアの働き方とは？)
一言で表すと＋その説明
(宮下)
「楽」：いかにして手を抜くか。最初に苦労することで後が楽になる。ハードだからこそ楽しめることもある。(石原)
「ネットワークの酸素」：なくてはならないもの。濃度(品質)が大事。フロントとのコミュニケーションをしっかり。(長野)
「地図に残る仕事」：気づかれないけど、プライドを持ってやる。花形を支える裏方。(越川)
「オールラウンドプレイヤー」：知識を集約した場所。(和田)
「サービスの最前線」：開発エンジニア・デザイナなどと一緒にサービスを作っている仲間。つらいことに目が行きがちだが、そんなことばかりでもない。
「見えない架け橋」っていうのが私の考え。顧客・エンドユーザ・開発者のニーズを感じ取って、目には見えない形で提供していくことができる。でしゃばりもせず、表にも出ないがなくてはならないものを支えている。実践できているかどうかは別として、これを信念として仕事をしています。
その他、会場からの質問
- ネットワーク層以下の対応はどうしているのか？(キャパシティプランニングで事足りるのか？)
(長野) 大域の増減はルールに従っている → ○○%使用したら増強
(和田) 数値を決めて増強。日本-台湾間のパケロスは経路変更で対応した。
参加してみて
他の会社の仕事を見てみたいなと思いました。今の会社はいろいろとチャレンジをさせてはくれるけれど、いかんせん目指すべき人が社内にいないことがすごくつらいです。宮下さんのpaperboy&co.がサーバエンジニアを募集しているという言葉に、心が揺らいでしまいましたｗ
でも、自分に与えられた仕事は責任を持って遂行してからでないと、離れることはできないので、まだまだ先になりそうです。
