サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
wtatsuru.hatenadiary.com
この記事は Mackerel Advent Calendar 2023 の10日目です。ちょっと出遅れてしまった、けど投稿日は無理やり調整しています。 今年のネタは今年のうちに供養するため、今年9月に開催された SRE NEXT 2023 というイベントで発表した内容の紹介です。発表資料はこちら。 speakerdeck.com SREの考え方は最近だいぶ浸透してきたなと感じます。今年の SRE NEXT での発表も、大企業での導入事例や実際に運用・改善してきたふりかえりなど、実践的な内容が多くなってきてますね。いいことです。 一方で、世間を見渡すと、まだ導入の時に苦労していることも多いなと思います。普段 Mackerel を開発しているので、余計にそういう声が聞こえやすい立場でもあるかもしれません。SREの考え方っていうは組織に導入するものなのでトップが理解してると導入が楽ですが、そのた
これは Mackerel Advent Calendar 2021 の5日目の記事です。昨日は @sogaoh さんによる [Day.04] Mackerel で かんたん AWS SES の bounce rate 監視 でした。 はじめに 先日、仕事用マシンを Apple Silicon 搭載の MacBook Pro 14インチ (2021) に更新しました。2018年の13インチからの乗り換えだったんですが、快適さに驚いています。リモートワークでビデオ通話を含む多くのツールを同時に動かすことも多いんですが、引っ掛かりを感じることがほとんどなく過ごせています。 今日から M1 MacBook Pro に変えて仕事してるのだけど、ビデオ通話しながら Google Docs を複数開いて miro に絵を描きつつ裏で docker build する、みたいな荒い使い方しても普通に快適に過
3月頃から自宅勤務をメインにしており、2年くらいはリモートメインになりそうな状況になった。チームメンバもだいたいリモート作業していて、仕事を進める上でそんなに不自由はしていない。しかしこれまで自宅に作業スペースがなく、ソファで仕事していてあまりいい状態でなかったので、この機会に仕事用・作業用の部屋を作った。 pr.hatenastaff.com まずは引っ越し 会社の近くに住むメリットがなく、また作業場所を作ろうにも物理的に場所がなかったこともあり、まずは引っ越しをした。 10年以上それなりの都会に住んでたので、いきなり離れすぎることに対する不安もあり、会社からある程度の距離に収まる(電車で1時間以内)範囲から探した。ちょっと郊外のベッドタウンで駅徒歩10分ちょい、5畳くらいの個室を確保できる分譲賃貸マンションで、いいところが見つかった。 作業環境作り 作業環境まずは机。会社で教えてもらっ
ISUCON10、ヌルポインターマリアユニバースというチームで id:polamjag id:Pasta-K と一緒に出てきました。 isucon.net 最終スコアはたぶん2335、なんとか予選突破できました。 振り返り 今回はあまり役割を決めず、時々で臨機応変に動くぞとやってました。結果的にインフラ面はだいたいやることになったし、結果につながったのはよかった。とはいえやった作業自体は簡単なものなので、もうちょっとコードを見られたはずだし、絶対的に足りない気はしてる...。 最初にルールを全員で読んだ これはよかった。スコア算出、ルールの問題についての認識は最後まで問題なかった リポジトリに入れるのをまかせつつ、ログ出したりデプロイ準備したりしてた デプロイ準備は長引いてしまった。問題についての雑談をしながら準備してしまったからで、ここはひたすら作業だとわかってたから思い切って集中してよ
こんにちは、id:wtatsuru です。この記事は、はてなエンジニア Advent Calendar 2018 8日目の記事です。昨日は id:taketo957 による aws-cdkを用いた開発事例の紹介 - taketo957の日記 でした。 このエントリでは、はてなでAWSをどのように使ってきたかを、サービス基盤の開発・運用の観点から振り返ります。 黎明期 はてなで最初にAWSをプロダクションに投入したのは2011年、はてなブログβリリース時でした。当時は EC2 のみのオンプレミス側と同じ構成からスタートしています。 JAWS-UG-Kyoto-2nd Dev Ops at Hatena VPNを張って共通のネットワークに置き、監視やセットアップでもオンプレミス側となるべく共通のものを使う、という思想で構築・運用を開始しています。今で言う EC2 Classic のみ、アカウン
ISUCON5 本戦に、同僚の id:motemen id:ichirin2501 と一緒に 2nd Party Cookies として出場してきました。 結果は7位に終わり、トップの fujiwara 組に3倍近い差をつけられてしまう結果となってしまいました。 まず全体 今回の題材は、社長が作ったマイクロサービスアプリの改善。予選の凝ったDB設計とアプリからはがらっと変わって、DBは PostgreSQL に変わったもののそこは焦点からは外れ、外部APIコールの最適化がメインのテーマとなりました。 予選に続いてとてもいい問題で、ベンチマークもスムーズで非常に楽しめました。運営の皆様は大変だったと思いますが、ありがとうございました。 個人的には、初動や全体の方針はそこまで悪くなかったものの、インフラ担当としての開発支援や視野の広さ、実現に持っていく力という部分での差の大きさを痛感しました。
ISUCON5 予選に参加し、無事に決勝に進むことができました。今年は、社内で id:motemen id:ichirin2501 と、 2nd Party Cookies というチームで出場しました。id:motemen がアプリ、id:ichirin2501 はアプリ / DBまわり、自分はインフラ全般を担当しました。結果は総合10位で決勝進出ですが、同じく社内若手エンジニアのチーム「はむちゃん」に負けてしまって悔しさいっぱいです。 やったこと 事前準備として、分析等の環境整備用セットアップスクリプト、nginx / slowlog の解析準備、ミドルウェアよくある設定復習、デプロイ雛形あたりまではやって臨む。 最初1時間とってた準備時間でサーバ構成を把握して、サーバ環境整備+最初のログ取得・解析。2台立てて1台はsandbox化。 普段あまり使っていない systemd でちょっと手
こんにちは。id:wtatsuru です。 この記事は はてなエンジニアアドベントカレンダー2014 の19日目です。昨日は、 id:hakobe932 による golangで書かれたSlack bot でエンジニアに話題提供しよう - はこべブログ ♨ でした。 今日は、Webサービスのシステム運用において不可欠なサーバリソース可視化の、はてなにおける運用の簡単な紹介をします。 はてなとサーバ管理ツールと可視化 サーバを運用する上で、日頃のサーバのリソース等の可視化と監視は必要不可欠なものです。その対象はCPU使用率やメモリ使用量などのOSレイヤから、ミドルウェアプロセス状況、レスポンスタイムまで多岐にわたります。このデータを蓄積しておくことで、システムの状態を正確に把握し、問題に対処することが可能となります。*1 はてなでは以前から、内製のサーバ管理ツールでサーバの管理を行っていました
このときにやった可視化部分の話。急いで作ったのでいろいろ雑な部分が多い。 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuru's blog はじめに 元のやつから内部情報を削ったサンプルを置いておきます。適当にサーバ名など修正すれば使えるかもしれません。 https://github.com/tatsuru/docker-sample-app 全体の仕組みについてはここの図がわかりやすいと思います Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ やりたいこと 目的はアプリケーションの現状を俯瞰できるダッシュボードを作ること。 それぞれのDockerコンテナは短命なので、下記の情報をうまく集約してやる必要がある。
3日間の開発合宿で、Docker と Mesos を使ってリソース管理からテスト・デプロイ管理までするやつのプロトタイプを作ってた。 4人チームで3日間みっちりやって、それなりにいい感じにはできたと思う。id:shiba_yu36 が既に書いてるけど、自分の視点から感想だけ書いておく。 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 経緯 最近忙しくてあまり触れてない、Immutable Infrastracture みたいなのを作ってみたかった。 Docker を開発に使うのはいい感じだけど、実際の運用に組み込むには、というイメージをつかみたかった。 というのをラーメン屋で話してたら4人集まったので風呂敷を広げてみた。 どんなものを作ったか アプリケーションは Docker コンテナとして動かす。 Debia
isucon に Third Party Cookies として id:onishi さん、 id:motemen さんと参加してきました*1。よく言えば7位、完走した中では最下位、惨敗でした。変更はけっこうrevertしてしまったので初期スコアとあまり変わりません。。 ISUCON公式Blog やったのはこんなかんじでした。他の2人がアプリ中心なので自分はインフラ側の視点から、という立場でした(今思うと区切ってしまったのがよくなかった) アカウント・互いのログイン・hosts そういうの整える nginx に入れ替えて ltsv ログ、mysql の slow.log、logrotate まわり整える ログと時間の割合の分析を見てアーキテクチャの目標をなんとなく思い浮かべる。とりあえず1台で帯域飽和するかどうかまで見てみる mysql 自体はチューニング要らないのでスキーマだけちょろっと
酒代がほしくて ISUCON3 に初参加してきました。暫定スコアは2日目5位総合11位くらいなのでたぶん決勝いけてると思います。。。 優勝賞金ドドンと100万円! 第三回 ISUCON 開催のお知らせ #isucon : ISUCON公式Blog 立ち位置的な すごいアプリケーションエンジニア2名 (id:onishi さん id:motemen さん) と参加したので、メインの方向性は2人におまかせしてひたすら下の方のチューニングをやってました。 普通に仕事でやる分程度にはやりましたが、それ以上のドラスティックな変化が足りなかったかなと反省です。 やったこと まずは一目見て変なところの調整から入る。 innodb memcache plugin とか使ったことないし知らんので memcached 使わせる。 一目見てダメなクエリ対策で index 追加 prefork httpd, ke
EC2で同じECUだけどCPUは違う - まめ畑 こういう記事を見て気になったので、社内のDBからCPU情報引っ張ってみた。ちなみにEC2は3年ほど前から使っています。 Nehalem から Sandy Bridge までずらっと*1。最近は Sandy Bridge に出会う割合が高くなってきている印象です。 Intel(R) Xeon(R) CPU E5410 @ 2.33GHz Intel(R) Xeon(R) CPU E5430 @ 2.66GHz Intel(R) Xeon(R) CPU E5506 @ 2.13GHz Intel(R) Xeon(R) CPU E5507 @ 2.27GHz Intel(R) Xeon(R) CPU E5620 @ 2.40GHz Intel(R) Xeon(R) CPU E5645 @ 2.40GHz Intel(R) Xeon(R) CPU
[http://atnd.org/events/21055:title-JAWS-UG - Kyoto勉強会 第2回] で、「はてなブログの下側」というタイトルで発表してきました。 JAWS-UG-Kyoto-2nd View more presentations from Tatsuru Watanabe 内容に関してはこんな感じです。 はてなのサービスとして初めてAWS上でリリースされた、はてなブログのインフラ面について。 ベータ中の体制と将来的な案、それに関わるメリットと不安。 柔軟なインフラが作れてうれしい! L2, L3 の自由が無くて苦しい! CPU・メモリは安くてうれしいが、SSD中毒なのでI/Oつらい!
このページを最初にブックマークしてみませんか?
『wtatsuruの技術方面のブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く