【悲報 5年後はおっさん】25歳になった

今日で25歳になった。 ここ数年Facbeookとかいうやつのせいで誕生日の印象が悪くなってるのはさておき、この1年はずっとサバッとか言ってた。 修了に失敗して社会人になったはずが、あまり生活に変化はない。 技術には集中できるようになった。 今の仕事はわりと楽しい。 こわいこわいとかいいながらスイッチオーバしたり、イミュータブルなんとかのゴミ掃除とかしたり、Chefに順番どおり実行してほしいとか祈願してたり、スラッシングしてるサーバみてシバ感あるとか言ってた。 5年後は30歳とか思うと未来がない。 25歳、もっとちゃんとしてると思ったが実体はこんなものだ。 とにかくおっさんになりたくない。 せめておっさん感のないおっさんになりたい。

ウィッシュリスト

追記

おっさんと年齢に関する話、下書きのまま放置されてた。

おっさんになりたくない話

最近、おっさんについての関心が高まっている。

まず、motemen さんが書いたおじさんパターン集っていう名エントリを引用する。

  • その面白そうな話、私も参加していいよね?なぜなら私は無条件に受け入れられているからおじさん(闖入おじさん) #おじさんパターン
  • 後出し難癖おじさん #おじさんパターン
  • 困難は成長のチャンス!だから君たちに成長の機会をあげようおじさん (成長おじさん) #おじさんパターン
  • あらゆる事案に一般論コメントおじさん #おじさんパターン
  • 俺ってあらゆることに精通してるじゃん?だから力になるよおじさん (精通おじさん) #おじさんパターン

他にも、

  • 古いものに固執して新しいものを根拠なく否定したがるおっさん。
  • 酒の場で酒を強要してくるおっさん。
  • 社会では通用しないとか言ってくるおっさん。

とかいろいろな最悪のおっさんがいる。 (ここでいうおっさんというのは、年齢的に30歳男性とか40歳男性とかそういうのではなくて、精神のあり方とか人の接し方がおっさんであるというぐらいの意味。)

そういうおっさんがいるのは怖くなくて、本当に怖いのは、自分がおっさんになってないかどうか。 そこで、おっさんパターンが役に立つわけだけど、どうすればおっさんにならないですむか考え続けてることになって後ろ向きでよくないし、おっさんパターンにあてはまらなかったからといってそれがよいかどうかはわからない。 オブジェクト指向のデザインパターンみたいなこれはよいパターンみたいなのがあるとよいと思っていて、ロールモデルとして尊敬できる人の真似をするのがきっと効果的。

なんでもいいからとにかくおっさんになりたくない。

Facebookの数千台規模のmemcached運用について

Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関する(多分)準トップレベルのカンファレンス。

  • Scaling Memcache at Facebook

Facebook のキャッシュシステムがどのようにスケールしてきたか、各スケール規模の勘所は何かについて書かれた論文だった。 内容はかなり盛りだくさんで、基本的なデータベースクエリキャッシュ戦略から、マルチリージョン分散の話まで多岐に渡る。 memcached に依存しない話も多いので、memcached というよりは、超大規模キャッシュシステムの運用例として読むのがよさそう。

論文概要

memcached はよく知られたシンプルなインメモリキャッシュシステムである。 論文では、memcached を基本単位として、世界最大のソーシャル・ネットワークを支える分散KVSをどのように構築し、スケールさせたかについて書かれている。 Facebook のキャッシュシステムは、秒間数十億リクエストを捌いていて、10億人を超えるユーザにリッチな体験を届けるために、数兆個のアイテムをキャッシュに保持している。

システムは、以下の4段階でスケールしてきた。 - 1. 数台のmemcachedサーバ - 2. 多数のmemcachedサーバを含むシングルmemcachedクラスタ - 3. マルチmemcachedクラスタ - 4. マルチリージョン

1. 数台のmemcachedサーバ

  • demand-filled look-aside cache 方式
  • 並列 memcache set 問題 (stale sets)
  • Thundering Herd 問題
  • memcache プロトコルの拡張 "leases"

2. シングルクラスタ

  • consistent-hashing
  • TCP incast congestion 問題
  • Layer 7でスライディングウィンドウでフロー制御
  • get リクエストは UDP にしてパケット減らす
  • 独自ルータを挟んでコネクション永続化

3. マルチクラスタ

  • フロントエンドクラスタ + ストレージクラスタ
  • 一貫性の保持
  • 全クラスタのキャッシュ無効化処理
  • SQL文に無効化キーを埋め込んでおきて、MySQLのコミットログをtailして埋め込みキーを無効化するデーモン

4. マルチリージョン

  • (フロントエンドクラスタ + ストレージクラスタ) x リージョン
  • リージョン間レプリ遅延を考慮して、キャッシュミス時にマスタDBをreadするかスレーブDBをreadするかマーカーをつける

Conclusion

  • キャッシュと永続ストレージを分離して、独立してスケールさせる
  • モニタリング、デバッギング、オペレーション効率を改善する機能はパフォーマンスと同じくらい重要
  • ロジックは stateless なクライアントに置くほうが混乱しない
  • システムは新機能の段階的なロールアウトとロールバックをサポートしなければならない
  • Simplicity is vital.

スライド

より具体的な内容はスライド参照。 相当はしょっているので、詳細な内容は論文参照。 はしょった内容については、後日ブログにするかも。

関連記事

感想

TCP incast問題を回避するために、TCPのスライディングウィンドウ的なロジックをアプリレイヤで実装していたりして、OSレイヤでの解決方法を大規模運用にあてはめてスケールさせているのが印象的だった。 仕事でそのロジックを実装するリソースを割けない、もしくはそもそもそんなスケール必要がないとかはあるにしても、話としては結構おもしろかった。 あと、memcached 自体には機能を追加せずに、クライアントサイドにロジックを入れていたのも気になるところだった。 Facebook はストレージにHBaseを使っている話 (The Underlying Technology of Messages)もあって、こっちはミドルウェアにロジックをもたせてたりするので、このへんの方針の違いも気になる。

関連記事にも載せてるけど、 https://www.facebook.com/publications で Facebook の出してる論文とか読めるので、いろいろ勉強になりそう。

ヘビーなGraphite運用について

"Monitoring Casual Talks #6"に参加して、「ヘビーなGraphite運用」についてしゃべってきた。 Graphite ここ数ヶ月ずっと運用してて、そこそこのリクエスト数さばけるようになるまでと冗長化の話をだいたいしてた。 Graphiteのパフォーマンス・チューニングで結構苦労してて、@sonots さんが発表されてた"GrowthForecast/RRDtool チューニング秘伝の書" がすごい参考になった。(Graphite(whisper) のデータ構造と RRdtool のデータ構造はよく似ている。) fadvise(2)とか知らなかった。 ぜひ試してみたい。

スライド

結構口頭で補足してた。Graphite 秘伝の書書きたい。

感想

今回の勉強会、かなり刺さる内容が揃っててよかった。 形式が30~100人くらいいて、数人の発表者がプレゼンするっていう感じじゃなくて、14人くらいで全員発表とかいう形式だったので、カジュアルに議論とかできてよかった。 あと、結構 Mackerel について言及していただいて関係者としては緊張感あった。 Nagios とか Zabbix の話は意外と少なめで Sensu とかあと、Docker のメトリクス収集とか、Auto Scale時のモニタリング方法とかの議論があって、みんなモダンなことにチャレンジにしててすごい。 また参加したい。

関係ないけど、今週 Docker 1.0 がリリースされて、Dockerそのもの + 周辺ツールが充実してきた感があるので、今回と同じような形式の Docker Casual とかあったらよさそう。

会場の提供/準備をしていただいた @takus さん、@sonotsさん ありがとうございました。

Mackerel を使ったサーバメトリクス可視化の背景っぽいやつ #可視化

可視化ツール現状確認会 on Zusaar

可視化ツール現状確認会で Mackerel-Based Server Metrics Visualization とかいう話をしました。 僕はアルバイト入社したときからサーバ管理ツールにずっと関わってて、周辺ツールとかもウォッチしてて、そういう流れで Mackerel がどういう位置づけにあるかみたいな話だったはず。

かつて自作社内サーバ管理ツールで、RRDtool の最悪の引数をURLクエリで互換するようなパーサ作ってたりして、異常な努力をしていましたが、ここ半年くらいで、モダンな Graphite とか Sensu をサーバ管理ツールと組み合わせようとしていて、気づいたら https://macekrel.io っていうサービスができてたという感じです。 Graphite と Sensu(Collectd) を導入しようとそれはそれで運用が思ったより面倒で、パフォーマンスがでないとかモニタリング用のサーバを用意したくないというようなことがあってかけた労力に見合わないという感じなら普通に Mackerel 使うと便利。 あと、サーバのIPアドレスとかホスト情報とサーバメトリクスビューが分散している場合(Munin と AWS consoleとか)に、統合管理するために Mackerel 使ってもらうのも便利。

ちなみに読み方はマケレルではなくてマカレル(英語読みはマッカレル?)っぽい。 なんでもいいけどとにかく RRDtool を使うべきではないと思います。

資料

軽くロードマップみたいなものも書かれています。 もうちょっと突っ込んだ使い方とか何ができるのかみたいな話は来週のモニカジで喋れたら良さそうです。

会場の提供、準備、運営をしていただいた Voyage Groupの皆様ありがとうございました。

インターネットの様子

DockerとS3を用いた、yum / apt リポジトリ作成・運用の継続的インテグレーション

Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ の続き。 前回は、rpm / deb パッケージを作るために、CentOS、Debianなど各種ディストリビューションを揃える手間をかけずに、Docker コンテナ上でパッケージングして、ついでに Jenkins で CI するみたいなことを書いた。

今回は、作成したパッケージを yum / apt リポジトリに登録して yum / apt コマンドでパッケージインストール/アップデートできるようになるまで継続的インテグレーションするという話。

問題点

  • yum / apt リポジトリ用の専用ホストを立てて、そこで apache とかで静的ファイルをホストするのはめんどくさい。
    • 特に、mackerel-agent みたいなユーザにインストールしてもらうパッケージの場合、リポジトリを公開しないといけなくて、冗長化とか面倒はさらに増える。
  • リポジトリ作成のために必要なメタファイル群を作成するために、createrepo や reprepro コマンドがインストールされた環境が必要となる。
    • OSX とかではインストールできない。(がんばったらできるのかもしれない)

Docker と S3 で解決

  • yum / apt リポジトリ用の専用ホストを立てて、そこで apache とかで静的ファイルをホストするのはめんどくさい。

前者については、S3 に静的ファイルをアップロードすることにより、サーバもたなくてよいので簡単。 手順は簡単で、S3のWebコンソールで適当にバケットを作って、createrepo または reprepro で作成したファイルをs3cmd とか aws-cli でバケットにアップロードする。 バケットには、bucket-name.s3.amazonaws.com. のようなエンドポイントがつくので、各ホストで リポジトリの設定を書くだけ。

さらに、Jenkins で master ブランチが更新されたときにパッケージの作成と同時に S3 にアップロードすることで、勝手にリポジトリに最新パッケージが入るので便利。今触ってるのは一般公開する代物なので、リリースは慎重に手でやってるけど、社内リポジトリとかならJenkinsで自動化したらよさそう)

  • リポジトリ作成のために必要なファイル群を作成するために、createrepo や reprepro コマンドがインストールされた環境が必要となる。

手元は OSX でも、Docker 上の各ディストリビューションでディストリ依存な createrepo や reprepro をインストール・実行できる。

ディレクトリ構成と Dockerfile

  • ディレクトリ構成 (yum)
tree -a
.
├── .s3cfg
├── Dockerfile
├── files
│   └── mackerel-agent-x.x.x.noarch.rpm
└── macros
  • ディレクトリ構成 (apt)

  • Dockerfile (yum)

# docker build -t 'hatena/mackerel/yum-repo' .
# docker run -t 'hatena/mackerel/yum-repo'

FROM centos
ENV PATH /usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin
RUN yum update -y
RUN rpm -ivh http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
RUN yum install --enablerepo=epel -y createrepo s3cmd

RUN install -d -m 755 /centos/x86_64
ADD files /centos/x86_64/
RUN /usr/bin/createrepo --checksum sha /centos/x86_64

ADD .s3cfg /.s3cfg
WORKDIR /centos/
CMD /usr/bin/s3cmd -P sync . s3://yum.mackerel.io/centos/
  • Dockerfile (apt)
# docker build -t 'hatena/mackerel/apt-repo' .
# docker run -t 'hatena/mackerel/apt-repo'

FROM tatsuru/debian
ENV PATH /usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin
ENV DEBIAN_FRONTEND noninteractive

RUN apt-get -y update
RUN apt-get -y install reprepro s3cmd
RUN apt-get clean

RUN mkdir -p /deb
ADD files /deb/
WORKDIR /debian
RUN mkdir -p db dists pool
ADD conf /debian/conf
RUN reprepro includedeb mackerel /deb/*.deb
RUN reprepro export

ADD .s3cfg /.s3cfg
CMD /usr/bin/s3cmd -P sync . s3://apt.mackerel.io/debian/

リポジトリの設定

独自リポジトリなので、インストール先ホストではリポジトリを設定する必要がある。 yum / apt で、それぞれ次のように設定するとよい。

  • yum の場合

/etc/yum.repos.d/mackerel.repo

[mackerel]
name=mackerel-agent
baseurl=http://yum.mackerel.io/centos/\$basearch
  • apt の場合
echo "deb http://apt.mackerel.io/debian/ mackerel contrib" >> /etc/apt/sources.list.d/mackerel.list

所感

Docker または Vagrnat を使うと、いちいちディストリビューション環境用意しなくてよいし、余分なサーバをもたなくて済む。 これは、Virtualbox や VMware で仮想ホストを立ち上げても同じだけど、Docker や Vagrant は CLI で操作できてプログラマブル(特に Docker はREST APIがある)なので、自動化しやすい。 さらに、Docker なら毎回クリーンな環境からリポジトリを構築しやすいのでゴミが入りにくいというメリットがある。 (Vagrnat でもできるけど、壊して再構築するのに時間がかかる)

前にも書いたけど、Docker 使うと、今まで特別な環境でしかできなかったことを気軽に手元でできるようになったりする。 Docker が Immutable Infrastructure 専用の何かみたいに言われることがあって、結局まだそんなにうまく使えないよねみたいな話あるけど、用途はいろいろあると思う。