e-trees.Japan | 製品概要 freeocean
いよいよWeb2.0時代の幕開けです。製品名：freeoceanは、これまでのネットワーク機器に 求められた複雑なシステムを抜本的に改善。シンプルで高性能なオールインワンパッケージ 化により、高速・大容量のパフォーマンスを発揮しながら設置スペース・運用・管理を大幅 に簡素化します。これからのWeb2.0の時代にfreeoceanが効率的なシステム構築を実現しま す。動画配信、SNS運用、Blog配信、freeoceanならフレキシブルで広範な対応が可能です。 お客様の”次”の情報配信にぜひともお引き連れください。 freeoceanがついにIPv6(Dual Stack)に対応！ freeoceanは、ネットワーク機器の概念を変えます。これまでの負荷分散装置、キャッシュサーバ、Webサーバ群に必要なシステム構築をなんと機器1台で実現します。集中アクセスの処理を同時50万アクセスまでfree
ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ネットワーク編)
尾藤正人です。 前回のエントリ ベンチャー流サーバ構築のススメ(ハードウェア編) では多くのコメント、トラックバック、ブックマークをしていただきました。ありがとうございます。僕自身多くのことで勉強になりましたし、新たな発見もありました。 技術は公開、共有して発展するものだと思っていますので、自分の無知をさらけ出すのを恐れずにいろいろ公開して、自分自身も成長していければと思っています。 今回はサーバ構築するときのトピックとして、どのようにネットワークを構築したかを書いてみます。 サーバ構築に限ったことではありませんが、重要なのは質を下げずにコストを下げることです。ネットワーク部分でお金がかかるのは回線ぐらいですから、ネットワーク周りで重要なのは人的コストを下げること、つまり管理コストを下げることです。 ・回線は2回線以上用意する 2回線以上用意するのは高可用性を確保するためです。通常は全ての
GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
というわけで、再び負荷を下げる方法を模索した、戦いの記録。 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サーバのハード
cyano: 30万個ぐらいの静的ファイルを配信するサーバーの選び方
naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 弊社の画像配信サーバーには、平均10kbぐらい（たぶん）の画像が30万個ぐらいあって、それをDell PowerEdge 1750+lighttpdを使って配信してます。 以前は搭載メモリ1GBのサーバーを使っていたのですが、その時のvmstatがこのような感じ。 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b sw
動画配信の負荷分散は比較的簡単 - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/naoya/20060407/1144376197 ではてなおやさんがYouTubeの負荷分散について語っておられる. mixiの負荷分散とは質が違うことについてはおおむね同意だけど, YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信にリソースがいるポイントは、ネットワーク帯域とディスク I/O です。つまり YouTube の負荷分散で気になるところは * ネットワーク帯域 * ストレージ o 容量の管理 o 動画を格納しているストレージサーバーの I/O あたりです。 はちょっと踏み込み足りないなぁという印象なので書いておく.集合知.集合知. 動画配信は通常の画像配信と違って下記の特性を持つ. 画像のように1ページに複数個配信する
ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ハードウェア編)
尾藤正人です。 ウノウでは最近新オフィスに引越ししたのですが、新オフィスにサーバルームを設置してフォト蔵のサーバをホスティング業者から自社サーバに移行しました。 自社サーバに移行のは下記のような理由からです。 フォト蔵のようなストレージ系のサービスの場合、十分な帯域を確保する必要があるが、広帯域を確保するにはコストがかかる フォト蔵のようなストレージ系サービスの場合、大容量のHDDが必要になるが、大容量のHDDを搭載したマシンはハイエンドマシンになり、増設コストがかかる マシンの増設に時間がかかりフレキシブルに対応できない というわけで自社サーバに移行したわけですが、自社サーバに移行するにあたって様々なノウハウがたまってきました。 サーバ構築にはいろいろトピックスがありますが、今回はハードウェア的な部分について書きたいと思います。 ・マシンは全て同じ構成にする 数多くのサーバを運用するに
[ThinkIT] 第3回：データレプリケーションとWebサーバの構築の基本 (1/4)
今回はRHEL4でrsyncコマンドを使ったデータレプリケーションによるバックアップ環境の構築方法について解説します。 rsyncコマンドを使ったデータレプリケーションは、LAN経由によるDisk To Diskバックアップとも呼ばれています。これはバックアップ対象のサーバとバックアップサーバがLANで接続されており、バックアップサーバ側はテープ装置ではなくハードディスクにバックアップデータを保管するからです。 この接続しているLANは、通常だと業務用のLANとは別にバックアップ専用のLANを敷設し、その専用のLAN経由でrsyncコマンドを実行します。 rsyncコマンドの利点は、なんといっても差分バックアップが可能という点です。 はじめにフルバックアップを取っておけば、次回以降では差分バックアップを行うためバックアップ時間は初回時に比べて非常に短くなります。そのためデータ容量が大きくて
GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
負荷対策概論 - Y-110's Wiki
最新文章 2018-12-26 17:10▪ 致敬英雄，致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发！上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞："吃出卫生巾"系人为当事顾客
DSAS開発者の部屋:サーバ管理者向け無精のすすめ 〜ちょっと便利なツールの紹介〜
弊社のLinuxサーバ、ネットワークインフラのDSASの特徴のひとつに、100台近くある全てのサーバの内容が(数個の役割設定ファイルを除いて)同期されているという点があります。 これにより、 スケーラビリティ 予備機をサービス投入するだけで済むので、テレビCMなど突発的な高アクセス時にも迅速な対応が可能です。 増強が容易 サーバをラックマウントしたら適当なサーバからまるまんまコピーすればクラスタに参加可能です。まとまった台数の増強をする際に、いちいちCD-ROMからOSをインストールしていると日が暮れちゃいます。 役割の変更が容易 ディスクの内容が同じなので、もし、メールサーバが故障しても、適当なWebサーバの役割設定ファイルを変更して再起動するだけでメールサーバに早変わりできます。 メンテナンスが容易 ディスク上のファイルを更新した場合は、rsyncなどで全サーバに同期コピーすれば更新完
PHPのスケーラビリティとパフォーマンス:phpspot開発日誌
Digg PHP's Scalability and Performance - O'Reilly ONLamp Blog This article addresses the all-to-common false assumptions about the cost of scalability and performance in PHP applications. PHPのスケーラビリティとパフォーマンスに関する記事。 Digg等に関して等いくつか面白いことが書いてあった部分のメモ JobbyはWASPフレームワークで書かれている Diggは１ヶ月で２億ＰＶ Diggは３台のウェブサーバー＆８台のＤＢサーバーで構成されている DiggはＡＰＣ、ＭＣａｃｈｅを使っている DiggやFlickrのような大規模なアプリを１，２人で安くメンテでき、かつ素早く構築するのにPHPは適している
naoyaのはてなダイアリー - YouTube の負荷
なんつったって動画ですよ。 ブログとかmixi日記のようなテキストレベルのコンテンツに比べて、はるかにサーバーにかかる負荷は高いはずです。 YouTube と mixi を比較して "負荷" の話をしていて、「動画配信だから負荷が高い」と断定していますが、これは何を"負荷"とするかにもよるかなと思います。 "負荷" というと CPU load や I/O などリソースの消費っぷりを指す言葉というイメージがありますが。(一般的には違うものでしょうか?) そういう意味での負荷で言ったら、「YouTube = 動画 / mixi = テキストだから YouTube の方が負荷が高い」という断定はやや微妙です。負荷の種類が違うのです。 YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信に
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 YAPC::Asia 2006 Tokyo 東京都大田区で開催されているPerl技術者向けカンファレンス「YAPC::Asia 2006 Tokyo」で2006年3月29日，日本最大のソーシャル・ネットワーキング・サイト（SNS）である「mixi」を運営するミクシィのBatara Kesuma（バタラ・ケスマ）取締役最高技術責任者（CTO）が，増え続ける膨大なトラフィックにどのように対処してきたのかについて講演した。カギとなるのは「データベース分割」である。 mixiのシステムはもともとBatara氏が1人で作り上げたものだ。2003年当時，米国でFriendsterなどのSNSがはやっており，同氏が会社（現在のミクシィ，当時はイー・マーキュリー）にSNSを作りたいと提案したところ認められたという。同氏が
cyano
ユーザーがページをロード開始してから閲覧できるようになるまでのロード時間はユーザーが自分のページを快適に閲覧できているかどうかを示す重要なファクターです。Google Analyticsのイベントという機能を使用することで、ユーザーの実際の体感速度を可視化することができます。 たとえば、このブログのある期間における体感速度のグラフはGoogle Analytics上で以下のように出ています。 44.84%のユーザーは100〜499msでロードできており、1秒未満でロード完了しているユーザーは合わせて73.49%であるとわかります。また、3秒以上かかっているユーザーも7.42%居ることも分かります。3秒以上ロードにかかるようだと離脱率も高くなるので、7.42%のユーザーに対して何かの施策が必要であるということも分かります。 このように、ユーザーが実際感じている体感速度を可視化することで、この
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (4) mod_deflateと組み合わせる際の注意点編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (4) mod_deflateと組み合わせる際の注意点編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 今回は、mod_deflateと組み合わ
cyano
ユーザーがページをロード開始してから閲覧できるようになるまでのロード時間はユーザーが自分のページを快適に閲覧できているかどうかを示す重要なファクターです。Google Analyticsのイベントという機能を使用することで、ユーザーの実際の体感速度を可視化することができます。 たとえば、このブログのある期間における体感速度のグラフはGoogle Analytics上で以下のように出ています。 44.84%のユーザーは100〜499msでロードできており、1秒未満でロード完了しているユーザーは合わせて73.49%であるとわかります。また、3秒以上かかっているユーザーも7.42%居ることも分かります。3秒以上ロードにかかるようだと離脱率も高くなるので、7.42%のユーザーに対して何かの施策が必要であるということも分かります。 このように、ユーザーが実際感じている体感速度を可視化することで、この
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (2) ProxyPassディレクティブに渡すパラメーター編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (2) ProxyPassディレクティブに渡すパラメーター編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 今回は、ProxyPassディレクテ
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 まず、mod_proxy_balancerの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソース情報データベースシステム(OSS iPedia) のコンテンツについて
GREE Engineering
