2015年5月25日

S3 の使用量を確認する方法

S3 を使っている場合、今どの程度の容量を使用しているか気になることはありませんか。

リージョン全体の月あたりのサイズであれば、請求書で確認することができます。バケット単位で見るにはタグをつけてコスト配分レポートを使えばわかりそうです。

毎月のコスト配分レポートの設定
http://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/configurecostallocreport.html


しかし、これでは現時点での使用量は確認できません。

AWS CLI の S3 コマンド の ls に summarize というオプションが追加されていました。

AWS CLI s3 ls
http://docs.aws.amazon.com/cli/latest/reference/s3/ls.html


summarize を指定すると、オブジェクト数や合計サイズが出力されます。
recursive を併用することで、"ディレクトリ" 配下のオブジェクトも合計に含めることができますし、human-readable を使うとファイルサイズが Bytes/MiB/KiB/GiB/TiB/PiB/EiB で表示されます。

$ aws s3 ls s3://mybucket --recursive --human-readable --summarize
(オブジェクトの一覧が出力)

Total Objects: 14182
Total Size: 4.1 GiB

S3 の API には合計を出力するものは無いと思うので、単に取得したオブジェクトのリストを内部的にカウントしてくれているだけだと思いますが、余計なひと手間がいらなくなりました。

これは便利ですね!

2015年5月20日

General Purpose (SSD) Volumes を使うときの注意

General Purpose (SSD) Volumesをデフォルトで使ううよう勧められるため、ほとんどGeneral Purpose (SSD) Volumesばかり使っています。

しかしながらGeneral Purpose (SSD) Volumesには落とし穴があります。

ドキュメントを見てみましょう。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#EBSVolumeTypes_gp2
ベースラインパフォーマンスの I/O レベルよりも高いレベルがボリュームで必要となる場合は、クレジットバランスの I/O クレジットを使用して、必要なパフォーマンスレベルまでバーストします(最大レベルは 3,000 IOPS です)。

I/O クレジットバランスが空になったらどうなりますか。

ボリュームがすべての I/O クレジットバランスを使用した場合、I/O デマンドがベースラインレベルを下回り、未使用のクレジットが I/O クレジットバランスに追加されるまで、ボリュームの最大 IOPS パフォーマンスはベースライン IOPS パフォーマンスレベル(ボリュームがクレジットを取得するレート)のままになり、スループットの限界はベースライン IOPS に最大スループットを乗算して 3,000 で除算した値まで下がります。

つまり8GBのEBSを使う場合、ベースラインである24IOPSを超える場合にはクレジットを消費します。
そして、クレジットが尽きた場合には24IOPSとなってしまいます。また、スループットも 128 * 24 / 3000 = 1.024 MiB/秒になります。
これはマグネティック ボリュームの平均 100 IOPS、最大スループット 40 ~ 90 MiB/秒よりも著しく小さいです。

こんなディスクでは使い物にならないですね。。。
スナップショットをとって新しいボリュームに作り直しましょう。
待つよりも初期クレジットをもらったほうが手っ取り早そうです。

各ボリュームは、初期 I/O クレジットバランス(5,400,000 I/O クレジット)を受け取ります。

継続的にIOが発生する場合にはもっとサイズを大きくするか、Provisioned IOPS (SSD)を使ったほうが良さそうですね。


ところで、General Purpose (SSD) Volumesにデフラグとかウィルススキャンかけたらどうなるんですかね。。。

2014年9月27日

Java SDKでリージョンを判断する方法

AWS Java Development Blog にリージョンを判断する方法が Post されていました。

API を呼び出すときは通常リージョンを指定する必要があります。
通常はリージョンをハードコーディングしたり、プロパティファイルに設定していますでしょうか?

こちらを動的にリージョンを判断することで、どのリージョンにデプロイしてもそのリージョンに限定した API を実行することができます。
たとえば東京リージョンのバックアップとしてシンガポールリージョンで動かそうとする場合、東京リージョンの API を呼び出すと意味が無くなります。

方法としてはブログにある通り、com.amazonaws.regions.Regions#getCurrentRegion() を呼び出すことになります。

Regions クラスのソースを確認すると、com.amazonaws.regions.EC2MetadataUtils#getInstanceInfo() を呼び出しています。
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/regions/Regions.java

こちらを見ると、EC2 のメタデータ http://169.254.169.254//latest/dynamic/instance-identity/document/ から取得できる json の region を取得しているようです。
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/util/EC2MetadataUtils.java

EC2 の MetaData はこんな感じで確認できます。確かに region がありますね。

$ curl 169.254.169.254/latest/dynamic/instance-identity/document/
{
"instanceId" : "i-12345678",
"billingProducts" : null,
"imageId" : "ami-12345678",
"pendingTime" : "2014-09-31T24:00:00Z",
"instanceType" : "t2.micro",
"architecture" : "x86_64",
"accountId" : "123456789012",
"ramdiskId" : null,
"kernelId" : "aki-12345678",
"region" : "ap-northeast-1",
"version" : "2010-08-31",
"privateIp" : "10.0.0.10",
"availabilityZone" : "ap-northeast-1c",
"devpayProductCodes" : null
}

JavaDoc に EC2 インスタンス上ではない場所で実行した場合には null となります。
これはインスタンスのメタデータが取れないからです。

これを活用してマルチリージョンでのデプロイを楽しみましょう~