Kosei Kitahara's Blog

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで

ちょうど 1 年前にリリースされてた機能だけど、恥ずかしながら知らなかった。 @t2y 先生が 紹介 していらっしゃって、後で試してみようと思ってたのですが...。 virtualenvwrapper ってインストール時にグローバルな site-packages に放り込んで、後は。。。って感じ。あんま見直したことなかったのですが、プロジェクト管理以外にも結構色んな機能が追加されてるんですね。 mkvirtualenv , workon だけじゃない！ ドキュメントを 和訳 してくださっている @t2y さんに多謝。基本的な機能やコマンド (と思いこんでいた mkvirtualenv , workon , etc...) については virtualenv, virtualenvwrapper, pip を使う方法 by @IanMLewis さん, Pythonを取り巻く開発環境 (PyCon JP 2012資料 #pyconjp) by @ymotongpoo さんの記事が参考になります。 >>> mkvirtualenv v3.3 から新しい オプション が増えてたんですね。これも知りませんでした。 -a <path/to/project> : プロジェクトに新しい env を関連付ける (後述) -i <library_to_install> : env 作成と同時に、インストールしたいライブラリを指定する mkvirtualenv -i django -i django-celery-with-redis <env_name> のように複数指定できる -r <path to requirements file> : env を作り requirements.txt 等指定したファイルに記載したライブラリを一括でインストールできる。個人的にこれは一番うれしいかも mkvirtualenv -r ./requirements.txt <env_name> ラクダーーー >>> mktmpenv これも v3.3 から。ユニークな名前で env 作成してくれる。 >>> cdvirtualenv , cdsi

PySpa がどんなイベントかは 既に紹介されつくした感じ ですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は 勉強したいテーマを見つける 童心に返って技術を楽しむ 煙草エリアのベンチを温める ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。

Hython 部の方から来ました。こんにちは。今回は Python ボルダリング部 (通称 #kabepy ) のアドベントカレンダーにお邪魔させて頂きます。もともと Hython 部は Pythonista が廃村に行くとかいうノリで始まったんですが、廃村が山奥にあることが多く、いつの間にかワンダーフォーゲル部になってしまいました。昔の日本は林業大国だったんですね。 今年 (2012年) の登山成果は、 谷川岳 - 一ノ倉 - 茂倉岳縦走 富士登山 槍ヶ岳縦走 浅間山縦走 丹沢縦走 です。#kabepy のアドベントカレンダーなので "ロッククライミングのメッカ" と言われている谷川岳について書かせて頂きます。 谷川岳について 谷川岳 - Wikipedia に詳しく書かれていますが、 剣岳、穂高岳と共に日本三大岩場のひとつ 日本三大急登 (高低差) がある 遭難による死者数が世界一 (ギネス認定 なんとも物騒な感じですが、コースによります。私が登ったコースは、とても登りがいがあり、稜線が素敵なコースでした。まだ登山歴 2 年目ですが、また登りたいと思った山は谷川岳だけ。 @rokujyouhitoma 先生の故御父様も谷川岳をこよなく愛されていたそうです。 コース 直線距離: 約15km / 高低差: 1.5km / 全 7.5 時間 ぐらいですかね。小雨。 07:30 - 土合駅 08:00 - 天神平 晴れてる時は富士さんが見えるらしい。残念ながら ガスで10m 先も見えない。 10:00 - 谷川岳トマの耳 (1,963m) 鎖場あり。岩場あり。登りごたえのある登山コースです。が！写真撮れません。ガスがひどくてシャッター下りません。立派なプレートだけ。 11:00 - 谷川岳オキの耳 (1977m) 景色？なにそれ。立派なプレート。 稜線の所だけガスが晴れた瞬間。ここから人とすれ違わなくなります。高山植物がいたるところに生えていて、ハエが大量にいます。が！写真撮れませんでした。 12:00 - 一ノ倉岳 (1974.2m) 立派な・・・ 手前に万年雪があります。ガスもあってただ一面白いだけ。ここもオートフォーカスが効かないという。 13:

Django-ja の方からきました。こんにちわ。さて、昨日の Ian 先生のブログ にも書いてある通り、ついに Django にも本格的に Python 3 の足音が近づいてきました。ただし現在 alpha 版が公開されている 1.5 では "実験的" なサポートで、1.6 以降で正式にサポートする予定となっています。あくまでも "実験的" であり、プロダクションでの利用は "非推奨" となっています。Django コミュニティでは、この 1.5 でサポートをテストしてもらい、そのフィードバックを呼びかけています。なのでプロダクションでの利用は 1.6 まで待ちでしょうね。また Python 3 サポートと同時に、Django 1.4 では Python 2.4 がサポートから外れ、1.5 では Python 2.5 がサポートから外れます。これで 1.7 以降から django.utils 配下が軽くなっていくんでしょうかね (現在は 3 サポートのためにさらに増えてる)。 バージョン 下位互換 Python サポート 2.5 2.6 2.7 3.2 3.3 Django 1.4 > 1.2 ○ ○ ○ - - Django 1.5 > 1.3 - >= 2.6.5 ○ >= 2.7.3 △ 実験的 △ 実験的 Django 1.6 > 1.4 - >= 2.6.5 ○ >= 2.7.3 ○ ○ Python 2.5 系を利用している場合は、1.6 のリリースまで (2013 後半ぐらい?) に Python 2.6.5 以上 (2.7.3 以上を強く推奨) への移行が必要です。1.5 は今月 (2012/12) 中にリリース予定とのことなので、今のうちに Python 3 へ移行方法を抑えときたいなと。以下 Django ドキュメントの翻訳作業がてら " Porting to Python 3 " を元にご紹介。さすが

遅くなったけど続編。前回 TODO にしてたスケールアウトのオートメーションあたり。AWS のオートスケールについては、 本家ドキュメント に一通り書いてあります。その機能を大まかにまとめると、 スケールアウト、バランシングが自動化できる 複数のゾーン (Availability Zone) にまたがっていても一元管理できる (AZRebalance ELB を指定してインスタンスを追加できる 不健全なインスタンスを自動的に入れ替えれる >>> オートスケールの設定 大きく分けると 3 つのステップ CPU やメモリ等のリソースを識別する CloudWatch に各リソースをモニタリングするためのメトリクスを作成する デフォルトでモニタリング可能なリソースが用意されている ( デフォルトで用意されているリソース EC2 の CPU 負荷、ディスク I/O、ネットワーク I/O ELB のホスト数 (健全/不健全)、 リクエスト数 、レイテンシ Netflix 推奨は ELB の rps (req/sec クラスメソッドさんが カスタムメトリクスの追加 について超わかりやすく解説されています。 リソースの変化に基づくアラームやオートスケール等のポリシーを定義する ポリシーベース: 負荷が高くなったら EC2 インスタンスを増やし、負荷が減ったら EC2 インスタンスを減らす スケジュールベース: 負荷の予測が可能な場合は、インスタンスの増減をスケジュールする (バッチ処理にも素敵 >>> Netflix がオートスケールから学んだこと Netflix さんが実際にオートスケールを運用して、その結果を フィードバック されています。以下抄訳とかメモとか 早めにスケールアップ 例えば負荷テストで 25rps (rec/sec) を超えると待ちが発生するとする。その場合は待ちが発生しないように、20rps を超えた際にキャパシティーを増やすよう設定する。この rps の上限設定は以下の目的がある。 オートスケールイベントのトリガーでは間に合わない程の、予想をはるかに超える rps もありうる このバッファーが "キャパシティスパイラル" を回避するセーフ