[ニュース] はてななどの各社担当者が自作サーバーのノウハウを紹介
はてなやサイバーエージェントなど、5社の担当者が自作サーバーに関するメリットやデメリット、ノウハウなどを紹介する「自作サーバカンファレンス」が11月25日に開催された。 自作サーバーのメリットといえば、コストダウンがもっともわかりやすいメリットだったが、最近ではベンダー製サーバーの価格低下やクラウドサービスも充実し、コスト面では以前ほどの価格差はなくなってきている。しかし、「まだまだ自作サーバーの可能性は豊富にある」ということで、はてななど自作サーバーを利用するITベンチャー5社が自社の導入例をもとにメリット・デメリット、ノウハウなどを紹介するカンファレンスを開催した。 カンファレンス冒頭に登壇した、株式会社はてなで執行役員を務める田中慎司氏は「はてなでは設立当初から自作のサーバーを使ってきているが、ここ最近を見ると他社でも自作サーバーを使用するケースが出てきている」とコメントした。 また
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
グーグルの最新のデータセンターは非常識なほど進化している
昨日はITpro主催のイベント「ユーザー企業のためのエンタープライズ・クラウドフォーラム」に参加してきました。 日経コンピュータ 中田敦記者のセッション「みえてきたクラウドのコスト」では、グーグル、アマゾン、マイクロソフトの最新データセンターの動向を紹介してくれたのですが、これが非常に興味深い内容でした。セッションの内容からトピックを2つほど紹介します。 大規模データセンターは7倍効率がよい 1つ目は、日経コンピュータ2009年7月8日号で同記者が記事としても書いていることなのですが、データセンターの規模の経済について。1000台クラスの中規模データセンターと、5万台クラスのデータセンターを比較すると、大規模データセンターのほうが7倍も効率がよいというデータが示されています。 つまり、ユーザーがある大きさのコンピュータリソースを調達しようとするとき、大規模データセンターは中規模データセンタ
ECサイトから65万人の情報漏洩 20人が70時間，不眠不休で対応
1. 8万のカード情報を含む65万人の個人情報が漏洩し，セキュリティをいちから見直した 2. 漏洩が判明した直後は延べ20人が3日間，夜を徹して作業に当たった 3. カード情報の管理を第三者に任せ，WAFを導入するなど安全性を高めた 「えらいことになってしまった。覚悟せなあかんな」。 2008年7月10日の深夜のこと。アウトドア用品や釣り具の販売で年間40億円を売り上げるECサイト「ナチュラム」を運営するミネルヴァ・ホールディングス（当時の社名はナチュラム，8月1日に持ち株会社として改称）の中島成浩氏（代表取締役会長兼社長CEO）は，創業以来の危機に直面していた。ナチュラムのサイトから，クレジットカード情報を含む個人情報がほぼ確実に漏洩していたことが判明したのだ。大阪市中央区の本社会議室に集まったメンバーは皆青ざめていた。 まず取り組んだのは被害の拡大を防ぐこと（図1）。丸3日間で一気に対
mod_securityでWebサーバを守る(第1回)
一体、Webサイトを持たない組織は今どれくらいあるでしょうか。 Webサーバを自前で持つ、ホスティングサービスを利用する、など運用形態はさまざまですが、Webサイトを持たない組織はほとんどないと思える程に Webは普及しています。 ファイアウォールはほとんどの組織で導入済みであり、多くのWebサーバはファイアウォールの中で運用されているのが一般的です。 しかしながら、最も普及しているファイアウォールはIPアドレス、ポートレベルでのフィルタリングです。この方法でのフィルタリングでは、許可していないサービスが持つ脆弱性を狙った攻撃を阻止できるため有用ではありますが、HTTPを許可している場合Web自体への攻撃に対して無力です。一方で、HTTPを不許可にした場合にはWebサイトへアクセスできなくなってしまうため本来の目的を達成できません。しかもここ数年、Webサイトを狙ったワームや不正アクセスは
Firefoxからsshのダイナミック転送を使って非公開サーバへアクセスする - 射撃しつつ前転 改
sshにはダイナミック転送という機能がある。この機能を使うと、sshはアプリケーション側にはSOCKSプロクシとして振る舞うが、そこからsshの接続先までは暗号化された状態で通信が行われる。 これだけだと通常のトンネリングとどう違うのかよくわからないかもしれないが、ダイナミック転送の場合は転送ポートを指定する必要がない。ここがダイナミックと表現される所以だろう。 例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これまではsshのトンネリング機能を使ってアクセスしてきたのだが、ウェブアプリケーションをデバッグする際はいちいちウェブアプリケーションのポート毎にトンネルを掘るのが面倒くさい。オフィスに限らずデータセンターへ
グーグル、自社設計のサーバを初公開--データセンターに見る効率化へのこだわり - CNET Japan
カリフォルニア州マウンテンビュー発--Googleは、自社のコンピューティングの運用については多くを語らない。しかしGoogleは米国時間4月1日、当地で行われた、注目度が高まっているデータセンターの効率性に関するカンファレンスで、そのインターネットの力の中枢にあるハードウェアを初めて公開した。 ほとんどの企業は、DellやHewlett-Packard（HP）、IBM、Sun Microsystemsのような企業からサーバを購入している。しかしGoogleは、何十万台ものサーバを保有していて、そのサーバを稼働させることが自社の中心的な専門技術の一部だと考えており、自社独自のサーバを設計および構築している。Googleのサーバの多くを設計したBen Jai氏は、高度な技術を持つ、非常に熱心な聴衆の目の前で、現在のGoogleサーバを公開した。 Googleサーバで非常に驚くのは、サーバ1台
さくらインターネットサーバでのCPAN導入を完全に手順化して見た - Perl入門ゼミ
Perl › 環境構築 (この記事の内容は古くなっています、現在はcpanmを使ってモジュールをローカルにインストールするのが簡単でしょう。cpanmによるローカル環境構築を見てください。) otsuneさんのところでさくらインターネットのレンタルサーバでCPANを使用する方法が紹介されているのですが、一部手作業が発生するので、すべてコピペで実行できるように手順化してみました。 さくらインターネットサーバcpan導入手順 # ライブラリのためのディレクトリの作成 mkdir -p ~/local # CPANの設定ファイルを作成 echo no | cpan # cpanコマンドの設定ファイルMyConfig.pmの書き換え # ( __END__の行まで一気にコピーして実行してください。とまった場合はEnter ) perl - ~/.cpan/CPAN/MyConfig.pm > ~/
CPANモジュールをスクリプト一発で依存解決しつつrpm化する - とあるはてな社員の日記
少し前にmizzyさんに そういえば、まっさらなサーバを30分で本番投入できるようにする で stanaka さんが「CPANの依存関係を解析してrpm化する手製スクリプトで、CPANモジュールのrpm化が、ほぼ自動化されています」と書いてるんだけど、これって公開してくれないのかなー。 HowToRpmizeCpanModules - mizzy.org - Trac と突かれたので、githubで公開してみます。 http://github.com/stanaka/cpan-dependency/tree/master 突かれたついでにmizzyさんに軽く動作確認してもらったところ、それなりに動いているようです。また、はてなでは、このスクリプトを利用して、日々それなりの数のCPANモジュールのrpm化を行っていますので、だいたいうまく動くのではないかと思います。 CentOSやFedor
IPv6 とかよくわからない人間が IPv6 対応サイトを作る際の知っておくべき 8 つの注意点 : にぽたん研究所
先日、一般や企業向けに IPv6 対応を支援をする、EDGE Co.Lab v6 というのを始めました。 これを始めるにあたって、弊社情報環境技術研究室の伊勢さんから、「なんかウチでやってるコンテンツで、どれか IPv6 対応しようよ」と、いきなり言われました。 実は IPv6 って何年も前からよく耳にするけど、特にインフラまわりの知識が拙いし、何だかんだ身の回りのほとんどが IPv4 で、それでまぁウマくいってるからよくわからないし、別にどうでもいい…と、IPv6 に対して「現実味がない。時期尚早なのでは？」みたいな勝手な印象を抱いて、毛嫌いしてました。 伊勢さんは 2ch の IPv6 板とかを立ち上げたらしく、IPv6 でアクセスすると、トップページのひろゆきが踊って表示されるそうです。 IPv6 と IPv4 の差って、ひろゆきが踊るか踊らないかの差だけ？とか、そうじゃないのをわか
スケーラビリティとユーザービリティの話
先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。 サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。 限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。 たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前
第1回 memcachedの基本 | gihyo.jp
株式会社ミクシィ 開発部 システム運用グループの長野です。普段はミクシィのアプリケーション運用を担当しております。今回から数回にわたり、最近Webアプリケーションのスケーラビリティの分野で話題になっているmemcachedについて、弊社開発部 研究開発グループの前坂とともに、使い方や内部構造、運用について解説させて頂きます。 memcachedとは memcachedは、LiveJournalを運営していたDanga Interactive社で、Brad Fitzpatrick氏が中心となって開発されたソフトウェアです。現在ではmixiやはてな、Facebook、Vox、LiveJournalなど、さまざまなサービスでWebアプリケーションのスケーラビリティを向上させる重要な要素になっています。 多くのWebアプリケーションは、RDBMSにデータを格納し、アプリケーションサーバでそのデータ
さくらインターネットでSubversion
[p.s.] 2007-04-15 Subversion 1.4.0以降について少し補足しました。 – さくらインターネットでSubversionの補足。 cvsは入ってるんだけどSubversion使いたい→でも入ってない→じゃぁ自分で入れるか→Portsの使い方がワカラン てことで、調査に数時間を費やし、結局「make install」で「あんたはwheelグループじゃないからダメ(当然だ)」的なことを言われしょげてたんですが、どうせ入れたいのはSubversionだけなんだからパッケージ管理なんていらないしソースから入れればいいんじゃない？ってことに気が付き実行。 あっさり使えるようになりました。以下に手順。コピペで実行すれば、「$HOME/local/bin」にインストールされます。 $ mkdir -p $HOME/local/src $ cd $HOME/local/src $
Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Availability)
« brainf*ck でマジメに素数探索 | メイン | Brainf*ck で動的リスト » 2006年06月29日 DNS ラウンドロビンと高可用性 (High Availability) ウノウラボ Unoh Labs - ベンチャー流サーバ構築のススメ(ネットワーク編) について。 おもしろく読ませていただきました。また、監視系を導入せずに自律的に動作させようという発想も大好きです。 でも、 DNSは各回線の内側に設置しておきます。例えば上図のような場合、回線A側のDNSは回線AのIPアドレスを返すようにして、回線B側のDNSは回線BのIPアドレスを返すようにします。こうするとどちらかの回線が切れたときは切れたほうの回線のDNSにアクセスできなくなるので、自動的に生きている方の回線に接続されるようになります。 (ウノウラボ Unoh Labs - ベンチャー流サーバ構築のススメ(
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
Googleで○○と検索すると○○：実用編
Notify::Pizzaネタ、大人気です。びっくり。 http://b.hatena.ne.jp/entry/http://e8y.net/blog/2006/07/25/p126.html http://d.hatena.ne.jp/textfile/20060725/pizza http://del.icio.us/url/4b67a8710066baf05fab3c8d253ff02d わくわくさせてくれるフレームワーク Plagger と、おもしろいことをするための言語 Perl に多くの人が興味を持つことになってくれたのなら、わざわざ面倒な方法でピザ頼んだかいがあったというものです。 OSCON での miyagawa さんによる Plagger のプレゼン にもネタとしていれてくださるということで、タイミング的にもよかった。外人にわかりやすく寿司じゃなくてピザにしておいてよか
selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理
Squid2.6 のCOSSがいい感じ : blog.nomadscafe.jp
Squid2.6 のCOSSがいい感じ Squidの比較的新しいcache_dirのCOSSが結構いい感じに動いている。 COSSだと、cache objectが１つの大きなファイルに納められるので、ディスクIOがかなり改善しています。 あまり情報がないのですが、Wikiに設定の説明と、aufsとの比較とかがあります。 cache_dir coss /var/spool/squid/coss 30000 block-size=2048 max-size=500000 cache_swap_log /var/spool/squid/%s こんな感じの設定のサーバで、cache個数 50万ファイル以上、最大リクエスト数500req/sec以上、Hit rateが99%の状態において、CPU負荷がUser:数%、iowait:1%弱とかで推移。もうちょっとcache個数の多いサーバでもiowai
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://techrepublic.com.com/2300-10879_11-6079378-1.html