- 2010 年 7 月 21 日
- [ Column ]
2010/7/21に突然、AVGを使っている方々が日刊スポーツを始めPC Watch等多くのサイトで「JS/Redirが検出されました」として閲覧が出来なくなりました。
調査していったところ、HTML中の特定の文字列に反応していることがわかりました。
サーバ側の対策としては、HTMLのソース中の
<script type="text/javascript" src="http://xxx/xxx.js"></script>
の><部分にスペースを入れれば回避できる事がわかりました。
<script type="text/javascript" src="http://xxx/xxx.js"> </script>
サーバ管理をしている人で困っている方、お試し下さい。
＃あーびっくりした(^^;
＃というか、時間を返して～>AVGさん
追記：実際にAVGで誤検出となるページを２パターン作成してみました。AVGを使っていない人はただの真っ白の画面になります。ソースを御覧頂くとわかるのですが中身はたった2行です。PC Watchパターン(isobe君ありがとう)。日刊スポーツパターン。
2010/7/21現在での最新のAVGを使っている人は、ブロックされて以下のような表示になるはずです。
- 2010 年 4 月 13 日
- [ Column, Other, iPhone ]
- 2010 年 2 月 25 日
- [ Column ]
日経が月額4000円で紙面やその他想定しうる機能をフル実装したサービスをスタートするようです。
新聞業界という複雑な体質の中、フル実装にこぎ着けられた裏方が非常に気になるところです。
また、電子版オンリーの金額設定が4000円という金額から、電子版オンリーでも購読者の地域の販売店にバックされるロジックがあるのでしょうか？
一般紙ではなく、セグメント化されたコンテンツホルダーならではなのですが、是非ビジネスモデルとして成功して欲しいと思う次第です。
気になるのは、iPadやiPhone Safariでの閲覧がどの程度の操作感になるかですね。
あとは、購読者の地域のチラシも一緒に読めるビジネスモデルは、広告集める販売店側も購読者もWelcomeな気がするのですがどうなんでしょうか？
少なくとも、ここからの１０年間。
私たちは、従来の紙の時代から変わりゆく歴史的転換点の目撃者になるのは間違いないなさそうです。
先日、iPhoneアプリからアダルトっぽいものはすべて削除されたそうです。
嘘かほんとかはわかりませんが、iPadに教科書をすべて入れて、子どもたちに配布するのが視野にあるからだという噂も。個人的には、ちょっと暴走気味な気もしますが、１０年後、子どもたちの重いランドセルが軽く小さくなる日が来るのかもしれません。
- 2009 年 10 月 9 日
- [ Cloud, Column ]
正直、この１年以上、ずーっと、クラウドや仮想化に関して追っかけてきました。
Google,Amazon,VMWare,Xen,etc
で、一つの結論があります。
弊社のように常に処理能力且つ低コストを要求されるシステムを構築する場合は、「クラウドを使わない従来スタイル（１サーバに１OSをセットし冗長化構成を構築）の方がハイパフォーマンス」という結論になりました。（あたりまえと言えばあたりまですが・・・）
「クラウド」は営業的にウケもよく、ビジネス的に儲かるかもしれません。いくらメンテナンス性や障害に強いといっても、客先の要求する処理能力と予算を満たせなければ、膨大な予算を使って「豚」なシステムを構築するだけになります。
しかし、そんな営業をされて取ってきた仕事を引き受ける技術者は悲惨な事になりそうに思います。「クラウド」はあるべき姿だと思いますが、弊社内のベンチマーク結果では、ms単位の処理能力要求があるシステムを構築するには時期尚早だという結論に達しました。
ベンチマーク結果を公表したいところですが、VMWareあたりは規約上NGらしいので。。。
なんかうちの会社、ベンチマークを取る度に、時代に逆行しているしているよな気がします。 ＃だから儲からないんですね(^^;
でも、うちのアドバンテージは、技術屋として、ビジネスより質実剛健なシステム構築を優先する所にあると思っています。
- 2009 年 2 月 17 日
- [ Column ]
昔は、SCSIならAdaptecの2015や2010。IDEならiodataのdelta2あたりをつかっておけば、いざっていうときは、RAIDカードを撤去してマザー直指しで復旧作業が出来ました。
しかし、昨今のHardware RAID カードは、メーカー独自フォーマットが主流となってしまいました。その影響で、サーバメンテナンス業者は、
- ＲＡＩＤカードが壊れると、そのハードディスクは、マザーに直接指しても全く読めないハードディスクになってしまう。
- ＲＡＩＤカードが製造中止になるとかなりまずい。
- 緊急時に別マシンで複製したりバックアップからリカバリーしたりするにも常に同じＲＡＩＤカード環境がないと作業が出来ない。
というリスクが伴います。
それでは、LinuxのSoftwareRAIDにしたら?という話になります。
ハードウエアRAID vs ソフトウエアRAID。
この論議を机上論で行うとハードウエアＲＡＩＤに軍配があがるのですが、実際の泥臭い現場の状況からすると、ハードウエアＲＡＩＤは結構痛い目に会うことが多いのは事実だと思います。これまで１４年間。数百台のサーバを作り最後まで看取ってきましたが、ハードウエアＲＡＩＤのホットスワップで得た恩恵の回数と、ＲＡＩＤカードを使った事によるトラブルに巻き込まれた回数とあまり変わらないように思います。やはりシステムの摂理として、シンプルなのが一番で、複雑になればなるほど事故も増加します。
そこで、システムが冗長化になっていれば、ホットスワップが出来ないＳｏｆｔｗａｒｅＲＡＩＤの方がメリットが多いのではないか？という切り口から、いまさらながら、ハードウエアRAID vs ソフトウエアRAIDのスピードテストを行ってみました。速度さえトントンであれば、この際、ハードウエアRAIDを捨てるのも現場的にはありかと思ったからです。
結果は、以下の通り。弊社ではこれを機会に冗長化してあるシステムにおいて、ハードウエアＲＡＩＤはやめる事にしようと思います。
■測定環境
| マザーボード |
Super X5DPR-8G2+ |
| CPU |
Intel(R) Xeon(TM) CPU 2.40GHz x 2 |
| メモリ |
2GB |
| ハードウエア RAIDカード |
3ware 8006-2LP |
| ハードディスク |
ST31000333AS x 2 |
| OS |
CentOS 4 |
| データベース |
PostgreSQL 8.1 |
■ 測定結果
以下SW=Software RAID, HW=Hardware RAID。水色が勝者。
▼bonnie++
○アクセス速度
|
Sequential Output |
Sequential Input |
Random |
Sequential Create |
Random Create |
| Per Chr |
Block |
Rewrite |
Per Chr |
Block |
Seeks |
Create |
Read |
Delete |
Create |
Read |
Delete |
| K/sec |
K/sec |
K/sec |
K/sec |
K/sec |
/sec |
/sec |
/sec |
/sec |
/sec |
/sec |
/sec |
| SW |
29738 |
76693 |
28425 |
26180 |
63601 |
387.5 |
33087 |
211403 |
35711 |
34286 |
273394 |
35336 |
| SW(-n 256) |
29221 |
76877 |
28401 |
26384 |
62070 |
377.2 |
19978 |
200433 |
509 |
11538 |
252888 |
266 |
| HW |
27081 |
57677 |
22943 |
25966 |
56936 |
379.2 |
29879 |
N/A |
N/A |
N/A |
N/A |
32170 |
| HW(-n 256) |
27983 |
56850 |
23303 |
24297 |
54209 |
352.6 |
19401 |
194718 |
715 |
11494 |
246347 |
377 |
○CPU使用率
|
Sequential Output |
Sequential Input |
Random |
Sequential Create |
Random Create |
| Per Chr |
Block |
Rewrite |
Per Chr |
Block |
Seeks |
Create |
Read |
Delete |
Create |
Read |
Delete |
| %CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
%CP |
| SW |
97 |
44 |
11 |
78 |
10 |
1 |
97 |
100 |
100 |
99 |
100 |
100 |
| SW(-n 256) |
95 |
45 |
11 |
79 |
10 |
1 |
70 |
100 |
2 |
40 |
99 |
1 |
| HW |
89 |
32 |
9 |
75 |
10 |
1 |
90 |
N/A |
N/A |
N/A |
N/A |
98 |
| HW(-n 256) |
91 |
31 |
9 |
70 |
9 |
1 |
70 |
99 |
2 |
41 |
99 |
1 |
▼pgbench
○条件
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 50
number of transactions per client: 200
number of transactions actually processed: 10000/10000
○結果
| SW |
123.03785 tps |
| HW |
95.591599 tps |
- 2009 年 1 月 24 日
- [ Column ]
データセンターの分散化をする場合、いまでもDNSラウンドロビンは現役です。
YahooやGoogleを始め、広くでも使われています。
先日、お客さんのサイトでトラブルがあり、ログを比較していたところ、特定のセグメントに、
かなり偏りがあることが判明しました。
１年ぐらい前はそんなことはなかったので、DNSラウンドロビンの誤差とも思ったのですが、
ログの量がほぼダブルスコアでした。はじめ、ログ収集でミスがあるのではないかと
必死に追ったのですが、全く問題がありませんでした。
トラフィックを見たところ、トラフィックも間違いなくダブルスコアになっています。
間違った、比率で応答するDNSがいるのかとも思ったのですが、全く見つけられませんでした。
そんな中、鈴木君が、ログ解析システムで、データセンター毎のユーザエージェントを
眺めていて、「あれ？なんかデータセンター毎のユーザエージェントがおかしい」言い始めました。
そう、Vistaが特定のデータセンターに集中していたのです。
| Data Center |
DNSラウンドロビンIP数での比率 |
Windows XP比率 |
Windows Vista比率 |
| A |
25 |
23 |
7 |
| B |
50 |
47 |
17 |
| C |
25 |
30 |
76 |
※OSとブラウザの組み合わせで出る問題なので、OSだけのデータでは語れないので参考値
いろいろと、調べて見ると、同じように騒いでいるページがあることがわかり、
結局、Vistaのgethostbynameが、DNSラウンドロビンの時は、
一番小さいアドレスを返す仕様（バグ？）であることが判明しました。
micorsoftさんもDNSラウンドロビンを使っているように見えるのですが、
みんな、困っていないのでしょうか？
Windows7でこの問題が治っているのを祈りたいところです。
それとも、getaddrinfoだと大丈夫なのでしょうか？
今後も改善されないとすると、結構、困ったことになりそうです。
- 2008 年 11 月 24 日
- [ Column ]
日本一の駄目経営者から世界一の駄目経営者になるべく、最近、ビジネススクールなるものに通っています。
まるで町の洋食屋のオヤジが、大手外食フランチャイズチェーン幹部と一緒に勉強しているような雰囲気です。(^^;
でも、大手の幹部がどうやって物事を考えているのか、もの凄く勉強になり、行ってよかったと思う次第です。
その中で、ハーバード・ビジネススクールのクリステンセンの教材を使った講義がありました。
内容としては、HPが1990年代前半に世界で始めて開発した1.3inchのハードディスク「キティーホーク」が、技術屋主導でろくに市場調査もせず突っ走った結果、ビジネス的に大失敗に終わるという、実に耳が痛～い(^^;)ストーリーでした。
講義ではいかにこのプロジェクトが駄目だったかを袋叩きにしていたのですが、私は、技術屋として、このプロジェクトがうらやましく思い、こんな熱いプロジェクトをやってみたいと思った次第です。（大失敗はまずいですが・・・）
教材の最後にこんな一節がありました。
「失敗したプロジェクトで、これほど多くのチーム・メンバーがもう一度はじめからやり直そうという意欲を燃やすケースは見た事がない。プロジェクトは終わっていずれかの折に、ほとんどのメンバーが私のところに来てはこういった『リック、あんな楽しいことはなかったね』と。」
たぶん、受講生の中で、ここで鳥肌が立ち、目頭が熱くなったのは、私だけかと。。。
お金だけ見ると確かに大失敗だったと思うのですが、きっとこのプロジェクトを通じて、人も会社もお金では計れない大切な財産をGETとした事と思います。今のHPには、このときのメンバーが残っているかどうかは知りませんが、「今のHPをささえているのは当時のメンバーだった」なんて後日談があったら素敵かなぁ～と思う次第です。
- 2008 年 10 月 20 日
- [ Column ]
先日、客先のサーバのマザーボードが壊れました。
２重化されていないサービスだったので、代替サーバを用意し、障害発生から約3時間でサービスを再開する事が出来ました。（今回のケースは思い返すとあと１時間は短縮できました）
また、２日後には、このサーバの二重化の環境が整いました。弊社では当然の如く、行った作業だったのですが、その話を、お客さんが、お客さんの同業他社の方に話されたところ驚かれたそうです。なぜでしょうか？
日本のソフトウエア開発プロジェクトの多くが赤字だそうです。利益が出ても数パーセントしか出ないそうです。弊社ではいくばくかですが利益を出しつつ、大手より安いコストで開発・保守を行う事が出来ています。なぜでしょうか？
答えは簡単なのですが、
弊社では開発したメンバーが保守までワンストップで行っています。
故に、サーバに障害が発生しても、すぐに対応が出来て弊社としては当たり前の事なのです。
この当たり前の事が、外注や派遣に頼り分業しすぎている大手には真似が出来ない芸当のようです。
弊社では全メンバーが全てを見渡せるレベルの技術者ばかりで構成しているため基本的に技術面から外注に出す必要がありません。また、人手が足りず外注に出さなければ受注できない仕事は、金額に関わらずお断りさせて頂いております。（過去にお断りをさせていただいた方、本当に申し訳御座いませんでした）
なんか弊社のCMのような文面になってしまいましたが、大手じゃないと出来ないソフトも多くあるのも事実なので、大手のやりかたを否定するわけではありません。でも大手じゃなくても出来るソフトを大手に社運をかけて発注し痛い思いをしているケースを聞くたびに、個人的には、もったいないなぁーと思う次第です。
- 2008 年 5 月 19 日
- [ Column ]
仕事の関係上、競馬のコンピ指数に携わる機会に恵まれているのですが、
「ギャンブルの金銭目的ではなく、プログラマーとしてコンピ指数を使った回収率の限界に挑戦してみたい！」
という思いから、Syunの食卓（社内で開催しているコンテスト）のテーマとしてとりあげ、先日、
無事（？）ステージ１が終了しました。
ステージ１は、2003年～2006年のコンピデータを使い予想ボットを各自で開発。
2007年のデータでの回収率を競うバトルとしました。
その結果、エントリーした35個のボットの内、6個のボットが100%越えを達成しました。（最高215%）
現在、各ボットのレギュレーションチェック中で、来週にはランキングが確定すると思います。
結構面白い結果となったので、このブログで発表できればと思っています。
- 2008 年 5 月 9 日
- [ Column ]
Google App Engineで遊んでみました。
感想としては、ついに来たか！という思いです。
Google App Engineが多くのソフトウエア技術ジャンキーを楽しましてくれればくれるほど
・データセンターがなくなる日
・ルータ・サーバ業者が商売にならなくなる日
・ネットワーク工事業者が商売にならなくなる日
・大手メーカーがさらに商売にならなくなる日
・ユーザはブラウザだけあれば全てが事足りてしまいOSはどうでもよくなる日
・ソフトウエア技術者がGoogle App Engineさえ使えこなせればよい日
の足音が聞こえています。
静かに、着実に、業界の歴史的転換点が近づいているように感じます。
その時、私たちは。。。。