2005年、伊豆で行われた合宿で、はてなブックマークは産声を上げました。 小さく生まれたこのサービスも、ユーザーの皆様とともに10年の時を歩み、 今では 353,327,075 件ものブックマークが集まるところまで成長しました。 10年という一つの節目を迎え、もっと面白いサービスとなるために、 はてなブックマークは10個の新企画にチャレンジします。
インフラストラクチャー部の成田(@mirakui)です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です
パフォーマンスチューニングガイド 1. 概要 Expand section "1. 概要" Collapse section "1. 概要" 1.1. 本書を読むにあたって Expand section "1.1. 本書を読むにあたって" Collapse section "1.1. 本書を読むにあたって" 1.1.1. 対象読者 1.2. リリースの概要 Expand section "1.2. リリースの概要" Collapse section "1.2. リリースの概要" 1.2.1. Red Hat Enterprise Linux 6 における新機能 1.2.2. 水平方向のスケーラビリティ 1.2.3. 分散システム 2. Red Hat Enterprise Linux 6 のパフォーマンス機能 Expand section "2. Red Hat Enterprise Li
アプリケーション(リソース)に対する監視・制御は,第5回で説明した通り,リソース・エージェント(RA)によって実現されます。Heartbeatでは,以下ディレクトリ配下に,Apacheや仮想IPアドレスを含み,標準で多くのRAが用意されています。 HAクラスタ・ソフトがリソースに対して,具体的にどのような監視・制御処理を実行しているかを知っておくと,構築作業でうまく動作しない場合や,パラメータ・チューニングを行うときに,大いに役立ちます。 また,実際に故障が発生したとき,適切にフェイルオーバーするかどうかは,このRAの実装によるところが大きいため,動作内容の把握は大変意味があります。 RAは,OCF(Open Cluster Framework)という形式に基づき,そのほとんどがシェル・スクリプトで実装されています。今回は,まず前半で,OCF形式RAを読み解く4つの基礎知識を説明し,後半で
懲りずに4回目のPacemaker on AWSネタです。 前回はPacemakerでパブリックIPアドレスであるEIPを付け替えてAWSクラウドデザインパターンのFloating IPパターンを実現しました。 今回はEIPではなく、仮想NICであるENIを付け替えるRA(Resource Agent)を書いてみました。 冒頭で先に言っときますが、今回のRAはあまり実用的ではなく、いろいろ弄ってみた結果生まれただけのものなので、実用的なRAをお求めの方は前回の記事をご参照ください:D aws-eni-resource-agentという名前でGithubに置いておきました。 例によってバグ報告、Pull Request、大歓迎です。 ちなみに過去のPacemakerネタはこちら。 PacemakerでEIPを付替えるResource Agentを書いてみた EC2上でPacemakerによる
変更履歴 2013.9.19 初版制定 2016.3.23 Pacemaker-1.1に対応 ■はじめに Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m みなさん、Pacemaker触っていますか? OSCなどのブースや講演で中の人がPacmakerをデモしているのを見かけると思いますが、ああいう構成って一から自分で作ろうとするとまぁ大変ですよね。 個人的に最初につまづくのが”CRM設定ファイル“だと思います。 例えば、2011年福岡で開催されたOSCで講演したデモ環境のCRM設定ファイル(これに含まれるdemo4.crmファイル)を見てみてください。 長い・・しかも設定ファイルなのに¥記号たくさんww やばい・・ゲシュタルト崩壊して¥がVサインに見えてきた(注1)。。だからみんなPacemakerのことピースメー
{ host: dfs1 what: diskspace mountpoint: srv/node/dfs10 unit: B type: used metric_type: gauge } meta: { agent: diamond, processed_by: statsd2 } What & Why? If you have a handful of metrics, you don't need to think about this and can stick with simple names for your metrics. However, as we grow our number of metrics and/or want to make more sense out of them, we need to be more systematic. Here are
Turn-key Observability Pipeline for DevOps and SRE teams Filling gaps in observability should be easy. With Sensu’s end-to-end observability pipeline, you can collect, filter, and transform monitoring events — sending them to the database of your choosing. Monitoring for mission-critical systems The shift from static to dynamic infrastructure introduces new business requirements for monitoring and
photo by Thomas Hawk Mackerel のフリートライアルが終わってしまったという通知が来て、あちゃーと思ったのだけれど無料分でも遊べそうだったので、手元の MacBook Pro 15inch Retina で試してみることにした。 開発機のロードアベレージとか見てもおもしろくもなんともないので、バッテリの残量を記録するようにしてみた。 準備 最初は普通に clone してきてビルドしたものを使おうとしていたけれど、公式で HomeBrew 用のパッケージが提供されていたのでこちらを使うことに。 tap してインストールするだけなので簡単。しかし、公式にはサポートされていないので自己責任で。 $ brew tap mackerelio/mackerel-agent $ brew install mackerel-agent 起動する前に API キーの設定をしておく。
Open Source High Availability Cluster Stack The ClusterLabs stack unifies a large group of Open Source projects related to High Availability into a cluster offering suitable for both small and large deployments. Together, Corosync, Pacemaker, DRBD, ScanCore, and many other projects have been enabling detection and recovery of machine and application-level failures in production clusters since 1999
今年のCPU実験では、有志からなる我らがX班が、おそらくCPU実験史上初である自作CPUへのOS (xv6) 移植に成功しました。コア係とコンパイラ係の面々がそれぞれまとめ記事を書いていたので、OS係から見たOS移植のまとめも書こうかなと思います。こんなことしてましたってことが伝わればいいなと思います。 この記事を読む後輩やらなんやらがいたら、ぜひ僕らがやったようなことはさっさとクリアしちゃって、さらにさらに面白いことをする踏み台にしていってほしいですね。 どなたが読んでもある程度概要が伝わるよう、まずCPU実験とは何かということをさらっと書いた後、実際にxv6を移植するにあたってやったことをまとめたいと思います。 CPU実験とは CPU実験は僕の学科(理学部情報科学科)で3年冬に行われる、半年間にわたる学科名物演習です。 最初の週で4~5人程度の班に分けられた後、それぞれの班でオリジナル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く