いまさらGoでElasticache Redisの負荷・障害試験をがっつりしてみた
こんにちは、 株式会社アプリボット、バックエンドエンジニアの小川詩織です。 今回はgolangで開発中の新規プロジェクトのため、ElasticacheRedisに関する検証を行いました。 かなり長くなってしまいましたが、参考にしていただければ幸いです。 以下、検証内容になります。 まえおき 検証のための実装にはgolangを用い、 go-redisによるElasticache Redisについての検証になります。 また、ゲームで良く活用される Ranking機能 の実装を想定した検証を行いました。 Ranking機能実装のためにRedisは ソート済みセット型 を用います。 Ranking機能についての想定なので、同一ランキングはkeyも同一になり、 Shardを増やしても負荷分散できないため全て Shard=1 として検証を行います。 また、Redisの 要素数は1000万件 用意しまし
Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム
概要 お仕事でRedisを触ってたので知見をまとめる。 Redisは高速はKVSだが、今回1000万件を超えるような大量のデータを扱った。 大量のデータをバッチで定期的に書き込んで、参照側では高速に返すシステムを考える。 バッチはユーザーの行動を『現在から1日以内にログインしたユーザー』のように時間区切りで条件検索している。そのため、検索する時間が変われば結果も変わるので、定期的に実行してデータを洗い替えている。 検索結果は1000万件あっても対応したい。 ユーザーがアクセスしてきたときにはこの検索結果の対象かどうか判断して結果を返したい。このユーザーからのアクセスは大量にあるため即座にレスポンスを返さなければならない。 洗い替えることによって使わなくなったデータは容量を空けるために削除したい。 クエリ結果はユーザーのidなので19475934や59103940のような法則性の薄い数字の列
redisのmaster-slave構成で考えるべきことの話 - diary
結論 Redisは2.6を使おう master-slave構成を取る場合はclient-output-buffer-limitをちゃんと意識するべき 概要 redisはエッジトリガ型のnon-blocking I/Oを用いてシングルスレッドでソケットの読み書きをぶん回す構造で書かれています。 よってclientやslaveへ対してのreplyを行う際も、ソケット自体の送信バッファが溢れた際(EAGAINが帰った際)には一度イベントループに処理を戻し、またソケットが書き込み可能になってイベントループが自分を呼んでくれた時に続きをwriteします。 まあnon-blocking I/Oなんだから当たり前なんですが、送信処理を再入可能にするためにredisはアプリケーションレベルで出力バッファを持っています。 これは送信が終わり次第適宜解放されるものの、write自体が間に合わなくなると詰まって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
