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ベンチマーカーと
ISUCON 7 予選2日目を3位で通過しました - 酒日記 はてな支店
まずは出題と運営チームの皆様にお礼を。予選から1チーム3台、合計1200台のサーバを用意するという空前の規模で、快適な競技環境を用意していただいてありがとうございました。 isucon.net 今回は ISUCON 4 の時の fujiwara組 (@fujiwara, @acidlemon, @handlename) を再結成して、自称社内最強チームで望むことに。1日目には同じくカヤックから参戦のチーム MSA が1位を取っていて、これは予選通過はもちろん、スコアでもできれば負けたくないという戦いでした。 最終的には 48万点越え、両日通してのスコアでも3位ということで、まずまずの結果が残せたと思います。 やったこと あらかじめ用意しておいた Chef recipe で各種ツールや各人のアカウント作成、公開鍵設定 さくらのクラウドで用意されている Ubuntu から使われるとすれば今回は
Consulクラスタ内でファイルを分散配布する tuggle を書いた - 酒日記 はてな支店
github.com これはなに? HTTPを使って、ファイルを Consul クラスタ内で分散配布する daemon です。Go で書かれています。読みかたは「たぐる」です。 開発動機とユースケース 拙作の Stretcher というデプロイツールがあります。嬉しいことに、自分が勤務しているカヤックだけではなく、他社さんでも使われているようです。 先日、某社の Stretcher をお使いのかたに話を伺う機会があり、デプロイアーカイブの取得時のネットワーク負荷が問題になっているということを聞きました。 カヤックではサーバは基本 AWS にあり、S3 からデプロイアーカイブ(200〜300MB程度)を取得しています。S3はちょっと意味が分からないぐらい堅牢で、stretcherの -random-delay 5 (開始を平均2.5秒、最大5秒ずらす) を設定した状態で100台程度から一斉に
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 で起動している やー、盛りだくさんでしたね… スコア推移とやった
Fluent::Logger(Perl)をFluentd 0.14のSub-second timeに対応した - 酒日記 はてな支店
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
nginx実践入門 - 酒日記 はてな支店
「nginx実践入門」 を著者の @cubicdaiya さんからいただきました。ありがとうございます。 簡単ですが感想など。 nginx実践入門 (WEB+DB PRESS plus) 作者: 久保達彦,道井俊介出版社/メーカー: 技術評論社発売日: 2016/01/16メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 感想 一通り読んだ感想としては、本書は「『実践』入門」であっていわゆる入門書ではないのですね。 手取り足取りしてくれるわけではなく、リファレンスの詳解でもなく、あくまで実践的に運用する人へ向けての、実用的な使い方の入り口を紹介してくれる本でした。 特に最近重要性の高い TLS(SSL) での安全でハイパフォーマンスな設定、大規模コンテンツ配信サーバの構築を例とした多段 proxy 構成、実用的なログ出力と Fluentd によるメトリクスモニタリン
Norikraのクエリをテキストファイルで管理する - 酒日記 はてな支店
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"
ISUCON5 で優勝しました - 酒日記 はてな支店
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は開いていて、会場からは接
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系ディストリビューションで
YAPC::Asia 2015で発表してきました & ConsulとStretcherについて - 酒日記 はてな支店
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と周辺に関
nginxでX-Accel-Redirectを使う場合に余計なヘッダを削除する - 酒日記 はてな支店
アプリケーションで認証後 S3 のコンテンツを返したかったのだけど、nginx で BASIC 認証を掛けていたらうまくいかなかった、というお話。 Amazon S3 の認証トークン付き URL をアプリケーションで生成し X-Accel-Redirect ヘッダに出力 nginx が S3 から取得してきてクライアントに返す という動作をさせたくて、以下のように設定。 # nginx.conf location = /reproxy { internal; set $reproxy $upstream_http_x_reproxy_url; proxy_pass $reproxy; proxy_hide_header Content-Type; }アプリケーションからは以下のようなレスポンスヘッダを出力。 X-Accel-Redirect: /reproxy X-Reproxy-URL:
Norikraでwebサービスを守る話をしてきた - 酒日記 はてな支店
Norikra meetup #2でLTをしてきました。LTといいつつ時間に余裕があったので15分以上しゃべっていたような… atnd.org 発表資料はこちらです。 speakerdeck.com Norikraで不正アクセスの兆候があるアクセスログを検知して、検知次第IPアドレスをmemcachedに突っ込んでそれをもとにアクセスをブロックする、というネタでした。 ログの流し込みが詰まった場合に誤爆しないように、結果のtimestampに1分以上の間隔があった場合は max(time) - min(time) で補正するとか、クエリに後処理で使うための定数を埋め込んでおくことでクエリごとに挙動を調整しやすくするとか、そんなかんじの細かい工夫をしています。 あと皆さん気になっていたNorikraの冗長化ですが、active-standby構成であればすぐできる気はします。 うちはいまst
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
ISUCON4本選で3位に敗れました #isucon - 酒日記 はてな支店
ISUCON4 に「fujiwara組」として参戦しましたが、既報のとおり 3位に敗れてきました。順位こそ3位で賞金10万円は獲得できたものの、スコアが示すとおり内容的には完敗です。 まずは主催のLINE社様、出題を担当していただいたCookpad社様、本番サーバ提供をしていただいたテコラス社様にお礼申し上げます。本当に楽しいイベントをありがとうございました。 うちのチームとしてやったことは #isucon 4の本戦で3位を取ってきました (追記あり) - beatsync.net に大変詳しいので、そちらをご参照ください。 簡単に最終的な構成をまとめると Redisは1号機に(動画以外)集約 動画はアップロードを受けたサーバがローカルファイルとして保存しnginxが返す。保存されたサーバのアドレスをメタデータとしてRedisに保存し、APIへのレスポンスに含まれるURLを構築するのに使用
#isucon 4に参加して予選2日目暫定1位になりました - 酒日記 はてな支店
ISUCON1, 2と「fujiwara組」で連覇し、2013年には出題を担当しましたが、今年は一参戦者として挑戦することになりました。 今年は弊社からの本選枠もなく(共催ではないので)、予選落ちしたらそれまで チームは ISUCON 1,2のメンバーが自分以外全員退職(…) してしまったため、去年の出題担当 @acidlemn @handlename で新規編成 というなかなかプレッシャーのかかる状況でしたが、さしあたり予選2日目の暫定1位スコアを出すことができました。(後述しますが、一部レギュレーションに引っかかる可能性のある修正をしているため、失格となる可能性はあります。その判断が下された場合は、当然受け入れます) 速報結果はこちらです ISUCON4 オンライン予選 二日目の結果発表 : ISUCON公式Blog 例年のことながら、大変楽しいイベントでした。運営・出題をしていただい
MHAをAWSで使うための支援ツールMHA::AWSをアップデートしてCPANに上げた - 酒日記 はてな支店
以前に作って、プロダクションでもいくつかのサービスに導入している MHA::AWS ですが、failover 方法を ENI 付け替えの他に VPC Route Table の書き換えもサポートしました。 ENI付け替えでは同一 Availability Zone 内での failover しかできませんが、VPC Route Table の書き換えによる方法では Multi-AZ 環境での failover も可能になります。 CPANにも上げましたので、 cpanm MHA::AWS でインストール可能です。 MHA::AWS - A support script for "MySQL Master HA" running on AWS - metacpan.org fujiwara/MHA-AWS · GitHub 以前の紹介記事 → #11 MySQL Master HA を AW
Starlet 0.24で子プロセスごとに乱数系列が初期化されるようになった - 酒日記 はてな支店
Perl 5で fork する場合に乱数系列が親と同じになってしまう現象については過去にもいろいろエントリがあります。 乱数と Perl5 にかんする蘊蓄の話 - blog.64p.org #22 カジュアルに乱数を使う方法とその注意点 | tech.kayac.com - KAYAC engineers' blog 0.23以前の Starlet では、親で一度でもどこかで rand (またはsrand) が呼ばれていると、初期化された乱数系列が fork された子プロセスにも引き継がれるため、その後に実際のユーザアプリケーションが走る子プロセス内で rand() しても同じ系列が返ってきてしまう、という現象があったのですが、0.24 では子プロセス生成後に srand() が呼ばれるようになりました。 # 正確にいうと、0.14 で --min-reqs-per-child がサポート
HAProxy で MySQL のヘルスチェックをちょっと便利にする - 酒日記 はてな支店
MySQL で slave を複数台立てて参照分散するには、HAProxy を利用してロードバランスと切り離しを行うと手軽に使えて便利です。 option mysql-check という設定で、HAProxy 自身が mysqld に接続してヘルスチェックが可能です。 listen mysql-slave bind 127.0.0.1:3307 mode tcp option mysql-check user haproxy balance roundrobin server slave1 192.168.1.11 check server slave2 192.168.1.12 check server slave3 192.168.1.13 checkなのですが、この設定だと以下のように少々不便なことがあります。 mysqldに接続できるかどうかのみを死活の判断にしているので、レプリケ
複数の zabbix-agent から取得した値を集約する zabbix-aggregate-agent を書いた - 酒日記 はてな支店
Immutableなインフラがなんやかんやと喧しい今日この頃ですが、インスタンスが頻繁に増えたり減ったりすると、監視サービスで継続的な値を追うのが難しくなるよね、という問題を最近感じています。 サービス全体で複数のホストの合計値を取得しておくことで使用量の推移を見たいような値、具体的には以下のようなものです。 外向けのネットワークトラフィック クライアントと永続接続する daemon の持っているコネクション数 ジョブの処理数 複数のMySQL slaveが処理した参照クエリ数 ということで、zabbix-agent への proxy として動作する、複数 agent からの数値を合計して返すようなものがあったら捗るんじゃないかと書いてみました。 公式ページ fujiwara.github.io/zabbix-aggregate-agent リポジトリ zabbix-aggregate-a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
