Hatena::ブログ(Diary)

akihitoの日記 RSSフィード

2009-02-04

Amazon S3使ってみた

今更ながら使ってみた。

Amazon Simple Storage Service

サーバのDiskが週に1Gとか日に1Gとか普通に埋まっていくのでなんとかしたい。

概念的に増やしたい!願ったり感じたり信じたりすると増えるみたいのが欲しい。

容量とか気にしなくて良いし、物理的に増設していくのも疲れるからね。

実際に使ってみる

S3Foxを使ってブラウザで管理。S3Foxでファイルの追加とかもできるけど、めんどくさいのでそこはCUIで!

Amazon S3用のコマンドラインツールs3cmd

s3cmd --configure
# ...いろいろ設定...

s3cmd ls
s3cmd ls s3://hoge
s3cmd put test.csv s3://hoge

こんなURLでアクセスできる。

http://hoge.s3.amazonaws.com/test.csv

以下をTrueにしておくと誰でも閲覧可能に

$ vim .s3cfg 
acl_public = True

さくさく動いて楽しいかも。

ApacheBenchとってみた

他でも計測している人がいましたが一応。1.15Mのファイルを"ab -n 100 -c 10"で計測

$ ab -n 100 -c 10 http://hoge.s3.amazonaws.com/test.csv
:
Document Length:        1214170 bytes

Concurrency Level:      10
Time taken for tests:   76.210336 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      121456000 bytes
HTML transferred:       121417000 bytes
Requests per second:    1.31 [#/sec] (mean)
Time per request:       7621.033 [ms] (mean)
Time per request:       762.103 [ms] (mean, across all concurrent requests)
Transfer rate:          1556.34 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      138  153  13.4    162     172
Processing:  2112 7149 1347.2   7362    9166
Waiting:      146  167  16.2    171     207
Total:       2284 7303 1351.6   7502    9336

Amazon CloudFrontも使ってみました。同様に計測

CloudFront

$ ab -n 100 -c 10 http://xxxxxx.cloudfront.net/text.csv
:
Document Length:        1214170 bytes

Concurrency Level:      10
Time taken for tests:   24.979753 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      121474600 bytes
HTML transferred:       121417000 bytes
Requests per second:    4.00 [#/sec] (mean)
Time per request:       2497.975 [ms] (mean)
Time per request:       249.798 [ms] (mean, across all concurrent requests)
Transfer rate:          4748.93 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       23   72 300.8     41    3046
Processing:   442 2354 2155.8   1244    8813
Waiting:       24   57  59.1     43     349
Total:        467 2427 2202.8   1270    8836

時間や混みぐあいで変わってくるようですが、どうでしょう。

2009-01-03

トラブルに強いWebアプリケーション

個人的にですが、Webアプリケーションを作るときに注意していることです。

URLとクラスのマッピング

URLとそこで操作するクラスの名称を一致させたり、似た名前にしておくと色々よい事があります。

  • ユーザ情報を表示するURL
 http://example/user/akihito/profile
  • ユーザ情報を取得するクラス(ユーザ情報を表示するときに使用)
 user = new User('akihito');
 user.profile.age;
 user.profile.email;

つまりURLとクラスがマッピングするように設計しておくわけです

 /user/akihito/prfile  <=>  user(akihito).profile
 # ユーザ情報の更新
 /user/akihito/prfile/update  <=>  user(akihito).profile.update({age=>99})
 # ユーザの削除
 /user/akihito/delete  <=>  user(akihito).delete()

こうしておくとトラブルやバグに遭遇したときに問題箇所が特定しやすくなります。

また、update,deleteの名称をURLに含めることで更新系の操作を別サーバに振り分ける布石にもなります。

例外処理

例外処理には例外オブジェクトを使用することをお勧めします。

PHPであれば標準のException,try,catch、PerlであればException::Class,eval,$EVAL_ERROR($@)があります。フレームワークが提供している例外クラスを使うのもいいですね。

下層のクラスで"throw Exception"しておけば、上層クラスで補足することができます。例外処理を標準化して、チーム全体で統一したエラー処理を行うようにしておきましょう。

ログ

参照系の操作なのにPOSTメソッドを使ってクエリーをアクセスログからなくしてしまうのは非常に残念なことです。

 http://example/search
 http://example/search?q=hoge

例外処理のエラーメッセージや場合によってはPOSTメソッドのクエリーをエラーログ等に吐き出しておくのもいいですね。ユーザの動きが非常に追いやすくなります

セッション

セッションに入れた値は可読性が失われます。また経路によってセッションデータを書き換えるような設計はトラブルの元になります。

自分はセッションに何を入れるかは、どちらかといえば慎重派です。小さいセッションで最大の効果を得られるようにすべきです。


まとめ

トラブルやバグには必ずあります、少なくすることはできますが、なくなる事はないです。

遭遇したときに問題箇所を特定し修復できるように事前に準備しておくことが、トラブルに強いWebアプリケーションだと思います。

2008-12-31

良いお年を〜

絶賛放置プレイ中のこのブログですが、来年もよろしくお願いします。

今月こっそりアップしたモジュールですが、そのうち何処かのブログで解説したいですね。

http://search.cpan.org/~akihito/File-Stat-Trigger/