Bloggerでのデータファイル置場に関する検証と考察

Googleのブログサービス、BloggerではJavaScript、スタイルシート等の静的ファイルをサーバにアップロードする機能が無い。
つまり、これらのファイルは別のサーバにホスティングする必要がある。
ホスティングするサーバに関して検証を行い考えてみた。
あくまで個人的な考えです。

発端

私は今までGoogle App Engineにファイルをホスティングしていたのだが、先日(といっても結構前)、Google App Engineで数時間に及ぶ接続障害が発生し、私のブログが閲覧できない状態になってしまった。
これは、head内でGoogle App Engineのファイルを参照していたため。

ホスティングサービス

Google Site

無料で利用でき、かつGoogleが提供しているサービスとして、Google Siteがある。
Google Siteでは、ファイルアップロード機能も用意されているため、Google Siteにアップロードし、そのファイルをBloggerにて参照するという方法。
アップロードもGUIが用意されているため比較的簡単にできる。
また、ファイルの世代管理も可能。

Google App Engine

こちらも無料で利用できるGoogleのサービス。
少々知識は必要だが、自由度も高く、アプリケーションも開発できる。
ファイルのアップロードは、コマンドラインやEclipseなどによるデプロイという方式をとるため、手間がかかる。
また、ときどき障害が発生し、ファイルが参照できなくなる。
ファイルが参照できないと、最悪の場合、Bloggerの閲覧が不可能になる。(head内でGoogle App Engineのファイルを参照している場合など)

オンラインストレージ

Dropboxや、SugarSyncなどにファイルをアップし、パブリックリンク機能を利用する方法。
ファイル管理は楽にできる。
また、ファイルの世代管理も可能。
但し、レスポンスが悪い時もある。

検証

Google Site、Google App Engine、Dropbox、SugarSyncにファイルを置いて、レスポンス時間を計測。
head内でGoogle App Engineのファイルを参照するのは懲りたのだが、改めてどの程度の応答か確認してみる。
置くファイルは、100KB(102,400Byte)のJavaScriptファイル。
計測する環境は、以下

• Windows 7 64bit
• Google Chrome 23

計測は、Google Chromeのデベロッパーツール(Ctrl+Shift+I)のNetworkにて行う。
また、デベロッパーツールにて、ブラウザのキャッシュを無効化(Disable cache)した。
計測後、HARファイルとしてエクスポートし、集計しました。

単位はミリ秒です。

	Google Site (リダイレクト)	Google Site (ファイル取得)	Google Site (リダイレクト+ファイル取得)	Google App Engine	SugarSync	Dropbox
1回目	312	277	589	549	613	1295
2回目	342	269	611	512	595	1273
3回目	260	263	523	720	589	2043
4回目	271	439	710	559	565	1220
5回目	281	267	548	816	948	1463
6回目	324	240	564	669	757	1700
7回目	256	275	531	655	822	1596
8回目	294	572	866	562	1011	1336
9回目	295	315	610	561	804	1541
10回目	324	458	782	748	527	1323
平均値	296	338	633	635	723	1479
中央値	295	276	600	609	685	1400
最小値	256	240	523	512	527	1220
最大値	342	572	866	816	1011	2043

検証で分かったこと

Google Site

Google のサービス内(Blogger、Google App Engine等)からであれば、ファイルを読み込むことが可能。
ただし、直接読み込めるわけではなく、リクエスト»Auth keyの発行»リダイレクト»ファイル読込 となるため、2回目のリクエストでようやくファイルを読み込むことができる。
Google App Engineと比較すると、稼働率は高いと思う。
レスポンスで返されるファイルは、Content-Encoding:gzipとなっており、ファイルが圧縮されているため、通信量の節約が行われているので、レスポンスも早い。
Last-Modified,Etag,Cache-Control(max-age=1, must-revalidate)ヘッダによってキャッシュ制御が行われている点も良い。

Google App Engine

ファイルを直接読み込むことが可能。
Google Siteと同じようにContent-Encoding:gzipによってファイルを圧縮して返してくれる。
しかし、Google Siteより稼働率は低いと思う。
ファイルに付与するヘッダや、キャッシュの有効期限を任意に設定できるという点で、自由度は高い。

SugarSync

ファイルを直接読み込むことが可能。
レスポンスは若干遅め。
Google Siteと同じようにContent-Encoding:gzipによってファイルを圧縮して返してくれる。
Last-Modified,Etag,Vary(Accept-Encoding)ヘッダによってキャッシュ制御も行われる。
障害は少ない。

Dropbox

ファイルを直接読み込むことが可能。
レスポンスはかなり遅い。
なぜなら、Google Site、Google App Engine、SugarSyncと異なり、gzip圧縮してくれないため、通信量が多くなる。
他と比べて、倍の時間がかかっている。
Cache-Control:max-age=0となっているため、ファイルは常にサーバから取得される。
レスポンスが遅いうえに毎回問い合わせとなるため、最悪。
障害は少ないがオススメしない。

総評

今回の検証ではGoogle Siteが一番良さげ。
早速head内で読み込んでいるファイルをGoogle App EngineからGoogle Siteに変更しました。
Dropboxは意外に残念な結果でした。

他に検証してほしいホスティングサービスがあれば、コメントにて教えてください。
ただし、パブリックリンクが取得できるホスティングサービスに限ります。
Google Drive、SkyDrive、Boxは現時点でパブリックリンクに対応していません。