タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万~数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ?ネットに本にも答え載ってないよ?低レイヤも意識しないと動かないよ? 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本
4つのバッチ処理・定期実行方式の詳細情報それぞれのバッチ処理・定期実行方式について詳細を見ていきます。 EC2について使用するAWSサービスEC2 処理概要Linux系OSで用いられる定時実行機能であるcronのコマンドを使用する メリット昔からよく使われているcronの知識が使える デメリットEC2インスタンスを起動しておく必要があり、使っていない時間もコストがかかる 障害に弱い。EC2サーバに障害があると終わる サーバが複数になると管理が大変 SQS×ECS使用するAWSサービスEventBridge SQS ECS 処理概要EventBridgeでキューを生成。ECSコンテナでキューを取得して実行する メリットECSを起動しておくため、コンテナの起動時間を要さない。 デメリットEventBridgeでキューを生成するが、EventBridgeはまれに1 つのイベントに対して複数回トリ
Amazon Web Services ブログ AWSサーバーレスバッチ処理アーキテクチャの構築 この投稿は、AWSソリューションアーキテクトであるReagan RosarioとWWPSソリューションアーキテクトであるMark Curtisによって書かれました。バッチ処理は多くの組織にとって基礎となるもので、大量の情報を効率的に自動化した形で処理することができます。ユースケースとしては、ファイル取り込み処理、キューベースの処理、トランザクションジョブ、さらに重いデータ処理のジョブなど、多岐にわたります。 この記事では、ファイル取り込み処理を実装するためのバッチ処理を、サーバーレスに実現するための方法を説明していきます。今回の例では、オーケストレーションにAWS Step Functions、オンデマンドのコンピューティングにAWS Lambda、データストアにAmazon S3、メールの送
ここから、表で挙げた内容をそれぞれ解説していきます。 構築難度に関しては、関数を実装するだけで済むLambdaが最も簡単で、バッチ専用に特化されたサービスであるBatchに関しては比較的バッチ構築はしやすい印象ですが、ECSに関してはバッチに特化していないため、バッチ処理を行うようにカスタマイズする必要があります。 タイムアウト制約に関して留意すべきは、Lambdaの実行時間は15分までなので、それ以上を超える処理時間のバッチは実装できないことです。 起動•実行上のオーバーヘッドに関しては、Lambdaにはコールドスタートがあるため起動時にオーバーヘッドを考える必要があり、Batchではジョブをキューに送信して、最適化のために、ある程度のジョブがキューイングしてから実行しようするので、即時性を求める処理には不向きです。 既存バッチを移行したいケースがあると思いますが、Lambdaで動かせる
この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、8パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng
アプリケーションエンジニアのid:tkzwtksです。今回はバッチ処理の冪等性(べきとうせい、idempotence)について、どう考えるか/考えてきたかをご紹介します。 このエントリを書くきっかけとなったのは、はてなエンジニア有志で定期的に開催しているCloudNative推進会です。ここでは、社内のシステムをクラウドネイティブにしていくため「クラウドネイティブなシステムとはどういうものか?」を考えており、この会での「クラウドネイティブなバッチ処理」の議論も踏まえつつ説明していきます。 バッチ処理における冪等性とは メッセージ送信の信頼性を考慮する クラウドネイティブで可用性を高めるために どのような場合に冪等性を考慮すべきか 冪等な実装における3つのケーススタディ ケース1: n分前までに更新されたレコードを集計する ケース2: DB上の対象レコードを更新する ケース3: 対象ユーザー
画像圧縮ツール「Optimage for Mac」がv3.0へメジャーアップデートしています。詳細は以下から。 ロシアのVlad Danilovさんは現地時間2019年06月26日、2016年から開発を続けている画像圧縮ツール「Optimage for Mac」をv3.0.0へメジャーアップデートし、JPEGやPNG, GIF, WebPの圧縮率を向上させたほか、新たにAPNGやHEVC, MP4, WebMの圧縮に対応したと発表しています。 What’s new in Optimage 3 More compression : Significantly improved JPEG, PNG, GIF and WebP compression, added APNG, HEVC, MP4 and WebM compression. Resize and convert : Added h
こんにちは。エンジニアリンググループの武井です。 私は現在、デジカルチームに所属し、クラウド電子カルテ、エムスリーデジカルの開発に携わっています。 昨年夏にエムスリーに入社し、早くも半年が経過しました。 digikar.co.jp この記事では、私が入社してから4ヶ月目に取り組んだ、バッチ処理の運用改善について振り返ります。 特に、新しくチームに加わったメンバーとして意識した点に焦点を当ててみたいと思います。 これから新しいチームに参加する方の参考になれば幸いです。 改善したバッチ 現状の正確な理解 現状に馴染む技術選定 自分なりの+αを加える 改善の結果 We're hiring 改善したバッチ 今回の改善対象は、特定の医療機関に紐づく全患者の全カルテをPDFファイルとして出力する、というバッチです。 デジカルのデータを医療機関側にエクスポートする用途で使われています。 移行前のアーキテ
こんにちは、EC基盤グループ 商品情報基盤チームの江村です。今回は私が所属している商品情報基盤チームで構築、運用を行っているシステムについてお話します。 モノタロウでは以前から記事になっていますが、検索システムの移行を行っており、現在商品検索ページの裏側の検索システムのSolrからElasticsearchへの切り替え*1が完了しました。 私が所属している商品情報基盤チームではElasticsearch、Spannerに入れるための商品情報の作成とSpannerおよび、Spannerからデータを取得するAPIの運用を行っています。今回はその中でもElasticsearch、SpannerのためのBigQueryでの商品情報作成処理について取り上げます。(詳しい検索部分の構成については以前の記事を参照ください) システム移行の背景 移行による設計ポイント 「MySQL + Python」の処
Amazon Web Services ブログ AWS Lambda でのカスタムチェックポイントによるバッチ処理の最適化 AWS Lambdaは、Amazon Kinesis Data StreamsやAmazon DynamoDB Streamsなどのソースから取得した複数メッセージをバッチ処理できます。通常の操作では、処理を行う関数は1つのバッチから次のバッチに移動して、ストリームからのメッセージを消費します。 ただし、バッチ内のアイテムの1つでエラーが発生すると、そのバッチ内の同じメッセージ群の一部が再処理される可能性があります。新しいカスタムチェックポイント機能により、失敗したメッセージを含むバッチの処理方法をより詳細に制御できるようになりました。 このブログ記事では、バッチ失敗時のデフォルトの動作と、このエラー状態に対処するために開発者が使用可能なオプションについて説明します。
結論から言えばそれは正しくない。より正確には期待通り動かないケースがあるため、「関数型の更新」を使う必要がある。なぜ必要なのかを以降説明していく。 要点 最初に本記事の要点を記載する。 (これだけで理解できてしまう方は、恐らく以降を読む必要は無いだろう。) React は state の更新をバッチ処理する。つまり複数の state 更新リクエストを一括で処理する 通常このバッチ処理の中間の state を参照することは出来ない。「新しい state を前の state に基づいて計算する」場合はこの点が問題になる。 「関数型の state 更新」を使うと、次の state を計算する際に、バッチ処理の中間の state も参照できる。「前の state」を利用したい場合には「関数型の state 更新」を使う方が安全。 state更新のバッチ処理 React では state の更新が行
追記 (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 以
[Step Functions]動的並列処理(Map)を使って60分×24時間=1440ファイルのバッチ処理を楽々実装してみた こんにちは、平野です。 下記のブログで紹介されているように、 Step Functionsにて、配列の入力を個別のLambda等にバラまいて処理させるMapステートがサポートされました!! [アップデート]Step Functionsで動的並列処理がサポートされました! 担当していた案件で、S3上にある直近24時間分ファイル群(各ファイル名に秒までの時刻が入っている)を、 1分毎にまとめて別のバケットに移すような処理があり、 これはまさにMapステートに最適な素材でしたので、Mapステートを使ったリファクタリングをしてみました! この記事では、ServerlessFrameworkのStep Functionsプラグインを用いています。 (対応早くて助かる!!)
本日のアップデートで 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 ホストの存在は少なからずとも意識する必要がありました。加えてゼロキャパシティからスケールする際は、キューイングしてから
2019年7月29日、Opt Technologiesが主催するイベント「Fun Fun Functional (2) 関数型言語Lightning Talks!!」が開催されました。関数型プログラミングについて楽しく学び、知見を共有することを目的に開催されている本勉強会。今回は6名のエンジニアが、関数型プログラミング言語にまつわるユニークな発表を行いました。プレゼンテーション「Scala ZIOをバッチ処理で使ってみた」に登壇したのは、リチャード伊真岡氏。講演資料はこちら 副作用を含むコードで関数型のテクニックを利用 リチャード伊真岡氏:「Scala ZIOをバッチ処理で使ってみた」という発表をします。リチャード伊真岡と申します。マーベリック株式会社というところで働いています。 今日一番大事なことを最初に言おうと思います。発表の内容はどうでもいいので、私の名前だけ覚えていってもらえば満足
こんにちは、Development部門に所属しているSREの佐藤と申します。 Development部門では複数プロダクト共通の基盤構築や、新技術の検証、インフラ整備などを幅広く担当しています。これまでストックマークではCI/CD基盤の構築やAWS上で構築するインフラのコード化、ニュース収集基盤のアーキテクチャの改善や運用負荷軽減から、製品利用状況のデータ分析基盤構築などに取り組んできました。 今日はAstrategyという製品でのMLOpsの取り組みについて話します。 AstrategyについてAstrategyは国内外Webメディアを対象として情報を収集・構造化し、調査・報告業務を包括的にサポートする検索プラットフォームです。 図1: 「言葉のAI」自然言語解析を用いたオープンデータ解析ツール 複数の分析画面を提供しており、目的に応じて異なる観点で市場変化や競合動向を可視化できます。
それぞれ微妙にできることや制限に違いがあり、ここを捉えた上で選択する必要があります。 Batchの強みはおそらくタイムアウトがないことによって長時間実行ができ、かつシンプルに実装できることだと思います。 (タイムアウト最大値に関して、Batchにおいては存在しないと公式動画の方で説明していますが、Cloud Composerについては不明でした。) Batch単体でもジョブ定義ファイル内で各タスクの依存関係(順次実行、並列実行)はできますが、Cloud ComposerやWorkflowsのように複雑なジョブネットを書くことは難しそうです。 ジョブネットのように動かしたい場合には公式ドキュメントにもあるようにWorkflowsなどからBatchジョブを実行するのが良さそうです。 動かしてみよう 実際にジョブを作って動かすまで試してみたいと思います。 GCP公式がBatchのサンプルコードを
本記事は、2020年インターンシップで勤務した高橋芽生さんによる寄稿です。 はじめに 2020年度PFN夏季インターン生の高橋芽生です。 今回のインターンではメタヒューリスティクスライブラリの開発を行いました。 コードはこちらで公開しています。 メタヒューリスティクス メタヒューリスティクスという用語には様々な意味がありますが、本稿では個々の問題に依存しない連続的な最適化のための一般的なフレームワークを指すものとします。これは関数の形が陽に与えられていない場合の最適化手法であるブラックボックス最適化の一つです。ブラックボックス最適化には、機械学習のハイパーパラメータチューニングや、音声認識システム [1]、結晶構造の解析 [2]、ソーシャルゲームの難易度・バランス調整 [3]などの応用先が知られています。多くのメタヒューリスティクスの手法では、同じバッチのスコアは互いに影響しないため、複数
ITシステムに関わるエンジニアなら、「バッチ処理」という言葉を聞いたことがある人がほとんどだろう。しかし、バッチ処理とは何かを正確に理解している人は意外に少ない。 数カ月前、ある週刊誌がみずほ銀行のシステムトラブルの原因を論じたWeb記事で、バッチ処理を「とっくの昔に時代遅れになった手法」と書き、ネットで論争になった。確かにバッチ処理は使われ始めてから長い年数がたつが、現在のシステムでも広く使われている。現場のエンジニアからは「時代遅れという表現には違和感がある」との意見が相次いだ。 先の記事には「みずほは何らかの理由で(バッチ処理に)こだわっていた」とあった。しかし、みずほだけが特にバッチにこだわっているわけではない。ITベンダー各社は「バッチ処理がないシステムは見たことがない」と異口同音に話す。それくらい現役バリバリでメジャーな手法だ。 データをためて後で一括処理 そもそもバッチ処理と
はじめに こんにちは、Media Do Tech Do Blog初執筆のogadyです。 メディアドゥには2019年の8月に入社して、この度ついにブログ執筆させていただくことになりました! 本記事では、私のチームで運用しているバッチツールをgoroutineで高速化した話をさせていただきます。 背景 現在メディアドゥでは、二つの電子書籍取次システムを片寄せし、統合する案件を進めています。 私のチームは、システムのDBマイグレーションを行う移行・突合システムをgoで開発・運用しています。 移行・突合システムでは、移行元の取次システムのデータを移行・突合システムにインポートして、ごちゃごちゃ加工してマイグレーションしています。 移行・突合システムイメージ図 この「取次システムのデータを移行システムにインポートして」という部分が曲者で、最新状態を保つため定期的・突発的に移行システムのDBを総入替
サーバーのバッチ処理が時間内に終わらないとの相談が顧客から寄せられた。ログを調べると、バッチ処理に使用するマスターデータの生成に時間がかかっていた。このためデータを生成するデータベースサーバーを調べたが異常は見つからなかった。それもそのはず、原因はネットワーク上に存在する1台のルーターだったのだ。 不具合が報告されているハードやソフトを利用するシステムでトラブルが発生したら、その不具合が原因に違いないと考えるだろう。実際、不具合が原因であることが多い。だが一方で、不具合とは無関係の箇所に原因が潜んでいる場合もある。この場合、トラブル解決は往々にして難航する。 顧客企業のシステム運用を請け負うチームのリーダーだったラックの七沢樹さんが直面したトラブルがまさにこのケースだった。七沢さんはどのようにして原因を突き止めたのだろうか。 時間内に終わらず子会社の業務に支障 七沢さんたちのチームが運用を
WebPやHEICを含む画像ファイルの変換や圧縮、リサイズのバッチ処理が可能なMac用イメージコンバーター「Image Tool+」がリリースされています。詳細は以下から。 Appleは2020年秋にリリースするSafari v14やmacOS 11 Big Sur、iOS 14でGoogleが開発した画像フォーマット「WebP」をネイティブサポートしますが、そのWebPを含む画像ファイルの変換や圧縮、リサイズのバッチ処理を行ってくれるMac用イメージコンバーター「Image Tool+」がリリースされています。 Convert, Resize, Optimize and Compress various type of images.Preview result images with compare slider. Image Tool+ – Mac App Store Image T
「8割9割ではなく、100%自動化することを重視した」。ソニー生命保険の後藤聖央執行役員兼ITデジタル戦略本部長はこう語る。 ソニー生命は、2020年6月からメインフレームにおけるバッチ処理やアプリケーションリリースに関する作業依頼の自動化を進めている。「100%自動化」を重視するのは、自動化の例外を残せば、作業依頼にかかる人員を完全になくすことはできないためだ。 同社は2023年4月に自動化システムの本格利用を開始した。オペレーターが依頼書などで受け付けていた1カ月に1000件以上の作業依頼を自動化し、処理実行までの時間を短縮した。依頼書のチェックにかかっていた人手も削減した。 ソニー生命では基幹系がメインフレーム上で稼働している。メインフレームは米IBM製だ。その中で「バッチ処理を大量に抱えている」(後藤執行役員)。例えば、顧客の口座から保険料を引き落とすため銀行に対してデータを定期的
はじめに メルペイバックエンドエンジニアの @r_yamaoka です。この記事は、Merpay Tech Openness Month 2022 の16日目の記事です。 私がつい最近まで所属していた加盟店管理業務を担うマイクロサービス群(以下、加盟店管理システム)では様々なバッチが稼働しています。本記事ではそれらの実装において過去に発生したトラブルやヒヤリハットから得た知見を共有したいと思います。 背景 本題に入る前に加盟店管理システムでどのような箇所にバッチ処理が採用されているかについて少し解説します。バッチ処理を採用するか否かの観点としては大きく下記2点があります。 機能要件上バッチ処理を採用しなければならない 非機能要件の都合で同期処理を採用できない 前者の例としては「配送業者との伝票情報連携」や「行政システムとの連携処理」というものがあり、これは連携先である配送業者や行政の業務の
このシリーズの 第2回 では、クライアントからバックエンドのサービスを利用する際に、なんらかの原因でエラーが発生した場合にクライアント側でリトライ処理が実行されると、リクエストが重複して送られる可能性があることを説明しました。クライアントからキューに対してメッセージを送信するようなサーバーレスのシステムにおいては、リトライ処理によって重複したメッセージが送信されてもメッセージの重複を排除する機能を利用することによってべき等性を実現する方法について解説を行いました。その中では、重複したメッセージをただ一度だけ処理する (Exactly Once) ことで、結果としてべき等性を実現するという具体的な実装方法と共に紹介しました。 第 3 回 では、キューからメッセージを取り出し、バックエンドのデータソースへ保存する処理においても、何らかのエラーによってリトライ処理が発生した場合に重複してデータの
「golang.tokyo」は、プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。ここで、フューチャー株式会社の真野氏が登壇。ここからは、Goの導入で工夫していることを紹介します。 WebAPIからバッチ処理までの工夫 真野隼記氏:ここから話は変わって、実際に使っている、導入の部分で工夫しているところをいくつか紹介したいと思います。(スライドを示して)Goの導入ですが、Goのバックエンド中心で強いのはだいたいそのとおりで、WebのAPIサーバやバッチ処理、BOTのアプリやCLIツールなどをいくつか導入しています。 細かな工夫について、WebのAPIやバッチで特に生産性に加味しそうなところを話していきたいと思います。 (スライドを示して)まずWebのAPIですが、特に技術選定のリーダーポジションでよく思うことです。デファクトスタンダードなWebのフレ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く