2012-03-20

退職します。

日常

4月中旬で退職して次の日から新しい職場となります。

現職は中小のSIerでしたが、これからはWebサービスの企画から運用までをインフラエンジニアという立場で支える仕事になります。

今の会社は初めて社会人となったので(学生が長かったので)色々と良い勉強をさせてもらいました。

最初はPHPやJavaを書いてましたがその後はOracle、ZABBIX等に基本的にインフラエンジニアとして関係しながらPythonでちょっとしたアプリを書いたりもして割と自由に裁量も与えられていたと思います。

ただ仕事を続けていく中で、SIではなく自社でサービスをしていてかつOSSをフル活用！みたいな会社で楽しそうに働く方達を勉強会等でお見かけする姿をとても羨ましく思っていました。

また、景気やエンドユーザの考え方に非常に依存した形でのビジネスのやり方に対して何かしら変えたいなと思って実際に動いたりもしましたががが…といった感じで当然ながら時間も掛かるなぁ、と。

それなら自分のやりたいような事をやってる会社に行こうと思って転職活動を始めました。

もう30だし。そんなに時間も無いと思ったし。自分が伸ばしたいと思ってるスキルを伸ばしやすい環境に身を置いてみたかったし。

というわけで今後とも宜しくどうぞ。

2011-11-23

ZABBIX-JP勉強会に行ってきた。

勉強会行ってきた

ブログを更新するまでが勉強会ィィィ！

というわけで一ヶ月前の勉強会ですが感想とかを。

発表資料とかはこちら

一つ一つのセッション毎に感想を書こうかなと思っていましたが、まとめて…。

既に記憶が薄れてきているのですが…Zabbix2.0での機能拡張のお話を非常に興味深く聞きました。

2.0でジョブ管理が入るって聞いていたのでその辺のお話が聞ければな～と思っていたのですけど、どうやら入らない？みたい。

SVNから引っ張ってきて1.9系のソースを軽く見てると

インベントリの機能拡張
1ホストに複数IPアドレス(DNS名も？) (「マルチホームホスト」と言うみたいです。)

とかのおかげでhostsテーブルの構造が少し変わってますね。

IPアドレスが1つのhostに複数紐付けられたことにより、hostsテーブルのhostidを外部キーにするテーブルが出来てたり、hostsテーブルのプロファイル、拡張プロファイルのカラムがごそっと別テーブルになってたり。

ちなみに1.8系だと公式ドキュメントにはZabbixAPIからプロファイルの設定は出来ると書かれていませんが一箇所PHPのソースを直せば既にhost.createとかの中では処理することになってるのでZabbixAPIからプロファイルも拡張プロファイルも作成・更新できます。

まぁ2.0になるとまた色々変わりそうですが。

あと注目したのはマップでホストグループ単位で1枚のマップにアイコンを羅列してくれる機能ですかね。

これは僕もお客さんと喋ってて結構よく聞く「欲しい機能」みたいなので。

てかこれと同等(？)の機能を独自に計算してAPI叩いてマップを作る、、みたいなのを目下実装中で複雑な気持ちになったりしてました。

マップの大きさの制限とか一枚に並べられるアイコンの個数の計算とかは1.9のソースをまだ見てないので今度見ておこうかなーと。

あとは他の発表(「エージェントとSNMPだけじゃないZabbix」)とも関係しますが現在ホストはIPアドレス(DNS名)のどちらも入力なしで作成出来ますがそれが2.0でも出来るのかな…？ってところが気になるところ。

これもソース読めって話なのでそのうち自己レスするかもしれません。

今回はAPIのお話が多かったように思います。

APIは確かに便利なんですが公式ドキュメントが…ちょっと…という感じはみんな思ってるのではないかと。

例えば公式ドキュメントのマップの作成のところ、例の通りに叩いても作れなかったりします。

それは、マップのエレメント作成時に指定するidが、ホストだったらそのホストのhostid、トリガーやマップも同様だったりするのですがその辺の事とかドキュメントだけではよく分からなかったりします。

今のところまとまったサンプル集は無いようなので、もしどなたかのご要望があれば作って公開しようかなーと思います。

最後に、発表者、並びに関係者や会場ご提供、ZABBIX-JPの中の皆々様お疲れ様でした！と共にありがとうございました！

2011-08-29

PyCon JP 2011

Python 行ってきた

（一番何もしてない自覚はありますが）スタッフとして参加しました。

当日は会場係ということでサブトラックにずっといました。

世界のKさんの発表の時にディスプレイのトラブルがあった以外は特に大きな問題もなく良かったかな、と。

次回以降はスピーカーとか発表する側でも関われたらなぁと秘かに…。

スピーカー、参加者、スポンサー、その他関係者の皆々様方ありがとうございました！

そしてお疲れさまでした！

（一番何もしてない自覚はありますが）スタッフとして見ていた感じだと、大成功だったと思います。

既に挙げられていることが多いですが、以下自分の関係したとこら辺でのメモ：

良かったこと

Ustreamを業者さんに頼んだこと(Twitter上でも評判よかったような)
(サブトラックには)机の上にモニタがあったこと
サンドイッチの提供、コーヒーブレイクが好評だったような

課題？改善点？

司会とタイムキーパーはやはり必要に感じた
誘導に関して(何時まで配置するか、看板設置有無とか)
ぼっち回避策

今後も何かあれば参加したりお手伝いしたいと思います！

本業のインフラ系のお仕事でも何かしたいですね…。

2011-06-17

PyConJP 2011

Python

Pythonistaの夏の祭典PyCon JP 2011が開催されますよっ。

ということで現在CFP募集中です。

詳しくはこちらからどうぞ。

ちなみに…前回のPyCon mini JPに参加して楽しい話をいっぱい聞けたし、なんか出来ないかなーと思い今回はスタッフとして参加してます。

2011-06-05

クックパッド×サイバーエージェント合同勉強会

行ってきた

行ってきました。

入るとまずはキッチンどーん！

後ろから始終調理音が聞こえてくる勉強会は初めてでした。

内容

OpenStack

無知だったので勉強になりました。

AWSとの差異や利点はあまり分からなかったけれど、AWSが最大公約数的な形で機能拡張していくとのことなので、色々面白そうな機能を独自路線で作っていってくれれば面白いかも？

あとPython触ってる端くれとしてはGUIがDjangoで出来てるってのもいい感じ。

以下、メモ。

プライベートクラウドをやってみたかった。

Cactusが現行バージョン

AWSとの機能比較

ロードバランシングはない

Cloud ControllerによってNovaプロセスを動かす。

デフォルトのハイパーバイザーはKVM

NW構成

FlatManaget

FlatDHCPManager

VLANManeger

novaコマンド

インスタンス起動・停止

スナップショットの作成

とか

euca2oolコマンド

Pythonで出来てる

novaコマンドとほとんど々ことができる

CloundControllerが停止してもComputeNOでとインスタンスに影響はない

ComputeNodeが停止すると稼働状況が伝わらない

デフォルトではvirtioを有効にして起動される

DjangoベースのGUIが付属している

ElasticFoxでも管理できる

WebAPIはある

CloudControllerは冗長化できる？

→出来るはず

スケールアウトする？

→多分。Eucalyptusがスケールしないから作ったという話なので

AmebaPicoとAWSについて

AmebaPiggの海外版？のAmebaPicoでのAWS運用のお話。

ZooKeeperを触ったことがないのでちょっと調べたところ、以下のページが勉強になりました。(日本語

Hadoop本読書会 - 13章 ZooKeeper

MongoDB、ちゃんと勉強しないとな…と思いました。

以下、メモ。

サーバ構成（全部AWS

キャッシュが効く静的データはCloudFront（CDN

細かい大量のコマンド独自のバイナリプロトコル（Socketサーバで受ける

分散Lockサーバ（ZooKeeper

キャッシュサーバ（memcached

DB（MongoDB

ログ集計サーバ（ElasticMapReduce

とかとか

EBSにバックアップ

Socketサーバ

ノンブロッキングIO

ID管理サーバ

ユーザIDの発行

UIDと認証機関でのIDの対を管理

Point管理サーバ

ユーザIDにひもづくポイント（サービス内通貨）を管理

ID管理サーバが発行したトークン付きのリクエストで処理

DB

エンティティはバイナリ形式でKeyValueストア可能なインターフェイスを持たせて定義

3台構成のレプリカセットを6シャード

プライマリ・セカンダリ・セカンダリ（on EBS）

Flashについて

クライアントで最初にメインモジュールを読み込み

→必要におうじてサブモジュールをロード

サーバとのイベント部分にはデリゲートインターフェイスを用意

Flashとサーバ側との分業体制をきちんと整備

EC2について

60個ぐらい運用していて、2、3ヶ月に一回くらいで落ちる（バージニアだから？

落ちたり特定ポートが死んだらリブート

落ちやすいので、冗長性をきちんと確保する

MongoDB

コネクションプールが枯渇する

シャードを増やした

スペックの高いインスタンスを利用

オートバランシングの挙動

そもそもバランシングのされ方が微妙

レプリカセットのコンフィグ情報未反映問題

コンフィグ反映には全台再起動が必要

画像配信システム

ここからはクックパッドの方の発表。

画像変換あたりの技術とかはやったこともなければ聞いたこともないという感じなので知らない単語が多かったす。

発表途中のアンケートでは、Apacheモジュールを書いている人が結構多かったのかな？一番前に座っていたので分かりませんでしたが。

今だとmod_wsgiだし開発止まっちゃったけど、mod_pythonの勉強でもしようかな…と思ったり。

以下、メモ

以前

ユーザの画像をAPサーバでコピー・リサイズしてストレージにぶっこむ

そしてそれを配信

どの画像サイズ、形が適切か？

→新サイズを試すたびに画像を800万枚リサイズ

iPhoneアプリとかに対応するためにまたリサイズ？

リリースも遅くなる

画像800万枚

秒間7000枚のリクエスト

クラウド移行を検討中（EC2へ

NFSをやめたい

現行（TOFUシステム

ストレージには1枚だけ溜め込む

リクエストのたびにリサイズする

URLにサイズと画質をぶっこむ

実装

Apache Module（mod_tofu.so

画像変換

ImageMagick

ストレージ

S3

AKAMAI（CDN）の後ろにELBでバランスしてApache

S3での苦労

APIが変になった

Akamai OR CloudFront？

EC2をオリジンに使用できるようになった（CloudFrontが）けど、

Akamaiの方が速い。

Akamaiのキャッシュ率はそんなに良くない。

昔はVarnishをELBの後ろに置いていたけど、値段が高い。

tofuを増やした方が安いので、今はそうしていて、Varnishは使っていない。