AWS Casual Talks#3に参加した
AWS Casula Tlaks#3に参加してきました。AWS Casual Talks #3 on Zusaar
2回目までは主催していたのですが、今回から主催をCookpadの星君に移して初めての開催でしたが、過去を超えてくる濃い・本気の内容ですごく良かったです。色々忙しい中ありがとうございます！
簡単にまとめると
メインセッション
@yoshiori Elastic Transcoder でウキウキ動画配信
クックパッド料理動画 を作った話。オンプレ環境で大容量・高トラフィックな配信環境を作った時の話しとAWSで作った際の話。オンプレ環境で実現する場合はクリアしなければいけない課題をAWSのサービスでどうクリアしたかという話でした。Elastic Transcoderの実用事例を聞けた貴重な機会でした。
@myfinder 僕らの AWS 移行記
オンプレ環境からAWSに完全移行した際のお話で、オンプレで使っていたものをAWSに移行する際にどう変えて移行を実施したか、非常に勉強になる話でした。AWSは完全にオンプレで実現出来ることをそのまま実現することは出来ないので、AWSベースな考えやシステム設計にしていくことになるのですが、何を使って何を使わないか、その判断の基準など非常に勉強になりました。
Managedサービスのセグメントを分けたり、Default VPCを使わなかった話など今後参考になる方多いのではないでしょうか。mackerelはAWSに親和性高いですね。
資料: https://github.com/myfinder/aws-casual-3
資料の中で出ている、docker repositoryの話は
AWS Solutions Architect ブログ: Amazon S3をDockerプライベートレポジトリにしてAWS ElasticBeanstalk環境にデプロイ です！
@imai_factory ナウい Kinesis とか DynamoDB の話 (仮)
本舗初公開のDynamoDBのパーティショニングの話を公開しました。DynamoDBはProvisioningされたスループットをどうパーティションで割り振るかや、Unitを下げた時にどういう動作をするか今まで公開されませんでしたが、今回ついに公開されました。
スループットを下げた際に、パーティションのマージは行われず、ホットパーテションの問題が起こる可能性がありますが、こちらはスループット設計時にベースunitを指定し、バースト分に関しては今まで通りスループット向上をするという方法で問題無いかと思います。この辺の話が外で公開出来るようになったことで、DynamoDBのスループット設計やスループット増減戦略が行い易くなったのではないでしょうか。詳細は今後聞いていただければお手伝い出来るところかと。
Kinesis Client LibraryもPython版がでたり進化してますね。
LT
@takipone 参考にならないAWSに関するブログの書き方の話
AWSのサービスUpdateに追従してBlogを書いて頂いている、裏話。あまり今まで語られることがなかったので新鮮でした。
朝起きてまずTwitterでJeff Barrや日本で早く情報をキャッチアップしている方々のTweetを確認するということでしたｗ
なるべく情報を早く深く出していけるように頑張らねば…
@yoshidashingo VPC by Default 時代のアクセス制御
Default VPCがリリースされて久しいですが、アクセス制御をどうするか、皆さん気になっているところだと思いますが参考になったのではないでしょうか。
アクセス制限はAWSのサービスでもそれぞれ異なる方法があり、出来ること出来ないことなどもあるので難しいのですが、きちんと設計して安心・安全な構成を。
@myfinder Redshift vs BigQuery
こちらはよく聞かれる質問ですが、LTでも話がでた、しっかりテーブル設計をしてクエリをしっかり設計してクエリを投げるのであれば、Redshift。しかしRedshiftおじさんが必要。そうでなく、そこまで複雑でないクエリならBQと、しっかりと要点抑えられたLTでした。内容的には同意で、ストリームアップデートなども考えると性能特性などをみて適材適所ですね。気軽にビックデータ系のサービスが使えるようになったのはすごいことだなぁと改めて思いました。
@kani_b Fight Against POODLE
POODLE対応の話。SSLv3を切るという対応がいいと言われていますが、実環境での難しさとAWSで対応を探った話。CloudFrontとELBも実は対応完了しております。
@sgwr_dts DSLネタかDynamoDBネタ (仮)
DynamoDBの前にキャッシュ置くやつー というところで耳が痛い話でしたが、参考になるところが多かったのではないでしょうか。
確かにDynamoDBは読み書きスループットが大きくなってくると値段が上がってしまうのですが、この辺はDynamicDynamoDBで増減させたり、ある一定量以上であれば、Reserved Capacityを使うことで値段が下がるかと。
今回のRW10,000unitsだと、Reserved CapacityでUpfront入れて月30万円位になるでしょうか。(http://aws.amazon.com/jp/dynamodb/pricing/)
そして、DynamoDBとredis/fluentdの合わせ技のRedy、書き込みに遅延は出てしまいますが、redisを同一VPC内に置くことでhit時の読み込みLatency軽減期待できそうです。
Blog:
DynamoDBの前にキャッシュを置こうとした話 - so what
