平素より「PHPプロ！」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ！」ですが、サービスの利用状況を鑑みまして、2018年9月25日（火曜日）をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日（火曜日）を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
そのときの発表資料と音声を公開します。 発表資料(PDF 1532KB) 音声(MP3 57350KB) ※音声はボリューム最大にしないと聞こえないかもしれません・・ごめんなさい ※資料はPDFに変換しているのでアニメーションがありません・・ごめんなさい 内容は DSASの設計思想 かたっぱしから冗長化 NICを冗長化してみよう L2SWを冗長化してみよう WEBサーバを冗長化してみよう ロードバランサも冗長化しよう メンテナンス性を重視したネットワーク構成 VLANの紹介 タグVLANの紹介 LinuxでもタグVLAN DSASの構成 フロントエンドサービス向けサーバ群の特徴 マスタサーバの特徴 Webサーバの特徴 こんな感じになっています。 おかげさまで多くの方にご参加いただき、盛況のうちに終了することができました。 懇親会もとても楽しかったです。 今回の反省点としては、、 「あれこれ
さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸
Weblioという人気サイトがある。調べたい用語の意味を，200以上の辞書から一度に検索できるサイトだ（参考記事，参考リンク）。2007年2月の実績は，900万ページ・ビュー，120万ユニークIPアドレスを誇る。驚くべきことに，このサイトのすべてのシステムは，ウェブリオ（Weblioを提供している会社）社内に設置された40～50台の中古パソコンでできている（写真1）。 このシステムをほぼ1人で作り上げたのが，ウェブリオ取締役最高技術責任者の佐々木亨氏（写真2右）である。ウェブリオに投資し，同社の社外取締役も務める紀信邦氏（写真2左）は「佐々木氏がいなかったら投資しなかった。彼がいなかったら，同じ事業をするのに10倍のコストがかかる」と語る。佐々木氏は，ハードウエア，ソフトウエア，ネットワークのそれぞれについて豊富な知識を持つ。「特にネットワークに強いのが大きい」と紀氏は評価する。 ウェブリ
先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
はてブで lighty のブログがあることを知ってブログを見てみました。lighty の中の人が書いてます。 ナント、lighty 1.5 系が pre release されているではありませんか！ なんでも、1.5 系は いままでより 80% のスループット向上が見込めると書かれています。激速の lighty が更に高速になるってわけですよ。Σ(ﾟДﾟ； Using Async IO allows lighttpd it overlap file-operations. We send a IO-request for the file and get notified when it is ready. Instead of waiting for the file (as in the normal sendfile()) and blocking the server, we ca
2004 年の春ごろ、情報学類の WORD 編集部 (学類誌編集部) にいたら、情報学類に新たに入学してくる予定の人達に入学前に配布する冊子「引越し準備号」に、原稿を書いてくれと誰かに頼まれました。 それで、すでに大学の宿舎に住む人のための生活ガイドみたいなのは誰かが書き始めていたので、私は、宿舎ではなく大学周辺のアパートかマンションに住む人向けの生活ガイドというのを書くことになったのです。 そこで書いた原稿のファイルが HDD から発掘されました。 ちなみに、よく覚えていませんが、この記事以外の全てのページは「宿舎での生活に必要な知識」とか、「大学の近くのスーパー・コンビニの一覧」だとかいった真面目なコンテンツばかりでしたので、ひょっとしてこのおかしな記事を読んで本気でこういうことをする新入生が出てくるのではないかと期待していましたが、残念ながらそういう人はあまりいなかったようです。 2
2006年10月28日22:30 カテゴリTips クローラにしかとシカトしてもらう50の方法 というわけで備忘録代わりに。 Apache: The Definitive Guide [邦訳:Apacheハンドブック] [を] Yahoo! Slurp に rel="nofollow" を無視されたYahoo! Slurp に一斉にアクセスされてサーバのロードアベレージが激ヤバ。 とりあえず、CGIスクリプトのファイル名を変更して回避。robots.txt 最も基本的なのがこれ。たつをくんがこれを知らないはずはないのだけど一応基本からということで。 robotstxt.org Robots Exclusion Standard - Wikipedia, the free encyclopedia http://www.dan.co.jp/robots.txt ちなみに最後のワイルドカードを
mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースを食いつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー
まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
ドキュメントを読まない輩 結論: ぐぐるな。ドキュメントに書いてあるとわかっているのになぜ google に頼る? 巷間でよく見られる、しかし Apache の配布アーカイブ一式に含まれているドキュメントをちゃんと読んでいれば起きないはずの設定ミスや、ミスではないがふしぎな設定について。 <Limit>: セキュリティ上のリスクがあるのですみやかに確認・修正されたし AddDefaultCharset: 穴ではないが修正が必要 LanguagePriority: ほとんどのサイトでは無意味 ScriptAlias: 管理者でなくエンドユーザがハマるのはしかたないけれど SetEnvIf: どこも間違ってはいないのだが… Apache のドキュメントは日本語未訳なところが一部残っているけれど、全体として非常によくまとまった情報源である。少なくとも、「このディレクティブをどう設定するとどう動く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
