TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
2023-04-06 DigdagからBigQueryを動かす - ChatGPTを使用してエラーを解決した話 AI BigQuery Digdag こんにちは、植村です。今回は弊チームで使用しているワークフローエンジンのdigdag(AWS, EC2)からGCPへアクセスしてBigQueryを動かした時のお話を書きます。やりたいこと：DigdagからBigQueryのExport機能を使用してGCSにデータを格納するGCPの環境は既にで… digdag BigQuery Chat GPT 2023-04-01 週休7日に興味あり？新しいBingが弊社の魅力をご紹介します！ AI こんにちは、菅野です。 もう一年の4分の1が終わりましたね。 新生活の季節となった4月1日なので(?)唐突に弊社を紹介する記事を書きました！ と言っても、私が紹介するのでは面白くないので「新しいBing」に会社の
サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇
処理が複雑でジョブの依存関係を定義したい場合は、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 な構成はまだまだ多く存在しています。 とあるサービスでも、クラウド化はされているものの、マネージドサービスを活用しきれていないメール配信システムが運用されていました。 一般にメール配信システムは、挙動の違う複数のメールプロバイダにスムーズに配信するために多くのことを気にする必要があり、その分管理コストも高くなりがち
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
こんにちは、カート決済部カート決済サービスブロックの林です。普段はZOZOTOWN内のカートや決済の機能開発、保守運用、リプレイスを担当しています。 弊社ではカートや決済機能のリプレイスを進めており、これまでにカート投入のキャパシティコントロールや在庫データのクラウドリフトを実現しています。 techblog.zozo.com techblog.zozo.com 本記事では新たにクレジットカード決済処理を非同期化したリプレイス事例を紹介します。 はじめに 背景・課題 非同期化のシステム構成 パターン1 - 完全非同期化パターン パターン2 - 非同期・同期切り替えパターン パターン3 - ポーリングパターン システム構成の決定 メッセージングサービスの選定 効果 今後の展望 まとめ さいごに はじめに 本章では、非同期化前のZOZOTOWNのクレジットカード決済を用いた注文処理の流れを説明
index.html
Webページが見つかりません 可能性のある原因 ・アドレスに入力の間違いがある可能性がある。 ・リンクをクリックした場合には、リンクが古い場合があります。 アドレスを再入力するか、前のページに戻る、 またはメインのサイトに移動して必要な情報を探してください。
AWS でバッチ処理・定期実行する4つの方法
4つのバッチ処理・定期実行方式の詳細情報それぞれのバッチ処理・定期実行方式について詳細を見ていきます。 EC2について使用するAWSサービスEC2 処理概要Linux系OSで用いられる定時実行機能であるcronのコマンドを使用する メリット昔からよく使われているcronの知識が使える デメリットEC2インスタンスを起動しておく必要があり、使っていない時間もコストがかかる 障害に弱い。EC2サーバに障害があると終わる サーバが複数になると管理が大変 SQS×ECS使用するAWSサービスEventBridge SQS ECS 処理概要EventBridgeでキューを生成。ECSコンテナでキューを取得して実行する メリットECSを起動しておくため、コンテナの起動時間を要さない。 デメリットEventBridgeでキューを生成するが、EventBridgeはまれに1 つのイベントに対して複数回トリ
Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの
SQS + Lambda という⾮同期処理 ⻩⾦パターン再⼊⾨ #AWSDevDay / SQS-Lambda-DevDay2022
Talked at AWS Dev Day Japan 2022. - 解説動画 : https://www.youtube.com/watch?v=hT7Se0oFEkU - イベントページ: https://aws.amazon.com/jp/events/devday/japan/ - Proposal:https://github.com/aws-events/aws-dev-day-online-japan-2022-cfp/issues/82
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
こんにちは。牧本 (@makimoto) です。最近はバックエンドシステムの設計をやったりしています。 今回は複数のサービスが存在するとき、その間でどのようにデータ連携を実現するかついて述べていきます。 背景と問題定義 cookpad.com は世界有数の規模の Ruby on Rails で作られたウェブアプリケーションです。 巨大な Rails アプリケーションは単純に起動やデプロイ、テストが遅いという問題以上に、自分の変更が与える影響範囲を予測するのが困難という大きな問題があります。cookpad のメインレポジトリ (cookpad_all と呼ばれる) には1つの mountable engine を共有する Rails アプリケーションは7つがあり、困難さに拍車をかけています。cookpad_all を触る開発者は新しい機能を追加する、既存の機能に手を入れる、不用な機能を消すな
非同期処理を使いこなそう ! -第 2 回 非同期処理と同期処理の処理構造 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
皆さんこんにちは。プロフェッショナルサービス本部のデジタルトランスフォーメーションチームでマネージャーをしています堀場です。 さて、いきなりですが、先日、ふと、頭に思い浮かんだ単語があります。それがこちら。 「機能」「情報」「連絡」「手順」「時間」・・・ 25 年以上前に覚えた単語がふと出てきたわけで・・・・この後、何が続くかご存知でしょうか ? 答えは、「論理」「暗号」です。 これは、モジュール強度 (または凝集度) の段階を表すもので「暗号」は凝集度が低く「機能」がもっとも高いと定義されています。なぜ、思い出したのかは謎です。ちなみに、10 年前の資料ですが IPA が提供している IT 人材育成用の汎用コンテンツ の 講義ノート に簡単な解説がありましたので興味がある方は読んでみてください。 凝集度が高いほど、堅牢性、信頼性、再利用性が高く、コードの読みやすさなどの点で好ましく、凝集
よく訓練されたアップル信者、都元です。AWSでシステム構築をする場合は、Design for failureという考えに基いて、複数AZにまたがる形の冗長構成を組むのがベストプラクティスです。さらに、このように分散させた各インスタンスには、出来る限りマスターを作らない、つまりSPOFとなるインスタンスを避ける構成であるのが理想です。 という話題については以前AWSにおける可用性の考え方というエントリーでも書きました。 可用性 (availability) と拡張性 (scalability) 本題はジョブWorkerですが、WebサーバやDBサーバの可用性と拡張性を先におさらいしておきましょう。 Webサーバ この考えで構築する最も基本的な構成が、Webシステムにおける ELB + Webサーバ の構成です。この構成マルチAZと呼び、片方のAZが丸ごとダウンしたとしても、サービス自体はダウ
【新機能】Amazon SQSにFIFOが追加されました！（重複削除/単一実行/順序取得に対応） | DevelopersIO
SQSの大型アップデートです！ オンプレでエンタープライズな開発を行ったことがある方であれば、分散キューシステムの設計が大変だったと思います。実際のところは高額ライセンス商品を買うしか選択肢はなかったのではと。Amazon SQSの登場によって、今まで実装が大変だったノンコア機能のキューが、超安価に簡単に使えるようになったのは衝撃でした。これだけでクラウドを使う理由になりました。 そして、年月は流れ、この度SQSが進化しました！まずは、今までのSQSの課題についておさらいしたいと思います。 標準キュー 今までのSQSは、メディアエンコーディングや大量タスクの分散処理などに適していましたが、いくつかの用途においてフィットしなかったり、独自実装をする必要がありました。 順番が保証されない SQSは高可用性を持った分散キューシステムですので、1つのエンドポイントに投げられたメッセージは複製され蓄
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散キューという名の苦しみ - Software Transactional Memo
FLINTERS Engineer's Blog
時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
AWSでバッチ処理を実装する際の選択肢とサービス比較
大規模分散システム ”Amazon Web Services” の使い方
大規模Email配信システムのクラウドジャーニー | BLOG - DeNA Engineering
AWS をどう使わずにおくか - portal shit!
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
SQSを用いたクレジットカード決済の非同期化 - ZOZO TECH BLOG
サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
最近のサービス間のデータとイベントの連携について - クックパッド開発者ブログ
AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻 | DevelopersIO