S3とCORS - まめ畑
最近、AWSのサービスも少し様変わりしてきて、インフラレイヤーから、アプリレイヤーまで幅広くサービスが出てきています。SDKも充実してきていて、デバイスやブラウザから直接AWSサービスにアクセスして、S3にデータをUploadしたり、DynamoDBにデータを入れたり、Kinesisにログを流し込んだりなどなど今までサーバをかえして行っていた処理が突き詰めればサーバレスで行えるようになってきました。 もちろん、データを受け取って整形など複雑な処理を行いたいという場合には今まで通りAPIサーバなりを用意する方法になるかと思います。 ここで一つ問題になるのが、認証周りかと思います。例えば、ブラウザやデバイスから直接S3にデータをUploadしたり読み出したりするアプリがあった場合、S3にアクセスするための認証情報をセットする必要があります。このキーの管理はなかなか難しいところがありますが、今ま
ElastiCacheとELBとtwemproxy その2 - まめ畑
以前、 http://d.conma.me/entry/2013/01/22/195331 のエントリで、Internal ELB + twemproxy + ElastiCacheの構成で、スループットが劇的に低下してしまう問題について書きましたが、その後色々と調査をしてみました。 Internal ELBのウォームアップを行い、都度コネクションを切っていたものを接続したままにし、コマンドを送信するように変更してみました。 しかし、結果は前回の結果と同様のものとなりました。 他にも色々とtwemproxyやカーネルパラメータなどの調整を行なってみたのですが、劇的な効果はありませんでした。 Internal ELB の代わりにhaproxyを使用してパフォーマンスを測定してみました。 条件は、haproxy * 1 / twemprxoy * 4 / ElastiCasche(large)
T2インスタンスがでたので簡単に性能をみてみた - まめ畑
昨日、EC2の新instance familyでT2シリーズが出ました。 今まで、t1.micro/m1.smallとか言われてたシリーズの現行版で、General Purposeにカテゴリも変更されています。 リリースは以下の記事 http://aws.amazon.com/blogs/aws/low-cost-burstable-ec2-instances/ http://aws.typepad.com/aws_japan/2014/07/low-cost-burstable-ec2-instances.html 置き換えは t1.microをt2.microへ m1.smallをt2.smallへ m1.mediumをt2.mediumへという感じです。 特徴としては、CPU(ECU)がバーストするということです。 リリースにも書かれている通りのアルゴリズムでバーストします。 また、
ElastiCacheとELBとtwemproxy - まめ畑
redis / memcachedをスケールする方法として、アプリケーションで分散アルゴリズムを実装する方法や、ライブラリを使う方法などありますが、 Twitterが作っているtwemproxy(https://github.com/twitter/twemproxy)というものがあります。 これは、redis / memachedの前段に置くことでキャッシュクラスタを構成することが出来ます。様々な分散アルゴリズムや、故障ノードの切り離しなどの機能もあり、 キャッシュノードが不具合で接続できなくなったとしても自動でサービスアウトしてくれます。 開発も盛んに進んでいて、今、ノード追加時にプロセスの再起動が必要ですが、gracefulの実装も見えて来ました。 詳しくは以前書いたこちらの記事を参照して下さい。http://d.conma.me/entry/20121227/1356596553
redisをAutoScaling環境で使う場合はtimeoutの設定に注意 - まめ畑
Redisをstorageやcacheとして使う事が多くなってきたのですが、普段使っている分にはさほど問題なかったものがautoscaleなどの頻繁なインスタンスの増減がある環境でtimeoutを上手く設定していないと問題が出る場面に遭遇したのでメモしておきます。 Redisのtimeout値(コネクションは貼られているが、コマンドが送られて来ない時間)はdefaultで300秒になっています。 この値を何らかの理由で0(無効)やとても長い時間に設定している場合、正常にコネクションがcloseされないと、Redis側からはESTABLISH状態に見えたままになていることがあります。 この状態の時はnetstatで確認してもESTABLISHEDになっています。 今回この場面に遭遇したときは、インスタンスの増減が頻繁に行われている時で、Redisの接続が失敗する事が増えてきたため気づきました
MySQLとInternal ELB - まめ畑
VPC上でInternal ELBが提供され、slave群をInternal ELB配下に置くことで、slaveサーバの冗長化が出来るようになりました。 そこで、ELB配下に配置した際のパフォーマンスの劣化と注意点を見つけるためにパフォーマンス測定をしてみました。 色々 DB: とあるデータ件数の多いDB コネクション数: 100,200,300,400,500,600,700,800 試行回数: 1クライアントにつき 100回 クエリはランダムに発行 ELB配下には２台配置 結果 スループット(qps) スループットが上がっているのは、キャッシュヒット率が上がっているため connection DIRECT ELB 100 1897.5 1703.5 200 2075.1 1696.3 300 2286.79 1897.37 400 3098.5 2033.93 500 3255.8 2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
conma.me
