こんにちは。エンジニアリンググループの武井です。 私は現在、デジカルチームに所属し、クラウド電子カルテ、エムスリーデジカルの開発に携わっています。 昨年夏にエムスリーに入社し、早くも半年が経過しました。 digikar.co.jp この記事では、私が入社してから4ヶ月目に取り組んだ、バッチ処理の運用改善について振り返ります。 特に、新しくチームに加わったメンバーとして意識した点に焦点を当ててみたいと思います。 これから新しいチームに参加する方の参考になれば幸いです。 改善したバッチ 現状の正確な理解 現状に馴染む技術選定 自分なりの+αを加える 改善の結果 We're hiring 改善したバッチ 今回の改善対象は、特定の医療機関に紐づく全患者の全カルテをPDFファイルとして出力する、というバッチです。 デジカルのデータを医療機関側にエクスポートする用途で使われています。 移行前のアーキテ
「8割9割ではなく、100％自動化することを重視した」。ソニー生命保険の後藤聖央執行役員兼ITデジタル戦略本部長はこう語る。 ソニー生命は、2020年6月からメインフレームにおけるバッチ処理やアプリケーションリリースに関する作業依頼の自動化を進めている。「100％自動化」を重視するのは、自動化の例外を残せば、作業依頼にかかる人員を完全になくすことはできないためだ。 同社は2023年4月に自動化システムの本格利用を開始した。オペレーターが依頼書などで受け付けていた1カ月に1000件以上の作業依頼を自動化し、処理実行までの時間を短縮した。依頼書のチェックにかかっていた人手も削減した。 ソニー生命では基幹系がメインフレーム上で稼働している。メインフレームは米IBM製だ。その中で「バッチ処理を大量に抱えている」（後藤執行役員）。例えば、顧客の口座から保険料を引き落とすため銀行に対してデータを定期的
それぞれ微妙にできることや制限に違いがあり、ここを捉えた上で選択する必要があります。 Batchの強みはおそらくタイムアウトがないことによって長時間実行ができ、かつシンプルに実装できることだと思います。 （タイムアウト最大値に関して、Batchにおいては存在しないと公式動画の方で説明していますが、Cloud Composerについては不明でした。） Batch単体でもジョブ定義ファイル内で各タスクの依存関係（順次実行、並列実行）はできますが、Cloud ComposerやWorkflowsのように複雑なジョブネットを書くことは難しそうです。 ジョブネットのように動かしたい場合には公式ドキュメントにもあるようにWorkflowsなどからBatchジョブを実行するのが良さそうです。 動かしてみよう 実際にジョブを作って動かすまで試してみたいと思います。 GCP公式がBatchのサンプルコードを
こんにちは、エンジニアリングユニットの飯森です。 先日、Anewsのバッチ処理のテストフレームワークを刷新するプロジェクトに取り組みました。 本記事ではこの取り組みについて紹介します。 本記事を読むことで、以下の2点が分かります。 バッチ処理のテストフレームワークの刷新をどのように進めたのかストックマークでは工数がかかる改善施策にどのように取り組んでいるのかプロジェクトの背景最初に、Anewsのバッチ処理とそのテストフレームワークについて説明します。 Anewsとバッチ処理ストックマークはAI 情報収集プラットフォームAnewsを運営しています。 Anewsでは、ニュース、論文、特許といった様々な情報を国内外約35,000メディアから収集し、AIによる最適な情報配信を提供しています。 Anewsで配信されるコンテンツ（フィード）には様々な種類があります。 例えば、ユーザーの興味や嗜好に合わ
オープンソースの高速な国産リレーショナルデータベース「Tsurugi」が登場した。Tsurugiの特徴やアーキテクチャ、導入方法などを解説する。 来歴 Tsurugi1は、国のバックアップ2を受けて作られた、純国産のOSS-RDBです。もともと有志の勉強会から始まったコミュニティ活動がベースで、各民間企業（ノーチラス・テクノロジーズ/NEC）、大学（東京工業大学/慶応大学/名古屋大学/大阪大学）、研究機関（国立天文台）などが主体となり、さまざまな企業・関係者の協力のもとに開発された、次世代高性能RDBです。OSSなので、だれでも自由に利用できます。商用サポートも提供されています。 2 なお、国によるバックアップは国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）によるもので、「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発／次世代コンピューティング技
【AWS】大規模なバッチ処理を支える技術選定
ここから、表で挙げた内容をそれぞれ解説していきます。 構築難度に関しては、関数を実装するだけで済むLambdaが最も簡単で、バッチ専用に特化されたサービスであるBatchに関しては比較的バッチ構築はしやすい印象ですが、ECSに関してはバッチに特化していないため、バッチ処理を行うようにカスタマイズする必要があります。 タイムアウト制約に関して留意すべきは、Lambdaの実行時間は15分までなので、それ以上を超える処理時間のバッチは実装できないことです。 起動•実行上のオーバーヘッドに関しては、Lambdaにはコールドスタートがあるため起動時にオーバーヘッドを考える必要があり、Batchではジョブをキューに送信して、最適化のために、ある程度のジョブがキューイングしてから実行しようするので、即時性を求める処理には不向きです。 既存バッチを移行したいケースがあると思いますが、Lambdaで動かせる
【実務でもよく使う】SQS × Lamda × EventBridgeで実現する非同期&バッチ処理の基本 - Qiita
概要 応答速度の改善を目的にシステムに非同期処理を組み込むことはよくあることかと思います。AWSでもSQSを利用することで比較的簡単にジョブキュー処理を実現することができます。一方で、バッチ処理との組み合わせも踏まえると、AWSのサービスの選択肢は複数存在するため分かりにくいです。 そこで、本記事では以下を整理してみました。 本記事で得られる内容 非同期処理のメリット・デメリット AWSで非同期処理・バッチ処理を実現する方法 実際にSQS × lamda × EventBridgeの組み合わせでサンプルアプリを作成 知識整理編 まず、前提となる基礎知識や非同期処理・バッチ処理を実現するために必要なAWSリソースを簡単に整理してみます。ここで紹介する内容は概要に留めるため、より詳細を知りたい方はAWSの公式ドキュメントやBlackBelt等の資料をご確認ください。 非同期処理 非同期処理とは
テーブル内に格納されているメールアドレスのデータを使って、1日ごと、1週間ごとに全ユーザーに対してメールを送信したいというバッチがあったとしましょう。 とある1人のユーザーのメールアドレスを調べること自体はQuery操作で可能ですが、バッチ処理の性質上それを全ユーザーに対してやると考えると、実質的にはテーブル全Scanと同等の処理が要求されてしまいます。 システムを利用しているユーザーから登録情報の参照・変更を随時受け付けるたびに、このテーブルへのCRUD処理が行われます。そのため、このテーブルへの全Scanはユーザー体験を損なう可能性が高いです。 解決策の模索 「とあるテーブルに対してバッチで大量アクセスするのを防ぎたい」という要件に対して、考えられるアプローチを挙げてみます。 リードレプリカの作成 コピーテーブルの作成 リードレプリカの作成 RDSやAuroraの場合は、同じデータを持
AWS でバッチ処理・定期実行する4つの方法
4つのバッチ処理・定期実行方式の詳細情報それぞれのバッチ処理・定期実行方式について詳細を見ていきます。 EC2について使用するAWSサービスEC2 処理概要Linux系OSで用いられる定時実行機能であるcronのコマンドを使用する メリット昔からよく使われているcronの知識が使える デメリットEC2インスタンスを起動しておく必要があり、使っていない時間もコストがかかる 障害に弱い。EC2サーバに障害があると終わる サーバが複数になると管理が大変 SQS×ECS使用するAWSサービスEventBridge SQS ECS 処理概要EventBridgeでキューを生成。ECSコンテナでキューを取得して実行する メリットECSを起動しておくため、コンテナの起動時間を要さない。 デメリットEventBridgeでキューを生成するが、EventBridgeはまれに1 つのイベントに対して複数回トリ
サーバーのバッチ処理が時間内に終わらないとの相談が顧客から寄せられた。ログを調べると、バッチ処理に使用するマスターデータの生成に時間がかかっていた。このためデータを生成するデータベースサーバーを調べたが異常は見つからなかった。それもそのはず、原因はネットワーク上に存在する1台のルーターだったのだ。 不具合が報告されているハードやソフトを利用するシステムでトラブルが発生したら、その不具合が原因に違いないと考えるだろう。実際、不具合が原因であることが多い。だが一方で、不具合とは無関係の箇所に原因が潜んでいる場合もある。この場合、トラブル解決は往々にして難航する。 顧客企業のシステム運用を請け負うチームのリーダーだったラックの七沢樹さんが直面したトラブルがまさにこのケースだった。七沢さんはどのようにして原因を突き止めたのだろうか。 時間内に終わらず子会社の業務に支障 七沢さんたちのチームが運用を
商品数の増加を見据えて商品情報作成処理をPythonからBigQueryに移行した話 | SQLによるバッチ処理で工夫した3つのポイント - MonotaRO Tech Blog
こんにちは、EC基盤グループ 商品情報基盤チームの江村です。今回は私が所属している商品情報基盤チームで構築、運用を行っているシステムについてお話します。 モノタロウでは以前から記事になっていますが、検索システムの移行を行っており、現在商品検索ページの裏側の検索システムのSolrからElasticsearchへの切り替え*1が完了しました。 私が所属している商品情報基盤チームではElasticsearch、Spannerに入れるための商品情報の作成とSpannerおよび、Spannerからデータを取得するAPIの運用を行っています。今回はその中でもElasticsearch、SpannerのためのBigQueryでの商品情報作成処理について取り上げます。（詳しい検索部分の構成については以前の記事を参照ください） システム移行の背景 移行による設計ポイント 「MySQL + Python」の処
はじめに こんにちは, 基盤開発チームの奥山(okue)です. High Link では, BigQuery を活用してデータの分析や可視化, 機械学習への活用を行っています. アプリケーション DB の BigQuery へ転送には, AWS ECS Fargate + Embulk という構成でバッチ処理を実行していましたが, いくつか運用上の問題点がありました. 本記事では, BigQuery へDBのデータを転送するバッチ処理を, AWS Step Functions + AWS ECS Fargate + Embulk で実装し改善した話をします. 改善前の構成と問題点 構成 改善前のバッチ処理は下図のような構成でした. AWS RDS MySQL には 60個以上のテーブルがありますが, それらを BigQuery へ転送する処理を1つの ECS Task で実行していました.
Amazon Connect の通話データの分析結果をバッチ処理で Word 文書にする – Amazon Connect アドベントカレンダー 2022 | DevelopersIO
Amazon Connect の通話データの分析結果をバッチ処理で Word 文書にする – Amazon Connect アドベントカレンダー 2022 こんにちは！森田です。 この記事は「Amazon Connect アドベントカレンダー 2022」の15日目の記事となります！ Amazon Connectアドベントカレンダー2022は、クラスメソッドと株式会社ギークフィードさんでチャレンジしている企画となっており、他にもAmazon Connect関する様々な記事がありますのでぜひご参照ください！！ この記事では、Amazon Connect の通話データをバッチ処理で分析しその結果を Word 文書にする方法をご紹介します。 やりたいこと Amazon Connectの音声データの分析結果を AWS Lambda で Word 文書に変換し、 そのファイルパスを Amazon Co
こんにちは, メディア開発部の今村です. この記事はGunosy Advent Calendar 2022 7日目の記事です. 昨日の前編から引き続き, EventBridgeとECSでバッチ処理基盤を整備した話を紹介します. 後編は監視についてです. EventBridgeやECSの情報をDatadogに集めてモニターを設定していきます. ECSタスクの失敗を検知する EventBridgeの失敗を検知する 監視のまとめ おわりに ECSタスクの失敗を検知する タスクのメトリクスとログについては, サイドカーコンテナとしてDatadog agentとFluent Bitを配置することで収集できます. 方法は大体公式ドキュメントにある通りです. しかし, ドキュメントに The ECS Fargate check does not include any events. とあるように, こ
こんにちは, メディア開発部の今村です. この記事はGunosy Advent Calendar 2022の6日目の記事です. 昨日の記事は村田さんの「Digdag が突然止まった障害を受けて」でした. この記事 (前編) と明日の後編では, EventBridgeとECSでバッチ処理基盤を整備した話を紹介します. 背景 & 技術選定 スケジューリング 実行環境 監視 タスク管理リポジトリの作成 構成 ecspressoでタスク定義を管理する より開発しやすくするために おわりに 背景 & 技術選定 最近はプッシュ通知送信システムのリプレイスを行なっており, その一環でEC2インスタンス上のcronで動くバッチ処理を移行することになりました. これまでチームとして決まったバッチ処理置き場を持っておらず, LambdaやEKS CronJobなどバラバラな環境を使っていたため, これを機に共
AWS - ECS Taskを使ったバッチ処理
ECS Taskを使ってバッチ処理するケースがあると思う。 構成のパターンは様々ありそうだが、必要となるAWSリソースであったり、監視・リトライの実現方法あたりを、整理しておこうと思う。 （Lambdaを使えばリトライ設定とかあるので簡単だが、処理時間が長いなどLambdaが使えないケースを想定している） 時間指定で、ECS Taskを起動したい EventBridgeでTargetに、ECS taskまたは、Step Functions state machineを指定すれば良い。 Targetの呼び出し自体に失敗したときのリトライはRuleに対して設定できるが、起動後の失敗に関してはStep Functionsで対応する必要がある。 なので、最初からStep Functions state machineを指定する形にしておくと良さそうな感じがする。 ECS Taskが失敗したら、リト
Lambda でバッチ処理を構築する際のエラー通知パターン 5選 - サーバーワークスエンジニアブログ
はじめに パターン1. 直接Publish パターン メリット デメリット パターン2. DLQパターン メリット デメリット パターン3. 失敗時送信先パターン メリット デメリット パターン4. メトリクスフィルターパターン メリット デメリット パターン5. サブスクリプションフィルターパターン メリット デメリット 各パターン比較表 まとめ はじめに アプリケーションサービス部の宮本です。 お仕事でLambda を使ったバッチ処理を構築することが多いのですが、バッチ処理でエラーが発生した場合、通知が必要なケースが大半です。そこで通知の方法について、幾つかパターンがあるので纏めてみることにしました。 イメージとしては以下の様なバッチ処理です。条件に当てはまらない場合は別のアプローチもご検討ください。 ここでいうバッチ処理のイメージ 実行頻度は1日数回程度以下。 失敗すると何かしらの業
アイ・ティ・アール（ITR）は2022年8月18日、ホワイトペーパー「業務自動化に向けた国内企業の現状と展望」を公開した。国内企業の業務自動化に向けた取り組み状況と、技術選定のポイントを解説した。 年商500億円以上の国内大企業に勤める部長職以上の役職者を対象にITRが実施した調査（2022年3月実施）によると、DX（デジタルトランスフォーメーション）における最重要課題は、「コミュニケーション／コラボレーションの高度化」（47％、複数回答、以下同）だった。次いで「業務の自動化」（45％）だ。
はじめに バッチ処理を作る際に検討項目が多く手が動かない。。。。 そんな状況にならないためにフォローできる記事になれば良いと思い書き込んでみました。 そもそもバッチ処理とは 簡単にいうと一定量のデータを集めて、一括で処理する方法のことです。 主にユーザアクションに起因しない処理です。 実行についても定期実行、手動実行など様々な用途で用いられます。 バッチ処理にするメリット 大量のデータを一括で処理できること 稼働する時間を調整できる。（業務システムが稼働していない夜間などに処理を行える） バッチ処理の構成 基本としてバッチ処理は以下の構成となっている。 入力して加工して出力する 例 入力 DBのデータ CSVファイル 加工 抽出する 削除する 集計する マージする 出力 DBに登録する CSVファイルに書き起こす メール送信 ファイル作成して転送 バッチを作る際の検討事項 構築する際に迷っ
後編(冪等性の設計導入)へ はじめに こんにちは。タイミーのバックエンドエンジニアの中野です。よくGopherくんに似てると言われます。 本記事では月次で実行している「締め」のバッチ処理に関する一連の技術的改善について掲載します。弊社のプロダクト「タイミー」は著しい事業成長に伴いデータ量が急増してきています。そこで今回はデータ量の急増を背景とした中長期的なバッチ処理の設計改善にどのように取り組んできたのかをご紹介したいと思います。バッチ処理に関する技術的改善の記事は前編・後編の2部構成をとっています。前編はバッチ処理におけるトランザクションの改善をテーマに、後編ではバッチ処理に冪等性の設計を導入したことをご紹介したいと思います。 今回は前編のトランザクションの改善をテーマにご紹介します。すでに本番稼働しているアプリケーションにおいてトランザクションの範囲が大きい場合にどのような問題が発生し
前編(トランザクション範囲の最小化)へ はじめに こんにちは。タイミーのバックエンドエンジニア中野です。 前編では締めのバッチ処理におけるトランザクションの範囲を最小化した技術的改善をご紹介しました。トランザクションの範囲をバッチ処理全体から最小限の範囲に変更したことにより、バッチ処理が失敗した場合に請求レコードの処理が途中まで完了している状態が発生するようになりました。後編では、処理対象の請求レコードに対し状態を持たせることでバッチ処理全体での冪等性を担保し、バッチ処理が途中で失敗した場合でも安全に処理を再開できるようにした取り組みをご紹介します。 はじめに 締めのバッチ処理とは 現状の課題認識 実施した施策 冪等性とは 冪等性を実現する方法 バッチ処理への適用 達成できたこと 今後の課題 スループット向上とリソース最適化 まとめ 締めのバッチ処理とは まずは前編のおさらいになりますが、
はじめに メルペイバックエンドエンジニアの @r_yamaoka です。この記事は、Merpay Tech Openness Month 2022 の16日目の記事です。 私がつい最近まで所属していた加盟店管理業務を担うマイクロサービス群（以下、加盟店管理システム）では様々なバッチが稼働しています。本記事ではそれらの実装において過去に発生したトラブルやヒヤリハットから得た知見を共有したいと思います。 背景 本題に入る前に加盟店管理システムでどのような箇所にバッチ処理が採用されているかについて少し解説します。バッチ処理を採用するか否かの観点としては大きく下記2点があります。 機能要件上バッチ処理を採用しなければならない 非機能要件の都合で同期処理を採用できない 前者の例としては「配送業者との伝票情報連携」や「行政システムとの連携処理」というものがあり、これは連携先である配送業者や行政の業務の
はじめに この記事は、Merpay Tech Openness Month 2022 の7日目の記事です。 こんにちは。メルペイのBackendエンジニアの@kaznishiです。 この記事では、私が所属しているチームで担当している加盟店精算のマイクロサービスにおけるバッチ処理のリグレッションテスト自動化の取り組みを紹介します。 まだBackendエンジニアしかテストシナリオの整備ができるようになっていなかったり、開発フローが整備しきれているわけではないですが、現時点でどのようなテストを回しているか、そして今後どのように改良していきたいかを述べたいと思います。 前提知識 加盟店精算のマイクロサービスの性質として、毎月決まったタイミングでの締め処理があります。この締め処理の中で、メルペイを導入してくださっている加盟店さまの売上を集計し、加盟店さまの銀行口座へ振込する金額の計算を行っています。
「golang.tokyo」は、プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。ここで、フューチャー株式会社の真野氏が登壇。ここからは、Goの導入で工夫していることを紹介します。 WebAPIからバッチ処理までの工夫 真野隼記氏：ここから話は変わって、実際に使っている、導入の部分で工夫しているところをいくつか紹介したいと思います。（スライドを示して）Goの導入ですが、Goのバックエンド中心で強いのはだいたいそのとおりで、WebのAPIサーバやバッチ処理、BOTのアプリやCLIツールなどをいくつか導入しています。 細かな工夫について、WebのAPIやバッチで特に生産性に加味しそうなところを話していきたいと思います。 （スライドを示して）まずWebのAPIですが、特に技術選定のリーダーポジションでよく思うことです。デファクトスタンダードなWebのフレ
こんにちは、id:shallow1729です。最近はインフラ寄りなお仕事をよくやっていますがこれまでにいくつかデータ移行やデータ基盤構築などのバッチ処理のお仕事をしてきました。以前にも一度そういった経験を元に記事を書いたのですが、MySQLやシステムに関する知識が以前よりも増えた今もう一度書き直したいなと思いました。 なので今回はバッチ処理を書く時のテクニック2022版という感じです。今の仕事の関係でMySQLやrailsを前提にしている話が多いですが、おそらく他のデータベースを使っている人にも役に立つ話が多いのではないかと思います。ただ、今回の記事は経験に基づくものが多く、あまりよくないアイデアもあるかもしれません。改善点や間違いなどあればご指摘ください。 冪等性を持つように 冪等性とは端的に言えばある操作を複数回実行しても一回しか実行しなかった時と同じ結果になる性質の事です。長時間かか
ほとんどバッチ処理しか書いたことのない者だがストリーム処理のシステムを開発することになった。 それにあたって独学で調べたことなどまとめておく。 ストリーム処理とは#そもそも “ストリーム処理” とは何を指しているのか。 以下の引用が簡潔に示している。 a type of data processing engine that is designed with infinite data sets in mind. Nothing more. – Streaming 101: The world beyond batch こちらは “streaming system” について述べたものだが、つまり終わりのないデータを扱うのがストリーム処理ということである。 例えば web サービスから生まれ続けるユーザ行動ログを逐次的に処理するというのがストリーム処理。 web サービスが終了しないかぎり
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
バッチ処理系の刷新とArgo Workflow移行
これはPTAアドベントカレンダーの7日目の記事です。 5年間運用されてきたバッチ処理系を刷新し、Argo Workflowを用いたバッチ処理系に移行したのでその紹介記事です。 背景 GKE上でバッチ処理のワークロードを実行しており、ワークフローエンジンとしてDigdagを採用していました。ユースケースとしては定期実行のバッチ処理、ETL、機械学習等。 Digdagを用いたワークフロー定義はシンプルかつ運用に必要な機能を提供してくれています。実際のワークフロー内部の処理としては、ワークフローの各タスクにおいては基本的にはロジックは持たずKubernetes Jobの実行のみを行います。そのためにDigdagとKubernetes Job間で協調動作するための仕組みが独自で用意されていました。このようなバッチ処理系が約5年程運用されてきました。 この仕組で今まで元気に動いてはいたのですが次のよ
バッチ処理における冪等性の検討 ─ クラウドネイティブもしくは、はてなダイアリーの自動移行を題材に - Hatena Developer Blog
アプリケーションエンジニアのid:tkzwtksです。今回はバッチ処理の冪等性（べきとうせい、idempotence）について、どう考えるか／考えてきたかをご紹介します。 このエントリを書くきっかけとなったのは、はてなエンジニア有志で定期的に開催しているCloudNative推進会です。ここでは、社内のシステムをクラウドネイティブにしていくため「クラウドネイティブなシステムとはどういうものか？」を考えており、この会での「クラウドネイティブなバッチ処理」の議論も踏まえつつ説明していきます。 バッチ処理における冪等性とは メッセージ送信の信頼性を考慮する クラウドネイティブで可用性を高めるために どのような場合に冪等性を考慮すべきか 冪等な実装における3つのケーススタディ ケース1: n分前までに更新されたレコードを集計する ケース2: DB上の対象レコードを更新する ケース3: 対象ユーザー
[アップデート] AWS LambdaがAmazon SQSをイベントソースとしたバッチ処理で部分応答をサポートしました | DevelopersIO
こんにちは。サービスグループの武田です。 AWS LambdaはPythonやJavaScriptで書かれた処理をクラウド上で実行できるAWSのFaaSです。さまざまなサービスと統合されていますが、そのひとつとしてAmazon SQSがあります。イベントソースマッピングという機能を使用することで、SQSへのメッセージ送信をトリガーとしてLambda関数を実行できます。SQSをイベントソースとしたLambda関数のトリガーは、バッチ処理として複数のメッセージをまとめて処理させることができます。さて複数のメッセージをまとめて処理する場合に起こる問題として、一部は成功するが一部は失敗してしまったというものです。 これまでは関数が成功すればすべてのメッセージが成功したとしてキューから削除。関数が失敗すればすべてのメッセージが失敗したとしてキューに残される。のどちらかしかありませんでした。そのため、
![[アップデート] AWS LambdaがAmazon SQSをイベントソースとしたバッチ処理で部分応答をサポートしました | 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)
Amazon Web Services ブログ AWSサーバーレスバッチ処理アーキテクチャの構築 この投稿は、AWSソリューションアーキテクトであるReagan RosarioとWWPSソリューションアーキテクトであるMark Curtisによって書かれました。バッチ処理は多くの組織にとって基礎となるもので、大量の情報を効率的に自動化した形で処理することができます。ユースケースとしては、ファイル取り込み処理、キューベースの処理、トランザクションジョブ、さらに重いデータ処理のジョブなど、多岐にわたります。 この記事では、ファイル取り込み処理を実装するためのバッチ処理を、サーバーレスに実現するための方法を説明していきます。今回の例では、オーケストレーションにAWS Step Functions、オンデマンドのコンピューティングにAWS Lambda、データストアにAmazon S3、メールの送
ITシステムに関わるエンジニアなら、「バッチ処理」という言葉を聞いたことがある人がほとんどだろう。しかし、バッチ処理とは何かを正確に理解している人は意外に少ない。 数カ月前、ある週刊誌がみずほ銀行のシステムトラブルの原因を論じたWeb記事で、バッチ処理を「とっくの昔に時代遅れになった手法」と書き、ネットで論争になった。確かにバッチ処理は使われ始めてから長い年数がたつが、現在のシステムでも広く使われている。現場のエンジニアからは「時代遅れという表現には違和感がある」との意見が相次いだ。 先の記事には「みずほは何らかの理由で（バッチ処理に）こだわっていた」とあった。しかし、みずほだけが特にバッチにこだわっているわけではない。ITベンダー各社は「バッチ処理がないシステムは見たことがない」と異口同音に話す。それくらい現役バリバリでメジャーな手法だ。 データをためて後で一括処理 そもそもバッチ処理と
バッチ処理とCOBOLは時代遅れ？ | スラド IT
ITベンダーの間では、かねて『なぜみずほは、わざわざ高齢のエンジニアを雇ってまでCOBOLを使い続けるのか』が疑問視されていました といった、ITジャーナリストの発言を掲載している。 しかしながら、銀行業務の中ではバッチ処理が適した性質のものも多いだろうし、過去の資産を使いまわさないといけない局面はたくさんあるのだからCOBOLエンジニアが必要（たとえそれが他の言語に移植する仕事だとしても）だろうし、上記2点がみずほ銀行のシステムの「爆弾」だとは言い過ぎの気がするがどうだろうか。
AWS CDK で EventBridge + Lambda で定期実行処理（バッチ処理）を実装してみた | DevelopersIO
はじめに プロフィールビューアーサービスProflly（プロフリー）の開発にて、定期的にデータを集計して、集計結果を保存しておく処理を、AWS CDK（TypeScript） を使って EventBridge + Lambda にて実装してみました。その定期実行処理（バッチ処理）の実装方法を紹介させていただきます。 作成するアーキテクチャ EventBridgeを利用して月初の AM 1:00 (JST) に Lambda を定期的に実行するように作成します。 環境 AWS CDK 1.121.0 TypeScript 3.9.7 実装内容 利用するパッケージをインストール 今回作成するアーキテクチャに必要なパッケージをインストールします。 npm install --save-dev @aws-cdk/aws-dynamodb @aws-cdk/aws-lambda-nodejs @aw
サーバーレスにおけるべき等性の実装 (バッチ処理と分散トランザクション編) ~サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第 4 回~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
このシリーズの 第２回 では、クライアントからバックエンドのサービスを利用する際に、なんらかの原因でエラーが発生した場合にクライアント側でリトライ処理が実行されると、リクエストが重複して送られる可能性があることを説明しました。クライアントからキューに対してメッセージを送信するようなサーバーレスのシステムにおいては、リトライ処理によって重複したメッセージが送信されてもメッセージの重複を排除する機能を利用することによってべき等性を実現する方法について解説を行いました。その中では、重複したメッセージをただ一度だけ処理する (Exactly Once) ことで、結果としてべき等性を実現するという具体的な実装方法と共に紹介しました。 第 3 回 では、キューからメッセージを取り出し、バックエンドのデータソースへ保存する処理においても、何らかのエラーによってリトライ処理が発生した場合に重複してデータの
AWS Lambda でのカスタムチェックポイントによるバッチ処理の最適化 | Amazon Web Services
Amazon Web Services ブログ AWS Lambda でのカスタムチェックポイントによるバッチ処理の最適化 AWS Lambdaは、Amazon Kinesis Data StreamsやAmazon DynamoDB Streamsなどのソースから取得した複数メッセージをバッチ処理できます。通常の操作では、処理を行う関数は1つのバッチから次のバッチに移動して、ストリームからのメッセージを消費します。 ただし、バッチ内のアイテムの1つでエラーが発生すると、そのバッチ内の同じメッセージ群の一部が再処理される可能性があります。新しいカスタムチェックポイント機能により、失敗したメッセージを含むバッチの処理方法をより詳細に制御できるようになりました。 このブログ記事では、バッチ失敗時のデフォルトの動作と、このエラー状態に対処するために開発者が使用可能なオプションについて説明します。
Webのバッチ処理とオンライン処理のポイントとシステムの応答性能を学ぶ#3（社内勉強会）｜TechRacho by BPS株式会社
#1 処理時間とレスポンス時間 #2 バッチ処理とオンライン処理 #3 バッチ処理を設計するときの注意点（本記事） #4 オンライン処理とUXの工夫 #5 Railsのジョブ管理システムと注意点 #6 バッチ処理ですぐに使えるノウハウ、まとめ バッチ処理を設計するうえでの注意点 バッチ処理を設計する際は、処理時間がどの程度になるのかを事前に計測・見積し、その結果を元に実行計画を立てるのが重要です。少なくとも、所要時間の見通しもなくバッチ処理を作成するのは危険です。 一般的にはデータ量が増えれば処理時間も増えるので、データ量が増えたときに処理時間がどのように延びるかは予め見積もっておきます。たとえば「データが1万件のときは20分、件数が倍になると処理時間が4倍増える」といったように、データ増加に応じた処理時間を予測できるように計測やベンチマークを事前に実施しておく必要があります。 データ量と
【レポート】サーバー⽴てっぱなしはもったいない︕ サーバーレスのみで構築する 中頻度&短時間バッチ処理 #PAR-29 #AWSSummit | DevelopersIO
本記事は、AWS Summit Japan 2021のセッション動画、「PAR-29: サーバー⽴てっぱなしはもったいない︕ サーバーレスのみで構築する 中頻度&短時間バッチ処理」のレポート記事です。 セッション概要 10 分に一度しか動かさないバッチ処理のためにずっと起動しっぱなしのサーバーを見てもったいないと感じたことはないでしょうか。 しかもその処理が 2,3 分もあれば全て終わってしまうとなれば尚更です。 本セッションでは AWS Step Functions を中心にサーバーレスなサービスを使用することで無駄な待機コストを無くし、かつレイテンシとスループットをできる限り上げたアーキテクチャを実際に設計・開発して得られた知見をご紹介いたします。 スピーカー 株式会社ゆめみ マーケティングソリューション事業部 遠藤 大輔 氏 セッションページURL https://summits-j
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ
「生保にメインフレームは不可欠」ソニー生命が月1000件超のバッチ処理依頼を自動化
GCPのバッチ処理サービス「Batch」を試してみる
改善施策のプランニングが鍵 - 大規模バッチ処理のテストフレームワーク刷新プロジェクト
なぜバッチ処理が得意なのか、純国産の次世代高速RDB「Tsurugi」
Microsoft 365 Developer Proxy v0.10リリース。バッチ処理のサポートと$selectガイダンスの改善を導入
DynamoDBはバッチ処理よりストリーム処理との相性が良いという話
バッチ処理が時間内に終わらない、原因はサーバーではなくまさかの「ルーター」
BigQueryへEmbulkで転送するバッチ処理を改善した話 - High Link テックブログ
EventBridgeとECSでお手軽バッチ処理基盤 (後編) - Gunosy Tech Blog
EventBridgeとECSでお手軽バッチ処理基盤 (前編) - Gunosy Tech Blog
AIで画像をアップスケールする無償ツール「Upscayl」に16倍拡大モードとバッチ処理が追加／最新版v1.5.0がリリース
業務自動化のために「バッチ処理」「RPA」「AI」をどう使い分けるべきか ITRが指針
バッチ処理を作る際に押さえておくこと - Qiita
バッチ処理の改善〜トランザクション範囲の最小化〜 - Timee Product Team Blog
バッチ処理の改善 〜冪等性の設計導入〜 - Timee Product Team Blog
バッチ処理実装時に考慮すべき事項 | メルカリエンジニアリング
バッチ処理のリグレッションテスト自動化のトライ | メルカリエンジニアリング
Web APIやバッチ処理を工夫 Go導入で生産性が安定、メンバーのモチベーションも向上
データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし
バッチ処理おじさんがストリーム処理のシステムを開発するにあたって調べたこと
AWSサーバーレスバッチ処理アーキテクチャの構築 | Amazon Web Services
バッチ処理は本当に時代遅れか、みずほ銀行も苦しめたその正体