「サーバにログインしない・させないサービス運用」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
メモった。間違い等あるかもしれませんが、その場合はごめんなさい。 Gunosy 2011.09リリース 現在900万DL突破 エンジニアは現在26名 2014.11は16名、2013.11は7名、2012.11は4名 クライアント+QAは5名、Web+APIまわりは5名、インフラは1名とかとか Gunosyの開発 API: Golang パートナー・広告主への管理画面: Rails バッチ・内部向け: Django or Python バージョン管理: GitHub 構成管理・デプロイ: Chef (+OpsWorks) 開発の特徴 小さい単位で作ってすぐ捨てる マイクロサービス的な 機能が増えすぎたら分割 メンテするよりリプレース サーバにログインされて困る事 信頼できないビルド・デプロイ 開発者の手元でビルドすると、どの断面なのかわからずトラッキングできない プロダクションに上がってい
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog
Redisへと至る、gumiデータストアの歴史
