Scaling Slack’s Job Queue – Several People Are Coding
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
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
OpenResty で証明書の動的読み込み - Qiita
ssl_certificate_by_lua* ディレクティブを使用することで、証明書を動的に読み込ませることが可能です。 例 クライアントから送られてきた ClientHello の SNI 拡張に含まれているサーバ名に対応する証明書を読み込んでいます。 対応する証明書が見つからない場合は ServerHello を返さずに、Internal Error (80) のアラートが返ります。 http { lua_shared_dict certs 10m; server { listen 10443 ssl; ssl_protocols TLSv1.2; ssl_certificate certs/www.example.com.pem; ssl_certificate_key certs/www.example.com.key; ssl_session_tickets on; ssl_s
RQ: Simple job queues for Python
RQ (Redis Queue) is a simple Python library for queueing jobs and processing them in the background with workers. It is backed by Redis and it is designed to have a low barrier to entry. It can be integrated in your web stack easily. RQ requires Redis >= 3.0.0. Getting started First, run a Redis server. You can use an existing one. To put jobs on queues, you don’t have to do anything special, just
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
LINEの100億超/日メッセージを支える Redis・HBaseのスケールアウト・アップ戦略 #linedevday - Togetterまとめ
リンク linedevday.linecorp.com LINE DEVELOPER DAY_2015 Tokyo LINE DEVELOPER DAY_2015 Tokyo is a technical conference in which our teams of engineers share their various experiences and also address open issues. Shunsuke.N A-5 HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ HALL A 13:30 - 14:10 "LINEのメッセージングストレージとしての難しい要求に対して、RedisとHBaseを利用してどのように問題を解決してきたかについて紹介します。 最初にLINEでのストレージのユースケースを共有した上で、ストレージの可用性を
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
Jepsen: Redis
Previously on Jepsen, we explored two-phase commit in Postgres. In this post, we demonstrate Redis losing 56% of writes during a partition. Redis is a fantastic data structure server, typically deployed as a shared heap. It provides fast access to strings, lists, sets, maps, and other structures with a simple text protocol. Since it runs on a single server, and that server is single-threaded, it o
「fluentd」と「Storm」の比較について - Tous Les Jours 攻防記
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching
GitHub - wataru420/redisTest: for test Redis speed.