OpenPNE3.0がリリースされたのでインストールまでしてみる
2009-01-29 01:54 | IT | 2 コメント »
昨日、新生OpenPNE3.0.0がリリースされました。
今回のリリースの大きな特徴はなんといってもベースとしてsymfonyを採用したことです。
しかも開発のコミュニティーを見ているとsymfonyの採用バージョンを1.1から1.2へと途中で変えたり、いろいろ試行錯誤があったようです。
最新ソースはこちらのリポジトリか、zipファイルで取得できます。
インストール
それでは作業を進めていきます。
ソースのダウンロードと、展開を行います。
wget http://downloads.sourceforge.net/openpne/OpenPNE-3.0.0.zip unzip OpenPNE-3.0.0.zip
展開されたファイル群の中からNOTICEを見てみると、
This product needs the third-party softwares listed blow to run. - PHP: Hypertext Preprocessor (5.2.x) - symfony (1.2.x)
と、symfony1.2以上、PHP5.2以上が必要だと明記されています。
この環境にはすでにsymfony1.2.2とPHP5.2.6がインストールされていますのでこのまま進めてみます。
DBはMySQLを利用し、
dbname=openpne3, username=openpne3, password=password, host=localhost を用意しておきます。
OpenPNE用taskが追加されており、openpneで始まるtaskが用意されています。
利用可能なタスクは
symfony -T
で確認できます。
DBの設定とデータの初期化を行います。
symfony openpne:install
DBに関する設定をウィザード形式で進めていきます。
Choose DBMS (mysql, pgsql or sqlite)
mysql
Type database username
openpene3
Type database password (optional)
password
Type database hostname
localhost
Type database name
openpne3
Type database socket path (optional)
The DBMS mysql
The Database Username openpne3
The Database Password ******
The Database Hostname localhost
The Database Name openpne3
The Database Socket
Is it OK to start this task? (y/n)
y
#以下処理が流れていきます
設定が無事終わったら、パーミッションの設定を行います。
symfony openpne:permission
これでアクセス可能になります。
って簡単にいかない
順調に行けば上の通りなんですが、今回の環境ではスムーズには行きませんでした。
必要な環境はこちらに書かれています。
XSLがない
[propel-sql] Could not perform XLST transformation. Make sure PHP has been compiled/configured to support XSLT.
PHPのXSLエクステンションが入っていないらしい。
この環境のPHPはソースコンパイルでいれたものなので、ソースからエクステンションのみコンパイルします。
cd ~/php-5.2.6/ext/xsl phpize configure make sudo make install
configure途中で
configure: error: xslt-config not found. Please reinstall the libxslt>= 1.1.0 distribution
なんて出る場合は、libxsltをインストールしてから、再度configureを実行します。
sudo yum install libxslt-devel
生成されたxsl.soを読み込むようにphp.iniを編集します。
sudo vi /etc/php.ini extension=xsl.so
読み込まれたかどうかを確認します。
php -i |grep xsl xsl libxslt Version => 1.1.11 libxslt compiled against libxml Version => 2.6.16 libexslt Version => 1.1.11
これで大丈夫です。
PDOがない
Execution of target "insert-sql" failed for the following reason: /usr/local/lib/php/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/build-propel.xml:275:1: [wrapped: could not find driver] [phing] /usr/local/lib/php/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/build-propel.xml:275:1: [wrapped: could not find driver] Some problems occurred when executing the task: build-propel.xml:275:1: [wrapped: could not find driver] Read the logs to fix them
なにやら真っ赤です。
could not find driverということなので、DB接続ドライバーがないというエラーです。
symfony1.2が採用しているORMのPropelが1.3になっていて、このライブラリがpdo_mysqlを必要としています。
xslと同じ要領で
cd ~/php-5.2.6/ext/pdo_mysql phpize configure make sudo make install
入ったかどうかを確認します。
php -i |grep pdo pdo_mysql
OKです。
さらにメモリーエラー
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 35 bytes) in /usr/local/lib/php/symfony/util/sfToolkit.class.php on line 191
これは素直にメモリの作業領域が足りないので、php.iniのmemory_limitの値を大きくします。
sudo vi /etc/php.ini memory_limit = 64M
容量はメモリの許す範囲で。
番外編
openpneタスクコマンドでインストールしない方法もメモしておきます。
通常のsymfonyアプリケーションの手順になります。
DBの設定のためconfigディレクトリにdatabases.ymlを作成して、設定を書き込みます
vi config/databases.yml
all:
propel:
class: sfPropelDatabase
param:
classname: PropelPDO
dsn: mysql:dbname=openpne3;host=localhost
username: openpne3
password: password
encoding: utf8
persistent: true
pooling: true
それから同じくconfigディレクトリのpropel.iniの一部を修正します。
vi config/propel.ini
propel.database.url = mysql:dbname=openpne3;host=localhost
propel.database.password = password
propel.database.user = openpne3
propel.output.dir = {ProjectRoot}#ここにはプロジェクトのパスを
DBにスキーマーを設定します。（DDL）
symfony propel:insert-sql
初期用のデータをインサートします。（DML）
symfony propel:data-load
これで動くようになりました。
所感
symfonyは採用されているプロジェクトはちらほらあるんですが、公式サイト以外ではなかなかまとまった情報が出てこなくて、ベストプラクティスみたいなものが手探りな感じがあるので、その辺りがあぶり出てくるといいなとsymfonyユーザーとしては期待しています。
少しソースをみたところだと、sfAction→sfOpenPNE*Action→通常のActionというように、間にOpenPNE用拡張クラスを入れていて、通常のActionに手をいれやすく設計されてますね。
もう少し読んでみたいと思います。
最強のUSBメモリ
2009-01-27 01:50 | IT, 写真 | 4 コメント »最近の携帯は外部メモリーにmicroSDを採用していることが多くて、知らずにmicroSDを使っている人は結構多いと思います。
それと同時に、microSDに必ずといっていいほどついてくる、通常サイズのSDカードに変換するアダプター。
これも同じくらいの人が持ってるんじゃないかと思います。
でも、SDカードサイズになったからって、そもそもSDカードリーダーを持っている人がどのくらいいるんでしょうか。
ノートPCならまだ装備している機種もあるかもしれませんが、これはこれで、たぶんSDカードリーダがついてること自体知らない人が多いんじゃないでしょうか。
一方、PCの世界でもっとも普及しているリムーバブルメディアというとUSBメモリーで、こちらはUSBメモリーのことを「USB」って呼んじゃうくらい市民権を得ていて、この携帯の標準外部メディアのmicroSDとPCの標準外部メディアのUSBメモリーが融合したのがこの商品！
これ見つけたときは感動しました。
これはアダプターだけですけど、microSD込でUSBメモリーとして売っているものもあります。
このサイズ。microSDより一回り大きいくらいです。
カバーを取ると、ほとんどUSBの端子部分。
端子を見てみると、USBの構造をうまく利用していて、この上半分の端子の中にmicroSDを挿します。
ここに、こうやって入れてしまいます。
結構堅いんで、ビビらずにザスッと。黄色い三角の部分がイジェクト用のスライドなので、これが上がばOK。
PCに挿してみるとこんな感じ。突出部分が5mmということです。
当然、問題なく認識されます。
VistaではSDカードリーダとして認識。当り前か。
受け渡したり持ち歩くには小さすぎて不便だし、なくしたりしそうでリスキーですが、常時挿しっぱの環境では小さくて邪魔にならないし、誤って抜けたりしにくいのでリスクも少なくなります。
現在自宅サーバーでは通常サイズのUSBメモリをバックアップメディアとして使ってるんですが、蹴っ飛ばしてしまいそうで怖いんですよね。
こういう用途には最適な商品です。
Aptana Cloudがとても簡単なのでかけ足で紹介
2008-12-22 01:46 | IT, エントリー | 1 コメント »Aptana Cloudを利用してみました。
統合開発環境のAptana Studioで有名な米Aptana社が運営しているWebアプリケーションのホスティングサービスです。
AmazonのEC2よりも上位層のアプリケーションレベルのホスティングなので、Google App Engineと同等のホスティングと言えます。
Eclipseからサインアップをしてみる
EclipseにAptanaのプラグインをインストールして、My Aptanaを開きます。
サイト名（サブドメイン名）と利用方法を決めます。今回は、21日間無料トライアルを利用しました。
Aptana IDを持っていない場合は、ここでアカウントを作ります。
利用規約をよく読んで同意します。
アプリケーションサーバーの環境構築処理が始まります。
アプリケーションサーバーの構築が完了しました。
生成されたURLにアクセスすると、なんと、すでに利用可能に。
コントロールパネルから全容を把握してみる
Aptana Cloudの構築が終わると、My AptanaにMy Cloudとうタブが加わります。
Aptana Cloudへのアクセスは基本的にこのコントロールパネル上から行います。
Overview
Settings
Stats
Services
Logs
less httpd access_log
アプリケーションのデプロイ
構築はあっという間でした。
Aptana Cloudの最大のメリットはIDEとの連携、そのシームレスさにあります。
Eclipseで開発を行う場合は、そのプロジェクト単位でアプリケーションの開発をおこないますが、そのプロジェクトとCloudをシンクロさせることが可能です。
フルスタックのWebアプリケーションフレームワークを利用して開発を行う場合は、フレームワークのプロジェクト=Ecliplseのプロジェクトとすることで、このツールでシンクロし、幾つかコマンドを叩くだけですぐにアプリケーションが利用可能となります。
このスムーズさは感動的です。
ネットワークの近さをみる
pingを使ってみてみましょう。
PING ms76.aptanacloud.com (207.7.120.111): 56 data bytes 64 bytes from 207.7.120.111: icmp_seq=0 ttl=240 time=134.128 ms 64 bytes from 207.7.120.111: icmp_seq=1 ttl=240 time=121.795 ms 64 bytes from 207.7.120.111: icmp_seq=2 ttl=240 time=124.219 ms 64 bytes from 207.7.120.111: icmp_seq=3 ttl=240 time=120.803 ms
今回割り当てられたIPを逆引きをすると、207-7-120-111.joyent.comとなるので
インフラはJoyentを利用しているようです。
tracerouteでは
#snip 10 xe-3-2-0.edge1.LosAngeles9.Level3.net (4.53.228.13) 137.081 ms 112.595 ms 113.381 ms 11 ge-2-1-0-69.bbr2.LosAngeles1.Level3.net (4.68.20.2) 119.894 ms ge-3-0-0-79.bbr1.LosAngeles1.Level3.net (4.68.20.65) 112.601 ms ge-6-2-0-99.bbr1.LosAngeles1.Level3.net (4.68.20.193) 112.317 ms 12 as-2-0.mp2.SanDiego1.Level3.net (64.159.1.138) 110.432 ms as-1-0.mp1.SanDiego1.Level3.net (64.159.1.29) 117.113 ms as-2-0.mp2.SanDiego1.Level3.net (64.159.1.138) 119.620 ms 13 so-8-0.hsa2.SanDiego1.Level3.net (4.68.112.138) 122.329 ms 122.332 ms 122.253 ms 14 sd-gw01-hsa2.nextlevelinternet.com (4.79.33.246) 123.228 ms 122.413 ms 121.994 ms 15 207-7-101-53.sd.nextlevelinternet.com (207.7.101.53) 116.279 ms 116.652 ms 117.598 ms 16 207-7-100-52.sd.nextlevelinternet.com (207.7.100.52) 110.002 ms 111.936 ms 110.253 ms 17 207-7-120-111.joyent.com (207.7.120.111) 115.965 ms 115.817 ms 115.724 ms
LosAngeles、SanDiego（ルートによってはSeattle）などの地名がみえるので
サーバーは北米西海岸にある模様。
EC2よりネットワーク的に速いのは地理の要因でしょうか。
ログインしてシステムをみる
なんとSSHでシェルにも入れます。
__ __ __ ___ ____ / /____ ____ ___ _ ____/ /__ __ _____/ / / _ `/ _ \/ __/ _ `/ _ \/ _ `/ / __/ / _ \/ // / _ / \_,_/ .__/\__/\_,_/_//_/\_,_/ \__/_/\___/\_,_/\_,_/ /_/ Welcome to ms76.aptanacloud.com! /!\ Warning! SSH access to Aptana Cloud is provided pursuant to the Aptana Cloud Terms of Service. See http://www.aptana.com/cloud/tos for important information related to your access to various areas of your Cloud Site. Aptana does not warrant any Services modified by you via SSH, nor will we be obligated to support fixing problems that may arise as a result of such modifications.
無事ログイン。
まずはunameをチェック。
-bash-3.2$ uname -a SunOS 9a2640a1.joyent.us 5.11 snv_89 i86pc i386 i86pc
もうちょっと詳しく。
-bash-3.2$ cat /etc/release Solaris Nevada snv_67 X86 Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 18 June 2007
-bash-3.2$ cat /var/sadm/system/admin/INST_RELEASE OS=Solaris VERSION=11 REV=0
Solaris Nevadaということがわかります。
続いてハードウェアをチェックしてみます。
メモリ
-bash-3.2$ /etc/prtconf System Configuration: Sun Microsystems i86pc Memory size: 32763 Megabytes System Peripherals (Software Nodes):
CPU
-bash-3.2$ /usr/sbin/psrinfo -v Status of virtual processor 0 as of: 12/18/2008 15:57:29 on-line since 10/03/2008 03:21:40. The i386 processor operates at 2660 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 12/18/2008 15:57:29 on-line since 10/03/2008 03:21:42. The i386 processor operates at 2660 MHz, and has an i387 compatible floating point processor. #snip Status of virtual processor 6 as of: 12/18/2008 15:57:29 on-line since 10/03/2008 03:21:42. The i386 processor operates at 2660 MHz, and has an i387 compatible floating point processor. Status of virtual processor 7 as of: 12/18/2008 15:57:29 on-line since 10/03/2008 03:21:42. The i386 processor operates at 2660 MHz, and has an i387 compatible floating point processor.
ディスク
-bash-3.2$ df -h
Filesystem size used avail capacity Mounted on
/ 0K 2.1G 4.9G 30% /
/dev 0K 0K 0K 0% /dev
/lib 2.0G 505M 1.4G 26% /lib
/platform 2.0G 505M 1.4G 26% /platform
/sbin 2.0G 505M 1.4G 26% /sbin
/usr 3.9G 888M 3.0G 23% /usr
proc 0K 0K 0K 0% /proc
ctfs 0K 0K 0K 0% /system/contract
mnttab 0K 0K 0K 0% /etc/mnttab
objfs 0K 0K 0K 0% /system/object
swap 72G 176K 72G 1% /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1
3.9G 888M 3.0G 23% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 256M 96K 256M 1% /tmp
swap 72G 12K 72G 1% /var/run
8つのCPU、32GBのRAMを仮想サーバー（Solaris コンテナ）でシェアしている模様。
この当たりはもともとJoyentの仕様っぽいですね。
すぐに使える言語やサービスをみる
Webアプリケーションに利用する言語やミドルウェアをチェックしてみましょう。
Ruby
-bash-3.2$ ruby -v ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-solaris2] -bash-3.2$ gem -v 1.3.1 -bash-3.2$ rails -v Rails 2.2.2
PHP
-bash-3.2$ php -v PHP 5.2.5 (cli) (built: Feb 4 2008 23:39:26) -bash-3.2$ pear info pear Packaged With PEAR 1.5.4
Perl
-bash-3.2$ perl -v This is perl, v5.8.8 built for i386-solaris-thread-multi -bash-3.2$ cpan -v cpan script version 1.03 CPAN.pm version 1.7602
Java
-bash-3.2$ java -Xmx32m -version java version "1.6.0_06" Java(TM) Platform, Standard Edition for Business (build 1.6.0_06-b02) Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
Python
-bash-3.2$ python -V Python 2.4.4
Apache
-bash-3.2$ apachectl -v Server version: Apache/2.2.8 (Unix) Server built: Feb 4 2008 23:16:59
MySQL
-bash-3.2$ mysql -V mysql Ver 14.12 Distrib 5.0.51, for sun-solaris2 (i386) using readline 5.2
PostgreSQL(未起動)
psql (PostgreSQL) 8.2.6 contains support for command-line editing
SQLite
-bash-3.2$ sqlite -version 2.8.16
この辺りはEC2と違ってはじめから全部入りの模様です。
Google App Engineが現在はPythonのみをサポートしていることを考えると、対象の開発者は絶対的に多いはずです。
しかし、逆にメモリが苦しいからPHP外したいとか、passengerではなくmongrelで動かしたいとかいうワガママは通らないようです。
自分のドメインで利用する
Aptana Cloudを構築するとサブドメインとグローバルなIPアドレスが振られます。
なので、DNSでAレコード、もしくはCNAMEレコードを設定するだけです。
この辺りはFAQに載っています。
追記
12/22 13:40 タイトル変更しました。
12/22 13:40 タイトル変更しました。
Amazon CloudFrontを体験してみた
2008-12-15 01:30 | IT, エントリー | 1 コメント »遅くなりましたが、CloudFrontを体験してみました。
実験の前に参考サイト
CloudFrontの設定方法や、ダウンロードのベンチマークなどは以下のサイトを参考にしましょう。（と丸投げ）
- AmazonS3上のファイルを国内でも高速配信可能なAmazon CloudFrontリリース : Media Technology Labs (MTL) : メディアテクノロジーラボ ブログ
- Amazonの従量課金制CDNサービス「Amazon CloudFront」を使う方法 – RX-7乗りの適当な日々
実験の方法
今回やりたかったことは、ブラウザーを使って普通にブラウジングをしてみて、体感を測ることです。
- HTMLファイル 1
- JSファイル 5
- CSSファイル 2
- 画像ファイル 25
合計33ファイル、163KBのページを表示して、ページがロードされる具合を体感してみました。
EC2単体で体感実験
まずは、全てをEC2のスモールインスタンス上にアップした状態で体感。
Apacheは2.2.9、設定はrpmのデフォルト。KeepAliveはOFF。
やはりもっさり感は否めません。（4.6秒）
CloudFrontで体感実験
では1のHTML以外をS3にアップロードして、CloudFront経由で体感してみます。
これは明らかに速い（1.16秒）。EC2の場合は「ただいま画像1つ1つをロードしてます」って感じで画像が描画されるまでもたもたしていましたが、CloudFront経由の場合はページのロードと同時に画像も描画されました。
Etagもきっちり返してくれるので2回目以降のアクセスには304が返ってきますし、gzipを利用したhttp圧縮も行われているので、cssやjsなどのテキストファイルは効率よく転送されるはずです。
ただし、最初のアクセス時はキャッシュサーバーにデータが届いていないため、キャッシュする為にS3サーバーからの転送時間が加わるので、もっさり感を感じます。2回目はX-Cacheヘッダーが上画像のように変わります。
まとめ
実に簡単な体感実験ですが、CloudFrontの実力は歴然でした。
イメージサーバなどの用途で静的なファイルを負荷分散をするサーバーを立てるケースを想定すると、アクセス急増時にロードバランサー配下のリアルサーバーを増やしたり、静的なファイルを共有する、もしくは分散する仕掛けを用意したり、トラッフィクに注意したり、メンテナンスと運用にかかる時間と人のリソースは、想像に難しくありません。
上記のような心配が必要なサービスを運用している会社さんの場合は、当然既にakamaiなどのCDNを利用していると思いますが、それでもファイル転送元のリアルサーバーは持っている必要があります。
CloudFrontの場合は、配信元サーバーがS3なので、そこのリソースも気にしなくて済みます。
社内でかかるメンテナンスコスト（ベンダー保守、社内保守・監視、対応）、電気代、帯域代、ラック代、サーバー代など様々なコストを考えると、すべて込み込みで1GB/30円っていうのはかなり魅力的ではないでしょうか。
EC2用にCentOS5.2のAMIを作ってみた
2008-12-01 01:33 | IT, エントリー | 3 コメント »CloudFrontで生まれ変わるか
EC2は日本からだと相変わらず帯域がもっさりしているんですが、Amazon CloudFrontがリリースされて、利用方法を工夫すれば、まともに使えるのでは？と俄然注目です。
CloudFrontはS3上に配置したファイルを展開するCDNで、しかもキャッシュサーバーが日本国内にもあるので、静的なコンテンツはCloudFrontで配信、動的なコンテンツはEC2で配信と分散すれば体感はだいぶ速くなるんじゃないでしょうか。
Amazon Machine Image(AIM)を作る
その実験に先立って、いざという時に安心して使えるEC2用のイメージを持っておこうと思い、使い慣れているCentOSのオリジナルイメージを作ってみました。
作成したイメージファイルを圧縮・分割してS3上に置いた上で、EC2にAIMとして登録を行うと、いつでもそのイメージファイルからインスタンス（サーバー）が起動できるようになります。
当然S3に保管しておくのに料金がかかりますが、月$0.15/GBなので、圧縮したイメージファイルが一つ500Mくらいですから、毎月$0.05（5円）程度ととても経済的です。
（実際、毎月のクレジットの明細にきっちり$0.05が請求されています。請求の手間の方がかかるような気が）
【参考】
RightScaleがCentOSのイメージを公開しているので、それでも問題ない場合はそれを利用した方が楽です。
ami-1363877a rightscale_images/CentOS5_2V4_0_2_Beta.manifest.xml
大まかな流れは
- 空のimgファイルにyumを使ってOSをインストールし、AMI用に各種設定を行う
- S3にアップロードする前にimgファイルを分割してマニフェスト（xmlの設定ファイル）を作る
- 分割したimgファイルとマニフェストをS3にアップロードする
- アップロードしたimgを自分のAMIとしてEC2に登録する
参考にしたサイト
とてもよくまとまっています。
ここを参考に作業を進めていけば、かなりスムーズにいきます。
なので、ここでは環境の問題などで詰まった部分や補足を説明します。
AMI tools は ruby が必要
EC2用のコマンドツール群はEC2のインスタンスを立ち上げたり、情報を取得したり、操作をしたりするec2-api-toolsと今回利用するAMIを作成したり、アップロードしたりするec2-ami-toolsがあります。
後者はrubyが必須で、前者はJava VMが必須です。
yum で 作ったイメージに CentOS 5 をインストールする
ここでyumのgroupinstallオプションでインストールをするわけですが、最初CentOS4.6上で作業した時にはここで躓きました。yumのバージョンが全然違うので、当たり前っていえば当たり前です。
CentOS5のイメージを作成する際に利用する作業マシンのOSはyum > 3 のものを利用しましょう。
（CentOS4系にyum3系インストールするのは依存関係が半端無く、萎えますのであきらめましょう。）
アップロード
ec2-upload-bundleコマンドでアップロードします。
今回はWindows Vista上のVMWareのゲストOS（CentOS5）で作成、そのままアップロードを行いました。
が、VMWare上ではゲストOSの時刻が狂うという問題がありまして、アップロード中にサーバー（S3）の時刻とクライアントの時刻が狂っているとエラーが発生し、正常にアップロードできません。
最終的には、S3Foxを使って手作業でアップロードして、該当するbucketのACLを修正して対応しました。
ACLの設定は「za-team」ユーザーにRead権限を与えます。
以降はスムーズに行くと思います。
インスタンスを立ち上げた後
無事立ち上がった後、このイメージをベースにするため、自分で利用しやすいように環境を整えます。
いきなりhttpdやpostfixなどミドルウェアを入れにいってもいいのですが、どんなサーバーに利用しても必要となる最低限の環境を整えることが今回の目的なので、
ユーザーの作成や、sysstatのインストール、yumレポジトリの追加を行いました。
ベース環境の設定が終わったら、今度はこのインスタンスをイメージ化するため、インスタンス上にprivatekeyファイルとcertificateファイルをコピーして、
ruby、ec2-ami-toolsのインストールからS3へのアップロード、EC2への登録まで、全く同じ手順で行います。
作業の途中、「ec2-bundle-vol」コマンドがエラーで止まってしまうはずなので、
こちらを参考に、EC2カーネル用モジュールをコピーして、依存を修正します。
これでようやく汎用的なマイイメージが出来上がりです。
今後はこれにhttpdを入れればWebサーバに、PerlやPHPを入れてAPサーバーに、MySQLやPostgreSQLを入れてDBサーバーにと、ベースのインスタンスを拡張していろいろな用途のサーバーを自由に、いつでも用意できるようになります。
次回はこのインスタンスを使って、Webサーバーを立てて、CloudFrontの実用性を検証してみたいと思います。
