静的ファイルの配信を Google Cloud Storage に移行しました

ブログの静的ファイルの配信を Amazon S3 + CloudFront の構成から、Google Cloud Storage へ移行してみました。Google Cloud Storage の方は単体で CDN 付なのでオブジェクトの ACL を一般公開設定にするだけで CDN 部分の設定が不要なのが便利です。

具体的には、Cloud Storage のコンソールで配信したいドメイン名でバケットを作成し、CNAME を c.storage.googleapis.com に向ければよいです。ドットを含む名前でバケットを作成する際は、それがドメインの所有権の確認が済んでいるドメイン以下である必要があるみたいです。
Bucket and Object Naming Guidelines - Google Cloud Storage

準備
Web UI はありますが細かい設定をしようとすると現時点では1ファイルずつしか設定できないので、速やかにCLIツールをインストールすることをお勧めします。

使用するコマンドは gsutil (Google Storage Util?) で、これのみインストールする方法もありますが gcloud コマンドからインストールすると自動更新対象になって良いと思います。gcloud コマンドのインストールは、Google Cloud SDK Quick Start で、インストール中にお勧めされるがままに進めると自動で gsutil も使用可能になると思います。

コマンド集

# バケット一覧
gsutil ls

# ヘルプ
gsutil help cp

# ファイルをアップロード
gsutil cp SRC DEST

# ディレクトリをアップロード
gsutil cp -r SRC_DIR DEST

# 今回アップロード時に使ったコマンド
gsutil -h "Cache-Control: public,max-age=31536000" cp -a public-read -z js,css,txt,html -r SRC_DIR gs://static.hidekiy.com/1/

setmeta が遅い
オブジェクトの新規作成 cp に比べてメタデータ (HTTP ヘッダー) の設定 setmeta は2倍～3倍ほど遅いように思ったので、配信を中断してよいのであればいったん削除してアップロードすると良いと思います。

遅い理由は、現在の ACL を読み取り、書き込みの2操作が余計に必要だからのようで、あらかじめバケットのデフォルト ACL を defacl で設定しておき、その設定のままで良いのであれば -n オプションを使って高速にメタデータを設定できるみたいです。

# gsutil help setmeta

-n          Causes the operations for reading and writing the ACL to be
             skipped. This halves the number of operations performed per
             request, improving the speed and reducing the cost of performing
             the operations. This option makes sense for cases where you want
             all objects to have the same ACL, for which you have set a default
             ACL on the bucket(s) containing the objects. See "help gsutil
             defacl".

gzip 済みで配信する方法
gsutil cp -z <ext,...> を使うと良いです。

デフォルト1時間になっている max-age を長くしたい
gsutil -h "Cache-Control: public,max-age=31536000" cp
で OK でした。cp の前に書くのがポイント。

全エッジサーバーからキャッシュを削除したい
オブジェクトを削除するとエッジサーバーにも伝搬するような挙動があるみたいです。これが公式仕様なのかは良く分かりません。

S3 との相違点
S3 では存在したアップロード先リージョンの指定がないので、その辺は Google が責任をもってデータを配置してくれるのだろうと思います。

追記 (2014/12/10)
データの保管されるリージョンはバケットの作成時に CLI で指定することが出来て、作成時に指定しなかった場合のデフォルトは US でした。+Shingo Ishimura さんご指摘ありがとうございます。
mb - Make buckets - Google Cloud Storage — Google Cloud Platform

また、S3 には存在したデータ喪失の可能性が上がるのを認めることでコストを下げるストレージタイプ (Reduced Redundancy Storage) の代わりに、耐久性ではなく可用性 (Availability) を下げるストレージタイプが Google Cloud Storage にはあるみたいです (Durable Reduced Availability Storage)。

QUIC 対応
とくに頼んでないですが Alternate-Protocol:80:quic になっているので可能な場合は QUIC で配信してくれるみたいです。


リンク
Concepts and Techniques - Google Cloud Storage — Google Cloud Platform
GoogleAppEngine - GCP エッジキャッシュ - Qiita

コメント

コメントを投稿

このブログの人気の投稿

[linux] ping は通るのに No route to host と言われる

ping による疎通は確認できるのに、いざ ssh などで繋ごうとすると No route to host というエラーで即座に接続失敗し途方に暮れる場合、おそらく原因は接続先のホストの iptables によりパケットがブロックされ、到達不能を意味する ICMP パケットが返ってきたことによります。 以下のコマンドで INPUT ポリシーをチェックします。上から順にマッチさせていき、マッチし次第ジャンプして終わるので、デフォルト条件の設定されていそうな一番下の行が肝心です。 # /sbin/iptables -L --verbose を追加してブロックしているポリシーのカウンタを見ながらブロック状況を観察できます。 # /sbin/iptables -L --verbose おそらく問題となっているのは INPUT ポリシー最下行で全てのパケットにマッチするこういう行です ... -j REJECT --reject-with icmp-host-prohibited 追加の説明 ファイアウォールの良くある動作として、不都合なパケットの受信を単に無視する動作ならタイムアウトとなります。しかしクライアントから見て TCP や UDP でパケットを送信した後、ICMP で Destination Unreachable Message が届いたときは親切にも No route to host と案内してくれるようです。 ちなみに icmp-host-prohibited は ICMP Unreachable Message の コード10 であり、経路上の障害などを調査するためのコマンド traceroute の結果に !X や !10 と表示されるようです。 参考 Man page of IPTABLES traceroute - Wikipedia Internet Control Message Protocol (ICMP) - Wikipedia
続きを読む

Chrome でダウンロードしたファイル名の一部がハイフンになる

Google Chrome で Content-Disposition ヘッダでファイル名に時刻 (12:34:56) のような文字列を入れてダウンロードするとなぜか勝手に 12-34-56 のようにハイフンになってしまう理由が良く分からなかったのですが、Windows ではそもそもファイル名にコロンは使えないので、安全のため全プラットフォームでファイル名にコロンを含む文字列を設定しないようになっているからみたいです。 変換対象の文字一覧は、 filename_util_unsafe.cc の illegal_characters に入っていて、変換先がハイフンになる理由は、 filename_util_internal.cc の GetSuggestedFilenameImpl でコールバック関数 replace_illegal_characters_callback を第二引数を '-' として呼び出しているからのようです。 ReplaceIllegalCharactersInPath の使い方は変換先を ' ' にしたり '_' にしたりするバリエーションがあったので、必ずしもハイフンに変換されるという訳ではないみたいです。 リンク https://chromium.googlesource.com/chromium/src.git/+/39.0.2171.95/net/base/filename_util_unsafe.cc https://chromium.googlesource.com/chromium/src.git/+/39.0.2171.95/net/base/filename_util_internal.cc
続きを読む

[windows] Windows 回復環境 (WinRE) を修理する

Windows 本体が起動しない場合は WinRE もしくはインストールメディアから利用可能なスタートアップ修復によって自動修復することができます。しかしインストール済みの WinRE 自体が起動しなくなった場合は自分で修理する必要があるようです。 winre.win の入ったパーティーションの開始位置をずらした場合や、BCD (ブート構成データ) から WinRE 自体のエントリをうっかり消去してしまった場合は、bootrec /rebuildbcd を使っても自動修復できません。そこで bcdedit を使ってちまちま再設定するのではなく reagentc を使うと以下の手順で簡単に再設定出来ることが分かりました。 winre.win というイメージをインストールディスクから抽出するか設置先から救出してきて、C:\Windows\System32\Recovery に戻します reagentc /enable というコマンドで BCD エントリとディスクイメージの設置 (winre.win のコピーではなく移動ｗ) が完了します 内部状態 ReAgent.xml には設定していると記録されていて、実際には BCD エントリが存在していない矛盾した状態になっているとエラーが出ます。その場合は ReAgent.xml を初期化すると無事動きます。 初期状態の ReAgent.xml は C:\Windows\WinSxS 内のどこかにあるようなので検索してみてください。手元の Windows 8 では C:\Windows\WinSxS\x86_microsoft-windows-winre-recoveryagent_... みたいな所にありました。 Windows 回復環境の現在の設定状況については reagentc /info で調べることができ、WinRE の無効化は reagentc /disable で行えます。 壊れる原因について Windows において MBR 経由の従来型のブート方式ではパーティーションごとの UUID 的な何かではなく、ディスク内でのパーティーションの開始位置によってどの OS を起動するべきかを BCD 内で指定しています。 よって gparted などで C:\Windows の入った領域の開始位
続きを読む