概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
こんにちは。初投稿です。 2012年新卒入社の竹内です。入社当時を振り返るとOracle10g,11gを良く利用していおり、データモデリングなどテーブル設計が好きで、2018年4月ぐらいまでRDBとバッチに浸ってました。 さて、現在プロジェクトでRedisを使っているのですが、いままでRDB人間だっただけにKVSやRedisならではの特徴に四苦八苦してます。 苦しんだ分、色々な知見を得ることができているので、その内容をご紹介します！ 対象者 Redisの業務システム導入を検討している方 RDBとRedisの違いを知りたい方 現場的なRedisの利用方法を知りたい方 書いてないこと データ型やコマンドなど、HelloWorld的に公式ドキュメントを見て得られる情報 インストールなど、Redisを利用できるまでの手順 フェイルオーバーやバックアップをはじめとする運用に関する内容 データ永続化に
まえがき HDDやSSDはシステムの中でもボトルネックとなる一番データの転送速度が遅い記憶媒体だ。 オペレーティング・システムには記憶媒体による遅延を減らすためキャッシュを利用するなど I/Oアクセスを最小限に留める工夫が施されている。そんな中でもI/OスケジューラはI/Oリクエストの処理順を入れ替えたりリクエストを一つにまとめたりすることにより応答速度やスループットを向上させる機能だ。ディスク・スケジューリングとも呼ばれることがある。 数年前まではLinuxカーネルは cfq noop deadline と言ったI/Oスケジューラを搭載していたが、昨今のスケジューラはだいぶ変わっているようだ。 Linuxカーネル ver 3.13 からCPUの多コア化、SSDやPCIeなどの高速な記憶媒体の普及に対応するために旧来の単一キュー処理からマルチキュー処理をする Blk-mq（Multi-Qu
HQというGoで実装したジョブキューを公開しました。 github.com WebのUIもあります。 概要 以下の特徴があります。 Goによる実装で、シングルバイナリ。 スタンドアロンのHTTP APIサーバー。ジョブのデータベースも組み込みであるため、別途特別な依存を必要としないで動作する。 シンプルでプログラミング言語非依存。HTTP APIでジョブを投入し、ジョブはHTTP POSTメッセージをワーカーアプリケーション(Webアプリ)に送信するというアーキテクチャ。 フロントエンドとしてCLIとWebUIを組み込みでサポート。 上記のリポジトリのREADMEにも載せてありますが、ざっくりジョブのフローを図解すると、以下のようなアーキテクチャになっています。 HTTP APIでジョブ(JSON)を投入します。HQはジョブを取り出し、ジョブに記載されたURLにHTTP POSTして、別途
Amazon SQSでFIFOだからってシステム全体が Exactly-Once になると思ったら大間違いだっていう話 - Smoky God Express
TL; DR Amazon SQS で Exactly-Once なキューを使おうとも冪等な処理を書くべき キューが Exactly-Once であるという性質はシステム全体が Exactly-Once になることを保証できない 結局マルチデータソースへの書き込みの問題が残る Designing Data-Intensive Applications (邦訳: データ指向アプリケーションデザイン） が良書でした 邦訳は未読1ですが原著の内容がいいのできっとだいじょうぶでしょう Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 作者: Martin Kleppmann出版社/メーカー: O'Reilly Media発売日: 2017/
テレビで素敵なサイトが紹介されていたのでアクセスしてみたら、なかなかレスポンスが返ってこなかったりステータスコード503になったりすることってありますよね。 テレビで紹介されたことで多くの人がサイトにアクセスした結果、そのサービスのキャパシティを超えてしまったわけです。 どうなるとキャパシティを超えるのでしょうか？ また、いつからレスポンスが遅くなるのでしょう。 効果的にリクエストをさばくにはどうしたらいいのでしょう。 Photo by Roman Arkhipov on Unsplash 待ち行列理論を使って理想的なモデルからこれらを考えてみたいと思います。 待ち行列理論はコンピュータサイエンスをやってきた人はみんな触れたことがあるとは思いますが、大石の場合はそれが何十年も(!)前のことなのであらためて思い出してみました。 モデル Railsでサービスを提供するとき、rackサーバとして
Amazon Web Services ブログ Amazon DynamoDB での優先度付きキューの実装 キューイングは、分散処理システムで計算コンポーネントを分離するために一般的に使用されるソリューションです。これは、サーバーレスおよびマイクロサービスアーキテクチャで使用する非同期通信システムの形式です。メッセージは処理のためにキューで待機し、1 人のコンシューマーが受信するとキューから出ます。このタイプのメッセージングパターンは、ポイントツーポイント通信と呼ばれます。 この記事では、他の大規模なキューイングシステムで行うように、Amazon DynamoDB テーブルのいずれかを、エンキュー (メッセージをキューに配置) とデキュー (メッセージを読み取り、キューから削除) が行えるキューに変換する方法について説明します。 DynamoDB は、任意の規模で 1 桁のミリ秒のパフ
「snmalloc: A Message Passing Allocator」という論文を読んだのでその紹介です。本論文は ISMM (International Symposium on Memory Management) 2019 に採択されており、論文とソースコードは GitHub (microsoft/snmalloc) で公開されています。リポジトリ名から分かる通り、著者の多くが Microsoft Research に所属しています。 免責 読み間違えている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue や Twitter へお願いします。 更新履歴 2019/07/08 bump pointer と free list の next entry pointer を判定する方法について追記 2019/0
インフラのリリース自動化戦略とその行き着く先 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。 本番リリースってドキドキしますよね。 本日はkintone.comのリリース自動化と、その戦略についてお話します。 kintone.comのCI/CDパイプライン kintone.comのインフラ構成はモノレポで管理しており、AWSの構成や、Kubernetes上にデプロイするサービスなどが1つのレポジトリに存在します。 現在のkintone.comは、開発環境、ステージング環境、本番環境の3つがあります。 適用タイミングをずらすことによる環境間の乖離を防ぐため、各リリースはすべての環境に適用することとしました。 開発環境でしばらく寝かせたい変更は、機能フラグやカナリアによって切り替えます。 CI/CDパイプラインは以下のようになっています。 それぞれの環境に順に適用し、本番環境適用後にテストが通れば無事リリース完了です。 kintone.comのCI
状態機械を合成してデッドロックを検出できる Go 言語パッケージを作ってみました - チェシャ猫の消滅定理
はじめに マルチスレッドで動作するプログラムの設計は難しい問題です。個々のスレッドの動作は単純に見えても、複数が並行して動作する場合の動作は組み合わせ論的に複雑になります。また、タイミングに依存する不具合は狙って再現することが難しく、通常の単体テストによる検出にも限界があります。 そんなとき、有効な手法がモデル検査です。システムの取りうる状態をあらかじめ網羅的に探索することで、「実際に動作させた際にごく低い確率で踏むバグ」であっても、動作させることなく設計段階で発見することが可能になります。 ところでちょうど先日、デッドロック発見器を自作するハンズオンに参加する機会がありました。内容は非常にシンプルなモデル検査器を実装するというもので、せっかくなのでそのときの成果物を Go のパッケージとしてまとめたものを以下に公開しました。 github.com 以下、このパッケージで何ができるのかを具
SQS を使った Python の非同期ワーカーは ndkale しかない - kawasin73のブログ
誰一人見捨てない!!! どうも、かわしんです。Celery は見捨てるんです。 この記事は Pythonその2 Advent Calendar 2019 の 15 日目の記事です。 やや強めのタイトルですが、AWS SQS を使った非同期ワーカーでまともな実装は ndkale しかないという内容です。Celery は論外です。 github.com 前半はディスってばっかりなので、ndkale のことだけを知りたい場合は途中の「大本命 ndkale」から読んでください 前提としての欲しい機能 まず、諸々をディスる前に非同期ワーカーとして欲しい機能をあげておきます。 正しく SQS を使って信頼性のあるタスク実行をする 即時再実行をする 複数のキューを使い分ける。また同じタスクでも動的に利用するキューを切り替えたい Dead Letter Queue も使えると嬉しい まず Celery を
Kernel Queue: The Complete Guide On The Most Essential Technology For High-Performance I/O When talking about high-performance software we probably think of server software (such as nginx) which processes millions requests from thousands clients in parallel. Surely, what makes server software work so fast is high-end CPU running with huge amount of memory and a very fast network link. But even the
「マイクロサービスとメッセージングのなぜ [概要編]」はこちらです。 レッドハットでインテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 概要編ではメッセージングの良い面ばかりに焦点を当ててきましたが、今回の疑問編ではメッセージングを検討し始めたときに疑問に思ったり困りがちなことを説明したいと思います。概要編とは異なり、細かな技術的内容も含まれますので、その時々で必要な部分や興味ある部分だけ読んでいただければと思います。 (ところで、当初は前回を前編、そして今回を後編にして終わらせようと思っていたのですが、今回もあまりに長くなってしまったので、構成を変えたのでした。 このため当初の前編は概要編と名前を変更しています。) ではまず主に疑問とされることを確認して、その後に対処法を見ていきましょう。 メッセージングを利用することによる主な疑問 対処方法 Q1:
![マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f80853750b1c5f85bbe4ae4c26691362ff89c530/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20191208%2F20191208182318.jpg)
[アップデート] Lambda イベントソースに FIFO キューが指定できるようになりました | DevelopersIO
関数の内容については、大栗の記事同様に以下のとおり設定しました。 from __future__ import print_function def lambda_handler(event, context): for record in event['Records']: print ("test") payload=record["body"] print(str(payload)) 次にイベントトリガーを設定します。「トリガーを追加」をクリックします。 トリガーに「SQS」を選択し、事前に作成しておいた FIFO キューを指定します。（記憶がうろ覚えですが、以前はここの選択対象に FIFO キューは表示されなかったと思います）。バッチサイズは 5 で検証してみました。 これで FIFO キューをトリガーとした Lambda 関数がセットできました。次にキューにメッセージを投入して、
![[アップデート] Lambda イベントソースに FIFO キューが指定できるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/25fe5c76b0259f67cfbb0286bc1fd48c715f810f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Faws-lambda.png)
マルチテナントを支えるkintoneのメール送信戦略 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！kintoneチーム DevOpsエンジニアの @szkayeah です。 Webサービスを使っていると、何らかの操作をトリガーにメールが届く時がありますよね。サイボウズの kintone(キントーン) も例外ではありません。「データを登録したよ」とか「Aさんからコメントがあったよ」など主に通知のために普段から多数のメールが送られています。 kintone は、エンドユーザーが業務アプリを自由に作成できるマルチテナント型のクラウドサービスです。ゆえに、テナントによってご利用方法が多種多様に渡ります。メールでの通知に関してもエンドユーザーが柔軟に設定できるため、テナントごとにメール送信量に差があるといった現状があります。 本日は、私のチームが運用している AWS版kintone でメールを安定して送るためにどんな仕組みを作っていったかを紹介します！ メールは非同期で順次送信されて
Introduction⌗ Postgres queue tech is a thing of beauty, but far from mainstream. Its relative obscurity is partially attributable to the cargo cult of “scale”. The scalability cult has decreed that there are several queue technologies with greater “scalability” than Postgres, and for that reason alone, Postgres isn’t suitably scalable for anyone’s queuing needs. The cult of scalability would rathe
CompanyEnterpriseOpen SourceGitHub merge queue is generally availableSupercharge pull request merges on your busiest branches by enabling your team to queue. General availability of GitHub’s merge queue means good-bye to traffic jams on your team’s busiest branches. No more rushing to merge your pull requests before someone else merges theirs 🥵. Turn on GitHub’s merge queue today and accelerate y
Kaigi On Rails
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
ぶらり組込みRustライブラリ探索の旅 BBQueue編 -スレッドセーフなSingle Producer Single Consumer Queue- - Nature Engineering Blog
ファームウェアエンジニアの中林 (id:tomo-wait-for-it-yuki) です。あけましておめでとうございます。 今年の目標はNature Remoのファームウェア開発にRustを導入すること、です。そこで引くに引けない状況を作り出すためにRustに関するブログエントリを書き、既成事実を積み上げていきます。 ぶらり組込みRustライブラリ探索の旅、と題して組込みRustで使えるライブラリをゆるく紹介していくシリーズをやりたいと思います。第一弾はBBQueueです。 BBQueue 本エントリ内で紹介する使い方や内部実装は、v0.5.1をもとにしています。 github.com https://docs.rs/bbqueue/0.5.1/bbqueue/ 特徴 BBQueueはno_stdで使えるだけでなく、スレッドセーフで、排他制御なしに使える Single Producer
こんにちは、WEARバックエンドブロックの天春（@AmagA001）です。バックエンドの運用・開発に携わっています。WEARはサービス開始から10年ほどの古いVBScriptを使った環境からRuby on Rails環境にシステムリプレイスを行なっています。本記事では、リプレイスの中でも既存環境が複雑で問題や課題が多くあったPUSH通知システムのリプレイスについてご紹介します。 目次 目次 PUSH通知システムとは リプレイス前のPUSH通知システム リプレイス前のPUSH通知システムの問題点 通知送信バッチのスケールアウトが出来ない 障害対応・運用が難しい状況 複数の開発言語による運用・改修コストが高い ステージング環境で通知確認ができない リプレイスの背景 リプレイス後のPUSH通知システム 非同期システム・EKS導入 既存システムの問題解決 バッチのスケールアウトが出来ない 障害対応
goqite
goqite (pronounced Go-queue-ite) is a persistent message queue Go library built on SQLite and inspired by AWS SQS (but much simpler). $ go get github.com/maragudk/goqite See goqite on Github Don't like queues? Get the Skip function to skip the queue for your messages! Example package main import ( "context" "database/sql" "fmt" "log" "time" _ "github.com/mattn/go-sqlite3" "github.com/maragudk/goqi
Amazon MQ Update – New RabbitMQ Message Broker Service | Amazon Web Services
AWS News Blog Amazon MQ Update – New RabbitMQ Message Broker Service In 2017, we launched Amazon MQ – a managed message broker service for Apache ActiveMQ, a popular open-source message broker that is fast and feature-rich. It offers queues and topics, durable and non-durable subscriptions, push-based and poll-based messaging, and filtering. With Amazon MQ, we have enhanced lots of new features by
LaravelではJob(ジョブ)もQueue(キュー)のどちらも使用することなくアプリケーションの構築を行うことができるので、設定したこともなければ存在さえしらない人が多いかもしれません。本文書では入門者でもわかるようにJobの作成方法からQueueの使い方まで簡単なコードを使って説明を行っていきます。バージョンによってコアな機能の違いはないため一度学習して理解することができれば長く活用できる知識になります。これまで使ったことがない人もぜひこの機会にLaravelのQueueにチェレンジしてください。 用語の確認 Queue(キュー)、Job(ジョブ)と Worker(ワーカー) とは キューは処理が実行されるのを待っているジョブのリストです。一度理解すればこれだけの文章でキューとジョブをイメージすることができますが初めての人であればキーとジョブをイメージするのは難しいと思うので身近なコ
In the ever-evolving world of cloud software, Deno aims to radically simplify. Leveraging public cloud infrastructure has traditionally demanded sifting through layers of boilerplate code and intricate configurations, often monopolizing a significant chunk of the developer’s time and energy. Our goal is to distill these intricacies into user-friendly primitives, enabling developers to design, refi
本連載では分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っています。 今回は、サーバー上で実行されるタスクを管理するシステムであるジョブキューについての全般と、そのライブラリであるBullMQについて紹介します。 ジョブキューとは ジョブキューは、Webサーバー上で発生する様々なタスク（ジョブ）を管理するシステムで、タスクを複数のサーバーで分散して処理させたり、タスク失敗時にリトライしたりする機能を持ちます。 Misskeyでもジョブキューを活用しており、例えばActivityPubにおけるアクティビティの受信および配送や、ユーザーデータのインポートエクスポート処理をジョブとして管理しています。 Misskeyが使っているジョブキューのライブラリであるBullMQは、毎日指定した時刻にジョブを実行する機能などもあるので、サーバーの統
Amazon SQSデッドレターキューにメッセージが入ったらSlackに通知するしくみをAWS CDKで構築する | DevelopersIO
こんにちは。サービスグループの武田です。 Amazon SQSやAWS Lambdaなどには、処理が失敗した際にメッセージを退避させるしくみとしてデッドレターキュー（以下、DLQ）というものが用意されています。DLQを用意しておくことで無制限のリトライを防止したり、デバッグに役立てることができます。 とはいえ、肝心のDLQにメッセージが入ったことを検知できなければ何の意味もありません。今回はDLQにメッセージが入った際に、Slackに通知されるしくみをAWS CDKを利用して構築してみました。 なお、ソースコードはGitHubに上がっています。 TAKEDA-Takashi/aws-cdk-sqs-dlq-alert-slack 環境 今回は次のような環境で検証しました。 $ node -v v10.19.0 $ sw_vers ProductName: Mac OS X ProductV
皆さん、普段 Python でコードを書くときはちゃんと型を書いてますよね? まだ型の書き方を知らない場合は Software Design 2020年 5月号の『Python でも型チェックしよう』を読むといいと思いますよ (宣伝)。 レビューのお手伝いをした『Python でも型チェックしよう』(by @t2y)が掲載されているSDが発売されました。型ヒントを使ってみたい方におすすめです。また、3.8で導入された Protocolなども紹介されており、すでに使っている方にもお勧め！ / Software Design 2020年5月号 https://t.co/JL5GgO0mcq — tk0miya (@tk0miya) April 18, 2020 私はコードに型をつけ始めておおよそ 3年ぐらいになるのですが、いまでは型がないと落ち着かなくなっています。 コード規模がある程度大きく
RQ は、Redis をメッセージブローカー兼データストアとして利用することで分散タスクキューを実現する Python ライブラリ。 RQ: Simple job queues for Python Redis はリスト型の LPUSH と RPOP だけでタスクキューっぽい動きができて、RQ はそれを薄くラップしただけのシンプルな API という印象。 Celery + RabbitMQ の方が高機能だが、シンプルなタスクキューでいいという場合には RQ の方がとっつきやすい (と思っている)。 動かしてみる 手動でプロセスを複数立ち上げるのも面倒なので、 Docker Compose でサクッと試してみる。 実際に運用する際はちゃんと Redis サーバと Worker サーバ複数を用意してやるはず。
Learn about the background, challenges, and future of Airbnb’s distributed scheduling and queueing system. IntroductionAsynchronous background jobs can often dramatically improve the scalability of web applications by moving time-consuming, resource-intensive tasks to the background. These tasks are often prone to failures, and retrying mechanisms often make it even more expensive to operate appli
Amazon SQS Now Supports a High Throughput Mode for FIFO Queues (Preview)
Amazon SQS now supports a preview of a high throughput mode for FIFO queues, allowing you to process up to 3000 messages per second per API action. This is a tenfold increase compared to current SQS FIFO queue throughput quota. Amazon SQS is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. Amazon SQS off
[Kinesis Video Streams] Mac上で各種ソースからの動画のアップロード 〜 kvssinkを利用する場合のGStreamerの使用方法 | DevelopersIO
[Kinesis Video Streams] Mac上で各種ソースからの動画のアップロード 〜 kvssinkを利用する場合のGStreamerの使用方法 1 はじめに CX事業本部の平内（SIN）です。 Kinesis Video Streamsでは、プロデューサーの一つとして、標準的なストリーミング管理ライブラリであるGStreamerのプラグインとして利用可能なシンクエンメント(kvssink)が提供されています。 参考：例: Kinesis ビデオストリーム プロデューサー SDK GStreamer プラグイン GStreamerでは、gst-launch-1.0を使用して、コマンドラインから軽易に下記のような構成を実現することが可能になります。 各種リソース -> フィルタ、変換など -> kvssink -> Kinesis Video Streasms 今回は、Ma
![[Kinesis Video Streams] Mac上で各種ソースからの動画のアップロード 〜 kvssinkを利用する場合のGStreamerの使用方法 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/171947bc554852c4101dbd1e0f86883e3a59515e/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F04%2Famazon-kinesis-video-streams.png)
はじめに フューチャーAdvent Calendar 2019 の4日目ですが、遅れて5日目に書いています。 この記事ではPub/Subを業務利用しようとして難しさを感じた点についてまとめ、どんな苦労をしたのかをちょっとだけ書きます。 背景としてはmosquittoやkafkaといったPub/SubブローカーからPubあるいはSubするアプリケーションをGoで作成してどのような形で業務利用できるかを考える機会がありました。 Pub/Subメッセージングモデルとは 以下の３つの要素で構成されるモデルです。 メッセージを仲介するBroker メッセージをためている部分 Topicという論理的なチャンネルにメッセージを紐付けて管理する メッセージを発信するPublisher Topicを指定してメッセージをBrokerに投げる メッセージを受信する（取りに行く）Subscriber Topicを
新機能 – Amazon SQS 標準キューに拡張されたデッドレターキュー管理エクスペリエンス | Amazon Web Services
Amazon Web Services ブログ 新機能 – Amazon SQS 標準キューに拡張されたデッドレターキュー管理エクスペリエンス 何十万人ものお客様が Amazon Simple Queue Service (SQS) を使用してメッセージベースのアプリケーションを構築し、マイクロサービス、分散システム、サーバーレスアプリケーションの分離とスケーリングを行っています。キューコンシューマーがメッセージを正常に処理できない場合は、メッセージをデッドレターキュー (DLQ) に保存するように SQS を設定できます。 ソフトウェア開発者やアーキテクトであれば、DLQ 内の消費されなかったメッセージを調べて確認し、処理できなかった理由を解明して、パターンを特定し、コードエラーを解決して、最終的に元のキューでこれらのメッセージを再処理したいと考えるでしょう。これらの消費されなかったメッ
AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴 - Qiita
著者: 伊藤 雅博, 株式会社日立製作所 はじめに AWSでストリーム処理を実現する際は、データをキューイングするメッセージングサービスと、キューイングしたデータをストリーム処理するサービスを組み合わせることが一般的です。本投稿では、AWSが提供する各メッセージングサービスのうち、ストリームデータを扱う際によく活用されている下記サービスの特徴を紹介します。 Amazon Kinesis Data Streams (KDS) Amazon Managed Streaming for Apache Kafka (MSK) Amazon Simple Queue Service (SQS) なお、本投稿の内容は2020年中頃の調査結果をベースに、いくつか更新を加えたものです。AWSのサービス仕様は随時更新されるため、最新の仕様とは異なる場合があります。最新の情報はAWSの公式ドキュメントをご参照
GitHub - hatchet-dev/hatchet: A distributed, fault-tolerant task queue
Hatchet replaces difficult to manage legacy queues or pub/sub systems so you can design durable workloads that recover from failure and solve for problems like concurrency, fairness, and rate limiting. Instead of managing your own task queue or pub/sub system, you can use Hatchet to distribute your functions between a set of workers with minimal configuration or infrastructure: What Makes Hatchet
Laravelで非同期実行する | RE:ENGINES
はじめに バックエンドの実装に関して、時間がかかる処理を行う場合、非同期に処理したいケースがあると思います。今回はLaravelで非同期に処理するための手軽な方法を紹介します。 動作環境 本記事ではPHP 7.2、Laravel 5.5の環境を想定しています。 準備 非同期に処理するに当たりジョブのキューを管理する方法としては、データベースを利用する方法やRedisを利用する方法などがあります。Laravelでは標準でデータベース、Redis、Amazon SQS、Beanstalkdを利用することができますが、今回は最も手頃なデータベースを使用する実装を紹介します。 デーブルの作成 以下のコマンドを実行してキューを管理するためのテーブルを作成します。
JMSJobQueueBundleユーザーのためのMessengerコンポーネント移行ガイド（Symfony4時代のasyncジョブ実行入門） | QUARTETCOM TECH BLOG
JMSJobQueueBundleユーザーのためのMessengerコンポーネント移行ガイド（Symfony4時代のasyncジョブ実行入門） SymfonyでWebアプリケーションを作るとき、HTTPリクエストから直接実行するには重い処理があったらどうするか？ 以前の記事 でも書いた通り、非同期処理を実装することが多いですね。 Symfony2時代の非同期処理のスタンダードは JMSJobQueueBundle でした。 JMSJobQueueBundleも一応Symfony4に対応してくれたのですが、不具合があって利用できない時期が長く、メンテナーの方が忙しいようでプルリクエストへの返信も遅れがちでした。乗り換え先をどれにするのが良いかTwitterで聞いてみたところ、 Symfony\Component\Messenger を使うと良いよというアドバイスをもらい、使ってみたらとても良
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
様々なrate limitアルゴリズム - Carpe Diem
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
システム開発で得たRedis利用ノウハウ | フューチャー技術ブログ
Linux：昨今のI/Oスケジューラ事情 2020
Goでジョブキューを実装した - オープンソースこねこね
どれだけリクエストをさばけるのかを待ち行列理論で考えてみた - Qiita
Amazon DynamoDB での優先度付きキューの実装 | Amazon Web Services
論文｜snmalloc: A Message Passing Allocator (ISMM 2019)
Kernel Queue: The Complete Guide On The Most Essential Technology For High-Performance I/O
マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ
Choose Postgres queue technology
GitHub merge queue is generally available
WEARにおけるPUSH通知システムのリプレイス - ZOZO TECH BLOG
【Laravelスキルアップ講座】Laravel JobとQueueも設定はこんなに簡単 | アールエフェクト
Announcing Deno Queues
Bullmqを使ったジョブキューの実装 | gihyo.jp
Python: Queue に型を付ける - Qiita
Python で分散タスクキュー (RQ 編) - Qiita
Dynein: Building a Distributed Delayed Job Queueing System
Pub/Subメッセージングモデルの業務利用における難しさ - Qiita