epoll を使った prefork 型アプリケーションサーバーにおける Thundering herd 対策の決定版として注目されていた EPOLLEXCLUSIVE が、 3/13 にリリースされた Linux 4.5 で導入されました。 昨年 SO_REUSEPORT というソケットオプションが登場して、 Thundering herd 対策として話題になったものの、ワーカーごとに listen キューが作られるため graceful restart するときに listen キューに入ってるリクエストを取りこぼす可能性があり利用するのが難しい状況でした。 参考: epoll の thundering herd 問題について解説しているサイト http://tech.geniee.co.jp/entry/so_reuseport http://uwsgi-docs.readthedo

レイヤを問わず (ethernet から HTTP や SMTP まで) 、ネットワーク絡みのトラブルシューティングや挙動の確認をするときにパケットの流れが見られると非常に有益です。 開眼すると「パケットの流れが目で見える」そうですが、私などはまだまだ修行が足りず裸眼では見えないので、tcpdump というツールを使って見ています。 tcpdump はその名前があまりよくないと私は思っていて、"tcp" だけでなく udp やICMP や ethernet フレームまで覗ける超強力ツールです。 というわけで tcpdump の簡単な説明を書いてみます。 tcpdumpについて tcpdump は UNIX 系の OS で使えるツールなのですが、Windows 用にはWinDumpという CUI のツールがあり、tcpdump と同じように使えます。 GUI がお好みの方は、後でも紹介するE

先日この記事において hook の呼び出しに関してコメントを頂きました． 実際のところよく分かってない部分もあったので，hook に関してまとめてみました． このページの記述について このページの内容に関して 英語の文章は，全て Apache 2.0.58 のソースコード中から集めてきた原文ママです． 全ての hook に関して調べ尽くした訳じゃないので間違いもあると思います．間違いに気づかれた方はコメントで指摘いただければ幸いです m(_ _)m hook の呼び出し順序に関して hook が呼び出される順序は，「設定初期化」「プロセス初期化」「コネクション」「リクエスト」に関しては記述した順序で呼び出されるようです． RUN_ALL，RUN_FIRST について RUN_FIRST の hook は，呼び出した hook 処理関数が OK や DECLINE エラーを返した場合，その次

native_password authentication_string カラムの内容は、 native_password が salt なしの純粋な SHA1(SHA1(password)) の先頭に、 MySQL 4.1 以前の形式と区別するための目印として "*" をつけたものです。 mysql> create user t3 identified with 'mysql_native_password' by 'password'; Query OK, 0 rows affected (0.20 sec) mysql> select Host,User,plugin,authentication_string from mysql.user WHERE User='t3'; +------+------+-----------------------+--------------

昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10

Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab

@methane です。 ISUCON 7 本戦で最大のスコアアップできたポイントが、 status と呼ばれる重い計算の結果となるJSONのキャッシュでした。 近年のISUCONによくある、「更新が成功したら以降のレスポンスにはその更新が反映される必要がある」（以降は「即時反映」と呼びます）タイプの問題だったのですが、今回のように更新頻度の高くかつ即時反映が求められるデータをキャッシュする方法について、より一般的に解説しておきたいと思います。 即時反映が不要な場合 まずは基本として、即時反映が不要な場合のキャッシュ方法からおさらいします。この場合、一番良く使われるのは参照時に計算した結果を Memcached などにキャッシュし、時間で expire する方法です。 このタイプのキャッシュには、参照元が分散している場合（Webサーバーが複数台あるなど）に Thundering Herd

#isucon2 参戦記を私と @pandax381 とで交互に書くことになりました。 今日は私の視線で前半戦についてまとめます。 課題、襲来 isucon2 の課題が発表されました。今回の課題はチケット販売サイトらしいです。 スコア算出方法が (完売までの時間[ms] - 0.001*GET数 - 0.01*完売後の処理数) と発表されましたが、 課題とスコア算出方法だけでは今回のキーポイントがどこになるのかが判りません。 事前の打ち合わせ通り、 @pandax381 には負荷試験を実行してHTTP/TCPレベルでの観察をお願いし、 私はアプリケーションを実際に使ってみながらソースコードやDBのスキーマと見比べて、 アプリケーションの仕様を把握しました。 この時点で、 "/ticket/<ticketid>" というパスのHTMLが500KB程度あるのを見つけました。 1Gbpsのイーサ

攻略記事一覧: pixiv private isucon 2016 攻略 (1/5) pixiv private isucon 2016 攻略 (2/5) pixiv private isucon 2016 攻略 (3/5) pixiv private isucon 2016 攻略 (4/5) pixiv private isucon 2016 攻略 (5/5) 現状確認 access.log をもう一度見直しましょう。 Request by total time 74.113 0.0307140489018 GET / 70.007 0.00532696697611 GET /image/* 43.428 0.0575205298013 GET /@user 24.058 0.283035294118 GET /posts?max_created_at= 23.976 0.0522352

こんにちは。インフラ担当の岡村です。 「LVSの高負荷対策 その1 ~障害発生~」の記事で、大量のSYNパケットを受信した際にロードバランサの再起動が発生したことと、その緊急の対策についてご紹介しました。 今回は、再現確認を行い判明した再起動の原因と、LVSに備わっている高負荷対策の機能についてご紹介します。 検証 前回ご紹介した通り、障害発生時のログからメモリ周りが怪しそうでした。 そこで、ロードバランサにSYNパケットを送り、メモリの使用量の推移を観察しながら、再起動が発生するかどうかを確認しました。 検証環境の構成は次のようになります。 検証環境の構成 パケット送信用サーバを複数台、ロードバランサを1台、Webサーバを1台使用し検証を行いました。 ロードバランサの検証を行う上で、本番環境と同様にロードバランスの処理をさせたかったため、LVSに振り分け先のWebサーバのIPアドレスを複

keepalivedはLinuxで冗長構成を組む道具としてとても便利ですが、運用面に関する配慮に物足りなさを感じることがあります。例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑） naoyaの日記でnaoyaさんも悩んでいるようですが、設定ファイルをうまく保守する仕組みをどう作るかが導入する際の大きな鍵になると思います。今回は、DSASではどのようにして2台のkeepalivedを運用しているかを少しだけご紹介させて頂きたいと思います。 1) マスターで設定ファイルを編集する 2) バックアップに設定ファイルを転送する 3) バックアップで設定を反映する 4) マスターとバックアップの差分を確認する 5) マスターで設定を反映する 具体的にはどのようにしているかというと、、、 lv1:# vi 設定ファイル lv1:# lvs-sync -ine lv1

KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp

こんにちは。インフラ担当の岡村です。 昨年、あるサービスで使用中のロードバランサが停止してしまうという事件が起こりました。 事の顛末を、数回に分けて紹介していきたいと思います。 もし同様の事象にお困りの場合は、役立てて頂ければと思います。 システム構成 KLabのDSASでは、ロードバランサにLVS (Linux Virtual Server) を使用しています。 ロードバランサはマスタ-バックアップ構成になっており、マスタ側が停止してしまっても、通常はバックアップ側がマスタに昇格し、サービスを継続できるようになっています。 おおまかな構成は下図のようになります。 ある日の晩、突然ロードバランサ(マスタ側)の死活監視のアラート通知が届きます。 （なんだろう..。電源障害？　その他HW障害？　もしくはカーネルのバグを踏んだ？） 原因調査・復旧はもちろん必要ですが、冗長構成のため、とりあえずサ

前回は、openssl コマンドの -CAfile オプションでCA証明書を指定してみました。 しかし、この方法だと検証したいサーバ証明書がどの認証機関で署名されているのかをあらかじめ知っておかないといけません。「うちはぜ〜んぶべり☆☆☆だもん」みたいな運用ならばさほど困らないかもしれませんが、サービスによって利用している認証機関が異なっていたり、独自に組織別CAを構築して運用しているような場合は少々面倒です。やはりCA証明書は勝手に選択して欲しいものです。 特に弊社のDSASでは、様々なコンテンツが同じシステムに同居しているため、どのサイトがどの認証機関を使っているかを全て把握することは至難の業だったりします。 -CApath というオプションがあります。 使い方は -CAfile と同様で $ openssl s_client -connect localhost:4433 -CApa

@methane です。 compact dict が Python 3.6 が9月（ベータになる直前）にマージされ、それのおかげで推薦をもらい 10月ごろから Python の Core Developer になりました。 「PythonのフルタイムコミッタとしてKLabに雇われている」という訳ではないのですが、 もともと自己裁量で業務時間の大半をOSSへの貢献やコードを読むことに費やし、特にこの3ヶ月位は Python ばかり触っていたので、実質的には近い状態です。 そちらでの活動をあまり日本で共有する機会がないので、 Money Forward の卜部さんが書かれている 最近の ruby-core という記事をリスペクトして、 最近の Python の開発状況を紹介する記事を書いてみたいと思います。 Python 3.6 リリース 12/23 に Python 3.6 がリリースされ

このエントリーは、KLab Advent Calendar 2016 の12/25 の記事です。 最終日の担当はCTOの安井です。 今年のアドベントカレンダーもテーマが多岐に渡っていてとても興味深いです。 ゲームに関係ありそうなものから関係なさそうなものまで盛りだくさんですね。 KLabでは業務と直接関係のない開発活動も積極的に推奨しています。 これには、自分が得意とする分野、興味のある技術に対して全力で取り組んで欲しいという願いがあります。好きなことに全力で取り組んで結果を残すことができるエンジニアは、様々な場面において高いアウトプットを出してくれることが多いものです。 社内ではよく「市場価値の高いエンジニアを目指そう」という言い方をしています。 エンジニアが安心して仕事を続けるためには「自分の実力に自信を持てること」がとても重要なことだと考えています。いくら上司から高い評価を得ていても

この記事は KLab Advent Calendar 2016 の 15 日目の記事です。 こんにちは。大野です。 KLab では最近、ローカルの DNS キャッシュサーバとして Unbound を使うようになりました。 今までは dnscache を利用していたのですが、キャッシュ削除のためにプロセスを再起動しなければならなかったり、特定のレコードのみを削除することができないといった課題や一部の問合せをキャッシュサーバ内部で解決したいといった要求があり Unbound を導入するに至りました。 Unbound を運用していく中でつまずいた点もありましたので、今回この記事で紹介します。 とある案件で AWS を利用した構成の運用を任されていたのですが、アプリケーションのエラーログには以下のような記録が残っており、何らかの理由で RDS で運用している DB サーバの名前解決に失敗し接続でき

こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、