ずいぶん時間がたってしまいましたが『おぺかじ！』という勉強会に参加して来ました。
『おぺかじ（Operation Engineers' Casual Talks）』
そしてなんとトークセッションに登壇させてもらいました！
※@studio3104さん、お誘いありがとうございました！
DevOpsだとかクラウド、Chefなどの言葉やらツールやらが流行ってきて、
『インフラエンジニアもコード書けないと！』というテーマが立ち上がったっぽいです。
というわけでこれについて考えていることや、参加してみて思ったことを書きます。
インフラエンジニアがコードを書くこと
僕自身はコードを書く、書かないを特に意識したことはないです。
『必要があれば書く』だけで、そのほうが効率的だと思ったらそうします。
全メンバーがそうである必要はないと思いますが、チームに1人もそういう人がいないのは致命的に非効率的だと思います。
サービスのコードは基本的に見ないです。
使う言語は主にシェルスクリプトとPerlでした（Rubyに切り替え中）
ボンヤリ設計を考えて、配列、ハッシュなど複雑なデータ構造が出そうならPerlにします。
Perlが好きだったのはこういう理由です。
- どのサーバにも入っている
- バージョンが安定（たいてい5.8.8が入ってる）
- 簡単なことが簡単にできる（特にテキスト処理）
- サービスで使っている言語と別（前職はサービスはPHPでした）
なんだかんだ言って上2つが大きいですね。
一番下は『サービス用の言語はいじると怒られる』というネガティブな理由で別の言語をあえて選択していた、ということなのですが、
- 開発チームとライブラリ、知識の共有ができない
- rvm/rbenv、perlbrew/cpanmなど、用途ごとに簡単に実行バイナリを切り替えられるようになってきた
という理由から今後は避けようと思っています。
インフラエンジニアとして意識していること
インフラエンジニアとしての僕の仕事は、品質とコストのバランスを取りながらサービス（の基盤システム）を効率的に運用することです。
そこでよく思うのは自分の扱う規模/環境にあった運用を考えること、です。
例えばとある書籍なり勉強会なりでこういうことを聞いたとします！
素晴らしい！ぜひ導入しよう！と短絡的に考えてもしゃあないです。
これって要するにこういうことだったりするのです。
- 検証/導入2ヶ月、各メンバー（Ruby知識なし）の教育に2週間かけてChefを導入。サーバ構築時間を30分から10分に短縮
- PHPをC++に変換してコンパイルするシステムを導入し、APPサーバの負荷を20%削減。毎回のデプロイに30分かかる。
- 年俸1000万の優秀なエンジニアを半年使ってDBの負荷を30%下げるキャッシュシステムを開発
これは自分の会社の規模/環境でペイするのか？を考えないといけない。
（このくらいの条件なら、たぶんサーバ1000台規模じゃないとペイしないと判断する）
『技術の最先端を走る』という言葉はかっこいいです。『Cで書かれたミドルウェアのソースコードを読む』『日本語情報がないので英語のドキュメントを読む』とかも。
ただそこで最先端を走る必要のある規模、サービス特性なのかについては必ず考えます。
たいていは規模的に最先端を走る必要のある会社（DeNAやサイバーエージェントなど）で初期のバグをひと通り踏んでもらって、日本語情報とかもだいぶ出てきた頃（導入コストが下がって小中規模でもペイするようになったころ）に導入を考えます。
もちろんそういうのを否定してるわけじゃないし、『やりたいこと』は発案者/担当者にもよりますがコスト30-50%減とかで考えたりもします。モチベーションって大事なので。
あんまりなんでも鵜呑みにせずに、自分でウンウンうなって考えるのが大事だと思います、ということです。
コード書きたいけど書けないという意見について
アンケート見たらいろんな理由づけがありましたが、たぶん気のせいです。まずはやっちゃえばいいと思います。
自分がと社会人になってとあるSIerで初めて書いたコードは、『サーバ監視項目のリストをお客さん提出用のフォーマットに変更するExcelマクロ』でした。
最初はたぶん週末とか早朝とか、個人の時間を使うことになるでしょう。
会社は『だれかがプログラムの勉強しながら半月かけて10分/日の作業を自動化すること（ができるかも）』を承認できないからです。
ただそうやって週末潰して書いたプログラムを『お昼休みに作っちゃいました』『昔作ったのがありました』とか言って出してると、しばらくするとそれが言葉通りになります。
自分は『勉強なんて一人でできる』『できることが仕事になる』、と思ってるので環境云々はあんまり関係ないと思ってます。
まとめ、じゃなくてクラウドの話
スピリチュアルなお題なのでまとめられませんｗ
ただ最近クラウド（AWS）のコストについてよく考えているのですが、
実際にある程度の規模で運用してる人たちの話を聞くと、『物理サーバよりちょっと高いくらい』という意見が多いです。
このへんがポイントになりそうです。
リザーブドインスタンスは『3年予約すると3年使わないといけない』というイメージをもっちゃいますが、実際は初期コストが発生するだけでその後は従量課金で『3年予約して半年使えば既にオンデマンドよりお得』とかになったりするらしいです。
US-EASTのm1.largeを半年使う例だと
- オンデマンドで半年利用：$1,123(0.26*24*30*6)
- 3年軽度予約で半年利用：$960(425 + 0.124*24*30*6）
詳しくはここの『オンデマンドとの比較による、RI 3年間の節減率』を。
動的な台数変更はCookpadのように
という運用特性がある場合は大きなコスト削減につながるでしょう。
しかもけっこう大きいと思うのが、『AWSはなんもしなくても勝手に値段が下がる』ことです。
HWの値段が下がれば物理サーバの値段も下がるじゃないかと言われますがなかなかそう簡単でもない。
- けっこうな割合を占めるDCコストが下がらない
- HWの性能が上がっても台数を削減できるサーバは一部だけ（スケールアウトが簡単なAPP、DBスレーブくらい）＆載せ替え作業が必要
というわけでやっぱり今後もクラウド利用は拡大していって、
そうなるとRailsのようなフレームワークにAWSのSDKとChefのレシピが組み込まれて、
・エイヤッとデプロイすれば必要なサーバが勝手に作成される
・さらに負荷状況を見て自動でサーバのスペックや台数が調整される
とかって状況はすぐ来るんじゃないかなと思うわけです。
その時、自分の仕事なくなるじゃん！と不安になる人は、いろいろ考えたほうがいいかもです。
※さすがにまとまりが無すぎ！！！また気が向いたら見直すかも(´・ω・｀)
