というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハード
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 倍について
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
インターネット・サービスの激戦区である動画配信で後発ながらYouTubeを上回る成長速度，YouTubeの3倍以上となる1日ひとり3時間以上という平均視聴時間を実現したニコニコ動画。開設後1年足らずで400万人の会員を獲得，日本全体のトラフィックの約10分の1を占める。その成長速度はmixiも上回り，日本史上最速と見られる。 ニコニコ動画は多くのメディアで語られ，2007年10月にはグッドデザイン賞も獲得したが，これまでは社会現象やマーケティングの観点から語られることが多かった。しかしニコニコ動画を作り上げ，その急拡大を支えたのはまぎれもなくエンジニアの技術だ。多くのクリエイタやユーザーを魅了し，巨大なアクセスをさばく技術はどのようなものなのか。ドワンゴのエンジニアに聞いた。 「感情」を共有するアルゴリズム 動画の上に文字をかぶせるサービスはニコニコ動画以前にも存在した。また，動画のタイミ
当日の講演資料と動画を公開です。 動画はニコニコ動画を利用して配信しています。ニコニコ動画のアカウントをお持ちでない方でも，gihyo.jp上で動画を再生できます（コメントの書き込みはできません）。 動画の最後でニコスクリプトを使ったアンケートを行っていますので，ニコニコ動画のアカウントをお持ちの方はご協力いただければ幸いです。動画をクリックすることでニコニコ動画の該当ページへアクセスすることができます（ニコニコ動画のマイリストはこちら）。 今回の動画公開にあたって，gihyo.jp用に新たなニコニコ動画プレーヤーを作っていただきました。この場を借りてニコニコ動画の方にお礼を申し上げます。 JavaScript Tips & Technique IT戦士amachangが最近のJavaScriptのテクニックやTipsについてご紹介します。
cacti - グラフツールcactiとは?
cacti(カクタイ)とは、サボテンという意味のグラフツール cacti(カクチ)とは、サボテンという意味のグラフツール 読み方を間違っていた MRTGの代替ツール † グラフツールというとMRTG*1が有名ですね。cacti*2もMRTGと同じように、SNMPエージェントが取得した値や、プログラム/スクリプトの出力結果をグラフ化することが出来ます。MRTGよりも優れている点はいくつもありますが、まずはその操作性を体験してみて下さい。ホストの追加やインタフェースの追加など、全てWEBのGUIを通してコンフィグレーション可能なので、慣れるととても楽です。 ↑ RRDToolのGUIフロントエンド † cactiはグラフデータの保存やグラフ生成に、MRTGより高機能なRRDTool*3を使っています。cactiではRRDToolの複雑なコマンドラインオプションと格闘することなく、RRDTool
CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
携帯向けサイト「モバゲータウン」の勢いが止まらない。2010年3月の会員数は約1800万人、月間ページビュー（PV）600億という"モンスターSNS"に成長している。意外なことに、これだけのアクセスをさばくのに、memcachedをはじめとするKVS（Key-Value Store）系のインフラ・ソフトはあまり使っておらず、MySQLで十分だという。モバゲータウンのインフラ担当者に話を聞いた。 モバゲータウンを運営するDeNA（ディー・エヌ・エー）は、もともと1999年に開始したオークションサイト「ビッダーズ」で知られている。その後、オークションに加えてECサイトを開始し、auとの提携により「auショッピングモール」などで急速に成長した。 ビッダーズだけでも、数千万PV規模の大規模サービスだが、最近はモバゲータウンの成長が著しい。 「特に2009年9月から順次リリースした自社製のソーシャル
追記 2009-04-03 まったくもってブコメでいただいた指摘の通りです＞＜ h2onda linux, tcpdump tcpdump(というかlibpcap)は、データリンク層(OSI layer2)レベルでパケットを取得する packet プロトコルを使ってるので、そうなります。参照: man packet(7) 2009/04/02 はてなブックマーク - h2ondaのブックマーク / 2009年4月2日 tt_clown network 細かいけど，図は逆（NIC が下）のが良いかなと思った．/ "ip"tables と言う位だから，IP層でパケットをフィルタしてるて事だろうな．tcpdumpはEthernet Frameも見えるので，後は分かるな？・・・てとこか． 2009/04/02 はてなブックマーク - tt_clownのブックマーク / 2009年4月2日 pack
naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
Docker ロードバランサ内部実装
先日のDockerCon16でDocker 1.12RCが発表されまして，主な機能追加として SwarmのDocker engineへの統合とそれに伴うクラスタ構築の簡略化 Service機能の追加 Load Balancer機能の追加 が発表されました． 今回はSwarmクラスタの構築~Serviceの定義まで行って，ロードバランサの内部実装を詳しく追ってみます． Docker 1.12RCのインストール これは既にget dockerで問題なく可能です． 今回はAWS上にクラスタを構築します． node1(master) : ip-172-31-1-218 node2 : ip-172-31-1-219 node3 : ip-172-31-1-217 これら３台のホスト上でそれぞれ以下のコマンドでDocker 1.12をインストールします． $ wget -qO- https://ex
LVS構築における最強の手順書を残してみました。 はじめに ロードバランサ（LVS）の需要は間違いなくあると思うのですが、いかんせんネットに情報が少ない。 かの有名な「サーバ/インフラを支える技術」が出版された2008年あたりがピークの感がある。(Klabさんの記事には大変お世話になりました) Googleで調べてもまとまった情報がなかったりするので、最初は大変でした。 普段インフラ周りで仕事しているので、そこで培ったノウハウを出したいと思います。マイブログ史上最大の情報量。 今回は「CentOS6.4 x86_64マシン」に「最新版keepalived-1.2.7を導入」で「割りと本番運用に耐えられる手順」を解説。もちろん定番のIPVS + Keepalived のDirect Server Return(DSR)構成。 ※是非コメント欄でもさらに有益な情報がありましたら歓迎です。 内容
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
Cerevo営業の栗林です。 取引先である機材屋様のYouTubeチャンネルでCerevoのライブ配信機器「LiveShell W」を、ご紹介いただきました！ AZDEN様のマイクアダプター MC-1PHと接続することに […]
先月、Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジンというエントリでSPIDERストレージエンジンによるスケールアウトが凄い！という話を書いた。SPIDERストレージエンジンは凄いヤツだが、ノウハウがあまりウェブ上で見つからない。唯一見つかる日本語の記事は、ウノウラボによる「国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く 」だけである。SPIDERストレージエンジンは斯波氏による単独の作品であるため、斯波氏は開発だけで手いっぱいであり、使い方の紹介記事を書くことまでは手が回らないのであろう。こんな凄いストレージエンジンをドキュメントが足りないせいで使って貰えないなんて勿体ない！！ というわけで、今日はSPIDERストレージエンジンの基本的な使い方について紹介する。少し長いエントリであるが、最後までお付き
EngineeringGLB: GitHub’s open source load balancerAt GitHub, we serve tens of thousands of requests every second out of our network edge, operating on GitHub's metal cloud. We've previously introduced GLB, our scalable load balancing solution… At GitHub, we serve tens of thousands of requests every second out of our network edge, operating on GitHub’s metal cloud. We’ve previously introduced GLB,
ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!
はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか？ 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅
本日は Google Gears 関連のもうひとつのネタを書こうと思ったのですが、間に合わなかったので最近仕事で使った Apache のリバースプロキシ機能の設定方法などをご紹介します。リバースプロキシは、特定のディレクトリ以下へのリクエストを他の Web サーバーに中継する機能です。 LAN 内の複数のマシンで稼動している Web サイトをひとつのグローバル IP で公開したり、 Apache 以外の Web サーバー（Rails でよく使われる mongrel とか）を Apache の Web サイトに統合したりとかが簡単にできます。 Web サイトを柔軟に構築するために、覚えておくと便利ですよ。 前提条件 Apache のリバースプロキシ機能を利用するためには、 mod_proxy を組み込んだ Apache が必要です。通常の Linux ディストリビューションなどではデフォルト
尾藤正人です。 前回のエントリ ベンチャー流サーバ構築のススメ(ハードウェア編) では多くのコメント、トラックバック、ブックマークをしていただきました。ありがとうございます。僕自身多くのことで勉強になりましたし、新たな発見もありました。 技術は公開、共有して発展するものだと思っていますので、自分の無知をさらけ出すのを恐れずにいろいろ公開して、自分自身も成長していければと思っています。 今回はサーバ構築するときのトピックとして、どのようにネットワークを構築したかを書いてみます。 サーバ構築に限ったことではありませんが、重要なのは質を下げずにコストを下げることです。ネットワーク部分でお金がかかるのは回線ぐらいですから、ネットワーク周りで重要なのは人的コストを下げること、つまり管理コストを下げることです。 ・回線は2回線以上用意する 2回線以上用意するのは高可用性を確保するためです。通常は全ての
【新機能】AWS ELBのApplication Load Balancer(ALB)の認証機能でWebアプリにGoogle認証を追加する | DevelopersIO
【新機能】AWS ELBのApplication Load Balancer(ALB)の認証機能でWebアプリにGoogle認証を追加する Application Load Balancer(ALB)の認証機能のひとつ、OpenID Connectの例としてWebアプリにGoogle認証をかける様子をご紹介します。 ども、大瀧です。 本日、AWS ELBのApplication Load Balancer(ALB)に認証機能が追加されました。 Simplify Login with Application Load Balancer Built-in Authentication | AWS News Blog ALBの認証機能では様々なことができるのですが独自IdPとの連携は既に他のメンバーが記事を書いているので、本記事ではOpenID Connectの例としてGoogle Identi
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
ロードバランサは高いので、Linuxで比較的簡単にL4の負荷分散を行えるLVSは使いドコロが色々あり結構便利。 久々に作った時のメモがわりとして、今回は、LVSの構築手順と簡単なテスト結果を順に書いてみた。 構成 ちょっと特殊な要件があり、負荷分散行うLVSも実際にレスポンス返すアプリも同じ筐体で動かしたいという前提で作った。 ※最初の投稿だと、同一筐体で動かした時にBACKUP STATEのLVSがARP応答する設定になっていたので、加筆！ LVS単体サーバとしても下記の手順で同じように作れる サーバはaa,bbの2台(vagrant上の仮想マシンとした) 同じ役割を持つサーバaa,bbをLVSを使って負荷分散したい LVS自身も冗長構成にして、aa,bbにやらせたい リクエスト元は、同一セグメントなのでDSR(Direct Server Return)を使う ※NATは、戻す時に直接L
おやじは、いつでも乗り換えられるようにいろいろなデストリのテストをしていたため、今までは1つのディスクに複数のデストリをインストールしていました。しかしながら、今回、仮想化テクノロジの本家とも言うべきVMwareがBeta版(正式版も無償で公開される予定のよう)ながらVMwareシリーズの「VMware Server」を無償公開してくれたので、これをWindows XP Pro SP2クライアントに入れて仮想マシンとして動作させるようにしてみました。 一般に、WindowsクライアントはCPUもそこそこ早いですし、メモリも結構積んでおり、HDDも容量があると思います。おやじの場合は、Pentium 4 2.6CG、1GByte、HDD: 256GByte +128GByteですが、ほとんどストレスなく動かすことができました。仮想マシンのイメージをバックアップしておけば、いつでもその状態に戻
drbd.conf
ストレージには寿命があり、保存された情報は永遠に正常性を保証されるわけではありません。その為に別のストレージにデータをバックアップしたり、ストレージそのものを多重化してデータを保護することが重要です。今回紹介するは、ストレージデバイスを多重化し、データを複数のストレージに保存する仕組みで、DRBD(Distributed Replicated Block Device)と呼ばれているものです。同様の仕組みにソフトウェア／ハードウェアRAIDがあります。 DRBD(Distributed Replicated Block Device)とは、TCP/IPネットワークを通じて複数のサーバのストレージ（パーティション）をリアルタイムにミラーリング（複製）するソフトウェアです。RAID1のようなミラーディスクを構築することができます。ソフトウェア／ハードウェアRAIDは同じサーバ内のストレージを使
nginx+squidで画像キャッシュサーバーの作り方 - hideden.hatenablog.com
仕事で画像キャッシュサーバーを構築した時のメモ。大規模事例の設定例が検索してもあまり見つからなかったので同じような境遇の誰かの参考になれば。 ピーク時のトラフィックは数Gbps 画像総容量は数十TB バックエンドのstorageが複数種類 規模とアクセス量とアクセスされる画像の種類が多いので、squidでdisk cacheを使用するとCOSS等を使用してもdiskIOで詰まる為、全てon memory cache。cache容量を確保する為に必然的にcacheサーバーの台数も数十台。 1. squidをsibling構成で並列に並べる cache_peer 10.0.1.1 sibling 80 3130 no-query no-digest proxy-only cache_peer 10.0.1.2 sibling 80 3130 no-query no-digest proxy-o
サーバ負荷分散の基本構成と動作 負荷分散装置（ロードバランサ）のニーズは現在も高まる一方です。従来はWebサーバのみを主な対象としていましたが、現在ではルータ#1／アプリケーションサーバ／メールサーバ／SIPサーバ／ファイアウォール／VPNゲートウェイ／ウイルスゲートウェイ／IDSなど、多種多様の機器やプロトコルが負荷分散の対象となっています。それに応じてロードバランサも現在では非常に多機能となっていますが、本連載では、全3回に渡ってアプリケーションベースではなく、ネットワークベースの技術、基本となるパケットフローやサーバヘルスチェック、接続維持などの動作について紹介します。また、パフォーマンス測定についてもお話ししましょう。 #1 ルータはレイヤ3でインターネット回線のマルチホーミングとして機能する（＝複数のWAN回線を接続して、同時に通信させることで負荷分散し、必要な帯域を確保するし、
2023年10月10日午前8時30分ごろに発生した「全国銀行データ通信システム（全銀システム）」の障害。全国銀行資金決済ネットワーク（全銀ネット）は復旧に向けた対応を実施しているが、11日午前11時時点で解消のめどは立っていない。 全銀システムは東京と大阪の2カ所のセンターで並行運転し、システムを構成する各種装置や通信回線などをすべて二重化してある。顧客に影響が出るシステム障害が発生するのは1973年の稼働以降、50年間で初めてとなる。 今回、不具合が生じたと考えられるのは、金融機関が全銀システムに接続する際に使う中継コンピューター（RC）のプログラムだ。送金元の金融機関から送金先の金融機関に対して支払う「内国為替制度運営費（旧銀行間手数料）」の設定などをチェックする機能に不具合が生じたと見られる。 きっかけは保守期限到来に伴い、10月7～9日の3連休中に14の金融機関で実施したRCの更改
以前、ブログに書いて以来、活用しているpsshとpscpなんですが、 付属コマンドのpslurpについてはすっかり忘れて全く利用していなかったんですが、 同僚の刺身さんが結構活用しているというのを聞いて、改めて使ってみると大変便利！ Parallel sshで複数のホストへ同時にコマンドを実行する | Glide Note - グライドノート 環境はSL6.1です。 pslurpの使いどころ 複数のサーバからaccess.logなどのログ、my.cnfといった設定ファイルなどの同名ファイルを持ってくる場合 DNSラウンドロビンや、ロードバランサを利用していてアクセスログが分散している場合 通常何も考えずscpとかで持ってくるとファイルが上書きされてしまうので、 ホスト毎にファイルを分けて管理したい場合にpslurpが活躍します。 pipを利用してpsshの導入 2012年なんでeasy_i
こんにちは sato です。 ベンチャーでは高価なハードウェアバランサなどを購入することはできないですが、 apache2.2 から mod_proxy_balancerという apacheモジュールの ソフトウェアバランサが 追加されたので、フォト蔵でも使用しています。 今のところ proxy サーバがボトルネックになることはないです。 想定構成は以下とし、apacheは 2.x を使用しました。 proxy1 +------web1 +------web2 ... +------webN ・基本設定 httpd.conf LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so ProxyPass / ba
AWS ELBの社内向け構成ガイドを公開してみる 負荷分散編 – Cross-Zone Routingを踏まえて ｜ DevelopersIO
ども、大瀧です。 最近、お客さまからの問い合わせからElastic Load Balancing(ELB)の負荷分散について調べ社内資料としてまとめる機会がありました。せっかくなので、ブログ記事として公開してみます。内容は随時アップデートしますので、ツッコミ・ご指摘があればぜひお願いします！ 負荷分散の仕組み ELBは、クライアントのリクエストを受け付けEC2インスタンスにトラフィックを転送するために、2種類の負荷分散を組み合わせて動作します。 スケーラビリティと冗長性のために、ELBはロードバランサの機能を提供するノードを複数動作させるはたらきがあり、クライアントから複数のノードへアクセスを分散させるためにDNSラウンドロビン、ノードからEC2インスタンスへのトラフィック転送を分散させるためにLeast Connsという手法を用いています。 DNSラウンドロビン DNSラウンドロビンはそ
はじめに Nginx でロードバランサを構成する Webサーバ1号機の作成 Webサーバ2号機の作成 ロードバランサの作成 ロードバランサとWebサーバの起動 Web アプリケーションの準備 Docker でアプリケーションをビルドする DBサーバの準備 ロードバランサとアプリケーションサーバの起動 まとめ はじめに 前回は Docker のインストールからイメージビルド・コンテナ起動・Compose までの流れをみてきました。 blog1.mammb.com 今回は以下のような、一般的な Web アプリケーションの開発環境を構築していきます。 前回の記事とあわせて、Docker の活用方法を理解いただければと思います。 Nginx でロードバランサを構成する 最初に、単純な Web サーバを Nginx でロードバランシングする環境を作成して動作を見てみます。 このような構成となります。
チープな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
外からはなかなか評価されない仕事としてもう一つ大きいのがサーバーの仕事です。はてなのように、1ヶ月のUU（ユニークユーザー）数900万人、月間のPV（ページビュー）が10億PVを超えるサイトを運営するには、当たり前ですが相当なサーバーやネットワークが必要となります。 これまでこのサーバーやネットワークについては、「なるべく安く」ということを目標に構築してきました。売り上げが安定的ではないため、業績が悪化した際にリスクとなる固定費をなるべく減らしたかったからです。（ちなみにはてなは外部からこれまで資本を入れておらず、全て自分たちの事業で生み出した利益を元に設備投資を行ってきています。苦労して生み出した利益を使ってサーバーを買うわけですから、そのコストについて厳しくなるのは当然ですし、そのおかげでネットベンチャーには珍しく、完全自己資本でここまで会社を成長させることができました。ただ、自己資本
昨晩はライブドアで開催されたテクノロジーセミナーで軽くはてなのシステムや開発体制についてしゃべってきました。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/061214livedoor_hatena.ppt (ppt, 286k) 昨晩の感想、資料を読んでの感想など、トラックバックでお待ちしております。
MySQLのネタ。 １台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 １台目にマスターのＤＢサーバー、 ２台目以降をスレーブのＤＢサーバーとして用いる。 マスターは更新系のみのＳＱＬ文を、 スレーブは参照系のみのＳＱＬ文を投げる。 こんな負荷分散を１台のサーバーで行う必要が出てきた。 現在１台でやっていて、ディスクＩＯが追いつかずに捜し求めた結果、下の形で落ち着いた。 １つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをＡとする １：Ａと同じテーブル構成で、エンジンをMEMORY(he
(注意: 印はくまくまー調べなので鵜呑みにしてはいけません) [開発] Apache上での開発はまず無理である。WEBrick は Ruby標準な上に最低限の機能・スペックは満たしているので未だに愛用者は多く、Rails初学者には十分である。WEBrickの速度に限界を感じたユーザは Lighttpd(愛称 lighty)を利用する。速度も十分でや設定も容易だが、起動時の引数でポートを指定できないなど若干使いづらい面もある。lighty ユーザは Mongrel に進むという予言もある。 [運用] Webサーバのデファクトはやはり Apache で、Rails的には生CGIは無理だが、FastCGIなどのモジュールと併用することで速度的な問題はなくなる。RailsはLighttpdなどの開発向けのサーバで動かし、リバースプロキシを利用する手もある。完全に Rails のみで運用されるサイト
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。（編集部） Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
ブラウザキャッシュでパフォーマンス向上
キャッシュ制御の方法 サーバサイドからキャッシュを制御するには、以下の2つの方法がある。 HTTPヘッダによる制御 METAタグによる制御 まずは、これらがどのようなものか、軽くおさらいしておく。 ■HTTPヘッダによる制御 HTTPプロトコルでは、HTTPヘッダにさまざまな情報を格納することができる。そのうちいくつかの情報は、キャッシュ制御のためのヘッダである。リクエスト（クライアント→サーバ）用のものと、レスポンス（サーバ→クライアント）用、リクエスト／レスポンス共通のものが存在する。 ■リクエスト用 If-Modified-Since 日時を指定する。指定した日時より新しいコンテンツの場合のみデータを返却するようにサーバに指示する。ローカルキャッシュの最新確認に使用される If-None-Match 指定したエンティティタグに一致しない場合のみコンテンツを返却するようにサーバに指示す
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
KOF 2008 の発表資料 - naoyaのはてなダイアリー
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
「感情の共有」，「負荷との戦い」---ニコニコ動画の技術：ITpro
WEB+DB PRESS Tech Meeting ［資料＆動画］｜gihyo.jp … 技術評論社
実践！ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
＠IT Special PR：600億PVもMySQLで！ モバゲーのインフラ底力
tcpdumpとiptablesの関係 - （ひ）メモ
KeepalivedによるロードバランサLVS構築 - RLB
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
Cerevo TechBlog - (株)Cerevoの中の人が書く、様々な技術情報を発信するBlog.
快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう！
GLB: GitHub's open source load balancer
Apache のリバースプロキシの設定方法 - WebOS Goodies
ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ネットワーク編)
livedoor Techブログ : nowaのサーバ構成
LinuxでL4のロードバランサを簡単に作る手順 - Qiita
仮想サーバの構築(VMware Server: WindowsXP編)
＠IT：パケットフローから負荷分散の基本を理解する
全銀システムの大規模障害、中継コンピューター2台ともに不具合で冗長構成が機能せず
複数のサーバから一斉にファイルを収集するのにpslurpが便利 - Glide Note
ウノウラボ Unoh Labs: mod_proxy_balancer 小技集
Docker でロードバランサ・アプリケーションサーバ・DBサーバの環境構築 - A Memorandum
(ひ)メモ - そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか
速くて落ちないサービスを提供する - jkondoの日記
naoyaのはてなダイアリー - ライブドアのテクノロジーセミナーでしゃべってきました。
１人で稼ぐ日記 | MySQL：１台しかない環境でエセ負荷分散
LiteSpeed
Poundで作るロードバランサとSSLラッパ（1/4） ― ＠IT