この記事は、はてなエンジニア Advent Calendar 2017の 20 日目の記事です。19 日目の記事は yasuhiro_onishi さんのScratchを使った子どもへのプログラミング教育 — 大西ブログでした。 今年の 2 月にはてなに入社して、あと 1 ヶ月と少しで 1 年を迎えようとしています。はてなに入社してから Mackerel のインフラと時系列データベースの AWS 移行プロジェクトを任されたり、移行を終えた後も後片付けや移行後の運用を担当したりと、主に Mackerel にコミットしていた 1 年でした。自分が Mackerel にコミットしたところは Mackerel のイベントで登壇したいくつかの登壇資料にもあるとおり数多いのですが、この記事では、運用する中で試行錯誤を重ねて苦労した Mackerel を支える時系列データベースのコンポーネントとして利用

TL;DR Redis Clusterで運用は本当に楽になった でも、Redis 4.0は不安 Redis Clusterで一番怖いのはDisk IO 特にフェイルオーバーなどのFull Resync時 Redisとは？ 高速なインメモリ型のKVS シングルスレッド 豊富なデータ構造(次ページにて詳細) 豊富な操作(次々ページにて詳細） 豊富なデータ構造 key-value型 hash型(key-field-value) set型(集合演算ができる) sorted set型(スコア付きset) 任意の型(redis modules機能) 豊富な操作 インクリメントや和集合などなど lua scriptも実行できちゃう シングルスレッドだからatomicな処理になる Redisの問題点 writeがスケールしない 気軽に停止できない サーバー再起動やバージョンアップなど Redis Clus

概要 RedisClusterのチュートリアルを読みつつ疑問を解消していく。 Redis自体がシンプルな仕組みなこともあり、ドキュメントを読むだけでおよそ理解できるものと思われるので、下手な追加説明はあまりしていません。 以下、引用の箇所は筆者が和訳したもの、それ以外が筆者のコメントになります。 Redis cluster tutorial このドキュメントはRedisClusterについて書かれています。 distributed systemのコンセプトを簡単にまとめたものになります。 どうやってクラスタを構成し、テストし、運用するかを要点を絞ってまとめたものです。詳細はspecの方をご確認ください。 しかし、可用性と一貫性についての説明も試みています。 プロダクションで使うにはspecificationも読むことをおすすめしますが、とりあえず試したい方はこちらをお読み下さい。 Redi

はじめに Developpers Summit 2016で「大規模Redisサーバ縮小化の戦い」というテーマで発表してきました。 大規模Redisサーバ縮小化の戦い from Yuto Komai Redisのdumpファイルを取得して、それらをマージする方法や、Redis内で使用するdb数を増やせば、接続数も増えていく、といった話をしました。 特にAWS上でRedisを運用する場合、ElastiCacheの接続数上限は変更できないことは見落としがちなポイントなので、サーバを何十台もスケールアウトする人たちにとって役に立つノウハウが共有できたのではないでしょうか。 当日はネタスライドを山程仕込んで 会場は大爆笑だったのですが、slideshareではネタスライドは割愛しております。 今回のお話 デブサミのスライドでは、ほとんどの話が縮小についての話だったので、今回はRedisの信頼性につい

Redis関連の監視/データ分析系ツールについてメモしておきます。 随時追記予定。実務で有用なツールが他にありましたら教えていただけると嬉しいです。 環境 CentOS 5.9, Ubuntu 12.04 (x86_64) Redis 2.6.10 (※ CentOSの6.x系への移行は足踏み状態。相当大変ですよね。。) 以下の順に紹介していきます。 Redisコマンド Redis Sentinel Redis Live Redis Faina Redis Sampler redis-top Nagiosプラグイン Zabbixテンプレート Muninプラグイン Cactiプラグイン 最後のCactiプラグイン以外は実際に導入して試してみました。以降、見出しに各プロダクトへのリンクを貼っておきます。 Redisコマンド ツール紹介の前にまずは基本から。Redisには監視やデータ解析用途で使

この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

This new command swaps two Redis databases, so that immediately all the clients connected to a given DB will see the data of the other DB, and the other way around. Example: SWAPDB 0 1 This will swap DB 0 with DB 1. All the clients connected with DB 0 will immediately see the new data, exactly like all the clients connected with DB 1 will see the data that was formerly of DB 0. MOTIVATION AND HIST

たまにはPowerShell 以外の記事を。 某記事でもRedis (REmote DIctionary Server)が memcached に代わり得る利点がBookSleeveを交えて丁寧に説明されました。 そして、Redisの運用が一定の目途を見せていることから、その初期設定に欠かせないチューニングについて記事にしてみようと思います。 全部明かすわけではありませんが、なかなかRedisに関する記事は少ないので、少し参考になれば幸いです。 経験上、高負荷環境ではRedisはチューニングで大幅に安定性が変わります。 インストール? 沢山記事ありますし、簡単なのでここでは省きます。 どうしても！な場合は希望していただければ記事にしますが。 Redis Quick Start 対象バージョン 2.6系とします。 2.4系でも大方一緒ですが、2.6系に特有な部分があるので、注意です。 対象O

Product { this.openCategory = category; const productMenu = document.querySelector('.product-menu'); window.DD_RUM.onReady(function() { if (productMenu.classList.contains('show')) { window.DD_RUM.addAction(`Product Category ${category} Hover`) } }) }, 160); }, clearCategory() { clearTimeout(this.timeoutID); } }" x-init=" const menu = document.querySelector('.product-menu'); var observer = new Muta

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

TL;DR rmlp という redis-cli monitor で出力されたログのプロファイラを作りました redis-cli monitor のログを調べる必要がある時は､使ってみて下さい｡ はじめに 時間帯によってはredis serverのcpu使用率が高くなるときがあった アプリのコードレベルでは cache や session をそれぞれ個別に指定できるようになっている それでも分けて負荷が下がる確証もなかったため､ コマンド､keyの利用比率を確認するためredis-cli monitor を実行して調べる事にしました keys ではだめなのか echo keys * | redis-cli > keys.log でkeyがどの程度あるかは調べられますが､実行される頻度が分からないので負荷を見ながら redis-cli monitor で実際に使われているkeyやコマンドを調

メモメモ。泥臭い話で面白かったです。 「大規模Redisサーバ縮小化の戦い」 駒井 祐人 氏 (株)アカツキ ゲームのサーバサイド機能開発、インフラの設計構築・保守運用 Redisとは インメモリDB 5種類のキーバリューのデータ型 ファイル永続化オプション システムの問題点 EC2サーバが20台に対して、AWSのElasticCache(Redis)が64台あった なぜ64台あったかというと、リリース直後にRedisの負荷問題があり、8台 => 64台になった 調査するとkeys("")を実行している箇所があった 当然お金がかかる(cache.m3.large * 64台 = 約135万円/月) 冗長化しんどいし、設定ファイルの記載も辛い ので、縮小化と冗長化の対処をしたい 現状整理 格納されているデータ フレンド情報、セール情報、ランキング情報 キーの件数 1サーバに8DB、1DBあた

最近必要に迫られて、ようやくRedisをインストールして触ってみました。(Redis童貞からの脱却) 色々と、基本部分ではあるけど、せっかく実際に触りながら勉強したので、このエントリにメモしておこうと思います。 尚、使ってみたRedisのバージョンは、stableの最新版である2.8.7です。(OSは、LinuxのCentOS 6.5) ちなみに、このエントリに書いていないような、Redisの基本的なアレコレについては、WEB+DB Press Vol.73のRedis特集(2.6向けではありますが)にほとんど書いてあるので読むべし。 WEB+DB PRESS Vol.73 作者: 設樂洋爾,白土慧,はまちや2,大和田純,松田明,後藤大輔,ひろせまさあき,小林篤,近藤宇智朗,まかまか般若波羅蜜,Mr. O,川添貴生,重国和宏,柳澤建太郎,奥野幹也,佐藤鉄平,後藤秀宣,mala,中島聡,堤智

去年の内に公開することが出来ず、ずっと下書き状態だったエントリーをちょっとずつ消化していきたいと思います。ネタとして古いものも含まれていたりすると思いますがしばらくご辛抱ください。。 Redis 2.8.9から追加された HyperLogLog をちょっと触ってみました。 環境 * CentOS 7.0 (x86_64) / Intel Xeon E312xx (Sandy Bridge) 2.4GHz 仮想3コア / 2GB RAM * Redis 2.8.17 * redis-py (Python 2.7.5) HyperLogLogとは HyperLogLog (以下HLL)というアルゴリズムはデータマイニング(トラフィックデータの分析等)とか自然言語処理をやってる人ならともかく、Webアプリケーション開発者にはあまり馴染みがないかもしれません。 HyperLogLog – Wiki

ユーザ情報のように ID をキーにした大量のデータを Redis で管理する場合、ひと工夫して Hash 型を使うと、単純に string 型を使った場合に比べてメモリ使用量が激減することを教わったので、追試してみた。 データモデル String 型を使う 各 ID のデータを Redis で管理する場合、素直にやるなら string 型で保存する。 > set object:123456 val123456 OK > get object:123456 "val123456" 非常に原始的なキーとバリューのペア。 Hash 型を使う Redis 2.2 以降では hash が機能改善され、フィールド数が一定数におさまり、フィールドのデータが一定サイズに収まると、メモリ使用量が平均して 1/5 に軽減されている。 Special encoding of small aggregate da

[15487] 04 Aug 21:02:37.523 * 1 changes in 900 seconds. Saving... [15487] 04 Aug 21:02:37.523 # Can't save in background: fork: Cannot allocate memory redis-cli infoしても、使用してるメモリは全体の半分ちょっとだったし、空きは十分にある… 答えは Redis Administration http://redis.io/topics/admin に書いてありました。 原因と解決策 redisのバックアップが走る際、おそらく現状使用している量と同じだけのallocateを要求しているために、redis自体はメモリ使用が50%強だとしても、バックアッププロセスが落ちてしまう模様。 解決は簡単で、Redis Administratio

はじめに Read/Writeともに高速で，様々なデータの持ち方が可能なことでキャッシュDBとして人気のあるRedisですが，何も考えずに実運用システムで使用しているとデータが肥大化してしまい非常に扱いにくくなることがあります． 今回は，データの肥大化とともに顕在化する問題と，データの肥大化に対する戦略についてまとめたいと思います． データの肥大化時に顕在化する問題 何のキーが入っているか分からなくなる Redisはオンメモリ型のKVSであるため，データがある程度増えてくるとサーバのメモリ容量を圧迫し始めます． このような状態で，プロダクション環境に対して keys * などをやってしまうと，一時的にメモリ使用量が跳ね上がり，メモリ使用量を抑えるためにRedisがキーを削除したり，OOM KILLERにRedis Serverごと殺されてしまう可能性があるため，そういったコマンドはうてなく