Disqus のスケール - Django で月間80億PVを処理する
私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。月間80億PV、45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は高速開発とパフォーマンス、新しい人が入ってすぐに開発に参加できることとカスタマイズ等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート (django.contrib とか?) や不要なコードがあ
Disqus のスケール - Django 編
やり直し。2010 年の Django Con のスライドより。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/PgBouncer: コネクションプール用。 PostgreSQL: 10 台ぐらい。Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFoui
Python の新ユニットテストフレームワーク (or unittest2)
これは Python3 Advent Calendar の記事です。夢はテストエンジニアです！ということでユニットテストについて書きます。 Python3 縛りとのことですが、この新ユニットテストフレームワークは Python 3.2 以降と 2.7 以降が対象です。これ以前のバージョンでこの新ユニットテストフレームワークを利用したい場合は、それぞれ unittest2py3k (3 系)、 unittest2 (2 系) というバックポートが用意されています。新ユニットテストは mock や IronPython 等の開発者としても知られている Michael Foord 氏を中心に開発されました。 >>> Python とユニットテストの歴史 Python のユニットテストは、1999 年 xUnit ファミリーの PyUnit として開発され、2001 年に公開された Python
Netflix のスケール
現在日本でサービスを提供していないため目にすることは少ないですが、AWS のベストプラクティスと呼び名が高い Netflix のスケールをメモ。ベストプラクティスと言われるだけあって、記事も解説も豊富です。まー規模が桁違い過ぎるので読み飛ばしていたってのが正直なところですが、V 先生ドリブンで資料を読み直しました。AWS の How-to 記事は日本語でも山ほどあったので、自社データセンターから AWS へ移行した過程を中心に書きたいと思います。Netflix のテクノロジーについては以下を参考にしました。 The Netflix Tech Blog @slideshare @github >>> サービスの規模 Netflix は主に北米で VOD と DVD 郵送レンタルサービスを提供している会社です。ほとんど VOD で、今後 DVD 郵送レンタルは縮小するらしい。AWS の資料も
Dropbox のスケールとか
Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか？" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ！当時、プ
Secure Shell - Awesome extention for Chrome
Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制
Pinterest のスケール
V 先生から教えて頂いたので、Instagram 同様 Django/AWS 構成の Pinterest のスケールをメモ。Pinterest はいつものアカウント名が初めて 先取 されたサービスなので、今後使わないと思います。 本題に入る前に、Python には The Zen of Python (日本語) という思想があります。私はこの思想を Python でのプログラミングだけでなく、インフラの構築の際も意識するように心がけています。"Simple is better than complex" です。Instagram や Pinterest のスケールを見て、この思想がもっと好きになりました。 Instagram はよりシンプルなインフラに更改していくことで、ただスケールするだけでなく、運用や変更のコストも最小限になるように最適化していると思います。結果的に Android ア
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
PySide チュートリアル - helloworld から ユニットテストまで
ここ 2 ヶ月ほど PySide でお仕事してました。もともと PyQt で動いてたアプリケーションだったのですが、けっこう仕様変更が大きかったこともあり、どうせなので PySide で作り直してみることにしました。両フレームワークの差異はこのページにまとまっています (id:doloopwhile さんが翻訳されています)。大きくは、 モジュール名が PyQt から PySide に PyQt の API は QString や QVariants 等 Qt が提供する型と、unicode 等 Python のデータ型の両方をサポートしていましたが、PySide では Python のデータ型のみをサポート 画像等のリソースファイルをバイナリに変換したりするツール類の名称がそれぞれ変更 pyuic4 -> pyside-uic pyrcc4 -> pyside-rcc4 pylupdat
Python で Skype にロギングする
id:moriyoshi さんが "Linux上で動くSkype用のbotを作る方法" というブログを書かれていたので便乗します。会社で Python から Skype へログを出力するためのハンドラーを試験的に使っていました。便利ですが、利用はお勧めしません。理由は最後に書きます。 コードはこんな感じになります。 # -*- coding: utf-8 -*- # skype_handler.py from logging import Handler try: import Skype4Py skype = Skype4Py.Skype() except: skype = None if skype and not skype.Client.IsRunning: # Skype が起動してなかったら起動する skype.Client.Start() class SkypeHandler
パーフェクトな Django の設定ファイル
"DAMON BLOGONS" の、 "The Perfect Django Settings File" という記事で紹介されていた Django の設定 (settings.py) が面白かったので、私が利用しているものと併せて紹介したいと思います。 環境による DEBUG の切り分け 開発環境では "DEBUG = True" と書くと幸せになれます。Django のデバッガーは強力です。ただし、本番環境にそのままデプロイしてしまうと・・・。デプロイを楽にするためにも、失敗を防ぐためにも自動的に切り分けるのが望ましいですよね。Damon 氏は以下のようなコードで切り分けているようです。 # Set DEBUG = True if on the production server if socket.gethostname() == 'your.domain.com': DEBUG =
高可用性ロードバランサーを nginx + heartbeat で作る
インストールと設定 パッケージ類のインストール (nginx と heartbeat) ロードバランサーとして利用する nginx と、クラスタリングするための heartbeat をインストールする sudo aptitude install nginx heartbeat nginx の自動起動をやめる sysv-rc-conf などを利用し、各ランレベルでの自動起動を停止しておく ※ sysv-rc-conf をインストールしていない場合は以下でインストールできる sudo sptitude install sysv-rc-conf hosts ファイルに各サーバを登録する sudo vi /etc/hosts 192.168.0.2 lb01 192.168.0.3 lb02 ※ お互い ping 試験 /etc/ha.d/ha.cf の作成 テンプレートがあるので、作業用ディレク
ubuntu への nginx のインストールと load balancer としての利用
nginx のインストール aptitude で リポジトリからインストールしてみる。 sudo aptitude install nginx sudo /etc/init.d/nginx start nginx の初期設定 ubuntu では、(apache 同様) サイト毎の conf がモジュール化されており、default のモジュールは /etc/nginx/sites-enabled/default となっている。 sudo vi /etc/nginx/sites-enabled/default 私は apache2 同様、 ./sites-available/* にモジュール化したサイトの conf をつっこんでおき、 ./sites-enabled/* 内にシンボリックリンクを作成するようにしています。 nginx では、いまのところ apache2 のように a2emod
ubuntu で nginx から memcache を利用する
memcached, python-memcache のインストールと起動 sudo apt-get install memcached python-memcache sudo /etc/init.d/memcached start 初期設定だと 11211 番ポートで起動しています。変えたい場合は /etc/memcached.conf で。 memcached とお話してみる (telnet 編) まずは telnet 経由でお話してみる。プロトコルについては official wiki を見ればいいと思います。 telnet 127.0.0.1 11211 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 'foo' という key で フラグ 0、無期限 (0)、 3 byte のデータ '
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
