2014年10月7日火曜日

私達がISUCON4の予選で失格した"たった1つ"の理由

ISUCON4にチームhogehogeとして予選1日目に参加してきました!

で、前置きはどうでも良いから何やったのか教えろという早漏君は、
ここまで飛んでしまえばいいさ!

失格した理由だけが知りたいというくれくれ君は、
ここまで飛んでしまえばいいさ!

さて。これ、本選の予習をする予定だった時間を使って書いてみたら、
凄い長文になってしまって、削除しようと思ったけど溢れ出す煮汁の如く
言葉が出てきたので、これは言霊に失礼だという事で削除しませんでした。
きっと読むの5分位かかりますよ。・・・きっと。

チームhogehogeは全員違う会社に所属していて、仕事の案件で知り合ったり
して参加した何ともTHE社会人みたいなチームです。
hoge1とK氏と私の3人で参加しました。

既にblogで皆さんが報告されているのを見る限り、

(´-`).。oO(みんなレベルたけぇ・・・)

って感じで、我々がやった事って全然先を行くかっちょえー感じでもなく、
ふーん、そうなのー的なレベルだし、それなら業務でやってるよね?的なので、
全然もう読む価値すらないかもしれませんが、
まぁ、暇だし付き合ってやってもいいよ?的な方がいらっしゃるんじゃないか!?
と、勝手に思ったので、もうそれならと読み物として充実させてやろうと、
文系エンジニアの実力をみせてやるぜ!的なノリで書きはじめていたら、
いやに長文になって、これ暇人じゃないと読めない。って感じなので、
ビスコでも食しながらレッドブル片手に現実逃避の御伴に読んでくれたらいいと思います。

で、結果は予選失格!な訳なのですが、まぁそれについても色々なドラマがあり、
ドラスティックな変化を執行していた訳ではないんですが、それはそれで
小規模な変化を色々と行った訳で、じゃー、なんなのさ。って言われると、
もう何なのかよく解らないんですが、強いて言えば、「楽しかった」って感じ。

本選に出れなかったんですが、本選の日の予定は勿論空けていたので、
「ヒカリエを見上げながら敗者の反省会という名の飲み会」
でも開いて惨めさを染み込ませて、
次回は絶対に本選に行ってやるという気持ちを高めようかと思います。
是非一緒に惨めさを染み込ませたいという方がいらっしゃれば
@taka3110_pcc までご連絡ください。

前置きはこの辺にして、
我々が選択した言語はみんな大好きPHPです。
perlかphpの2択でしたが、業務で慣れてるphpを選択しました。

で、色々チューニングした結果、
最高で38000、最終的な提出スコアは36500程度
でした。

予選1日目は、いろいろあれな事が発生したので、修正込で自己計測だと38000位でした。
惨敗かと思ってたら、意外にギリギリのスコアだったようで。まぁ、失格な訳ですが。



では、当日のドラマをどうぞ。



自社の会議室を借りれるという事で、皆さんにお越し頂きました。
会議室にhoge1、K氏と私の3人がお酒以外で初めて集まりました。

まずやった事。

・100万円の使い道を決める。
まず、これが大事。これを決めないとやる気が起きないという事で、
とりあえず、30万を分割し、残りの10万で祝勝会という王道パターンに決定。
決まった後は、やるぞやるぞコールです。

・コミュニケーションツールを決める
みんなアカウントを持っているという事でChatworkに即決定です。
といっても、今回は口頭と白板やモニタでのコミュニケーションが主だったので、
使用用途としては画像やURLのシェアと「コピペして欲しいコマンドを貼る」程度でした。

・コードやコンフィグの管理方針を決める
gitとかやるよりこの規模ならrsyncすればよくね?という発想で全員一致。
マスターのインスタンスと各人のインスタンスを作り、声を掛けながらマージしていくやり方に。

役割分担としては、
K氏      コード全般解析やチューニング
hoge1   インフラ回りのチューニング
自分     お茶くみ
という感じです。

お茶くみとして先ずやった仕事としては、
・お茶を配る
・お菓子を配る
・モニタや白板等、会議室の準備をする
って感じです。

一応、一番年上なんですけどねっ!
始まる前からもうあれです。あ、このメンツなら俺、戦力外やなと。
もう、K氏もhoge1も各社の中核を担う素晴らしいエンジニア達なんで!
とりあえず、会議室の設営やモニタの準備等をやらせて頂きました!
ひゃっふぅぅぅぅぅ!これで100万もらえるなんてすばらしいイベントやっ!
もう住宅ローンに回して家族からも「パパ素敵!」的な感じの祝福があるだろう!
って思ってて、この時までは勝つ自信がありました。

10:15くらいになったところでスタート。
ベンチを走らせたところ3位になりました。
ここからゴリゴリとK氏がコード全般の解析を始めます。

hoge1もゴリゴリとインフラを触り始めており、私は遠い目をしてました。
追い付くべくphp変更にあたってrubyのプロセスが落ちない等の紆余曲折を経て、
なんとかphpに変更完了。

と、この調子だとちょっとした小説になりそうなので、ダイジェストでどうぞ。


※赤字は目に見えて効果があったものです。

方針としては、大きな変更は1チャンスというイメージ。
CPUが全く使えていないのでCPUを効率的に使う為の設定、
並列処理を上げるチューニングへと大枠の方針決定。
また、memoryが大量に余っているので、I/Owaitを無くして
より効率よく処理させる方針に。

構成はphpの最初に入っていた構成のままです。
nginx --> php-fpm(2インスタンス) --> mysql

簡単に効果があった順に書くと
・MySQLのindex変更
・カーネルチューニング
・オンメモリ化(セッション含む)
・不要モジュールの削除
というような感じでしょうか。
MySQLのindexを変更する事によって効率よくCPUを消費出来るようになり、
phpやベンチに回せるようになって処理速度が向上。
カーネルが追いつかなくなった為にカーネルのチューニングを実施。
残っているI/Oを全てメモリに行くようにして、phpの重い処理を削除。
・・・振り返ると普段どおりの事をやった感じです。

本来はここから色々変更するという形になっていくと思うのですが、
そこまでは今回は手が回りませんでした。

という訳で、足取りを詳細に書いてみました。


Start~15:00


[自分がやった事]
・インフラのボトルネック調査
 dstatをインストールしてdstat / vmstat / topでボトルネックを確認しました。
 と言っても、MySQLが使うCPUが目立ちすぎていたので直ぐに解りましたが。。

・オンメモリ化(結果的に採用)
 一番最初にこれに取り組んだが殆ど変わらなかった為、一旦不採用にしました。
 ⇒最後に劇的な変化がありました。

・mysqlの設定チューニング(採用)
 mysqlの設定は各種bufferサイズを上げたのと、
 tmp/cache系の設定をmysql_tunerの情報を参考に入れました。
 あとはinnodbのコンカレンシーをセット。

・phpの再インストール(不採用)
 ちょっとスコアが上がったが、余り意味が無くバグが増えるのもあれなので見送り。
  ※configureオプションを見直してしっかりかえてれば・・・と後悔。

・index等を静的化(不採用)
 login等の処理でエラー多発。DOM構造を変えちゃうかも?という事で見送り。

・MySQLのアップデート(不採用)
 5.6に変更しましたがtimedateの問題でクエリを修正した結果、逆に遅くなりました。


[チームメンバーがやってたっぽい事]
・ソースコードから仕様の把握
 処理遷移を全員でシェア

・ボトルネックの洗い出し
 SQLがポイントという話に。indexの見直しを開始。

・MySQL index 作成(採用)
 indexを貼り換えたり適切なものにしていく事で劇的に変化。


[この時の感覚]
 15時の段階でindexの効果が目に見えて確認出来ており、
 徐々にスコアアップし、10000超え。
 しかし、周りのスコアがもの凄いアップしてました。
 一気に上がってるチームも居たので、恐らくコードとか全部変えてるんだろうと。
 (この予測はのちのブログを見る限り、合っていたようです)
 とりあえず、出来るところまでやろうと励まし合いながら進めました。



~17:00

[自分がやった事]
・APCuのインストール(不採用)
 ソースコンパイルでインストール。不採用理由は後述。

・nginxでcache(不採用)
 適当なキャッシュ設定だったので逆に下がった。
 ※こちらもしっかりと設定出来てれば、2000位のアップが見込めたので後悔。

・niceの調整(不採用)
 mysql、ベンチマーク、nginx、php-fpmそれぞれのパターンを試したがイマイチ。


[チームメンバーがやってたっぽい事]
・カーネルチューニング(採用)
 tcp session timeout設定、port range 拡張、ulimit -n 設定などなど、
 tcp周りとファイルディスクリプタ不足のエラー解消

・php-fpm 多重起動(採用)
 より並列処理させる為に、ポートを変更してもう1つphp-fpmを起動

・php date 変更(採用)
 phpのdateを設定

・APCの代わりに/dev/shmにファイルおいてみた(不採用)
 デフォルト状態の時間と変わらず

・APCで検索結果キャッシュ(不採用)
 SQL実行が高速化したためオーバヘッドが多く意味なし

・検索結果をRadisにキャッシュを検討(不採用)
 DBからの整合性がとれない+時間が無い為断念
 ※ここに早めに着手する決断が出来ていればと後悔。

[この時の感覚]
 この段階で既に詰めにかからなければいけなかったのですが、
 試していた事に対するバグ取りが結構時間が掛かるという事で、
 デフォルトのミドル構成で勝負する事を決定。
 カーネルチューニングで徐々にスコアは上がりますが、
 周りのチームのようにスコアがなかなか上がらず、半ばあきらめムードに。


~17:50

[自分がやった事]
・xdebug削除(採用)
 不要なモジュールの削除という事でxdebugを削除。

・カーネルチューニングにプラス(採用)
 net.ipv4.tcp_syncookies = 0を追加

・nginxとphp-fpmの通信をunix socketに変更(不採用)
 ファイルディスクリプタが追いつかない状態になり断念。
 ※ここをクリアしていれば結構増えたかもと少し手を付けるのが遅れたのを後悔



[チームメンバーがやってたっぽい事]
・nginx backend との keepalived 60(採用)
 nginxとphp-fpmのkeepaliveを設定して接続コストを少しでも減らそうと。

・log出力停止(採用)
 全プロセスのログ出力を停止してI/Oを極限まで削減

・セッション、MySQLデータのオンメモリ化(採用)
 /tmpに吐かれていたセッションファイルとMySQLのデータを/dev/shmに変更
 Diskへのアクセスをほぼ無くし、I/Owaitを0に。


[この時の感覚]
 残り45分くらいにしてセッションのオンメモリ化とxdebugの削除で、
 何とか37000台まで上がる事が出来て最後まで戦える状態に。
 ただ、なかなかその他の施策が上手くいかず、決め手に欠けており、
 焦りばかりが進むような状態でした。


~18:00


35000~38000で結構振り幅があった為、願いを込めながらベンチマーク連投。
結果的に値が下がってフィニッシュ orz


今回のチューニングを通して気付いたのが、
・チューニング仕きってから始めてI/O勝負になる。
・MySQLがCPUゴリゴリ使ってる場合は、indexの貼り方等、クエリ確認を優先

という感じでしょうか。
真っ先にI/Oとか色々弄ってたんですが、indexとかそっちをチューニングした
後じゃないと、効果が見えてきませんでした。
インフラ回りをガッツリいじる前にやる事あるんじゃないの?というのが教訓。


で、1日目だけにあった終了後のイベントに突入
~18:30
終わってからworkloadに盛り上がっているのに気付き、自分達も試したところ、

いやああああああああああああああっていう数字が。

workloadを600にしたところ、failも少なく234173
9分程度っで完了しました。

この瞬間、完全に敗北を覚悟。
「もう、酒飲もう! もうね。。飲もう!」
って事で、このまま新宿めだかに場所を移して反省会に突入。

本来であれば、workloadの恩恵を真っ先に受けるべき戦略だったのに、
このバグに気付かなかったのは我々の完全なミスでした。
1分で終わるだろうという勝手な憶測によりworkloadを10~30位で確認してました。
12が丁度良かったので、これをセットして報告をしましたが、並列処理を考えて
チューニングしたので、100とか桁を変えて確認しても良かった筈。完全な思い込みです。


負け・・・。負け・・・。圧倒的・・・負け!!!!


というカイジのナレーションが私の頭をよぎっていました。

ただ、これだといかに負荷を掛けるかという、負荷コンテストになるのでは?
これ、ISUCONじゃなくてIFUCONやんけ。」という話が出た位のタイミングで、
チャットルームを覗いていたところ、運営様よりお知らせが。

ベンチマークソフトをアップデートしてバグを改修したうえで、
再計測をし更に3枠追加します!との事。

いやー、これ当日も良いジャッジだと思いましたが、
後日確認してみて改めて物凄いジャッジだと思いました。
順位を推測しながら皆さんのブログを確認していたら、
プラス3組ってものすごい絶妙な数字で、
workloadで勝ち上がった人達の分追加されているイメージなのかなと。
それを当日、あのタイミングでジャッジしたのは運営さん凄いなと。

題材も、これ弄るとこそんな無いのでは?という感じでしたが、
弄ってみると以外にも伸びしろがあるという面白い内容でした。
何よりphpでも結構戦えるね~というのが解って嬉しかったです。
今回は失格という残念な結果に終わりましたが、
次回必ずや本選に行けるように日々精進したいと思います!



あ!大事な事、忘れてましたね。
失格になった1つの理由ですが、恐らくお気付きの方もいらっしゃると思います。
~17:50にあったパートですね。

・セッション、MySQLデータのオンメモリ化 です。

我々はベンチマークを実施する前提でプロセスを立ち上げるのは問題無い
という確認をしていたので、ベンチマークソフトのinitに仕組みを仕込みました

簡単に言うと、ベンチのinitでrsyncをして/dev/shmに移すという作戦でした。
再起動テストも実施して、完璧と考える状態で提出しました。

しかしながら、レギュレーションには以下が記載されていました。
"ベンチマーク実行時にアプリケーションに書き込まれたデータは、再起動後にも取得できること。"

もうお気付きですね。

これだと、実施後の再起動でデータの整合性が取れないんです
私たちが失格した"たった1つ"の理由。それは・・・


「レギュレーションをちゃんと理解していなかったこと。」


次回は先ず読み合わせからやります!
っていうか、俺、遠い目をしながら最初にレギュレーション読んでた!
だまっててごめん!っていうか、スルーしてて、ほんとごめんなさい!!!


俺等は技術で負けたんじゃない!国語で負けたんだ!


という名言を文系エンジニアが吐いたところでドラマをクローズしようかと。


ちゃんちゃん。

2014年3月29日土曜日

外れないワインを選ぶ3つのポイント

今日は家族が居ないのでワインを飲みながら検証していたら、
makeしている間のネットサーフィンしてたんですけど、美味しいワインの選び方ってページが結構あったんですね。
気持ちよくなってきたので、ちょっと趣旨を変えて外れないワインの選び方でも書こうと思います。
まず第一に、美味しいワインの選び方なんてないと思ってます。
不味いとか美味しいというのは趣味だし、その人が感じる想いですよね。
たとえば、今私が飲んでいるワインをみんな美味しいっていうかというと、
まず大半の人はもっと美味しいのがあると言うと思います。
じゃ、美味しいワインの選び方ってなんじゃい?っていう話になるんですが、
結論、ないんです。 ただ、自分が好きだと思う味ばかりを選んで、
ワインの外れを極力無くすことは出来ます。
私は味とか美味しさとか、全然解らないんですよ。もうセンスの欠片もないw
という訳で、「外れないワインの選び方」です。
実際、色んな方に教えて外れないと言われるので、これ、ほんとに外れないと思います。
しかも、この方法をとると1本500円のようなテーブルワインも全然OKです。
何で外れないワインを選べるようになったかというと、理由があります。
ワイン好きっていうと何かあれな感じしちゃうんで、私の場合はそういう類と違います。
普段飲むのは酒屋で選んで高くても1本1000円以内のものです。
昔、ソムリエ気取りで高いワインを飲んだ時期があったんですが、全然美味しいと感じず。
タバコ吸ってたから細かい味なんて解る筈ないというのもあるんですが、飲み方を知らなかった。
ただ、これは高いワインなんだ。すげーみたいな。そんな感じだったと思います。
今考えると、とてつもなくもったいない事してたんですが、私は飲み手として成熟してなかった。
高いワインは飲み手も選ぶって話です。
んで、当時のワイン売り場のソムリエさんがオーストラリアのワインを勧めてくれて。
そこで出会ったワインにとても衝撃を受けまして。
これは凄いって事で、それから特に南半球を買い漁って飲んでました。
でも、当たり外れが凄いあるんですよね。要するに好みじゃないワインが混じって来る。
常に美味しく飲みたい私は飲んだワインを記録とってみたんですね。
毎度前置きが長いんですが、ここからが本題です。
美味しいと思ったワインを記録から分析すると傾向がわかりました。
1.緯度が殆ど同じ。
2.葡萄の品種が殆ど同じ。
この2点です。
気候とか土壌とか、細かい味を作る要素なんか殆ど私には解りません。
単に美味しいワインの生産地だなって思う国を並べると、「オーストラリア・チリ・南アフリカ」なんですよ。
それぞれの国の北と南では相当緯度が違うんですが、美味しいと思うシャトーがある緯度が殆ど一緒なんですね。
あと、葡萄の品種。私の場合は前述の通り「シラーズ」という品種を美味しいと感じるという事がわかりました。
ちなみに私が好きなのは南半球のシラー種。例えばイタリアのシラーとオーストラリアのシラーズは品種が同じですが
抽出の製法が違うので、全く違う味になるらしいです。奥深いですね。
3つのポイントで2つしかあらへんやんけ!って感じだと思うんですが、もう1つは買った後です。
上記2点でも、あれ?外れた?って思うことがあるかもしれませんが、その時はおまじないをします。
一旦開けた後に、ビンをブンブン振ります。星付きシャトーの高いワインでは絶対にやらない事だと思いますが、
空気に触れさせることを強制的にさせるのは安いワインでは結構重要らしいです。
たとえば、コノスルというワインがあります。これはチリのワインなんですが、
オーストラリアのデ・ボルトリや南アフリカのオビクワとちょっと違ってスパイシーです。
開けて1日置いておくと丁度良くなります。1日待てない時は、ブンブン振ります。
たったこれだけです。これだけで自分が美味しいと思う外れないワインを選べます。
緯度まで解るかい!っていう人は、南半球であれば国名を覚えておけば大体OKです。
ITに話を戻しましょう・・・もともとしてないですが・・・
これは、身近なデータの活用でもあります。分析をして傾向を知るのは重要なことだと思います。
自身が購入したワインの蓄積データを活用して、1つの答えを導きだしています。
これが店舗単位になってくるとワインの売れ行きから、その地域のワインを購入する客層をターゲットとして、
品揃えを考えたり、新しい商品ラインナップを考えたり出来るわけですね。
統計的にオーストラリアのワインを買うお客様が南アフリカのワインを買う確率が高い。
というデータが導き出された時、オーストラリアのワインを買ってるお客さんに、
南アフリカのワインを勧めればとっても効果的ですね。また、逆もしかり。
こういうアプローチってネットではよく見ますね。
スーパーやコンビにでは、当たり前のようにビッグデータが活用されてますが、
まだまだ個人商店規模や小さいスーパーではデータの活用余地があるんじゃないかな。
と思ってます。個人向けのデバイスはどんどん発展してきているので、後は解析手法や
インタフェースが充実してくれば、より身近になっていくと思います。
ビッグデータの活用は廃棄率低下にも繋がり、究極のエコにも繋がると思います。
ビッグデータがより身近になって、地球がよりよくなっていければ良いと思いました。
外れないワインを選ぶ3つのポイントを地球規模の問題にして、この文章を閉めようと思います。

2014年に思う事

あけましておめでとうございます。
今年もよろしくお願い致します。
2014年になりました。
昨年を振り返ってみると、vagrantやらchefやらが成熟した感が半端なく、
またzabbixも2.2になって大分クラウド環境に馴染んできました。
APIもだんだん成熟してきており、世界に広まるのも時間の問題かなという感じになっています。
NagiosベースではsensuがAPI系で注目株となっています。自動化は加速していくばかりです。
クラウド業界では満を持してマイクロソフトのAzureが日本リージョンを発表しました。
日本リージョンは作らないって言ってたのにずるいなぁ・・・と思ったのは内緒です。
今年の上半期にリリース予定となっています。Azureを未だ触ってない方はお早めに。
お金持ちだからか、かなり大きい事例も増えてきており、目が離せない状態になっています。
マイクロソフトが復権する日も近い気がします。というより、既に来てます。
今年でAWS1択から2択になるぐらいに成長してくれるだろうと注目をしています。
さて、2014年は私はIT運用自動化元年になると考えています。
2010年がクラウド元年。CMでも佐藤浩市がクラウドの話をしていました。
たった4年で市場がここまで大きくなりました。
今やクラウド戦略が鍵を握るといっても過言ではありません。
その流れで自動化も加速していきました。
AWSの影響はとても大きいと思います。歴史を作る企業とはキャッチフレーズだけではありません。
AWSのお陰でインフラAPIでソフトウェア化が加速し、開発者も気軽にインフラを触れるようになりました。
DevOpsなんて言葉が2012年頃から流行り始めて、今では当たり前のキーワードになってます。
今年はその成熟したIT運用自動化がサービス化されていく年だと考えています。
オペレーションだけを行っているようなIT運用は今後、本格的に淘汰されていくでしょう。
いかにあらゆるリソースデータから解析を行いKPI化していけるか。プロアクティブに提案できるか。
それが運用者の仕事となっていくと思いますし、そうしていかなければいけないと信じています。
「アウトプットは障害対応です。」というIT運用の発想は今はまだしも、今後は通用しないでしょう。
要するに世の中の殆どのMSPが淘汰される。MSP自体の考え方が変わるという事です。
私は世の中のMSPは無くなったほうが良いと思ってます。
(MSPに属する人間がこんな事を言うと怒られてしまうかもですが・・・)
具体的には働き方や売り方を変えるといったほうが正しいかもしれません。
IT運用のスペシャリストであり、私のIT運用の師匠がこんな話を結構前にしてくれました。
「障害が発生して人が電話をするのっておかしくない? だって、お客さんは絶対に怒ってるじゃん。
 怒ってるの解ってて電話するなんて、そんなの人じゃなくて機械がやれば良いんだよ。」
今までは24×365で有人で監視していることが優位だと思っていましたが、
この話を聞いた時、初めて私は「有人監視」の優位性が吹き飛びました。
とても単純な話です。「人が人らしく働くために、人がやらなくても良い事をを機械にやらせる。」
IT運用、特にMSPのユーザが求めてるのは人が電話してくることではなく、
「正確な情報が伝達され、かつ素早く対応が行われること」だと思います。
その後に人としてのコミュニケーション、やり取りが必要なケースはあると思いますが、
1次対応に人である事を求めている訳ではないとおもいます。
人が判断して切り分けを行い、そして本当の障害だけを通知するようにする。
というのが有人監視の優位性と言われるところだったと思います。
しかし人が判断する内容が「決められている事」であるならば、それは自動化可能です。
自動化出来る為の材料が成熟して出揃っている以上、やらない理由がありません。
今年の展開等は色々と考えたり、自社のメンバーとも話をしていますが、
プラスαを提供して、MSPらしさが出せるようなIT運用自動化を考えています。
今年はIT運用のスペシャリスト見習いとして、IT運用業界に貢献できるような動き、
既存のMSPの概念を破壊するような動きをしていきます。
(あくまで私はMSPの中の人です(笑))
ちなみに、一緒に破壊してくれる人も募集中です(微笑)
どうか本年もよろしくお願い申し上げます。

AWS認定ソリューションアーキテクト アソシエイトレベルの話

先日、AWSの試験を受けてきました。
正式名称は「AWS認定ソリューションアーキテクト アソシエイトレベル」というらしいです。
色々書きたいんですが、詳しいことを書くと規約違反になるらしいので控えめに。
なかなか情報も少ない試験ですので、やった事をロギングしておこうと思います。
受験する方の参考になれば幸いです。(2013/12/20の情報です。)
■私のレベル
これから受験を考えている方で、この文章を読む上で重要な基準が私のレベルだと思います。
「一般的なAWSの用語や意味は理解していて、お客様に説明出来る。」レベルです。
AWSは日常的に運用を行っていました。ある程度の設計・構築の提案等も行っています。
運用規模的には10台~30台程度。基幹システムもフルAWSで提案等を行っていました。
ソシャゲの基盤運用をやらせて頂いたり、負荷分散やDRについては割と触れ合ってました。
■試験内容について
セクションは大きく4つ。(右の%は出題割合です。)
高可用性、コスト効率、対障害性、スケーラブルなシステムの設計 60%
実装/デプロイ 10%
データセキュリティ 20%
トラブルシューティング 10%
下記のExam Blueprintに詳細が記載されています。
http://aws.amazon.com/jp/certification/
※受験される方は必ず確認する事をお勧めします。
受験にあたっての振り返りです。
1.勉強時間
そもそも業務の方が繁忙期で直前1週間は全く時間が取れませんでした。
本当はもっと勉強したかったんですが、費やした総勉強時間は大体10時間程度でした。
AWSを触っている時間ではなく、この認定試験の為に勉強した時間です。
AWSをある程度触っていて理解している人ならば大体この程度でギリギリいけると思います。
毎日のように触って構築なり運用なりしてるぜ!っていう人はもっと少なくても受かると思います。
逆に、他のクラウドは触っていてもAWSを全く触ってない人は苦労すると思います。
その中でも、ある程度の一般レベルのサーバー運用や管理を知っていたり、考えていたりする人は、
一般的な知識とAWSのサービス名称とを紐付けられればOKだと思います。
2.勉強方法
色んな勉強方法があるようですが、私は通勤時間が主でしたのでスマホでブラウジングして勉強しました。
主にAWSのサービス説明のページを読みました。サービス毎にまとまっているので楽でした。
ちょっと解り辛い表記の部分が幾つかあるんですが、それを調べると大体誰かが質問していて、
FAQのページに書いてあるので、説明ページ→FAQという形で理解を深めました。
実際に触った事があまり無い方はクラウドデザインパターン系の本やWebページを参考にして、
作ってみるのが良いと思います。AWSへの予算としては1000円もあれば十分です。
前述の通り、試験範囲は公式ページに記載されているので必ず確認する事をお勧めします。
3.重点的に勉強したところ
参考にしたのは前述の説明ページとFAQです。
http://aws.amazon.com/jp/products/上記から主に読んでいったのは以下です。
—————————————————————-
コンピューティング
Amazon Elastic Compute Cloud(EC2)
Auto Scaling
Elastic Load Balancing
コンテンツ配信
Amazon CloudFront
データベース
Amazon Relational Database Service(RDS)
デプロイ&マネジメント
AWS Identity and Access Management (IAM)
Amazon CloudWatch
AWS Elastic Beanstalk
AWS CloudFormation
AWS OpsWorks
アプリケーションサービスの全て
ネットワーキングの全て
ストレージの全て
—————————————————————-
これだけ見ると範囲広すぎなんですが、全てのサービスと連携し得るものを厚めに勉強し、
それ以外については言葉の意味や専門用語の理解を深める方向で進めました。
特にIAMやCloudWatchと他との連携は詳しくなかったので調べておきました。
60%と厚めな配分の可用性、冗長性まわりという事で、ELB、AutoScalingも厚めに。
MultiAZが出来る場合はどういう動きをするのか等を見直しました。
私は運よく合格する事が出来ましたが、想像を遥かに超えて難しかったです。
満遍なく得点は取れてはいましたが、実装/デプロイのセクションが70%の正答率でした。
CloudFormationやOpsWorks、ElasticBeanstalkあたりの理解度が低いんじゃないかなと思います。
デプロイ系は私の業務ではあまり触る機会が無いので、勉強して理解を増やしたいと思います。
またVPCについて理解を深めていなかったのも影響したと思います。
色々書きましたが自分の弱点や習熟度がAWS基準でわかりますので、
個人的には15000円払って受ける価値がある良い試験だと思いました。
■あとがき
今は挿せば繋がりますが、一昔前はLANケーブルっていってもストレートやクロスがあって、
ちゃんと対象機器によって使い分けていたと思います。
インターネットに繋ぐのにもモデムを使用してテレホーダイ等を駆使して一生懸命繋いでましたが、
今やWifiスポットがそこらじゅうにあり、テザリングでも簡単にネットに繋げる時代になりました。
恐らく近い将来、インフラエンジニアではAWSが使えて当たり前の時代になっていると思います。
そうなる前に、AWSがある程度解っているという事をAWS基準で確認して、
AWS以外を積極的に触っていくというのも一つのやり方なんじゃないかなと思います。
とりあえず、今の世の中的には持っていて損が無い資格だと思いました。
今回はこの辺で。

Windowsの小ネタ

最近、縁あってまたWindowsサーバをイジル機会が増えてきて嬉しい限りなのですが、
昔の資料を漁っていたら、2003をSIしていた頃に使っていたネタのメモが見つかりました。
使えるかなーと思って試してみたら、2008R2でいくつか使えたので書いておきます。
2008R2等で使用する際は、コマンドプロンプトを管理者モードで実行する必要があります。
右クリック→管理者として実行でOKです。
・色んなサイズのファイルを一瞬で作る方法
転送テスト等をする際に重宝するコマンドです。
ファイル処理系のバッチファイルの実行時間を計るマテリアルとしても使えます。
fsutil file createnew ファイル名 ファイルサイズ
例) test.txtというファイルを1GBで作る
fsutil file createnew test.txt 1073741824
・テストでイベントログを出す方法
監視検知テスト等をする際によく使用したコマンドです。
またバッチファイルの失敗等をイベントログに出力する際にも使えます。
システムイベントログ
eventcreate /T 種類 /ID イベントID /L system /SO ソース /D 説明
アプリケーションイベントログ
eventcreate /T 種類 /ID イベントID /L application /SO ソース /D 説明
/TはSUCCESS、ERROR等の種類。/IDはイベントID(1000以内で指定)。
/Lは出力するイベントログ、/SOはソース(アプリケーション名)、/Dは説明です。
ソースは省略するとeventcreateとして出力されます。
例) アプリケーションイベントログにbackup処理というソースの「バックアップ処理失敗」というイベントログをID500でエラー出力する
eventcreate /T error /ID 500 /L application /SO “backup処理” /D “バックアップ処理失敗”
・ネットワークドライブにバッチログインする方法
定番ですね。NAS等にログインして使用する際に使用出来ます。
NetApp等のストレージをNASにして、そこへデータを送り込む時に使ったりしてました。
ユーザレベルでもTerraStation等、バッファローのNAS製品で使えそうですね。
AD環境下でも通常のUserログイン時でもどちらでも可能です。
■AD環境
net use デバイス名 \\コンピュータ名\共有名 パスワード /user:ドメイン名\ユーザー名
■WU環境
net use デバイス名 \\コンピュータ名\共有名 パスワード /user:コンピュータ名\ユーザー名
・リモートからコンソールログインする方法
障害対応あるあるで、リモートセッションが埋まってしまって対応出来ない。
なんて時に、コンソールセッションを使って対応します。
(こういう事にならないように皆さんログオフしましょうね^^;;)
mstsc /console /f /w: /h:高さ /v:サーバ名
ちなみに、mstsc /consoleだけでokです。実行するとリモートデスクトップの入力画面が出てきます。
(管理セッションでログインする mstsc /admin はver6.1~有効です。)


未だpowershellとか全然ないときの話なので、今はもっと簡単に出来るのかな?
2012R2とか未だ触れていないので、触りながら試そうと思います。
Windowsの小ネタでした。

vyattaの初歩的コマンド

最近、vyattaを使う事が増えてきた。
IOS+NetscreenOSな感じなので、使い始めると結構面白い。
Tab補完や?の使いかたも普通のNW機器となんら変わりません。
とりあえず、検証環境で確実に使う初期コマンドとNAPTのおさらい。
※vyattaは6.6を使用してます。6系とそれ以前ではNATのコマンドが違うので注意。
自分の検証環境は1台の物理(クアッドのHTで論理8コア)サーバにXenServerを入れて、
そのゲストにネットワーク機能を持たせて通信させるという構築をしている。
XenServerではOtherLinuxテンプレートでvyattaのCD(LiveCD)を用意してやれば普通に入る。
大体4コアは決めうちで以下な感じ。
XenServer(HOST)
- vyatta (NW)
- Windows2008R2 (XenCenter等管理)
- CentOS (開発統合:Gitlab / ChefServer / redmine)
AWS等とVPNでつないで、残り4コアでzabbixの検証したり、debianだったりと色々と遊んでます。
開発環境は今度ゆっくり書くとして、今回はvyattaの初期コマンド。
以下だけでインストール~初期稼動可能。
例の内容(適宜自己環境と変更)
ホスト名:vyatta1
IP:10.2.184.4/16(eth0)
DefaultGW:10.2.184.2
その他:
・10.2.0.0/16のNWはIPマスカレードさせる(オーバーロード)
・10.2.184.1/16のport22を10022でport転送させる。
★基本の流れ
ログイン→configure→設定→反映(commit)→保存(save)
※save(いわゆるcopy run sta)を忘れることが無いように注意
初回インストール時ログイン
ID:vyatta / PASS:vyatta
インストールコマンド(基本的にEnterでOK)
install image
コンフィグモードに変更
configure
通常モードでの設定確認
show configuration
コンフィグモードでの設定確認
show
設定反映
commit
設定の不揮発セーブ
save
ホストネーム
set system host-name vyatta1
ホストドメイン設定
set system domain-name pc-concierge.net
パスワード変更
set system login user vyatta authentication plaintext-password h0geHoge
サービス設定(ssh)
set service ssh
インターフェースIP設定
set interfaces ethernet eth0 address 10.2.184.4/16
デフォルトゲートウェイ設定
set system gateway-address 10.2.184.2
IPマスカレード設定
set nat source rule 10 source address 10.2.0.0/16
set nat source rule 10 outbound-interface eth0
set nat source rule 10 translation address masquerade
port変換(port転送)設定
※translationは転送後のポート、destinationは転送前ポート
set nat destination rule 100 inbound-interface eth0
set nat destination rule 100 destination port 10022
set nat destination rule 100 protocol tcp
set nat destination rule 100 translation port 22
set nat destination rule 100 translation address 10.2.184.1
NAT設定の確認
show nat destination rule
設定の削除
delete ~
こんなもんかな。とりあえず、これだけ覚えれば設定可能。
VPN設定等はまた次の機会に。

サバフェス!に参加したという話

全くブログを更新してなかったので、このイベントに乗って更新してしまえ。
と思ったかどうかは別として、↓↓↓なイベントに参加しました。
http://serverfesta.info/?page_id=5
イベントの名前はサバフェス!で、Twitterのタグは #サバフェス です。
簡単に言うと、「アプリを触らずに5台使ってインフラだけで1週間使って何とかする大会」です。
で、今回のアプリはWordpressでした。
まぁ、アプリを触らずにインフラだけでっていうところがとっても憎いあんちくしょーな訳で。
インフラで何とかしてください。(キリッ」 っていわれる運用屋の日常を地でいったような大会で、
ドMエンジニア日本代表としては、まさにど真ん中な状態であったわけです。
まぁ、結果的に10位近辺をうろうろとしてまして。。TOP10入り出来たかな?
というところだと思います・・・。
20万円の使い道として、游玄亭で焼き肉を食べて祝勝会をするって話までしてたので、
この落ちっぷりっていったらもう・・・・なんですが、とりあえず楽しかったです。

さて、今回も頼もしい仲間と一緒に参加しました。
いーすふるで参加する大会も今回で3度目。準優勝→圏外と来たので、
3度目の正直という事で強引なスケジュールでしたが、みんなで参加する事にしました。
1人がパッケージ、1人がソース、1人が解析と役割分担をして進めました。
で、やった事をざっくり書くと、
0.環境の整備
1.バージョン/パッケージの取捨
2.ベンチ対策/ベンチマークソフト作成
3.シングル構成でのチューニング
4.構成決定/環境構築
5.LB構成でのチューニングとLB変更
という感じだったと思います。

0.環境の整備
環境といってもgitでうんちゃらとか、Chefでうんちゃらっていうのはやっていません。
コミュニケーションツールとしてインストールマニアックスの時も活躍したChatworkを採用。
GoogleDriveを使用して情報の共有を行っていました。
しかしChatworkの神ツールっぷりは凄いですね。今更なにをって感じかもしれませんが。
ログとして残せて途中参加の人でも見れるというのが、とても助かってます。
今回は音楽にも勝手にこだわりました。Zardの負けないでを局所で流す事で、
ブレイクスルー出来ない間、なんとか自分に頑張れって。メンタルマネジメントをしました。
Youtubeで聞いてたんですが、いつの間にかに揺れる想いを聞き始めていて、
気付いたら中山美穂&WANDSですよ。もうね、なつかしさに浸る訳で。これはまずいなと。
そうそう。モーツァルトをエンドレスで掛けまくってたんですが、これもダメですね。
モーツァルトの音楽って何も考えなくなるくらい凄いんですよね。もう、考えられなくなっちゃう。
逆に言えば、音楽に没頭しちゃうんですね。気付いたらモーツァルトでヘドバンしてました。
あー、これやべーなー。って思って、ホルモンに変えたんですけど、またヘドバンしてました。
この辺のパワープレイは結果的にperfumeに落ち着きました。あ、東京ドーム見に行きます★

とりあえず、普通のブログ1話分くらい書いておいて技術の話をまるでしてないですね。
半年ぶりの更新なので許して下さい。以下、技術をちゃちゃっと。

1.バージョン/パッケージの取捨
先ず、以下を最新のstableでソースからインストールしました。
Apache2.4、php-fpm(php5.5+zendopcache)、MySQL5.6で-c100でlocalhostでabしてみました。
Requests per second:    18.07 [#/sec] (mean)
っで、次にApache2.4をNginx1.5に変更すると、
Requests per second:    22.46 [#/sec] (mean)
ここまでは想定内。で、proxy_cache。
Requests per second:    10711.23 [#/sec] (mean)
まぁ、そうなりますよね。で、この状態で初日は3位でした。
これでいけるかなーと思いつつも、SSL等、入らないものは外していましたが、
適当にコンパイルしていたので、念のためパッケージでも確認。
チームメイトに確認してもらったところ、!!(⊃ Д)⊃≡゚ ゚ な結果に。
nginx1.4.4、php-fpm(PHP 5.4+zendopcache)、MySQL5.5.34
Requests per second:    26.49 [#/sec] (mean)
Nginx1.0系だと22.79程度まで下がったので、1.4にした効果は相当あった模様。
後述のベンチツールで比較してもパッケージの方が早かったので、
この結果から、基本的にパッケージ(殆どyum)で対応しようという話に。
最適なコンパイルオプションを考えるのがだるかったのと、
もし本当にテンプレ化された時に、運用も楽なのでパッケージを採用しました。
あ、zendopcacheのみソースインストールです。
git cloneで持ってくるとcheckoutしないとdev版が入るし、そもそも全てパッケージにした為、
gitをインストールする意味も無くなったので、普通にtarをwgetで持ってきてコンパイルしました。

2.ベンチ対策/ベンチマークソフト作成
ベンチ対策として負荷確認の為に、sysstatを1分更新にして、
psやnetstat、vmstatの状態を毎分取得するスクリプトを作ってcronに仕込みました。
ミドルウェアのログはWebサーバを慣れているapacheにしてログを詳細に記録。
MySQLはbinlog、slowlog全部だし。php-fpmも出しました。
この時点ではphpが重く、php-fpmのCPU使用が顕著でした。
解析してたチームメイトが独自のベンチマークソフトを作ってくれました。それを使用して確認しました。

3.シングル構成でのチューニング(最終日前日)
この状態でphpが重くてpostがネック!っていうのは解っていたので、
php-fpmのプロセス数を調整したり、mysqlのメモリ調整をしたりなどをしました。
EngineはMyISAMでもInnoDBでも変わらなかったので、InnoDBに変更しました。

4.構成決定/環境構築(最終日前日)
構成ですが、nginxのproxy_cacheよりvarnishの方が高速だったので、varnishにしました。
localhostに対して-c100のabをかけると、nginxだと10000~11000だったのが、varnishだと、
Requests per second:    15202.19 [#/sec] (mean)
14000~15000くらいで安定しました。もちろんvarnishもyumです。
負荷分散については
LVSが全員苦手で良いイメージが無いので
書き込みと読み込みを分けるかも?という今後の展開を考えてhaproxyにしました。
これがこの後悪夢を生むことも知らず・・・。
kernelも最新だった3.12.1に変えてみましたが、苦労と時間の割に殆ど変らなかったので、
こちらも運用面や今後を考えて使用しませんでした。
構成は、3層+リバプロにしました。アクセス順で書くと、
LB: HAProxy
ReverseProxy: Varnish
WebServer: Nginx
AppServer: php-fpm
DBServer: MySQL
という構成で、Nginxとphp-fpmはUnixSocketで連携しようって話になったので、
Varnish~php-fpmをスケールアウトしていく方針にしました。

5.LB構成でのチューニング(最終日)
さて、HAProxyでバランシングしたのは良いんですが、Getが伸びません。
Postはスケールアウトした分だけ伸びるので、想定通り。ですが、Getが何をやっても伸びない。
modeをTCPにしようが、Listenにしようが変わりません。
GETスコアも80000位をいったりきたりしており、ここが壁となりました。
前述したZardの負けないで連発ポイントです。ほんとくじけそうでした。
気分転換に散歩してる時に思いついたのが、
1.そもそもGetの後にPostしてるんだからL7要らないよね?(今更感)
2.65536に近い値だったので、何かしらの上限に引っかかってる?
という2点。
とりあえず、TCP周りを少しいじって2の様子をベンチで見てみましょうという話に。
それから1を考えていくという方針になりました。
既にエラーとして出ていたsyncookiesを外したりportレンジ上げたり。
TIMEWAITの数を減らす為にtw_recycleとfin_timeoutを短くしたり。
net.ipv4.tcp_syncookies = 0
net.ipv4.ip_local_port_range = 10000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 10
あとはopenfileまわりもすこしいじってdstatかけながらベンチを待ちました。
で、ここで想定外の事態。ベンチが来ないw
待てど暮らせどベンチが来ない。ビリージョエルベスト(1h10m)1周しても来ない
New York State of mindをリピートし続けますが来ない
そうこうしてるうちに何と計測時間終了・・・。3時間待ちでベンチ来ませんでしたorz
さあ、、、どうしようという話をしていたところ、
LVSはHAProxyの2倍以上の性能差との資料を発見。それからLVSにするという動きが活発に。
LVSでDSRをしてやればこの状況もブレイクスルー出来るのでは?
しかしながら、LVSでドハマりした経験ばかりの3人は空を見上げてました
(あれ・・・・Applicationうんちゃらっていうテンプレートが使えたような・・・。)
レギュレーションを見直すと使えるって書いてありました。これ、使っちゃおうぜ。
って事で、LVSをこのテンプレートを使ってインストール。
WebUIもあって楽ちんに誰でもLB管理が出来て、対話方式でインストールできます。
これ、ほんと楽です。もうベンチが来なかった事は許しましょう!!www
ここからLVSへの組み直しを実施。インストール後はデフォルトでDSRの状態。
iptablesの使い方まで教えてくれる親切っぷりでした。
今回のイベントって、これ使ってほしかったのかな?・・・・。
簡単にベンチをとってみると、明らかに数字が伸びていました。
今度はGETもスケールしただけ増えていきました。
ただ正式なベンチは終わった後だったので、実際どうなるかは解りませんが・・・
最後にブレイクスルーした?筈なので、何とか戦えた感があって良い終わり方でした。
寝ようと思った矢先、そういえばbeta版もダメだったよな・・・
APCuがbeta版でした。使ってないのにとりあえず入れたっていう訳わからない状態だったので、
APCuについてはコメントアウトして使用しないようにしました。
最後に再起動テストを行って完了!時間は5時でしたw
最終的な構成は以下の通り。
Web専用機 3台
DB+WEB機 1台
LB機 1台
Web構成(基本的にパッケージ)
-varnish(80/1180)
-nginx(1180/UnixSocket)
-php-fpm(UnixSocket)
-php54(zend_opcache)
Web+DB構成(基本的にパッケージ)
-varnish(80/1180)
-nginx(1180/UnixSocket)
-php-fpm(UnixSocket)
-php54(zend_opcache)
-mysql5.5
LB+web構成(基本的にパッケージ)
-LVS

やらなかった事や、やり残した事は以下の通り
1.varnish+nginxを複数インスタンス立ち上げる
GET時はvarnishのCPU負荷は20%程度だった為、ポートを変えてvarnish+nginxを増やしていけば
その分だけGETも増える筈です。煩雑になるし、そんな使い方しないよなっ。という理由で止めました。
2.オンメモリ化
M8インスタンスでメモリが売るほど余っていたので、当初は全てオンメモリにする予定でした。
ただし、突然落ちた場合にデータが消える等、運用上の様々の問題を考えると難しいかなと。
そもそもGETはcacheだし、MySQLもInnoDBにして殆どI/O負荷がなかったのでオンメモリ化も控えました。
3.ip_conntrackの設定
やらなきゃってタスクだしもしていたのにすっかり忘れてました。
いつもは機能分離で、FWは別にやらせてiptablesを起動する事自体が少ないのですが、
今回はiptablesを起動している事をすっかり忘れてました。普通に使えばハマらないのですが、
iptablesご使用の際にはきっと・・・になります(微笑)
4.LVSサーバの有効活用最後の最後に変更したため、色々移す気力がありませんでしたorz
本当はDBをLVSサーバに持って来て、WEB専用機をもう1台作ろうと思ってました。
かなり勿体ない事をしたかなと思ってます。
こんな感じで1週間を過ごしました。
Wordpressのインフラをここまで考えた事が無かったので、とても良い刺激になりました。
途中どうなるのか(微笑)っていうスコアも出てましたが、運営のベンチ変更は適切だったと思います。
次回はec-cubeあたりでしょうかw 次回のサバフェスでは今回をふまえてリベンジしたいと思います!

supergrepでログをブラウジングする

「apacheやsystemのログをブラウジングしたい。」
こういう要望が増えたのってソーシャルゲームが流行り始めた頃だと思います。
KPIっていう言葉が聞こえてくるようになって、非エンジニアの方もログを見る必要が出てきた。
MapReduceでガッツリ解析もそうなのですが、今、nowなログが見たいんや!!(特に課金周りの)
なんていうのが月初に飛び交ったりするとか、しないとか。
自分で書いても、そんなに難しい話ではないのですが非エンジニアの方も見て、
尚且つ不要なログを簡単に省けるような仕組みというとちょっとめんどい。
更に言えば、この手の悩みって誰もが持つので、やってる人は世の中に沢山居るはず。
自分の記憶だと確かrailsのアプリでログをブラウジング出来るアプリケーションがあったと思うのですが、
思い出せずにgoogle先生にrubyの線で聞いてもまるで見つからず、、、途方に暮れてたら、
「supergrep」というnode.jsで使うとんでも素晴らしいアプリがあったので導入してみました。
インストールについては、node.jsとnpmが入ってればOKです。
私はgitで持ってきますが、宗教的理由などでgitを使えない方はzipで落とせば良いと思います。
https://github.com/etsy/supergrep
こんな感じで簡単にインストール→起動できます。
git clone https://github.com/etsy/supergrep.git ~/supergrep
cd supergrep/
npm install
./runlocal
で、「http://サーバIP:3000/」にブラウザでアクセスすればOK。
設定ファイルは「localConfig.js」です。nameとpathら辺を弄れば、どんなlogにも対応出来ると思います。
ちょっと見てみれば解りますのであえて説明しません。あしからず。
英語でガイドがあるんですが、とりま日本語でWebUIの紹介を。
1
Guideで英語のツアー的なのが見れます。英語読めない人は途中でやめられないので飛ばすの面倒です。
チェックボックスで設定ファイルのnameで指定しているログを切替が出来ます。この例ならWebです。
Max entriesで最大表示数を選択できます。
Max entriesで数を減らした後に数を増やしても、減らした分はリロードしないと再表示出来ないので注意。
2
Wrap linesで折り返しの表示になります。便利な機能ですが使うシーンは少ないかもですね。。
3Reverse sortで、ソートを逆にする(過去から順番にソートをする)事が出来ます。便利だ~。
4Filterでは文字列でフィルタリングが出来ます。デフォルトでは入力キーワード以外を表示になります。
入力キーワードのマッチング行のみを表示したい場合は、Invertにチェックを入れます。
例の場合は404で引っ掛かる文字列のみを表示しています。これが一番使う機能でしょうね~。
5Highlightではキーワード行を黄色く塗りつぶしてくれます。バグを見つけるのも早くなりそうです。
6Clear Logで、現在表示されているログをクリアできます。
もちろん、ブラウザをリロードすれば再表示されますのでご安心を。
とまぁ、いたれりつくせりなツールな訳ですが注意点が幾つか。
・セキュリティをしっかりと。
当たり前の話ですが、セキュリティはしっかり担保しましょうという話ですね。
FWが無い環境では、しっかりとiptables/ufwで守ってやるのが良いかと。
表示させるログについても必要最低限にするのが吉。
・表示行のチューニングを。
デフォルトでは表示行は500です。増やすのは構わないのですが、
ブラウザ、サーバ、共に表示させる労力を考えて環境に合わせてどうぞ。
supergrepを紹介しました。これで快適にロギングしてくだされ。
ここまで色々書きましたが、「log linux grep tail browser」で検索すると結構出てきますね。
ここは参考にさせてもらいましたー。あざっす!あざっす!
「ブラウザから tail -f log | grep keyword できるツール supergrep」 TAKUMI SAKAMOTO’S BLOG
http://blog.takus.me/2013/04/25/supergrep/

4月1日からブログを始めた2つの理由

はじめまして。taka3110と申します。
2013年4月からブログを始めました。どうぞよろしくお願い致します。
このブログはIT運用者向けに技術情報は勿論、チームビルディングやマネージメントについて、
色々と勉強しながら学んでいく目的で書き始めました。
ペンギンの教科書ではメンバー・チームリーダー視点で書いていましたが、
この「愛される運用・監視」についてはリーダー・マネージャーの視点で書いていこうと思います。
ペンギンの教科書を読んで下さった皆さんは恐らく、その立場になられているんじゃないでしょうか。
後輩を持って、主任になって。リーダーになって、マネージャーになって。
立場が変われば視点も変わるのは当然だと考えており、私もその視点で考える立場になりました。
これからはマネージメントや経営品質についても考えられるブログにしたいと思ってます。
さて、このブログを4月1日から始めた理由は2つあります。
1つは移動等が多いという事。
昇進等も多く、今までと違う悩みを抱えやすいこのタイミングで同じ境遇の方達と、
色々なコミュニケーションを取っていければ良いなぁと思って書き始めました。
また、私自身も転職をして環境が変わるこのタイミングは書き始める切っ掛けになりました。
もう1つの理由は、勿論これです。
「エイプリルフール」だから。いや、続けますよ。ええ。
ただね。続かなかった時の言い訳にし易いじゃないですか。
あ、あれね。あれ、エイプリルフールだからって。
なんてアメリカナイズされた言い訳なんでしょう!!!逆にこの日に始めない理由がないですね。
ダイエットを始めたりするのにも都合が良い日ですね。
俺、今日から走るわー。とかいって、FPSでもやりながらピザ食ってる訳ですよ。
ピザはトマトの割合が高くてサラダだから。少なくとも俺はサラダ認定してるからとか。
自分に言い訳をする訳ですが、まわりにはエイプリルフールですから!って言える訳です。
という訳で、頑張ってゆるーく続けますので皆さん応援をお願いします。