読者です 読者をやめる 読者になる 読者になる

Cookpadに入社しました

f:id:mikeda:20150216095639j:plain

2/9に入社を決めて、「じゃあ来週から行きますね」「はい、じゃあそれで」みたいな感じで今日から出社してます。
来週には社員旅行あるらしく、ハミりそうですごく心配です。

Cookpadではインフラストラクチャ部に所属します。
上司はmirakuiさんです。今日はラーメン作ってもらいました。

f:id:mikeda:20150216123048j:plain

細かいことは決まってないですが、AWSメインのインフラとかを見てくことになります。

自分は今まではオンプレがメインの人で、ファシリティやNW、資産管理とか、ラッキングやケーブリングとかも、得意だしけっこう好きでした。
そのへんは個人じゃさわれないので参入障壁が高くて需要もあるんだけど、
どうしても大規模向けスキルになってきて、自分はあんま大規模志向とかスペシャリスト志向が無いので、今後考えるとどうだろうなぁ、と思ってました。
ここで強制的にそれが無い環境にして、そのぶん開発基盤の仕組み作りやマネジメントみたいなのをやってくかなーとか考えてます。

ちなみに料理はぜんぜんできません。
大学生になって一人暮らしを始めた当初は自炊してたんですが、
みるみる痩せて体重が47kgになって、
貧血で2回倒れて(授業中と雀荘と)、
ということがあり、自分はむいてないんやな・・・と泣く泣く料理を断ちました。

あれからもう15年。
これを機にもう1回挑戦してみるか!!
というわけでwishlist作ったのでよろしくお願いします!

料理するぞ!

wishlist公開するの初めてなんだけど、これでいいのかな?

負荷低すぎはもはや障害じゃないのか

前のブログの続きで、もにかじ7で話した小ネタその2。

実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます?って話です。

まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。
※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。

でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。

そうすると、
『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』
みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか?
みんななんかやってますか?

というようなことを参加者に聞いてみました。

参加者の中では、AutoScalingしているところは当然対応できているけど、それ以外については特に監視してないな、という感じでした。

AutoScalingは確実に最終的な解の1つなんですが、現状なかなか全てをそうするのは難しい。
現状のままサクッと監視できないかなぁ。

というわけで

例えばこういうコマンドを作って定期的に監視するのは1つの手かな、と思います。

f:id:mikeda:20150201191036p:plain

中ではこういうことやってます。

  • AWS SDKで稼働中EC2インスタンスのIPアドレス、インスタンスサイズを取得する
  • 各インスタンスにSSHして昨日のCPU使用率、メモリ使用量の最大値を取得する
  • 各インスタンスの既存負荷に耐えうる最適な(最も安い)インスタンスサイズを求める
  • 合計の既存コスト、最適コストの差が30%以上になったら警告する

デモ用のネタ実装なので、EC2のみ対応でReservedやSpotは無視とか実用性は全くないです。

監視ツールと連携して、もっと簡単にやる方法はないかな。
Zabbixとかならサクッとできそうだけど。

ちなみに

AWS Trusted Advisorにそういう機能があるらしいんだけど、

毎日の CPU 使用率が 10 %以下およびネットワーク I/O が 4 日以上 5 MB 以下となる場合、最後の 14 日間、常に稼働している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを確認し、お客様へ警告します。

とのこと。イマイチすなぁ。

まとめ

クラウド化でスペックダウンが容易になり、効果も大きくなったので、
『負荷高すぎ』だけじゃなく『負荷低すぎ』も障害として監視すべきじゃないのかな。

でもどうやって監視するか迷い中。って話でした!

もにかじ7 & nagiosとmuninをChrome拡張で合体させる

昨日、Monitoring Casual Talks #7に参加してきました。

f:id:mikeda:20150130223410j:plain

もにかじは2年ぶりに参加したのでまず感想

2年前はサーバ監視はだいたいZabbixかnagios+muninのどっちかだったけど、今回はDataDog、Mackerel、PagerDutyみたいな外部サービス使ってますって事例が多かった。

そしてPacker+AutoScaling、Docker、ConsolやSensuみたいなものを使って、動的に変化するインフラをどう管理していくかという議論が多かった。

この辺りはみんな絶賛試行錯誤中でぜんぜん話まとまらないんだけど、いろんな技術や考え方がバンバン出てカオスってて面白い。
長いことぜんぜん追えてなかったので、いろいろ話が聞けて良かった。

そして若い人が増えたなー。平均年齢すんごい下がってる。クラウド化と並行してこの傾向も進んでいきそう。

自分はというと、こういうことをバラバラと話したんだけど、

  • ここ2年ぐらい監視周りでやったこと
  • ちょっと考えてみた小ネタをいくつか

資料は公開出来るように調整するのが面倒そうなので、いくつかのトピックをピックアップして個別にブログに書いていきます。

で、今日は『nagiosとmuninをChrome拡張で合体させる』という小ネタ

このChrome拡張をインストールしてNagiosにアクセスすると、

ホストのリストにmuninへのリンクがついて、

f:id:mikeda:20150131180749p:plain

そのまま対象ホストのmuninのグラフが見れる。

f:id:mikeda:20150131180747p:plain

そしてホストのアラート詳細画面にはCPU使用率、メモリ使用率とかのグラフ画像がくっつく。

f:id:mikeda:20150131180748p:plain

長いことNagiosもmuninも使ってないし、作りもネタレベルなのでWEBストアで公開はしませんが、コードはgithubにアップしておきます。

https://github.com/mikeda/munios

nagios、muninの設定に応じてmanifest.jsonのmatchesを調整して、Developerモードでファイルで読み込めば使えます。

muninのURLにホストグループ名が入っててそれをNagios側でどう付与するかについて、
『muninのトップにアクセスした時に各サーバのグループを取得して保存しておく』
というかなりムリヤリで気持ち悪いことをやっています。

まとめ

久しぶりに『もにかじ』に参加して面白かった!
参加者9人で3時間以上かかったw

インフラコストを削減する その1

過去2回ほど、20%~30%程度のサーバ削減をやったことがあって、
その時のメモが出てきたので、考え方とかやったことをザックリまとめてみる。

まず例えば、不要なサーバを削減してインフラコストを月額10万円減らしたらどうなるか。
これは運用コストも解約リスクも無い、恒久的な利益になる。
裏返すと以前は恒久的な損失が発生していたということなんだけど、情報をまとめないとだれも気づかない。

なのでどこまでやるかは状況次第だけど、情報をまとめることは最低限必須だと思う。

ということで、『効率化する』、『安く買う』についてはまた次回にして、
今回は『情報をまとめる』、『ポリシーを決める』、『適切なサーバ台数を維持する』ことについて。

基本的にオンプレ環境を前提として考えます。

情報をまとめる

まずは最初に言ったように、必要な情報をまとめる。

そしてだれでも見れるようにする。
これをしないと自分が思いつく範囲の最適化しか実行されないから非効率。

サーバの一覧を作る

ないなら作る。

ここで大事なのは各サーバの用途をちゃんと確認すること。
これだけでけっこうな台数のサーバを減らせることもある。
もうサービスアウトしてたとか、使う予定だったけど結局使ってないとか、けっこうある・・・

コストを見える化する

月額のファシリティ費用とその内訳、HWの購入費用等をだれにでも見えるようにする。

合わせてサーバあたりの概算月額コストも感覚的に覚えてもらう。
例えばこういう条件であれば、約2万円/月とか。

  • 1ラックが20万円/月で、平均20台のサーバを搭載:20/20 = 1
  • エッジスイッチが18万円×2で、使用期間は5年とする:18 * 2/(12 * 5 * 20) = 0.03
  • サーバ1台の平均購入価格は36万円で、使用期間は3年とする:36/(12 * 3) = 1

状況に応じてその他の費用を含めてカスタマイズする。
使用期間は経理上の償却期間とは別に、実運用実績に近い値を設定する。

リソース使用率を見える化する

最低限、Zabbix、munin、mackerel等の一般的なグラフツールが導入されていれば良し。

プログラマブルに数値のリストが取得できればさらにいい。
こんなことしてたころも。
サーバのリソース使用状況レポートを作る

ポリシーを決める

検討に必要なポリシーを決めて、それを要件に落としこんでいく。

例としてCPUバウンドなAPPサーバの台数とピーク負荷がこうなっているとして、台数の妥当性を検討してみる。

f:id:mikeda:20150116133130p:plain

  • サーバのCPUコア数は4(1コア使い切ると100%として最大400%)
  • 各サービスA、B、CのAPPサーバの台数と過去1年の最大CPU負荷
    • サービスA : 5台 合計650%(1台あたり130%)
    • サービスB : 4台 合計400%(1台あたり100%)
    • サービスC : 2台 合計100%(1台あたり50%)

障害点分割

サービス間でどのコンポーネントは共有し、どのコンポーネントは分離するかを決める。

出来る限り複数サービスで共有化したほうがリソース使用率が高くなる。
ただそうすると障害点まで共有化されて信頼性が低くなるので、バランスを取りつつポリシーを決める。

例)

こんな感じで決める。

  • NW回線、コアNW機器(L3SW、FW、LB) : 全サービスで共有
  • ラック、エッジSW : 事業部単位で分割
  • サーバ : サービス単位で分割。ただし売上がXX以下の場合は3サービスまで共有
  • ...

その結果、サービスA、B、Cのサーバをこうまとめることになったとする。

  • サービスA : 専用
  • サービスB,C : 共有

冗長度

各コンポーネントの冗長度を決める。

もちろん冗長度が上がると信頼性は上がるがコストも上がる。

例)

例えばこんな感じに決めたとする。

  • 回線/NW:Active/Standby構成で2重化
  • サーバ:サービス系はN+1構成、非サービス系は冗長化無し(ただしバックアップから3時間以内に復旧可能)
  • 電源:冗長化しない
  • HDD:全てRAID10で冗長化
  • 予備サーバ:...
  • ...

サービスA、B、Cは全てサービス系なのでAPPサーバはN+1構成にする。

単体のリソース使用率上限

ラック電力、NW帯域、サーバCPU等、コンポーネント単体の各種リソースの使用上限値を決める。

例)

CPU使用率は70%を上限とする。
※CPU上限はHT(Hyper-Threading)を使う場合は特に、慎重に決める。実際のサービスで特定サーバの振分けを徐々に増やして検証する、ということができればそれが一番確実。

APPサーバ1台あたりのCPU使用率上限は400 * 0.7 = 280%、となる。

サービスごとの最大の合計リソース使用量

各サービスのある機能に、最大どの程度のリソースが必要かを決める。

例)

過去1年の最大負荷に20%のバッファをのせたものを最大合計リソース使用量と決める。

各サービスのAPPサーバのクラスタで必要な合計CPU使用率はこうなる。

  • サービスA : 合計780% (650 * 1.2)
  • サービスB : 合計480% (400 * 1.2)
  • サービスC : 合計120% (100 * 1.2)

適切な台数に調整し、維持する

ここまで決定すると、

必要なサーバ台数が決まる

今回のAPPサーバの例だと、負荷的に必要な台数はこうなって、

  • サービスA : 3台 (780 / 280 = 2.78)
  • サービスB,C : 3台 (480*120 / 280 = 2.14)

N+1台構成にするとこうなる。

  • サービスA : 4台
  • サービスB,C : 4台

適切な台数になるように調整作業をする

やっと作業だ!!!

f:id:mikeda:20150116133131p:plain

今回の例だと台数が減ったけど、冗長度が足りてなかった場合は増えることもある。

まぁたいてい減るかな。
負荷が上がるとアラートなるけど、負荷が減った時は何も起こらなくて対応が放置されがちだから。

繰り返す

PV増減、アプリ変更、最適化作業やサーバリプレース等によって負荷が変動したら、
また調査、調整して、台数を適切な状態に保つ。

ポリシーも適宜見直していく。

まとめ

というわけでインフラのコストを削減する、ということに関して、まずはその前提となる、

  • 情報をまとめる
  • ポリシーを決める
  • 適切なサーバ台数を維持する

についてでした。

『効率化する』、『安く買う』についても近いうちに書く・・・きっと・・・

サーバの電源って冗長化してますか?

実は自分はあんましてないです。

理由について書くと。。。

例えばこんなラック、サーバが前提で、

  • 電源コンセントは2系統で、それぞれ25A(100V, 2.5kva)でブレーカ落ちる
  • サーバは平均2A(100V, 0.2kva)の電力を消費する

片系20Aで合計40Aまで使うとして、サーバは20台突っ込みたい、と思ったとする。

最初はこうしてたんですが、

f:id:mikeda:20150115155747p:plain

これだと片系電源に障害があった時とか、ミスってブレーカ落とした時、
もう片系に40Aの全電力がかかって共倒れして、全サーバが停止してしまう。

でもサーバ搭載数を半分にするのはお金的にムリ過ぎる。

※DCと調整して片系50kvaまで使える2系統にしてもらって、実効電力ベースの契約にするとか、いろいろ手はありそうだけど。

というわけで、

こっちのほうがまだマシか、と次はこうしました。

f:id:mikeda:20150115155748p:plain

これだと片系落ちても半分のサーバは生き残るので、サービスは維持できるかもしれない。

まぁただ、ハッキリ言ってそんなうまいことはいかないですよね。
全てがそんなキレイに冗長化できないし、冗長化台数がN+1じゃなく2Nになってしまうし。
なのでこれだと厳密にはサーバの電源ユニット冗長化にしかなってないわけです。

そこまでして電源ユニットを冗長化する必要があるか・・・?
単一サーバ障害であればちゃんと冗長化してるから大丈夫だし・・・
電源ユニットを冗長化するにはR410じゃなくちょっとお高いR610を買わないといけないし・・・
※追記:勘違いでした。R3x0もR4x0も電源冗長組めます!

と考えて、

けっきょく電源ユニットも冗長化しなくなってしまった。

f:id:mikeda:20150115155749p:plain

あんま電力食わないNW機器は両系統に繋いで冗長化してますが。

みんなどうやってるんですかね。

友達の会社めぐり 目黒(リブセンス)編

友達の会社めぐり 六本木ヒルズ編に続き、目黒編!!!

と言っても今回はリブセンスだけですw

リブセンス

目黒駅からすぐ近く、1Fはスターバックスな大人な感じのオシャレビル。
テナントとしてスターバックス ジャパンのオフィスも入ってるそうです。

社員数を聞いてみると『正社員が100人、アルバイト・派遣社員が150人くらいかな』とのこと。
思ってたより多いですね!ここ以外にもいくつか拠点があるらしいです。

まずはエントランスと来客用MTGスペース。

f:id:mikeda:20150113135143j:plain

f:id:mikeda:20150113135332j:plain

WEB系(特にソシャゲ系?)によくある悪ノリ感のない、白と青がメインのキレイ系オシャレオフィス。

女子率も高く、心がとても落ち着きます。

f:id:mikeda:20150113135746j:plain

リラックマと女子エンジニア。癒やされるよ(*´Д`)ハァハァ

お水ももらいました。

f:id:mikeda:20150113150655j:plain

今までCA、Cookpad、GREE、Yahoo等、いろんな会社の水をもらってきたけど、
圧倒的にオシャレ!そしてかさばる!!!

社内はエンジニア比率がとても高いらしく、勉強会なども頻繁に開催されているらしい。
社内で「勉強会文化」を根付かせるには?

だれでも自由に貼れるという社内掲示板には、いろんな勉強会企画が貼りだされてます。

f:id:mikeda:20150113140243j:plain

面白そうなので、社外の人もOKというLT大会に参加を申し込んでみました。
LT大会「TechNight」、1/28(水) 19:30〜開催します。

そして、エンジニアの汚い机をネタで晒してやろうと思ったら、

f:id:mikeda:20150113140617j:plain

@さんの机がキレイすぎてフイタwww

まとめ

というわけで、リブセンスに初訪問してみました!

他にもいろいろ面白いところがあるので、詳しくは『株式会社リブセンス に行ってきた! - 941::blog』を見て下さい!!!

@さん、福田さん、いろいろありがとうございました。

@さんのホントの年齢とか創業時の話とか、いろいろ興味深い話も聞けてよかったです!

WEB系各社の技術ブログのはてブ数を調べてみた

『フォロワーのブログのはてブ数を調べてみた』が好評だったので、
同じやりかたでWEB系各社の技術ブログのはてブ数を調べてみた。

  1. 92802 クラスメソッド Developers.IO
  2. 38505 アシアル アシアルブログ
  3. 30311 ヤフー Yahoo! JAPAN Tech Blog
  4. 25295 ミクシィ mixi Engineers' Blog
  5. 22347 カヤック tech.kayac.com
  6. 22186 グリー GREE Engineers' Blog
  7. 19949 クックパッド クックパッド開発者ブログ
  8. 19352 KLab DSAS開発者の部屋
  9. 17747 paiza paiza開発日誌
  10. 15623 nanapi nanapi TechBlog
  11. 12130 はてな Hatena Developer Blog
  12. 10776 インフィニットループ インフィニットループ技術ブログ
  13. 10496 Livedoor livedoor Techブログ
  14. 9815 サイバーエージェント サイバーエージェント 公式エンジニアブログ
  15. 8967 さくらインターネット さくらのナレッジ
  16. 7712 ハートビーツ インフラエンジニアway
  17. 5609 DMM ツチノコブログ
  18. 5381 アイレット cloudpackブログ
  19. 5363 サイボウズ Cybozu Inside Out
  20. 5028 サーバーワークス サーバーワークス エンジニアブログ
  21. 4737 LINE LINE Engineers' Blog
  22. 3656 VOYAGE GROUP VOYAGE GROUP エンジニアブログ
  23. 3271 DeNA Technology of DeNA
  24. 2726 Qiita Qiita Blog
  25. 2383 pixiv pixiv engineering blog
  26. 2039 VASILY DEVELOPERS BLOG
  27. 1766 GMOメディア GMOメディア エンジニアブログ
  28. 1706 ドワンゴ dwango エンジニア ブロマガ
  29. 1682 シナジーマーケティング TECHSCORE BLOG
  30. 1540 ヌーラボ ヌーラボブログ
  31. 1205 Wantedly Wantedly Engineer Blog
  32. 1050 ネクスト 株式会社ネクスト エンジニアBlog
  33. 883 gumi gumi Engineer’s Blog
  34. 703 Treasure Data トレジャーデータ(Treasure Data)公式ブログ
  35. 603 NaviPlus NaviPlus Engineers' Blog
  36. 457 セプテーニ Septeni Engineers' Blog
  37. 291 Itandi ITANDI技術ブログ
  38. 281 MUGENUP MUGENUP技術ブログ
  39. 67 ユーザベース UZABASE開発者ブログ
  40. 38 CROOZ CROOZ公式エンジニアブログ
  41. 18 gloops gloops Blog

クラスメソッドさんハンパない!

大きな会社は力いれてるところ多いけど、やっぱまちまちすなぁ。

参考