カラカニのメモ帳の最新の日記

こんにちは。ほぼ1年に1回しか日記を書かないkarakaniです。重い腰がようやく上がり日記を書いてます。

#isucon 行ってました。@mutotaiju と @3xv とで善戦してきました。準優勝で入賞でした。

まとめと反省点

• 地道なボトルネックの調査は重要。
• 時間的な制約がある中で新しいことはやらないほうがいい(最近使い始めたGitを使おうとしたけど無駄に時間使った)
• 経験も重要(他のチームのブログ見ててとても参考になりました)

やったこと

次のことをしました。

1. アプリケーション(データベースへのアクセス)のパフォーマンスアップ
2. 静的コンテンツの扱い・リバースプロキシの設定
3. キャッシュ戦略(失敗)

キャッシュ戦略は中途半端、というかできませんでした。

データベースはデチューニングされているのでは？ という声がありましたが、私たちのチームではほとんどチューニングはしませんでした。ただ設定ファイルを見る限りデチューニングされているかもしれないというのは薄々感じてました。感じてたレベルですが。

1. アプリケーション(データベースへのアクセス)のパフォーマンスアップ

• 昔使ったプロファイラでクエリ解析してみた
• JOINを使った超遅いクエリがある。EXPLAINの結果も良くないし、頻出クエリのレスポンスに0.3秒は致命的。
• なのでカラムを追加し、JOIN無しでデータを取得できるようにした。

テーブルはarticleとcommentの2種類しかなく、データ量も数千件？程度だったのですが、articleの最新コメントに応じて取得する、というクエリでインデックスが適切に使われていなかったため、articleのカテーブル構造を変更し、 JOIN無しで取得できるようにしました。

この変更は他のチームでも行われてたので常道なのかもしれません。

-- 元のSQL
SELECT a.id, a.title
	FROM comment c
	INNER JOIN article a ON c.article = a.id
	GROUP BY a.id
	ORDER BY MAX(c.created_at)
	DESC LIMIT 10;

-- スキーマの変更
ALTER TABLE article ADD COLUMN last_comment_at timestamp;
ALTER TABLE article ADD INDEX (last_comment_at);

-- 既存のデータへの変更の反映
-- 記憶を呼び起こして書いてるので間違ってるかも…
UPDATE article AS a SET last_comment_at = (SELECT created_at FROM comment AS c WHERE a.id = c.article)

-- 変更後のSQL
SELECT id, title FROM article ORDER BY last_comment_at DESC LIMIT 10;

最初の数分はクエリの投げ方だけで対応できるのではないかと思ったのですが、アプリケーションの規模を見る限り、コメント、記事の投稿が行われるポイントを把握することは簡単だったのでカラム追加で対応することにしました。

今思えば、別チームでトリガを使うほうがスマートな方法だと思いました。(もっともトリガの使用は実運用では賛否両論になるという話を聞いたことがありますが、それは仕様如何の問題でしょう。)

2. 静的コンテンツの扱い

• リバースプロキシ(以下リバプロ)は単純にリバプロしかしていない
• なので、アプリサーバーまでリクエストが届いている静的コンテンツをフロントのリバプロで返すようにした
• ついでにApacheをNginxに変更しようとしたが、諦めた

難なく静的コンテンツへの切り替えは出来たのですが、httpdからNginxへの置換えを行ったところ、パフォーマンスが落ちるという問題に直面。

直感的にKeep Alive周りで不具合を起こしているのではないかと思ったのですが、"リバプロ-アプリサーバー間"のKeep Aliveが機能していないせい(Nginxをプロキシ動作させる場合にはHTTP/1.0で動作しKeep Aliveが動作しないことを知っていました)と勘違いしたため、フロントエンドのKeep Aliveで主催者の罠が仕掛けられてるせいだとはわかりませんでした。

ちなみに、その後の作業中の調べでわかったのですが、そもそもアプリ側がもともとKeep Aliveに対応していないことがわかっていたので、もっと調べを進めても良かったのではと反省しました。
アプリの起動オプションに "--disable-keepalive" というのがあったので単純に外してみたのですが、上手いこと動作しないっぽいのでアプリ側のKeepAliveはずっと無効のままだったようです。

3. キャッシュ戦略(失敗)

何処にキャッシュ入れよう？

1. データベースでのクエリキャッシュ
2. アプリでのデータベースからのデータの取得時のキャッシュ
3. アプリでのHTML生成後のキャッシュ
4. リバプロでのキャッシュ

• アプリの調べを進めたが、結局何処にもキャッシュ入れられなかった。

1番目のデータベースのでクエリキャッシュは他のチームのブログを見て思い出しました。が、キャッシュの場所としては奥深くすぎるかなと思いあまり考えてませんでした。

2番目のデータベースからのデータ取得時のキャッシュはどのチームも考えてたことだと思います。が、他のチームもここでキャッシュをするだろう＆HTML生成コストも減らしたい願望があったので、2番目のキャッシュ場所に加え、3番目のHTML生成場所でのキャッシュも考慮に入れて調査をしました。

4番目のリバプロでのキャッシュは、今回の「POST実施後、1秒以内にコンテンツに反映する」という条件に適合できるかどうか確証がなかったので全く考慮に入れてませんでした。
確かに今回のトップチームの結果を見ると、結果が明らかなようで、キャッシュメカニズムの動作の調査にそんなに時間もかかるものではないため思い込みだけではなく地道に調査をしとくべきだったというのは今回の反省点の一つです。

結局、キャッシュ機能は動作させることができず、導入できませんでした。

DBサーバーが3台目のアプリサーバーに

ところで、「キャッシュ機能を有効にした場合、データベースサーバーってほとんど仕事してないよね」という話題になり、「じゃあ、データベースサーバーもアプリサーバーにしたら早いかもね！」ということでデータベースサーバーもまさかのアプリサーバーとして動作させることにしました。

今回のような構成の場合に実環境でそんな事するのか…という疑問も湧きますが、仮想サーバーの導入目的の一つに資源の有効活用というのがあると思います。実際の仮想サーバー上ではこんな構成にはならないと思いますが、今回の様に資源の有効活用をするというのは大切な事だと思います。なので今回のような構成には目をつむって良いと思います。。

結局のところ、アプリキャッシュはうまいこと行きませんでしたが、一番最初のDBアクセスの部分の対応でDBサーバーの負荷は十分下がっていたので結果として高速化にはつながっていたのだと思います。ここを考慮すると2位になったのはまぐれ的な要素があるのではと自身がなくなります。

他に考えていたこと・試したこと

同時接続数

• Perlアプリのプロセス数は初期設定では10プロセス/サーバー
• テストスクリプトの同時接続数は10だった
• 最終評価時にそれなりに同時接続数を増やされると死ぬと思った

なのでプロセス数は100に変更し、バックエンドのMySQLサーバーの最大同時接続数も200超にしておきました。メモリ消費はPerlのコード数も大きくないし、データベース上のデータサイズも大きくないので、おそらくそんなに問題ないんじゃないかなと思っていました。
結局、この対応は必要ありませんでした。

負荷状況の計測

• topとvmstat、netstat使って負荷状態を調べたりステータスを確認してました
• 用意されたグラフは実は粒度が低かったのであまり見てませんでした…
• 目の前の「いんふらえんじにあー」チームさんのプロジェクターが羨ましかったです

これから反省会する

とりあえず、 @mutotaiju と @3xv とで反省会としてAWSでもう一度 #isucon アプリの高速化に挑戦しようと思っています。反省会終わったらまた結果を書きます。

最後に

主催していただいたlivedoor技術部会様、参加された方々、ありがとうございました。
楽しかったです！ また機会があったら参戦します！

久しぶりに映画を観てきたよ。二本立てで。

• the social network
• Wall Street

ソーシャル・ネットワーク

うーん… 微妙。地上波で放送されるときには30分位にカットされて放送されるんじゃないか。
今話題のFacebookを取り上げました、半分実話です！って感じの内容ですが、話題性に便乗して作ってしまった感の強い作品です。

エンターテイメントとしてみても、史実映画としても中途半端すぎてどうしようも無いです。

ディスカバリーチャンネルかヒストリーチャンネルのリメイクに期待したいです。

綿密な取材をしたそうですが、Facebookには取材を断られたというのを小耳に挟みました。(ググッてくると出てくる話しだと思います)

マーク・ザッカーバーグはこの映画を嫌ってるわけではなさそうです。ググると出てきますが、主役のジェシー・アイゼンバーグとマーク・ザッカーバーグが一緒にテレビでてます。

Wall Streat

楽しかったです。金融用語というか金融商品や用語に慣れてないと90%位何言ってるのか分からないかもしれません。それでもエンターテイメントとして楽しかったです。
金融市場に疎くても誰が悪者、誰が主役なのかはわかります。が、何入ってるのか理解しようと思ったら一度、これを機会に金融商品を買ってみても良いかもしれないです。

マイケル・ダグラスかっこいいね。渋い。

ってか、なんでここでチャーリー・シーン出てきたんだよ、ピヨピヨ言ってるご老人って何？とか思って今調べてたら、この作品、同名の87年の映画の続編らしい。

予告編で言ってくれればレンタルで借りてきて見てたのに。

こちらも昨今の金融危機に乗じて作りました！！ って感じの作品ですが社会背景を反映した作品で良いのではないでしょうか。

（誰もそんなに評価してないと思いますが、映像の雰囲気が好きでした。1年に1回映画を観ればいいくらいの人間がつぶやくものすごい個人的な独断と偏見の評価ですが。）

という感じでした。久しぶりに日記書いてみました。

二つの作品を観て勝手に感じたのは、新興企業って大切だなってことです。
また明日から頑張ろう。

ということで、こんにちは。カニです。

なんだかんだでゴダゴダしていた生活から抜け出し？ ようやく日記を再開してみました。

ちょうど1か月前に引っ越しし、蒲田から高円寺に移り住みました。有言不実行の生活にかかわらず、引っ越しだけはコンスタントに2年に1回のペースで続けています。

今回の引っ越しのポイントはルームシェアです。3人暮らししてます。

場所は駅(新高円寺)から3分、新宿までは自転車で20分、渋谷・原宿・表参道までは40分くらいかかります。

部屋は8畳、クローゼット付き。簡易的な防音です(2重窓とか)。

引っ越しの様子についても少し。

引っ越しはあんまりお金をかけたくなかったので自力で引っ越しできるかなと思ってたのですが、結局引っ越し会社にお願いしてしまいました。

あと、知り合いに引っ越し前日に助けてもらっちゃいました。ありがとうございます！

引っ越しは3日連続で、自分、同居人、同居人と続きました。他の同居人は比較的近くだったのですが、一番最後の同居人の引っ越しはかなりの難引っ越しでした。本当に何人くらいに手伝っていただいたのかわからないくらいです。（大げさかもしれないけど）

今はある程度落ち着き、快適生活を過ごしています！

どうぞみなさんいらしてください。

悲劇的。

http://id.hanihoh.com/aisho/?k1=a9100999904ace2cd713c76

久しぶりに日記を書いたと思ったらこれか！

会社で何やってんだ…


そうそう。高円寺に引っ越しましたよ！ 1ヶ月前に。

今度また書きます！

今までの蒲田から表参道までの通勤経路を書き綴ってみます。
総距離はGPSによる計測で12-13キロほど。1時間強くらいで走りきります。ということは平均時速25キロくらい？
そんなに早くないと思うけど…

実はいつも使っている経路は2種類あって、表道と裏道があるのです。それぞれ併走しているので距離は変わらないのですが、表道と裏道の重複部分はたった1キロほどしかありません。

通勤経路は前も書いたかもしれませんが、

蒲田 → 品川 → 泉岳寺 → 三田 → 赤羽橋 → 麻布十番 → 六本木 → 西麻布 → 南青山

という感じなのです。

特に品川（御殿坂）や麻布、六本木は坂がきついので息が切れそうになります。

蒲田と品川の間は結構距離があって、ちょっと海のほうに出ると小型船舶の船着場が見えたりします。

明日から、通勤経路を逆順で紹介します。