タグ

システム運用に関するykazu323のブックマーク (5)

  • 満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ

    ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、へのリンクをまとめておく。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

  • DBMによるテーブルデータベース - mixi engineer blog

    正月早々インフルエンザにかかって寝込んだmikioです。電車に乗る時や繁華街などに出る時はマスク着用が必須ですね。さて今回は、Tokyo Cabinetで実装したテーブル方式のデータベースについて紹介します。意外にどうして強力な機能なので、このネタは連載することを予告します。 テーブルデータベースとは 簡単に言えば、リレーショナルデータベースのテーブルのように、複数の列からなるレコードを格納できるデータベースです。SQLや表結合などの複雑な機能はサポートしませんが、そのぶん高速に動作します。つまり、DBMの速度で動くリレーショナル風データベースです(厳密にはリレーショナルデータベースではありません)。 TCの基となるハッシュデータベースは、単純なkey/value型のデータベースであり、つまりキーにも値にもスカラ(数値や文字列などの特に構造を持たない単一の値)しか格納することはできません

    DBMによるテーブルデータベース - mixi engineer blog
  • Persistence is Power:MySQLユーザコンファレンス2008(1日目)でアメブロの裏側の話を聞いてきた - livedoor Blog(ブログ)

    Days in programming, computing, studying, considering and enjoying @東京ステーションコンファレンス。日1日目は諸事情あり十分な聴講時間がとれなかったこと&明日2日目は行けそうにない事から、今日聞けた中で一番面白かった Ameba(アメブロ) の話のメモをとりあえずポストしておきます。スピーカーはサイバーエージェントの岡田さん、大黒さん。 セッションのメモは以下に転記しますが、講演の内容は、2006 年以降アメブロで行われた Oracle => MySQL 移行の苦労話や、増大する PV (月間50億PV!) による負荷対策の取り組み、各種ストレージエンジン x ファイルシステムの組み合わせでのパフォーマンス検証結果、自作サーバによる各種ディスク構成でのパフォーマンス検証結果などなど、といったところでした。 率直な

  • [ThinkIT] 第1回:Inside Hatena Bookmark (1/2)

    筆者が勤務する株式会社はてなが提供するある一つのインターネットサービスを題材に、LAMP(Linux+Apache+MySQLPerl)でのアプリケーション開発や、負荷分散について述べるという発表でした。はてなで提供しているサービスには、はてなブックマーク以外にもはてなダイアリー(注2)のような月間何億PV(Page View)もある大きなサービスもあります。はてなブックマークはそれらに比較すると小さい、中規模なシステムです。 システム運用について発表するにあたって、億単位のPVをさばく巨大なサービスについて述べるよりも、ある程度現実的な規模のものについて解説する方が、みなさんの参考になるかなと思い、このテーマを選択しました。 稿ではYAPC::Asiaでの発表の中からいくつかのトピックを選んで、Perlを使ったシステムの運用や負荷分散のコツなどを中心に解説したいと思います。 なお、発

  • CodeZine:DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意(前編)(モバオク, モバゲー)

    シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレー

  • 1