はてなで大規模サービスのインフラを学んだ - ゆううきブログ
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
H2O - the optimized HTTP server
The document describes H2O, an optimized HTTP server developed by Dena Co., Ltd., highlighting its key features such as support for HTTP/1.x and HTTP/2, modular design, and high performance based on efficient memory management and input parsing. It emphasizes the server's capabilities in handling various protocols, its testing methodologies, and design principles aimed at achieving speed and relia
エンジニアならウェブサーバーのひとつでも自腹で立てて運用すべき理由と、サーバー環境の選び方 : akiyan.com
エンジニアならウェブサーバーのひとつでも自腹で立てて運用すべき理由と、サーバー環境の選び方 2013-08-26 なんかスイッチが入ったので書いてみる。 目次 1 技術的なレイヤーは掘り下げるべきなので、ソフトウェア・エンジニアだってサーバー運用は経験すべき2 ローカルの仮想環境にインストールとかは意味がない3 強制的に運用しなければいけない状況を作ること4 自腹なのはコストを意識するためと、自由になるため5 初めてならVPSだ6 自宅サーバーはより低レイヤーを経験できるが、高コストで面倒が多い7 初めてだとOSの再インストールは絶対にしたくなる8 専用レンタルサーバーは、無い9 仕事でAWSを使ってるならEC2もアリ10 EC2以外のクラウドのメリットはあまり無い11 OSは仕事で使っているOSにしておこう12 というわけで13 追記：はてブやtwitterで沢山のコメント頂いたので反応
YappoLogs: 馬鹿でもわかる Application Server と Reverse Proxy Balancer のお付き合いを考える
馬鹿でもわかる Application Server と Reverse Proxy Balancer のお付き合いを考える 一般的な Web Application というのはロードバランサ、Webサーバ、アプリケーションサーバという HTTP を喋るサーバで構成されていると思います。 ロードバランサは高級なハードウェアからソフトウェア(lvs, httpd, etc..)で作るものまで色々ありますね。 アプリケーションサーバでは各種言語に合わせた実装でデーモンが常駐してるでしょう。これはいわゆる普通の Web サーバよりは単純なコンテンツを返す性能が低いです。 そんなわけで動的なアプリケーションサーバが有る構成では js や css や画像など静的なファイルは Apache や nginx などの専用の Web サーバでサービスして、動的なリクエストだけバックエンドのアプリケーションを
「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...
ふと今更、年初のCROSS 2013の「次世代 web セッション」の動画を見て、うんうん唸ってしまった。プロトコル編の方は知識不足であんまり分からなかったですが、アーキテクチャ編の方はグサグサくるものがあった。「自分の頭でこれからの web を考えてブログに書くまでがこのセッション」という宿題が出ていたので、せっかくなので最近考えてることをつらつらと書いておこうと思った次第。特にまとまりはないですし、戯言です。 これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) – Block Rockin’ Codes 前提 僕はコード書いてない＆サーバサイドしか見たことない＆WEB サーバはあんまり見たこと無くて、それより後ろ側ばっかり見てた人なので、ユーザ側とかアプリ開発者がどうなっていくかについて特に尖った意見はありません orz SPDY とかもまだ手を
サーバ管理の仕組みを作り始めた話 - Kentaro Kuribayashi's blog
先日(10/9)、riywoさんさんの呼びかけにより、サーバ管理をどうやったらいい感じなるかを話し合う会がもたれました。僕は、直接サーバ管理をやっているわけではないのですが、社内でそういうの欲しいという話をしていて、ツールを作りたいといっていたので、参考になればというわけで、お誘いいただいて参加してきたのでした。 riywoさんから、叩き台としてホストのキーを元にした統合的なAPIの構想を図式化したスライドを提示していただいた後、管理システムの主なユースケースや、各社の実際の管理手法などをいろいろお話をうかがいました。僕など、インフラ的な知識に乏しいもので、これはなかなか大変なことだなあというのがあらためてわかりました。 組織体制や経理ルールの複雑性が各社でだいぶ違う サーバの情報として必要な属性が各社でだいぶ違う そもそもサーバの情報が複雑 既にあるなんらかの管理の仕組みとの整合性を取る
小規模Webサービス向け安上がりシステム構成と開発フロー（怖話.jp） - Fjord, Inc(株式会社フィヨルド)
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
Webアプリケーションエンジニアはノマドであれ（特定のサーバに依存しない方法） - blog.nomadscafe.jp
弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 本番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元／管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技
TwitterがBitTorrentで高速にデプロイしている仕組みについて
Twitterは、同社の何千台ものサーバに対してバイナリをデプロイする場合に、ピア・ツー・ピアシステムのBitTorrentを利用したツール「Murder」を用いていると、7月1日の記事「Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」」で紹介しました。 FacebookでもBitTorrentによる大規模なデプロイが高速に行われていることは、7月16日の記事「Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側」で紹介しました。 どうやら大規模システムにおけるデプロイではBitTorrentの利用が進んでいるようです。 7月15日付けのTwitter Engineering Blogに、Twitterのエンジニア、Larry Gadea氏による「
livedoor ReaderのクローラとStreaming APIなどの話
Artificial Intelligence, Data and Competition – SCHREPEL – June 2024 OECD dis...
「クックパッド」の裏側にいってきた | Carpe Diem
Web デベロッパーの祭典に行ってきた。今回は、通路沸きに用意された比較的狭いスペースで開催された。 以下、メモと自分の勝手な感想をまとめておく。 クックパッドについて 毎日の料理を楽しみにすることで心からの笑顔を増やす 1998年にオープン 去年のリニューアルのときに Rails で作り直した 使い方 レシピをのせる レシピをさがす 月間ユーザ数 547万人 Rails サイト中世界7位 (from rails 100 wiki)、まさか1位がscribd.comとは 月間 2.8億 PV(PVでは、Rais サイト中世界3位) 登録レシピ数: 47万品 トラフィックは、16-18時くらいがピーク(夕飯を作る前に調べるユーザが多いとのこと) 秋からバレンタインにかけてトラフィックが伸びる(来週はピークだということで、最近はパフォーマンス向上に中心にやっていた) ユーザ数: 547万人(す
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
ヒトもカネもなくともシステム内製はできる
「ヒトもカネもない中小企業でも，やればできる」---菅雄一氏は関西のある企業のたった一人のシステム担当である。従業員約200人の製造業で，ほぼ独力でネットワークを引きサーバーを立て，社内向けのグループウエアや顧客向けのQ＆A情報検索システム，販売システムなどを構築してきた。 ミドルウエアとして使っているのは，すべてオープンソース・ソフトウエア。ハードウエアの代金と回線料を除けば，費用はほぼ菅氏の人件費だけだ。 最初はエラーの連続 菅氏がシステム内製を始めたのは，2000年に同社がインターネットに接続したことがきっかけだった。この時，インテグレータから提案されたサーバーの費用は，営業所や本社のパソコンの設定変更，ファイアウオールなどを含めて100万円以上。それを見た菅氏は「10万円のパソコンにLinuxを入れればもっと安くできるのに」と思った。 菅氏は思っただけでなく，実際に行動した。自前で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
