Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2012年09月27日

EBSブートのAMIのEBS容量変更時の注意点

みなさん、こんにちは!フリューでモバイルサイト開発を行っているAWS大好きっ子の鷲見といいます。

今回はAWSのTIPSを1つ。

今年の7月後半にAWSのManagementConsoleでEBSブートのAMIのEBS容量を指定して起動することが出来るようになりました。

今まではManagementConsoleからはAMIごとに異なるデフォルトの容量でしか起動できず、EBS容量を変更するにはAPIを操作して起動する必要がありました。

これはかなり便利になったと思うのですが、一つだけ落とし穴があります。

起動した直後はEBSの容量の変更が認識されていないため、AMI毎に指定されている容量しか認識できていません。実際にdfコマンドを使って確認すると下のようになります。

上の画像の通り、20GiBを指定して作成したのですが、このAMIで元々指定されている8GiBしか認識されていません。

というわけでresize2fsコマンドを実行して、サイズの変更を認識させます。

上の例のAmazon Linuxの場合は以下のとおりとなります。

resize2fsコマンドの実行完了後に再び容量を確認してみます。

無事、容量が20GiBと正しく認識されました。

というわけでEBSブートのAMIのEBS容量変更時はresize2fsを忘れずに!

ちなみに実行中は少し負荷がかかる上、容量が大きくなると実行完了まで時間もかかるので、既に利用中のEC2インスタンスでは、タイミングを考慮して実行するようにしてください。

以上、AWS TIPSでした。


2012年09月12日

いしはら

デジタルハリウッド大阪校で講演をおこないます

ソフトウェア開発部の、いしはらです。
9月23日(日)にデジタルハリウッド大阪校が開催する
「デジタルストリーム 2012 OSAKA」にて講演をおこなうことになりました!

デジタルストリームとは?

デジタルストリーム 2012 OSAKA

「フォトグラフィック講座」「デジタルメディア概論」「Webクリエイター女子対談」など、デザイン&デジタルを1日で丸ごと体験できるイベントです


私は「Webクリエイター女子対談」で、Web業界の女性の働き方についてお話します。
弊社についてもお話する予定なので、「Web業界で働きたい!」
「フリューでどんな仕事をするのか知りたい!」
という方は是非ご参加ください。参加は無料です。
詳細はこちら


2012年09月4日

Amazon Glacierを使ってみた

みなさん、こんにちは!フリューでモバイルサイト開発を行っている鷲見といいます。今日はAWSの新しいサービスAmazon Glacierについて実際に触れて検証してみたのでその報告をしてみたいと思います。


Amazon Glacierとは

Amazon Glacier(以下、Glacier)とは2012年8月21日にAWSが発表した低コストなストレージサービスです。低コストと言われている通りなんと1GBあたり月額約1円($0.012/GB)で利用することができます。今まで安いと思っていたS3が1GBあたり約10円(最初の1TBまで$0.13/GB)なのでなんと、S3の10分の1程度のお値段で利用できます。まさに価格破壊のストレージサービスです。

ちなみに上記以外にはファイルのアップロード、ダウンロード、アーカイブデータの一覧取得のリクエストの回数に応じてお金がかかるのと、転送量に応じてお金がかかります。

ちなみに読み方は『グレイシャー』だそうです。


S3との違い

S3の約10分の1のお値段で利用できるならGlacierを使えばいいじゃんと思ってしまいそうです。S3とGlacierはどう違うのでしょうか?

GlacierのS3との違い

GlacierがS3と比べて違う点は

  1. ファイルのダウンロードを開始できるようになるまで時間がかかる
  2. 好きなファイル名をつけることはできずArchiveIdで管理される

の2点です。

特に1つ目の点がS3と違う大きな特徴です。

Glacierでは、ファイルの取得のためにジョブと呼ばれるものを開始します。ジョブはキューに保存され順番に処理が行われます。ジョブがキューから取り出され実行されて完了すると、ファイルがダウンロード出来るようになります。このファイルがダウンロードが出来るようになるまでの時間が4,5時間と言われています。

2つ目の特徴ですが、ファイルのアップロード時にArchiveIdと呼ばれるIDが付与されます。アップロード完了後、ファイルの取得・消去の際にはこのArchiveIdを指定する必要があります。よってこのArchiveIdがどのようなファイルと紐付けられているかを管理する必要がでてきます。

S3との使い分け

上記のようなGlacierの特徴を考えると、Glacierには頻繁に出し入れが発生するファイル、すぐにダウンロードできないと困るようなファイルはGlacierでの保存に向いていません。このようなデータは今までどおりS3に保存するべきでしょう。

逆に一度保存すると出し入れがほとんど発生しない、ダウンロードするのに時間がかかってもよいようなデータはGlacierでの保存に向いています。各種データのバックアップ・アーカイブなどのコールドデータの保存にはGlacierが向いています。

Glacierという名前は英語で「氷河」なので、そもそもコールドデータを保存するのに適したストレージであるということがネーミングにも込められているようです。


Glacierの使い方

Glacierの基本的な使い方は以下の様な感じになります。

1.Vaultの作成

Glacierを使うにはまずはVaultを作成する必要があります。Vaultは貯蔵庫を意味する英語で、S3でいうところのBucketに近い感じでしょうか。Vaultには任意の名前をつけることができるので、用途に応じたわかりやすい名前をつけるのが良いでしょう。

2.ファイルのアップロード

1で作成したVaultにファイルをアップロードします。GlacierではデータはすべてArchiveという名前で扱われ、アップロードされたファイルも以降はArchiveと呼ばれます。Archiveにはそれぞれに一意となるArchiveIdが割り当てられ、アップロード後はArchiveIdでデータを識別します。ファイルのアップロード時にArchiveIdが割り振られますので、ArchiveIdとファイルの紐付けを利用者側で行なっておく必要があります。

3.Archiveのダウンロード

2でアップロードされたArchiveをダウンロードします。ArchiveをダウンロードするにはまずはGlacierに対しデータの取得リクエストを送信し、ジョブを開始します。データ取得のためのジョブが完了するとジョブの結果をダウンロードできるようになります。このリクエストの送信から、ジョブの完了までおよそ4,5時間かかります。


サンプルプログラム

現在、Vaultの作成はManagementConsoleから行うことができますが、Archiveの操作やVault内のアーカイブ一覧の取得などはManagementConsoleでは行うことができません。このような操作はAPIから行う必要があります。今回はAWS SDK for Javaを使ってGlacierの基本的な操作を行なってみます。

※AWS SDK for Javaのバージョンが1.3.18より前だとGlacierに関するバグがあるようです。1.3.18以降のバージョンを利用するようにしてください。

Vaultの作成

まずはプロキシを使っている場合などはプロキシの設定を行います。

次にGlacierを操作するためのクライアントを生成します。クライアント生成後エンドポイントを指定し、リージョンを設定します。

エンドポイントはこちらに整理されています。

AwsCredentials.propertiesにはアカウントのアクセスキーとシークレートキーを記入しておきます。 書き方はこちらを参照してください。

Glacierのクライアントが生成できたので、Vaultの作成リクエストを生成し、クライアントから送信します。

これでVaultの生成は完了です。

次にVaultにたいしてArchive取得・Archive一覧取得のジョブが完了したときにSNSで通知を行うよう設定を行います。

ここでは予めSNSのTOPICを予め生成し、ARNを控えておきます。

withEventsに渡しているのは通知を行うイベントの種類で“ArchiveRetrievalCompleted”を指定するとArchive取得ジョブ完了時に、“InventoryRetrievalCompleted”を指定するとArchive一覧取得ジョブ完了時に通知が行われます。

これでSNSの設定も完了です。これでこのVaultに対するジョブ完了時に通知が行われます。

ファイルのアップロード

ファイルのアップロードにはArchiveTransferManagerを利用します。GlacierクライアントとCrendentialを渡してArchiveTransferManagerを生成し、uploadメソッドでファイルをアップロードします。

uploadメソッドに渡している引数はVault名、Archiveの説明文,アップロード対象ファイルとなります。

これでファイルのアップロードは完了です。uploadメソッドの返り値として渡されるUploadResultにはアップロードしたファイルのArchiveIdが含まれています。アップロードしたファイルは今後ArchiveIdを指定して取得することになるので、ArchiveIdを必ず控えておくようにしましょう。

ちなみに200MBのファイルのアップロードにかかった時間は10回の平均で50.038秒でした。

Vault内のArchive一覧取得

現在Vaultの中に保存されているArchiveの一覧を取得します。こちらはArchive一覧取得ジョブを開始し、ジョブが完了後に、ジョブの結果をダウンロードするという流れになります。

ジョブの開始リクエストを生成し、GlacierクライアントのinitiateJobメソッドを呼び出します。

このinitiateJobメソッドの返り値のInitiateJobResultに、開始したジョブのIDが含まれています。ジョブ完了後に結果をダウンロードするのに必要となるので、JobIdを控えておくようにしてください。

SNSにメールを登録していると、ジョブが完了すると以下の様なJSON形式の内容のメールが送信されます。

ジョブが完了したことがメールからわかるのでジョブの結果をダウンロードすることができます。ちなみにジョブの結果をダウンロードできるのはジョブ完了後24時間以内ですので注意してください。ではジョブの結果をダウンロードしてみましょう。

Vault名とJobIdを指定してジョブの結果取得リクエストを生成し、GlacierクライアントのgetJobOutputメソッドを呼び出します。結果として渡されるGetJobOutputResultのgetBodyメソッドでInputStreamを取り出すことができます。このInputStreamを読み込むことでジョブの結果を読み込むことができます。InputStreamで読み込んだ内容をファイルに書きだすのが良いかと思います。

このcreateFileFromInputStreamメソッドはInputStreamで読み込んだ内容を引数で渡されたファイルに書き込んでいます。

実際に書きだされたファイルの中身は以下のようになります。

Vault内にArchiveが複数ある場合は、”ArchiveList”の配列内にオブジェクトが複数格納されます。

ちなみに検証時は4時間から4時間30分までの間にジョブが完了していました。

Archiveのダウンロード(Low Level API)

Archiveのダウンロードは基本的にArchiveの一覧取得とほぼ同じ方法で行います。

違う点は対象のArchiveIdを指定するところ、withTypeで”archive-retrieval”をしているところとなります。

 

SNSにメールを登録していると、ジョブが完了すると以下の様なJSON形式の内容のメールが送信されます。

ジョブの結果のダウンロードはアーカイブ一覧の取得と全く同じ内容で、JobIdを変えて実行すればダウンロードすることができます。

ちなみに検証時はジョブが完了するまで4時間30分ほどでした。

Archiveのダウンロード(High Level API)

GlacierのAPIには通常のLowLevelAPIとより簡単に利用できるようになっているHighLevelAPIの2種類があります。ArchiveのダウンロードやアップロードにはHighLevelAPIを使うことができます。ここではHighLevelAPIを使ってArchiveをダウンロードしてみます。

ファイルのアップロードと同様ArchiveTransferManagerを使うと簡単にダウンロードすることができます。ただ現在、US-EAST以外のリージョンで利用する場合はSNSとSQSのエンドポイントを個別に設定する必要があります。

ArchiveTransferManagerのdownloadメソッドが呼び出されるとジョブが開始され、ジョブが完了すると引数で渡したファイルにジョブ結果の内容が書き込まれます。なおジョブが完了し、結果をダウンロードし終わるまで制御が返って来ませんので、別スレッドにて実行するか、バックグラウンドで実行することをおすすめします。

ちなみにジョブ完了までの時間はLowLevelAPIとほぼ同じでした。

Jobの状態取得

SNSの設定を忘れてジョブを開始した場合、ジョブが完了したか実行中かわからないということもあるかと思います。そのような場合のためのジョブの現在の状態を取得することができます。

ジョブ実行中の場合はgetCompleted()はtrue,getStatusCode()は”InProgress”を返します。

ジョブが完了している場合はgetCompleted()はfalse,getStatusCode()は”Succeeded”を返します。

これでジョブの現在の状態を把握することができます。


現在の注意点

1.ArchiveIdとファイル内容、JobIdとジョブ内容の紐付けが必要

ファイルはアップロードした時点でVault内のArchiveとして扱われ、アップロード以降ファイルの操作にはArchiveIdが必要となります。ArchiveIdとファイル内容を紐付けて管理しておかないと、どのArchiveIdのファイルがどのような内容かわからなくなってしまいます。

またArchiveの取得、Archiveの一覧取得時にジョブを開始した際、ジョブにJobIdが割り振られ、ジョブの結果をダウンロードする際にこのJobIdが必要となります、JobIdとジョブの内容を紐付けて管理しておかないと、どのジョブが、何をダウンロードしようとしていたのかがわからなくなってしまいます。

このあたりはSimpleDBに紐付けデータを保存しておくのが手間が少なくてスジがよさそうな気がしています。

2.Archiveの取得に時間がかかるうえ、期間内に取得しなければならない

ジョブの開始から完了まで検証中は4時間から4時間30分かかっていました。また、ジョブの結果は完了後24時間以内に取得する必要があります。SNSの設定を行なっているとジョブの完了時にメールが送信されるとはいえ、うっかりしているとダウンロードし忘れてしまいそうですね。ジョブのステータスを取得するプログラムを定期的に実行し、完了している場合はダウンロードするような仕組みがあるといいかもしれませんね。

3.詳細な利用にはプログラミングが必要

現在GlacierへのArchiveの保存、Archiveの取得などはAWS SDKを使ってプログラミングをしないと利用することができません。

Management Consoleでは8月31日現在ではVaultの作成と設定変更・削除のみが可能となっています。このあたりは今後のManagement Consoleの機能追加に期待したいところです。ちなみにS3との間でシームレスにデータを移動するためのオプションが追加される予定とのことなので、今後がとても楽しみです。


利用方法を検討してみる

では、実際にGlacierをどのように使うのかを考えてみます。

弊社ではファイル・データのバックアップに現在S3を利用しており、日次でデータをS3に転送しています。これが毎日続くとなると結構な容量と結構な金額となってしまいそうです。そこでGlacierを活用してみたいと思います。

まず今までの運用通り毎日のバックアップデータはS3に保存します。ただS3に保存後一定期間経過後のデータをGlacierに転送します。

そうするとS3に保存されているデータは常にほぼ一定の容量となります。そして価格の安いGlacier上にどんどんバックアップデータが蓄積されていきます。

今までS3に保存されていたデータをGlacierに移すことができるので、コスト削減が見込めそうですね。


まとめ

今回はAmazon Glacierの概要の説明とサンプルプログラムを解説してみました。

  • Amazon Glacierは1GBあたりの月額が約1円の超低コストストレージサービスです。
  • S3と比べ、ファイルのダウンロードを開始できるようになるまで時間がかかるなどの制限も多いです。
  • 操作にはAWS SDKを用いてプログラミングを行う必要があります。

というのがGlacierの特徴でした。

制限も多いですが、特徴を理解して利用できればかなりのコスト削減になるのではないかと思いますので、ぜひGlacierを利用してコスト削減にチャレンジしてもらいたいと思います。

今回一部公開しましたサンプルプログラムはこちら(GitHub)で公開していますので、ぜひ参考にしてみてください。


2012年09月3日

sakata

関西Javaエンジニアの会 ’12 8月度 を開催しました!

Hello world! ソーシャルネットワーク事業部開発部の、jyukutyoこと阪田です。

2012/8/28(火)に、関西Javaエンジニアの会(関ジャバ)を開催しました。私は、関ジャバの運営メンバーなのです(実は発起人です)。会場は、四条烏丸にある京セラコミュニケーションシステム株式会社の会議室をお借りすることができました。広くキレイで会議室で、とてもよい時間を過ごすことができました。

セッションは、次のようなものでした。合わせて2時間、みっちりテクニカルな内容で、ボリュームたっぷりでした!

  • 「Javaニュース」 / irofさん
  • 「Xtend30分クッキング」 / s_kozakeさん
  • 「MessagePack RPC でドキドキ非同期通信」 / tksmdさん
  • 「Java並行処理基礎」 / hakuraiさん

関西Javaエンジニアの会という名前は私がつけたのですが、Javaエンジニアの会であって、Java勉強会ではありません。なのでセッション内容はJavaだけに限らず、Javaエンジニアに役立つものであれば、何でもOKと考えています。もう3年以上続いています。これも運営メンバーのがんばりのおかげです!

Javaニュース

ニュースとしては、「Project Jigsaw」がJava 8に入らず、Java 9に延期になったこと、Spring Frameworkのファウンダー、ロッド・ジョンソンがVMWareから離れたこと、などがありました。

スライド:http://www.slideshare.net/irof/javanews-aug-2012

Xtend30分クッキング

Xtend

Xtendはプログラミング言語です。他のJVM言語と毛色が違うのは、XtendソースコードからJavaソースコードが生成され、Javaとして実行されるところです。最近のJVM言語にあるような機能はひと通りあるようです。オフィシャルサイトには、モダナイズしたJavaだとあります。気になる点は、スタックトレースがJavaのままだったら、該当するXtendのソースを見つけるのは簡単なのだろうか、という点です。

スライド:http://www.slideshare.net/s_kozake/xtend30

MessagePack RPC でドキドキ非同期通信

MessagePack

フォーマットとしてバイナリにすることで、JSONを使うよりシリアライズ/デシリアライズが速い、MessagePackの話です。JSONどころかProtocol Buffersよりも速いようです。ドラクエ10でも使用されているとか。tksmdさんのスライドはいつもおしゃれで、かつわかりやすいです。デモもあり、非常におもしろい内容でした。

スライド:http://www.slideshare.net/tksmd/messagepack-rpc-20128

Java並行処理基礎

マルチスレッドプログラミングをするための基礎という話でした。synchronizedとかvolatileとか。私も今ちょうど勉強していたところなので、復習できました。

スライド:http://www.slideshare.net/hakuraipod/java-update1

さいごに

関ジャバは約2ヶ月に一度、大阪または京都で開催しています。基本的に平日開催で、時間は19時か19時半からです。参加者は常時20〜30名です。まずまず活発に活動しているコミュニティだと思いますので、Javaエンジニアの方はぜひ次回参加してみてください!全然怖くないコミュニティですよ!