矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
・2年で月間10億PVを支えるまで成長した ZenClerkの運用上の工夫を紹介 ・AWSのTipsとあるある話の共有
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップ フロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない 自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。 フロントエンドの本番コードベースは一つのものを共有 日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion（過去の経緯で使っている。）にコミットする 同じエンジニアがコードをコミットする間隔は中央値で10時間 本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード
https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドのRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン
企業がマーケティングの自由度やブランドのファンとの緊密な結びつきなどを求めて、自社のブランドを冠したECサイト、オフィシャルストアを構築するのは、技術的にはそれほど難しいことではないように見えます。 しかし、ゲーム開発企業の「スクウェア・エニックス」やアニメ制作企業の「アニプレックス」、アーティストの「Dreams Come True」、アイドルグループ「SKE48」などのオフィシャルストアのためのECプラットフォームを提供するクロスワープのデータによると、熱心なファンを集めるブランドのオンラインショップなどでは、限定グッズなどの発売時に予想もできないほど突出したトラフィックが津波のように押し寄せることになります（前回「大規模なトラフィックを捌く基本テクニックは。ECプラットフォームを提供するクロスワープに聞く」参照）。 こうした状況でたとえばオフィシャルストアが過負荷で落ちて、新製品や限
おそらく世界でもっとも大規模にMySQLのクラスタを展開し、運用しているのがFacebookでしょう。複数のデータセンターにまたがり何千台ものMySQLサーバを運用するために、自動化の仕組みは欠かせません。 その自動化がどのような仕組みになっているのか。FacebookのデータベースエンジニアであるShlomo Priymak氏が、Under the hood: MySQL Pool Scanner (MPS)という記事をFacebookで公開しています。 かなり長い記事なので、ここではそのポイントをまとめて解説してみました。詳細はぜひ原文をあたってみてください。 MPSのおもな3つの機能 Facebookで稼働しているMySQLは、つねに1つのマスターとそこからレプリケーションされた複数のスレーブによるレプリカセットを構成しています。このレプリカセットの構造を維持し続けることで、可用性と
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
はじめに 近年注目されているサーバー管理ツール「Chef（シェフ）」は、ファイルに記述した設定内容に応じて自動的にユーザーの作成やパッケージのインストール、設定ファイルの編集などを行うツールだ。今回はこのChefについて、基本的な環境構築方法と使い方を紹介する。 前回はサーバーの設定管理ツールとして「Puppet」を紹介したが、今回紹介するChefは、このPuppetと人気を二分するサーバー設定管理ツールだ。 Chefは米Opscodeが開発しているオープンソースソフトウェアで、Rubyなどのオープンソースな技術を使って実装されている。ライセンスはApache License 2.0だ。同社はChefにいくつかの機能を追加した有償版の「Private Chef」やクラウド型の「Hosted Chef」といったサービスも提供しているが、本記事ではオープンソース版のChefについて紹介する。
こんにちは！ 先月ドワンゴは歌舞伎座に引っ越したので"銀座"にあうように人生初の美容院に行ったけど、結果は床屋で切ったのと変わりなかった氏家です。 前回はChefとはなんぞや、というところで終わってしまいましたが、今回は導入編で、 - 最新のChef Solo 11.6.0、Knife Solo 0.3.0 限定 - 導入から実行するまでの、迷わない セットアップ手順 及びファイル構造の新定番！ を提案したいと思います。 それは、私がChef Soloを導入しようとしたときに引っかかった インストールして使い始めるまでのとっつきにくさ 開発環境と本番環境をどうCookbookで表せばいいのか 用途の違う複数のサーバーや、複数のプロジェクトを、どう管理するのがよいか 開発メンバーにも秘密にしたい秘匿情報は… といった問題をどう解決したか、そして少しでもChef導入の手助けになればと思っていま
Chef使おうとしてるけどChefいろいろつらい． 具体的には以下がつらい． 独自概念多い chefのクライアントを対象ホストに入れなければならない knifeとか覚えないといけない外部ツールがある 最初からディレクトリ構成がわいわい (rails newしたときのあのきもち） 公式ドキュメントの量が多いかつわかりにくい 以前にmiyagawaさんのpodcast を聞いてたらnaoyaさんがAnsibleっていうシンプルなプロヴィショニングツールがあるっていう話をされていたので，使ってみた． AnsibleWorks | Radically simple IT orchestration Ansible 触ってて感じるイメージは，ChefがRailsでAnsibleがSinatraな感じ． ディレクトリ構成がない (一応大規模運用を考えたディレクトリ構成のベストプラクティス Best P
Munin の監視ノードが増えてくると、ストレージの IO がボトルネックになりがち。Munin によるランダムなファイルの読み書きが主な原因。改善するためには、 rrdcached と Munin を連携する方法が手軽で確実な方法です。Muninサーバの処理が重いなと思ったら、SSD など高速ストレージを導入する前に、まずは rrdcached の導入がおすすめです。 記事内容は、rrdcached のメリット（1台で300ノードまでの監視に対応）と、RHEL5 で導入したときの手順メモ、そして rrdcached の効果を知る為の rrdcached プラグインの導入方法です。 ■rrdcached を何故使うのか？ Munin は収集データを RRD ファイルに格納し、グラフ描画時に再び参照します。このとき、ストレージに対する読み書き(IO)が増えます。 とりわけ、負荷になりがちなの
技術開発チーム・運用技術開発担当（通称opdev）の辰已です。 opdevは社内のさまざまなプロダクトの開発・保守運用を行っており、日々業務効率改善、ハートビーツの価値向上に繋がる技術開発・情報発信を行っています。 先日、opdevで開発した社内向けのプロダクトに対して、Visual Studio Code（以下VS Code）とPlaywrightを使ってE2Eテストを実施しました。 セットアップが簡単で、使い勝手も良かったので、今回はVS CodeとPlaywrightを使ったE2Eテストの実施方法を紹介します。
馬鹿でもわかる Application Server と Reverse Proxy Balancer のお付き合いを考える 一般的な Web Application というのはロードバランサ、Webサーバ、アプリケーションサーバという HTTP を喋るサーバで構成されていると思います。 ロードバランサは高級なハードウェアからソフトウェア(lvs, httpd, etc..)で作るものまで色々ありますね。 アプリケーションサーバでは各種言語に合わせた実装でデーモンが常駐してるでしょう。これはいわゆる普通の Web サーバよりは単純なコンテンツを返す性能が低いです。 そんなわけで動的なアプリケーションサーバが有る構成では js や css や画像など静的なファイルは Apache や nginx などの専用の Web サーバでサービスして、動的なリクエストだけバックエンドのアプリケーションを
by @dekokun on 2013/04/07 19:30 Tagged as: Python, Fabric, デプロイツール. 2013/04/09 追記 意外と反響があるようなので、Tips追加しました。 2013/05/10 追記 並列実行について調べたのでついでに追記 「次のプロダクトはシンプルなデプロイツールだと噂のCinnamonでも使ってみるかー」と言っていたら、「Cinnamonは使ってるユーザ数が少なそうだし同様のことが行えるFabricのほうがいいんじゃないですかね。」というツッコミをいただき、今回はPerlのプロジェクトでもないためFabricを使用することにしました。 初めて触るFabric、やはり初学者にはいろいろとよくわからない部分があったため、はまって解決したことや便利なTipsなどをつらつらと列挙していきます。 なお、以下情報はPython2.7及びF
1. 第10回 静岡ITPro勉強会 インフラ部 nginxの紹介 滝澤 隆史 株式会社ハートビーツ MSP事業部 所属 http://heartbeats.jp/ 1 2013-‐‑‒05-‐‑‒18nginxの紹介 2. 私は誰 • ⽒氏名: 滝澤 隆史 @ttkzw • 所属: 株式会社ハートビーツ ▫ サーバの構築・運⽤用や 24時間365⽇日の有⼈人監視をやっている会社 ▫ いわゆるMSP（マネージド サービス プロバイ ダ） • nginxとの関わり ▫ 所属会社の技術ブログ「nginx連載」 – http://heartbeats.jp/hbblog/nginx/ ▫ Software Design 2012年年12⽉月号 第2特集「⾼高速・⾼高機能HTTPサーバ Nginx構築・ 設定マニュアル」 2 2013-‐‑‒05-‐‑‒
3. システム構成 • Node数：97台 • サーバスペック 機器：Dell R410、R420 メモリ：64GB CPU:16コア、24コア HDD：600GBx4 (RAID-10) 600GBx2(RAID-1)+SSD 512GB(RAID-0) • クラスタ数：1 • Cassandraのバージョン：1.1.5-2(独自バージョン) • KeySpace数：8 • ColumnFamily数：156 4. 運用状況とか Cluseter Writes Request: 32000/sec Cluseter Reads Request : 58000/sec 1 nodeあたりのデータロードサイズ 約200～230GB
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
