処理が複雑でジョブの依存関係を定義したい場合は、AWS Batch 単体で制御するか、より複雑な場合は Step Functions を用いて Lambda、ECS（Fargate）、AWS Batch（Fargate） を組み合わせる。 AWSにおけるバッチ処理の選択肢 ざっくりとした選択肢は下記。 Lambda ECS（Fargate） AWS Batch（Fargate） これらのサービスに実際は SQS や Step Functions を組み合わせることもあるので選択肢はさらに広がる。 ちなみに、SQS + Fargate（常時起動でポーリング） という構成や、SQS + Lambda + Fargate（都度実行） という構成は、AWS Batch が Fargate に対応した現在は特にメリットがないので取り扱わない。 2021/5/2 追記 「常時リクエストがくるユースケー
こんにちは、AI 基盤部の大谷です。 最近は兼務で MLOps 以外にも様々なシステムを構築しています。 弊社では全社的にオンプレミスからクラウドに、よりマネージドに寄せていこうという大きな指針が定められています。 (参考: フルスイングの記事 ) しかし、古くから運用されているサービスなどでは、未だにオンプレミスで構築されているものも少なくありません。 また、クラウドにホストされている場合でも、マネージドサービスを完全に活用しきれていない場合もあり、EC2 ベースの IaaS な構成はまだまだ多く存在しています。 とあるサービスでも、クラウド化はされているものの、マネージドサービスを活用しきれていないメール配信システムが運用されていました。 一般にメール配信システムは、挙動の違う複数のメールプロバイダにスムーズに配信するために多くのことを気にする必要があり、その分管理コストも高くなりがち
公開日 2024/05/28更新日 2024/12/02注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット会員限定コンテンツ無料登録してアーキテクチャ
こんにちは、カート決済部カート決済サービスブロックの林です。普段はZOZOTOWN内のカートや決済の機能開発、保守運用、リプレイスを担当しています。 弊社ではカートや決済機能のリプレイスを進めており、これまでにカート投入のキャパシティコントロールや在庫データのクラウドリフトを実現しています。 techblog.zozo.com techblog.zozo.com 本記事では新たにクレジットカード決済処理を非同期化したリプレイス事例を紹介します。 はじめに 背景・課題 非同期化のシステム構成 パターン1 - 完全非同期化パターン パターン2 - 非同期・同期切り替えパターン パターン3 - ポーリングパターン システム構成の決定 メッセージングサービスの選定 効果 今後の展望 まとめ さいごに はじめに 本章では、非同期化前のZOZOTOWNのクレジットカード決済を用いた注文処理の流れを説明
先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの
AWS上でバッチ処理を行う場合に、 どのAWSサービスが選択肢として考えられるかどのAWSサービスを選択すればいいのかについて考えていきます。 AWSでバッチ処理・定期実行する方法を4つ紹介し、それぞれ特徴やメリットとデメリットがありますので、この点について記載していきます。 バッチ処理・定期実行方式のパターンと特徴を知って適切な手段を選択しよう！という記事です。 まずはどのような構築方法があるかについて記載していきます。
Talked at AWS Dev Day Japan 2022. - 解説動画 : https://www.youtube.com/watch?v=hT7Se0oFEkU - イベントページ: https://aws.amazon.com/jp/events/devday/japan/ - Pr…
コーディングは技術者(エンジニア)の嗜みでして / Learning the System Development Mindset from Rock Lady
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
皆さんこんにちは。プロフェッショナルサービス本部のデジタルトランスフォーメーションチームでマネージャーをしています堀場です。 さて、いきなりですが、先日、ふと、頭に思い浮かんだ単語があります。それがこちら。 「機能」「情報」「連絡」「手順」「時間」・・・ 25 年以上前に覚えた単語がふと出てきたわけで・・・・この後、何が続くかご存知でしょうか ? 答えは、「論理」「暗号」です。 これは、モジュール強度 (または凝集度) の段階を表すもので「暗号」は凝集度が低く「機能」がもっとも高いと定義されています。なぜ、思い出したのかは謎です。ちなみに、10 年前の資料ですが IPA が提供している IT 人材育成用の汎用コンテンツ の 講義ノート に簡単な解説がありましたので興味がある方は読んでみてください。 凝集度が高いほど、堅牢性、信頼性、再利用性が高く、コードの読みやすさなどの点で好ましく、凝集
Here I plan to share my technical knowledge and experience, as well as my interests in the subject. Please note that this tech blog is a space for sharing my personal views and ideas, and it does not represent the opinions of any company or organization I am affiliated with. The main purpose of this blog is to deepen my own technical skills and knowledge, to create an archive where I can record an
こんにちは、プロフェッショナルサービス本部クラウドアプリケーションアーキテクトの五十嵐です。 先日、Web で美味しそうな料理の写真を見かけ、自宅で作ってみることにしました。 大きく分けて以下の手順が必要でしたが、みなさまでしたらどのように調理を進めるでしょうか ? 鍋で水を沸騰させる 野菜を切る 野菜を茹でる 調味料で味付けをする 皿に盛り付ける 1. で鍋を火にかけた後、鍋の前で沸騰するのをじっと待ちますか ? 今回は次の手順が沸騰を待たなくてもできる「野菜を切る」のため、沸騰を待たずに 2. で野菜を切り始め、沸騰したことを確認してから 3. で野菜を茹で始めると思います。 このようにして、完成までの時間を短縮化させる工夫をするのではないでしょうか。「他タスク (今回は水の沸騰) の完了を待たなくても良いケース (野菜を切る)」と、「他タスクの完了を待つべきケース (野菜を茹でる)」
こんにちは！LayerXエンジニアの高際 @shun_tak です！ この記事では、LayerX インボイスの請求書AI-OCRを支える非同期処理の仕組みについて解説したいと思います。 いきなりサマリーですが、今回お伝えしたいのは以下の2点です。 請求書は突然大量にアップロードされるので（大歓迎です！）、Amazon SQSとGoの machinery を活用して非同期処理しているよ！ AI-OCRの処理は重たいけど、AWS Lambdaを活用してシステム全体の負荷を分散し、スケーラビリティと可用性を確保し、コストも抑えることができたよ！ では早速ですが、前回のブログ LayerX インボイスにおける請求書AI-OCRの概要 の復習です。LayerX インボイスの請求書AI-OCRは、以下の図のように複数の処理によって構成されています。 図にするとあっさりしてますが、前処理も後処理も複数の
これまで、システムから候補者へのメール送信機能はありましたが、候補者からの返信メールはメールクライアントで確認する必要がありました。「候補者とのやり取りを一箇所で完結させたい」という要望を寄せられていました。そこで、候補者が送信したメールを以下画像のようにWeb画面上で確認できる機能を追加することになりました。 課題メール受信機能を実装するにあたり、以下のような課題がありました。 セキュリティ: 外部からのメールを安全に受け取る方法 信頼性: メールの紛失を防ぎ、確実に処理する方法監視: メール処理の失敗を検知する方法また、実装方法についても以下の検討が必要でした。 SNSからの直接Webhook vs SQSポーリングメッセージの重複排除監視設計やったこと（取り組み・改善内容）システム設計メール受信機能の実装にあたり、以下のAWSサービスを組み合わせたアーキテクチャを採用しました。以下フ
Amazon Web Services ブログ マルチテナントソリューションでAmazon SQSを使う AWS SaaS Factoryチームのシニアパートナーソリューションアーキテクト Raju Patel によって書かれた記事です。 モダンアプリケーションは、サービス統合、バッチ処理、またはワークフローオーケストレーションの一部として、キューイングに依存することがよくあります。キューは、システムの環境に拡張性と耐障害性を追加するうえ重要です。 これは、キューイング戦略をマルチテナントソリューションのワークロードにどのように適用するかを考える必要がある、Software-as-a-Service（SaaS）環境では特に当てはまります。SaaS アプリケーションのキューイングモデルを設計する際には、データの分離、パフォーマンス、および運用を考慮する必要があります。 多くの組織がアマゾンウ
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 maragu.dev/goqite See goqite on Github Examples Queue package main import ( "context" "database/sql" "fmt" "log/slog" "os" "time" _ "github.com/mattn/go-sqlite3" "maragu.dev/goqite" ) func main() { log := slog.Default() // Setup the db db, err := sql.Open("
SQS はサービス間の通信を非同期で実現するための メッセージキュー をマネージドサービスとして提供しています。ここではキューにメッセージを送る役割のサービスをプロデューサー、キューのメッセージを取得して処理する役割をコンシューマーと呼びます。 現実世界でこの関係を喩えてみます。私はたまに立ち食い寿司のお店に行くことがあるのですが、そのお店では複数の寿司職人さんがいます。私は注文を書いた紙を所定の位置に置いておけば、手が空いた寿司職人さんが注文を受け取ってお寿司を握ってくれます。その場合の関係を以下のように当てはめてみます。 注文する客 → プロデューサー 寿司職人 → コンシューマー 注文 → メッセージ 注文を置く場所 → キュー 私は注文を書いた後、手の空いた寿司職人さんを捕まえられるまで探し続けなくても良いですし、依頼したお寿司を握ってもらっている時間も自由に使えるので「次に何を頼
こんにちは。 NewsPicksエンジニアの美濃部です。 NewsPicksではAWSをインフラ基盤として利用しているのですが、この記事では実際に行ったSQSのコスト削減の話をしたいと思います。 結論から話すとタイトルにもありますが「SQSでメッセージを受信する時にはショートポーリングではなくロングポーリングにした方が大体においてコストが下がります」という内容です。 この話の発端はコスト削減の余地がないかを検討していてSQSのコストが高すぎないかと感じたところから調査が始まりました。SQSはAPIリクエスト数に応じた従量課金なのですがAPIリクエスト数を確認するとやはり多すぎると感じました。（ここはかなり感覚的なところなので何をもって多いと判断したかと言われると困るのですが） NewsPicksでは「SQS＋ワーカープロセス」で非同期処理を行うシステムがいくつかあり、これはよくあるワーカー
この記事は AWS LambdaとServerless Advent Calendar 2022 の24日目の記事です。 EvenBridge Pipes のイベントソースに SQS キューを利用したときのインフライトメッセージの削除処理について試していきます。 インフライトメッセージとは、キューに入っているメッセージをコンシューマーが受信したけど、キューから未削除のメッセージのことです。以下の状態のメッセージです。 はじめに サービス間を疎結合につなぐ選択肢としてメッセージキューがあります。AWS だと Amazon SQS を選択する方が多いでしょう。 この SQS に入っているメッセージを処理するコンシューマーとしての Lambda が本当に最高です。理由は以下のスライドに書かれている通り、受信処理にまつわる様々な実装を Lambda サービス側にオフロードし、実装者はメッセージを扱
背景と目的 マイクロサービス間で非同期メッセージングを実現するために、いくつかメッセージブローカーとしての選択肢があります。例えばAWSのサービスだとSQS, Kinensis, MKSなどが挙げられます。 今回はSQSがサービス間の非同期メッセージングを実現するために利用できるかを調査した時の観点をまとめました。 概要 まず非同期メッセージングの概要を整理します。 非同期メッセージングの役割 ネットワークを介してプロセス間でメッセージを送受信するには、同期的な通信と非同期的な通信があります。 同期的な通信はクライアントがリクエストを発行し、レスポンスを待つという形式になります。 リクエスト先のサービスが対応可能である必要がある レスポンスが返ってくるまでブロッキングされる すぐにリクエストが処理される リクエスト先のサービスの呼び出し方を知る必要がある 非同期的な通信はプロデューサー（あ
はじめに おはようございます、もきゅりんです。 ECSサービスのオートスケーリングしてますか？ ユースケースも少ないかとは思いますが、とにかく爆速でオートスケーリングしたくなることもありますよね？ (春ですし) ということで、本稿はステップスケーリングポリシーを使ってSQSキューの長さでECSサービスタスクを爆速オートスケーリングしてみました。 最初に注意 下記ご注意下さい。 この構成は、高速スケーリングにするために、高解像度のカスタムメトリクスを取得します。高解像度のメトリクス発行およびアラームの課金には注意して下さい。また、とりあえずやってみましたが、本当にこの構成を実装することが真なのかどうか、これで要件が満たせるのかどうか、他に適切な構成がないかどうかなどはよくよく検討する課題があるものだと考えます。 やりたいこと AWS のサービスによって生成されたメトリクスは、デフォルトで標準
こんにちは、プロフェッショナルサービス本部クラウドアプリケーションアーキテクトの五十嵐です。 「非同期処理を使いこなそう !」シリーズの第 3 回となる今回は、いよいよ物理アーキテクチャ、つまり AWS サービスを利用したアーキテクチャ構成を考えていきます。 これまでの連載記事では、EC サイトを例として 第 1 回 で同期処理と非同期処理の使い分けについてご説明し、第 2 回 で各処理のステップや論理構成についてご説明しました。これをベースとして、第 3 回は非同期処理を実現するための AWS サービスをご紹介し、それらを活用した非同期処理アーキテクチャについてご説明します。 みなさまは AWS を活用したアーキテクチャ (以下「アーキテクチャ」と記載) をご自身で描かれたことはありますでしょうか。もしあまりイメージがわいていなかったり、見たことはあるけどもご自身で描いたことがないという
開発中に AWS Lambda 関数をローカル環境で実行するなら AWS SAM CLI の sam local invoke -e event.json コマンドを使えば良く，また AWS Lambda 関数のベストプラクティスに載っている Lambda ハンドラーをコアロジックから分離します。 を意識して実装すれば，単体テストを軸に動作確認を進めることもできる． とは言え，実際に AWS Lambda 関数のイベントソースマッピング（トリガー設定）を確認したいこともあり，今回は AWS SAM を使って構築する Amazon SQS キューと AWS Lambda 関数の組み合わせを samlocal コマンドを使って LocalStack にデプロイして動作確認をしてみた．結果的に期待した通りに動いた❗️ ＼( 'ω')／ LocalStack 便利すぎ〜 🚀 アーキテクチャ図
各実装方式の詳細は以下のとおりです 1. Lambdaイベントソース型 Lambdaのイベントソースマッピングを利用すると、SQS・Kinesis Data Streamなど様々なソースにポーリングを行い、Lambdaを呼び出せます。 イベントソースが暗黙にポーリングやSQSメッセージの受信･削除をするため、Lambdaアプリケーションは受け取ったメッセージの処理ロジックだけを記述します。 def lambda_handler(event, context): for message in event['Records']: print(message['body']) 覚えることが少なくて済み、管理も楽なため、SQSコンシューマーの初手としておすすめできる一方で、最大の問題点はLambdaの制約に縛れることです。 メッセージ処理が15分を超えたり、10GBを超える潤沢なメモリが必要だった
こんにちは、稲葉です。 最近、Lambda＋SQS 構成での開発で可視性タイムアウトの設定で躓いた箇所があった為、 その共有と対処法について、今回記事にしたいと思います。 躓いた箇所 Lambda＋SQSで構成して、SQSからのメッセージをトリガーにしてLambdaを実行していました。このLambdaは最大4回ループ、また1回の処理でも比較的時間がかかる処理を行います。 実際に動かしてみた所、処理が完了したはずなのに再実行されるといった意図しない動作をしました。そのため、まずはLambdaのログを確認。しかし、ログを確認した所、エラーは発生しておらず正常に動作してました。 となると、問題があるのはSQS の設定だと考え、色々調べた結果。遂に、原因を突き止めました！ ズバリ、可視性タイムアウトの設定が原因でした！ と言うより、可視性タイムアウトは特に設定していなかったため、デフォルトの30秒
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
メッセージの順序を厳密に保ちたい場合や、重複不可の場合には、FIFOキューの使用を推奨します。それ以外の場合は標準キューの使用を推奨します。 SQSのアーキテクチャと処理の流れ SQSの仕様と処理の流れを以下の図に示します。これはSQSのクライアントライブラリであるProducer/Consumerを使用した場合の例となります。 SQSに書き込むメッセージは、一意なID、最大10件のメタデータ属性、最大256KBのテキストデータのペイロードから構成されます。 書き込み側のアプリケーションは、SQSのProducerライブラリを使用してキューにメッセージを送信します(Sendリクエスト)。このとき最大10通または256KBのメッセージを一度に送信可能です。メッセージはキューに保存され、単一リージョン内の複数AZに複製されます。保存期間は1分～14日間 (デフォルト: 4日)で設定可能で、保存
Introduction 皆さんご存知のとおり、AWS Lambdaとはサーバーレスでプログラムを実行できる 環境を提供するAWSのサービスです。 実行したい処理を関数として定義すればそのまま実行できますが、 S3/DynamoDB/Kinesis/SNS/SQSなどをトリガーとしてLambdaを起動させることも可能です。 本稿ではSQSをトリガーとしてLambdaを実行させてみます。 (先日この仕組みで確認事項があり、試してみたのでそのアウトプット) SQS + Lambdaの仕組み 仕組みは単純です。 イベントソースマッピングを行い、SQSとLambdaを関連付けるだけです。 Lambdaは自動的にスケールされ、設定により細かく制御可能です。 イベントソースマッピングは、現状標準キューとFIFOキューがサポートされています。 Lambda はキューをポーリングし、キューからメッセージを
皆さんこんにちは。kubotak（@kubotak_public）です。 この記事ではLaravelをECS Fargateで動かす際のQueueとScheduleに関して、弊社で行った知見を紹介したいと思います。 Laravel on ECSに関しては以下の記事も是非どうぞ M&Aクラウドを丸ごとAmazon Elastic Container Service(ECS)に移行しました！〜コンテナイメージ作り編〜 - M&Aクラウド開発者ブログ AWS CDK v2 の変更点5選 - M&Aクラウド開発者ブログ ※なお、本稿においてはLaravel8系を利用しています。（おそらくLaravel9系でも問題ありません） ECS FargateでQueueを動かす 弊社ではもともとAWS ElasticBeanstalkのWorker環境（以下EB Worker）でQueueおよびSchedu
この記事を見れば、SQSの概要・主要機能を理解して、日々の業務に活かしたり、AWS認定資格の対策になります。 また、SQSを含めたAWSのサービスを、ハンズオン形式で学ぶなら動画で学べるUdemy の講座がぴったりです。 ＼ AWS学習の決定版！30日以内なら返品もOK！ ／
あるアプリケーションなどが SQS にメッセージを送信し、ec2 から aws sdk 等を用いて SQS をポーリングすることでメッセージを受信するという構成です。 例えば S3 への動画 upload 処理で重い動画を upload するのに時間がかかってしまうという場合などに利用できます。この構成にすることで処理が分散されるため、手が空いている EC2 が次々と upload 処理を行うようになります。逆に単一の EC2 の場合であると、重い処理を一度行ってしまうと、他の軽い処理を待たせてしまうのでサービスの速度に影響がでてしまうという問題があります。SQS を通して並列処理を活用していきましょう。 こちらの構成は s3 と SQS、ラムダを用いた構成になります。 s3 には通知イベントという機能が備わっており、s3 のオブジェクトを保存、更新、削除などをしたときに SQS にメッセ
前にまとめたんですけど、やっぱややこしかったのでもうちょっとまとめます 勉強前イメージ SQS ... バッチのキューとか処理で後続の処理を実施できるイメージ SNS ... notificationだから通知が主なイメージ 調査 SQSとは 詳細は こちら SQSは Simple Queue Service の略 キューイングサービス キューは ソフトウェア間を直接データを渡すのではなく、第三者経由でデータを渡すことで、送信側と受信側が好きなときに処理を行う データの取得方法は、 他のサービスがSQSをポーリングして、キューがあれば取得 します SNSとは 詳細は こちら SNSは Simple Notification Service メッセージングサービス プッシュしたメッセージをHTTP,HTTPS,メール,SQS,モバイルプッシュなどに通知出来る データの取得方法は、 SNSがメ
UnsplashのKristina Tripkovicが撮影した写真おはこんばんちは。 Finatextグループのクレジット事業でソフトウェアエンジニアをしている Hanake です。 ところで、皆様はローカルでのメール送信をどのようにテストされていますか？ SMTP サーバを立ててテストしていますか？もしくは開発環境用にマネージドなメール送信サービスを利用していますか？ いずれにせよ、本番との環境の差異やコスト面での課題があるかと思います。 今回は、LocalStack と aws-ses-v2-local を使って可能な限り本番に近い環境で非同期のメール送信をローカルで再現する方法をご紹介します。 LocalStack とはLocalStack は、Amazon Web Services(以下 AWS) のクラウドサービスをローカルでエミュレートするためのツールです。 AWS の主要サ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 概要 前回のイラストで理解するが好評だったので、今回もイラストを使ってSQSの学習記録を記事にします。(本当は絵にして覚えたものにちょっと文字を足しただけ) この記事で得られること SQSがメッセージを配信する仕組みをイラストを交えながら理解できます。 概要を理解できれば公式ドキュメントも読みやすくなるはずです。 用語 まずはSQSに出てくる用語を見てみましょう。 メッセージ SQSが受け取るデータのこと 今回はニュース原稿 キュー メッセージをためておく場所 今回は原稿を入れる箱 コンシューマ メッセージを処理するもの（La
AWS Compute Blog Implementing AWS Well-Architected best practices for Amazon SQS – Part 2 This blog is written by Chetan Makvana, Senior Solutions Architect and Hardik Vasa, Senior Solutions Architect. This is the second part of a three-part blog post series that demonstrates implementing best practices for Amazon Simple Queue Service (Amazon SQS) using the AWS Well-Architected Framework. This blo
本記事は以下ブログの内容を転記したものです。 以下ブログの方が見やすいと思います。気になる方はどうぞです。 はじめに 最近、仕事でSQSを使う機会があったのですが、デッドレターキューやSQSによるリトライ処理がイマイチ理解できていませんでした。 AWSの公式ドキュメントやブログ記事などを見てもあまり理解できなかったため、実際にサンプルアプリを作って検証しました。 実施内容(概要) 実施内容は以下です。 LambdaにSQSでメッセージを送信する Lambdaはエラーとなるような処理とする 複数リトライ後、SQSのメッセージがデッドレターキューに入ることを確認する デッドレターキューに入ったメッセージを使って再処理できることを確認する 実施内容(詳細 - 設定) IAM 一般的なユースケースからLambdaを選択し、次のステップ：アクセス権限を押します。 ポリシーとしてAmazonSQSFu
SQSには「標準キュー」と「FIFOキュー」という２つのタイプが存在します。 それぞれのタイプについて動作の違いを検証してみました。 標準キューとFIFOキューの特徴 まず、標準キューとFIFOキューの違いとしてそれぞれ以下の特徴があります。
着想の元 この記事を見ているときに「イベント駆動アーキテクチャ」といえば、EventBridgeはどうなんだっけ?と思った
ある業務で一連のサービス（特定の業務を処理するプログラム）を連結させて全体の処理を行う方式に、オーケストレーション（Orchestration）とコレオグラフィ（Choreography）があります。 前者は、指揮者の指示に従って各演奏者が担当する楽器を演奏するように、全体の処理の流れを制御する指揮者にあたるプログラムが存在し、そこからのリクエストによってサービスを実行し、実行結果をレスポンスとして指揮者に返して次の処理に引き継ぐ方式です。これを「リクエスト・リプライ方式」と呼んでいます。 各サービスは、そのサービスを制御する指揮者が受けもっている特定の処理のためだけに利用され、他の指揮者が制御する別の処理を引き受けて実行することはありません。そのため処理が増えれば、指揮者のプログラムもその数必要となり、同時に多くのサービスが駆動されます。 一方、後者は、演劇や踊りで演技者に予め振り付けが
著者: 伊藤 雅博, 株式会社日立製作所 はじめに AWSでストリーム処理を実現する際は、データをキューイングするメッセージングサービスと、キューイングしたデータをストリーム処理するサービスを組み合わせることが一般的です。本投稿では、AWSが提供する各メッセージングサービスの概要と、ストリームデータを扱う際の選択基準を紹介します。 なお、本投稿の内容は2020年中頃の調査結果をベースに、いくつか更新を加えたものです。AWSのサービス仕様は随時更新されるため、最新の仕様とは異なる場合があります。最新の情報はAWSの公式ドキュメントをご参照ください。 投稿一覧: AWSでストリームデータを扱うためのメッセージングサービス (本投稿) AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴 AWSのKinesis Data Analytics
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く