実際には2階層下にファイルがある：

$ ls -R nas_mnt_point
a b c

nas_mnt_point/a
a.txt

nas_mnt_point/b
b.txt

nas_mnt_point/
c.txt

でもfindでは：

$ find nas_mnt_point
nas_mnt_point/a
nas_mnt_point/b
nas_mnt_point/c

で、symlinkと同じように-followオプションを付けると：

$ find nas_mnt_point -follow
nas_mnt_point/a
nas_mnt_point/a/a.txt
nas_mnt_point/b
nas_mnt_point/b/b.txt
nas_mnt_point/c
nas_mnt_point/c/c.txt

それだけ。

ところで、SoftBankといえばドメイン名がないなど独自の書式のURLを特に自社サービスや課金まわりで多用することで知られている。例えばYahoo!ケータイのトップ画面はhttp://ptl/menu/だ。他にも、デジタルコンテンツのダウンロードに固有なURLなどがあるわけだが、その手のものもいろいろと見えてしまう。また、GPSの送信履歴からいろいろと面白い行動履歴を追うこともできる。

しかし、実際には遅いウェブサイトは機会損失であり、いくら昔と比べてハードウェアが安価になり、仮想化技術が発達したとはいえ、それだって無料だったり無限に増設可能なわけではない。PCサーバ1台の増設をサービスのプロデューサに納得してもらうのは結構難しいことだ。仮想環境だってたくさん立ち上げるにはそれなりの実環境が必要になる。不景気の中で運用コストが上がる解決方法しか提示できないのは競争力に問題があるといわざるをえない。よって、スケールアウトは常に正しい解決ではない。

もちろん、最初から最大限に速度を追求してシステムを組むのは素晴らしいことで、誰もが実践するべきだ。しかし、そんなに簡単なことなら速度が問題になることなどあり得ないわけで、実際にはこの点を追求し過ぎるとリリースしなければいけない期日を守るのがとても難しくなってしまう。遅いのも機会損失だが、リリースできなければ機会が存在さえしなくなってしまうので、エンジニアリング過多は根治されるべき疾患だ。

期末が近づいてきたので、この2年くらいの自分の仕事をざっと整理してみたのだが、一昨年の暮れから今年の始まりにかけて、よく考えたらずっと既存のソフトウェアの高速化ばかりやってきた気がする。最初の立ち上げから1年以上経過したサービスがとうとう音を上げてしまったこともあれば、作ったばかりなのに社内の別チームから要求された速度が到底達成不可能だったので急遽なんとかしなければいけなくなったケースもある。恨み言をいわせてもらえば、ハードウェアやシステム構成の選定は当の検品屋連中だったりするので、そいつらの見積りが甘いのが原因なのだが、お客さんの求めるものがあってのソフトウェアであるわけで、理不尽だと叫んでもプログラムは速くはなってくれない。

そんなとき、誰もが思いつくのは、出力データや処理結果をキャッシュして速度を稼ぐ方法だろう。ご多分に漏れず自分もだいたいいつもそうやってきた。ウェブ上のプログラムには、大変ありがたいことにエントリーポイントがひとつしかない。そう、リクエストを受け付ける場所だ。出所の同じHTTPのリクエストは同時に一ヶ所にしか届かない。そこから、中間の処理があって、出力先は最終的にはリクエストを送ってきたクライアントになる。

前提条件 => 処理実行 => 処理結果

ネットワークの遅延や巨大なレスポンスによるクライアント側の負担といった問題は、普通はそんなには起きない。単純に考えると、結局はウェブ上のサービスはリクエストという前提条件があり、ソフトウェアによる処理があり、レスポンスという処理結果があるだけだ。

ということは、前提条件と処理結果の関係を把握して、その近道を探すのが高速化の第一歩ということになる。ここでのチェックポイントは

「前提条件（リクエスト）と処理結果（レスポンス）の関係」

の検討だ。自分で作業する場合は、まず

（１）リクエストをグループ化することができるか

を考える。メソッド（GETや、POSTときどきDELETEやPUTみたいな動詞）、リクエストURI、クエリで処理結果が同じになるグループを作成することができれば近道は見えたようなものだ。

例：GETのみ、docomoのゲートウェイを通過、FOMA端末、/listsへのアクセス、クエリは「type=used&maker=toyota」であればレスポンスは共通

この場合、リクエストを受け付けた際に既に同じレスポンスを返したかどうか判定して、していなければ通常の処理を実行してキャッシュを作成、キャッシュが作成済みであれば処理をすっ飛ばしてキャッシュからデータを返す、という単純な対応が可能かもしれない。キャッシュの実装内容はシステムのI/O負荷により異なるだろうが、そこは後で検討すればいい。ストラテジーパターンで変更できるようにするとか、まあいろいろ手はある。

そこで問題になるのが、動的コンテンツを提供する場合、まあ当然ながら静的なコンテンツで速度が問題になるのはほとんどあり得ないだろうから当たり前だが、レスポンスとして返されるコンテンツの内容の更新頻度だ。リクエスト毎に内容が変わるのであれば、単純なキャッシュでは対応できない。そこで

（２）更新頻度のグループ化

について検討することになる。いまどきカウンタなんか載せているサイトは絶滅しているだろうが、それでも刻一刻と在庫状況が変化したり、コメント数が増えていくようなコンテンツはたくさんある。

ページ全体が同じ頻度で更新されることは稀だろう。同じリクエストとみなしていいグループに常に新しいContent-typeを返すことはあり得ないが、オークションの入札状況のようにサーバ側のリソースに変化があればそれを常に反映する必要のある部分もあれば、人気の検索語のように1時間くらいに1回更新しても誰も気づかないようなものもある。

例：更新頻度最大 = 入札状況、更新頻度中程度 = 残り3時間以内の商品、更新頻度低 = ホットな検索語

更新頻度のグループがあまりに細分化されている場合は、運用者とよく話し合って、可能な限り単純化していくことが必要になる。サービスの品質に影響がない程度に、できれば3パターンくらいになるとちょうどいい。

3パターンくらいであれば、キャッシュした全体のデータに部分的なキャッシュを組み合わせてレスポンスを作り上げるだけのプログラムをリクエストを受けた場所で処理して済ませることができる。

それから、もっとサーバに楽をさせてあげたいときは

（３）クライアント側に処理を肩代わりできるか

を検討する。PC向けサービスであればクッキーに格納できるデータもあるだろう。JavaScriptにあらかじめ呼び出されそうなデータを格納してしまってもいい。検索候補を表示するのに正直にデータを毎回取得したりせず、サーバ側からは定期的に更新するだけのデータをブラウザ側に先に送っておけば、毎回非同期通信が走ることもない。

もちろん、第三者からアクセスされてはいけないデータもあるので、なんでもかんでもこのやり方が正しいわけではないが、なんでもかんでもサーバ側で処理するのも同様に正しくはない。でも、推測不可能なハッシュ値を格納しておいてそれをキーとしてmemcachedにデータを探しに行って、なければDBに問い合わせるといった対応も可能だ。

３はちょっと話が逸れたが、１と２は「前提条件（リクエスト）と処理結果（レスポンス）の関係」の検討だ。これらがクリアになれば、途中の処理をどれだけ端折ってレスポンスを作成することができるか考えるのはそんなに難しいことではなくなる。

そうなると次にやるべきことは

「処理実行の副作用への対処」

ということになる。アクセスログのように勝手にサーバ側で実行される副作用なら深く考えることもないだろうが（カスタム形式に必要な処理があれば別だ）、検索履歴の保存やアフィリエイトからのアクセスの記録など、サーバ側に直接レスポンスとは関係のない副作用が生じるケースがあれば、それに対応しておかないとサービスには深刻な影響がある。関数型言語をかじったことのある人なら、ある関数が副作用を持つことで前提条件と結果の関係だけで安心することができないことを充分教育されているだろうから、この副作用というものについては手続型言語しかやったことのない人に比べれば敏感かもしれない。

というわけで、単純な考察に相応しい単純な結論として、高速化が可能なプログラムを作るには、上の手続きの反対をまず心がけることだ。リクエストがグループ化可能なレベルになるように要件を定義して、出力するコンテンツの更新頻度をなるべく単純なグループに分類可能に保ち、それから副作用に慎重になる。RESTfulなサービスにする意味はリクエストのグループ化に貢献することにある。更新頻度の単純化と副作用を最小限にすることはキャッシュ戦略を容易にしてくれる。アルゴリズムやプログラミング手法で高速化することも非常に重要であり、キャッシュは万能ではないが、ウェブサイトを100倍速くしたいなら、まずはこんなところから手をつけてみるといいのではないかと思われる。

当然ながら、RAMが128MBでCPUがCeleronの500MHzというサーバで1秒間に100もの動的コンテンツへのリクエストを受けるといった無謀な環境で大冒険している人は、こんなことを検討する必要はこれっぽっちもない。手元の中古のデスクトップを抱えてデータセンタに駆けつけてケーブルを引っこ抜いて差し替えて、全部のリクエストに「ごめんね」と返すだけの設定が完了したら、あとはなるべく遠くまで逃げることだ。追いかけてくる連中も、そんなに賢いことはあり得ないので、深刻に気に病むこともない。

*原文はHTMLのコメントになっています。

A new approach to China
1/12/2010 03:00:00 PM

名前の知られた企業の常として、私たちは毎日あらゆるレベルのサイバー攻撃に晒されています。12月の中頃にも、私たちの企業インフラは中国発のかなり高度な、目標の絞りこまれた攻撃を受け、その結果Googleの知的財産が盗難の被害に遭っています。しかし、当初は単なるセキュリティ事件に思われたものが、実際そうではあるのですが、全く異なる問題であることがすぐに明らかになったのです。

第一に、攻撃はGoogleだけを狙ったものではありませんでした。調査の過程で、インターネット関連や金融、科学技術、メディア、化学分野といった幅広い分野に渡る少なくとも20の世界規模の企業が同様に攻撃目標となっていたことを突き止めました。私たちは現在これらの企業に問題を通知し、同時に関連する米国の機関と共同で作業を進めています。

第二に、私たちは攻撃者の最終目標が中国の人権活動家たちのGmailアカウントにアクセスすることだったという証拠を手に入れました。現在までの調査では、攻撃は目標を達成できなかったと思われます。2つのGmailアカウントの情報にアクセスされていましたが、それもアカウント情報（アカウントが作成された日付など）とメールの件名に限定されており、メール本文にはアクセスされていません。

第三に、本件の調査の過程で、今回のGoogleへの攻撃とは関係なく、私たちはGmailユーザで米国や中国、ヨーロッパを拠点とする中国国内の問題にかかわる人権活動家たちのアカウントが日常的に第三者によりアクセスされていることを発見しました。これらのアカウントはGoogleのセキュリティ対策を掻い潜ってアクセスされていたわけではありませんが、大半は一般のパソコンに仕込まれたフィッシング詐欺や悪意のあるコンピュータウィルスによるものと思われます。

私たちはGoogleとそのユーザのセキュリティを強固にするためのインフラや設計の改善のために今回の攻撃から得られた情報を利用しています。個人ユーザの皆様は、信頼できるアンチウィルスソフトウェアやアンチスパイウェアプログラムをコンピュータにインストールして、OSの更新プログラムで最新のパッチを適用し、ウェブブラウザをアップデートしてください。インスタントメッセージや電子メールに表示されるリンクをクリックする際やパスワードのような個人情報をオンラインで提供するかどうか質問される場合は常に注意してください。私たちのお勧めするサイバーセキュリティについての詳細はこちらでご覧頂けます。今回のような攻撃について更に知りたい方は米国政府のレポート（PDFファイル）やNart Villeneuveのブログ、GhostNetのスパイ事件についてのこちらのプレゼンテーションをお読みください。

私たちが今回の攻撃についての情報をこのような形で公表するのは、セキュリティと人権問題への影響だけが理由ではありません。この情報がさらに幅広い国際的な言論の自由についての議論の核心に迫るものだからです。過去20年間、中国の経済改革と市民の起業の才は非常に多くの中国人民を貧困から救いあげてきました。この国はさらなる世界の経済発展の中心となっているのは間違いありません。

私たちはさらなる情報へのアクセスが中国の人々に利益をもたらし、より開かれたインターネットが検索結果を検閲することになる不快さを上回ることを信じて2006年の1月にGoogle.cnを立ち上げました。当時、私たちは「自分たちのサービスを制限する新しい法律や規制を含め、中国の状況をより注視していく。もし先に概説した目標を達成することが出来ないと判断した際には、中国へのアプローチを再考するのに躊躇はしない」ことを言明していました。

暴露されたこれら一連の攻撃や監視、それに過去数年間に渡るウェブ上の言論の自由を制限しようとする試みにより、私たちは中国での事業運営が実行可能であるかどうか再考するべきであるという結論に至りました。私たちはこれ以上Google.cnで検索結果を検閲し続けるつもりはありません。今後数週間、法律の範囲内で可能な限り検閲のない検索エンジンを運営することをベースに中国政府と議論していきます。これによりGoogle.cnの閉鎖もあり得るでしょうし、中国国内のオフィスの閉鎖の可能性もあります。

中国での事業運営の見直しの決定は厳しいものであり、その潜在的な影響も大きいものであることは理解しています。この変更は米国本社の決定であり、Google.cnの今日の成功を支えるべく懸命に働いている中国国内の従業員の考えや意思決定によるものでないことをここに明言しておきます。私たちはこのような非情に困難な問題を解決すべく責任を持って取り組んでいます。

auの端末からのリクエストには、端末の契約情報に紐づいた一意のID（サブスクライバID）がリクエストヘッダとして送信される。そこで、こんなのを作ってみた。

（１）リモートアドレスでauのデートウェイからのリクエスト以外は弾く
（２）POSTリクエストを受け付けるURIはサブスクライバIDで異なる

まあ（１）はよくあることなのでいいとして、（２）はこんな感じになっている。公開するURLは「http://example.com/form」とかいう形式になっている。au端末からそのURLへのリクエストがあると、サーバ側で「https://example.com/xxxxxxxxxx/」にリダイレクトする。この「xxxxxxxxxx」はサブスクライバIDとサーバ側に保持している特定のsaltとなる文字列（例えば創世記の全文）から生成されたハッシュ値になっている。リクエストしてきた端末のサブスクライバIDから生成したハッシュ値とURIのハッシュ値が一致すればリクエストを通して、そうでなければ弾く。リダイレクト処理が入るので「http://example.com/form」へのPOSTリクエストはリクエストボディーの内容が消えたGETのリクエストになってしまうから、もし第三者がこのURLに対してCSRFを仕掛けてきても無効化される。ハッシュ値付きの正しいURLにPOSTリクエストを投げるようにしたくても、端末が送信するサブスクライバIDとsalt値とハッシュ値の生成ルールが分からなければ犠牲者の端末専用のURLが推測できないため攻撃用のフォームを作ることができない。

あとは.htaccessなどで存在しないディレクトリへのアクセスをリライトしてしまえばおしまい。

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

とかいう感じ。いやっほう。

あんまり見たことないやり方なので破り方があるかどうかちゃんと検証できてない気がするけど、思いつかないので実戦投入した。

ぼくもライトセーバーがほしいな。

思い立ったらすぐ行動、それが暗黒卿の生きる道です。

しめしめ、お母ちゃんは見当たらないぞ。

これはライトセーバーかな？

やったあ、ライトセーバーをゲット（たぶん）だ！

ご満悦の暗黒卿。

こうして、宇宙を征服するはずの暗黒卿「ダースまめ」は、すっかり野球選手になってしまいましたとさ。

SSL

SSLを利用している場合、基本的にSSLv3とTLS1以外を利用することはないので切っておく。特にNull暗号をオフにしておく必要がある。

Apacheだとこんな感じ。

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL

Poundだとこんな感じ。

ListenHTTPS
  Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL"

Apache

リクエストヘッダのHost部分を書き換えられることを前提とした設定をしていないケースが多いと思われる。VirtualHostの先頭にデフォルトの設定を入れて対応する。mod_rewriteは入っているものとみなす。

Apacheのバージョンが低い場合のTRACEメソッドの禁止も追加。

  DocumentRoot /var/www/html
  ServerName default.host.name
  RewriteEngine on
  RewriteCond %{REQUEST_URI} !^/server-status
  RewriteRule .* - [F]
  #TRACEメソッドの禁止
  RewriteCond %{REQUEST_METHOD} ^TRACE
  RewriteRule .* - [F]

Aliasで指定されたiconsやmanualは不要なので削除。

#Alias /icons/ "/var/www/icons/"
#
#
以下このディレクティブの最後まで。

PHP

基本的な設定はされているものとして、忘れがちなのをいくつか。php.iniの場合は

バージョン情報を晒さない。

expose_php = Off

リモートファイルをスクリプトとして読み込ませない。

allow_url_fopen = Off

リモートファイルをスクリプトとして読み込ませない。

display_errors = Off

続く、かも。

サイト更新 --POST--> Pubsubhubbub --POST--> Ferretのインデックス更新

で？といわれたら、それ以上でも以下でもないとしかいいようがない。しかも小っ恥ずかしいことに新規追加にバグがあったので直した。