タグ

ブックマーク / d.conma.me (11)

  • VPC内のインスタンスからメールを送る - まめ畑

    AWSには、SESというメールを簡単に送信出来るサービスがありますが、ケータイキャリア向けに最適化して送りたいとか、送信前に色々やりたい、送信したメールの情報を取っておきたいなどなどで、自前のメールサーバからメールを送信したいという要望はあると思います。 suz-lab - blog: Postfixでリレー設定(冗長構成) の記事で、Postfixのrelayhostとfallback_relayを使用した冗長構成が紹介されていましたので、今回は、Internal ELBを使った構成とAWS内の自前のメールサーバからメールを送信する際の注意点についてまとめておきます。 まず、Internal ELBを使った場合の利点ですが、メンテナンスの容易性と可用性があります。 アプリケーションサーバやバッチサーバなどのメール送信元に設定するメールサーバの接続先情報は、Internal ELBのドメイ

    VPC内のインスタンスからメールを送る - まめ畑
  • 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)がバーストするということです。 リリースにも書かれている通りのアルゴリズムでバーストします。 また、

    T2インスタンスがでたので簡単に性能をみてみた - まめ畑
  • redisをAutoScaling環境で使う場合はtimeoutの設定に注意 - まめ畑

    Redisをstorageやcacheとして使う事が多くなってきたのですが、普段使っている分にはさほど問題なかったものがautoscaleなどの頻繁なインスタンスの増減がある環境でtimeoutを上手く設定していないと問題が出る場面に遭遇したのでメモしておきます。 Redisのtimeout値(コネクションは貼られているが、コマンドが送られて来ない時間)はdefaultで300秒になっています。 この値を何らかの理由で0(無効)やとても長い時間に設定している場合、正常にコネクションがcloseされないと、Redis側からはESTABLISH状態に見えたままになていることがあります。 この状態の時はnetstatで確認してもESTABLISHEDになっています。 今回この場面に遭遇したときは、インスタンスの増減が頻繁に行われている時で、Redisの接続が失敗する事が増えてきたため気づきました

    redisをAutoScaling環境で使う場合はtimeoutの設定に注意 - まめ畑
  • 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 Casual Talks#3に参加した - まめ畑
  • ElastiCacheとELBとtwemproxy - まめ畑

    redis / memcachedをスケールする方法として、アプリケーションで分散アルゴリズムを実装する方法や、ライブラリを使う方法などありますが、 Twitterが作っているtwemproxy(https://github.com/twitter/twemproxy)というものがあります。 これは、redis / memachedの前段に置くことでキャッシュクラスタを構成することが出来ます。様々な分散アルゴリズムや、故障ノードの切り離しなどの機能もあり、 キャッシュノードが不具合で接続できなくなったとしても自動でサービスアウトしてくれます。 開発も盛んに進んでいて、今、ノード追加時にプロセスの再起動が必要ですが、gracefulの実装も見えて来ました。 詳しくは以前書いたこちらの記事を参照して下さい。http://d.conma.me/entry/20121227/1356596553

    ElastiCacheとELBとtwemproxy - まめ畑
  • AWS ElastiCache と twemproxyを使ってみた - まめ畑

    このエントリの最後の方で書いてあるtwemproxyの変更ですが、pull requestを出して、体にマージされました。2012/12/31時点でまだリリースバージョンが切られていないので、githubからcloneしてビルドして下さい。 先日のAWSの発表で、VPCにもElastiCacheがやって来ました。 (http://aws.amazon.com/jp/about-aws/whats-new/2012/12/20/amazon-elasticache-announces-support-for-amazon-vpc-1/) さらに、オートディスカバリ機能も少し前に発表されています。 オートディスカバリを使えば、Configuration Endpointに対して config get cluster コマンドを発行することで、そのClusterで有効なnodeの接続情報リスト

    AWS ElastiCache と twemproxyを使ってみた - まめ畑
  • 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)

    ElastiCacheとELBとtwemproxy その2 - まめ畑
  • S3のStatic WebSite Hostingでエラー時にリダイレクト - まめ畑

    S3のStatic WebSite Hostingは静的ファイルをホストするにはとても便利な機能です。 S3のバケットにたいして、Static WebSite Hostingを有効にして、バケットポリシーで全公開するだけで、Webサーバなどを用意することなくサイトが公開出来ます。 S3のアクセスに対するキャパシティは非常に大きく、イベント告知やTV放映時の着地サイトなどに使うことで安く簡単に大量のトラフィックを受け止める事が可能になります。 このあたりのことは、よく書かれているのですが、実はもう1つ便利な機能があります。それは、特定の条件にマッチした時に、指定した条件でリダイレクトをさせるというものです。 特定のファイルに関しては、ファイルのプロパティでMetaタグとして、「Website Redirect Location」を設定し、リダイレクトするパスを設定します。 こちらはファイルが

    S3のStatic WebSite Hostingでエラー時にリダイレクト - まめ畑
  • 気軽なMySQLバージョンアップ - まめ畑

    このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル! このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、番環境で流れているクエリをバージョンアップ先のDBに実際に流して

    気軽なMySQLバージョンアップ - まめ畑
  • ElastiCache Redis Engineのベンチマークともろもろ - まめ畑

    Amazon Web Services Blog: Amazon ElastiCache - Now With a Dash of Redis で日ElastiCacheでRedisが使えるようになりました。今まではmemcachedだけでした。 (同時にAmazon Web Services Blog: More Database Power - 20,000 IOPS for MySQL With the CR1 Instance も発表されています) 基的なこと 機能 Replication GroupsによるRedisレプリケーションのサポート Replication Groupsは1ノード毎にSlaveとなる、Endpointは各ノード毎にアサインされる Masterへは統一のEndpoitが与えられ、Read replicaをmasterにpromoteしてもendpoin

  • MySQL5.5 と MySQL5.6 と RDS - まめ畑

    MySQL5.6は5.5よりもベンチマーク性能が落ちるという話がここ最近見受けられます。 My MySQL is faster than your MySQL Is MySQL 5.6 slower than MySQL 5.5? MySQL5.6の検証は半年程前から格的に開始して、大量データに対して、JOINやLIMIT、INDEXが不十分なクエリに対して、productionデータで試してみたところ、完全に新規パラメータの設定やデフォルト値の変更を適用していない状態でも性能向上が出ていたので、安定性のテストをしていたのですが、上の記事などを読んでsysbenchやsql-benchを試してみました。 これは基的なクエリを流すので、複雑な処理を高速化しているとかはあまり考慮されません。 ついでに、RDSもベンチマークを測ってみました。 MySQ5.5と5.6は基的な設定内容は同一に

    MySQL5.5 と MySQL5.6 と RDS - まめ畑
  • 1