aij[beta]

Google Data APIの続き。

といっても、今日はDOMを思いだしてリンクを付け加えたり、Googleマップへクエリーを足したり。どちらかというとjavascriptのお勉強。

2008 花火大会カレンダー -東京-


追記
とりあえずテーブル表示に対応。
2008 花火大会カレンダー -東京-


追記
Iframe表示を削除した。リンク先は、IEでは表示されない。

Googleカレンダーを使用して、2008年の花火カレンダーを作成している。せっかくデータが集まったので、他に使えないかと考えた。Googleカレンダーは、Google Data APIをサポートしているので、XMLでいろいろと取り出せる。

Google Data APIをJSONでアクセス - 水青(サービス)Wikiを参考にして、試してみた。
javascriptは得意ではないのだけど、サンプルをごにょごにょしてみる。

今日のところは、カレンダーデータを"東京都"のqueryをかけてフェッチして、日付順にソートするところまで。

2008 花火大会カレンダー -東京-


目標は、プルダウンで県名を選択して、テープル表示かな。

追記
Iframe表示を削除した。リンク先は、IEでは表示されない。

2月13日から、IE7が自動更新の対象になる。

どうも、ピンと来ないのだけど、これを指折り数えて楽しみにしている人がいるのだろうか？Windows Internet Explorer 7: 自動更新インストールのお知らせでは、カウントダウンまでしている。

欲しい人はすでにインストールしているだろうし、逆に企業の情シスではやれやれと思っているだろうし、誰もメリットを感じていないと思うのだけど。直接担当しているわけではないけれど、業務アプリをwebアプリケーションで実装していると、ブラウザの検証だけではなく、アプリそのものや、シェルとしてのExploerやらも面倒を見る必要があるし、OSのアップグレードよりタチが悪い。こういう外的要因の検証なんてコストもかけられないしな。誰も嬉しくないよね。

暇つぶしに答えていた、IT Security Award 2008の当選通知が来た。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
▼ご当選賞品
　監督賞　Tech・Ed 2007 Post Conference DVD
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

まあ、参加賞みたいなものか。

IT Security Award 2008 授賞式とやらにもご招待されたけれど、どうしたものか、

サーバーとして使用しているWindows 2003 server上のアプリケーションやバッチファイルをリモートから実行指示をかける話。

方法1
WMIを使う。
バッチファイルを起動する程度あればこれが一番楽。
リモートのWMIプロバイダに接続して、Win32_Processをコントロールしてやればよい。
リファレンスとしては、WMI Operating System Classes (Windows)。ただし、実行するアプリケーションがネットワーク上のリソースを必要とする場合はうまく実行できない、ネットワーク上のサーバーからファイルをコピーするとか。どうもWMIから実行されるプロセスに制限があるようなのだが、そのあたりのドキュメントが見つからない。

WMI Fun !! 〜 WMI に興味がある方・システム管理者必見 !! 〜このあたりも必読。


方法2
タスクを使う。
スケジュールしない（無効な）タスクとして、アプリケーションを登録して、そのタスクを外部から呼び出す方法。管理共有が有効であれば、リモートからタスクを呼び出すことが可能なので、

schtasks /Run /S マシン名 /U ユーザー名 /P パスワード /TN タスク名

あたりで、なんとかなるか。

UNCパスから、.NET Frameworkで作成されたアプリケーションを起動する時は、caspol.exeで、file URLを追加してやるとうまくいく。

同じURLを複数追加すると、ポリシー判定がうまくいかなくなる。
caspol.exeはお馬鹿だから、同じポリシーがあることに気がつかない。って、こんなことにハマって半日無駄にした。

web applicationの実行環境として、VMware Infrastructure 3を使用したシステム構築を行った。


web applicationはwindowsベースで、IIS、ASP、ASP.NETをベースにしている。web applicationはTCPコネクションの数をベースにして、実行プロセス数が増え、経験的には管理するプロセスが30-40になるとサーバー性能が頭打ちになる。現在ホスティングしているアプリケーションは60コネクションが限界となる。

インフラ構築としては、最大値をベースにして考えざるを得ないので今までは、要はサーバーを何台建てましょうかというのが、ビジネス側の要件定義との交渉になるのが普通だ。2000ユーザーが同時にアクセスして問題ないシステムにしろという要件だと、サーバー一台で40ユーザーですから、2000/40で50台サーバーが必要です。サーバー一台50万として、2500万になります。その他、構築費用、IDCの初期費用、このあたりはビジネスの速度にもよるのだが、ざっと5-6000万くらい、もちろんDBサーバーもあります、ストレージもありますとなると普通に一億になる。まあ、だいたいこのあたりでビジネス側とは喧嘩になるのだが。

BtoB のweb applicationが稼働するサーバーはリソース状況を見ると、ピーク時間帯が決まっていて、それ以外でCPUの利用率が10-20%くらいなものだ。要はピークに合わせると明らかに無駄なシステムになる。そこで今回は、8Uのブレードサーバー20台に、VMware ESX Serverを使用して仮想マシンを60台という構成を組んでみた。実マシンはdual coreのCPUを2つ、memoryは20GBで1台のブレードに3つの仮想マシンという構成だが、CPUやmemoryの設定はデフォルトのままで、ほぼ期待通りの性能が得られた。問題点はネットワーク周り。VMware ESX Serverと今回のブレードシステムに関しては、NICのチーミングが使えなかったので、耐障害性とパフォーマンスのどちらかを優先する形となり、今回はパフォーマンス優先で考えた。経験的にはNICの故障率はほとんど低く、ネットワークトラブルのほとんどはNICから先で起こることが多いので、そちらで工夫してみることにした。

全体の効果としては、ハードウェアの初期費用の圧縮、IDCの初期費用の削減が大きい。実マシンでの構築の場合のほぼ40％まで圧縮できた。VirtualCenterという仮想マシンの集中コンソールを使用したオペレーションの効率化も図れる。あとは、仮想マシンがハードウェアにほとんど依存しないので、開発環境、ステージング環境と、運用環境の統合が、仮想マシンというイメージファイルベースで管理できるのは、あまり予想していなかったメリット。

季節変動のあるアプリケーションの場合は、仮想マシンのホスティング数を動的に変更するようにすると、アウトソーシング費用も従量課金的にできるが、ここはIDCによって考え方がいろいろなので検討の余地がある。
同じプラットフォームでLinux系のアプリケーションもホスティングするのが、直近の課題。

ビジネス側も喜んで、よかったよかったなのだが、コスト削減やビジネスの立ち上げ速度の要求は果てしないので、次のステップを考えなければ。