「ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解」記事へのコメント

うーん

[Inetpub (20077)]

「img1.mixi.jpで提供しているものを
mixi.jpから提供するようにすればいいんじゃね？」
ってワシは思うし、みんなまずそれを思いつくと思うんだけど
なんか他の手段で解決しようとしてるとこを見ると
ドメインを変更できない理由があるんだろうね。

Re:うーん

[Another_View (29838)]

単純にロードアベレージの問題ではないか？。
mixi.jpドメインはロードバランサ配下でスクリプトの実行に専念し、静的コンテンツは(img1.mixi.jp等の)他のサーバからとらせると。

ま、ようするにバランシングの設計がまずかったわけだな。

Re:うーん

[ef (25263)]

freeocean [e-trees.jp] {を,も}使っているようです。
View HTTP Request and Response Header [web-sniffer.net]

Server: e-trees.Japan freeocean (e7-3.0R)

「もう負荷分散は必要ない」---1台で同時50万接続のWebサーバーが登場：ITpro [nikkeibp.co.jp]

freeoceanは，HTTP，TCP/IP，イーサネットなどWebサーバーの機能に必要な最低限のプロトコルをFPGA（Field Programmable Gate Array）で実現したWebサーバー専用装置である。

Re:うーん

[Another_View (29838)]

いまちょっと試してみた。

icXX.mixi.jp(XXは数字)はApacheかlighttpdの混成だった。
img-p1とimg-p3はfreeoceanでimg-p2はlighttpd。
img1はApacheでimg2はSquid。

よくわからん。

Re:うーん

[Another_View (29838)]

　1年くらい前はmixi.jp自体は多数のLinuxサーバだった(Fedora Core)。いまもそうなのだろう。
　img1の方は、静的コンテンツを直接パスで指定し、freeoceanを使うことでロードバランシングのために多数の鯖をそろえるのをケチったわけだな。
　結局のところ、当初の設計がまずかったんだろうなあ。ここまでの規模になることを想定していなかったんだろう。

　#1039448のいうとおり、認証サーバをたてるのが良いのだろうが、いろいろ書き直しになるんだろうな。あるいは、画像もデータベースに放り込んじゃうとかね(w
　でも、いずれにせよ、せっかく買った珍しいおもちゃ(freeocean)を捨てなきゃいけないな。

Re:うーん

[ef (25263)]

1年くらい前はmixi.jp自体は多数のLinuxサーバだった(Fedora Core)。いまもそうなのだろう。

そのころ、はてな、イー・マーキュリー(当時；現ミクシィ)共同勉強会 [hatena.ne.jp]というのが開かれていて、イー・マーキュリー発表資料(PDF) [hatena.ne.jp]にイメージクラスターの事も載っています。
が、増え続ける負荷に対応するための努力の解説に終始しており、画像の認証に関しては言及はありません。

Re:うーん

[Anonymous Coward]

LBで静的コンテンツディレクトリとスクリプトを
それぞれ別プールに振ればいいだけのような気も。

Re:うーん

[Anonymous Coward]

拡張子で判定とかできないんですかね。 それですら負荷？