S3

久々の更新。 昨日はネットワークスペシャリストを受験してきたけど散々でした… (ちーん IAMで特定のバケットのみRead Writeを許可するユーザを作成する必要があったのでその時のメモ。 ポリシを自分で書いちゃえばいけました。 例えばhogehogeというバケットに対してフルアクセスを許可したいときは { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3::hogehoge", "arn:aws:s3:::hogehoge/*" ] } ] } 後はユーザを作成して上記のポリシをアタッチするだけでOKです。 実は下記にポリシシミュレータがあって、ポリシの検証をができるらしい。 https://policysim.aws.amazon.com/home/index.jsp 上のポリシで検証したらFailed出てS3のアクセスができないよってログが出てたのだけれど、 個別バケットの場合は、ポリシシミュレータがFailedを返すようでした。 実際に上記のポリシをアタッチしたユーザでaws-cliコマンドを叩くとそのバケットだけにアクセスできました。 »

沖縄でもAWS 認定ソリューションアーキテクトが受験できるというのを先日知り、腕試しをしてみようと思い資料漁りをしてます。 そんな中、S3への大量のリクエストをさばくにはどうすればいいんだろうとか考えてました。S3っていつもデータぶん投げるためだけに使ってたし、勝手にスケールするんでしょ〜とか思ってたけど 大量アクセス時に負荷が高い場合の性能の引き出し方が載ってた。 http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/request-rate-perf-considerations.html S3のバックエンドでは、keynameでパーティションを分割してバケットリクエストの増加に耐えるようになっているみたい。こっちにも例が載ってた。 http://aws.typepad.com/aws_japan/2012/03/amazon-s3-performance-tips-tricks-.html なので、keynameにprefixつけて運用するような設計にしておくとよきに計らってくれるみたい。(もちろんつけ方は気をつけないといけない) もちろんこれは、高負荷の時に考えるもので下記のリクエストレートが常時超えてるような場合に有効. PUT/LIST/DELETE が 100回/sec GET 300回/sec 急激な増加で下記を超える場合がありそうならサポートに連絡的なことがかいてある。 PUT/LIST/DELETE が 300回/sec GET 800回/sec でも、GETリクエストを抑えるだけなら、CloudFrontにキャッシュさせて配信させるほうが安心かも。 自分のブログはAWSに移行してから、S3 + CloudFrontで配信してる。 特にS3に大量アクセスが来るわけではないのでS3だけ使ってても良かったのだけれど…. https://www.slideshare.net/hz_ouchi/20130222-16684434 備忘録として残しておく。 そういや1年前に買った書籍 AWS クラウドデザインパターン設計ガイド 実は1年前に買って全然読んでなかったのを思い出して昨日読んでました（笑） デザインパターンはある程度知ってたけど、 実際に手を動かして環境を作って動かしてみたのは少ないので、気になるところだけでも作ってみようと思う。 さすがに75パターンあると全部試すのは結構しんどいから気になるところだけ。 AWSは進化が激しく古くなったパターンもあるようで、そこは公式読みながら補完したほうがよさそう。 Cloud Design Pattern »

先日はRekognitionを利用して飯テロ禁止botを作成しましたが、 今回はLINEにアップした画像をS3に保存するbotを作ってみました。 Lineトークにアップされた画像は2週間でLineサーバから削除されるため、 後でダウンロードしようと思った時に有効期限が切れてしまってもう1度アップし直してもらう… なんてことがありました。 アルバムに置いてれば保存期間は無期限なんですが やはりトーク内に画像貼り付ける方が楽ですからね。 そんなこんなで、S3に置いて永続化できるといいなぁと思った次第です。 アーキテクチャ 基本構成は前回のものと同じですが、RekognitionがS3に置き換わっています。 実際に作ってみた コードはGithubに置いてます。 https://github.com/328/serverless-practice/tree/master/linebot-s3 serverless.yml LambdaにはS3の書き込み権限を付与します。(めんどくさいのでフルアクセスにしてるのは申し訳ない） 環境変数はLine developerからとってくる handler.js 保存するファイル名をどうしようかなぁちょっとばかり悩んでたんですが 「画像をMD5関数に突っ込んでハッシュ値を得る。そのハッシュ値をファイル名として利用する。」 としました。 メリットとして 同じ画像が既に上がっていた場合は上書き保存される。 同じ画像はリストに出てこなくなるので一種の重複排除機能として利用できる。 もちろん問題点はあって 「ハッシュ値は衝突する可能性がある」 ということで この辺りを改善するには ハッシュ値 + タイムスタンプ でファイル名とする 既に同じファイル名のものがS3上にあるか検索し、あればMD5とは別のもので再計算する くらいでしょうか。 実際に大量のファイルを保存する場合にはこの辺りも考慮にいれないといけなかったり。 あとは他のアルゴリズムを使うと計算量が多くなる可能性があったり その分Lambdaの実行時間が長くなってしまう可能性もある(要検証)。 個人で利用する分にはこれくらいのもので良いし、 違う画像でMD5が一致した場合には画像が消えてしまいますが、 その辺は許容します。 という感じでLinebotを作ってみました。 先日のRekognitionと組み合わせれば画像を仕分けしつつ保存できそうですね。 もう少し時間を作って他のLINE APIも触ってみようかなと思います。 »