並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 77件

新着順 人気順

batchの検索結果1 - 40 件 / 77件

  • 入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ

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

      入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ
    • EC2とcronで動いていたバッチ基盤をマネージド化した - Uzabase for Engineers

      概要 ソーシャル経済メディア「NewsPicks」SREチームの中川です。 皆さんはバッチ処理基盤はどうされていますでしょうか。 NewsPicks では少し前まではそれらをEC2、cronの組み合わせで動作させていました。 何年も前からこの仕組みだったのですがSREとしてはEC2の面倒見るのも手間ですし、それ以上にcronを変更する際のオペレーションミスが目立ったのが懸念点でした。 その為、まずはAWSマネージド化するための基盤を整備し、その後バッチアプリを載せ替えていくようにしました。 対応前の基盤構成 同じSREチームの安藤さんが CloudNative Days Tokyo 2023 で登壇されたときの資料をお借りします。 ご覧の通り、大体のサービスはマネージド化していましたがバッチ基盤だけは旧来のままEC2インスタンスを利用していました。 10年モノのサービスのインフラを漸進的

        EC2とcronで動いていたバッチ基盤をマネージド化した - Uzabase for Engineers
      • GKEでMLバッチ運用のコツ - エムスリーテックブログ

        この記事はエムスリーAdvent Calendar 2023とMLOps Advent Calendar 2023の12日目の記事です。 AI・機械学習チームの北川です。 最近は猫のかまってアピールがすごすぎて、よく仕事の邪魔されます。 かまって欲しがる猫 現在AI・機械学習チームではMLのバッチをGoogle Kubernetes Engine(GKE)上で運用しています。 現在数えてみたところ240個以上のバッチがGKE上で動いているようです。 AI・機械学習チームでは2019年頃から約4年ほどGKE上でMLバッチを運用しています。 その間にコストの最適化や安定したバッチの運用などに力を入れてきました。 この記事では、主にスケールインとコスト最適化について説明しようと思います。 チームのMLについて全体を把握したい場合は以下の記事が詳しいです。 www.m3tech.blog GKEの

          GKEでMLバッチ運用のコツ - エムスリーテックブログ
        • [レポート] Amazon MWAA と AWS Step Functions を比べてみた #AWSreInvent #API307 | DevelopersIO

          [レポート] Amazon MWAA と AWS Step Functions を比べてみた #AWSreInvent #API307 こんにちは、muroです。AWS事業本部 サービス開発室でopswitchの開発・運用を担当しています。opswitchは今年の1月にApache Airflowベースのアーキテクチャから、AWS Step Functionsに移行しました。 今回 re:Invent で Amazon MWAA と AWS Step Functions のそれぞれの長所短所を学ぶセッションがあったので、自身の理解度を確認するために受講してきました。 セッションの概要 タイトル Comparing Amazon MWAA and AWS Step Functions 概要 Organizations looking to orchestrate ETL data pipel

            [レポート] Amazon MWAA と AWS Step Functions を比べてみた #AWSreInvent #API307 | DevelopersIO
          • 【AWS】大規模なバッチ処理を支える技術選定

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

              【AWS】大規模なバッチ処理を支える技術選定
            • AWS GlueからAWS Batchにしたことで費用を75%削減した - Classi開発者ブログ

              こんにちは、最近データエンジニア業を多くやっているデータサイエンティストの白瀧です。 これまでClassiのデータ基盤は、Reverse ETLをしたり監視システムを導入したりとさまざまな進化をしてきました。しかし、Classiプロダクトが発展するとともにデータ量が増加し、これまでのデータ基盤では耐えられない状態に近づいてきました。 そこでデータ基盤の一部(DBからのExportを担う部分)のリアーキテクチャを実施したので、この記事で紹介したいと思います。 概要 Classiのデータ基盤では、Amazon RDSからAmazon S3へJSONで出力し、その後GCS→BigQueryという流れでデータを送り、BigQueryからもBIツールやReverse ETLなどで使っています。詳細は、Classiのデータ分析基盤であるソクラテスの紹介 - Classi開発者ブログを参照してください。

                AWS GlueからAWS Batchにしたことで費用を75%削減した - Classi開発者ブログ
              • Background Tasks in FastAPI

                Before jumping into Celery. Let's start with the most straightforward tool to help us understand background tasks. FastAPI already has a BackgroundTasks class that can help us implement simple background tasks. Let's create a virtual environment to isolate our project requirements. python -m venv env Now, all we need is FastAPI and a web server e.g. Uvicorn or Hypercorn. Before installing these le

                • 1秒動画のつくり方 ― 「家族アルバム みてね」における動画エンコードパイプラインとその最適化事例 | gihyo.jp

                  なお上記の「大量配信」とは、「⁠1~3月分の四季版を4月15日から配信開始し、1週間で全家族に配信完了する」などのように、「⁠新しい期間の1秒動画をはじめて配信してから、その時点で条件を満たす全家族への配信が完了するまで」の期間を指します。1秒動画の生成・配信の大部分はこの大量配信期間に行っていることから、これを「大量配信」と呼んでいます。 生成⁠・配信の流れ 1秒動画の生成・配信は、図1のとおり(1)対象家族抽出、(2)素材選択、(3)動画エンコード、(4)配信、の4段階で実現しています。以下ではその詳細を説明します。 図1 1秒動画の生成・配信の流れ (1)対象家族抽出 1秒動画の生成・配信処理は、基本的にはバッチ処理として毎日実行しています。そのはじめに行うのは、「⁠その日、どの家族に、どのバージョン・どの期間の1秒動画を生成・配信するか」を取り出す対象家族抽出です。この処理は四季版

                    1秒動画のつくり方 ― 「家族アルバム みてね」における動画エンコードパイプラインとその最適化事例 | gihyo.jp
                  • Google Cloud Batchを使ってバッチの処理待ち時間を1/30以下にしたので紹介させて欲しい - DeLMO(identify)エンジニアブログ

                    この記事について 今回、Google CloudのBatchを利用した動画変換処理を実装したので、どのようにしたのか、どこにハマったのか(ハマっているのか)、その効果についてまとめました。端的に現状を3行でまとめると、以下のようになります。 動画変換処理にGoogle CloudのBatchを使いました GPUを利用することで処理時間を短くできました コンテナでGPUをうまく使えずシェルスクリプトとGoで作ったバイナリを活用しています(コンテナ化の知見募集中です) はじめに はじめまして。identify株式会社 CTOの@suthioです。 弊社、identify株式会社では動画素材サービスDeLMOの運営を行っています。 service.delm0.jp 簡単に言うと、動画素材を提供するサービスとなります。 課題 弊社ではGoogle Cloud Platformをインフラとして利用し

                      Google Cloud Batchを使ってバッチの処理待ち時間を1/30以下にしたので紹介させて欲しい - DeLMO(identify)エンジニアブログ
                    • AWS でバッチ処理・定期実行する4つの方法

                      4つのバッチ処理・定期実行方式の詳細情報それぞれのバッチ処理・定期実行方式について詳細を見ていきます。 EC2について使用するAWSサービスEC2 処理概要Linux系OSで用いられる定時実行機能であるcronのコマンドを使用する メリット昔からよく使われているcronの知識が使える デメリットEC2インスタンスを起動しておく必要があり、使っていない時間もコストがかかる 障害に弱い。EC2サーバに障害があると終わる サーバが複数になると管理が大変 SQS×ECS使用するAWSサービスEventBridge SQS ECS 処理概要EventBridgeでキューを生成。ECSコンテナでキューを取得して実行する メリットECSを起動しておくため、コンテナの起動時間を要さない。 デメリットEventBridgeでキューを生成するが、EventBridgeはまれに1 つのイベントに対して複数回トリ

                        AWS でバッチ処理・定期実行する4つの方法
                      • バッチシステムをクラウドネイティブにするために考えたこと

                        Cloud Native Days Tokyo 2022 Session: https://event.cloudnativedays.jp/cndt2022/talks/1518

                          バッチシステムをクラウドネイティブにするために考えたこと
                        • Google Cloud Batch ジョブを VPC を指定して実行してみた。 | DevelopersIO

                          こんにちは、みかみです。 3年ぶりに東京いったら、普通に移動するだけで乗り換えだなんだすごく歩く必要があって、筋肉痛になりました。。(運動不足ここに極まれりw Google Cloud の Batch とは 予め VM インスタンスを準備しなくても、自動でインスタンスを立ち上げてくれて、ワンショットなバッチ処理を実行できるサービスです。 処理内容は、スクリプトを直接指定、またはコンテナイメージで指定することができます。 処理終了次第使用したインスタンスは削除してくれるので、長時間バックグラウンドで動かしたいバッチ処理をコスト効率よく実行することができます。 あらゆる規模でバッチジョブをスケジュールできる新しいマネージド サービス、Batch のご紹介 | Google Cloud ブログ Get started with Batch | Batch ドキュメント Google Cloudの

                            Google Cloud Batch ジョブを VPC を指定して実行してみた。 | DevelopersIO
                          • 次世代のワークフロー管理ツールPrefectでMLワークフローを構築する CyberAgent Developers Blog | サイバーエージェント デベロッパーズブログ

                            ※ DynalystではAWSを全面的に採用しているため、AirflowもManaged版を調査しています。 導入後の状態 Prefect導入後は、以下の構成となりました。 ポイントは以下の点です。 ワークフローをDocker Image化することで、開発・本番環境の差を軽減 staging・productionはECS Taskとしてワークフローを実行、開発ではローカルPC上でコンテナ実行 ML基盤のGitHubレポジトリへのマージで、最新ワークフローが管理画面であるPrefect Cloudへデプロイ 従来のyamlベースのdigdagから、DSに馴染み深いPythonベースのPrefectに移行したことで、コード量が減り開発負荷が軽減しました。 Prefect 入門 ~ 基礎 ~ 注意: 本記事ではPrefect 1系を扱います。Prefect 2系が2022年7月にリリースされてい

                              次世代のワークフロー管理ツールPrefectでMLワークフローを構築する CyberAgent Developers Blog | サイバーエージェント デベロッパーズブログ
                            • 入門Kueue 〜KubernetesのBatchワークロード最前線〜 | gihyo.jp

                              こんにちは、CyberAgentの岩井佑樹(@tenzen-y)です。連載「5分でわかる!Kubernetes/CloudNative」の第3回では、Kubernetes上でのBatchワークロードの扱いに触れた後、Kubernetes NativeなJob Queueing基盤を実現するためのOSSである、Kueueについて紹介します。また本記事で紹介するKueueは、記事執筆時点の最新バージョンであるv0.2.1です。 KubernetesとBatchワークロード Kubernetesではこれまで標準機能として、ロードバランシングやローリングアップデートなどのServiceワークロードのための機能や、Container Storage Interface(CSI)、Container Object Storage Interface(COSI)、Storage Capacity Tra

                                入門Kueue 〜KubernetesのBatchワークロード最前線〜 | gihyo.jp
                              • 66分かかる同期処理を10分以内に短縮せよ!~商品情報同期システムでの、処理速度と運用の改善~ - MonotaRO Tech Blog

                                はじめに この記事では、モノタロウの基幹系を構成するシステムの一つである、商品情報管理システム(PIM:Product Information Management システム)の導入プロジェクトで、商品情報を基幹系と同期するシステム(商品情報同期機能)の性能や運用環境の改善を行った話をご紹介します。 背景 モノタロウの基幹系は、長年内製のシステムで支えられてきました。基幹系のシステムは、少数のWebアプリケーションと多数のバッチから構成されています。中でも商品情報の管理に関するシステムは、在庫や仕入先に関するシステムと一体化していて、商品情報に関する数多くのマスタメンテナンス画面を備えたやや複雑なシステムです(図1)。 図1 基幹系の概略図 当社のシステムは、もともと自分たちのビジネスに必要な機能を提供する手頃なパッケージ製品がなかったため、すべてを内製でまかなってきたという経緯があります

                                  66分かかる同期処理を10分以内に短縮せよ!~商品情報同期システムでの、処理速度と運用の改善~ - MonotaRO Tech Blog
                                • 定時バッチをECS scheduled task + ecscheduleでお手軽管理する - BOOK☆WALKER inside

                                  メディアサービス開発部モバイルアプリケーション開発課のtukiyo(id: tukiyo320)です。現在はニコニコ漫画のバックエンド開発を担当しています。 本記事では、Webサービスに付き物の定時バッチについて、ニコニコ漫画では現在どのような方針で管理・実行しているかをご紹介します。 ニコニコ漫画の構成おさらい 以下の記事に詳しいですが、ニコニコ漫画のバックエンドは4系統存在しています。どれも現在はAWS上に乗っており、PHPの現行システム以外はECS(fargate)で管理されています。 現行PHP(独自フレームワーク) 新バックエンド(Ruby on Rails) React向けBFF(Nest.js) 課金サブシステム(Ruby on Rails) developers.bookwalker.jp 本記事で扱うのは、ロジックの書き直しを目的とした新バックエンドが持つバッチとなります

                                    定時バッチをECS scheduled task + ecscheduleでお手軽管理する - BOOK☆WALKER inside
                                  • GitHub - gazette/core: Build platforms that flexibly mix SQL, batch, and stream processing paradigms

                                    Gazette makes it easy to build platforms that flexibly mix SQL, batch, and millisecond-latency streaming processing paradigms. It enables teams, applications, and analysts to work from a common catalog of data in the way that's most convenient to them. Gazette's core abstraction is a "journal" -- a streaming append log that's represented using regular files in a BLOB store (i.e., S3). The magic of

                                      GitHub - gazette/core: Build platforms that flexibly mix SQL, batch, and stream processing paradigms
                                    • [ JJUG CCC 2022 Spring ] AWS Batch × Spring Batch でクラウド最適なバッチを構築した話 - Qiita

                                      [ JJUG CCC 2022 Spring ] AWS Batch × Spring Batch でクラウド最適なバッチを構築した話JavaAWSspring こんにちは。Red Frasco でインフラエンジニアをやっている猪熊です。 JJUG CCC 2022 Spring にて、 AWS Batch × Spring Batch でクラウド最適なバッチを構築した話 というタイトルで登壇させていただきました。 セッション内容の紹介と登壇のふりかえりをしようと思います。 セッションの紹介 まずは、セッション内容について紹介します。 アーカイブ動画が公開されました。良ければこちらからご覧ください。 https://youtu.be/ArEY_yIt0GI 自己紹介 詳細は割愛します。 香川県出身で、うどんが好きなインフラエンジニアです。 バッチ基盤を構築する背景 物件情報がポータルサイト

                                        [ JJUG CCC 2022 Spring ] AWS Batch × Spring Batch でクラウド最適なバッチを構築した話 - Qiita
                                      • バッチ処理実装時に考慮すべき事項 | メルカリエンジニアリング

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

                                          バッチ処理実装時に考慮すべき事項 | メルカリエンジニアリング
                                        • バッチ処理のリグレッションテスト自動化のトライ | メルカリエンジニアリング

                                          はじめに この記事は、Merpay Tech Openness Month 2022 の7日目の記事です。 こんにちは。メルペイのBackendエンジニアの@kaznishiです。 この記事では、私が所属しているチームで担当している加盟店精算のマイクロサービスにおけるバッチ処理のリグレッションテスト自動化の取り組みを紹介します。 まだBackendエンジニアしかテストシナリオの整備ができるようになっていなかったり、開発フローが整備しきれているわけではないですが、現時点でどのようなテストを回しているか、そして今後どのように改良していきたいかを述べたいと思います。 前提知識 加盟店精算のマイクロサービスの性質として、毎月決まったタイミングでの締め処理があります。この締め処理の中で、メルペイを導入してくださっている加盟店さまの売上を集計し、加盟店さまの銀行口座へ振込する金額の計算を行っています。

                                            バッチ処理のリグレッションテスト自動化のトライ | メルカリエンジニアリング
                                          • Cron→Rundeckに乗り換えた話 - MonotaRO Tech Blog

                                            こんにちは。MonotaROで商品管理や受発注システムの開発を担当している中尾です。 この度、これまでcronで実行していたジョブに対してRundeckを導入し、ジョブのスケジュール管理を効率化することができましたので、導入にあたって苦労した点とその解消方法を中心に紹介いたします。 Rundeck導入の背景 Cronの限界を感じた 過去にも導入しようとしたが・・・ Rundeck導入において苦労した点 Rundeckが落ちた場合の対応の検討 GitでのRundeckジョブのバージョン管理 導入してよかったこと 複数のサーバーに跨ってジョブフローが組めること Cron式が使えること 重複起動制御ができること まとめ Rundeck導入の背景 Cronの限界を感じた MonotaROでは「注文を倉庫に連携する」、「商品の発注を自動で行う」といった様々なバッチ処理が、細かいものも含めると1日数千

                                              Cron→Rundeckに乗り換えた話 - MonotaRO Tech Blog
                                            • オンプレで実行されているバッチ (cron + shell script) をAWS Lambdaに移植する方法 - エムスリーテックブログ

                                              こんにちは、エンジニアリンググループの大和です。 弊社ではエンジニアリンググループ全体で継続して脱オンプレを進めており、これまでに多くのDBやサーバを停止してきました。 www.m3tech.blog また、直近ではコンシューマチームでの取り組みが紹介されています。 www.m3tech.blog 私が所属するマルチデバイスチームでも、前年度までに管理しているサービスのオンプレDBおよびサーバを廃止しました。 コンシューマチームの記事でも説明されていますが、脱オンプレではサーバアプリケーションとDBだけを移行するだけでは足りず既存のバッチや監視周り等含めて移行する必要があります。 この記事では、そのうちcronでshell scriptを実行しているような簡単なバッチをAWS上に移行する方法を紹介します。 構築するシステムの構成 インフラ構築 VPCに紐付けるLambdaの設定 Lambd

                                                オンプレで実行されているバッチ (cron + shell script) をAWS Lambdaに移植する方法 - エムスリーテックブログ
                                              • データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし

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

                                                  データ変更を伴うバッチ処理を書く時に考慮していること - shallowな暮らし
                                                • 定期実行処理を crono_trigger に移行したお話 - Kaizen Platform 開発者ブログ

                                                  こんにちは、エンジニアの ryopeko です。 今回は Data Platform と呼ばれているデータ集計基盤の Rails プロジェクトで定期実行用に使われていた gem、 sidekiq-scheduler を crono_trigger に移行したお話です。 なお Data Platform の記事については以前ブログで紹介したこちらの記事も合わせてご覧ください。 KaizenPlatform では非同期処理には長らく Sidekiq が使われており、Data Platform でも非同期処理が必要な部分で使われております。 Data Platform では集計処理を cron 形式で指定した日時に定期実行するという機能があり、そこでは sidekiq-scheduler が使われていました。 この sidekiq-scheduler は Redis に各種メタデータを入れておき

                                                    定期実行処理を crono_trigger に移行したお話 - Kaizen Platform 開発者ブログ
                                                  • バッチ処理 プラクティス

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

                                                      バッチ処理 プラクティス
                                                    • AWS S3バッチオペレーションのちょっとしたtipsなどのご紹介 - たきざわの日記

                                                      このエントリは、はてなエンジニアAdvent Calendarの9日目の記事としてかかれました。 AWS S3にはバッチオペレーションというマネージドサービスがあって、これは指定したバケット/オブジェクトに対して一括で何かしらの操作ができる。例えば「バケット内のすべてのオブジェクトを別バケットにコピーしたい」とかそういう時に使うと便利。 aws.amazon.com その一括操作ではLambdaを利用することもできる。Lambdaを使うとかなり柔軟な操作ができるようになるが、ドキュメントを見ただけでは最初どうしたらいいかわからなかった上に、利用する機会もそんなに無いので覚えられない。その他にも最初に知ってたらよかったみたいなのが細々とあるので、そういうのを少しまとめておく。 なお、このエントリではS3 バッチオペレーション自体のジョブの登録のやり方自体は割愛する。まずS3バッチオペレーショ

                                                        AWS S3バッチオペレーションのちょっとしたtipsなどのご紹介 - たきざわの日記
                                                      • バッチ処理系の刷新とArgo Workflow移行

                                                        これはPTAアドベントカレンダーの7日目の記事です。 5年間運用されてきたバッチ処理系を刷新し、Argo Workflowを用いたバッチ処理系に移行したのでその紹介記事です。 背景 GKE上でバッチ処理のワークロードを実行しており、ワークフローエンジンとしてDigdagを採用していました。ユースケースとしては定期実行のバッチ処理、ETL、機械学習等。 Digdagを用いたワークフロー定義はシンプルかつ運用に必要な機能を提供してくれています。実際のワークフロー内部の処理としては、ワークフローの各タスクにおいては基本的にはロジックは持たずKubernetes Jobの実行のみを行います。そのためにDigdagとKubernetes Job間で協調動作するための仕組みが独自で用意されていました。このようなバッチ処理系が約5年程運用されてきました。 この仕組で今まで元気に動いてはいたのですが次のよ

                                                          バッチ処理系の刷新とArgo Workflow移行
                                                        • Fargateの運用 ~デプロイ自動化や監視等~

                                                          初めてFargateを触ったので、運用保守の観点で構築時に設定しておいた方が良いポイントをまとめました。 デプロイの自動化と書いているのにデプロイの話薄めになってしまいました…。 こちらはJAWS-UG朝会 #28で発表したものになります。

                                                            Fargateの運用 ~デプロイ自動化や監視等~
                                                          • バッチ処理における冪等性の検討 ─ クラウドネイティブもしくは、はてなダイアリーの自動移行を題材に - Hatena Developer Blog

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

                                                              バッチ処理における冪等性の検討 ─ クラウドネイティブもしくは、はてなダイアリーの自動移行を題材に - Hatena Developer Blog
                                                            • 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 Batch ベストプラクティスまとめ | Amazon Web Services

                                                                Amazon Web Services ブログ AWS Batch ベストプラクティスまとめ この記事はプリンシパル HPC ソリューションアーキテクトの Pierre-Yves Aquilanti、AWS Batch のプリンシパルプロダクトマネージャの Steve Kendrex とプリンシパル HPC アプリケーションエンジニアの Matt Koop によるものです。 更新: 2021 年 10 月 5 日 セクション 2 に於けるサブネット CIDR ブロックのガイドラインを修正。 AWS Batch は、科学者や技術者が複雑なシステム構成を管理する必要なく、自由にスケールできる計算環境を提供するサービスです。2017 年に登場して以来、疫学、ゲームシミュレーション、大規模機械学習といった諸々のワークロードを稼動させる様々な業種や組織といったお客様に採用されてきました。 この投稿で

                                                                  AWS Batch ベストプラクティスまとめ | Amazon Web Services
                                                                • 加盟店リソース作成時の整合性担保の検討と実装 | メルカリエンジニアリング

                                                                  こんにちは。メルペイでバックエンドエンジニアとして従事している a-r-g-v です。私は加盟店さまの初期審査やサポートを行うための社内向け管理画面(以下、社内Tool)や加盟店さま向けの管理画面を開発しているチームに所属しています。この記事はメルペイ加盟店リソースを作成するシステムとそこにある課題、それらに対する改善の取り組みついて紹介させていただきます。 また、本記事は、Merpay Tech Openness Month 2021 の16日目の記事です。 背景 メルペイではマイクロサービスアーキテクチャを採用しています。我々のプロダクトでは、精算サービス、銀行サービス、決済サービスなどの複数マイクロサービスを組み合わせて加盟店さまの体験を作り上げており、メルペイ内でもトップクラスに他のマイクロサービスと接続しています。 メルペイを導入するためにはまず加盟店申込みフォームから申込みをし

                                                                    加盟店リソース作成時の整合性担保の検討と実装 | メルカリエンジニアリング
                                                                  • AI-OCRを支える非同期処理アーキテクチャ - LayerX エンジニアブログ

                                                                    こんにちは!LayerXエンジニアの高際 @shun_tak です! この記事では、LayerX インボイスの請求書AI-OCRを支える非同期処理の仕組みについて解説したいと思います。 いきなりサマリーですが、今回お伝えしたいのは以下の2点です。 請求書は突然大量にアップロードされるので(大歓迎です!)、Amazon SQSとGoの machinery を活用して非同期処理しているよ! AI-OCRの処理は重たいけど、AWS Lambdaを活用してシステム全体の負荷を分散し、スケーラビリティと可用性を確保し、コストも抑えることができたよ! では早速ですが、前回のブログ LayerX インボイスにおける請求書AI-OCRの概要 の復習です。LayerX インボイスの請求書AI-OCRは、以下の図のように複数の処理によって構成されています。 図にするとあっさりしてますが、前処理も後処理も複数の

                                                                      AI-OCRを支える非同期処理アーキテクチャ - LayerX エンジニアブログ
                                                                    • 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 BatchがジョブレベルでEFSボリュームをサポートするようになっていました | DevelopersIO

                                                                        こんにちは。AWS事業本部のKyoです。 AWS BatchがジョブレベルでEFSボリュームをサポートするようになっていました。 BatchでEFSを使うためには一手間が必要だったのでより簡単に使えるようになったというアップデートです。 AWS Batch now supports EFS volumes at the job level これまでとこれから、そして何がうれしいのか これまで EFS自体の利用は可能でした。一方で、マウントには起動テンプレートが必要でバッチインスタンス(EC2)レベルでのマウントが必要でした。具体的な方法は以下にあります。 これから ジョブ定義からEFSを指定することでマウントできるようになりました。マウントのための起動テンプレートは不要になります。 何がうれしいのか Batchのストレージに何を使うかは、扱うデータのサイズや求められる計算スピードなどを踏ま

                                                                          AWS BatchがジョブレベルでEFSボリュームをサポートするようになっていました | DevelopersIO
                                                                        • 形態素解析を行うだけのバッチをつくる - クックパッド開発者ブログ

                                                                          研究開発部の原島です。今日は表題の渋いバッチをつくった話をします。 あっちでも形態素解析、こっちでも形態素解析 みなさん、形態素解析してますか?してますよね?クックパッドでもさまざまなプロジェクトで形態素解析をしています。 いや、むしろ、しすぎです。プロジェクト A でレシピを解析し、プロジェクト B でもレシピを解析し、プロジェクト C でもレシピを解析し、... といった具合です。ちなみに、形態素解析(の結果)が必要なプロジェクトとしてはレシピの分類やレコメンド、各種分散表現(e.g., word2vec)や BERT の学習などがあります。 もちろん、最終的に得たい解析結果が違うのであれば問題ありません。しかし、私が見たかぎり、ほとんどの場合は同じ(もしくは、同じにできそう)でした。であれば、 解析器をインストール(→ Dockerfile を試行錯誤) 解析対象を取得(→ SQL

                                                                            形態素解析を行うだけのバッチをつくる - クックパッド開発者ブログ
                                                                          • 転職会議から冪等でないバッチ処理を根絶した話 - LIVESENSE ENGINEER BLOG

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

                                                                              転職会議から冪等でないバッチ処理を根絶した話 - LIVESENSE ENGINEER BLOG
                                                                            • AWSがAWS Fargateのバッチサポートを導入

                                                                              Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                                                                                AWSがAWS Fargateのバッチサポートを導入
                                                                              • Cloud Composerによるデータバリデーション ~常に正確なデータ集計を実現するために~ - ZOZO TECH BLOG

                                                                                こんにちは。ECプラットフォーム部データエンジニアの遠藤です。現在、私は推薦基盤チームに所属して、データ集計基盤の運用やDMP・広告まわりのデータエンジニアリングなどに従事しています。 以前、私たちのチームではクエリ管理にLookerを導入することで、データガバナンスを効かせたデータ集計基盤を実現しました。詳細は、以前紹介したデータ集計基盤については以下の過去記事をご覧ください。 techblog.zozo.com 本記事では、データ集計基盤に「データバリデーション」の機能を加えて常に正確なデータ集計を行えるように改良する手段をお伝えします。 データバリデーションとは バリデーション導入後のデータ集計基盤 ジョブネット構築 テンプレートによる効率的なDAGの作成 DAG間の依存関係の設定方法 バリデーションDAGのタスク構成 まとめ データバリデーションとは データバリデーションとはデータ

                                                                                  Cloud Composerによるデータバリデーション ~常に正確なデータ集計を実現するために~ - ZOZO TECH BLOG
                                                                                • LINEの新しいセルフサービス型バッチデータ収集システム「Frey」の導入

                                                                                  こんにちは、Data Platform室Data Engineering 1チームの徐です。 Data Platform室では、大規模なHadoopクラスタを運用し、データ収集、分析、活用するためのプラットフォームを提供しています。Data Engineering 1チームのミッションの一つは、様々なストレージからのdata ingestionシステムを構築、運用することです。 本記事では、バッチ処理でデータ収集を行うシステムの概要を説明した後に、LINEのセルフサービスツールであるFreyをご紹介します。 課題: このシステムでもデータ収集のバッチ処理を実行・管理するという目的は果たせましたし、ユーザーとタスクの規模が小〜中程度であれば問題はありませんでした。しかし、LINEの全てのプロダクトまでスコープを広げるにつれ、次のような問題に躓くことが増えていきました。 コード記述(ステップ1

                                                                                    LINEの新しいセルフサービス型バッチデータ収集システム「Frey」の導入