最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio

勝った！！引退！！！ 取り乱しました。 ずっと参加してきているWebアプリケーションパフォーマンスチューニングコンテスト ISUCON、ISUCON11本選にチーム「fujiwara組」で参加して、優勝しました。 ISUCON11 まとめ : ISUCON公式Blog fujiwara組は初回のISUCONから参加している老舗チームで、自分(fujiwara)以外のメンバーは都度入れ替わっているのですが、今回はISUCON10の時と同様に会社(面白法人カヤック)の同僚である acidlemon と macopy とのチームです。 チーム紹介スライド 過去に ISUCON1, 2, 5 で優勝しているので、6年ぶり4度目の優勝になりました。もう引退していいよね！(というか941さんに出禁って言われた気がする…) やったこと リポジトリはこちらです。 github.com アプリケーションの変

3行で シンプル/ミニマルな Lambda のデプロイツール lambroll を書いてるよ Lambda API 以外は極力触らないやつです 既存 function の移行も簡単です 開発の経緯 AWS Lambda を管理、デプロイするのに数年来 Apex を使っていましたが、最近更新がないと思っていたら案の定というか、残念ながら No longer maintained となってしまいました。 で、代替を探したのですが… Lambda管理、Apexがお亡くなりになってServerlessかSAMになるんだけど、本当は関数だけdeployできればよくて(IAMとか関連リソースはTerraformでやるんで)、それなら裏でCloudFormationが動くようなのじゃないシンプルなのがいいなあ。作れば作れるけどデプロイツールばっかり書くことになるな…— fujiwara (@fujiwa

あるところに、ひとつの Web サービスの本番環境が 20 個以上の Terraform state で管理されているリポジトリがありました。 おもに AWS 上で動いている、大変年代物かつ巨大なモノリスのサービスです。最初は何もコード管理されていない状態から徐々に Terraform を導入したのですが、その際に「一度に全部管理はできないから、徐々に Terraform 化していこう」という方針で管理を始めたところ… 新機能を追加するのでそのリソースを別 state で管理 改修があるのでそれらのリソースを別 state で管理 を繰り返すうちに、中に数個程度しかリソースがない state がどんどん増殖し、いつの間にやら20個以上になってしまったという状態です。ちなみにリソース定義は合計で 500 程度ありました。 さすがにここまで分割されてしまうと相互参照はできないし、VPC / S

とあるネットワーク(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

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ベンチマーカーと

ハッカーズチャンプルー2018 で Go と ISUCON について話してもらえませんか? というお誘いをいただきまして、20年ぶりに沖縄に渡っております (注 まだ帰ってないので現在進行形)。 発表資料はこちらです。 speakerdeck.com 前日〜前夜祭 早めの飛行機で昼前に着いたので、瀬長島という空港から車で15分ぐらいの島へ渡って、沖縄らしいもの…ということでハンバーガーを。 ヤバい pic.twitter.com/MDSxfaSFRu— fujiwara (@fujiwara) June 29, 2018 氾濫バーガー チムフガス というお店の「氾濫バーガー」すごい。1.5cm厚のほぼ脂身なベーコンとパティ2枚、40過ぎの人間が食べるものではないのでは…と思ったけど意外としつこくなくて完食。 寝不足の状態で沖縄の凶悪な太陽を浴びたため、その後ホテルで昼寝して、起きたら前夜祭

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

ISUCON 6 にチーム「morimoto組」で参加して、最終スコア 36,067 で準優勝しました。 morimoto組は自分と、会社の新卒1,2年目( kasari , id:moshisora ) という歳の差チームです。 今年も作りました #isucon pic.twitter.com/y2fX4HiJys— fujiwara (@fujiwara) October 22, 2016 お題 匿名お絵かきサービス ログイン、セッション管理などはない SSE (Server Sent Events) で他のユーザの書き込みがストリーミングで流れてくる 一番前に React のサーバサイドレンダリングをする node のプロセスがいる react, 各言語実装のアプリケーションサーバ, MySQL はすべて Docker で起動している やー、盛りだくさんでしたね… スコア推移とやった

ISUCON 6 にチーム「morimoto組」で参加して、予選を通過して決勝進出することになりました。 ISUCONは過去5回のうち優勝3回、3位1回、出題1回、ということでもう引退(勝ち逃げ)しようかな…とも思ったのですが、今年は出題にも関わっていないので参加しないと完全に縁が切れてしまうし、それも寂しい。ということで。 チームメンバーは直前まで決まらなかったのですが、結局会社の新卒1,2年目( id:amusan , id:moshisora ) と組むことにしました。若いとはいえ去年と今年の社内ISUCON優勝メンバーです。(歳の差何歳だろう) 当日やったこと 設営完了 #isucon pic.twitter.com/Beu4lLiYnC— fujiwara (@fujiwara) 2016年9月18日 天気は悪いが見晴らしはいい会議室を確保して万全の体制 (まぶしいのですぐブライ

Fluentd 0.14 がリリースされましたね。 Fluentd v0.14.0 has been released | Fluentd 新機能が盛りだくさんですが、そのうちの一つ Sub-second time (秒未満の解像度のtimestamp) に Fluent::Logger 0.18で対応しました。 <source> type forward </source> <match **> @type file path ./test time_format %Y-%m-%dT%H:%M:%S.%N </match> このような fluentd.conf で fluentd 0.14 で起動して、以下のように event_time オプションを真にした Fluent::Logger から送信すると、 #!/usr/bin/env perl use 5.12.0; use Fluen

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 の予選1日目にチーム「fujiwara組」(@fujiwara, @songmu, @sugyan) として参加して、全体通して1位のスコアで通過しました。 isucon.net 今回は ISUCON 1 の時の優勝チームを再結成という形になったわけですが、最初はISUCON 4の時と同じ社内のチームででようかと思ってたんですよね。ところが昨年優勝チームだった「LINE選抜 生ハム原木」が今回参戦できないということで、sugyanがチームどうしよう、と困っていたのでつい…*1 初代fujiwara組を再結成しよう— fujiwara (@fujiwara) 2015, 5月 27 準備 今回はOSは Ubuntu(バージョン非公開)なのが事前にレギュレーションで公開されていたので(前年まではCentOS, Amazon LinuxなどのRedHat系ディストリビューションで

fluentdで集約したログをRedshiftに投入するのに、これまでは fluent-plugin-redshift を使っていたのですが、諸々の理由でこれを置き換えるツールをGoで書きました。 Rin - Redshift data Importer by SQS messaging. プロダクション環境に投入して、2週間ほど快調に動作しているので記事を書いておきます。 アーキテクチャと特徴 S3にデータが保存されたタイミングで、Amazon SNS または SQS にメッセージを飛ばすイベント通知機能がありますので、それを利用しています。 (何者か) S3 にデータを保存する (fluent-plugin-s3, その他どんな手段でも可) (S3) SQS に S3 の path 等が記述されたメッセージを通知する (Rin) SQS のメッセージを受信し、Redshift へ CO

ISUCON4 に「fujiwara組」として参戦しましたが、既報のとおり 3位に敗れてきました。順位こそ3位で賞金10万円は獲得できたものの、スコアが示すとおり内容的には完敗です。 まずは主催のLINE社様、出題を担当していただいたCookpad社様、本番サーバ提供をしていただいたテコラス社様にお礼申し上げます。本当に楽しいイベントをありがとうございました。 うちのチームとしてやったことは #isucon 4の本戦で3位を取ってきました (追記あり) - beatsync.net に大変詳しいので、そちらをご参照ください。 簡単に最終的な構成をまとめると Redisは1号機に(動画以外)集約 動画はアップロードを受けたサーバがローカルファイルとして保存しnginxが返す。保存されたサーバのアドレスをメタデータとしてRedisに保存し、APIへのレスポンスに含まれるURLを構築するのに使用

ISUCON1, 2と「fujiwara組」で連覇し、2013年には出題を担当しましたが、今年は一参戦者として挑戦することになりました。 今年は弊社からの本選枠もなく(共催ではないので)、予選落ちしたらそれまで チームは ISUCON 1,2のメンバーが自分以外全員退職(…) してしまったため、去年の出題担当 @acidlemn @handlename で新規編成 というなかなかプレッシャーのかかる状況でしたが、さしあたり予選2日目の暫定1位スコアを出すことができました。(後述しますが、一部レギュレーションに引っかかる可能性のある修正をしているため、失格となる可能性はあります。その判断が下された場合は、当然受け入れます) 速報結果はこちらです ISUCON4 オンライン予選 二日目の結果発表 : ISUCON公式Blog 例年のことながら、大変楽しいイベントでした。運営・出題をしていただい

タイトルが長いですが、つまりそういうものをGoで書いています。 fluent-agent-hydra - Github (hydraっていうのは首のいっぱいあるアレです。キングヒドラとか) 特徴 fluent-agent-lite 的なファイルを tail -F のように追尾する機能 1プロセスで複数ファイルを追跡できます in_tail のような pos_file, parse 機能は今のところありません in_forward 的な TCP で msgpack 形式のログを受け取る機能 各種言語の logger (Ruby, Perl, Go など) から投げたログを受け取って fluentd に送り直せます JSON 形式には対応していません 簡易的なオンメモリバッファを持っています 上記から入力されたログを fluentd に送信する out_forward 的な機能 複数の送信先を

すっかりISUCONのことも忘れかけたある日曜日のこと… @fujiwara ISUCON3のチーム毎のベンチ回数が公開されてないと思うんですが！ 2013-12-08 02:09:12 via Twitter for iPhone to @fujiwara そういえば公開していませんでしたので公開します。 success, fail, 順位とベンチマーク試行回数の相関はあまりなさそうに見えますね。 rank name count(*) Miami 11 50ms or die. 15 Noder 25 1 LINE選抜「チーム生ハム原木」 25 白金動物園 27 ( (0) / (0)) ☆祝☆ 28 :ok_woman: 28 5 山形組 31 4 くらげとみかんと江戸幕府 34 6 銀杏絶滅しろ 34 ぜかまし 40 チームぽわわ2 40 かまたまうどん 40 勝浦タンタンメン 41

参加者の皆様、共催で運営となった LINE, DataHotel, カヤック各社の皆様、本当にありがとうございました。いくつかトラブルがあったものの、本選もなんとか無事に終えることができました。 まずは優勝した LINE 選抜チームの皆様、おめでとうございます！なかなか初期スコアから上がってこないので内心ものすごく心配していましたが、ポイントを見極めて作業が終わったところで一気にスコアを上げてきたのは感服しました。 本選終了から48時間経過したいまでも頭の疲労が回復しきっていない感じで、整理できていないので思うままにつらつら書きます。 以下長文になってしまうので最初に告知です。 ISUCON3反省会 というイベントを 11/15(金) に行います。ISUCON参加者でなくてもどなたでも無料でプレミアムモルツ飲み放題ですので、日時が迫っていますが是非お越しください。 出題内容について お題は