リバースプロキシ／ロードバランサ配下のApache HTTP Server（以降、単にhttpdと記す）ではmod_rpafというモジュールを使用すると、アクセス元のIPアドレスを正しく取得して、そのIPアドレスでログに出力したり、アクセス制御を行ったりすることができるようになります。 今回の記事の前半ではこのmod_rpafについてインストール方法や設定方法について説明します。 後半ではmod_rpafを使ってもアクセス制御ができない問題が発生して、それを解決した経緯などを紹介します。具体的にはロードバランサとしてAmazon Elastic Load Balancingを、プロキシサーバとしてnginxを、バックエンドサーバとしてAmazon Linux 2011.09のhttpdを使ったときにアクセス元IPアドレスによるアクセス制御がうまくできない問題が発生しました。このあたりにご興
Apache httpd 2.4.1を試してみた
接続数とリクエスト/秒はserver-statusハンドラーで取得したものです。使用帯域については、2.2のserver-statusは正確な値を返さないので2.4.1とは比較できません。そこでネットワークインターフェイスの出力帯域の直近の5分平均を採りました。メモリーの使用量とCPUの使用率は、httpdのプロセスの合計の値をprstat -aで調べました。 出力帯域を見る限り、どちらのバージョンも同様な負荷状況にあります。出力帯域にはFTPやrsyncも含まれていますが、HTTPがほとんどだからです。しかし、接続数やリクエスト/秒は2.2.22より2.4.1のほうがずっと小さいです。まだソースコードを読んでいないので正確なことはわかりませんが、計測方法が異なっているためではないかと思います。問題のメモリーとCPUの使用状況ですが、2.2.22よりも2.4.1のほうが2倍以上大きくなって
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 久々のApache HTTP Server 2.4.1という安定版がリリースされたので、早速ベンチマーク評価を行う。今回はevent_mpmのExperimentがとれて、晴れてデフォルトMPMになったのでそれを使ってみたい。 日本一（ひょっとすると世界一）早いApache 2.4.1 event_mpmのレビューを意識してみた。 はじめに 個人的にも、event_mpmが採用されたことに最も注目している。event_mpmは非同期型のIO処理をしていて、nginxに近いアーキテクチャをとっている。厳密には、nginxの非同期と比べた場合、nginxは徹底的にノンブロッキング（accept4を使う等）してworkerスレッドで次々と並列処理し
ウェブアプリケーションにおいて、認証がかかっている画像や大きなファイルを配信する場合には、Perlbal 等でサポートされている X-Reproxy-URL ヘッダが有効なことが知られていて、その理由としては、 (メモリを大食いする) アプリケーションサーバのプロセスを転送終了まで占有しない HTTP ベースの分散ファイルシステムとリバースプロキシが直接交信するので、ネットワーク負荷が低い といった点が挙げられます。「でも、Apache は X-Reproxy-URL ヘッダをサポートしてないんだよねー」という話が、先日の YAPC::Asia 2009 においても話題になっていました[要出典]。回避策としては、ワンタイムURLのような手法もあるのですが、セキュリティな懸念もあります。 なんとかしたいなと思っていたのですが、気が向いたので、Apache に X-Reproxy-URL ヘッ
<section id="hero_custom" class="hero_custom"> <video aria-hidden="true" role="presentation" class="hero_custom__background hero_custom__background--video" webkit-playsinline="true" playsinline="true" loop="true" autoplay="true" muted="true"> <source src="/content/dam/system-files/acom/custom-code/change-more/media/custom-rad-hero-bg-video.mp4" type="video/mp4" /> </video> <a class="hero_custom__c
h5ai larsjung.de Apacheのディレクトリインデックスをありえない位かっこ良くできる「h5ai」 HTML5の機能を使って、通常の味気ないディレクトリインデックスをかなりかっこ良くしちゃうというものです。 ディレクトリ一覧。アイコンなんかもついてかなりリッチ mod_headersとmod_autoindexというApacheモジュールを応用して作られているようですが、こんなことが出来るとは知りませんでした。 表示方法もアイコンベースに変更することも可能です。これはイカしていますね。 サイドの丸みを帯びた物体にカーソルをあわせるとニュイーンと伸びてツリービューが表示。これまた便利です。 動作デモはこちら デザインは基本的にHTML+CSSなので、あなた好みにカスタマイズすることも可能。 Apacheの味気ないデザインページは嫌だ！というデザイナーさんは覚えておくとよさそう
YAPC::Asia Tokyo 2010 で LT してきました。以下はその資料(に少し説明を追加したもの)です。 mod_rewrite 正規表現によるURL書き換えモジュール スイス製アーミーナイフ / 黒魔術 まだ Apache 使ってますよね? reverse proxy とか… はてなの mod_rewrite 活用事例 ほぼ reverse proxy URLにより用途別のbackendに振り分ける 用途によりbackendを分けリソース効率化 特定のアクセスをキャッシュサーバーに振る URL加工 Squidにキャッシュさせたいが同一URLで異なるコンテンツを返す場合がある →クエリに情報を付加する BAN! 便利な半面… 増える! $ cat jp.www.proxy.apache.conf | grep Rewrite | wc -l 179 テストしづらい! → 一行加
先日は，必要に迫られて Apache 1.3 の mod_access を改造したという話を書きました．その時は単にあるものを改造しただけでしたが，ふと思い立って，一から Apache 2.0 用のモジュールを書いてみました．書く上で色々 Web サイトを探してみたのですが，あまり日本語の入門向けの文章が見あたらなかったので，開発する上で分かったこと(と言うほど大したものじゃないですが)をまとめておこうと思います． フェーズには，例えばそのリクエストを受け付けるか拒否するかを決めるフェーズや，リクエストされた URI と実際のディスク上のファイルとの間の対応付けを解決するフェーズ，そしてもちろん実際のレスポンスを生成するフェーズ等があります．hook 関数を挿入するポイントはこれらのフェーズになりますが，もちろんその全てのフェーズのための関数を用意する必要はありません．また個別の設定を施す
※ 2010/9/27 さらに実験してみた http://d.hatena.ne.jp/toritori0318/20100927/1285591445 そもそもは「Twitterのくじらを実装するのはどういうのがスタンダードなのか？」という疑問。 軽くググってみると以下のようなページがヒット。 mod_rewriteでサーバーの負荷が高いときだけリダイレクトする http://rebecca.ac/milano/mt/archives/001540.html http://d.hatena.ne.jp/inspfightman/20071212/1197433349 すると神の声が http://twitter.com/fujiwara/status/24544644921 ですよねー。 とりあえずこういうときは 憶測するな、計測せよ！ ということで実験。 環境 os CentOS 5.
Apacheの設定で Order deny,allowとか Satisfy anyとか、なんだか意味わからん人のために。僕はずっとわかってなかった。 基本 Apacheのアクセス制御には、 ホストによる制御 (Order,Allow,Deny) ユーザ認証による制御 (Auth*, Require) の2通りがある。 Satisfyは、2通りあるアクセス制御の両方を満たす必要があるかどうかを決定する。デフォルトはSatisfy all。Satisfy anyなら、どちらか片方満たせばよい。 Order http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order Order deny,allowは、全てのホストからのアクセスを許可する。 Order allow,denyは、全てのホストからのアクセスを拒否する。 Order d
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
mod_log_rotate のススメ で紹介されていた mod_log_rotate がよさげです。 http://www.hexten.net/wiki/index.php/Mod-log-rotate ドキュメントには書いてない(と思う)んですが、CustomLogのファイル名にstrftimeの書式指定が使えるようになります。 ついでに、rotatelogs より cronolog の方がフットプリントが小さそうなので、ErrorLogはcronologを使うようにしてみました。 before ErrorLog "|/usr/local/bin/rotatelogs /var/log/httpd/irori.org/www.err.%Y-%m-%d 86400 +540" CustomLog "|/usr/local/bin/rotatelogs /var/log/httpd/ir
としみじみ。 いや、携帯サイトを作っていて、PCサイトはそこそこの性能(Apache + MySQL)出しているんですけど、携帯になるとなぜか遅い。。 でも、開発環境だと携帯でもそこそこの性能。なんでだろーってなる訳です。開発環境はUniform Serverを使っていて、本環境は自前でApacheやら、MySQLやらせこせこと入れて行った訳です。で、そうなるとまずはhttpd.confのにらめっこなのですよ。 で、ふと、「このモジュールは何？」ってのにぶち当たったのですよ。それがmod_deflate。何々、コンテンツを圧縮してくれる？そんな便利な物は本環境に入っていませんでしたよ。ええ。 で、またapacheコンパイルし直しかい。って思っていたらば。 mod_deflateモジュールのインストール # cd /Apacheのソース/modules/filters/ # /usr/loc
ASF Bugzilla – Bug 46949 Apache httpd serves sometimes content from another thread Last modified: 2017-05-09 15:45:01 UTC
20070817 リバースプロキシ背後のWebDAVサーバでリネームできない Mac OSXにapacheをインストールし，WebDAVサーバをたてたのだが，ファイルやディレクトリのリネームができない．いろいろ検索して調べたところ， Subversion behind an Apache Reverse Proxy subversion: Mail reader あたりがヒット．リバースプロキシの背後にあるWebDAVサーバに対してSubversonからリネームできない問題への対処が書いてある．今回の件もこれと同じであった． リバースプロキシがhttpsで，WebDAVサーバがhttpの場合にこの問題が起きる．WebDAVのMOVEメソッドでは，ファイルの移動先はリクエストヘッダDestinationに書かれる．これが，例えばhttps://dav.example.com/destinat
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
今更な話題で恐縮ですがmiyagawaさんがものすごい勢いで教えてくれたのでメモっておきます。 mod_proxyでバックエンドにリクエストを投げたとき、リクエストのうち何個かが極端に遅いという現象が起こりました。その時のabの結果は以下。 % ab -c 5 -n 500 http://127.0.0.1:21082/ Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 4 95% 1008 98% 1994 99% 2003 100% 2020 (longest request)なお、今回使おうとしたバックエンドはStarmanです。 多分こんな原因 検証不足で断言はできないのですが、多分以下のような感じ。多分。 Apache のデフォルトのServerLimi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
