2007 年 7 月 9 日

転送量オーバーの問題は思っていたよりも容易ならざる問題だということが分かってきた・・・

先日、ninjaToolsのカスタマーサポートより「転送量の超過が規約違反なので改善されない場合は削除する」という通知が来たという件、何人かの方から情報をいただいた。
プロのサーバ管理者の方に言わせれば
「40～50GB／月間程度のトラフィックはしれた問題で、それに対処出来ない鯖はちょっとさびしいかも」
というご意見らしい。
それでちょっと楽観していたのだが、実際には現実はもっと厳しいということが徐々に分かってきた。
ある方からいただいた情報では、こういう問題は実は各所で起きていることらしい。

その実例として教えていただいたこちらのサイト「maclalalaweblog- 突然ですが・・・.」は私もブックマークしていたサイトだっただけにちょっと衝撃だった。

ここにトラックバックをかけているThe blog of H.Fujimoto：あなたのBlogに迫る「続けられなくなるかも」という危機というサイトの結論にもあるように、
『ただ、レンタルBlogの業者も、ボランティアでやっているわけではありません。
負荷の問題など、業者側が技術でカバーできる点は、ある程度はカバーすると思います。
しかし、それだけで済まない点については、藤シローさんの例のように、業者がBlogの著者に対して「相応の負担」を求めるようになる可能性は否定できません。

これからは、
「コストを負担してでもBlogを続けるか、それともBlogを辞めるか」という選択を迫られる人が、徐々に増えてくるのかも知れません。』
というところが実情かもしれない。
当サイトの場合画像ファイルが転送量を押し上げている要因なのだが、その対処法はいずれも一時しのぎで結局いつかはこの問題に直面せざるを得ないということだ。

私の場合、とりうる手段は、画像を多用するサイトのスタイルを放棄するか、多くの問題を抱えるGeoのサーバに戻るか、サイトを非公開化するか、あるいはサイトそのものを止めてしまうか、のいずれかしかないということになる。
Geoを画像倉庫代わりに使うことを熱心に勧めてくださる方もいらっしゃるのだが、Geoのサーバは外部から画像を呼び出せないという問題もあることにも気がついた。
このことはメールをいただいた方からもコーションがあったし、私自身今のninjaサイトをテストしている時に実際にテストして確かめていたのをすっかり忘れていた。
つまりGeoもあまりにも倉庫代わりの使用が多いので対策を施してあるということだろう。
Geoに画像を置くならGeoに戻るという選択肢しか無い。

非公開化して読者を排除するというのは最も現実的な選択なのだが、「情報は共有されなければならない」という私のポリシーとも矛盾するし、細々やっている個人サイトは「読者が増える」ということしか励みが無いだけに、これはやはりモラル低下につながる解決法になるだろう。

こちらの
「転送量問題とポイントカード問題は実は似ている。 (Junnama Online (Mirror))」
というサイトを見ていて思ったのだけど確かに、インターネットの「無料サービス」に過剰な期待をしてはいけないという現実を思い知った。
昔「完全無料接続プロバイダ」を謳った「ライブドア」という会社は、その高い理想と斬新なニューエコノミーのモデルにもかかわらず、現実には経営不振に陥り、結局はホリエモンのオンザエッヂに買収されるという憂き目にあってしまった。
その後このパイオニア企業がどうなってしまったかは周知の事実だ。

１０GB／月間という規約があっても、ユーザが全員そのギリギリのトラフィックを使い切れば結局そのサービスは破綻するというのは、
「無料サービスは広告モデルで成立する」
というネットでいわれている話のウソを証明している。
そりゃそうだろう。でなかったらアクセスが多いサイトを追い出すなんて絶対しないはずだ。

結局トラフィックの問題はサイト管理者に負担を回すしか解決策が無いということらしい。
しかも10GB／月間程度のフローでも超過になってしまうのだ。

FC2などは1GBという途方も無いファイル容量を謳っているが規約によると
「全契約者の平均転送量の１０倍を超える場合は削除の対象になる」
とのことだ。
平均の転送量がどれくらいなのか知る由もないが、ひょっとしたら数十MBかもしれず、それだとどう考えても回避の方法はないということになる。非公開化しか手段は無いかもしれない。
そういえばこのninjaのサーバも規約には「異常に多い転送量」が規制の対象になるとは書いてあるが、具体的にはどれくらいの転送量がそれに当たるのかということはどこにも書いていない。
事前に自分でチェックすることは全く不可能だということだ。

あと考えられる方法は月数千円～数万円の契約料を払って有料サービスに移行するか、自宅鯖を上げるか。
しかしボランタリのサイトをそんな持ち出しをしてまで続けなくてはいけない意味は何なんだろう？
自宅鯖を上げるという方法も今の回線の太さでは話にならないだろうから、設備投資も必要だし技術的にも手間的にも費用的にも出費は多い。
技術的な問題は興味があるのでちょっとやってみたい気はするが、そんな手間と金銭的コストを支払う余裕が自分にあるとは到底思えない。

結局上杉謙信の逸話ではないが、「渇いたる者は泥水をもすする」でエロサイト専用サーバでもどこでも探してみるということになるかもしれない。
エロ広告が出まくるのはちょっと困るが。

ページ分割での対応はかなり厳しいかも

上記転送量の問題についてninjaさんに問い合わせたところ以下の回答が来た。

『平素はNINJA TOOLSをご利用頂き、誠に有難う御座います。
ご質問について返信させて頂きます。

アクセス数が多いことも関係しているのかもしれませんが、
保存するディレクトリを増やして、１ファイル自体のサイズを小さくするなどし
できるだけ忍者ホームページ管理画面内「HTTP転送ログ情報」で、転送量が赤字
で表示されないようにご改善を行っていただけますよう、お願いいたします。』

このログ情報を見て思ったのだが、私の計算はちょっと甘かったようだ。
ここの数字を見ると転送量は
７０～９０GB／月間
ということになりそうで、お叱りを受けてもしかたがないというレベルなのかもしれない。
このあたりの常識が私には分からないのだが。

この最新記事から以降、運用ページを週割りにして毎月４ページに割ればここの転送量は減らせるかもしれないが（減らせないかもしれないが）、それでも多分４０～６０GB程度に抑えられたら上出来かもしれない。
ninjaさんがどれくらいの転送量を許容してくれるのか今問い合わせ中だが、仮説として１MB/req以下とすると、例えばよく使うアプリ９「サウンドアプリ」のページが今７MBなのだが、７分割しないといけない。
よく使うアプリのページは、そこだけで合計１００ページ以上に分割しないといけない計算だ。
この一覧性が私的には良いと思っているのだが、トラフィックを考えるとやはりダメということらしい。
しかもそこまでやって、一時的には規約レベルをクリアしたとしてこれ以上アクセスが増えたらやはりさらにページを細分化しないといけなくなるということになるかもしれない。

先ほどninjaさんから問い合わせの答えが届いた。
一日の転送量の許容量の目安は120MB、月間だと3～4GB程度ということらしい。
つまり転送量を２０～３０分の１に抑えなくてはいけないということだ！！

ここで机上の議論をしていてもしかたがないので実際に、画像ファイルを全部リンクで飛ばすというサイトを作るとどうなるか試作してみた。
以下は先日の記事で上げるはずだった、AppCleanerの記事をそのように書き直してみたものだ。
これでトラフィックの改善につながるだろうか？

文中アプリのページへのリンクがいくつかあるが、こういうものもページを細かく分割すると全てリンク切れになってしまうので、書き直さなくてはいけないということだ。

AppCleaner

Macのアプリのインストールはインストーラを使うものもあるが、基本的にはディスク上にアプリを置くだけという簡単なものが多い。

どちらにしても非常に簡単だ。
だがアンインストールも簡単かというと、そうでもないのが残念だとういう話を何度かここにも書いた。
ところがそういうことに不満を持つ人が多いせいか、最近では「アンインストーラ」というジャンルのアプリがいくつかでてきて、この不便も解消されつつある。

もともとOSXのアンインストールは簡単ではないといっても、モジュール化が進んでいるOSXのことだから基本的にはそのアプリと同じ名前を含む支援ファイルを探してそれを削除すれば良い。
Windowsのdllをエディットだのとかいう話に比べれば遥かに簡単なのだが、その支援ファイルがどこに入っているかという勘所を知らない初心者にはやはりアンインストールはややこしいかもしれない。

このAppCleanerはAppZapperやuApp、AppDeleteなどのこれまで紹介してきたアプリの一長一短あったところを兼ね合わせたような良さを持っている。

まず関連ファイルを選択する正確さはAppZapperに匹敵しているかもしれない。これまでのところやはり実用的に使うには信頼性ということではAppZapperが一番だったと思っているのだが、このAppCleanerはいろいろ比較してみたくなった。

それにこれはアプリだけでなく、Widgetやプラグインなども本体を指定するだけでアンインストールすべきファイルを探してくれる。
こういうものも実は周辺ファイルを散らかすものがあるので、この機能はありがたい。
例によって「起動中のアプリは削除出来ない」とか「デフォルトアプリケーションは削除出来ない」などの安全装置も装備しているし、削除したくないアプリを登録する機能も持っている。

ここまで実用性のことばかり書いてきたが、このアプリのビジュアルのアクションもなかなか面白い。回転したりスイングしたりというウインドウの切り替わり方は見ているだけで楽しい。
だからって調子に乗って必要なアプリまで削除しないように、注意は必要なのだが。

AppCleanerのスキンはシンプルそのもの
基本的な使い方はこのようにウインドウに削除したいアプリをドロップするだけだ
それで削除すべきファイルを表示してくれる手順はAppZapperあたりと同じ

またウィジェットの削除もここでできる
ウィジェットは一時脆弱性もいわれたので手順を踏んだ削除が必要だが
いちいちDashboard画面に入らなくてもアンインストールできる

削除すべきファイルのリストを表示するので問題なければ下のバツマークをクリック

また歯車マークをクリックすると設定に入れる
ここでどういう種類のファイルを削除するかを選択出来る
基本的には全部捨てるという設定でまず問題は無いはずだが

このAppCleanerの良いところはこういうレシートファイルの.pkgまで削除してくれること
これを無視するアンインストーラアプリが多いのでこれはすばらしいと思う
つまりインストーラアプリもちゃんと削除出来るということだ
unpkgのようなアプリも必要なくなるかもしれない

インターネットプラグイン、コンテクストメニュープラグイン、
システム環境設定ペイン、スクリーンセーバ、QTプラグインなどを探索できる
なんだこれ！万能じゃないか！

そしてお約束の「削除してはいけないアプリ」の指定もできる
まさに至れり尽くせりというところだ

もうひとつの解です。
http://nmuta2005.web.fc2.com/nmuta2005/

アカウント名は
account
パスワードは
passwd

ある程度移行を完了したらパスワードを変更して非公開とします。

2007 年 7 月 10 日

Twicetab

Safariにタブの空いたスペースをクリックするだけで新規タブをさっと開けるSIMBLプラグイン。

インストーラの指示に従ってただOKボタンをクリックするだけで、プラグインの本体は
"~/Library/Application Support/SIMBL/Plugins/Twicetab.bundle"
にインストールされる。
アンインストールはこれを削除するだけ。

Safariの設定に入ってタブのページでタグを常に表示するという設定にしておく。
あとはSafariのタブの空いている居場所をどこでも良いからクリックするだけで良い。
同じ操作は
コマンド＋Tキー
でもできるが、マウスでもそういう操作ができた方が良いし、そのクリックのターゲットは小さなアイコンよりもこういうタブ領域全部と広い方がクリックだって当然やりやすい。
小粒ながらなかなかピリッとしたプラグインだ。

Twicetabをインストールすれば
タブの空き領域のどこをクリックしても新規タブを開くことができる
これはスグレモノだ

2007 年 7 月 11 日

例の転送量オーバーの問題ははっきりいって思わしくない

ここのところ継続している転送量オーバーを解消するトライの評価だが、この数日で言えば全く成果が上がっていない。それどころか若干悪くなっている。

最新記事を毎週新規ページにすることで運用ページの転送量を改善するという方法はやや成果があった。経験的に過去ログを見る人は非常に少数なので、この対策は有効だった。
しかしninjaさんの言っている水準と、現実のトラフィックとは２０倍以上の開きがあるので、はっきりいってこれだけでは焼け石に水のようなことだ。

また各記事の画像を別リンクにしてビジタが「図参照」をクリックして呼び出すという方法では、全く改善しないことが分かった。
結局最新記事の場合は、皆がここを開くので全く改善に寄与しない。ましてやここにサムネイルを貼ったりしたら逆に転送量の増大につながるだろう。
この方法は最新記事だけにやっていたのでは、全く効果がない。

このninjaさんがいって来ている水準について考えてみたのだが、
120MB／日
という水準は現状「よく使うアプリ」のページに一日２０人のビジタがくればもうこの許容量は越えてしまう。
一人当たりの平均ページビューが３ページだとするとたった７人だ！
一日他のページを見る人が一人も来なかったと仮定しても、たった７人のビジタで、この水準は越えてしまう。
私のサイト全体の中ではこの領域のトラフィックはしれているのだが、それでもこの基準を達成しようと思ったらやはり全ての領域で、改善は必要だということだ。

これをやるなら過去記事も、アプリレビューのページも全てやらないと意味が無い。
そこでサウンドアプリ／Audio Operationで早速この方法をトライしてみた。
トライしてみたのだが、もううんざりしてしまった。

サイトを書き換えられたのは数時間かかって頭の１０分の１くらいだろうか。
この画像リンクを書き換えるという作業は、非常に退屈で根気と注意力を要求され、しかもその結果サイトの見てくれを破壊し、ユーザビリティを毀損するというだけの作業で、やっていくうちに、ここまでの手間を要求されて現状のサーバに留まる意味は一体何なんだという疑問が強く残ってしまった。
＜IMG SRC=のタグを全部機械的に書き換えるようなスクリプトも当然使えないし、ひとつひとつ目視してタグを読んで書き換えるべきタグか判断して、書き換えるという作業をしなくてはならない。 しかも私のサイトの画像の量は１００や２００というようなオーダーではない。

この作業をサイトの全領域で完了するには数ヶ月の期間が必要だし、その間更新も滞るだろうし、何よりも私自身が数ヶ月この作業に耐えられるかという問題がある。

ちょうどその時にMarine~麗しの青林檎のSeireiKさんよりメールをいただいた。

『皆さん「画像を別のサイトから呼び出せばいいのでは」と簡単におっしゃいます。テキスト主体のHTMLなら確かに軽く、画像サイズが転送量のかなりの部 分を占めていることも確かなんですが、これから書く部分に関してはいいとしても膨大な過去ログにおける画像ファイルのリンク先（＜img src= ＞や＜a href= ＞の部分）を全て書き換えねばならないことを考えると気が遠くなります。過去記事のリンク直しなんてのは本当に手間がかかる単調な作業です。
もちろん都合のよい画像置き場サーバーが見つかり、過去記事のリンク書き換えが達成されればかなり恒久的な解決になるとは思いますが、それよりはそっく りそのまま移転できるところを探した方が早いのではと私は思ったわけなんです。』

まさにそういう検証作業をしている最中だったので、SeireiKさんの書いておられることは正鵠を得ていた。
この作業を実際にやってみて、画像を別リンクにしたり外部の画像置き場のようなところに置いて、そこから直リンクで貼付けるという方法も全て非現実的だと思い知った。
大体昨年の移転にあれだけ時間がかかったのはほとんどこの画像リンクを修正する作業に時間がかかかったわけで、その苦労をもうしなくても良いように画像をテキストと同じボリュームに置くというリンクにやっと書き換えたのにまたそれを外部に置くというリンクに書き換えるなんてばかばかしい。
いくら自己中心的と言われようが、この方法だけは現実的だとは私には思えない。
どなたかがボランティアでこの書き換えを買って出てくれるというなら話は別だが、私にはもうこんな作業はできそうにない。

それで全てのページをもっと細かく分割してディレクトリを作るという方法も並行して試してみることにした。
これはユーティリティ5～その他／Utilities/Many other thingsのページですでに実施してみた。
計算上は転送量を２０分の１に抑えなくてはいけないわけだから、ページは２０倍以上に分割しなくてはいけないことになる。
それでもアクセス数が増えればまた転送量が増えるわけだから、その時には４０倍、８０倍という分割を考えなくてはいけないかもしれないが、そのことはそうなってから考えることにする。

ここまで作業をやってみた感じでは、この方がまだ現実的だ。
作業もこちらの方が数十倍軽微だ。
それにやってみて分かったのだが、これで各頁の呼び出しは随分早くなったのでこれはこれで快適だと思う。
問題はこのユーテリティのページだけで２０ページ以上になってしまったので、これをよく使うアプリのページ全域でやると数百ページにディレクトリが増えてしまうということだ。

過去ログまで拡げると１０００ページを越えるだろう。

しかもこの方法だとサイト内リンクの大部分は切れてしまう。私もどこにサイト内のリンクを置いたかもうさっぱり覚えていないので、とりあえずこのアプリの目次のページのリンクは直せるとしてもそれ以外のサイト内リンクはほとんど全て諦めるということになる。
ユーザビリティが壊れてしまうことはこれだって同じだ。画像リンクよりは遥かにマシだろうけど。

当座はこのninjaのサイトはこうした転送量とユーザビリティの兼ね合いをテストする実験場になると思う。私自身この問題には興味がわいて来たので、やってみようという気にはなっている。
でもこれをやって改善しないならやっぱりサイトは閉鎖か。
サイトの体裁が壊れていないところで見たいという方は、先日告知した
http://nmuta2005.web.fc2.com/
のサイトで見ることができる。
ただしこちらは非公開サイトなので、見るにはアカウントIDとパスワードが必要だ。
常連さんには個別にパスワードを発行するのでメールをいただければと思う。
nmuta2003アットマークyahoo.co.jp

プライバシーポリシーは
１）メールアドレスなど知り得た皆さんの情報は第３者に引き渡したり、公開することは無い
２）メールアドレスを収集して勧誘などのメールを送ることは無い
３）皆さんのメールアドレス、アカウント、パスワードは暗号化して保管され取り扱いには慎重を期する
ということで。
転送量オーバーになった時の対策で不定期でパスワードは変更される可能性がある。

＜追記＞
昨日のアプリページの細分化だが、意外に良いかもしれない。
徐々に他のページもやってみよう。