awslim - Goで実装された高速なAWS CLIの代替品を作った - 酒日記 はてな支店
最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio
「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」を執筆しました - 酒日記 はてな支店
「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」という本を6名の共著で執筆しました。技術評論社さんから、2022年6月4日発売予定です。電子版もでます。 gihyo.jp Amazon はこちら。 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon タイトルの通り、ISUCON で出題されるようなWebサービスを例にして、Webサービスのサーバーサイドパフォーマンスチューニングを指南する内容です。通称「ISUCON本」と呼んでください。 2020年の末に、技術評論社さんからWebサービス高速化 × ISUCONに関する書籍を執筆しませんか、と藤原までお誘いをいただいたのが発端でした。 書きたい気持ちはあったものの、内容的にとて
ISUCON11で優勝しました - 酒日記 はてな支店
勝った！！引退！！！ 取り乱しました。 ずっと参加してきているWebアプリケーションパフォーマンスチューニングコンテスト ISUCON、ISUCON11本選にチーム「fujiwara組」で参加して、優勝しました。 ISUCON11 まとめ : ISUCON公式Blog fujiwara組は初回のISUCONから参加している老舗チームで、自分(fujiwara)以外のメンバーは都度入れ替わっているのですが、今回はISUCON10の時と同様に会社(面白法人カヤック)の同僚である acidlemon と macopy とのチームです。 チーム紹介スライド 過去に ISUCON1, 2, 5 で優勝しているので、6年ぶり4度目の優勝になりました。もう引退していいよね！(というか941さんに出禁って言われた気がする…) やったこと リポジトリはこちらです。 github.com アプリケーションの変
ISUCON10予選に参加して不通過でした - 酒日記 はてな支店
Webアプリケーションパフォーマンスチューニングコンテスト ISUCON http://isucon.net/、記念すべき10回大会の予選に参加して、あと3チーム100点弱の差で不通過に終わりました。悔しい！ チームメイトは会社の同僚の @acidlemon (ISUCON 3の出題、ISUCON 4, 7 のチームメイト), @mackee_w (macopy, 実はチームを組んだのは初) です。 序盤から中盤 ベンチを回して MySQL が重いねー(いつものことだ) と把握 acidlemon estate の範囲検索になっているカラムを = 条件で取れるように 0〜49999 -> 0, 50000〜100000 -> 1 のようにクラスわけ(verify がたまにコケるのを解消できず取り込めず interpolateParams=true (server side prepare
FirehoseのHTTP配信機能でMackerelにメトリックを投稿する - 酒日記 はてな支店
先日、Amazon Kinesis Data Firehose が任意の HTTP エンドポイントに対しての配信機能をサポートしました。 aws.amazon.com 従来の S3 / Redshift / Elasticsearch Service などのマネージドなリソースに対してデータを配信する機能に加えて、自分で作った HTTP(s) のエンドポイントに対しても Firehose からデータを投げ込んでくれる機能です。 Amazon Kinesis Data Firehose now supports data delivery to Datadog 既に Datadog や New Relic へもマネージドでデータを配信できていて、それらに送りたいデータはとりあえず Firehose に流しておけば、実際の送信やバッファリングやリトライは Firehose が面倒を見てくれると
複数の Terraform state を結合する tfstate-merge を書いて20個以上の state を大統一した - 酒日記 はてな支店
あるところに、ひとつの Web サービスの本番環境が 20 個以上の Terraform state で管理されているリポジトリがありました。 おもに AWS 上で動いている、大変年代物かつ巨大なモノリスのサービスです。最初は何もコード管理されていない状態から徐々に Terraform を導入したのですが、その際に「一度に全部管理はできないから、徐々に Terraform 化していこう」という方針で管理を始めたところ… 新機能を追加するのでそのリソースを別 state で管理 改修があるのでそれらのリソースを別 state で管理 を繰り返すうちに、中に数個程度しかリソースがない state がどんどん増殖し、いつの間にやら20個以上になってしまったという状態です。ちなみにリソース定義は合計で 500 程度ありました。 さすがにここまで分割されてしまうと相互参照はできないし、VPC / S
AWS Lambda のミニマルなデプロイツール lambroll を書いた - 酒日記 はてな支店
3行で シンプル/ミニマルな Lambda のデプロイツール lambroll を書いてるよ Lambda API 以外は極力触らないやつです 既存 function の移行も簡単です 開発の経緯 AWS Lambda を管理、デプロイするのに数年来 Apex を使っていましたが、最近更新がないと思っていたら案の定というか、残念ながら No longer maintained となってしまいました。 で、代替を探したのですが… Lambda管理、Apexがお亡くなりになってServerlessかSAMになるんだけど、本当は関数だけdeployできればよくて(IAMとか関連リソースはTerraformでやるんで)、それなら裏でCloudFormationが動くようなのじゃないシンプルなのがいいなあ。作れば作れるけどデプロイツールばっかり書くことになるな…— fujiwara (@fujiwa
graceful restart できない daemon の再起動時のダウンタイムを HAProxy でリトライして救う - 酒日記 はてな支店
とあるネットワーク(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
AWS X-Ray による ISUCON8 本選問題の解析 - 酒日記 はてな支店
ISUCON8 の本選問題は、競技者がコントロールできない外部 API 呼び出しを多数含んだ出題内容でした。 講評では、 サービスの特性を適切に分析した上で、まとめるところはまとめたり、遅延させるところは遅延させるなど ……とさらっと書かれていますが、実際そんなことを短時間で分析することは可能なのかよ！という話題が競技後の懇親会でもあったので、それ AWS X-Ray でできるよ、というエントリをまとめておきたいと思います。 今回の解析は Perl 版の初期実装に対して行ったものですが、なぜ Perl かというと AWS の公式 SDK にない X-Ray 関連の CPAN モジュールを自分が書いているので、その宣伝も兼ねています。(blogエントリ書いてなかった) AWS::XRay Plack::Middleware::XRay Devel::KYTProf::Logger::XRay
ISUCON8 本選出題記 あるいはISUCONベンチマーカー負荷調整の歴史 - 酒日記 はてな支店
ISUCON 8 の本選出題を同僚の @ken39arg と担当しました。参加された皆様、運営にご協力して頂いたすべての関係者の方々にお礼申し上げます。 恒例の #isucon pic.twitter.com/iXAjgfgbeZ— fujiwara (@fujiwara) 2018年10月20日 問題についての講評は公式の ISUCON8 本選問題の解説と講評 をご覧頂くとして、こちらでは今回、出題に導入された新要素である「シェア機能」について、どういう経緯で導入されたのか、裏話的なことを書いておきたいと思います。 「ベンチマークの負荷を自分で決めるのも、自動で際限なく負荷が上昇するのも実際のアプリケーションとは違うよね?」というところから思いついた機構なのですが、経緯についてはいろいろな前提と、歴史の理解が必要になります。結果的に長文になってしまいました。 ISUCONベンチマーカーと
sardine で mackerel-plugin の出力をサービスメトリックとして投稿する - 酒日記 はてな支店
全国三千万 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 で収集した値を
fluent-logger-golang の実戦的な使いかたまとめ - 酒日記 はてな支店
OSS紹介アドベントカレンダー の14日目の記事です。 Fluentd の 公式 Go 版 Logger である fluent-logger-golang はこのように使うのがよさそう、という使い方をまとめてみました。 元々社内で書いておいたドキュメントを編集したものです。 github.com 前提のユースケース Webアプリケーション(APIサーバ) を Go で書いていて、そこから何らかのログを Fluentd に送信したい。 config のお勧めオプション Timeout : Connect に対するタイムアウト。デフォルト3秒なのでそのままでよさそう WriteTimeout : 書き込みのタイムアウト。デフォルトだとずっと待ってしまうので 3 秒とか? BufferLimit : デフォルト 8MB これを超えると捨てられてしまう。送る流量によって調整が必要 MaxRetry
Redisでログの書き込みがblockを引き起こす - 酒日記 はてな支店
「RedisかわいいよRedis」(by typester)……というほど自分は Redis 期でもないのですが、最近 Redis を使ったサービスの面倒を見ていて時々レスポンスが悪化する現象に出会ったので調べました。 前提 使用しているのは Redis 2.4.16 です。 redis.conf に "save [t] [n]" を定義すると、最後に save をしてから [t]秒間に [n]個以上の key が更新された場合に background で save (=bgsave) が実行されます。 save 60 10000これだと、60秒間に 10,000 keys です。 bgsave では redisは自分自身のプロセスを fork() し、子プロセス側は自分のメモリに乗っている内容をファイルにすべて書き出します。 この仕組みによって、1プロセス 1スレッドで動作している re
ISUCON 7 予選2日目を3位で通過しました - 酒日記 はてな支店
まずは出題と運営チームの皆様にお礼を。予選から1チーム3台、合計1200台のサーバを用意するという空前の規模で、快適な競技環境を用意していただいてありがとうございました。 isucon.net 今回は ISUCON 4 の時の fujiwara組 (@fujiwara, @acidlemon, @handlename) を再結成して、自称社内最強チームで望むことに。1日目には同じくカヤックから参戦のチーム MSA が1位を取っていて、これは予選通過はもちろん、スコアでもできれば負けたくないという戦いでした。 最終的には 48万点越え、両日通してのスコアでも3位ということで、まずまずの結果が残せたと思います。 やったこと あらかじめ用意しておいた Chef recipe で各種ツールや各人のアカウント作成、公開鍵設定 さくらのクラウドで用意されている Ubuntu から使われるとすれば今回は
ISUCON6で準優勝でした - 酒日記 はてな支店
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 で起動している やー、盛りだくさんでしたね… スコア推移とやった
nginx実践入門 - 酒日記 はてな支店
「nginx実践入門」 を著者の @cubicdaiya さんからいただきました。ありがとうございます。 簡単ですが感想など。 nginx実践入門 (WEB+DB PRESS plus) 作者: 久保達彦,道井俊介出版社/メーカー: 技術評論社発売日: 2016/01/16メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 感想 一通り読んだ感想としては、本書は「『実践』入門」であっていわゆる入門書ではないのですね。 手取り足取りしてくれるわけではなく、リファレンスの詳解でもなく、あくまで実践的に運用する人へ向けての、実用的な使い方の入り口を紹介してくれる本でした。 特に最近重要性の高い TLS(SSL) での安全でハイパフォーマンスな設定、大規模コンテンツ配信サーバの構築を例とした多段 proxy 構成、実用的なログ出力と Fluentd によるメトリクスモニタリン
ISUCON5予選を全体1位で通過しました - 酒日記 はてな支店
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系ディストリビューションで
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
Amazon SQSを利用してS3からRedshiftにデータ投入するRinというツールを書いた - 酒日記 はてな支店
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
Goで並列実行のベンチマークを取るためのライブラリ parallel-benchmark を書いた - 酒日記 はてな支店
以前 Perl で、forkして並列実行するベンチマークを取るためのライブラリ、Parallel::Benchmark というのを書きました。 Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店 これを使うと、単に Perl コードのベンチマークだけではなく、並列に外部にアクセスして計測を行うような (たとえばApacheBenchのような) ベンチマークツールが簡単に作れるので重宝しています。(仕事では、ソーシャルゲームのサーバアプリケーションに対する負荷テストを行うために使ったりもしています) で、思い立って Go 版を書きました。 kayac/parallel-benchmark · GitHub 使用例 フィボナッチ数を求めるコードを並列実行するベンチマーク fib(30) を1回計算するごとにスコア1とする 10個の goroutine
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
