Content-Length: 342456 | pFad | http://b.hatena.ne.jp/q/%E3%83%90%E3%83%83%E3%83%81%E5%87%A6%E7%90%86

バッチ処理の人気記事 71件 - はてなブックマーク

並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 71件

新着順 人気順

バッチ処理の検索結果1 - 40 件 / 71件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

バッチ処理に関するエントリは71件あります。 batchawstechfeed などが関連タグです。 人気エントリには 『バッチ処理 プラクティス』などがあります。
  • バッチ処理 プラクティス

    バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か?」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。

      バッチ処理 プラクティス
    • データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし

      こんにちは、id:shallow1729です。最近はインフラ寄りなお仕事をよくやっていますがこれまでにいくつかデータ移行やデータ基盤構築などのバッチ処理のお仕事をしてきました。以前にも一度そういった経験を元に記事を書いたのですが、MySQLやシステムに関する知識が以前よりも増えた今もう一度書き直したいなと思いました。 なので今回はバッチ処理を書く時のテクニック2022版という感じです。今の仕事の関係でMySQLやrailsを前提にしている話が多いですが、おそらく他のデータベースを使っている人にも役に立つ話が多いのではないかと思います。ただ、今回の記事は経験に基づくものが多く、あまりよくないアイデアもあるかもしれません。改善点や間違いなどあればご指摘ください。 冪等性を持つように 冪等性とは端的に言えばある操作を複数回実行しても一回しか実行しなかった時と同じ結果になる性質の事です。長時間かか

        データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし
      • AWSでバッチ処理を実装する際の選択肢とサービス比較

        処理が複雑でジョブの依存関係を定義したい場合は、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 追記 「常時リクエストがくるユースケー

          AWSでバッチ処理を実装する際の選択肢とサービス比較
        • AWS でバッチ処理・定期実行する4つの方法(EC2,EventBridge,SQS,ECS,Lambda)

          AWS上でバッチ処理を行う場合に、 どのAWSサービスが選択肢として考えられるかどのAWSサービスを選択すればいいのかについて考えていきます。 AWSでバッチ処理・定期実行する方法を4つ紹介し、それぞれ特徴やメリットとデメリットがありますので、この点について記載していきます。 バッチ処理・定期実行方式のパターンと特徴を知って適切な手段を選択しよう!という記事です。 まずはどのような構築方法があるかについて記載していきます。

            AWS でバッチ処理・定期実行する4つの方法(EC2,EventBridge,SQS,ECS,Lambda)
          • AWSサーバーレスバッチ処理アーキテクチャの構築 | Amazon Web Services

            Amazon Web Services ブログ AWSサーバーレスバッチ処理アーキテクチャの構築 この投稿は、AWSソリューションアーキテクトであるReagan RosarioとWWPSソリューションアーキテクトであるMark Curtisによって書かれました。バッチ処理は多くの組織にとって基礎となるもので、大量の情報を効率的に自動化した形で処理することができます。ユースケースとしては、ファイル取り込み処理、キューベースの処理、トランザクションジョブ、さらに重いデータ処理のジョブなど、多岐にわたります。 この記事では、ファイル取り込み処理を実装するためのバッチ処理を、サーバーレスに実現するための方法を説明していきます。今回の例では、オーケストレーションにAWS Step Functions、オンデマンドのコンピューティングにAWS Lambda、データストアにAmazon S3、メールの送

              AWSサーバーレスバッチ処理アーキテクチャの構築 | Amazon Web Services
            • 【AWS】大規模なバッチ処理を支える技術選定

              ここから、表で挙げた内容をそれぞれ解説していきます。 構築難度に関しては、関数を実装するだけで済むLambdaが最も簡単で、バッチ専用に特化されたサービスであるBatchに関しては比較的バッチ構築はしやすい印象ですが、ECSに関してはバッチに特化していないため、バッチ処理を行うようにカスタマイズする必要があります。 タイムアウト制約に関して留意すべきは、Lambdaの実行時間は15分までなので、それ以上を超える処理時間のバッチは実装できないことです。 起動•実行上のオーバーヘッドに関しては、Lambdaにはコールドスタートがあるため起動時にオーバーヘッドを考える必要があり、Batchではジョブをキューに送信して、最適化のために、ある程度のジョブがキューイングしてから実行しようするので、即時性を求める処理には不向きです。 既存バッチを移行したいケースがあると思いますが、Lambdaで動かせる

                【AWS】大規模なバッチ処理を支える技術選定
              • アナリスト出身の人にバッチ処理を書いてもらう際にレクチャー & サポートしたことメモ - yasuhisa's blog

                あまりよくある話ではないと思うんですが、アナリスト/Analytics Engineerの人にバッチ処理を書いてもらう機会がありました。基本的にはSQLを普段書かれていて*1、場合によってはTerraformを少し書くこともあるというバックグラウンドの方です。これに対して私はレクチャーやサポートする形になったので、メンター的でどういうことを考えていたかをこのエントリでは書こうと思います。 対象のタスク レクチャーしたこと Step by Stepで実装する APIやjqに慣れる Dockerfileを使って環境構築する 正常系を実装する 適切な関数やクラスに分割する コマンドライン引数や環境変数を使う 型アノテーションを付ける loggerについて知る 異常系を考慮する テストどうする問題 脱線 バッチ処理をアナリスト出身の人に書いてもらうのは適切か? バッチ処理初心者とLLMの付き合い方

                  アナリスト出身の人にバッチ処理を書いてもらう際にレクチャー & サポートしたことメモ - yasuhisa's blog
                • バッチ処理における冪等性の検討 ─ クラウドネイティブもしくは、はてなダイアリーの自動移行を題材に - Hatena Developer Blog

                  アプリケーションエンジニアのid:tkzwtksです。今回はバッチ処理の冪等性(べきとうせい、idempotence)について、どう考えるか/考えてきたかをご紹介します。 このエントリを書くきっかけとなったのは、はてなエンジニア有志で定期的に開催しているCloudNative推進会です。ここでは、社内のシステムをクラウドネイティブにしていくため「クラウドネイティブなシステムとはどういうものか?」を考えており、この会での「クラウドネイティブなバッチ処理」の議論も踏まえつつ説明していきます。 バッチ処理における冪等性とは メッセージ送信の信頼性を考慮する クラウドネイティブで可用性を高めるために どのような場合に冪等性を考慮すべきか 冪等な実装における3つのケーススタディ ケース1: n分前までに更新されたレコードを集計する ケース2: DB上の対象レコードを更新する ケース3: 対象ユーザー

                    バッチ処理における冪等性の検討 ─ クラウドネイティブもしくは、はてなダイアリーの自動移行を題材に - Hatena Developer Blog
                  • AIで画像をアップスケールする無償ツール「Upscayl」に16倍拡大モードとバッチ処理が追加/最新版v1.5.0がリリース

                      AIで画像をアップスケールする無償ツール「Upscayl」に16倍拡大モードとバッチ処理が追加/最新版v1.5.0がリリース
                    • 入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ

                      こんにちは。エンジニアリンググループの武井です。 私は現在、デジカルチームに所属し、クラウド電子カルテ、エムスリーデジカルの開発に携わっています。 昨年夏にエムスリーに入社し、早くも半年が経過しました。 digikar.co.jp この記事では、私が入社してから4ヶ月目に取り組んだ、バッチ処理の運用改善について振り返ります。 特に、新しくチームに加わったメンバーとして意識した点に焦点を当ててみたいと思います。 これから新しいチームに参加する方の参考になれば幸いです。 改善したバッチ 現状の正確な理解 現状に馴染む技術選定 自分なりの+αを加える 改善の結果 We're hiring 改善したバッチ 今回の改善対象は、特定の医療機関に紐づく全患者の全カルテをPDFファイルとして出力する、というバッチです。 デジカルのデータを医療機関側にエクスポートする用途で使われています。 移行前のアーキテ

                        入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ
                      • 商品数の増加を見据えて商品情報作成処理をPythonからBigQueryに移行した話 | SQLによるバッチ処理で工夫した3つのポイント - MonotaRO Tech Blog

                        こんにちは、EC基盤グループ 商品情報基盤チームの江村です。今回は私が所属している商品情報基盤チームで構築、運用を行っているシステムについてお話します。 モノタロウでは以前から記事になっていますが、検索システムの移行を行っており、現在商品検索ページの裏側の検索システムのSolrからElasticsearchへの切り替え*1が完了しました。 私が所属している商品情報基盤チームではElasticsearch、Spannerに入れるための商品情報の作成とSpannerおよび、Spannerからデータを取得するAPIの運用を行っています。今回はその中でもElasticsearch、SpannerのためのBigQueryでの商品情報作成処理について取り上げます。(詳しい検索部分の構成については以前の記事を参照ください) システム移行の背景 移行による設計ポイント 「MySQL + Python」の処

                          商品数の増加を見据えて商品情報作成処理をPythonからBigQueryに移行した話 | SQLによるバッチ処理で工夫した3つのポイント - MonotaRO Tech Blog
                        • AWS Lambda でのカスタムチェックポイントによるバッチ処理の最適化 | Amazon Web Services

                          Amazon Web Services ブログ AWS Lambda でのカスタムチェックポイントによるバッチ処理の最適化 AWS Lambdaは、Amazon Kinesis Data StreamsやAmazon DynamoDB Streamsなどのソースから取得した複数メッセージをバッチ処理できます。通常の操作では、処理を行う関数は1つのバッチから次のバッチに移動して、ストリームからのメッセージを消費します。 ただし、バッチ内のアイテムの1つでエラーが発生すると、そのバッチ内の同じメッセージ群の一部が再処理される可能性があります。新しいカスタムチェックポイント機能により、失敗したメッセージを含むバッチの処理方法をより詳細に制御できるようになりました。 このブログ記事では、バッチ失敗時のデフォルトの動作と、このエラー状態に対処するために開発者が使用可能なオプションについて説明します。

                            AWS Lambda でのカスタムチェックポイントによるバッチ処理の最適化 | Amazon Web Services
                          • 負債となっていたバッチ処理基盤を無停止で(ほぼ)ユーザ影響なく移行した話 - tebiki Tech Blog

                            Tebiki株式会社でtebiki現場教育サービスのプロダクトエンジニアを担当している清田です。 去年、tebiki現場教育で利用していたバッチ処理基盤を移行しました。 当記事では、その移行の内容を紹介します。 前提tebiki現場教育サービスでは、主に以下の用途でバッチ処理基盤を利用していました。 ・業務イベントに応じたメール一括送信 ・ユーザ全体へのお知らせ通知 ・ユーザの学習状況の収集 バッチ処理基盤はAWSのElastic Beanstalk上でRuby on Rails製のアプリケーションとして起動しており、wheneverというgemを利用して所定のジョブを定期実行していました。 バッチ処理基盤のアプリケーションは改修頻度が低く、社内でオーナーシップを持ってメンテナンスするメンバーがいない状況でした。 その結果、Elastic Beanstalk上で稼働するgemのバージョンが

                              負債となっていたバッチ処理基盤を無停止で(ほぼ)ユーザ影響なく移行した話 - tebiki Tech Blog
                            • DynamoDBはバッチ処理よりストリーム処理との相性が良いという話

                              テーブル内に格納されているメールアドレスのデータを使って、1日ごと、1週間ごとに全ユーザーに対してメールを送信したいというバッチがあったとしましょう。 とある1人のユーザーのメールアドレスを調べること自体はQuery操作で可能ですが、バッチ処理の性質上それを全ユーザーに対してやると考えると、実質的にはテーブル全Scanと同等の処理が要求されてしまいます。 システムを利用しているユーザーから登録情報の参照・変更を随時受け付けるたびに、このテーブルへのCRUD処理が行われます。そのため、このテーブルへの全Scanはユーザー体験を損なう可能性が高いです。 解決策の模索 「とあるテーブルに対してバッチで大量アクセスするのを防ぎたい」という要件に対して、考えられるアプローチを挙げてみます。 リードレプリカの作成 コピーテーブルの作成 リードレプリカの作成 RDSやAuroraの場合は、同じデータを持

                                DynamoDBはバッチ処理よりストリーム処理との相性が良いという話
                              • Reactのstate更新におけるバッチ処理と「関数型のstate更新」がなぜ必要なのか?について - Qiita

                                Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

                                  Reactのstate更新におけるバッチ処理と「関数型のstate更新」がなぜ必要なのか?について - Qiita
                                • 転職会議から冪等でないバッチ処理を根絶した話 - LIVESENSE ENGINEER BLOG

                                  こんにちは、かたいなかです。 最近転職会議のバッチ処理をすべて冪等にし、処理失敗時に気軽に再実行できるようにすることで運用性を向上させました。 今回の記事ではその取り組みを紹介します。 再実行すると重複送信につながるメール送信バッチ もともと、転職会議では一部のバッチ処理を除いてほとんどのバッチ処理が冪等に作られていました。しかし、残りの冪等ではないバッチ処理では、失敗するたびに毎回アドホックな対応をする必要があり運用性に課題を抱えていました 残っていたもので一番大きな問題を抱えていたのがメール送信バッチです。これは、以下の図のようなアーキテクチャで動いており、ワーカーにメールを送信するように指示するメッセージをSQSにキューイングする処理を行うものです。 このメール送信バッチのキューイング処理が途中で失敗した際に、雑に再実行してしまうと同一のユーザに重複してメールが送信されてしまう事にな

                                    転職会議から冪等でないバッチ処理を根絶した話 - LIVESENSE ENGINEER BLOG
                                  • 業務自動化のために「バッチ処理」「RPA」「AI」をどう使い分けるべきか ITRが指針

                                    アイ・ティ・アール(ITR)は2022年8月18日、ホワイトペーパー「業務自動化に向けた国内企業の現状と展望」を公開した。国内企業の業務自動化に向けた取り組み状況と、技術選定のポイントを解説した。 年商500億円以上の国内大企業に勤める部長職以上の役職者を対象にITRが実施した調査(2022年3月実施)によると、DX(デジタルトランスフォーメーション)における最重要課題は、「コミュニケーション/コラボレーションの高度化」(47%、複数回答、以下同)だった。次いで「業務の自動化」(45%)だ。

                                      業務自動化のために「バッチ処理」「RPA」「AI」をどう使い分けるべきか ITRが指針
                                    • ECS タスクメタデータエンドポイントを使ったバッチ処理コンテナのリソースモニタリングツール kobanzame を作りました - ようへいの日々精進XP

                                      追記 (2020/06/15) Container Insights は GA しています! tl;dr kobanzame 作ったもの 仕組み なんちゃってプラグインアーキテクチャ 使い方 設定ファイル 実行 Example 参考 それ, Container Insights で良いんじゃないのか おっしゃるとおり じゃあ, なぜ, 俺は kobanzame を作ったのか 以上 追記 (2020/06/15) Container Insights は GA しています! 2020/06/14 現在はベータ版として提供されていますが この記述は誤りで Container Insights は 2019 年 11 月には既に GA されておりますので, ここで訂正させて頂きます. aws.amazon.com 確認不足で誤った情報を記述してしまい大変申し訳ございませんでした. tl;dr 以

                                        ECS タスクメタデータエンドポイントを使ったバッチ処理コンテナのリソースモニタリングツール kobanzame を作りました - ようへいの日々精進XP
                                      • なぜバッチ処理が得意なのか、純国産の次世代高速RDB「Tsurugi」

                                        オープンソースの高速な国産リレーショナルデータベース「Tsurugi」が登場した。Tsurugiの特徴やアーキテクチャ、導入方法などを解説する。 来歴 Tsurugi1は、国のバックアップ2を受けて作られた、純国産のOSS-RDBです。もともと有志の勉強会から始まったコミュニティ活動がベースで、各民間企業(ノーチラス・テクノロジーズ/NEC)、大学(東京工業大学/慶応大学/名古屋大学/大阪大学)、研究機関(国立天文台)などが主体となり、さまざまな企業・関係者の協力のもとに開発された、次世代高性能RDBです。OSSなので、だれでも自由に利用できます。商用サポートも提供されています。 2 なお、国によるバックアップは国立研究開発法人新エネルギー・産業技術総合開発機構(NEDO)によるもので、「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発/次世代コンピューティング技

                                          なぜバッチ処理が得意なのか、純国産の次世代高速RDB「Tsurugi」
                                        • バックグラウンドで実行するバッチ処理の改善のためSidekiq Enterpriseを導入しました🥳 - メドピア開発者ブログ

                                          こんにちは、エンジニアの森田です。 MedPeerでは、バックグラウンドで非同期に処理を実行させる方法としてSidekiqを使っておりましたが、今回Sidekiq Enterprise(Proを含む)を導入しました。 https://sidekiq.org/products/enterprise.html 今回はSidekiq Enterpriseを導入するにあたって解決したかった課題と実際の導入方法、導入後の活用事例をを紹介できればと思います! Sidekiq Enterpriseとは? Sidekiq Enterpriseとは、その名の通りエンタープライズ向けの機能拡張が行われた有料版のSidekiqです。(Sidekiq Enterpriseとは別にSidekiq Proもありますが、Sidekiq Enterpriseを導入するとSidekiq Proの機能も使用出来るようになりま

                                            バックグラウンドで実行するバッチ処理の改善のためSidekiq Enterpriseを導入しました🥳 - メドピア開発者ブログ
                                          • [アップデート]ゼロキャパシティからのバッチ処理に最適!AWS Batch で AWS Fargate が利用可能になりました! #reinvent | DevelopersIO

                                            本日のアップデートで AWS Batch で AWS Fargate の利用が可能になりました! Serverless Batch Scheduling with AWS Batch and AWS Fargate AWS Batch for AWS Fargate AWS Batch はジョブをキューイングすると、定義された内容に従い自動的にコンピューティングリソースを起動し、計算処理を実行するバッチコンピューティングのサービスです。バックグラウンドでは Amazon ECS が動いているのですが、ユーザーは ECS を意識することがないようにラッピングされています。 従来はいわゆる ECS on EC2 がサポートされていましたので、ラッピングされてるとはいえ EC2 ホストの存在は少なからずとも意識する必要がありました。加えてゼロキャパシティからスケールする際は、キューイングしてから

                                              [アップデート]ゼロキャパシティからのバッチ処理に最適!AWS Batch で AWS Fargate が利用可能になりました! #reinvent | DevelopersIO
                                            • BERTを使ったMLバッチ処理実サービスのアーキテクチャとMLOpsの取り組み

                                              MLOpsの取り組みについて

                                                BERTを使ったMLバッチ処理実サービスのアーキテクチャとMLOpsの取り組み
                                              • GCPのバッチ処理サービス「Batch」を試してみる

                                                それぞれ微妙にできることや制限に違いがあり、ここを捉えた上で選択する必要があります。 Batchの強みはおそらくタイムアウトがないことによって長時間実行ができ、かつシンプルに実装できることだと思います。 (タイムアウト最大値に関して、Batchにおいては存在しないと公式動画の方で説明していますが、Cloud Composerについては不明でした。) Batch単体でもジョブ定義ファイル内で各タスクの依存関係(順次実行、並列実行)はできますが、Cloud ComposerやWorkflowsのように複雑なジョブネットを書くことは難しそうです。 ジョブネットのように動かしたい場合には公式ドキュメントにもあるようにWorkflowsなどからBatchジョブを実行するのが良さそうです。 動かしてみよう 実際にジョブを作って動かすまで試してみたいと思います。 GCP公式がBatchのサンプルコードを

                                                  GCPのバッチ処理サービス「Batch」を試してみる
                                                • 評価関数のバッチ処理に対応したブラックボックス最適化ライブラリの開発 - Preferred Networks Research & Development

                                                  本記事は、2020年インターンシップで勤務した高橋芽生さんによる寄稿です。 はじめに 2020年度PFN夏季インターン生の高橋芽生です。 今回のインターンではメタヒューリスティクスライブラリの開発を行いました。 コードはこちらで公開しています。 メタヒューリスティクス メタヒューリスティクスという用語には様々な意味がありますが、本稿では個々の問題に依存しない連続的な最適化のための一般的なフレームワークを指すものとします。これは関数の形が陽に与えられていない場合の最適化手法であるブラックボックス最適化の一つです。ブラックボックス最適化には、機械学習のハイパーパラメータチューニングや、音声認識システム [1]、結晶構造の解析 [2]、ソーシャルゲームの難易度・バランス調整 [3]などの応用先が知られています。多くのメタヒューリスティクスの手法では、同じバッチのスコアは互いに影響しないため、複数

                                                    評価関数のバッチ処理に対応したブラックボックス最適化ライブラリの開発 - Preferred Networks Research & Development
                                                  • バッチ処理は本当に時代遅れか、みずほ銀行も苦しめたその正体

                                                    ITシステムに関わるエンジニアなら、「バッチ処理」という言葉を聞いたことがある人がほとんどだろう。しかし、バッチ処理とは何かを正確に理解している人は意外に少ない。 数カ月前、ある週刊誌がみずほ銀行のシステムトラブルの原因を論じたWeb記事で、バッチ処理を「とっくの昔に時代遅れになった手法」と書き、ネットで論争になった。確かにバッチ処理は使われ始めてから長い年数がたつが、現在のシステムでも広く使われている。現場のエンジニアからは「時代遅れという表現には違和感がある」との意見が相次いだ。 先の記事には「みずほは何らかの理由で(バッチ処理に)こだわっていた」とあった。しかし、みずほだけが特にバッチにこだわっているわけではない。ITベンダー各社は「バッチ処理がないシステムは見たことがない」と異口同音に話す。それくらい現役バリバリでメジャーな手法だ。 データをためて後で一括処理 そもそもバッチ処理と

                                                      バッチ処理は本当に時代遅れか、みずほ銀行も苦しめたその正体
                                                    • goroutineでバッチ処理時間を大幅に改善した話 - Tech Do | メディアドゥの技術ブログ

                                                      はじめに こんにちは、Media Do Tech Do Blog初執筆のogadyです。 メディアドゥには2019年の8月に入社して、この度ついにブログ執筆させていただくことになりました! 本記事では、私のチームで運用しているバッチツールをgoroutineで高速化した話をさせていただきます。 背景 現在メディアドゥでは、二つの電子書籍取次システムを片寄せし、統合する案件を進めています。 私のチームは、システムのDBマイグレーションを行う移行・突合システムをgoで開発・運用しています。 移行・突合システムでは、移行元の取次システムのデータを移行・突合システムにインポートして、ごちゃごちゃ加工してマイグレーションしています。 移行・突合システムイメージ図 この「取次システムのデータを移行システムにインポートして」という部分が曲者で、最新状態を保つため定期的・突発的に移行システムのDBを総入替

                                                        goroutineでバッチ処理時間を大幅に改善した話 - Tech Do | メディアドゥの技術ブログ 
                                                      • バッチ処理が時間内に終わらない、原因はサーバーではなくまさかの「ルーター」

                                                        サーバーのバッチ処理が時間内に終わらないとの相談が顧客から寄せられた。ログを調べると、バッチ処理に使用するマスターデータの生成に時間がかかっていた。このためデータを生成するデータベースサーバーを調べたが異常は見つからなかった。それもそのはず、原因はネットワーク上に存在する1台のルーターだったのだ。 不具合が報告されているハードやソフトを利用するシステムでトラブルが発生したら、その不具合が原因に違いないと考えるだろう。実際、不具合が原因であることが多い。だが一方で、不具合とは無関係の箇所に原因が潜んでいる場合もある。この場合、トラブル解決は往々にして難航する。 顧客企業のシステム運用を請け負うチームのリーダーだったラックの七沢樹さんが直面したトラブルがまさにこのケースだった。七沢さんはどのようにして原因を突き止めたのだろうか。 時間内に終わらず子会社の業務に支障 七沢さんたちのチームが運用を

                                                          バッチ処理が時間内に終わらない、原因はサーバーではなくまさかの「ルーター」
                                                        • WebPやHEICを含む画像ファイルの変換や圧縮、リサイズのバッチ処理が可能なMac用イメージコンバーター「Image Tool+」がリリース。

                                                            WebPやHEICを含む画像ファイルの変換や圧縮、リサイズのバッチ処理が可能なMac用イメージコンバーター「Image Tool+」がリリース。
                                                          • バッチ処理実装時に考慮すべき事項 | メルカリエンジニアリング

                                                            はじめに メルペイバックエンドエンジニアの @r_yamaoka です。この記事は、Merpay Tech Openness Month 2022 の16日目の記事です。 私がつい最近まで所属していた加盟店管理業務を担うマイクロサービス群(以下、加盟店管理システム)では様々なバッチが稼働しています。本記事ではそれらの実装において過去に発生したトラブルやヒヤリハットから得た知見を共有したいと思います。 背景 本題に入る前に加盟店管理システムでどのような箇所にバッチ処理が採用されているかについて少し解説します。バッチ処理を採用するか否かの観点としては大きく下記2点があります。 機能要件上バッチ処理を採用しなければならない 非機能要件の都合で同期処理を採用できない 前者の例としては「配送業者との伝票情報連携」や「行政システムとの連携処理」というものがあり、これは連携先である配送業者や行政の業務の

                                                              バッチ処理実装時に考慮すべき事項 | メルカリエンジニアリング
                                                            • 「生保にメインフレームは不可欠」ソニー生命が月1000件超のバッチ処理依頼を自動化

                                                              「8割9割ではなく、100%自動化することを重視した」。ソニー生命保険の後藤聖央執行役員兼ITデジタル戦略本部長はこう語る。 ソニー生命は、2020年6月からメインフレームにおけるバッチ処理やアプリケーションリリースに関する作業依頼の自動化を進めている。「100%自動化」を重視するのは、自動化の例外を残せば、作業依頼にかかる人員を完全になくすことはできないためだ。 同社は2023年4月に自動化システムの本格利用を開始した。オペレーターが依頼書などで受け付けていた1カ月に1000件以上の作業依頼を自動化し、処理実行までの時間を短縮した。依頼書のチェックにかかっていた人手も削減した。 ソニー生命では基幹系がメインフレーム上で稼働している。メインフレームは米IBM製だ。その中で「バッチ処理を大量に抱えている」(後藤執行役員)。例えば、顧客の口座から保険料を引き落とすため銀行に対してデータを定期的

                                                                「生保にメインフレームは不可欠」ソニー生命が月1000件超のバッチ処理依頼を自動化
                                                              • [アップデート] AWS LambdaがAmazon SQSをイベントソースとしたバッチ処理で部分応答をサポートしました | DevelopersIO

                                                                Amazon SQSをイベントソースとしたLambda関数のバッチ処理において、一部の失敗したメッセージのIDを返すことで成功したメッセージは削除され失敗したメッセージはキューに残せるようになりました。 こんにちは。サービスグループの武田です。 AWS LambdaはPythonやJavaScriptで書かれた処理をクラウド上で実行できるAWSのFaaSです。さまざまなサービスと統合されていますが、そのひとつとしてAmazon SQSがあります。イベントソースマッピングという機能を使用することで、SQSへのメッセージ送信をトリガーとしてLambda関数を実行できます。SQSをイベントソースとしたLambda関数のトリガーは、バッチ処理として複数のメッセージをまとめて処理させることができます。さて複数のメッセージをまとめて処理する場合に起こる問題として、一部は成功するが一部は失敗してしまった

                                                                  [アップデート] AWS LambdaがAmazon SQSをイベントソースとしたバッチ処理で部分応答をサポートしました | DevelopersIO
                                                                • サーバーレスにおけるべき等性の実装 (バッチ処理と分散トランザクション編) ~サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第 4 回~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

                                                                  このシリーズの 第2回 では、クライアントからバックエンドのサービスを利用する際に、なんらかの原因でエラーが発生した場合にクライアント側でリトライ処理が実行されると、リクエストが重複して送られる可能性があることを説明しました。クライアントからキューに対してメッセージを送信するようなサーバーレスのシステムにおいては、リトライ処理によって重複したメッセージが送信されてもメッセージの重複を排除する機能を利用することによってべき等性を実現する方法について解説を行いました。その中では、重複したメッセージをただ一度だけ処理する (Exactly Once) ことで、結果としてべき等性を実現するという具体的な実装方法と共に紹介しました。 第 3 回 では、キューからメッセージを取り出し、バックエンドのデータソースへ保存する処理においても、何らかのエラーによってリトライ処理が発生した場合に重複してデータの

                                                                    サーバーレスにおけるべき等性の実装 (バッチ処理と分散トランザクション編) ~サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第 4 回~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
                                                                  • 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

                                                                      AWS CDK で EventBridge + Lambda で定期実行処理(バッチ処理)を実装してみた | DevelopersIO
                                                                    • バッチ処理をFargateに移行した - アクトインディ開発者ブログ

                                                                      morishitaです。 先日、いこーよを Kubernetes に移行した件を紹介しました。 tech.actindi.net いこーよは Web だけで動いているわけではなく、裏で定期的に実行されるバッチ処理も行っています。 本エントリではそのバッチ処理の実行環境を Fargate ECS に移行した件について書きます。 移行前はどうなってた? いこーよは Rails で開発しています。 バッチ処理というと、DB を集計したり、一斉に DB の値を書き換えたりするものがほとんどです。 そこで ActiveRecord のモデルを利用したいので、バッチ処理も Rails で実装しています。 つまり、Rails Runner で定期的にバッチ処理を実装したメソッドを実行しています。 移行前は、バッチ処理専用サーバがあって、crond で定期的に実行していました。 バッチ処理そのものやバッチ

                                                                        バッチ処理をFargateに移行した - アクトインディ開発者ブログ
                                                                      • バッチ処理おじさんがストリーム処理のシステムを開発するにあたって調べたこと

                                                                        ほとんどバッチ処理しか書いたことのない者だがストリーム処理のシステムを開発することになった。 それにあたって独学で調べたことなどまとめておく。 ストリーム処理とは#そもそも “ストリーム処理” とは何を指しているのか。 以下の引用が簡潔に示している。 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 サービスが終了しないかぎり

                                                                          バッチ処理おじさんがストリーム処理のシステムを開発するにあたって調べたこと
                                                                        • Web APIやバッチ処理を工夫 Go導入で生産性が安定、メンバーのモチベーションも向上

                                                                          「golang.tokyo」は、プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。ここで、フューチャー株式会社の真野氏が登壇。ここからは、Goの導入で工夫していることを紹介します。 WebAPIからバッチ処理までの工夫 真野隼記氏:ここから話は変わって、実際に使っている、導入の部分で工夫しているところをいくつか紹介したいと思います。(スライドを示して)Goの導入ですが、Goのバックエンド中心で強いのはだいたいそのとおりで、WebのAPIサーバやバッチ処理、BOTのアプリやCLIツールなどをいくつか導入しています。 細かな工夫について、WebのAPIやバッチで特に生産性に加味しそうなところを話していきたいと思います。 (スライドを示して)まずWebのAPIですが、特に技術選定のリーダーポジションでよく思うことです。デファクトスタンダードなWebのフレ

                                                                            Web APIやバッチ処理を工夫 Go導入で生産性が安定、メンバーのモチベーションも向上
                                                                          • Lambda でバッチ処理を構築する際のエラー通知パターン 5選 - サーバーワークスエンジニアブログ

                                                                            はじめに パターン1. 直接Publish パターン メリット デメリット パターン2. DLQパターン メリット デメリット パターン3. 失敗時送信先パターン メリット デメリット パターン4. メトリクスフィルターパターン メリット デメリット パターン5. サブスクリプションフィルターパターン メリット デメリット 各パターン比較表 まとめ はじめに アプリケーションサービス部の宮本です。 お仕事でLambda を使ったバッチ処理を構築することが多いのですが、バッチ処理でエラーが発生した場合、通知が必要なケースが大半です。そこで通知の方法について、幾つかパターンがあるので纏めてみることにしました。 イメージとしては以下の様なバッチ処理です。条件に当てはまらない場合は別のアプローチもご検討ください。 ここでいうバッチ処理のイメージ 実行頻度は1日数回程度以下。 失敗すると何かしらの業

                                                                              Lambda でバッチ処理を構築する際のエラー通知パターン 5選 - サーバーワークスエンジニアブログ
                                                                            • バッチ処理の改善 〜冪等性の設計導入〜 - Timee Product Team Blog

                                                                              前編(トランザクション範囲の最小化)へ はじめに こんにちは。タイミーのバックエンドエンジニア中野です。 前編では締めのバッチ処理におけるトランザクションの範囲を最小化した技術的改善をご紹介しました。トランザクションの範囲をバッチ処理全体から最小限の範囲に変更したことにより、バッチ処理が失敗した場合に請求レコードの処理が途中まで完了している状態が発生するようになりました。後編では、処理対象の請求レコードに対し状態を持たせることでバッチ処理全体での冪等性を担保し、バッチ処理が途中で失敗した場合でも安全に処理を再開できるようにした取り組みをご紹介します。 はじめに 締めのバッチ処理とは 現状の課題認識 実施した施策 冪等性とは 冪等性を実現する方法 バッチ処理への適用 達成できたこと 今後の課題 スループット向上とリソース最適化 まとめ 締めのバッチ処理とは まずは前編のおさらいになりますが、

                                                                                バッチ処理の改善 〜冪等性の設計導入〜 - Timee Product Team Blog
                                                                              • AWS ECS で実行するバッチ処理を Cluster Auto Scaling を使ってコスト最適化する - Hatena Developer Blog

                                                                                システムプラットフォームチームで SRE をしている id:chaya2z です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の6月号です。先月は id:MysticDoll さんの Postfixのログ監視で注意すべきSMTPのステータス仕様について でした。 ECS で実行するバッチ処理を、インスタンス数を最適化する仕組みである ECS Cluster Auto Scaling を使ってコスト最適化した取り組みを紹介します。 ECS の起動タイプに EC2 を使う背景 はてなでは、ECS の起動タイプとして Fargate ではなく EC2 を使用しているサービスがあります。そのサービス例として、バッチ処理があります。バッチ処理のジョブには数秒・数分で終わるものもあれば、数時間かかるものがあります。 EC2 起動タイプを選ぶ理由は、タスク終了までのタイムアウト待

                                                                                  AWS ECS で実行するバッチ処理を Cluster Auto Scaling を使ってコスト最適化する - Hatena Developer Blog
                                                                                • 改善施策のプランニングが鍵 - 大規模バッチ処理のテストフレームワーク刷新プロジェクト

                                                                                  dummy GA 新しいURLに転送しています… https://stockmark-tech.hatenablog.com/entry/2023/12/05/130000...

                                                                                    改善施策のプランニングが鍵 - 大規模バッチ処理のテストフレームワーク刷新プロジェクト

                                                                                  新着記事









                                                                                  ApplySandwichStrip

                                                                                  pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


                                                                                  --- a PPN by Garber Painting Akron. With Image Size Reduction included!

                                                                                  Fetched URL: http://b.hatena.ne.jp/q/%E3%83%90%E3%83%83%E3%83%81%E5%87%A6%E7%90%86

                                                                                  Alternative Proxies:

                                                                                  Alternative Proxy

                                                                                  pFad Proxy

                                                                                  pFad v3 Proxy

                                                                                  pFad v4 Proxy