アマゾンはperlでできている - Javaジャバ言ってる間にも(7)

長らく謎だと思っていたことが、あっさり判明した。 アマゾンのWebサイトはperl言語でできている。

以下、http://www.masonhq.com/?AmazonDotComより。

Since mid-2002, Mason has been Amazon.com's official website templating system, powering the main Amazon.com site as well as partner sites. As one engineer at Amazon writes, "Mason elegantly solves the problem of large-scale web development, giving Amazon.com web developers the power of industry-standard Perl and the simplicity of re-usable components. This has made it easy to manage and evolve a very large mission-critical global codebase, and has halved the ramp-up time for new developers."

The web tech team at Amazon is intent on contributing Mason changes back to the community where possible. For example, about half of the changes in 1.21 and 1.22 (mostly performance improvements) originated at Amazon. See also the MasonPlugins project.

And now the recruiting plug: Amazon.com is seeking experienced Perl and Mason users for full-time web development positions. See http://www.amazon.com/jobs for details.

以下筆者翻訳:
2002年中ごろ以来、Amazon.comはWebサイトテンプレートシステムにMasonを正式に使用しています。 それはamazon.comだけでなくパートナーサイトにおいても同様です。 Amazonのあるエンジニアはこう書いています。 「Masonは大規模なWeb開発における問題をエレガントに解決してくれています。 業界標準であるPerlのパワーと、コンポーネント再利用の容易性を Amazon.comの開発者に与えてくれています。 それによって巨大でミッションクリティカルなコードベースの発展と管理が容易になり、 また新しい開発要員の立ち上がり(育成)に必要な期間が半減しています。」

AmazonのWeb技術チームはMasonを改良しそれを可能な限り積極的にコミュニティに還元しています。 例えば、バージョン1.21と1.22の間の変更(ほとんどがパフォーマンス関連の改良)の 約半分はAmazonの技術チームによるものです。 MasonPluginsプロジェクトも参照してください。
Masonというのはperlで書かれたWebサイト開発向けのテンプレートライブラリだ。 配布元のページによると、 たとえば Masonをインストールしてapacheの設定ファイル(httpd.confとか)に
PerlModule HTML::Mason::ApacheHandler
<Location />
    SetHandler perl-script
    PerlHandler HTML::Mason::ApacheHandler
</Location>
と書き、
% my $noun = 'こんちは';
やあ、<% $noun %>!
元気?
と書いたindex.htmlファイルをドキュメントルートにおいて、 http://www.example.com/index.html をブラウザで見ると
やあ、こんちは!
元気?
となるという寸法。PHPやJSPと書き方が非常によく似ているようだ。

はたと思い出してamazon.co.jpのスタッフ募集ページを見直してみたら、しっかり書いてある。

・・・ C/C++、オブジェクト指向の設計および分析、RDB、SQLおよび業務処理システムに強い方。 XML、XSL、HDML、WAP、XHTML、 CSS、Perl、Python、MasonおよびCORBAの知識がある方。 RPC、SOAPおよび他のメッセージ技術とネットワークプロトコル および UNIXシステムの高度な経験がある方。
ざっと見たことはあったのだが、 Masonがperl言語で書かれたWebサイト向けライブラリであることを 恥ずかしながら知らなかったせいか、ピンときていなかった。 主なシステムはC言語で、perlやpythonはそれらの主なシステム間の ちょっとしたつなぎ程度の小さなプログラムの開発に使っているのだろう、くらいにしか思っていなかったのだ。 (実際そういうケースはよくある) ちなみにアメリカ本国のアマゾンのスタッフ募集ページも技術者の求人スキルについては ほぼ同様の書き方だった。

なお、アマゾンのソフトウェアが全てperlかというとそうではないだろう。 「アマゾンで使用されているソフトウェアのうちWebサイト用なのは 全体の4割に満たない」というような話をアマゾン関係者の インタビュー記事かなにかで昔読んだ覚えがある。

たしかに、物販系のECサイトでは消費者向けのフロントエンドだけでなく、バックヤード、つまり在庫や物流の管理、卸業者との取引管理のほうがよほど重要だし、ソフトウェアの本数的にも大きいだろう。 それらのバックヤード側のソフトウェアにもperlがメインに使われているという確証は無い。

しかし、ひとつのビジネスを展開するうえで、そのIT基盤を作り上げるためのプログラミング言語は少なければ少ないほど良い。 技術者を融通しやすいからだ。したがってどんな企業であれ、 必要以上に多種類の言語に手を出したりはしない。

この記事を書くきっかけとなった、 Six Apartの宮川氏に深謝。 ちなみに宮川氏のサイトにあるこの翻訳も 参考になる。

See also:
Javaジャバ言ってる間にも (2003/12)
Javaジャバ言ってる間にも(2) (2004/3)
いまおすすめの言語はPHP −Javaジャバ言ってる間にも(3)(2004/5)
Javaジャバ言ってる間にも(4) − FriendSterはJavaからPHPに乗り換えていた(2004/9)
IBM、PHPの支持を表明 − Javaジャバ言ってる間にも(5)(2005/3)
「従来のEJBは存在自体が間違いだった」 - Javaジャバ言ってる間にも(6) (2005/6)

警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性 − 後悔しないためのWebデザイン

産業技術総合研究所の高木氏のブログより。

警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性 (高木浩光@自宅の日記 2005/7)
激しく同意。

日立が出しているZoomsightとかいう読み上げソフト?の解説ページによると

警察庁では、高齢者の方および障害者の方が警察庁ホームページで提供される情報に問題なくアクセスし利用できるようにするための取組みを行っています。 その取組みの一環として、音声読み上げ等の機能を警察庁ホームページで提供開始いたしました。
・・・・。もうなんと言ったらいいのかわからない。誰も何もおかしいと思わないのだろうか。

ちょっと無理を承知でたとえ話にしてみよう。

あるレストランでは、障害者にも利用してもらおうと、玄関前の階段の横にスロープをつけることにした。工事を請け負う建設会社はこう言った。「便利な車イスがあるんですよ!その特別製の車イスしか通れない専用のスロープにしましょうね!専用車イスはレストランさんがお客さんに配ってあげてください。」

ここで「うんよろしく」と言ってしまったのがいまの警察庁の状態なのである。

普通にものを考えることができる社会人は「アホか。手すりでもつけてあとは広めに作っておくだけでよろしい」と言うだろう。 そういうごく普通の考えのもとにWebサイトをデザインすると例えば最近リニューアルされた例で言えば 気象庁のトップページのようなデザインとなる。弱視を含む視覚障害者向けのソフトウェア=特注の車イスではなく普通の車イス=は、こうしたシンプルなWebページであればあるほど効果と利便性を発揮するようになる。 気象庁のWebサイトをデザインした制作会社がこういう効果を提案してこのシンプルなデザインが採用されたのか、それとも気象庁の役人の側からそういう注文をつけたのか定かではないが、まあ前者だろうというのは想像に難くない。

警察庁だけでなく、あらゆるWebサイトの役割は、自身の持つ情報を正確かつ見やすく整理して掲載すること=どんな車椅子が来てもたいてい通れるようにしておくこと=であって、特殊な車イスを提供することではない。それはラーメン屋がドンブリを手作りしているようなものだ。 警察庁の例では不要なソフトを大枚はたいて買った無駄だけでなく、 高木氏の指摘のとおり、市民のコンピュータのセキュリティ性を低く誘導するという副作用までつけてしまった。

楽天の「大人のブックス」のその後

リンクチェッカーを動かしてたら気づいたのだが、 楽天のアダルト本コーナーである「大人のブックス」がいつのまにか移転している。 正確に言うと、http://books.rakuten.co.jp/otona/ にアクセスしようとすると、http://dl.digipa.com/shop/digipa/adult/book/ というページにリダイレクトされる。 リダイレクト先には、オトナのブックスのほうに以前からあった 不良っぽいバニーみたいなロゴマークが残っている。(以上2005年7月現在)

楽天のアダルト本コーナーは、筆者がその存在を指摘したのは2003年12月のこの記事でのことだが、 2004年暮れのライブドアvs楽天のプロ野球球団設立騒ぎで がぜん注目を浴びたのは記憶にあたらしい。ちなみにこの時期のアクセス数やトラックバック数は今でもこの「ネタ帳」サイトの五指に入る(笑)。

さてこのデジパというサイトだが、はたと見た目には楽天グループと無関係に見えるところが例によってというかなんというか。 その会社概要 に載っている経営陣の名前と楽天の経営陣の名前の一部が完全一致することは頭の隅に入れておいていただきたい。

別に楽天が悪いとかライブドアかわいそうとか、どっちの肩を持つとかいうわけではないのだが、 プロ野球騒ぎのときは有名な弁護士さんにまで「楽天社長の三木谷浩史氏の嘘は、スポーツマンシップに反し、プロ野球オーナーとしては、致命的というべきです。」とまで徹底的に批判されていた。 なのにここへきてまだ「移転しました」のページをはさむでもなく黙ってリダイレクトしているだけで脈々と商売を続けている。しかし http://books.rakuten.co.jp/otona/ のときには無くて批判されていた「18歳以上ですか?」の確認ページはしっかりはさんであるところがまた・・・

普通に考えれば、そんなコソコソやらなければならないのならいっそやめてしまえばいいのにと考えるのが普通だし、 今の楽天ならそういう選択肢も現実的だと思うのだが、 そうは行かないのがEC業界の現実だったりするのだ。 書籍、CD、DVDのEC業界ではもうアマゾンが完全独走。bk1がかろうじてくらいついて、あとは死屍累々(楽天ブックスも含まれる)。アップルのipodのブレイクとiTune ミュージックストア日本版の来襲も迫ってますます崖っぷち。残る安定収入源はアダルトのみ、というわけ。

大バトル勃発! AmazonレビュアーVS著者

まぁちらっと見ただけなんですが。

大バトル勃発! AmazonレビュアーVS著者
改めて思うのが、
  • 新聞記者が書く記事は意外とウソやトンチンカンが多いのと同様に、 本屋の新書コーナーに並ぶような本を書く人も(当然その内容も)ピンキリなんだなぁということを改めて実感。
  • 本は本で今後も重要な情報源であり続けることに変わりないだろうが、ネットもネットで本なみの影響力を持ちはじめているのだなぁ。
  • ますますもって、情報の取捨選択(選択眼を持つこと)が重要になってきた。
そんな感じの日曜日。さて、本屋にでも行くか。

Googlebot-Mobile 現る

ここ2,3日前から、Webサーバのログにこんなのが現れるようになった。

DoCoMo/1.0/N505i/c20/TB/W20H10 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
IPアドレスはgoogle所有のもので間違いなかった。 どうやら、モバイル端末向けコンテンツに特化した検索にも注力し始めたようだ。

勝手にDoCoMoを名乗るのもどうかと思うが。(笑) しかし、コンテンツを供給する側がUser-Agentヘッダを見てコンテンツを振り分けているケースも多々あるはずだから、仕方ないか。

部屋番号のないマンションとPermalink(特定のコンテンツ≒特定のURLという前提が崩れるとき)

むかし、

特定のコンテンツ≒特定のURLという前提が崩れるとき - 後悔しないためのWebデザイン(2004/7)
という記事で自分が書いた内容とほとんど同じことが
部屋番号のないマンションとPermalinkの共通点(2005/6 伊藤直也の「アルファギークのブックマーク」より)
で書かれていて、その分かり易さの違いというか文章力の差に脱帽・・・。

天気予報をXMLで提供すると気象庁が発表してから半年が経った

2005/8追記: この記事には筆者の誤解に基づく内容が含まれています。 コメントを含めてよく読んでください。 なお、新しい記事のほうもどうぞ。
実は2004年の11月には既に気象庁がこんなプレスリリースを出している。
府県天気予報・府県週間天気予報を新しい形式(XML形式)で提供します。
◎:平成16年12月から追加して発表するもの
(XML形式で提供します。気象庁HPでも12月から掲載します。
しかし発表で予告された12月1日からもう半年以上を経た2005年7月現在、 気象庁のwebサイトにはXML形式のデータなどどこにも見当たらない。

理由をいくつか考えてみよう。(注:あくまで想像ですので本気にしないように)

理由その1:アクセスが殺到しそうなので大規模な配信サーバ環境をいま作っているところです

文系の官僚や代議士をごまかすのに有効な言い訳である。 確かに、天気予報&XMLというコンテンツの性質上、かなりの数のアクセスが予想される。 単純なWebサーバではあっという間にパンクするだろう。 しかし、そもそもが天気予報だ。 そのデータ量はゲームや動画に比べれば米粒みたいなものである。 ブレードサーバを十数台も束ねれば十分だろう。 いや、CDN(コンテンツデリバリネットワーク)サービスに丸投げしてしまうのも手っ取り早くて安全確実な方法だ。 いずれにせよ準備に半年もかかるようなことではない。

理由その2:天気予報は単純だけど重大な情報。 間違いがあってはいけないので、どういう流通&加工がされるかわからないXML形式での配信はやっぱりやめました

一見理にかなっていそうだからやっかいな言い訳である。 しかしよく考えると、交通事故は困るから自動車に乗るのはやめましょう、 と言っているのに等しい。

理由その3:公開してますよ。財団法人気象業務支援センターが。有料で。

・・・・ラーメン屋行ったらラーメンが700円で割り箸が70万円と言われてる気分。 (注:支援センターが本当に日々の天気予報のXML形式での情報配信を今現在やっているかどうかは実際のところ不明)

プレスリリースまで出しておいて、結局はあいかわらずのオトナの事情、と。

追記:
正解は 理由その3 でした。

JMeter使用上の注意

久しぶりに技術的な話題。Apache JMeter(ジェイメーター)というオープンソースソフトがある。負荷テストツールと呼ばれるもので、大量のHTTPアクセスを発生させてWebサーバなどに負荷をかけ、どの程度のアクセス数に耐えられるかを調査するためのソフトだ。

短時間のうちに大量のアクセスが予想されるWebサイト、例えば、コンサートチケットの予約サイトや、人気ゲームの予約販売サイトなどを構築する際にこうしたツールがよく利用される。 商用の負荷テストツールもあるが、高機能だが値段も高いので、 apacheと同系統のオープンソースソフトであるJMeterも重宝されている。

ところが、ちょっとした誤解がもとで、JMeterは使い物にならないという間違った判断を下してしまうケースが意外と多いらしい。

JMeterの実行時の設定として「スレッドグループ数」と呼ばれる値がある(一般にはリクエストの多重度とも呼ばれる)。 例えばこれを10に設定すると、あたかも10台のPCのブラウザが同時にアクセスするかのようなHTTPリクエストを発生することができる。 では、100に設定すれば100台ぶんの、10000に設定すれば10000台ぶんのHTTPリクエストを同時に発生させることができるのだろう ・・・と考えてしまいがちなのが罠であり注意すべき点だ。 無限に大量のHTTPリクエストを発生させることができるはずがない。

数年前に筆者がJMeterを試したときも、あやうくこの罠にひっかかるところだった。

  1. スレッド数10で実行してみる・・・Webサーバからのレスポンス速度平均が1秒
  2. スレッド数20で実行してみる・・・Webサーバからのレスポンス速度平均が1.3秒
  3. スレッド数60で実行してみる・・・Webサーバからのレスポンス速度平均が5.6秒
  4. スレッド数100で実行してみる・・・Webサーバからのレスポンス速度平均が5.5秒・・・って、なんでスレッド数60のときと値が変わらないんだ!?!?
スレッド数を増やす(≒多重度を上げる)とおかしな値になるということは、 JMeter自体にやはり何らかのバグでもあるのだろう。信頼できないなあ・・・ という感想を残して終わってしまうケースが意外に多いのではないだろうか。 筆者が最近聞いた話で、そういう判断を下してしまっていたケースが実際あった。

真相は、単にJmeterを実行しているマシンの性能限界に達していたために、 設定したスレッド数ぶんのリクエストを発行できなかっただけである。 どんなに優れたソフトだろうと高性能なハードだろうと必ず限界があるのは当然だ。 JMeterを利用する場合には、PCのリソースメーターでも見ながらテストとしていくつかのスレッド数で実行してみて、 マシンの性能限界に達しない程度のスレッド数を事前に見極めておく必要があるのだ。 筆者が試したのはもう数年も前のことだが、確かPentium400Mhz程度のマシンでスレッド数50前後でCPU利用率が100%に達してしまった覚えがある。

なお、JMeterには、親マシンを1台指定して、 複数台の子マシンを操ってリクエストを発生させることで、 この性能限界問題を解決する機能がある。 解説はこちら

最近ではJmeterに関する雑誌記事や解説サイトも増えてきたが この落とし穴に言及している内容は意外に少ない。注意したほうがいいだろう。