みうら かずひと(SonarQube好き) @kazuhito_m 本日は「FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会」という勉強会に来ています。「抽選に当たった」のと「内容聴いてきて下さい」という(グランド)オーダーから上ました。余すところなく聴いていきたいと思います! connpass.com/event/91736/ #ゲームサーバ勉強会 pic.twitter.com/MnXY6qmLso 2018-08-03 19:10:23
![FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会まとめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/c80c0d8ff64228ef0e28671ba0f74531d9ea4fd6/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F4b011218e8b957e229f079040ec0cfb5-1200x630.png)
Robustly Handling Billions of Tasks in Milliseconds Using Kafka and Redis Slack uses a job queue system for business logic that is too time-consuming to run in the context of a web request. This system is a critical component of our architecture, used for every Slack message post, push notification, URL unfurl, calendar reminder, and billing calculation. On our busiest days, the system processes o
redis 4.0 GA release ついに昨日(2017/07/15)に、redis 4.0のstableがリリースされました。 今までのredisと何が変わったのか?というのを、軽くまとめたいと思います。 間違いなどありましたら、指摘いただけると幸いです。 前回のqiita記事 プロダクションで2年間RedisClusterを運用してみて release notes 一部抜粋すると Note that 4.0 is probably one of the most extreme releases of Redis ever made in terms of changes inside the internals: all the aggregated data types no longer use Redis Objects structures but directly S
A high performance, linearly scalable, highly available (HA) and distributed open-source database with support for pluggable persistent and in-memory storage engines. THIS PROJECT IS NO LONGER MAINTAINED. Please use the upstream repo from Netflix. DynomiteDB is a high performance Dynamo layer that adds data replication and sharding to Redis and other single-server storage engines, plus the ability
EngineeringMoving persistent data out of RedisHistorically, we have used Redis in two ways at GitHub: We used it as an LRU cache to conveniently store the results of expensive computations over data originally persisted in… Historically, we have used Redis in two ways at GitHub: We used it as an LRU cache to conveniently store the results of expensive computations over data originally persisted in
大平です。今回はさだまさしネタは特に無しです。 先日、サービスのクローラーで使用しているID生成器について置き換えを行いました。非常に地味な話になりますが、本記事ではその辺の内幕の話をしたいと思います。 ID生成にまつわる苦悩 弊社ゴクロの提供しているSmartNewsは表向きはニュースアプリですが、裏側の仕組みは検索エンジンに近似しています。ユーザーの方々の興味関心や、アクセス傾向をクエリーとし、その内容に応じた話題のニュースを検索結果として返却する、という風に捉えていただくと、なんとなく私が言わんとしている事を想像していただけるかと思います。 SmartNewsはTwitterのつぶやき情報を用いたトレンド分析をベースとしており、話題になっているニュースを選定するためには、大量のTwitter上のtweet、ならびにその中に含まれているURLに対してクロールを行う必要があります。日々配
無料でそれなりなメモリとコネクション数を確保できる Heroku Redis。最近できたばかりのアドオンで情報がなかなか出回ってないが、ここに落とし穴があるので利用する場合は注意。 注意点は以下の2点だ。 アイドル状態のコネクションをデフォルトではKillしない Heroku Redis は アイドル状態のコネクションをデフォルトではKillしない。これはどういうことかというと、つなぎっぱなしになって、最終的に限界である20コネクションに達し、アプリケーション全体が落ちる、ということが起きる。 しかもこの復旧はなかなか大変で、コマンド経由でRedisを再起動ということができないのでびっくりすることになる。対応するなら、一度Redisアドオンを削除し、再度追加する、といったところか。もちろん Redisに保存していたデータは全て消える。 そんなことにならないようにHeroku Redisを入
« Sponsored Post: Apple, Wargaming.net, PagerDuty, HelloSign, CrowdStrike, Gengo, ScaleOut Software, Couchbase, Tokutek, MongoDB, BlueStripe, AiScaler, Aerospike, LogicMonitor, AppDynamics, ManageEngine, Site24x7 | Main | Stuff The Internet Says On Scalability For April 25th, 2014 » Here's an Update On Disqus: It's Still About Realtime, But Go Demolishes Python. How do you add realtime functionali
UPDATE: I have open-sourced a Java implementation of the below principles called “RedisQ“. Enjoy! Redis is a high performance key-value datastore that differs from other key-value solutions in the way it handles values. Instead of just storing values as simple strings, it recognizes multiple specific data types such as Lists, Sets, Hashes (maps), Strings or Numbers. Each data type has its own set
Node におけるスケールアーキテクチャ考察(Scale 編)というエントリーを読んで、RedisはPub/Sub型通信をサポートしているという事を知りました。エントリーでも言及されているように、Pub/Subを使えば Node.js + WebSocket サーバをスケールする際に、中継サーバの役割を果たす事が出来るはずです。 そんな訳で実際に Node.js と Redis を使って Pub/Sub の実験を行なってみました。ユーザが別々のNode.jsサーバに接続していてもWebSocketを通してメッセージのやり取りを出来るようにします。 イメージとしてはこんな感じです。 下準備# Ubuntuの場合は apt-get で1発でインストールする事が出来ます。 $ sudo apt-get install redis npmでredisモジュールをインストールします。 $ npm i
Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く