クラスメソッドが提供するAWS監視サービス(監視オプション)。2018年にリニューアルした際に、その基盤としてはてな社のMackerelを新たに採用しました。なぜこれまで使っていたOSS実装から離れてSaaSに乗り換えたのか? なぜMackerelだったのか? 当時を知る担当者が赤裸々にお話します。 …
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
はじめに 以前こんな記事を書きました。(ほぼリンク集ですが・・) tekunabe.hatenablog.jp 今回はこれのプレゼン資料版のような記事です。ここ半年くらいの資料を対象にしています。 具体的なツールの使い方などのスキルとは別に、考え方についても備えていきたいと思っています。 運用自動化、不都合な真実 いろいろと考えるきっかけになった資料です。 "「やれるところから始める自動化」は弊害を生む" "使う人が自分で作るしか無い、という結論" 生き残る運用管理者 ~運用自動化を成功させる人、失敗させる人~ "成果だけ出したい人にはお手軽なため「焼畑農業的な運用自動化」をする人に注意が必要。" その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 (2018/07/17リンク追記) リクルート流SRE インフラ運用がサービスを変える世界 新卒
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを1〜2時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く