しばらく前に作って書きそびれていましたが、Yokohama.pm #10 でLTしたのでエントリもあげます。 Perl版 https://metacpan.org/release/Redis-Setlock Go版 http://fujiwara.github.io/go-redis-setlock/ LTのスライドはこちら ⇒ Redis-Setlockを書いたはなし なにをするもの? 「setlockコマンドのロック処理をRedisサーバで行うもの」です。 setlockはflockを使ってロックを獲得したら引数に渡されたコマンドをexecする、daemontools付属のwrapperコマンドで、cronでコマンド実行するときなど多重実行を制御する場合に重宝します。 flockだとホストをまたいだロック処理が行えないため、その部分をRedisを使った排他制御に置き換えたものを書いてみ

Amazon ECS のタスク定義には、タスク内のコンテナの起動と終了の順序を制御する依存関係が定義できます。 docs.aws.amazon.com アプリケーションのコンテナと、アプリケーションが依存しているミドルウェアのコンテナがあった場合、依存を定義すると タスク開始時にミドルウェアが起動してからアプリケーションが起動する タスク終了時にアプリケーションが停止してからミドルウェアが停止する というような制御が可能です。 graphviz による可視化 しかし依存関係が複雑になると、JSON で文字列で書いただけでは実際にどう依存しているのかがよく分からないし、間違ってループを作ってしまうと起動できないので事前に確認したい、ということで可視化してみました。 これはとあるアプリケーションタスクの依存関係を、task definition の JSON から graphviz 用の .d

とあるネットワーク(Web)サーバがありまして。 graceful restart できない graceful stop はできる 処理中のものは全て処理し終わってから終了する 再起動は数秒で完了する という性質のものを、稼働中に再起動するとダウンタイムがでてしまうのをなんとか誤魔化したかったのです。 最初は nginx から proxy しているところで、繋がらなかったら何秒かおいて何回までリトライ、みたいな設定ができないか探したんですが見つからず、HAProxy を調べたら以下のような設定でできたのでメモ。 frontend absorber mode tcp default_backend upstream bind *:9999 backend upstream mode tcp server localhost localhost:8888 weight 1 retries 10

Mackerel Advent Calendar 2018 22日目の記事です。 ちょっと前に maprobe という、Mackerel のホスト情報と連携して外形監視を行うエージェントツールを作りました。 sfujiwara.hatenablog.com maprobe は指定した Mackerel のサービス、ロールに存在しているホストに対して外形監視を行った結果をホストメトリックとして投稿するものです。定義にしたがって外から ping や TCP, HTTP の疎通を確認した結果を投稿できるのですが、mackerel-agent のメトリックプラグインと互換性のある出力をするコマンドを実行する機能もあります。 今回は AWS インテグレーションで管理されているマネージドサービスのホストに、maprobe でメトリックプラグインで取得したメトリックを追加することで、運用負荷を下げる手法

ISUCON8 の本選問題は、競技者がコントロールできない外部 API 呼び出しを多数含んだ出題内容でした。 講評では、 サービスの特性を適切に分析した上で、まとめるところはまとめたり、遅延させるところは遅延させるなど ……とさらっと書かれていますが、実際そんなことを短時間で分析することは可能なのかよ！という話題が競技後の懇親会でもあったので、それ AWS X-Ray でできるよ、というエントリをまとめておきたいと思います。 今回の解析は Perl 版の初期実装に対して行ったものですが、なぜ Perl かというと AWS の公式 SDK にない X-Ray 関連の CPAN モジュールを自分が書いているので、その宣伝も兼ねています。(blogエントリ書いてなかった) AWS::XRay Plack::Middleware::XRay Devel::KYTProf::Logger::XRay

ISUCON 8 の本選出題を同僚の @ken39arg と担当しました。参加された皆様、運営にご協力して頂いたすべての関係者の方々にお礼申し上げます。 恒例の #isucon pic.twitter.com/iXAjgfgbeZ— fujiwara (@fujiwara) 2018年10月20日 問題についての講評は公式の ISUCON8 本選問題の解説と講評 をご覧頂くとして、こちらでは今回、出題に導入された新要素である「シェア機能」について、どういう経緯で導入されたのか、裏話的なことを書いておきたいと思います。 「ベンチマークの負荷を自分で決めるのも、自動で際限なく負荷が上昇するのも実際のアプリケーションとは違うよね?」というところから思いついた機構なのですが、経緯についてはいろいろな前提と、歴史の理解が必要になります。結果的に長文になってしまいました。 ISUCONベンチマーカーと

全国三千万 Mackerel ユーザーの皆様こんにちは。 mackerel-plugin で生成した値を、サービスメトリックとして投稿したいと思ったことはないでしょうか。ありますよね。でも mackerel-agent ではホストメトリックしか投稿できません。 ということで、拙作の sardine に Mackerel のサービスメトリックとして投稿する機能を追加しました。(Thanks for @jet_zousan) sardine についてはこちらをご覧ください。 sfujiwara.hatenablog.com github.com mackerel-plugin 互換の出力を CloudWatch のメトリックとして投稿する agent です。 おもにコンテナ環境で、mackerel-agent を全部に立てたくはないけど使い慣れた mackerel-plugin で収集した値を

OSS紹介 Advent Calendar 2017 - Qiita 18日目の記事です。(一週間遅れ) Amazon ECS へのデプロイツール ecspresso と、そこで使っている環境変数を展開しつつ複数の YAML/JSON/TOML を読み込む config loader である go-config の紹介をします。 ecspresso github.com 「エスプレッソ」と読みます。Go で書かれた Amazon ECS 用のデプロイツールです。以下の3つのファイルを用いて ECS へのサービス、タスク定義作成、入れ換えを行います。 YAML の設定ファイル タスク定義のための JSON (aws ecs describe-task-definition 出力と互換) サービス定義のための JSON (オプション。aws ecs describe-services 出力の

OSS紹介アドベントカレンダー の14日目の記事です。 Fluentd の 公式 Go 版 Logger である fluent-logger-golang はこのように使うのがよさそう、という使い方をまとめてみました。 元々社内で書いておいたドキュメントを編集したものです。 github.com 前提のユースケース Webアプリケーション(APIサーバ) を Go で書いていて、そこから何らかのログを Fluentd に送信したい。 config のお勧めオプション Timeout : Connect に対するタイムアウト。デフォルト3秒なのでそのままでよさそう WriteTimeout : 書き込みのタイムアウト。デフォルトだとずっと待ってしまうので 3 秒とか? BufferLimit : デフォルト 8MB これを超えると捨てられてしまう。送る流量によって調整が必要 MaxRetry

まずは出題と運営チームの皆様にお礼を。予選から1チーム3台、合計1200台のサーバを用意するという空前の規模で、快適な競技環境を用意していただいてありがとうございました。 isucon.net 今回は ISUCON 4 の時の fujiwara組 (@fujiwara, @acidlemon, @handlename) を再結成して、自称社内最強チームで望むことに。1日目には同じくカヤックから参戦のチーム MSA が1位を取っていて、これは予選通過はもちろん、スコアでもできれば負けたくないという戦いでした。 最終的には 48万点越え、両日通してのスコアでも3位ということで、まずまずの結果が残せたと思います。 やったこと あらかじめ用意しておいた Chef recipe で各種ツールや各人のアカウント作成、公開鍵設定 さくらのクラウドで用意されている Ubuntu から使われるとすれば今回は

初福岡ですが前日は熊本に泊まって馬刺しを食べました。今まで食べてきた馬刺しとはなんだったのか。 合法レバ刺しです 🐴なので pic.twitter.com/v2t7y6pI01— fujiwara (@fujiwara) 2017年6月30日 発表資料はこちらです。 speakerdeck.com github.com 開発してから2年、本番で使いまくっていますが大変安定してますし、いろいろ面白い使い方ができる特性を持っているので、是非お試しください。(rausサポートした版はまだ本番に入れてないですが、今後数ヶ月のうちに入れる予定です)

github.com これはなに? HTTPを使って、ファイルを Consul クラスタ内で分散配布する daemon です。Go で書かれています。読みかたは「たぐる」です。 開発動機とユースケース 拙作の Stretcher というデプロイツールがあります。嬉しいことに、自分が勤務しているカヤックだけではなく、他社さんでも使われているようです。 先日、某社の Stretcher をお使いのかたに話を伺う機会があり、デプロイアーカイブの取得時のネットワーク負荷が問題になっているということを聞きました。 カヤックではサーバは基本 AWS にあり、S3 からデプロイアーカイブ(200〜300MB程度)を取得しています。S3はちょっと意味が分からないぐらい堅牢で、stretcherの -random-delay 5 (開始を平均2.5秒、最大5秒ずらす) を設定した状態で100台程度から一斉に

タイトル長い。 LambdaでGoが正式サポートされるのを首を長くして待ちつつ、Apex で Go を実行しています。 先日、API Gatewayで受けたすべてのリクエストをLambdaに丸投げすることができるようになりました。 Amazon API Gateway に API 設定を簡素化する 3 つの新機能を追加 Amazon API Gatewayが非常に便利なHTTPプロキシとして進化したらしいので使ってみた - Qiita これまではAPI Gatewayでいちいちマッピング定義を作るのが面倒で、いまいち普通のWebAPI的なものをLambdaで作る気がしなかったわけですが、これで行けるのでは…? と思って、catch all されたリクエストとレスポンスを net/http.Request と net/http.ResponseWriter で扱えるようにする ridge と

Norikra に登録されているクエリが大量にある場合、WebUIで登録、編集をしていると複数人での共同作業で管理しきれなくなるため、クエリをファイルにしておいてリポジトリで管理したくなります。 norikra-clientには query add, remove, suspend, resume などの機能が従来からありますが、add, removeは冪等でないため登録されているクエリに対して再度実行するとエラーになるので状態管理は難しい。 ということで、norikra-client に query dump query sync という機能を追加して 1.3.1 で取り込んでもらいました。これで JSON によってクエリを管理し、Norikraと同期することができます。 $ norikra-client query dump > dump.json [ { "name": "test"

chef-server は仕組みが大げさでインストールも大変だし、10〜20台ぐらいなら chef-solo と capistrano を組み合わせればいいよね？（同案多数） Capistranoとchef-soloを組み合わせて使う | ひげろぐ capistrano + chef-soloで構成管理する - delirious thoughts 実はこれまでもずっと、適当に書き殴った shell script で rsync && chef-solo 実行というのをやっていたのですが、複数の json をいい感じにマージして適用したかったので、capistrano で書き直してみました。 fujiwara/chef-solo-with-capistrano · GitHub 方針 cookbook などのファイルの同期は rsync で 共通で使用する json とホストごとにそれを上

Norikra でクエリした結果を Mackerel に投げたい場合、これまでは fluent-plugin-norikra で取得して fluent-plugin-mackerel で送信する、という作りにしていたと思います。 Norikra 1.2以降では Listener plugin が使えるようになったので、クエリ結果を直接 Norikra 上で扱うことが可能になりました。 ということで、norikra-listener-mackerel (rubygems) を書きました。Norikra 単体で、クエリ結果を Mackerel のサービスメトリクスとして送信できます。 使い方 $ gem install norikra-listener-mackerel norikra が動作する ruby でインストールすれば、norikra start 時に自動的に読み込まれます。 クエリ

ISUCON5、予選を無事通過して10/31(土)に開催された本選に参加し、優勝しました。 チームは ISUCON 1 の時の初代「fujiwara組」再結成ということで、@songmu, @sugyan とのカヤックの元同僚メンバーです。 最初に、毎回素晴らしいイベントを開催、運営していただいている @941 さんをはじめとした運営チームの皆様、出題の @tagomoris さん、@kamipo さん、他すべての協力いただいた皆様に感謝を申し上げます。本当にありがとうございました！ 競技開始からベンチ実行まで 作った #isucon pic.twitter.com/5RZkPUsaPu— fujiwara (@fujiwara) 2015, 10月 31 ロゴがなかったので作った。 競技開始、まずは3台で相互にsshできるようにするのに一瞬戸惑う。port 22は開いていて、会場からは接

遅い回線のエミュレーションをしたかったので、Squid で帯域制限をやってみた。 以前にも同じようなことを FreeBSD で bridge + dummynet でやったのだが、今回はお手軽に Squid のみで。 dummynet だと IP レベルで制限をかけるので遅延もエミュレーションできる (遅い回線で遅延を大きくするとか) が、Squid はダウンロード帯域のみの制限になるので、厳密さはちょっと落ちるはず。 squid.conf に以下のように記述。64, 128, 256, 512, 1024kbps の制限を port 別にかけて、クライアントから Proxy にその port を指定してやる。 http_port 10064 http_port 10128 http_port 10256 http_port 10512 http_port 11024 acl 64kbps

YAPC::Asia 2015 でトークを採用していただいたので、発表してきました。 YAPC::Asiaは自分は2006年から10回皆勤で、トークは2009年LT、2010〜2013, 2015は本編で計6回もしてるんですね…YAPC::Asiaにはここまでのエンジニア人生の半分以上を支えてもらっていて、(ひとまず)最後の回でもトークできて感無量です。 1年ぶりにYAPCでしか顔を合わせない人もいた懇親会は、皆さん言うように同窓会のよう、というか本当の同窓会よりも現在の話題を共有している分濃密でしたね。 Consulと自作OSSを活用した100台規模のWebサービス運用 1日目午後一の激戦枠に放り込まれたのでどれぐらい会場が埋まるか心配でしたが、200人以上入る会場でほぼ満員だったようで、聞きに来ていただいた皆様ありがとうございます。 ここ1年程度で本番運用してきたConsulと周辺に関