DNSラウンドロビンを使った時にアクセス・負荷が偏る話 - 元RX-7乗りの適当な日々
昨日に続き、アクセスが偏る系のエントリです。 なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。 DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。 基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。) この事は、Wikipediaの該当ページにも記載されています。 主にIPv6における宛先アドレス選択アルゴリズムとして定義され
グリーCTOが語る、大規模ソーシャルゲーム開発の舞台裏
9月1日、ゲーム開発者向けカンファレンス「CEDEC 2010」において、SNS「GREE」を運営するグリー株式会社（以下 グリー）が『大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～』と題するセッションを講演した。 一日あたり億単位のトラフィックを捌くインフラはどうなっているのか。技術者2名が解説したインフラ構築のノウハウや、ソーシャルゲームと一般のオンラインゲームとの違いについて紹介する。 オンラインゲームとソーシャルゲームとの違い 最近テレビCMでも目にする機会が多くなってきたSNS（ソーシャルネットワーキングサービス）の「GREE（グリー）」。2010年6月時点の数字で、会員数2059万人、月間353億ページビューという言わずとしれた大人気サイトだ。中でも携帯電話向けソーシャルゲームが特徴的で、専用機向けのゲームと比べるとコアゲーマー以外のプレイヤーも多く、利
月間57億PV、300台のサーバを運用するミツバチワークスが編み出したインフラ技術
ミツバチワークスのエンジニアは、「月間57億PV」という巨大なトラフィックをさばくため、さまざまな技術を駆使してインフラを構築している。主と副の2本立てでデータベースを運用し、300台のサーバを使いながら「負荷の限界」に挑むエンジニアに、技術ノウハウを聞く。 ミツバチワークスが運営するケータイブログサービス「DECOLOG」は、異色のサービスである。10代後半から20代前半の女性に最も人気のあるケータイブログサービスで、「デコメール」などを利用して、かわいくカラフルなブログを作成できる。広告基準を厳しくすることで女性ユーザーにも不安なく使ってもらえるような安心感を作り出し、口コミだけでじわじわとアクセス数を伸ばしてきた。 結果、2010年7月実績で月間57億PV（ページビュー）超、想定800万UU（ユニークユーザー）、会員登録者数180万件と、ケータイブログサイトでは国内最大のサービスとし
フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - （ひ）メモ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
(ひ)メモ - そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ（要はreverse proxy）なんていらねっす。セッション？ んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン！ Linux Virtual Serve
0×0018 till I die » はてなnaoyaさん「はてなを支えるバックエンドシステム」
403 Forbidden nginx
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね（しんぱいそうなめでみている） http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、１台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
Yahoo!オークションでのMySQL 冗長化技術
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはオークション事業部プラットホーム技術のチャックです。 オークションでは一部サービスに RDBMS の MySQL を使ってサービスをご提供させていただいております。 オークションでは多くのお客様よりアクセスを頂いておりますので、大量の更新、参照の処理速度に優れた MySQL を選択し、お客様にストレスなくサービスをご利用いただけるよう 日々業務に取り組まさせていただいております。 しかし、精密機器には故障がつきもので、サービス運用の観点からは 「機器が故障するのはしかたない、しかしそれをいかに早く復旧させるか」 といったことを念頭に入れております。 実際には、障害が起こってから復旧させるのではなく、障害が発生した場合に
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
ロードバランサとVIPによるアクセス分散
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog オークション事業部の齋藤です。 私は主に出品や入札など、オークションを操作するマシンやオークションの商品詳細ページを表示するマシンの運用を担当しています。 Yahoo!オークションでは日々たくさんのお客様からアクセスをいただいています。アクセスをできるだけ早く処理するためにオークションシステムではさまざまな対策を行っています。われわれ独自の対策も行っていますが、基本的な大量アクセスへの対処は以下の二つになります。 マシンのCPUやメモリーなどのハードウエアを増強する マシンの台数を増やす 一つ目の対策を行うとマシン一台あたりの処理能力が上がり、同じマシンの台数でより多くのアクセスを処理できるようになります。 二つ目の対策を行うとマ
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソーシャルゲームスケールアウトの歴史
PHPで大規模ブラウザゲームを開発してわかったこと
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine