Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

2010年5月アーカイブ

「クラウド」って言ってみたかった。今は反省していr

20100528traffic.jpg

上のグラフは前回のエントリーを公開したときの、当blogを配信しているサーバのトラフィックグラフです。記事を公開した17時にぴょーんとトラフィックが伸びています。4時にも増えているけどこちらは謎。

実はこのグラフもCloudForecastを利用して取得しています。CloudForecastはサーバ等のリソース監視を行うツールもしくはフレームワークで、rrdtoolの薄いラッパーとして動作し、小規模から大規模なサーバ群を一括で管理できるように設計してあります。tokuhirom曰く、「perlが書けてrrdtoolがつかえるsysadminの人だったら使いやすいと思われる」というのがもっともしっくりくるような気がします。Perlとrrdtoolが使える運用者によるカスタマイズ前提なのがフレームワークと呼んでいる所以です。

CloudForecastはもともとミクシィで使われていた古いPerl4ライクなスクリプトをモダンな設計に書き直し、gearmanに対応させることで監視処理を分散させることを実現しています。監視項目は大規模ウェブサイトのmixiで使われているものをサービスに依存する部分を除き、ほぼそのまま受け継いでいます。今回オープンソースとして公開することで負荷の高いウェブサイトの運用ノウハウも広めていくことができるのではないかと思います。

ソースコードはgithubにて公開しています http://github.com/kazeburo/cloudforecast


このエントリーではインストール方法を簡単に紹介します。

本体のインストール前に、rrdtoolやSNMPのperl bindingが必要になります。これは各OSのパッケージで入れてしまうのが楽です。

# ubuntu
$ sudo apt-get install librrds-perl libsnmp-perl
# CentOS
$ sudo yum install net-snmp-perl
# rrdtoolはEPELを利用
$ sudo yum install rrdtool-perl

CloudForecastのソースコードはgithubから落とします

$ git clone git://github.com/kazeburo/cloudforecast.git
$ cd cloudforecast
$ cpanm -l extlib --installdeps .

*extlibにlocal::libを利用して依存モジュールを入れることができます

他にMySQLを監視したい場合は、DBD::mysqlなどを入れておくといいでしょう。

次に設定ファイルです。sampleをコピーして編集します

# 設定ファイル
$ cp cloudforecast_sample.yaml cloudforecast.yaml
# サーバ一覧ファイル
$ cp server_list_sample.yaml server_list.yaml


サンプル設定ファイル(cloudforecast_sample.yaml)の中身

---
config:
# gearmanを利用する場合、enableを1にして、germandのhost名とportを指定します
  gearman_enable: 0
  gearman_server:
    host: localhost
    port: 7003
# rrdのファイルを設置する場所。「/」から始まると絶対パスとなります
  data_dir: data
# 監視項目の設定ファイルを設置するディレクトリ。「/」から始まると絶対パス
  host_config_dir: host_config

component_config:
# SNMPでデータを取得する時のオプション。communityとversion
  SNMP:
    community: public
    version: 2
# MySQLを監視する場合のuser名とパスワード
  MySQL:
    user: root
    password: ""


サンプルサーバ一覧ファイル(serverlistsample.yaml)の中身

--- #Dev
# --- #Hogeと書くことでサーバ一覧を区切ることができます
# configはhost_config内の監視項目の設定ファイル名
# hostsは 「IPアドレス[space]ホスト名[space]コメント」です。コメント内にはスペースがあってもかまいません
servers:
  - config: basic.yaml
    hosts:
      - 192.168.55.10 dev1 develop
      - 192.168.55.11 dev2 develop

--- #Production
servers:
  - config: httpd.yaml
    hosts:
      - 192.168.51.10 web1 web memcached
      - 192.168.51.11 web2 web memcached
  - config: mysql.yaml
    hosts:
      - 192.168.51.60 db1 mysql master
      - 192.168.51.61 db2 mysql slave
      - 192.168.51.62 db2 mysql slave
  - config: basic.yaml
    hosts:
      - 192.168.51.90 batch1 batch


とりあえず、サーバ一覧ファイルを編集し、監視したいサーバだけにします。localhostをSNMP経由で基本的な監視を行うなら

--- #HOME
servers:
  - config: basic.yaml
    hosts:
      - 127.0.0.1 server1 my great server

となるでしょう。

localhostのsnmpdが設定されているとして(別途どこかで説明します)、巡回デーモンとWebサーバを起動します。

# 巡回デーモン。5分ごとにリソースデータの取得を行います
$ ./cloudforecast_radar -c cloudforecast.yaml -l server_list.yaml
# Webサーバ
$ ./cloudforecast_web -p 5000 -c cloudforecast.yaml -l server_list.yaml

巡回が2回ほど行われるとグラフの描画が始まります。ブラウザで確認できます。画像は自宅サーバで動いているものになります

サーバ一覧画面

serverlist.jpg

リソースグラフ画面

resourcegraph.jpg

カスタマイズはまたブログなどで説明したいと思います。今年のYAPC::Asiaはこのネタでしゃべりたい!
さっそく試してくれた nekokak++ tokuhirom++

nau.jpg

昨日tweetした通り、株式会社ミクシィを退職しました。正確には今月末までとなり、今は少ない有給消化期間です。次の会社は既に決まっていて、6月1日から新しい会社となります

ミクシィにはちょうど4年間在籍しました。その間mixiはPVにして10倍以上という驚異的な成長をし、会社としてのミクシィも上場をするなどさまざまな経験をさせて頂きました。

自分だけでやったことではなく、もちろん他のエンジニアの協力のもとで行ったことですが、4年間の間に自分のミクシィでやっていたことをBlog等ですでに紹介したものを中心にいくつか書くと

  • アプリケーションレベルでのDBのフェイルオーバ
  • Apache modproxybalancerの導入
  • デプロイツールの作成
  • サーバ設定のバージョン管理化
  • Squid COSSの検証導入
  • プロフィール画像などSquid CARPを利用した分散構成対応
  • Nginxの検証
  • Varnishの検証・導入
  • Nagiosの設定簡略化スクリプト
  • RSSクローラ
  • 各種rpmの作成と大量のモジュールのインストール方法
  • memcached周りのあれこれ
  • Q4Mの検証導入、非同期処理フレームワーク作成
  • リソース監視ツール(cloudforecast)

あたりが上げられます。この他にも

  • WEB+DB PRESSやSoftware Designでの執筆
  • YAPC::Asia 2008,2009での講演

などもさせて頂きました

4年間このような業務に携わってきましたが、今回、転職を決意した理由として、自分の技術のガラパゴス化を防ぎたいということがあります。どうしてもほぼ単一のサービスであるミクシィに運用も特化してしまい、技術の幅が広がらないのではないかという気がしています。そのためにもミクシィの外へで様々なサービスに触れたいと思っています。また、サービスとしての良い悪いではありませんが、自分がここまでやって来れたのはBlogやtwitterなどオープンなメディアがあったからであり、SNSよりもそのオープンなメディアを支えたいという考えもあります。

次の職場でも主な業務はかわらず、運用といった側面からサービスのスケーラビリティを支えていくことになります。これまでお世話になってきた方にはこれからもお世話になることとなると思いますが、よろしくお願いします