いろいろやってみるにっき

てきとーに生きている奴の日記

古いエントリのサムネイル画像がリンク切れになってたりするけど、チマチマ修正中


帯域

現代の仕事とは思えない。どういう業界の話か知らないけどその業界の情シス子会社ってラクな仕事だなあ。これ、受託したSIerのやらかしだったら訴訟沙汰だわ。

 

togetter.com

 

普通、元々の通信量を測って帯域設計するのよ。LANだとほぼレイテンシを無視できるかもしれないけど、WANを使う場合は色々なネットワーク機器を通過するため、公称数値通りにならないこともあるので、実測して検証したりもするし。

 

クラウド側も出口に大金払えばそれなりのレスポンスを出せるけど、予算的にそういう設定にできない場合もあるし、やはりここにも帯域設計は重要。

 

 

ポストから分かる範囲の想像でしかないけど、純社内システムならOSのバージョンとかオウンリスクとして負う気になれば拙速に更改する必要もない。(セキュリティ面で)ネットワーク設計がきちんとできていれば、脆弱性を突かれる可能性も低いし。今回の話は基本的にイントラネットの話に見えるので、拙速だったとしか思えない。

 

あと、まとめた人なんでコレをまとめに入れた?

WordPressみたいな話はしてないんだよ。イントラネットのシステムで全くWordPressを使わないとは言わないけど(単なる社内お知らせ系とか)、基本的には業務系システムの話しているんだよ。

shigeo-t.hatenablog.com

 

これで終わると面白くないと思うので20年以上前の昔話を書いておく。20年以上前でも今世紀なんだよな。

某企業でシステム更改の案件を受注した時の話。代理店システム(代理店側)の更改案件で、それまで代理店側に設置したPCアプリを全部Webシステム化する話。今回のようなクラウド化と同じようにネットワークの利用量が大幅アップの案件である。

 

この企業は大変賢いので、普通にWeb化すると各代理店の帯域が苦しいのではないかと考えた。そこで、画面定義は常時PCにある状態にできるUI製品の採用を「ウチが受注した後に」通告してきた。提供社名は変わっているけど製品は存在するので、生き抜いたんだなあという感想を持った。

それ以外にもヤバい会社を配下に開発することなども「ウチが受注した後に」通告してきて色々苦労したんだけど、そっちはまあその……今回は関係ないので書かない。

 

画面は最初のダウンロードでは時間が掛かるけど、業務が変わって画面に変更が生じないのであれば転送が生じない。そのため、ほぼ業務データのみのやりとりとなる。当時だとJavaアプレットで同様の効果を求めることが多かったが、クライアントサイドJavaよりも動作が軽いという点でも当時のクライアントPC事情に合っていた。

 

当時の代理店はADSLを使っていたりする店もあり、ヘタすると数100kbpsしか出てないこともあるので合理的である。ただ開発期間中に起きたトラブルはオレは許していない。

このUI製品とサーバ側はうまく通信で来ているように見えるのに、画面の描画でサーバから送っているはずのデータがはめ込まれないという事象である。オレは別サブシステムで忙しかったのに急遽トラブルシュートに呼ばれ、全データをトレースしたところ、うまくいっていない通信であるのに、このUI製品が盲目的に200 OKを返していたのである。403あたりを返すべき(まあエラーコードならなんでもいいけど418以外)であったと記憶している。

developer.mozilla.org

 

サーバ側は200が返ってきているのでうまくいったと思っているし、UI製品側は処理できないデータを受け取っているので処理できていない。ワイワイ騒いでいるのを横目に見てから2日くらい、オレが調査始めて4時間くらいで問題に行きついたが、そのあとこのUI製品開発企業に詰めて製品検査方法からレクチャーするなど、オレの仕事そっちのけで掛かり切ったので、そりゃ許せないでしょ。

418ならこういう機器が必要。

お時間あったら、他のエントリもクリックして頂ければ幸いです。