AWS Summit Tokyo 2016 3日目に行ってきた
Lambda! Kinesis! Lambda! Kinesis! ... DynamoDB! Aurora!という感じだった。
非常に勉強になった発表が下記。
秒間数万のログをいい感じにするアーキテクチャ クックパッド
https://speakerdeck.com/kanny/miao-jian-shu-mo-falseroguwoiigan-zinisuruakitekutiya
感想
ログ管理は「ログはfluentdで流すようにしてS3に保存する。ElasticSearch/BigQueryにも流して解析に利用する」まではまあ簡単で、もう少し改善できないか悩んでいた私にはちょうどいい発表。
やっぱりKinesis Stream。pull型のpubsub分散キューは素晴らしい。
実験的なアプリをconsumerとして気軽につなげるという発想はなかったが、新しいことを考えてすぐに試せるのが楽しそう。
Kinesisのshardは運用イメージがつかみにくいので、注意点も参考になる。
ログの集約ノードが結構新しい構成まで残っていたことが意外。スライドにある通りいろいろ問題あるし冗長化とかも相当手間。
GREE流! AWSをお得に使う方法
コストとmemcachedの整合性の問題から、memcached + mysqlからDynamoDB(一部のみmamcachedを利用)に移行したという話。
- BatchWriteItemしてもwriteされたitem数で料金計算されるのでコスト面からは減らない
- atomic counterとかconditional saveが整合性を保つのに便利
- DynamoDBはコストが見えやすいのでコスト意識が湧く
- writeは整合性のあるreadより10倍高い
- indexもwriteの増加に影響するので無駄につけないように
- deleteをせずに新規にtableを作る方がいい場合もある
- randomな取得はindex付きのrandom idを作ってrange&limitでクエリすればいい
- capacityを超えても5分のburstはあるけど確実にthrottringを防いでくれるものではないし当然設計ではそうならないように考慮する必要がある
- aws sdkを使っていればretryはしてくれる
- partition
- partitionがsplitされたらcapacityも分割される。その時にリクエストが片方のpartitionに偏るとcapacityを超えてしまう
- partition keyはuser idなど分散されるものを使う
- とは言っても難しいものはあり、mamcachedを一部利用しているものもある
- partitionのcapacityを計算したり管理するのは大変なので、スケーリングにはAmazon DynamoDBというツールを利用している
- scale upでpartitionが作られるが、scale downしてもpartitionは減られないことに注意
aurora
- auroraはwriteのパフォーマンスが高い
- slaveへの切り替え時に数秒処理できなくなるので注意
インフラの作業をlambdaで改善
- ちょっとした作業にはmanagedサービスを使うとすごく安く済む
- EBSスクリーンショット取得とかインスタンスの定期監視とかをcloud watch eventから呼び出したlambdaを使って行った
- lambdaは公式には起動に失敗する可能性があるのでログをチェックする仕組みを入れる必要がある。ただ、実際に運用で起動に失敗したことはなかった
- 実行時間は5分までなので、必要ならば処理を分けること
- lambdaをhttp/httpsから呼び出す場合はAWS gateway apiを使う必要があるがこのコストをかけたくない場合、クライアントからhttp/httpsを使わにという手がある
- lambdaは呼ばだしリクエスト量とその時間単位での課金なので、lambdaでの非同期処理を使うことでコストを下げることができる
他
- 開発に利用するes2インスタンスは夜中とか休日は止める
