[ニュース] はてななどの各社担当者が自作サーバーのノウハウを紹介
はてなやサイバーエージェントなど、5社の担当者が自作サーバーに関するメリットやデメリット、ノウハウなどを紹介する「自作サーバカンファレンス」が11月25日に開催された。 自作サーバーのメリットといえば、コストダウンがもっともわかりやすいメリットだったが、最近ではベンダー製サーバーの価格低下やクラウドサービスも充実し、コスト面では以前ほどの価格差はなくなってきている。しかし、「まだまだ自作サーバーの可能性は豊富にある」ということで、はてななど自作サーバーを利用するITベンチャー5社が自社の導入例をもとにメリット・デメリット、ノウハウなどを紹介するカンファレンスを開催した。 カンファレンス冒頭に登壇した、株式会社はてなで執行役員を務める田中慎司氏は「はてなでは設立当初から自作のサーバーを使ってきているが、ここ最近を見ると他社でも自作サーバーを使用するケースが出てきている」とコメントした。 また
Last.fmがサーバにSSDを導入、分散ファイルシステムもSSD対応にしてスケール向上に成功！
音楽配信サイトのLast.fmは、今年の10月からXbox Liveでも利用できるようになったことを受けてユーザー数が大幅に増加。これに対応するためサーバにSSDを採用したところ、問題なくスケールの向上に成功してしまったことをブログ「Launching Xbox, Part 2 - SSD Streaming」で明らかにしています。 SSDで同時接続数が300から7000に増加 Last.fmはこれまで7200rpmのSATAドライブをバックエンドに利用。ファイルシステムとしてオープンソースの分散ファイルシステムであるMogileFSを採用していました。 オーディオストリーミングの能力は基本的にこのMogileFSの管理下にあるハードディスクのランダムI/O性能に依存しており、現在は1つのハードディスクあたり約300同時接続をサポートしていたとのこと。 しかしXbox LiveがLast.
PerlbalでMogileFSを更に高速化、効率化する - builder by ZDNet Japan
MogileFSのさらなる高速化、効率化 前回「MogileFSで構築する高速スケーラブルな分散ファイルシステム」では、moonlinxで活用しているMogileFSについて説明しました。今回はMogileFSの更なる高速化、効率化を追求してみましょう。 MogileFS活用のために、まずは問題点を把握 素のMogileFSをそのまま利用した場合、ファイルにアクセスするために、クライアントが毎回trackersへ問い合わせをすることになります。これは、trackersはデータベースに全ての情報を格納しているので、毎回データベースを参照することを意味しています。 moonlinxでは、作品メディアファイルのサムネイルも含めてMogileFSに保存しています。そのため、サムネイルが多い画面では1つの画面を表示するために、数十回ほどMogileFSへアクセスすることになります。 trackers
MogileFSで構築する高速スケーラブルな分散ファイルシステム - builder by ZDNet Japan
本連載「オープンソースソフトウェアでクリエイターを支援するmoonlinx」の第1回「ウェブメディア「moonlinx」を支えるオープンソースソフトウェア」ではmoonlinxの概要およびシステム構成を、第2回の「openSUSEの管理ツール「YaST」で作業を効率化：moonlinxを支えるOSS」では使用OSであるopenSUSEについて簡単に説明しました。 今回は、moonlinxで取り扱うメディアファイル（画像、音楽、動画）の保管方法について説明したいと思います。 分散ファイルシステム「MogileFS」 moonlinxでは、各種メディアファイルの保管に、オープンソースの分散ファイルシステム「MogileFS」を利用しています。 分散ファイルシステムを用いることにより、ファイルシステムを構成するノード群の一部がダウンしても、データを失うことなくシステムとして機能し続け、かつ自動レ
MogileFSの利用と高速化 » SlideShare
MogileFS+Perlbalな運用形態におけるX-REPROXY-URLの活用と、X-REPROX-CACHE-FORを使ったサーバレスポンスの高速化、サーバの負荷軽減についてRead less
第13回 MongoDBの性能 | gihyo.jp
はじめに 前回、前々回とMongoDBの非機能面に着目してきましたが、今回も非機能に着目して、MongoDBの処理性能について説明します。まず前半では、MongoDBの動作の中で処理性能に影響を与える動作を説明します。それをふまえた上で、後半では処理性能をどのように上げるかを説明します。 なお、今回はMongoDBを単体で使った場合の処理性能を考えています。レプリケーションやシャーディングを行った状態の処理性能については対象外とさせていただきます。 処理性能にかかわるMongoDBの動作 データアクセス MongoDBがどのようにデータにアクセスするかは、MongoDBの処理性能を考える上で非常に重要です。 MongoDBではデータファイルを仮想メモリにマッピング（Linuxではmmapという機能を利用）し、MongoDBのプロセスは仮想メモリにアクセスします。図1のように、アクセスするデ
時系列データとMongoDB2.4の新機能Hash based sharding - 中年engineerの独り言 - crumbjp
実は数年前（MongoDB 1.6〜1.8の時期）にログをリアルタイムに全てmongodbに叩き込んで期間毎に解析する仕組みを作ろうとして挫折した事がある。 理由は幾つかあったのだが主に cappadコレクションでは解析時の負荷とログ投入負荷が重なってしまう。 → 最終的には書き込みが負けてoplogが溢れる。 時系列カラムをshard keyにするとchunk migrationが辛すぎる。 そもそもshardingの信頼性が・・・ という理由だった。 今ならストレージエンジンが早くなったし再挑戦しても良いかもしれない。 ログは非同期に準リアルタイムに拾って投入。 出力元＋時間でshard key。 なるべくグループコミットの効率が上がる塊を作る。 とか、、 お題 ともかく、今回は 時系列データを投入した時chunk migrationがどう動くのか？ の話。 そもそも時系列カラムをsh
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
RRDtool の使い方
このblogは、著者である「sakito」が技術的に生存している事を報告するために存在します タイトルを「紹介マニアどらふと版」から変更しました 概要 「RRDtool」は時系列データを高速にロギングしたり、グラフ化するためのオープンソースのツール。 「Munin」等のツール経由で利用する機会が多い。 ほとんどコマンドラインから利用しないので使い方をちゃんと調べた事がなかったのだけど、Munin で高度なグラフが必要になる機会が増えてきたので、ちゃんと調査してみることにした。 インストール Mac であれば MacPorts なり homebrew なりでインストールするのが楽。この記事を書いている時点では「1.4.7」がインストールされる。 コマンドの引数は以下。 filename:ファイルの名前。通常拡張子を「rrd」にするが、特に拡張子は関係ない。 --start:記録開始とする時刻
mongodbの真の売りは性能にあらず
主にfacebookにつぶやきまくる毎日。 noteとかzenn.devにも書いてるので、こっちはあんまり更新してません。 最近あんまりmongodb触ってません。 以前の案件でのmongodbは近日停止しちゃうし、現在従事してる案件はredisです。 なんでredis？っと思いましたが、半年も前から決めちゃってる話で、 性能で選んだらしい。色々調べてみるとそれなりには納得。 http://blog.brandonc.me/2011/11/memcached-vs-redis.html 色々まとまってるのは上記ですね。中国語ですが。 #自分で測定する時間と元気は今はありません。済みません。 性能測定上は、redisはmongodbより3倍速いってことなのでしょう。 実際そうなのでしょう。 ただしmongodb経験者からみると、redisは機能が低すぎてビビります。 「データベース番号」とか
仙人掌世界: Memcached vs Redis vs MongoDB vs MySQL 效能比較
"記憶體是新一代的硬碟"在高流量網站內已是稀鬆平常的事情，像是採用 Memcached 做分散式快取服務即是典型的應用模式，Memcached 使用概念簡單且相關應用情境、文件、工具、演算法都已相當成熟，許多知名網站都運用 Memcached 提升scalability，像是GAE、Heroku 等PaaS 環境也有提供 Memcached 的收費服務，這些市場訊息已說明大規模的使用記憶體是可以合乎成本效益的。 Redis 是近年隨著 NoSQL 熱潮出現的 Key-Value store，其功能涵蓋了 Memcached 並且提供許多高階功能，在許多應用情境下相較 Memcached，能降低開發與營運複雜度，比如： 豐富的資料結構(strings, hashes, lists, sets and sorted sets) 更易於設計適當的資料粒度增進資料重用的機會，且可依不同的資料結構特
本当にあったredisの怖い話
主にfacebookにつぶやきまくる毎日。 noteとかzenn.devにも書いてるので、こっちはあんまり更新してません。 出稼ぎのとある案件で、redisを使ってますが、色々ヤラれますね。 運用面 スキーマ(に相当する概念)を、整数で管理しなければならない 故に、DBを取り違えても、書き込めてしまう。 書き込み先DBを間違えてることに、果たして何時気がつくやら。 端的に言えば、複数のredisインスタンスを使い分けるような運用を想定してないのでしょう。 逆に言えば、そんな使い方するならredisを選択するのが間違ってます。 バックアップは、永続ファイル1個をコピーするしかない。 逆にいうと、バックアップが必要になるような運用にredisを選択するのが間違ってます。 appendonly=true は永続ファイルを壊す可能性は減るが 実はジャーナルなので、永久に増え続ける。 長期運用すると
Mouse::Util::TypeConstraints等を使って新しい型を定義するときのベストプラクティス - 時計を壊せ
更に追記 MouseX::Typesですが、その後検証してみたかんじ、 要素を「=>」で繋げてしまうと左辺が文字列として認識されてしまうようなので、 要素を「,」で繋げなければいけないようです。 等価だと思っていましたが微妙に違うんですね。 package HogeProject::MouseType; use strict; use warnings; use utf8; use MouseX::Types -declare => [qw/UInt/]; use MouseX::Types::Mouse qw/Int/; subtype UInt, as Int, where { $_ >= 0 }; 1; 追記 id:gfxさんによるとMo[ou]seX::Typesがまさにそんな機能を持っているとの事。知らなかった！ http://search.cpan.org/~gfuji/Mou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
省サーバ運用
JSON-RPC
GitHub - oetiker/rrdtool-2.x: RRDtool 2.x - The Time Series Database
おっさんは若者から搾取しないと人生が維持できない(山本一郎) - 個人 - Yahoo!ニュース
GitHub - livedoor/Sledge: ancient Perl Web Application Framework.
Kotlin Repojitories