conma.meThis domain may be for sale!
S3とCORS - まめ畑
最近、AWSのサービスも少し様変わりしてきて、インフラレイヤーから、アプリレイヤーまで幅広くサービスが出てきています。SDKも充実してきていて、デバイスやブラウザから直接AWSサービスにアクセスして、S3にデータをUploadしたり、DynamoDBにデータを入れたり、Kinesisにログを流し込んだりなどなど今までサーバをかえして行っていた処理が突き詰めればサーバレスで行えるようになってきました。 もちろん、データを受け取って整形など複雑な処理を行いたいという場合には今まで通りAPIサーバなりを用意する方法になるかと思います。 ここで一つ問題になるのが、認証周りかと思います。例えば、ブラウザやデバイスから直接S3にデータをUploadしたり読み出したりするアプリがあった場合、S3にアクセスするための認証情報をセットする必要があります。このキーの管理はなかなか難しいところがありますが、今ま
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)がバーストするということです。 リリースにも書かれている通りのアルゴリズムでバーストします。 また、
気軽なMySQLバージョンアップ - まめ畑
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル！ このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流して
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)
EC2・オンプレ環境のMySQLからRDSのマイグレーションがやりやすくなった - まめ畑
本日 Migrate On-Premises MySQL Data to Amazon RDS (and back) | AWS Official Blog Importing Data to an Amazon RDS MySQL DB Instance with Reduced Downtime - Amazon Relational Database Service の発表があり、RDSに対して、オンプレミス環境・EC2上で動いているMySQLとのマイグレーションが行い易くなりました。 ただ、常にレプリケーションさせてというわけではなく、移行時に使うという用途です。 オンプレミス環境・EC2上で動いているMySQLとRDSでレプリケーションが可能になりました。 ドキュメントには環境・データサイズ毎のマイグレーションについて書かれているのでご一読下さい。 つまり このような構成が取れる
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.6のちょっとした話 - まめ畑
最近、とあるサービスの本番環境にMySQL5.6を導入していっています。社内だけの環境も含めて5システムに導入しました。 5.5からのアップデートや最初から5.6というものもあります。 今回、導入で変わった点いろいろありますが、メモ程度にまとめておきます。 間違いなどありましたら指摘していただけるとありがたいです。 Replicationエラー時 今までは、replicationのエラーが起こった場合は SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; とかでダメなクエリを確認しつつSKIP出来ればしていましたが、5.6でGTIDモードONの場合、これが使えなくなりました。 GTID便利なんですが、この点少し不便です。 以下のように直します。 まず、slaveでmaster server UUIDと最新のGTID、Retrieved_Gtid_Setを確認します
VPC内のインスタンスからメールを送る - まめ畑
AWSには、SESというメールを簡単に送信出来るサービスがありますが、ケータイキャリア向けに最適化して送りたいとか、送信前に色々やりたい、送信したメールの情報を取っておきたいなどなどで、自前のメールサーバからメールを送信したいという要望はあると思います。 suz-lab - blog: Postfixでリレー設定(冗長構成) の記事で、Postfixのrelayhostとfallback_relayを使用した冗長構成が紹介されていましたので、今回は、Internal ELBを使った構成とAWS内の自前のメールサーバからメールを送信する際の注意点についてまとめておきます。 まず、Internal ELBを使った場合の利点ですが、メンテナンスの容易性と可用性があります。 アプリケーションサーバやバッチサーバなどのメール送信元に設定するメールサーバの接続先情報は、Internal ELBのドメイ
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は基本的な設定内容は同一に
ElastiCacheとELBとtwemproxy - まめ畑
redis / memcachedをスケールする方法として、アプリケーションで分散アルゴリズムを実装する方法や、ライブラリを使う方法などありますが、 Twitterが作っているtwemproxy(https://github.com/twitter/twemproxy)というものがあります。 これは、redis / memachedの前段に置くことでキャッシュクラスタを構成することが出来ます。様々な分散アルゴリズムや、故障ノードの切り離しなどの機能もあり、 キャッシュノードが不具合で接続できなくなったとしても自動でサービスアウトしてくれます。 開発も盛んに進んでいて、今、ノード追加時にプロセスの再起動が必要ですが、gracefulの実装も見えて来ました。 詳しくは以前書いたこちらの記事を参照して下さい。http://d.conma.me/entry/20121227/1356596553
Kageを使う時にやっておくと便利なこと - まめ畑
先ほど、Kageというgemが公開されました。 https://rubygems.org/gems/kage https://github.com/cookpad/kage このgemは、クライアントからのリクエストを複製し、バックエンドの複数のサーバに同じリクエストを送る事が出来ます。これを使うことで、これから本番に適用するコードの負荷試験や、書き込みをDummyDBに逃がして、slaveを本番に接続するなどして本番データを使用した負荷テスト、ミドルウェアのバージョンアップのテストを行うことが出来ます。 実際にクライアントに返されるレスポンスデータはproductionサーバとして指定されたサーバから返却されるため、本番のリクエストを使用してテストが簡単に行えるようになります。 実際に本番のアクセスを流す方法にはいくつかあると思います。Kageが導入されたサーバに直でトラフィックを流す方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
conma.me