はじめに サーバソフトウェアの設定ファイル等でよく見かける項目であるBacklogってどういう意味なんだろうと、少し調べたのでメモを残します。 Backlog apacheやnginx、memchachedなどのサーバ系ソフトウェアの設定ファイルの中で設定することが多い、このBacklogとは何なのかをここでは言及する。 サーバアプリケーションがlistenしているソケットがacceptしていない、確立済TCPセッションを何個までOS側で保持するかを定義したもの。 例えば、下記のようなサーバーアプリケーションがあるとする。 server.py import evenlet server_sock = eventlet.listen(('0.0.0.0', 6001),backlog = 1) new_sock, address = server_sock.accept() new_sock
PHP-FPMには、Apacheやnginx同様、プロセス数などが見られるステータスページが用意されている。 以下のようにすると見られる。 PHP-FPM側の設定 以下のようにコメントアウトする /etc/php-fpm.d/www.conf pm.status_path = /phpfpm_status nginx側の設定 以下のように、うえで書いたlocationを渡せばOK /etc/nginx/conf.d/default.conf server { listen 80 default_server; server_name _; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } } 確認する curl http://localhost/phpfpm_statu
概要 MongoDBでCPU使用率やロードアベレージが高くないのに処理が詰まっている現象が起きました。 その時間にbatchが動いていてアクセスが急に増えることが原因と言うのは分かっているのですが、負荷的には十分余裕があり不思議な状態でした。 そこでdstatで見るポイント - Carpe Diemでも述べたように、負荷の状態から判断する基準があります。 ロードアベレージを確認する １が高ければCPU、ディスクI/O、メモリにボトルネックがある １が低ければTCPコネクションにボトルネックがある 今回の現象から判断するに、TCPコネクションに原因がありそうです。 原因調査 Too many open filesは出ているか ファイルディスクリプタが足りない場合はコネクション数が足りずに処理が詰まってしまいます。 そしてその場合Too many open filesというエラーが出ます。 し
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。（TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です） また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
Site Reliability Engineering（SRE） Teamの@cubicdaiyaです。 今回は数あるnginxのサードパーティモジュールの中でも一際強力で、メルカリでも活用しているngx_luaの便利な活用方法や最適化集について紹介します。 ngx_luaは軽量スクリプト言語のLuaでnginxを拡張できるモジュールです。 nginxの設定ファイル内にLuaのコードを埋め込んだり、nginxの拡張モジュールをCではなくLuaで開発することができます。以下はngx_luaにおける「Hello, World!」です。 location / { content_by_lua 'ngx.say("Hello, World!")'; } 上記のロケーションにHTTPでアクセスするとnginxはボディが「Hello, World!」のレスポンスを返します。 なお、先月末にリリースさ
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
Nginx Inc.は、HTTP/2に対応した「NGINX Open Source 1.9.5」のリリースを発表しました。商用版のNginx Plusに続いてのHTTP/2サポートになります。 Nginxはオープンソースで開発されている軽量なWebサーバ。今回のHTTP/2サポートはこれまでサポートしていたSPDYに代わるもの。 先週、9月22日から3日間、サンフランシスコでNginxの年次イベントである「nginx.conf 2015」が開催されており、今回のHTTP/2対応はそれに合わせた形です。 また、このnginx.confでは、NginxにJavaScript仮想マシンを組み込み、Nginx内で動作する「nginScript」が発表されました。nginScriptはまだプレビューレベルで、将来のNginxで利用可能になる見通しです。 nginScriptを発表したブログ「Laun
原稿の締め切りを越えた先にあるもの、それは校正です。「俺達の戦いはこれからだ！」的な展開に胸が熱く・・・いえ、ちょっと胃のあたりがチクチクする@cubicdaiyaです。 今回はメルカリのプッシュ通知システムとその変遷について紹介します。 メルカリとプッシュ通知 メルカリではアプリ内でのさまざまなイベントの発生時に対象ユーザに対してプッシュ通知を行うようになっています。アプリ内で発生するイベントというのは例えば、 商品の購入 購入した商品の発送 商品に対するいいね！、コメント といったものです。通常アプリ内でイベントが発生した際はAPIサーバにHTTPSリクエストを発行し、MySQLデータベースへの参照・更新が行われた後ユーザにレスポンスを返します。そして必要であればプッシュ通知を行います。 メルカリのプッシュ通知システムの課題と変遷 メルカリのプッシュ通知システムはこの1年間で2度刷新さ
NginxでHTTPS：ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス 今日のインターネットの世界では、一般的な静的Webサイトも含め、 全てのWebサイト に、強固で安全なHTTPSのセットアップが必要となります。この記事は、Nginxセキュリティをどのようにセットアップするのかに関するシリーズのパート2です。 パート1 は、Webサーバに有効な署名証明書をセットアップする話で終了しました。しかしこれには、最適な設定とは言い難い、デフォルトのNginxの設定を使用していました。 この記事を読み終えれば、SSL Labsのレポートで、A+の評価を獲得できる安全なHTTPSの設定ができます。それだけでなく、追加でいくつかの微調整も行い、パフォーマンスそしてUXも向上させていきます。 ここに掲載した記述やコードの抜粋の他にも、すぐに使
nginx で SSL 設定をするのは、スゴイ簡単です。 サーバ証明書と秘密鍵がすでにあるなら、/etc/nginx/nginx.conf に以下の設定を追加するだけでおっけ。 server { : listen 443 default ssl; ssl on; # サーバ証明書（サーバ証明書に中間CA証明書を連結したもの） ssl_certificate /usr/local/nginx/conf/cert.pem; # 秘密鍵 ssl_certificate_key /usr/local/nginx/conf/cert.key; : } via. HttpSslModule サーバ証明書を持ってなくて、とりあえずオレオレ証明書を作成したい場合は以下のようにして作りましょう。 $ cd /usr/local/nginx/conf $ openssl genrsa -des3 -out s
1. 第10回 静岡ITPro勉強会 インフラ部 nginx⼊入⾨門 滝澤 隆史 株式会社ハートビーツ MSP事業部 所属 http://heartbeats.jp/ 1 2013-‐‑‒05-‐‑‒18nginx⼊入⾨門 2. 私は誰 • ⽒氏名: 滝澤 隆史 @ttkzw • 所属: 株式会社ハートビーツ ▫ サーバの構築・運⽤用や 24時間365⽇日の有⼈人監視をやっている会社 ▫ いわゆるMSP（マネージド サービス プロバイ ダ） • nginxとの関わり ▫ 所属会社の技術ブログ「nginx連載」 – http://heartbeats.jp/hbblog/nginx/ ▫ Software Design 2012年年12⽉月号 第2特集「⾼高速・⾼高機能HTTPサーバ Nginx構築・ 設定マニュアル」 2 2013-‐‑‒05-‐
プロダクトでWebサーバ上の現在時刻出したい要件がありました。 これぐらいの処理ならアプリケーション介さずともnginxだけでやりたいですね。 現在時刻ヘッダーにつけるならnginx標準機能で出来そうなんですが、 深淵なる理由からコンテンツとして欲しいとのこと。 今後、Nginx+Lua試してみたいなーという要件もありましたし、 せっかくなのでこの機能をLuaスクリプトで書いてみることにしました。 NginxでLuaを動かす環境 まず環境整えるのが若干大変でした。*1 以下のような手順でインストールするようです。 LuaJITインストール ngx_devel_kitインストール lua-nginx-moduleインストール ライブラリのパスなど気をつけないとハマるかもしれませんね。 nginxレシピ opscodeのnginxクックブックにはluaをインストールするレシピもありました。 し
Nginx 1.4.2で試しました。 ネームサーバーは、ローカルのunboundをlocal-zone, local-dataを使って簡易コンテンツサーバーにして試しました。 local-zone: "oreno." static local-data: "api.oreno. 30 IN A 192.0.2.11" # local-data: "api.oreno. 30 IN A 192.0.2.12" proxy_passにホスト名を書くと→名前解決は一度だけ このように Nginx の設定を書いた場合、 location /api { proxy_pass http://api.oreno:9999; } 「api.oreno」の名前解決は、nginxの起動時に行われます 名前解決できない場合は、nginxは起動しません 名前解決できた場合は、ずっとそのIPアドレスにreverse
このブログのバックエンドApacheからNginxに乗り換えたので、それまでの流れをメモとして公開します。Nginxをわざわざ使う上でやっておいたほうがいい基本的な設定とリバースプロクシキャッシュの動く設定からベンチマークツールの賛否両論まで。 次世代WebサーバーのNginxという未来へ! 「Nginxがすごい!!!」みたいな話を聞いて、はや4年。なんだかよくわからず、Apacheを使い続けていましたが、やっとNginxのすごさがわかったので、乗り換えました。そのあたりのより入門的な内容やApacheでよくやる設定をNginxでどうやろうかもつらつら調べているので、そのあたりは別記事としてたぶん公開するとして、まず手っ取り早く導入しないとそのあたりをやる気力もなくなるので、個別のカスタマイズはさておき、導入内容ついて記事にしておきます。とりあえず、Nginxの公式サイトでも見てみるといい
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
この記事の内容は不正確なので、別の記事をご覧ください リクエストURIが複数のlocation設定にマッチしても適用されるものは１つだけです。適用の優先順位は 完全一致（=） 前方一致（^~あり、複数マッチした時は一番パスが長いもの） 正規表現（~または*~ 複数マッチする場合は一番上のもの） 前方一致（^~なし、複数マッチした時は一番パスが長いもの） =や^~でマッチした場合はその時点でマッチング処理を終了するそうです。 わずかでも軽くしたいなら正規表現を避けるといいのかもしれません。たとえば画像ファイルを全て /img 以下に設置しているのであれば location ~* .(gif|jpg|png)$ { access_log off; }よりも前方一致マッチングを使って location ^~ /img/ { access_log off; }とした方が、わずかながら速くなるかもし
アプリケーションでどうしても捌けない量のリクエストが一時的に押し寄せてしまう場合、アプリケーションサーバが死ぬのを避けるために GET は制限を掛けたいが、POST はリトライが面倒なのでなるべく通してあげたい、というような要求を nginx で処理できるかどうか。 実装として一番望ましいのは GET は 100 req/sec で制限 (超えたら503) POST は無制限 のようにメソッドごとに別々の制限を掛けることだったのですが、とりあえず HttpLimitReqModule を使うことで、メソッドごとに同一の上限を設定することはできました。 http { limit_req_zone $request_method zone=method:1m rate=100r/s; server { listen 80; location / { limit_req zone=method;
nodejsでやってやろうと思ったけど、JSがわからなかったし自動起動とかその辺が面倒なのでnginxでやってみた。(jsとかよくわからないおいらに取ってはnginxの方が何倍も簡単にできた) あと、この記事は基本的に設定に関して中心にやっていくんだけどこまい所でArchLinuxの癖が出てる可能性があるので注意。 今日やること Nginxを使ってApatchのhttpとhttpsへのリバースプロキシを作る。 Apatchの設定 ポートは当然nginxが80番と443番だったかを取るので、それ以外に設定する。Apatchのポート番号変更は"Listen"を書き換えるとよい。 ArchLinusの場合は/etc/httpd/conf/httpd.confの上のようにあるListenを書き換える Listen 8000 とする。(http) また、httpsに関しては/etc/httpd/co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く