エンジニアの僕が三軒茶屋で写真を存分に使ってmcrouter

はい

---

突然こんにちは！
巷でジャック・ニコルソンの偽物をさせて頂いている@kakerukaeruと申します。

おれやで

— ジャック・ニコルソン (@kakerukaeru) 2014, 12月 20

CyberAgent エンジニア Advent Calendar 2014の20日目を書かせていただきます。
昨日は僕の敬愛する先輩である@strskさんのpt-online-schema-changeを安全につかう - Around the Worldでしたね、皆さんチェックされましたでしょうか。
そして、明日は@k66dangoさんの予定です。

というわけで

---

記事に移ります。

AdventCalendarにはMySQLかCI関係の何かと告知をしていましたが、
この前のMySQL Casual Talks vol.7で上の奴は少しお話してきてしまったので、
せっかくだから違う記事にしようと思います。

で、何を書くかというと
Facebookが今年の9月ぐらいに発表したmemcachedをクラスタ化してくれるmcrouter
上の公式ブログに書いてあるのですが、

• memchaced ASCIIプロトコルサポート
• コネクションプーリング対応
• マルチクラスタ対応
• ヘルスチェック＆自動フェイルオーバー
• 新規node追加時のcacheのウォームアップ
• etc..

などなど、上げていくとキリがないほど魅力的な機能が紹介されている。
なんと最高で秒間50億のリクエストも捌いてたんやでという逸話つき。

ほんまかいな。
ということで、動作検証から性能検証までを行っていく。

その前に

---

エンジニアたるものやはりお酒を飲まないと検証が捗らない。
まずはオフィスがある渋谷を離れ、弊社の社員さんもいっぱい住んでいると噂されている三軒茶屋に移動します。

１軒目は先輩におすすめしてもらった
赤鬼 （あかおに） - 三軒茶屋/居酒屋 [食べログ]

お店の外観はこんな感じ。

えー感じの空気が漂ってますね。
しかし残念ながら満席。
あかん、、、
お酒がないと捗らへんのや、、、
次に、移ります。

２軒目は
ほしぐみフライドキッチン - 三軒茶屋/串揚げ・串かつ [食べログ]

三茶のゴチャゴチャした三角地帯にあるお店。
気軽に入れて結構リーズナブルなのが好き

お店の提灯にもドドンと発表しちゃうぐらいおすすめの、
塩煮込みと柚子胡椒トーストは絶品。

発表？
発表といえばこの前LTをした時に使ったDecksetって便利だったなー(棒

ふぅ、お腹いっぱい。
しかし、お酒はそんなに飲んでない。
次行こうか。

３軒目は、
富士屋本店グリルバー - 三軒茶屋/立ち飲み居酒屋・バー [食べログ]

お肉とワインがオイシイ立ち飲みのお店。

元々釣り堀だった所を改装したらしいよ。

お腹いっぱいになってきたからチョットお腹に優しい物食べよか

優しい？
優しいといえば、ハード周り情報を拾うのコマンド纏めてみた
これで急にサーバの保守を依頼された新人さんも安心だー(棒

おいしい幸せ。
しかし、ワインも２杯ぐらいしか飲んでない
これじゃ、本気出せない

４軒目、
やっぱり日本酒が飲みたい
采 （サイ） - 三軒茶屋/立ち飲み居酒屋・バー [食べログ]
またまた立ち飲みのお店。

お通しからの鳳凰美田。
おいしい。

日本酒入ってる冷蔵庫撮っていい？
ッて聞いたら快くOKしてくれた。多謝

日本酒大好き。
こういう所はみんなに教えたいけど、本当は秘密にしておきたい。
e,秘密？
秘密といえば、最近ようやくdata_bagの暗号化を始めたなー(棒

そろそろ気分がノッてきた。
今なら検証も出来る気がする

５軒目、
アルフヘイム （ALFHEIM） - 三軒茶屋/バー [食べログ]
個人的に一番行ってる店

写真撮っていい？と聞いたら
キメ顔してくれた、優しい。

クラナドというカクテルを注文した。
店主がクラナドというアニメが好きで作ったらしい。
新卒の子にクラナドを見たことがないと告げたら「岩永さん、人生楽しんでますか？」と壮絶にdisられた事を思い出しました。

もうフラフラ
最期は店主の決めポーズでさようなら

ふぅ

---

とってもいいツアーでした。
三軒茶屋はまだまだ他にもいっぱい良いお店があります。
是非飲み歩いてみては如何でしょうか。
弊社社員にばったり遭遇しちゃうかもしれません。

そろそろちゃんと検証記事を書かないと運営に怒られそうだし、
末代までクズエンジニアの烙印を押されそうなので家でPCを開いて本気出して書いていきます。
おっとこんな時間に誰かが来たようだ。うわ、何をする やめr

最期に

---

ここまで読んでいただきありがとうございました。
辛い道のりを乗り越えた皆さんに、弊社自慢のIT芸人 より２つ目のキーワードの発表です。

おわり

MySQL Casual Talks vol.7で「Continuous Restoreへの道」を発表奴

タイトルの通りだけど

MySQL Casual Talks vol.7でお話してきた。

MySQLのbackupはみんな取ってると思うけどそのBackupって本当にRestore出来るのかなーという不安からRestoreを検証してくれる仕組みを作ってみたというお話　　

発表資料はこれ

実は発表の二日前にようやくちゃんと全部のjobが綺麗に動いたんだけど、
何故かその段階で、もう大丈夫っしょ！(・。・)となってしまい、
実際に全部のjobを連結させて一連の流れが見えるようになったのは、
なんと発表当日会場入りの30分前という体たらくっぷり。

なので、資料の途中に書いてある実際の運用ではとかのくだりは、あくまでもそういう予定である。
みたいなかんじになってしまった。なんか今思うと詐欺みたいだなｗ

発表にあたって

実は人前で何かを発表するみたいな経験に乏しく、
発表当日は緊張しすぎて雨に濡れた子犬みたいになってた。
発表までにカジュアルウォーター３本ぐらい空けてしまったし

あと緊張のあまり大阪弁で発表してしまい、
「バァーンってBackup取ってー」
「バァーンってinstance作ってー」
「バァーンってRestoreしてー」
「バァーンってRestoreのcheckしますー」
みたいな感じで擬音語を多発したことにより、
バァーンの人みたいな認知のされ方をしたのは今となってはいい思い出です。

謝辞的な

この場を借りて的なお話を。

まず@namikawaさん
引きこもりがちな僕に発表の機会を与えていただきありがとうございます。
とってもいい経験になったし、もっと外に出てアウトプットしていかなきゃなと思える一日でした。
あと、発表の後の開放感からお酒を飲み歩いてベロンベロンになってしまった僕の代わりに夜間の障害対応をしていただき本当にありがとうございました・・・:(；ﾞﾟ'ωﾟ'):

そして、発表練習＆内容の相談に付き合ってくださった@kuwa_twさん、@dblmktさん、@kakky_hさん、@nekoruriさん本当にありがとうございます、資料当てをしてなかったら多分会場で死体が出来上がってました。
特に@kuwa_twさんは資料にも出演していただき本当にありがとうございます＾＾

あと、発表の時に@oranieさんを壮絶にdisってしまいましたが
いつもお世話になっております、本当にありがとうございます＾＾；

おわり

最近の私のchef周りの事情

どうやら台風が来るらしい。
台風にえしゃこらされて頑張ってる雨の音を肴にビール飲みながらブログ書いてる。
台湾ビール旨い、そしてフラフラする

んでまぁ、
事務職をドロップアウトしてインフラ周りのお仕事に戻って二ヶ月ぐらい。
サーバ管理ツールとしてchefをまた使い始めた。
chef周りのテストとかの運用ってどうするべきなのかなーと悩んだりしているのだが、現状のところを纏めてみる。
どうしたもんかなー

使用しているツール

• chef-solo
• Berkshelf
• Vagrant
  • sahara plugin
• serverspec

こんな感じ。

今まではchef-serverを主に使っていたのだが、
chef-serverじゃないといけない理由もないし、
触ってみたこと無いやっていうモチベーションでchef-soloを使い始めた。

Berkshelfも依存関係管理すんのメンドイな、とか使ったことねーなーというモチベーションで始めた。
てか、意外とcommunityのcookbook使ってるのよね、最近。
まぁ、使ってみたら意外と便利。

Vagrantは完全にテスト用。
後述するが別にvirtualboxでもワンチャン実現可能じゃね？って言われそうな用途で使用しているが、
sahara-pluginが便利でVagrantに落ち着いている。

serverspecは最近使い始めた。
chef適用後の構成管理もちゃんとしたいなと思い使い始めてみた。あと、chefで管理してない部分とかね。
LDAPやら、NICやら、

なんだけど、今のモダンなchef周りの運用ってどんな感じなのかしら。
ダレか教えてよ（適当

おまけ

今のchefのテスト環境を作るに至るまでに辿ってきたページ。

chef-solo - Chefを読んで実行するための全知識 - Qiita
Cookbookの管理を楽にするBerkshelfの使い方( ｰ`дｰ´)ｷﾘｯ とか。 - 256bitの殺人メニュー
saharaでVagrantの状態管理 - Qiita
serverspec インフラ層のテスト項目を考える | Ore no homepage

すごいわかりやすいです、いつもお世話になってます。

おまけ２

vagrantのメモ

chefのテストはvagrantを使用している。
社内用に少し改良したvagrantboxを使用しているがそれ以外は特別なことはしていない。
vagrant upする時にchef_soloを走らせてもいいのだが、chefのレシピのテストでいちいちup＆destroyを繰り返してたら時間がいくらあっても足りない、のでsahara_pluginを使って以下のように実行している。

# cd Vagrant用のディレクトリ
# vagrant ssh-config >> ~/.ssh/config
# sed -i 's/Host default/Host kakeru_vagrant/' ~/.ssh/config
# cd hogehoge/chef-repo   #chefのRepositoryに移動してね
# knife solo prepare kakeru_vagrant
# knife solo cook kakeru_vagrant
# vagrant sandbox on
# vagrant sandbox commit

# テストしたいレシピを実行

vagrant sandbox rollback #初期状態へ

ssh kakeru_vagrantでノンパスログイン出来るように、ssh_configを書き換えておく。
その後に、どのサーバにも適用するようなbaseのレシピを適用した後にcommit。
そしたら、作成中のレシピを当てて、ミスったらrollback、修正して適用、rollbackみたいな感じ。

おまけ３

chef-soloがんばるぞ～って矢先にchef-soloやめっからって公式が言い出したみたい。
Chef-Soloはオワコンになりlocal modeが今後の主流になるとのこと - DQNEO起業日記
あらまぁ。

hoge

なんか日記みたいなブログやな・・・

出、出〜、homebrew-cask便利奴〜ｗｗｗｗｗ

なんというか、会社で所属チームが変わった。
そして、変わった瞬間に夏休み突入した。
今治なう。orionビール片手に記事を書いてる。

なんでまぁ、良い機会だからアウトプット増やす的な意味でちゃんとブログ再開する。
リハビリで手順書記事。

経緯

先日新卒の頃に自作したWindowsPCを墓地に伏せ、会社支給のMBPを召喚した。
障害対応用に前から持ってたMBAもそろそろクリーンインストールしたいなーとか考えてたから、
この際Macの初期のセットアップをちゃんと手順化したいなーとか思ってた。
そしたら、homebrew-caskなるものが便利という噂を聞いた。なんで使ってみた( `o´ )
https://github.com/caskroom/homebrew-cask

homebrew-caskってなんなん

homebrewみたいな感じでdmg形式のアプリも管理出来るらしい。
マジか！

導入

# homebrew入れてね
$ ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

# cask導入しよか。
$ brew tap caskroom/cask
$ brew install brew-cask

cask使ってみる

Mou - Markdown editor for web developers, on Mac OS X 入れてみよか

# 入れたいアプリあるかなー
$ brew cask search mou
==> Exact match
mou ...
# あった入れてみる
$ brew cask install mou

これで入る、うげー便利。ゲロ吐いた

もっと管理する

brewfileで管理するとモットいいと思う

brewfileやで
こういうのを用意しといて

$ brew bundle Brewfile

すれば、上記のアプリが勝手に入る
うげー便利。鼻血吹いた

出、出〜、ELBSSL証明書奴〜ｗｗｗｗｗ

早くこの形式のタイトルから脱したい
【たまごELBSSLかける】
【ELBにSSL証明書かける】
とか。なんでもいいけど。

で、
ELBにオレオレ証明書を突っ込んだ時の手順書が掘り出されたのでブログにも書き残すことにした
今年はいっぱいブログ書くねん....('A`)

証明書的な云々

証明書ってなんなんとか、オレオレ証明書ってどうやってツクんの？とかは人様のブログを参考に・・・
オレオレ証明書をopensslで作る（詳細版） - ろば電子が詰まっている

CSRを作るまで

秘密鍵作るで〜

作る
$ openssl genrsa -aes128 2048 > server.key
Generating RSA private key, 2048 bit long modulus
...................+++
...................................+++
e is 65537 (0x10001)
Enter pass phrase:
Verifying - Enter pass phrase:

確認
$ openssl rsa -text < server.key

ELBは秘密鍵にパスフレーズがついていたらエラるので、パスを削除してあげる

$ openssl rsa -in server.key -out server.key
Enter pass phrase for server.key:
writing RSA key

CSR作成
今回はオレオレ証明書でやってみるので、対話形式で色々聞かれるけど今回は全部空Enterでかまわないす。
もし、ちゃんと認証局に依頼をするならここでちゃんと記入してね

作る
$ openssl req -new -key server.key > server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
以下略

確認
$ openssl req -text < server.csr

で、本来なら出来たcsrを認証局に投げて、証明書をもらう。
でも、今回はオレオレなので、それも自分でやる

証明書

自分で署名して証明書つくんで〜

作る
$ openssl x509 -req -signkey server.key < server.csr > server.crt
Signature ok
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Getting Private key

確認
$ openssl x509 -text < server.crt

設定すんで〜

AWSのマネジメントコンソールから
create Load Balancerをぽちっと押して、

こうやって

こう！

Private Keyが
$ cat server.key 

Public Key Certificateが
$ cat server.crt

やで〜。

ほなな〜ノシ

出、出〜、mongos接続突然切奴〜ｗｗｗｗｗ

なんというか、ただの恥さらしブログになんだけど自戒のために残しておく。

なんかおかしい

ある日、本番稼働してない控えのmongosさんで変なエラーが出てアプリでもいっぱいエラーが出てきた。
なんかオカシイ。
エラー的には下記

Tue Nov 26 18:20:47.294 [conn88] Socket say send() errno:32 Broken pipe 10.10.10.10:27018
Tue Nov 26 18:20:47.294 [conn88] warning: problem while initially checking shard versions on RS01 :: caused by :: socket exception [SEND_ERROR] for 10.10.10.10:27018
Tue Nov 26 18:20:47.294 [conn88] DBException in process: socket exception [SEND_ERROR] for 10.10.10.10:27018

Broken pipe....?
mongos->mongodの接続が切れてる... ? _ ?

調べる

最初は単純にBroken pipeだからネットワーク的な問題かなと思い、
トラフィックが急にオチてたりethとかで変なエラーが出てないかを見たがそれっぽいものは特に何もナシ。

connectionsが頭打ちになってね？となり
そこ周りで調べてみることにした

mongodのプライマリシャードのconnectionsを確認してみる。
900ちょっとで停滞・・・？

実際にログインしてプロセス数を確認してみる

ec2-user@prd-mongod001(ip-10-10-10-10) ~
$ ps auxxx -L | grep mong | wc -l 
931

設定値は？

$ ulimit -u
1024

ﾃﾞﾌｫﾙﾄ･･･(´ｪ`* ;;;)

すごくそれっぽい

作業

mongoさん優しい。ulimitの推奨値書いてた
http://docs.mongodb.org/manual/reference/ulimit/
ulimitの説明とかも書いてくれてるしなんて親切なの・・・

実際に、作業にはいる

vim /etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
#*          soft    nproc     1024

こっちをコメントアウトして、

vim /etc/security/limits.conf 
追記
root    soft    nofile  64000
root    hard    nofile  64000
root    soft    stack   unlimited
root    hard    stack   unlimited
root    soft    nproc   32000
root    hard    nproc   32000
*       soft    nofile  64000
*       hard    nofile  64000
*       soft    stack   unlimited
*       soft    nproc   32000
*       hard    nproc   32000

プロセス再起動

$ cat /proc/`pgrep mongo | head -1`/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            unlimited            unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             32000                32000                processes 
Max open files            64000                64000                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       13087                13087                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        

反映された
エラーも消えた。

実際の作業はchef流して、各mongo鯖のプロセスを再起動。
一応全てのmongoを１台ずつ再起動していったから、メンテに入れること無く作業は終わりました。
こんな所まで管理できるのもちょっと怖いね

感想

今回のサービスがAWS上で０から環境を作るというものだったのだが、
今まで社内の環境でKickstartとかでデフォルトで入ってた用意されたインフラ的なものにいかに助けられてたかという事を痛感した。
もっかいちゃんと読んでみよう。

おまけ１

mongod側のconnectionsをちょっと広い期間で見てみる。
（間にconnectionsが０にまで下がってるのは、僕がmongoのメモリリークのバグを踏んでサービスメンテ状態を２回引き起こしたからです、ごめんなさい死にます）

本当に今になって思えばなんだけど、
このグラフの期間で増設をしてmongosの台数が約2.5倍になったのに
mongodのconnectionが500 -> 900しかいかないなんて単純に考えてオカシイ

ちなみに、その後ulimitの変更を全ての鯖に適応したら

1200近くまで上がりました(′ʘ⌄ʘ‵)

おまけ2

ulimit適用してもOS再起動時に反映されてないんじゃないの？
【参考】http://blog.father.gedow.net/2012/08/08/ulimit-configuration/
といろいろ不安になったが、そもそも起動スクリプトにulimit書くとか以前に、起動ユーザーのulimitの値を引き継いでプロセスが上がってくるから、そんな心配はいらなかった
実際、試してみたら実行ユーザのulimitで上がってきました。

おまけ???

max processes1024
やんけ！と発見した後に、ulimitが原因だったと他に示す証拠が出てこなかったので、ステージング環境でmax processesを125とかにして再現するか試してみたらmongod自体が死んでテストにならなかった。うふふ
結局500ぐらいに変えて再発した。ので本番にも適用することにした。
状況証拠を集めみたいになってしまったが、今思えばmongodとかもログレベル上げてみれば良かったんや。

isucon2013で生き恥をさらした話

結果

予選敗退＾ｐ＾

多分技術的には読んでても面白く無いとおもう

なんせ何をチューニングしたのと言われても、
途中から何をどうしたか分からん状態に陥ってたから。

• そもそも当日の朝に全員集合して言語何にする？とか選ぶ体たらくっぷり。
• 僕遅刻しましたし
• とりあえず、PHPでベンチ動いたからPHPにすっか(死ね)
• とりあえず、ベンチ動かしてmysqlがボトルネックっぽ(適当)
• とりあえず、インデックス貼ってみるか(適当)
• innodb_Memcachedってなんぞ(適当)
• とりあえず、countとか別にもたせたらいいんじゃね(適当)
• 全件取りに行く奴、キャッシュさせろ(適当)
• apacheでもキャッシュさせるか(適当)

とか、もうこんな感じですよ。
分担とかは特にせず、これボトルネックっぽくね、どうやったら解決できる？って全員が口出して解決しようとしてたのは逆に良かったのかな・・・？

悪かったこと

何よりも事前準備が足りなかった。
そして、ただただ自分の知識の無さを痛感した。
これ何？何に使っててどうやって動いてんの？みたいな。

良かったこと

自分がウンコカスだと改めて自覚した。
そして、モチベーションが何故か上がったこと。
自分と予選突破一位の人たちと、８倍強の差が開いてたけど、自分もあんな人達にみたいになりたいと純粋に思えた。
また再挑戦したい。

余談

予選敗退の日のお酒は本当に美味しかったです（悲しい）