redis / memcachedをスケールする方法として、アプリケーションで分散アルゴリズムを実装する方法や、ライブラリを使う方法などありますが、 Twitterが作っているtwemproxy(https://github.com/twitter/twemproxy)というものがあります。 これは、redis / memachedの前段に置くことでキャッシュクラスタを構成することが出来ます。様々な分散アルゴリズムや、故障ノードの切り離しなどの機能もあり、 キャッシュノードが不具合で接続できなくなったとしても自動でサービスアウトしてくれます。 開発も盛んに進んでいて、今、ノード追加時にプロセスの再起動が必要ですが、gracefulの実装も見えて来ました。 詳しくは以前書いたこちらの記事を参照して下さい。http://d.conma.me/entry/20121227/1356596553
クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基本は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
データベースの見直し 前回までの対策でリクエスト数は激減、なんとかルーターが処理しきれるようになりました。次はデータベーススキーマとクエリーの見直しです。WebサービスのボトルネックとなりやすいのがDBサーバーなど、ディスクアクセスが発生するサーバーです。ネギ振りカウンタではMySQLを使用しているのですが、急ごしらえで機能拡張を繰り返していったため、恥ずかしいことにインデックスがうまく効いていないクエリーが含まれていることがわかっていました。 前回でも触れましたが、一見自明な問題に見えても思い込みで対策すると何時まで経っても一番のボトルネックにたどりつかず、対策しても対策しても遅いままという状態になってしまいます。そこで、MySQLにはスロークエリーログという遅いクエリーだけを抽出してくれる機能があるのでそれをみてみました。 →「スロー クエリ ログ（MySQL 5.1 リファレンスマニ
The document describes configuration and usage of the memcached caching server. It shows commands to start memcached, set listening addresses and ports, set memory limits, and check status and settings via the telnet protocol. It also shows integrating memcached monitoring into Nagios/Icinga using checks for TCP connections and specific status metrics.Read less
handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] kazuho (Kazuho Oku) http://twitter.com/kazuho/status/21477219149 考えて答えてみる。 HandlerSocketやmycachedを利用し、MySQLへの接続数が数万単位で行えるようになったり、より多くのクエリ数が発行できるようになっても、memcachedは不要ではないし、使うべきケースもあります。 memcachedは単なるKVSではなく、ExpiresとLRUがついたキャッシュサーバです。キャッシュオブジェクトには期限を付ける事ができ、期限が過ぎたキャッシュは無効にされ、またアクセスがされていない不要になったオブジェクトは削除され、空いたスペースは新しいキャッシュオ
こんにちは。システム本部技術部たんぽぽGの森本です 先日のmixi大規模障害についてのブログです。 はじめにお断りしておきますが、弊社CTOがtwitterで公開した以上の情報はまだ得られておりません。 twitterでは書ききれなかった細部を補足してみたいと思います 現状判明しているのは以下の点です memcachedに大量の接続・切断を行うとmemcachedプロセスが突然終了することがある memcachedには異常時に終了するフローもあるが、同時に出力されるはずのエラーログは出ていなかった coreも出力されていなかった テスト環境にて追試を行ったところ、なんどか再現させることができましたが、確実に発生する条件は未だ不明です。 障害時の memcachedのバージョンは1.4.4, libeventのバージョンは1.3bです memcached の起動オプションは以下のとおり ./
Neal Sato @nealsato 二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixi 2010-08-12 02:33:00 Neal Sato @nealsato memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。 2010-08-12 08:45:50 Masahiro Nagano / 長野雅広 @kazeburo ファイルディスクリプタが不足してmemcachedが落ちたとして、そのときには、3万強の接続となってるはず。3万強の接続となるにはアプリケーションサーバ側のmax clientが平均60とし
当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。 これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。 user system total real
Membaseを入れてみたので、実際にどれくらいの速度が出るのか試してみました。 memcached vs TokyoCabinet vs TokyoTyrant vs Redis - blog.katsuma.tv この記事のパクリですね。これにMembaseを加えてみた感じです。 クライアントによって速度が変わるのが嫌だったので、すべてPythonのmemcachedクライアントを使って、1万回setを行いその時間を計測してみました。 Membase 1.18884205818 memcached 0.683738946915 TokyoTyrant 0.788640022278 Redis 0.642278909683 思ったよりMembaseが遅い…。って言うかRedis速い。 まとめ 使おう！Redis！APIも豊富だし、レプリケーションとかも簡単らしいよ！ ちなみに今回計測に使
memcachedの開発者らが中心となって今年の3月に立ち上げた企業NorthScaleが、memcached互換のNoSQLデータベース「Membase」のオープンソースプロジェクト「membase.org」を6月23日に発表しました。 MembaseはWebアプリケーションのバックエンドに使われることを想定したキーバリュー型データストア。高速かつ高いスケーラビリティを目指したもの。 主な機能として、将来にわたってmemcachedとプロトコルの互換性を保証しつつ、ディスクへの永続性機能（データのディスクへの書き込み）、階層型データストア管理、データレプリケーション、稼働状態での設定変更とノード間のリバランシング機能なども備えると説明されています。 Membaseの特徴はmemcached互換とスケーラビリティ MembaseのWebサイトの情報を基に、特徴を紹介しましょう。 動的なノー
Webインフラ企業の米NorthScaleは6月23日（米国時間）、オープンソースのNoSQLプロジェクト「membase.org」を立ち上げたことを発表した。プロジェクトのサイトでは、「Membase 1.6」ベータ1のバイナリとソースコードを公開している。 NorthScaleは分散メモリキャッシュシステム「memcached」の主要開発者が立ち上げたベンチャー企業で、memcachedをベースにした「NorthScale Membase Server」や「NorthScale Memcached Server」などの製品を開発・提供している。今回、membaseの早期ユーザーである米Zynga、韓国NHNの2社と共に、オープンソースプロジェクトとしてmembase.orgを立ち上げた。今後は、membase.orgをオープンソースプロジェクトとし、商用版としてMembase Serv
Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」（クジラの解剖学）では、Twitterのエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T
実際のサービス運用時はないと思いますが、debugしているときやトラブルの調査をしているときにmemcachedのキー一覧を閲覧したいときはありますよね。 そんな時は、telnetを使って下記のコマンドを打つことでKey一覧を取得することができます。 $ telnet localhost 11211 stats items STAT items:1:number 6 STAT items:1:age 20505 STAT items:1:evicted 0 STAT items:1:evicted_time 0 STAT items:1:outofmemory 0 STAT items:1:tailrepairs 0 stats cachedump 1 100 ITEM foo [9 b; 1264464651 s] ITEM bar [9 b; 1264464649 s]ざっとこんな感じ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
