[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

負荷分散に関するshimookaのブックマーク (28)

  • ソーシャルゲームスケールアウトの歴史

    1. ソーシャルゲーム スケールアウトの歴史 gussan@Drecom Co., Ltd. Copyright © Drecom Co., Ltd. 12年2月20日月曜日

    ソーシャルゲームスケールアウトの歴史
  • CentOS5.5上でPostgreSQL9.0のレプリケーションを試す - bose999の試験管の中の話

    ・プライマリサーバ 192.168.14.101/24 ・ホットスタンバイサーバ 192.168.14.102/24 まず、プライマリーサーバで作業を行ないます。 # su - postgres $ createdb -E UTF8 -O 'postgres' sample $ exit →テスト用のsampleデータベースをpostgresのものとして作成 # mkdir /var/lib/pgsql/9.0/archive # chown -R postgres:postgres /var/lib/pgsql/9.0/archiveアーカイブログの置き場所の作成 # vi /var/lib/pgsql/9.0/data/pg_hba.conf # vi /var/lib/pgsql/9.0/data/postgres.conf →内容については下記に記載したものを参照 # /etc

    CentOS5.5上でPostgreSQL9.0のレプリケーションを試す - bose999の試験管の中の話
  • サーバ負荷分散概論 - KLablabWiki

    特集のはじめに 特集のメインテーマは『サーバ負荷分散』です。 負荷分散というと むずかしそう 機器が高価 大規模向け というイメージが先行して、敬遠している人は多いのではないかと思います。 実は、今回の特集はそんなあなたのために書きました。 特集を読み終えたあと、きっとその印象は おもしろそう 安い 手軽に使える に変わっているでしょう。 ではではさっそく題に入りましょう。まず章では「サーバ負荷分散」一般についてざっと説明し、次章以降でより具体的な実現方法を解説していきたいと思います。 なぜサーバ負荷分散をするのか? 『サーバ負荷分散』[1]をひとことでいうと、「1つのサービスを複数のサーバで行うこと」です。では、どうして複数のサーバでサービスしたいのでしょうか? どんな利点があるのでしょうか? 大別するとそれは2つあります。[2] 性能 まず1つめの利点は性能向上です。 例

    shimooka
    shimooka 2010/01/27
    絵は何で描いてるんだろ?/id:shoma++ 結構新し目のバージョンなのかな?
  • ウノウラボ Unoh Labs: 国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く

    こんにちは。中村です。 MySQLにはMyISAM、InnoDBCSVなどのいくつかストレージエンジンがありますが、皆さんはSpiderというストレージエンジンを聞いたことはありますでしょうか。Spider Storage Engineは斯波健徳さんにより作成されたDatabase Shardingを可能にするストレージエンジンでMySQL 5.1で利用可能です。 先日、某集まりで斯波さんとお会いしたときにSpiderを作っているということを教えてもらったので、早速詳しい内容を教えてもらうことにしました。 ※Spiderについての説明資料はMySQLカンファレンス 2009にて斯波さんが発表されたときのスライドがあります。スライドの直リンク(zip) Spider Storage Engine について posted by (C)フォト蔵 Spider Storage Engineとは?

  • Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件

    大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:

  • LVS+ldirectorを使ってMySQLをロードバランスをしてみる - sanonosa システム管理コラム集

    今回はLVSを使ってMySQLのslaveサーバをロードバランシングする方法を記してみます。LVSは単に振り分けしかやってくれませんので、リアルサーバの生存確認やLVSの作動管理のためにldirectorも導入しています。 LVSだけだとLVSの設定を入れ込まなければなりませんが、ldirectorを使うとldirectorの設定ファイルに書いておくことでLVSの設定をldirectorが自動生成して反映してくれるので楽ちんです。 ※世の中にはLVS+keepalivedの組み合わせが多いようですが、検証してみたところldirectorのほうが導入も運用も簡単なのでこちらを採用しました。 前提条件 VIP: 10.0.2.10 DB1: 10.0.0.101 DB2: 10.0.0.102 ロードバランサーとなるサーバへのインストール方法 【インストール】 # yum install ip

    LVS+ldirectorを使ってMySQLをロードバランスをしてみる - sanonosa システム管理コラム集
  • ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな

    Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね(しんぱいそうなめでみている) http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、1台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム

    ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
    shimooka
    shimooka 2009/04/17
    『EeePCすばらしい』
  • livedoor Techブログ : MySQL Proxy を試してみました

    こんにちは。金子です。 先日、社内勉強会で MySQL Proxy を取り上げました。その際まとめた資料を、一部加筆修正して公開します。 最初にお詫び 大元の文章を書いたのが 2007 年の 7 月なので、内容が少し古いです。これを書きながら最新版をチェックアウトしてきて再検証したかったのですが、レポジトリがダウンしていて最新のソースコードを入手できませんでした。なので、一ヶ月前のリビジョン(rev.116) 時点でのソースコード + 二週間くらい前にレポジトリを覗いたときの記憶のみで書いており、いろいろ間違っているおそれがあるので、みなさん是非自分でコンパイルして試してみてください(注意!ただでさえつながりにくいので、このエントリを全部読んで一週間後にまだ MySQL Proxy のことを覚えていた人だけレポジトリにアクセスしてくださいね) 気の早い人向けの結論 まだ実践投入するには厳し

  • 止まらないシステムはLinuxで作る!~オープンソースを活用したHAサーバ構築入門一覧

    EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    止まらないシステムはLinuxで作る!~オープンソースを活用したHAサーバ構築入門一覧
  • ldirectordで、LVS(Linux Virtual Server)による負荷分散システムの構築

    EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    ldirectordで、LVS(Linux Virtual Server)による負荷分散システムの構築
  • 高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋

    「こんなに簡単! Linuxでロードバランサ」のシリーズでは、 こんなに簡単! Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単! Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単! Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや?」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調

    高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
  • こんなに簡単! Linuxでロードバランサ (3) : DSAS開発者の部屋

    前回はkeepalivedを使ってWebサーバを冗長化してみました。 今回はkeepalivedのもう一つの機能であるVRRPを使って、ロードバランサ自身を冗長構成にしてみたいと思います。 ┌─────┐ │ client │ └──┬──┘ │[10.10.31.200] │ ━━━━━━━┯━━━━┷━━━━━┯━━━━━━━━━ 10.10.31.0/24 │ │ │ │ │ ←(10.10.31.10) → │ │ ←{10.10.31.100}→ │ [10.10.31.11]│ │[10.10.31.12] ┌─┴─┐ ┌─┴─┐ │ lv1 │ │ lv2 │ └─┬─┘ └─┬─┘ [192.168.31.11]│ │[192.168.31.12] │ ←(192.168.31.10)→│ │ │ ━━━━━━┯┷━━━━━━━━━━┷┯━━━━━━━━ 192.168.3

    こんなに簡単! Linuxでロードバランサ (3) : DSAS開発者の部屋
  • こんなに簡単! Linuxでロードバランサ (2) : DSAS開発者の部屋

    前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す

    こんなに簡単! Linuxでロードバランサ (2) : DSAS開発者の部屋
  • DSAS開発者の部屋:こんなに簡単! Linuxでロードバランサ (1)

    DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々

    DSAS開発者の部屋:こんなに簡単! Linuxでロードバランサ (1)
  • ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog

    Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と3サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ

    ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
    shimooka
    shimooka 2008/08/20
    『ディスクIOのコストは画像の変換にかかるCPUのコストよりも高い』『CARP』
  • mixi Engineers’ Blog » 期間限定の新機能「エコー」登場

    こんにちは。mixi開発部のyouheiです。 今回は先日8月4日にリリースした「エコー」について書きたいと思います。 エコーとは まずはエコーとはどういう機能かのご紹介ですが、プロモーションページがございますのでそちらをご覧いただければ幸いでございます。 http://mixi.jp/guide_echo.pl いくつか抜粋しますと、 あなたの"今"を一言にしてみませんか?誰かに伝えたいこと、ひとりごと等、何でもOK! 気軽な新コミュニケーション機能です。 たとえば、「今日はいい天気だな〜」という、ひとりごとから、「お腹すいたー!誰かランチにいこうよ!」というメッセージ的な使い方まで、「エコー」の楽しみ方はあなた次第! マイミクシィ同士で「エコー」を使うとホームにお互いの書きこみが表示されます。 気になった書きこみには、返信することもできちゃいます。あなたがふと書きこんだ一言に、思わぬ返

    mixi Engineers’ Blog » 期間限定の新機能「エコー」登場
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • High Scalability | Building bigger, faster, more reliable websites.

    Kafka 101 This is a guest article by Stanislav Kozlovski, an Apache Kafka Committer. If you would like to connect with Stanislav, you can do so on Twitter and LinkedIn. Originally developed in LinkedIn during 2011, Apache Kafka is one of the most popular open-source Apache projects out there. So far it Capturing A Billion Emo(j)i-ons This blog post was written by Dedeepya Bonthu. This is a repost

    High Scalability | Building bigger, faster, more reliable websites.
  • http://diary.eth.jp/?date=20080515

  • 現場指向のレプリケーション詳説

    この文書は、技術評論社刊『WEB+DB PRESS Vol.22』に執筆した記事を技術評論社の 許可を得てWWWで公開しているものです。 このWWW版は校正前の原稿を元にしている点、WWW公開後に必要があれば修正する点で、雑誌版の文章とは異なる部分があります。また、図表も雑誌版とは異なります。 予めご了承ください。 また、この文章が対象しているのはMySQL 4.0系なので、最新のリリース版と比べると説明不足な点などが多々あると思います。 レプリケーションの基をおさえるには、この文書はまだ有益だと思いますが、設定レベルの説明は最新のドキュメントを参照するようにしてください。