タグ

運用に関するyuuponのブックマーク (23)

  • 簡単&便利 Capistranoのススメ (導入編)

    ごきげんよう、TrinityTです。桜も咲き始め春の到来を感じますね! 今日は最近になって使い始めたとても便利なツール、Capistranoについて説明します。Railsを使っている人はもちろん、使っていない人両方にオススメです。  Capistranoって何?簡単に言うと「複数の環境に同じ処理を同時に実行させる」ツールです。・昔はSwitchTowerと呼ばれてました。・RoR環境でしか使えないと誤解されがちだが、他の環境でも十二分に便利。・(サービスがPerlで書かれてる)はてなでも導入・RoR環境だと基的なコマンドが揃っているため特に便利。 何がうれしいの?WebアプリでよくあるパターンとしてAPサーバが複数ある場合に各サーバに対して全く同じ処理(APを転送&APサーバ再起動...etc)を行う場合ってありますよね?そういう場合にCapistranoを導入すれば以下のようなメリット

  • MySQL の MERGE テーブルで巨大なテーブルを効率的に運用する

    naoya.dyndns.org is currently offline. Please try again later. Questions about our services? Learn more at Dyn.com.

    yuupon
    yuupon 2009/07/14
    MERGEテーブルの使い方知らなかったなあ。
  • MySQL バイナリログの削除 - とみぞーノート

    1. 概要 MySQLでレプリケーションを行っているとMasterにバイナリログが溜っていきディスクを圧迫するので定期的に削除してやる必要がある。 2. 手順 2.1 レプリケーション状態の確認 まず、どこまでバイナリログを削除してよいかを調べる。 Slave側でSHOW SLAVE STATUSを実行し、Slaveがバイナリログをどこまで読み取っているかを調べる。「Master_Log_File」が現在参照中のバイナリログ。以下の例ではskylancer00-bin.000084を使用していることになるので、skylancer00-bin.000083まで削除してしまってよいことになる。Slaveが複数いる場合は、全Slaveについて確認を行う。 mysql> SHOW SLAVE STATUS \G *************************** 1. row ********

  • ECサイトから65万人の情報漏洩 20人が70時間,不眠不休で対応

    1. 8万のカード情報を含む65万人の個人情報が漏洩し,セキュリティをいちから見直した 2. 漏洩が判明した直後は延べ20人が3日間,夜を徹して作業に当たった 3. カード情報の管理を第三者に任せ,WAFを導入するなど安全性を高めた 「えらいことになってしまった。覚悟せなあかんな」。 2008年7月10日の深夜のこと。アウトドア用品や釣り具の販売で年間40億円を売り上げるECサイト「ナチュラム」を運営するミネルヴァ・ホールディングス(当時の社名はナチュラム,8月1日に持ち株会社として改称)の中島成浩氏(代表取締役会長兼社長CEO)は,創業以来の危機に直面していた。ナチュラムのサイトから,クレジットカード情報を含む個人情報がほぼ確実に漏洩していたことが判明したのだ。大阪市中央区の社会議室に集まったメンバーは皆青ざめていた。 まず取り組んだのは被害の拡大を防ぐこと(図1)。丸3日間で一気に対

    ECサイトから65万人の情報漏洩 20人が70時間,不眠不休で対応
  • Osc2009 Do Xen Hara

    The Power of Virtual Network: Infrastructure as a Service Cloud Computing - W...axsh co., LTD.

    Osc2009 Do Xen Hara
    yuupon
    yuupon 2009/07/01
    OSC2009北海道の資料。「仮想マシンの動的プロビジョニング&複雑なネットワーク構築」
  • グーグル、自社設計のサーバを初公開--データセンターに見る効率化へのこだわり - CNET Japan

    カリフォルニア州マウンテンビュー発--Googleは、自社のコンピューティングの運用については多くを語らない。しかしGoogleは米国時間4月1日、当地で行われた、注目度が高まっているデータセンターの効率性に関するカンファレンスで、そのインターネットの力の中枢にあるハードウェアを初めて公開した。 ほとんどの企業は、DellやHewlett-Packard(HP)、IBM、Sun Microsystemsのような企業からサーバを購入している。しかしGoogleは、何十万台ものサーバを保有していて、そのサーバを稼働させることが自社の中心的な専門技術の一部だと考えており、自社独自のサーバを設計および構築している。Googleのサーバの多くを設計したBen Jai氏は、高度な技術を持つ、非常に熱心な聴衆の目の前で、現在のGoogleサーバを公開した。 Googleサーバで非常に驚くのは、サーバ1台

    グーグル、自社設計のサーバを初公開--データセンターに見る効率化へのこだわり - CNET Japan
    yuupon
    yuupon 2009/04/06
    各サーバごとにバッテリー。なんかコストがかかるような感じだけど、UPSを使うよりコストが安いそうな。
  • Linuxでやる夫: やる夫がapacheのコネクション数を調べるようです。

    apacheのコネクションについて 急にアクセス数が増えて、サービス中のサイトが重くなることがあると思います。単にアクティブユーザ数が増えた・・・または、スパムが襲撃してきた等原因は様々ですが、リアルタイムでのapacheの稼動状況を調べる方法があります。 ____        /::::::::::  u\         /:::::::::⌒ 三. ⌒\    あれ?     /:::::::::: ( ○)三(○)\       サイトおもくね・・・?     |::::::::::::::::⌒(__人__)⌒  | ________      \::::::::::   ` ⌒´   ,/ .| |          |     ノ::::::::::u         \ | |          |   /:::::::::::::::::      u       |

    yuupon
    yuupon 2009/03/17
    やる夫を使ってApacheの運用を解説しておる。
  • あなたのLinuxマシンをセキュアにするために知っておくべきiptablesのルール10選

    文:Jack Wallen(Special to TechRepublic) 翻訳校正:村上雅章・野崎裕子 2009-03-03 08:00 iptablesをマスターするには時間がかかるものの、セキュリティに関する基的なニーズを満たすことのできるいくつかのルールを知っておくだけで、あなたのLinuxシステムのセキュリティを向上させることができる。記事では、その手始めとなる重要なルールを解説する。 iptablesは、Linuxマシンをセキュアにするための強力なツールだ。とは言うものの、その機能の多さには圧倒されてしまいがちである。そして、コマンドの構造をしっかりと理解し、マシンのどの部分をどのようにセキュアにすべきかを把握した後であっても、ややこしいことに変わりはない。しかし、iptablesの良いところは、極めて広いその適用範囲にある。このため、iptablesのルールのいくつかを

    あなたのLinuxマシンをセキュアにするために知っておくべきiptablesのルール10選
  • void element blog: 「こくばん.in」を運営している立場として「うごメモはてな」を本気で心配してみる

    任天堂とはてなが提携して「うごメモはてな」が発表されましたが、老若男女問わず不特定多数が参加するお絵描き投稿の場というのは思った以上に混沌とすることが予測されます。 「こくばん.in」ではユーザ数こそ圧倒的に劣るものの利用年齢層がDSiの購入層と近いと考えているので、過去に起こった事例に当てはめて「うごメモはてな」で発生しうる事態を挙げてみます。 1.通報するはてな市民のモチベーション低下 2.不特定多数とピクトチャットができる 3.アニメーションを利用した不適切な投稿の隠蔽 4.他人の作品に書き足すことによる弊害 5.悪質なユーザを遮断できない 6.狙い撃ち通報 7.通報が追いつかない あくまで一部ですが、事例も含め共有しておいた方がいいと思ったので簡単ですがまとめてみました。 いずれも起こらないことに超したことはありません。 1.通報するはてな市民のモチベーション低下 まず、はてな市民

    yuupon
    yuupon 2008/12/24
    予言。さてどうなることやら
  • はてなのインフラ、いまむかし @ サーバ/インフラ Tech Meeting - stanaka's blog

    先週の金曜にサーバ/インフラ Tech Meetingで「はてなのインフラ、いまむかし」という発表をさせていただきました。先日発売された「サーバ/インフラを支える技術」の新刊記念のイベントです。 [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行(ソフトカバー)購入: 132人 クリック: 2,246回この商品を含むブログ (283件) を見る 発表内容は、OSC 2008 Kansai in Kyotoでid:naoyaが発表したはてなのインフラの歴史の抜粋に加えて、今後、発展させようしている方向性について話させていただきました。ちょっと30

    はてなのインフラ、いまむかし @ サーバ/インフラ Tech Meeting - stanaka's blog
  • 0×0018 till I die » はてなnaoyaさん「はてなを支えるバックエンドシステム」

     403 Forbidden nginx

  • 負荷分散講習会 Apache編 | feedforce Engineers' blog

    ゴール 負荷分散のいくつかの方法に関して理解する mod_proxy_balancerによる負荷分散クラスタが構築できる 基礎知識編 基的な資料 主にクラスタによる負荷分散の資料。 - Apache モジュール mod_proxy_balancer - mod_proxy_balancerで中?大規模サーバー運用するときの勘所 - cyano あと社外秘資料。 負荷分散? 複数台のサーバにアクセスを分散して、個々のサーバにかかる負荷を減らし、全体的に処理できるアクセスを増やすこと。 以下のようなアプローチがある。 DNSラウンドロビン DNSでひとつのホスト名に複数のIPアドレスを割り当てる方法 シンプル しかしダウンしているホストにもアクセスが振り分けされてしまう 冗長化と併用でなんとかなるかな? 機能ごとにホストを分割 ウェブサーバとDBサーバの分割(基過ぎるが一応これも負荷分散)

    負荷分散講習会 Apache編 | feedforce Engineers' blog
  • sanonosa システム管理コラム集: Linuxでそこそこ安全かつ楽にサーバを立てる方法

    【1.初めに】 要望がありましたので、今回はLinux(実際はRedhat系Linux)でそこそこ安全かつ楽にサーバを立てる際の手順を記してみます。 ※一応注意:今回は、試しにサーバを立てる程度であればこのくらいで十分ではないかと思うレベルを想定しています。サービスに投入するサーバでは私はもっと細かいところまで手を入れています。 【2.そこそこ安全かつ楽にサーバを立てる手順】 さて、いよいよ題です。サーバを立てる際は、不必要なものを全て取り除いてから必要なものを追加していくというのが基になります。以下の手順1~5では不要なものの除去、手順6~7で必要なものを追加し確認しています。それを踏まえまして。 ■手順1. OSをインストールします。(私はLinuxであればCentOSを入れることが多いです。その際私はインストールの種類をカスタムにしパッケージグループの選択では開発ツール以外全部チ

    sanonosa システム管理コラム集: Linuxでそこそこ安全かつ楽にサーバを立てる方法
  • puppet

    Ramp your automation efforts with the leading DevOps platform

    puppet
  • Lists of the full-text retrieval softwares which can handle japanese properly.

    INDEX このページの目的 全文検索技術について簡単に フリーソフトウェアで日語の通るもの フリーソフトウェアだが日語が通らないもの 商用製品で日語の通るもの どのシステムを選ぶべきか 実際の導入事例の比較一覧 参考文献紹介 掲載ありがとう ページ作者のつぶやき Since: Thu Apr 17 13:43:10 1997 Last Refreshed: Fri Nov 12 00:05:46 JST 2004 時間の都合上、この一年ほどは十分にメンテナンスできていません。 ご利用の際には、その旨、悪しからずご了承下さい。(2002/5/31) ★ (2003/7/1) 拙著『Namazuシステムの構築と活用』を改訂しました。 詳しくは サポートページをご覧ください。 ★ (2003/5/21) MitakeSearch v4.0 リリース。 ★ (2003/4/25) Ver

  • とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする

    すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定

    とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
  • ウノウラボ Unoh Labs: メンテナンス画面を簡単に出してみる

    カレーはあまり好きじゃないKeitaです。 映画サイトの映画生活のデザインリニューアルをして、いくつかデザイン以外の修正もあり、サーバ停止時間が発生するため、メンテナンス画面を作ることにしました。今日はその簡単なトピックスを書いてみたいと思います。 まず最初に、メンテナンス画面は次のような形の要件があるかなと思っています。 ドメイン以下すべてがメンテナンス画面になる クローラー対策でヘッダで503を出力する 癒される 特にクローラー対策は、クローラーがきておかしいものをキャッシュされると結構痛いかなと思うので、503が的確かはともかく、そこらへんのエラーを出すことにしました。 最初、ここら辺のすべての処理をmod_rewriteだけで実現できるかなと思ったのですが、残念ながら、mod_rewriteでは300番系のエラーを出すことができますが、503のエラーは出せないようなのでさくっ

  • ウノウラボ Unoh Labs: mod_expires と mod_rewrite を使ってウェブサーバへのアクセスを減らす方法

    最近、雨の日が続いて自転車通勤ができていない naoya です。 今日は、先週ぐらいからフォト蔵に導入した Apache で mod_expires と mod_rewrite を使ったウェブサーバへのアクセスを減らす方法を紹介します。 通常のウェブサーバは、更新されていないリリースに対してアクセスすると、ステータスコード 304 とIf-Modified-Since ヘッダをつけて応答データを返しますが、CSSJavaScript など比較的更新頻度の少ないファイルに対して、毎回応答を返すのはウェブサーバから見ると無駄なアクセスです。 Apache の mod_expires と mod_rewrite を使うと、この無駄なアクセスをブラウザキャッシュを有効活用にすることにより、静的なファイルに対するアクセスを減らすことができます。 まず、仕組みから説明すると、とても単純で mod

  • naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う

    あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----

    naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
  • Poundで作るロードバランサとSSLラッパ(1/4) ― @IT

    Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。(編集部) Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの

    Poundで作るロードバランサとSSLラッパ(1/4) ― @IT