LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog みなさんこんにちは、LINE LIVE開発のYappoです。 今回は先日リリースされました一般向けのPC配信機能を実装するときに作った簡易的な遅延実行Queueについて書いていこうと思います。 関連エントリ：LIVE PRESS 公式ブログ - ゲーム実況にもぴったり！LINE LIVEでPC横型ライブ配信を試してみよう 背景 今までのLINE LIVEでの配信方法としては、アプリ上で直接配信する方法と、公式アカウント向けの専用画面(LINE OFFICIAL ACCOUNT MANAGER)とRTMPソフト(もしくは専用機材)を利用してPCからの配信する方法がありました。 この2つの方法は全く違う仕組みで実装されるように見え
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
<?php $end_loop = 50000; $ext = new redis(); $ext->connect('localhost'); include 'vendor/predis/predis/autoload.php'; $predis = new Predis\Client('tcp://127.0.0.1:6379'); $ext->set('hogehoge','fugafuga'); echo '--- get ---' . PHP_EOL; // redis extension 読み込み $start = microtime(true); for($i=0;$i<$end_loop;$i++){ $ext->get('hogehoge'); } printf("phpredis %f\n",microtime(true) - $start); // predis 読
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 近年の KVS では割と Redis が覇権を取っていることもあり(当社比), 社内の多くのプロジェクトで Redis を使用するようになりました. ということでノウハウ的なのも溜まってきたのでまとめたいと思います. (大量のユーザーデータを扱うソシャゲにしか当てはまらない部分もあるかと思います) 単純にパフォーマンスを RDB < Redis と思い込んでとりあえずでキャッシュしない 「Redis は速い」と言われますが, インデックスをちゃんと貼った RDB のクエリも そこまで遅いわけではありません. 結局通信コストの方が遥かに大
「これ、同時にリクエスト飛んできた場合って、どうなるの？」 「2つ登録されちゃいますね…」 はじめに Web APIは、リクエストを受け、処理を終えた後レスポンスを返します。モバイルアプリやウェブアプリとセットで開発しているとつい忘れがちになってしまいますが、同時に同じリクエストが飛んできた場合にどういう挙動をするか ということは常に考慮しておかなくてはなりません。「UI上同時にリクエストが送れないから問題なし」では Web APIの設計が不十分です。別の端末から同時に同じリクエストを送ることも可能ですので、UIとは切り離して考えるべきです。 さて、この状況、GETリクエストについては大きな問題にはならないでしょう。いくらリクエストが来てもサーバ側の状態に変化はないので、負荷対策だけしておけば大丈夫そうです。問題はPUTリクエストやPOSTリクエストといった、サーバ側のリソースに変化を及ぼ
2017 - 06 - 02 【資料公開】AWS Summit Tokyo 2017にてDMMのAWS移行について紹介してきました Tweet Share on Tumblr 本日AWSSummitにて岩崎、飯田、西村の3名が登壇して来ました！ 『DMMにおける会員基盤プラットフォームへのAWS導入から活用事例の紹介』 と言うタイトルでお話をさせていただきました。 導入時期が特段早かったという訳ではないですが、 開始してからはかなりのスピード感で移行を行うことが出来たと考えております。 内製DMM API GatewayのAWS移行で特にお伝えしたいポイントは４点 ・オンプレミスのミドルウェア⇒AWSのマネージドサービスの置換 ・EC2パラメータストアによるシークレット値管理 ・ElastiCache Redis Clusterの選定理由 ・Multi-AZ構成環境下のシステム統
WebSocket を利用するアプリケーションは Pub/Sub サーバを使ってスケールアウトさせるのが一般的です。 今回は Redis の Pub/Sub 機能を使って Phoenix の WebSocket をスケールアウトさせてみます。 Phoenix で WebSocket 通信をさせる方法はコチラをご参照ください。 事前知識: WebSocket アプリケーションのスケールアウトについて 通常の Web アプリケーションにおけるスケールアウトは、サーバ台数を増やしてロードバランサでリクエストを分散させる、というのが一般的ですが、WebSocket アプリケーションではこの手法が使えません。 なぜかというと、WebSocket アプリケーションはコネクションをサーバ内で管理するステートフルな作りになっているためです。冗長化させたサーバにリクエストを分散させてしまうと、他サーバで接続
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
ゴクロの大平です。ごくろうさまです。 Redisは高速で、かつデータの永続化や、複数のデータ型によるストア(list,set,sorted set等）も対応しており、機能的が豊富ということから愛用者の多いKVS実装の一つだと思います。 特に私のようなアプリケーションエンジニアの人間にとってはデータ型のバリエーションの豊富さが便利さを感じる部分で、たとえばlistを用いてタイムライン的な情報や履歴情報の管理、sorted setを用いてランキング情報の管理、などのようにアプリケーションの需要の多くにRedisが対応することができます。 これらの情報を登録する際のフローとしては自作のアプリケーションから直接、というケースが多いと思いますが、せっかくFluentdのような便利なlog collector実装があるので、FluentdとRedisを組み合わせる事でカジュアルに情報の蓄積を行いたい…
去年の内に公開することが出来ず、ずっと下書き状態だったエントリーをちょっとずつ消化していきたいと思います。ネタとして古いものも含まれていたりすると思いますがしばらくご辛抱ください。。 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
2. システム概要 homingは、アメーバピグ関連サービスのいずれかにログインしているユーザに対して、各サービスの通知情報を横断的にプッシュ通知します。 システムの構成は以下の通りです。 図2-1. システム概要 2-1. APIサーバ ユーザへの通知要求を受け付けるREST fullなAPIを備えたWebサーバです。 Node.jsのClusterによる、master/worker構成で稼働します。 通知要求はワーカプロセスで処理します。 図2-2. APIサーバ 2-2. Redisサーバ（データストア用） 一時的なデータをストアするためのRedisサーバです。 sentinelプロセスによる、master/slave構成で稼働します。 ストアされたデータはメモリ上のみで管理し、ディスクへの書き込みは行いません。 以下の情報を管理します。 ユーザのオンライン情報 ユーザIDの索
こんにちは、フルボッコヒーローズのフラゲガチャの中の人です（でした） 一応メインエンジニアでした。（ぼっち） 本日 関西ソーシャルゲーム勉強会・２０１４夏 に登壇させてもらいました。 関西ソーシャルゲーム勉強会・２０１４夏 #ksgstudy - Togetterまとめ その時に自分が関わっていたフライングガチャについて話したので資料を公開します。 最近他社さんでも弊社のフラゲガチャをパクったシステムをどんどん作っているようなので、もしよければ参考にしてみてください。（ここまで完全にRedisに極振りしてると逆に真似しようと思っても出来ないと思うけどｗ） スライド Resemaraを支えた技術 フライングゲットガチャの舞台裏 #ksgstudy #ドリコム from Go Sueyoshi (a.k.a sue445) 資料に書き忘れたこと 資料内の表記ぶれてますが「リセマラガチャ＝（フル
ElastiCache Redis の AOF 周りを自分用にまとめた クラスターを構築したとしても AOF はデフォルトで OFF なだけで、有効に出来る。 AOF のメリットとしては AWS 側の OS や Redis が自動でリブートしたとき等にかなり有効。 AOF があるので「一時的な接続」が切れるだけで自動で復旧することが出来る。 read replica が master へ昇格する入れ替えは自動ではなく手動になる。 AOF が有効では無い場合、 master で OS reboot 等が起きた際、 master は read replica からデータをコピーするため、read replica 側にデータの転送が終わる前にシャットダウンした場合はデータの一部がロストする可能性がある。 AOF が有効であっても、ハードウェア障害が起きて master を復旧できない場合は新規で
RedisのHash型を活用するとメモリ使用量が激減
ユーザ情報のように 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
インフラストラクチャー部 星野(@con_mame)です。 クックパッドでは、AWSを活用してサービスを行っています。 現在クックパッドでは、各種キャッシュにMemcachedやRedisを使用しています。 しかし、用途の多様化やアクセス数の増加などでこれらのサーバのインスタンス数が増加し管理コストが増加してきています。 特にRedisサーバのインスタンス数が増加しており、AWSのサービスの中でもキャッシュのサービスを提供しているElastiCache for Redisへの置換えを検討しています。 ElastiCache for Redisは、一部管理系のコマンドがrenameされており使用出来ませんが、通常のRedisと同じ物で、現在Version 2.6.13と2.8.6が使用出来ます。 SlaveにあたるものはReplication Groupという形で指定でき、Replicati
redisのデータ型の概要と利用例まとめ
RDBMSの代替としてredisを使うことになり、DB設計する上で考慮すべき型の概要と利用法をまとめる。 間違いやもっと良い使い方があれば教えてください＾＾ ■String - 文字列型 ・概要 １つのkeyに対して1GBまでの文字列を１つ持つことが出来る。基本。 ・使いどころ JPEGイメージ、シリアライズされたオブジェクト情報など単体で持つ時。 （他の型の基本になってるので、これ単体で使うと言うより応用する感じ？単体で十分なとき等で使う？） ■List - リスト型 ・概要 文字列型のリスト。値を追加した順序が保持される。値は重複OK！ リスト前後からの出し入れ、リストの範囲指定での取り出し等の操作ができる。 ・使いどころ 時刻または日付を保持するような情報。TwitterのTLの様な追加順に並ぶ一連のデータ。 要素の追加削除がリストの先頭や末尾（そうでない場合は適さない）に高頻度に発
翻訳について¶ このドキュメントは、RedisのWiki(http://code.google.com/p/redis/wiki/)の内容を参考にしながら、構成などはSphinxに合わせつつ翻訳しています。また、必要に応じて、配布物の中のファイルなども引用しながら訳しています。
仕事でRedisを使うことになったのですが、RDBMSに慣れてしまっていたのでKeyValue型データベースの設計思想に馴染むのに時間がかかってしまいました。 せっかくなのでKeyValueの型について私の個人的な考え方を整理してみました。KeyValueを学ぶ人にとって少しでも足しになれば幸いです。 KeyValueデータベースの考え方 RDBであれKeyValueであれやっていることは「データの位置」と「データの内容」を保存しているだけですから理論的には同じ事ができるはずです。ただ、データ構造の違いからRDBとKeyValueには向き不向きがある様です。 RDBが得意な分野 ・条件をたくさんつけて絞り込む検索。 ・複雑なデータを多角的に分析する検索。 KeyValueが得意な分野 ・質問と答えが1対1に近いデータの検索。 ・単純なデータをただ取り出すだけの検索。 例えば都道府県から県庁
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
