垂れ流されるログのおしりを追いかける - （ひ）メモ
滝のように流れるログは見ていて楽しいのですが、見ているばかりでは仕事にならないので、 https://github.com/hirose31/chase-tail というスクリプトを書きました。 機能はこんな感じで、 ログ中のきわどいキーワードに色をつけて目立たせる HTTPステータスの「50[0-9]」とかMySQLの「Lock wait timeout exceeded」とか 秒間にある一定行数以上ログが流れたら「NOTIFY_FLOOD」と出力する iTerm 2のPreferences→Profiles→AdvancedタブのTriggersにキーワードを登録しておくとGrowlで通知できるので、「NOTIFY_FLOOD」を登録しておけば、いつよりログがビャービャー流れたときにGrowlで知ることができます ちなみに、iTerm以外のアプリがフォアグラウンドでも、chase-ta
3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
ディレクターやエンジニアが運用エンジニアにインフラの相談をする際に持って来て欲しい5つのこと - blog.nomadscafe.jp
新しいWebサービスを開始する際や、既存サービスに変更を加える際に、サーバを何台確保するか、ストレージやAPIといった共有リソースを使用して良いか、ディレクターやアプリケーションエンジニアの方に訪ねられることがありますが（というかそれが仕事ですね）、その際相談のためにどんな情報を持って来て欲しいか書いてみます。人間同様にサーバやネットワークリソースも有限なので、無駄にならない最適なサーバ台数を割り出したり、増強が必要かどうかを判断して、会社のビジネスを効率よく進めていくことが重要です。 人によっては以下に書いてあることが、非常に緩く感じでしまうこともあるかもしれません。これはWebサービスを早く立ち上げて、柔軟に運用していくことができる環境ならではだと思います。それでも出して欲しいモノはいくつかあります 企画書 どんなサービスであるか説明できる企画書があるといいでしょう。ないわけはないと信
DeNAが社内利用しているMySQLの自動フェイルオーバーツール、オープンソースで公開開始
MySQLがダウンしたときに自動的に別のMySQLへ処理を引き継ぐことで、高可用性を実現するフェイルオーバーツール「MySQL-MHA: MySQL Master High Availability manager and tools」がオープンソースとして公開されたことを、作者の松信嘉範（まつのぶよしのり）氏がブログで伝えています。 Yoshinori Matsunobu's blog: Announcing MySQL-MHA: "MySQL Master High Availability manager and tools" 松信氏はモバゲーなどで知られるDeNAに勤務しており、MySQL-MHAによる自動フェイルオーバー機能はDeNAのインフラ運用を支えているとのこと。同氏のブログから引用します。 Difficulties of master failover is one of
デブサミ2011【17-A-3】ソーシャルアプリを支えるインフラの現場
#devsumi #17A3 山口徹 氏 / 小野篤司 氏 / 安井真伸 氏 / 冨成章彦 氏 / 大仲能史 氏 大量データをさばくモバイルサービス各社の取り組み。
Phpconf2010
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonightAmazon Web Services Japan
Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～
2010/07/14 リリース直後から大量のユーザーが流れ込み、高負荷に晒されるソーシャルアプリ。システムダウンによって、ビジネスチャンスを逃さないためには負荷対策が不可欠です。 KLabは長年の大規模・高負荷モバイルサイトの構築・運用によって、対負荷性能を持ったアプリ・インフラのノウハウを積み重ねてきました。ソーシャルアプリ市場においてはオープン当初からSAPとして参入し、ソーシャルアプリならではのアクセス集中を経験したことで、現在はより安定したサービスを提供できるに至っています。 今回は、KLabが実施してきたそんな負荷対策ノウハウを広く紹介いただきます。Read less
デブサミ2011レポート 数十～数百億PVのトラフィックをさばく、ソーシャルアプリのインフラ現場の実情
モバゲータウンなど、Feature Phone向けの人気ソーシャルアプリケーショーションは、月間数十～数百億PV（ページビュー）もののトラフィックがある。それらを支えるインフラの現場で働く技術者たちは、どのような手法を用いてトラフィックをさばいているのか。4人の現場エンジニアがパネラーとなり、現状のシステム構成やクラウドの 可能性について、さらには今後の展望などについて語った。 モバゲータウンなど、Feature Phone向けの人気ソーシャルアプリケーショーションは、月間数十～数百億PV（ページビュー）もののトラフィックがある。それらを支えるインフラの現場で働く技術者たちは、どのような手法を用いてトラフィックをさばいているのか。4人の現場エンジニアがパネラーとなり、現状のシステム構成やクラウドの可能性について、さらには今後の展望などについて語った。 モデレータ 株式会社ディー・エヌ・エー
ウノウラボ by Zynga Japan: サーバ情報を収集する Ruby スクリプトを書くには
こんにちは。kyagi です。今回はサーバ情報を収集する Ruby スクリプトを書く方法をお知らせいたします。具体的には Facter モジュール(※1)の紹介と使い方になります。 Ruby にはサーバのホスト名、IP アドレス、OS、ハードウェアなど様々な情報を収集するために Facter というモジュールが提供されています。RPM では「facter」というパッケージ名で提供されています。ターミナルから実施できるインターフェイスとして同名の「facter」というコマンド(※2) が用意されており、以下のように実施するだけでそのサーバの色々な情報を一度に取得することができます。 $ facter (... snip ...) architecture => x86_64 domain => local.hoge.bar.net (... snip ...) ipaddress_eth0
livedoor Techブログ : ウェブサービスのサーバ増設の基本（1台構成から仮想化まで）
お疲れ様です、スエヒロです。 先日発売されました、弊社技術陣が執筆した「4Gbpsを超えるWebサービス構築術」、お手に取って頂けたでしょうか？ ウェブサービスの負荷対策、分散技術など、実用的な話が盛りだくさんの本書ですが、本日は実際に稼働しているサービスのサーバスケールアウト方法を、弊社サービス「livedoor ニュース」を例にしてご紹介したいとおもいます。 0. 問題点の把握 2003年オープンしました「livedoor ニュース」ですが、当時はアクセス数、データ量も少なかったため、サーバ1台で運用していました。 静的な画像やcss、javascriptへのリクエストを処理するapache（80ポート）と、動的コンテンツへのリクエストを処理するmodperl組み込みのapache（8080ポート）を切り分け、mod_rewriteでリバースプロキシし、リクエストをながしています。リバ
AMQPによるメッセージング | GREE Engineering
こんにちは。GREEのプラットフォーム開発部でインフラ系の仕事をしているmdoi(@m_doi)と申します。よろしくお願いします。今回は、AMQPについて簡単に紹介したいと思います。 はじめに GREEで稼働中のサーバは、日々サーバの異常ログ、自己監視結果、メール等々、大量のメッセージをやり取りしています。しかしながら、共通のメッセージングインフラが存在しないため、それぞれが独立に色々なメッセージ送信を行っています。 サーバ台数の増大に伴って、メッセージ配送の負荷が無視できないレベルになって来ると、それらのメッセージングシステムについて、個別に負荷対策を施すなど運用上様々な問題が課題が出てきます。また、メッセージの種類によっては、その配送の仕組がスケーラビリティに欠けるものとが存在し、規模の増大に対応できなくなる恐れもあります。そのため、こういうった用途に使えるスケーラブルなメッセージング
Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」
Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」 先週の6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」が開催されていました。 その中で、TwitterのJohn Adams氏がTwitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」（クジラの腹の中：Twitterでの運用）が行われています。Twitterのような大規模かつリアルタイムなWebサイトの運用とはどういうものなのでしょうか？ 公開されているセッションの内容を基に概要を記事で紹介しましょう。システム管理者の新たな役割、Railsの性能の評価、Bittorrentを使った
Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」
Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」 米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」の、Twitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」（クジラの腹の中：Twitterでの運用）を紹介をしています。 この記事は「「Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」」の続きです。 Twitterのサブシステム「loony」「Murder」「memcached」 ここからはTwitterのサブシステムについて紹介しよう。 T
グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
【LAMPで作るソーシャルアプリの負荷対策 ～アプリとインフラの調和のテクニック～】
森本 隼 KLab株式会社 プロジェクトマネジメント部リーダー 2006年KLab株式会社にプログラマーとして入社。 自社メディア事業、SNS事業の開発リーダーを経験し、現在ソーシャルアプリ開発のPMとして活躍中。 セミナーのテーマは 【LAMPで作るソーシャルアプリの負荷対策 ～アプリとインフラの調和のテクニック～】。現在ソーシャルアプリ周りで最もホットな高負荷対策について、KLabの取り組みを紹介しました。 会場は満員御礼で立ち見もちらほら。おおよそ150人程度の方に聴講頂きました（感謝！）。 以下のとおり当日の資料を公開しました。（ソーシャルアプリに限らず）高負荷にお困りの方は必見です！ Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～
Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側
クラウドのように大規模なシステムでは、ソフトウェアの開発と同等以上に、大規模運用の巧拙が、システム全体の成功を大きく左右します。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」で、FacebookのTechnical Operations teamを担当するTom Cook氏が「A Day in the Life of Facebook Operations」（Facebook運用のある1日）と題したセッションで、Facebookがふだんどのような運用を行っているか、紹介しています。 世界でトップクラスの大規模サイトが、普段どのようなツールを用い、どのような方法で運用しているのか、セッションの内容を紹介しましょう。 6年で4億アクティブユーザー、3カ所のデータセンター Tom Cook氏。Facebo
グリーの開発環境（歴史と概要） | GREE Engineering
こんにちは。グリーでインフラ的なお仕事をしているsotarokです。今回は、グリーの開発環境についてお話します。 グリーの開発環境 開発環境どうするか、という問題はエンジニアリングをしている会社であれば誰しも一度は悩んだことのある問題だと思います。開発環境の作り方は、会社やサービスの規模、事業の形態などによって様々ですし、割と小さな規模から「歴史的な経緯」を経て成長してくることが多く、これといったスタンダードがあるわけでもありません。 グリーでも初期の頃から、いくつかの経緯を経て現在の開発環境があります。これは、特に画期的な開発環境やスタンダードに合わせてつくったわけではなく、日々の業務のなかで、あれこれ困ったことやより便利にしたいことなどを解決していくうちに作り上げられたものです。 今回は、グリーの開発環境の移り変わりと、今後の開発環境づくりについてお話させていただきます。 初期の頃の開
グーグルが構築した大規模システムの現実、そしてデザインパターン（3）～教訓編
グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」（グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性）という講演を、6月に行われたACM（米国計算機学会）主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。 講演の内容を4つの記事（MapReduce編、BigTable編、教訓編、デザインパターン編）で紹介しています。この記事はBigTable編の続き、教訓編です。 大規模分散処理システムの構築から学んだこと ここからは、グーグルがたくさんのシステムを経験して学んだことと、それらのデザインパターンなどを紹介していきたい。 まず、大きく複雑な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scaling Social Games
大規模分散システムにおけるストレージの集約
