沖縄でも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年前に買った書籍
実は1年前に買って全然読んでなかったのを思い出して昨日読んでました（笑）
デザインパターンはある程度知ってたけど、 実際に手を動かして環境を作って動かしてみたのは少ないので、気になるところだけでも作ってみようと思う。
さすがに75パターンあると全部試すのは結構しんどいから気になるところだけ。 AWSは進化が激しく古くなったパターンもあるようで、そこは公式読みながら補完したほうがよさそう。