タグ

serverに関するkistame228のブックマーク (17)

  • 自宅サーバのインフラ設計書を公開します - @int128

    自宅サーバのインフラ設計書を公開します。 Design paper of the home server(抜粋) 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発(SI)の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ

    自宅サーバのインフラ設計書を公開します - @int128
  • イベントレポート(食べログ&クックパッド共催勉強会) - クックパッド開発者ブログ

    こんにちは。クックパッドでイベント運営を担当しているスミです。 去る12/17、べログさんと共催で勉強会を行いました。べログさん、クックパッドエンジニアがそれぞれ3名ずつ、お集まり頂いた約30名のエンジニアの皆さまの前でプレゼンを行いました。 インフラのお話をテーマにした今回。会場の皆さまからたくさんのご質問を頂き、とても熱い時間を過ごさせて頂きました。ご来場頂いた皆さま、どうもありがとうございました。 クックパッドエンジニアが使用した資料を公開いたしますので、是非ご覧くださいませ! ・クックパッドのスケーリング(高田悟史) [slideshare id=2756725&doc=20091214tabelog-key-091221024948-phpapp01] ・800万人の"べたい"をHadoopで分散処理(佐々木達也) [slideshare id=2735999&doc=

    イベントレポート(食べログ&クックパッド共催勉強会) - クックパッド開発者ブログ
  • もっとApacheを知ろう いまさら聞けない!? Web系開発者のためのサーバ知識 第2回 - @IT

    もっとApacheを知ろう:いまさら聞けない!? Web系開発者のためのサーバ知識(2)(1/3 ページ) 自動起動の設定 第1回「Webサーバから始めよう」で手順を追って設置した/etc/rc.d/init.d/httpdというApacheの制御スクリプトは、システム起動時におけるApacheの自動起動に利用できます。 今回は、Linuxのシステム起動時に各種のサーバプログラムを自動的に起動させる方法を、Apacheを例に紹介しておきましょう。 まず、/etc/rc.d/init.d/配下に、サーバ制御スクリプトを設置します。制御スクリプトの内容はサーバプログラムにより異なりますが、多くのパッケージではインストール時に自動で設置されるか、またはサンプルが提供されます。今回の例では、すでに紹介した手順で/etc/rc.d/init.d/httpdを設置済みです。 次に、/etc/rc.d/

    もっとApacheを知ろう いまさら聞けない!? Web系開発者のためのサーバ知識 第2回 - @IT
  • 54行で分散KVSを実装する(レプリケーション機能付き) - Blog by Sadayuki Furuhashi

    Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます(レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行)。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、(keyのハッシュ値 % サーバーの台数)番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は

    54行で分散KVSを実装する(レプリケーション機能付き) - Blog by Sadayuki Furuhashi
  • lsyncdをつかって簡単にファイル同期を - UNIX的なアレ

    lsyncdというツールをご存じでしょうか?これを導入することで、リモートのホストとディレクトリ単位で同期をすることができます。 先日のエントリーでも紹介していますが、実は設定や導入がすごく簡単です。した設定でリモート間でファイルの同期をとれるのはやはり便利ですよね。 さて、今回はlsyncdの簡単な導入方法を紹介したいと思います。 lsyncdの仕組み lsyncdはlinux kernel2.6.13で導入された、inotifyというAPIをつかって動作しています。 inotifyはファイルシステムのイベントを取得することができるAPIで、ファイルの作成や削除などをそれぞれイベントとして取得をすることができます。 この仕組みと、rsyncを組み合わせてファイルの同期を行うことを実現しています。 lsyncdのインストール まず、以下のページからsourceをダウンロードしてください。

    lsyncdをつかって簡単にファイル同期を - UNIX的なアレ
  • KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog

    KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収

    KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
  • Apacheの設定を変更し、単一IPアドレス上で複数のSSLサイトを運用する - builder by ZDNet Japan

    Apacheのバージョン2.2.12以降では、SNI(Server Name Indication)という、SSLプロトコルに対する拡張機能がサポートされているため、名前ベースのHTTPサイトを設定する場合と同じように名前ベースのHTTPSサイトを設定することが可能になっている。記事では、Apacheのこの機能について紹介する。 Apache Webサーバがバージョンアップし、成熟していくに伴い、新機能の追加やバグの修正が行われてきている。そして、バージョン2.2.12で追加された機能のうち、最も重要なものはおそらく、単一IPアドレス上で複数のSSLサイトを運用できるようにするという、長らく持ち望まれていた機能だろう。 これまでは、特定のIPアドレスに対してSSL対応のWebサイトを割り当てた場合、そのサイト1つしかSSL対応のWebサイトを運用することができなかった。つまり、IPアドレ

    Apacheの設定を変更し、単一IPアドレス上で複数のSSLサイトを運用する - builder by ZDNet Japan
  • ウノウラボ Unoh Labs: サーバのネットワーク速度の調査/測定方法

    こんにちは。kyagi です。先日データセンタ内のサーバ群のうち、なぜか特定の1台だけネットワークの速度が極端に遅いという問題がありました。今回はサーバマシンのネットワーク速度の測定方法と原因についてお話しします。同様のトラブルが発生している方のお役に立てば幸いです。問題解決までの手順としては以下になります。 1. 現在の状態を調べる 2. ハード/ソフト含めて考えられる原因をいくつか挙げる 3. 原因について改善されるまでひとつひとつ検証していく まず現在の NIC の HW 情報とドライバを lspci で調査します。ここでは Broadcom の NetXtreme BCM5722 という NIC を使用していることがわかります。 # lspci -vvv | grep Ether 01:00.0 Ethernet controller: Broadcom Corporation

  • Webサーバから始めよう

    Webサーバから始めよう:いまさら聞けない!? Web系開発者のためのサーバ知識(1)(1/2 ページ) プログラマの弱点(?) ある程度の規模の開発プロジェクトでは、上流工程と下流工程、開発担当とサーバ担当、さらに開発担当のなかでもバックエンドのロジック担当とフロント周りの担当など、分業体制で進めていくのが一般的です。 ここまできっちりと分業されていない場合でも、コーディングはプログラマが行い、番向けのサーバ構築などは詳しい人に任せてしまうといったことは多々あります。 こういった分業体制はもちろん理に適ったことなのですが、開発者が常にプログラマに徹してしまっていると、どうしてもサーバ知識が不足しがちになります。アプリケーションを動作させるために必要な最低限の環境を自分のPC上に整えたら、あとはひたすらコーディングの日々といったことの繰り返しになるので、なかなかサーバ知識が深まりません。

    Webサーバから始めよう
  • blog.keitap.com: FFFFOUNDとnoatime

    スケーラブルWebサイトを読んでたらnoatimeの事が書いてあったので、画像を保存してるディスクをnoatimeでマウントし直したらロードアベレージとDiskのI/Oがえらい下がった。 (途中、データが取れてない部分がありますが、サーバがダウンしてたわけではなくて単に監視がうまくいってなかった) 再マウント時のコマンド: mount -o noatime,remount,rw /dev/sda2 画像配信のキャッシュサーバの方も同じくnoatimeでマウントしてみたけど、そっちはSquid使ってるのでキャッシュが単一のファイルの為効果はなし。 結論としては、大量のファイルを保有してる場合はnoatimeの効果は絶大だと。

  • 最新のFedoraとUbuntuではrelatimeもnoatimeもいらない? - 科学と非科学の迷宮

    (2008/6/14 13:35 追記) 続き書きました http://d.hatena.ne.jp/shiumachi/20080614/1213415948 要約 前回の検証で、マウントオプションに noatime や relatime をつけても オプションなしのときと性能が変わらないという結果を報告しました*1。*2 しかし、調査の結果、Fedora8、Fedora9、Ubuntu8.04 LTS などでは カーネルのコンパイルオプションに default_relatime がついていることが 判明しました。 そのため、各ファイルシステムに noatime や relatime オプションを つける必要はなくなっています。 relatimeについての調査 relatime マウントオプションについて調査していたところ、 LWN.netに atime 周りの議論のまとめ記事が掲載され

    最新のFedoraとUbuntuではrelatimeもnoatimeもいらない? - 科学と非科学の迷宮
  • Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか

    多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか? echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ

  • ムーアの法則を理解しているということ(第98回カーネル読書会) - 未来のいつか/hyoshiokの日記

    第98回カーネル読書会は、はてなの田中さんによる、はてなでのハードでの性能の引き出し方というお題で思う存分お話をいただいた。 1年半で半導体の集積度が2倍になるというムーアの法則は誰でも聞いたことはあると思うし、IT系の技術者であれば、知っていて当然の「法則」である。問題は知っていることとそれを理解していることというのはまったく別のことである。将棋のコマの動かし方を知っていたとしても名人にはなれない。ムーアの法則を知っていても、それが自分の仕事にどのような意味を持つかということを理解し、実践している人は驚くほど少ない。 田中さんは数少ないムーアの法則を理解し実践している技術者の一人である。 1年半で様々なコストが半分になるとしたら、それを前提にシステムを組むことによって、どのような競争優位性をもたらすのか。それを自社のサービス戦略にどのように組み入れるか、ということをムーアの法則の文脈の上

    ムーアの法則を理解しているということ(第98回カーネル読書会) - 未来のいつか/hyoshiokの日記
  • Google's Chiller-less Data Center

    Data Center Knowledge is part of the Informa Tech Division of Informa PLC This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

    Google's Chiller-less Data Center
  • はてなサーバーを更に解剖 - 発言注意!

    はてなの1U自作サーバーの情報が出てましたね。せっかくなので、写真からみてもう少しわかるところを掘り下げてみるとします。 1Uラックマウント可能なサーバを自作する - marqs blog 電源 電源は「Enhance FLEX 300」 最安値は、¥8,650くらい。300Wクラスの薄型電源では、最安クラスだと思うので、コスト重視ならいいチョイス。 冷却ファン(ケース取り付け用) ケース背面近くに2つある冷却ファンは「San Ace 40」っぽい。 取り付け位置とかも計算されてるんでしょうね。ラックの前面・背面の両方につけるので、非対称な位置につけることで、前後2台で空気循環させるような考え方かな?メモリやCPUを避けて、空気の流れを作りやすくしてるっぽい。 冷却ファン(CPU) 冷却ファン(CPU)は「Dynatron P199」 最安値¥3980ほど。丈が低いファンで他の選択肢が

  • 1Uラックマウント可能なサーバを自作する - marqs blog

    はてなでは以前から自社製サーバを使用しているのですが、今年の春に、新たに自社製1Uハーフサーバを開発しました。 最近、タワー型だとメーカー製でもかなり安価なサーバがあるのですが、データセンターでの運用を考えると1ラックへの集積度が問題になってくるので、必然的にラックマウント可能なサーバが求められます。1Uサーバの中で価格対性能比のよいものを探すと、まだまだはてな的に使いやすいサーバが少ないので、今回このような1Uラックマウント可能なサーバを自社開発しました。 さてこのサーバの特徴としては、 ケーブル類がフロントアクセス 組み立て簡単 いけてるインフラアルバイトのid:hxmasakiが組み立てると15分 1ラックに60台以上搭載可能 もちろん、電源容量との兼ね合いもあります ディスクのホットスワップが可能 低消費電力 お値段据え置き 以前の自社製サーバとほぼ同価格 といったところがあげられ

    1Uラックマウント可能なサーバを自作する - marqs blog
  • 軽量・高速WebサーバThinを使う手順のメモ - Hello, world! - s21g

    Thin は、最近話題の軽量・高速が売りのWebサーバです。 Thin is a Ruby web server that glues together 3 of the best Ruby libraries in web history: the Mongrel parser, the root of Mongrel speed and security Event Machine, a network I/O library with extremely high scalability, performance and stability Rack, a minimal interface between webservers and Ruby frameworks ということで、 RailsアプリケーションでThinを使う方法をメモしておきます。 何はともあれ、まずはsudo g

  • 1