S3: S3のアクセスログ
S3には、Server Access Loggingという機能がある。バケツ単位で設定して、有効化しているバケツのオブジェクトにアクセスした場合、指定した別のバケツにアクセスログが保存される。（デフォルトは無効）
アクセスログのフォーマットはこちら。
この機能、現時点(2012年6月)ではBetaであることもあり、ログの集約はベストエフォートの設計となっている。そのため、すべてのアクセスログが完全に保存することは保証されていない。
http://docs.amazonwebservices.com/AmazonS3/latest/dev/LogDelivery.html
S3: 課金の算出とタイミング
S3やEBSの単価は 1GB/month でいくら、となっている。
では、計算をどうやっているか？
Q: Amazon S3 を利用すると、どのようにして課金され、請求されますか？
http://aws.amazon.com/jp/s3/faqs/#How_will_I_be_charged_and_billed_for_my_use_of_Amazon_S3
1ヵ月に請求されるストレージの GB は、月全体を通じて使用される平均ストレージです。これには、お客様のアカウントで、お客様が作成したバケット内に格納されるすべてのオブジェクトデータやメタデータが含まれます。当社は「TimedStorage-ByteHrs」で、お客様の使用量を測定します。これは月末に加算され、お客様の月額料金が生成されます。
とのことで、平均使用量を基に算出される。
ちなみに、請求のタイミングは月単位の課金サービスについては、月末締めとなる。
訳:DynamoDB:SSD Hot S3 Cold パターン
DynamoDBのベストプラクティス的なパターン
High Scalability - High Scalability - DynamoDB Talk Notes and the SSD Hot S3 Cold Pattern
＝＝＝＝
Amazon DynamoDB for Developersトークに参加する前の、DynamoDBに対する印象は、シンプル・速い・スケーラブル・地理的冗長性・使うには高い・運用不要、という、Amazonのいつもの品質のサービスだった。
トークの後、印象はより微妙(nuanced)になった。品質の印象はそのまま。フォーラムを見れば、すべてのプロダクトに典型的な問題があることがわかるが、それは驚きではない。SimpleDBの発展版( SimpleDB++)として、DYnamoDBはセカンドシステム症候群を避けて、もっとエレガントな設計を作ったように見える。
驚いたのは、DynamoDBがとても非クラウド的だったことだ。従量課金モデルと、バーストトラフィックに対して素早く柔軟に対応するというクラウドの柱が捨てられ、DynamoDBを作る前に使い方を考える必要があることだ。
トークの中で感じたことは、、、、
- DynamoDBは Key-Valueデータの地位を明らかにした 。インターフェースは簡潔で、CreateTable, PutItem, BatchWriteItem, GetItem, Scan, Queryのように操作に一貫性がある。バッチ書き込みはトランザクションがサポートされていない。アクセスは、主キー、もしくは、ハッシュキーとレンジキーの複合で行う。データの最大サイズは64KB。スキーマレス。対応する型は、文字列型と数値型、そしてその集合(set)。読み込みは整合性有り、もしくは無しが可能で、書き込みは常に整合性有りで、整合性有りの読み込みは2倍のコストになる。
- 操作は通常10msec以下で、だいたい3-4msec。だいたいネットワークで1.5msec以下、データベース処理で1.5msec以下で、データサイズに依存する。顧客は 1-2msecの応答時間を要求するのでAmazonはストレージにSSDを使うという革命的な手段を選んだ。はじめはSSDのガベージコレクション周期に起因する性能問題があった。ベンダーとの広範な作業により問題は解決したが、知財の事情で、どのようにやったかはわかならい。
- プロビジョンスループットモデル。 DynamoDBの最も革新的な機能であり、最も不確かであり、簡潔なAppleの設計美学である。プログラマはアプリケーションが必要になるだけのデータベースへの秒間リクエスト数を指定する担当である。DynamoDBが残りを請け負う。要求された性能を実現するためにデータを自動で多くのサーバに分散する。実行中(on the fly)にレートを変更できるが、新しく要求するレートをサポートするまでには最大10分必要になる。
- 騒音隣人問題を解決する。クラウドの問題は、うるさい隣人が他の隣人の性能に影響を及ぼす可能性があること。DynamoDBがマルチテナント環境でSLAを順守するために、格納する値の最大サイズ64KBという制限を設けた。更に、1KBのデータを1回読み(書き)するのを Read/Writeキャパシティの単位としてリクエストが課金される。データサイズを固定し、スループットレートを保証するための仕様を決めるすることで、負荷をスケジュールために必要な情報を得た。
- 従量課金ではない。プロビジョンスループットモデルの反面、実際に発生したトラフィックに対して支払う代わりに、確保したスループットに対して支払うことになる。Amazonの見方(perspective)だと、キャパシティを確保しているのだからある程度キャパシティを使っている、ということだが、クラウドの弾力的な素性が生み出すキャパシティ計画問題が同じように発生する。正しいスループットをどうやって弾きだすか？下回れば、顧客を失う。上回ればお金を失う。トラフィックがバーストしがちなら、ピーク時のスループットで年中確保しなければならない。スループットを調整できるが、バーストに合わせられるほど素早く調整できないし、drop通知のメカニズムもイケてなく(clumsy)て、メールでアラートを受け取ったら手動で調整する必要がある。
- イケてる機能たち。 DynamoDBは、インクリメント操作と CAS( compare-and-swap)をサポートしており、両方ともとても便利である。
- 運用不要(NoOp)ではない。開発者を助けるために腕利きは残る。 DynamoDBの運用は残るが、領域が違ってくるだろう
-
- トランザクションが無い。開発者は冪等性(idempotency)、ガベージコレクション、その他DynamoDBがサポートすべき機能を実装する必要がある。例えば、セカンダリインデックスや検索がサポートされておらず、難しく、直接システムがサポートされt無いのであれば実装にエラーが入りやすくなる。
- ホットキー・ホットパーティションがサポートされてない。プロビジョンモデルは自動ではないので、ホットキーも自動で負荷分散しない。特定のキーやパーティションに対する読み込みが大量にあると、プログラマーがその問題を修復する必要があり、DynamoDBは何もしない。NoOpは通用しない。
- バックアップをサポートしていない。データをバックアップするには、Hadoopを使う必要がある。これは解決される問題らしいが、現時点では抜けている。
- 64KB以上のデータ。 64KB以上のデータを保存するトリックは、スループットの性能低下を引き起こす。
- データ閲覧にHiveを使う。 DynamoDBは巨大なデータ集合をターゲットにしているので、データを見るには Hadoop/Hiveを使う。そのうち、より便利な機能がダッシュボードに実装されるだろうが。。
ホットデータはDynamoDBにコールドデータはS3に、そして同じように見るためにHadoop/Hiveを使え
最も興味深い考えの一つは、DynamoDBとS3をつなぐ新しいエコシステムとしてHadoop/Hiveがとても機能しているということ。DynamoDBに保存されているデータのコストはS3よりも10倍高いので、古いデータやコールドデータはできる限りS3に移してほっとデータのみDynamoDBにおいておきたい。例えば、時系列データはだいたい、日・週・月単位で保存されるが、すべてのデータをDynamoDBに保存するのではなく、S3に移してコストを削減する。
問題は、データにアクセスする方法が大きく異なること。DynamoDBは純粋にテーブル経由のプログラム的アクセスだが、S3はファイル経由である。コードの修正を少なくしてどのようにこの差異を埋めるか？
EMRとHiveの洗練されたクエリを使うことでDynamoDBとS3のデータを共通のアクセスレイヤで実行可能になる。強力なエコシステムを提供する上でこのようにツールが使えることは良い例になる。
S3: PHPで バケツの一覧を取得する
Amazon LinuxへのPHPとAWS SDK for PHPのセットアップ
$ sudo yum install php php-pear php-xml $ sudo pear channel-discover pear.amazonwebservices.com $ sudo pear instlal aws/sdk
一覧のコード
＜?php error_reporting(E_ALL); require_once '/usr/share/pear/AWSSDKforPHP/sdk.class.php'; ## prepare credential data $credential = array( // set access key id 'key' => 'AKIAIUEYQ', // set secret access key 'secret' => 'GEhkVzpvw' ); ## create S3 client $s3 = new AmazonS3($credential); $s3->set_region(AmazonS3::REGION_TOKYO); ## get buckets list $res = $s3->list_buckets(); $buckets = $res->body->Buckets->Bucket; ## print result foreach($buckets as $b ){ print($b->Name."\n"); } ?＞
を list_buckets.php として保存したあと
$ php list_buckets.php
とすると、バケツの一覧が表示される
EC2: S3に画像アップロードするPHPサンプルを作る
パッケージ追加
$ sudo yum install php httpd mysql mysql-server php-mysql php-pear php-xml
$ sudo pear channel-discover pear.amazonwebservices.com $ sudo pear install aws/sdk
セキュリティ設定
$ sudo cp /usr/share/pear/AWSSDKforPHP/config-sample.inc.php /usr/share/pear/AWSSDKforPHP/config.inc.php $ sudo vi /usr/share/pear/AWSSDKforPHP/config.inc.php $ sudo diff /usr/share/pear/AWSSDKforPHP/config-sample.inc.php /usr/share/pear/AWSSDKforPHP/config.inc.php 57c57 < 'key' => 'development-key', --- > 'key' => 'xxxxx', 61c61 < 'secret' => 'development-secret', --- > 'secret' => 'xxxxx',
サーバ起動
$ sudo /etc/init.d/httpd start
ファイルアップロードの準備
$ sudo mkdir /var/www/html/images/ $ sudo chmod -R 777 /var/www/html/images
ファイルのデプロイ
$ cd /var/www/html/ $ git clone git@github.com:understeer/aws.git
- form_upload.php: アップロードのフォームページ
- upload.php: ローカル(/var/www/html/images/)に上げる
- s3upload.php: S3に上げる
- https://github.com/understeer/aws/tree/master/php/s3
EC2： Linuxのバックアップとリカバリ
Backup and Recovery for Linux With Amazon S3
View more presentations from Amazon Web Services
ちなみに、DR関連の資料
CF : アクセス制限をつけてCDN配信する方法
CDPのパターンがある。
CDP:Private Cache Distributionパターン - AWS-CloudDesignPattern
アバウトな手順は
0.S3のバケットに対して、
CFからしかアクセス受けないような設定をしておく
→CFのAPI叩いて設定必要
1.Webサーバ(EC2)等で特定のユーザ向けに、
一部が暗号化(正しくは署名)されたURLを生成する
・特定のユーザといいつつも「接続元IPアドレス」「URLの有効期間」にて指定
・Webサーバには秘密鍵登録して、URL生成ロジックを実装しておくこと
2.エンドユーザは指定されたURLにアクセス
3.CFはあらかじめ登録してある公開鍵でURLを復号(正しくは署名検証)
IPアドレスや有効期限チェックしてOKなら該当のファイルを返却
・Webコンソールのアカウント管理>セキュリティ証明書に、
CF用のキーペアを設定できる箇所がある
＝＝＝＝
リファレンスドキュメントはこちら。
