予選敗退から学ぶISUCON10の正しい歩き方 - そーだいなるらくがき帳
チームメンバーの感想エントリーはこちら。 blog.kamipo.net memo.sugyan.com 良い問題だった。 それだけに悔しくて、悔しくて、この2日間ずっと考えてたけど、どこかで区切りをつけなきゃいけないので筆を取る。 去年の失敗から学んだこと 先によかったことを書く。 まずギリギリまで手を動かせるほど力を出し切った。 兎に角みんな id:kamipo さんの 感想戦を見てほしいのだけどやりたいことはまだまだ沢山あった。 けど時間が全然足りなかった。 昨年のような手詰まりにならなかったのは成長だと思う。 github.com また初動の対応やNewRericを試す、愚直なprintデバッグを用意するなど反省を活かせたところも沢山あった。 こういうのは「去年と同じチームで出たメリット」だったなと思う。 だからこそ、去年よりも悔しさは大きかった。 そしてそれだけ力を出し切って負け
トラブルを解決できる人になろう - そーだいなるらくがき帳
そんな想いを込めてこの特集記事を書きました。 自分が担当したところ バックエンドとデータベースの2つの章を担当しました。 バックエンドもデータベースもトラブルはISUCON9を題材にWebアプリケーションのトラブル、特にパフォーマンスチューニングについて話を書いています。 この本に書いてあることは明日から使える実践的な内容になったと感じています。 これはISUCONの問題がとても実践的で現場に即した内容だからこそ。 だからISUCONを題材にすることを快諾していただいた @941 さん @catatsuy さんは感謝しています。 本当にありがとうございます！！！ この本を読めば予選抜け出来るとは言わないけど何も出来なかった！ってことは無いんじゃないかなといえるくらいのHowは書いたつもりです。 これをきっかけに是非、ISUCON9の予選問題もチャレンジしてみてください。 isucon.ne
障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
iptablesの監視 ~ mackerel-plugin-conntrackを読み解く - そーだいなるらくがき帳
この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の15日目です。 qiita.com soudai.hatenablog.com それでは15日目は mackerel-plugin-conntrack です。 mackerel-plugin-conntrackはiptablesのトラッキング情報の統計情報である ip_conntrack を監視するプラグインです。 github.com ip_conntrackってなに？って方のためにすごくよくまとまったエントリーがあったのでこちらをどうぞ。 あなたの大量配信サーバ、ip_conntrack溢れていませんか？│株式会社イー･エージェンシー インストールと設定手順 本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。 インストール先は /usr/
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
今こそ知りたい、2大OSSデータベースのMySQLとPostgreSQLの違いについて話をしてきた - そーだいなるらくがき帳
去年書いたSoftwareDesignを題材にお話してください！って言われたので話してきました。 下の特集記事は１年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ！ gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね！！ ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
