なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
JavaScript is not available.
Something went wrong, but don’t fret — let’s give it another shot.
サーバはデータセンターの中を液体のように流れるような存在になる、という仮説
先日、あるIT関係の集まりで、大手ネットワーク機器ベンダの偉い人がこんな話をしてくれました「最新のイーサネットは、サーバの内部バス並のスピードで通信ができる。これはすごいことだよね」と。 いま市場では10ギガビットーサネットが普及し始めているところですが、すでにその次の世代のイーサネットとして40ギガビットイーサネットと100ギガビットーサネットも昨年、IEEEによって標準化されており、まだ非常に高価ですが製品が登場し始めています。 その話を聞く少し前、僕は別の大手システムベンダの偉い人のこんな話を聞いていました。「これから2年もしないうちにサーバの形が大きく変わっていく。すごく面白くなるはずだ」と。 この2つの話はつながっているように思えました。 サーバは液体のように流動的で論理的な存在に クラスタを構成するネットワークが内部バス並みに高速になれば、あるサーバの負荷が高まってきたときには
サーバの生死管理をWeb上で統合管理する·SmokePing MOONGIFT
SmokePingはネットワーク監視システム。Pingの遅延速度などをグラフ化する。 SmokePingはPerl製のオープンソース・ソフトウェア。ネットワークは目に見えないため、トラブルがあった時の原因究明に時間を要する場合が多い。目に見える断線とかであれば良いが、見た目は普通なのになぜか繋がらないといった場合が多い。 グラフ そんな時にはネットワーク調査用のツールが多々使われるが、Webベースで調査やレポートを提供してくれるのがSmokePingだ。 SmokePingはMRTGやRRDtoolの開発者でも知られるTobi Oetikerが開発しているネットワーク管理用ソフトウェアで、ネットワークの遅延を中心として計測し、グラフ化する。分散した測定に対応しマスター/スレイブによる測定を行う。全ての結果はグラフで表示されるようになっている Webベースのtraceroute 最新版ではS
GNU Parallel を本番環境で使ってみました | Carpe Diem
GNU parallel を本番環境で使ってみました。 本番環境では、10 台程度ある Apache のウェブサーバのアクセスログを mod_log_rotate で 1 時間ごとに出力して、バッチ処理のサーバで集めています。 最初は、シェルスクリプトで、次のようにしていました。 次の例はウェブサーバが s1 〜 s10 まであって、$LOG_DIR/$LOGFILE に 1 時間ごとに出力したアクセスログがあると想定しています。当然ながら、下記のシェルスクリプトの実行ユーザで対象のサーバへ SSH 経由に接続できるものと想定しています。 for s in s1 s2 s3 s4 s5 s6 s7 s8 s9 s10; do ssh -q $s "test -f $LOG_DIR/$LOG_FILE" RETVAL=$? if [ $RETVAL -eq 0 ]; then rsync -
HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました（参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」）。 ホワイトペーパーでは、HDDの代わり
ライブドアデータホテルパトロール 無料サーバ・ネットワーク監視サービス
「DATAHOTEL PATROL」サービスからのアラートメール誤配信のお知らせ（2019年4月3日） 2019.04.03 平素は大変お世話になっております。 掲題の通り、既にサービス提供を終了しております、「DATAHOTEL PATROL」 サービスにおきまして、3月30日から31日にかけて、以前ご利用のお客様のメールアドレス に対してアラートメールが誤って配信されました。 メールを受信された皆様には、ご迷惑お掛けしまして、大変申し訳ありませんでした。 本事象の原因は、サーバ撤去時の誤作動により、誤って監視が再開され、アラートメールが 配信されたことによるものでございます。 該当サーバは既に撤去及びデータ消去を実施済みのため、メールは配信されないよう 対応させて頂いております。 お客様におかれましてはご不便をお掛けいたしましたことをお詫び申し上げます。 今後とも弊社をご愛顧くださいま
満足せる豚。眠たげなポチ。:CGI から Mongrel まで、Rack で Web アプリを Web サーバから抽象化する
Rack ってなに？ Rack は Web サーバと Ruby プログラムや Ruby で書かれた Web アプリケーションフレームワークとの間に、最小限のインターフェースを提供します。 http://rack.rubyforge.org/ Rack のインストール gem install rack Rack の簡単な始め方 Rack を使うには、まず call されるアプリケーションを書きます。call メソッドを定義し、引数に env を取ります。 # app.rb require 'rack' class TinyCaller def call(env) [200, {'Content-Type' => 'text/html'}, ["Hello, World."]] end end 続いて、Rack を使うための DSL ファイルとなる .ru ファイルを作成します。 # tiny
Kazuho@Cybozu Labs: ウェブアプリケーションにおけるHDDの正しい使い方
« ディスクが１回転する間に複数回 fdatasync する方法について | メイン | Q4M - MySQL 上で動作するメッセージキュー » 2008年01月04日 ウェブアプリケーションにおけるHDDの正しい使い方 データベース等のソフトウェアは一般に、停電やOSのクラッシュ時にデータが破壊されないよう、HDD へデータ保存が完了したか確認しながら処理を行うようになっています。その目的を果たすためにどのような API が OS によって提供されているか、少し勉強し直すことにしました。 下表のうち、赤い部分がデータの永続性が保証されない危険な手法、青い部分が安全な手法です。したがって、各行において出来るだけ左側の (高速側の) 、そして言うまでもなく青い色の同期手法を使っていることが望ましいということになります。 OS openモード HDD または RAID 内の書込先 キャッシュ
さくらインターネット移行記#5 久しぶりの移転作業
だいぶ間が空いてしまいましたが、久しぶりのデータセンター移行記です。 アンテナ、カウンター、検索を移転 完全移行もぼちぼちゴールが見えて来た今日この頃ですが、先日もサーバーの移行作業を行いました。はてなアンテナの巡回システム周り一式、はてなカウンター、はてな検索などをまとめて移行しました。今回の移行も深夜作業。夜の 2:00 に集合して作業開始です。上の写真は僕のメンテナンス時の作業着です。 サーバールームからサーバーを運び出します。台車が大活躍です。 ぎっしりサーバーが詰まっていた旧サーバールームも、だいぶ閑散としてきました。まだ 70 台近くのサーバーが残っていますが、開発機などを除くと残り 40 台程度になりました。年内には全部移行できるのではないかと思います。 アンテナやカウンターともなるとはてなの中では古いサービスなので、使っているハードも古い。移転にあたって古いサーバーはハード
CORESERVER.JP:コアサーバー
レンタルサーバー界最高クラスの パフォーマンス 他を寄せ付けない圧倒的なスペック 最新EPYC CPU64コア128スレッド 業界最高クラスの64コア128スレッドのCPUを搭載。圧倒的な演算処理能力とマルチ処理能力を保持しており、ウェブページ表示、DB処理を安定して超高速に実行することができます。 メモリ最大1TB 最大で1TBのメモリ容量を有したサーバーを利用しており、収容人数やアクセス過多によるトラブルやパフォーマンスの低下は起こりづらくなっています。 ストレージNVMe SSD RAID10 NVMe SSDをRAID10構成にすることで、ピュアSSDのRAID構成と比較して、読み込み速度が最大で14倍以上に向上、レスポンス速度の高速化を実現しました。 WebサーバーLiteSpeed 高速化を追求した次世代WebサーバーのLiteSpeedは応答速度が速く、最新プロトコルに対応な
Kazuho@Cybozu Labs: サーバシグニチャは隠さないのが当たり前
« Pathtraq バージョンアップのおしらせ - サイドバー表示に対応 | メイン | Perl から MySQL に非同期アクセスする方法 » 2007年09月05日 サーバシグニチャは隠さないのが当たり前 ウェブサーバ(Apache)で、404などのエラーページを表示したとき、ヘッダやページの下にApacheやOSのバージョンが表示されます。こういったサーバ情報をわざわざ表示する必要はありません。 ウノウラボ Unoh Labs: 5分でできるウェブサーバのセキュリティ向上施策 私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。 yohgaki's blog - サーバシグニチャは隠すのが当たり前 Server: ヘッダを隠すメリットについての議論はあるようですが、Server: ヘッダを表示すべ
naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転
さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸
shell のちょっとしたテクニック - odz buffer
後輩が cat README | tr ' ' '\n' | sort | uniq -c | sort -nr | head てなテクニックを見て、びっくりしたみたいな話をしていたのだが、こういうパイプラインを利用するテクニックを学んでいないのは色々損な気がする。 ていうか、サーバで丸一日以上かかるような処理を実行するのもしょっちゅうなのに、GNU screen も nohup も知らないってのはいろいろ支障があるような気もするのだが、だれも教えないものかなぁ。 ということで、bash or zsh のちょっとしたテクニックとか*1。リダイレクトとかパイプラインは略。 連続実行 単純に連続実行。 % foo; barfoo が正常終了したときだけ bar を実行 % foo && barfoo が正常終了しなかったときだけ bar を実行 % foo || bar&&、||は本来は論理演
「すでにOSSミドルウェアの性能十分」、IPAが評価終了 － ＠IT
2007/02/07 データベースやアプリケーションサーバといったOSSミドルウェア適用における課題は、もはや性能ではない――。 独立行政法人情報処理推進機構（IPA）の委託で、大手SIベンダやハードウェアベンダなど9社が中心となって2004年から実施している「OSS（オープンソースソフトウェア）性能・信頼性評価プロジェクト」の第4回目の成果が発表された。PostgreSQLやMySQLといったOSSのデータベースはCPU数のスケーラビリティが格段に向上し、チューニング次第で大幅な高速化や大規模対応が可能という。 3年で状況は一変、もはやOSSミドルウェアは性能面は十分 プロジェクトが活動成果を発表するのは今回で4回目。OSSの性能限界を明らかにし、適用可能領域を明確にするのが目標の1つだ。OSのLinuxは、カーネル2.4系にあったロック競合の問題はカーネル2.6系で解消され、スケーラビ
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションの無停止稼働 - Server::Starter, Parallel::Prefork, Starlet を使って (SoozyConference 7 発表資料)
月額490円で使える仮想サーバー「ServersMan@VPS」が実現できた訳 
mputの日記。 - , rootのパスワードは潰さないほうがいいと思う件