タグ

batchに関するlilpacyのブックマーク (22)

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

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

    入社4ヶ月目で73時間かかるバッチ処理を7倍以上高速化した話 - エムスリーテックブログ
  • AI-OCRを支える非同期処理アーキテクチャ - LayerX エンジニアブログ

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

    AI-OCRを支える非同期処理アーキテクチャ - LayerX エンジニアブログ
  • Scala + Akka Streamで既存のバッチを10倍以上速くした話 - Qiita

    完了まで約2時間半かかっていた既存のバッチ処理を、最近興味があったReactiveでリプレイスして10分以内に完了するようにした時の躓きポイントのまとめ Scala/Akka Streamをチョイスした理由は、下記のスライドに触発されたのと、Spark on EMRを触っていてScalaに躓いていたのでScalaともう少し友達になりたかったからです。 バッチを Akka Streams で再実装したら100倍速くなった話 #ScalaMatsuri from Kazuki Negoro システム概要 処理概要 MariaDBから処理対象のデータIDを取得 idから必要となるデータを取得して、JSONを生成 ElasticSearchのBulk APIでデータ投入 ElasticSearchのAlias切り替え 1〜3を繰り返す サーバ EC2(vCPU 4コア) 既存システム概要 PHP

    Scala + Akka Streamで既存のバッチを10倍以上速くした話 - Qiita
  • Akka StreamsでMySQLからデータを取得してCSVに書き出す | DevelopersIO

    こんにちは。山崎です。 MySQLのデータをCSVに書き出すバッチ処理をAkka Streamsで実装する方法を紹介します。 Akka Streamsとは ノンブロッキングなバックプレッシャ付きの非同期ストリーム処理の標準を定めるReactive StreamsのAkkaを使った実装です。 Akka Streamsに関しましては、こちらの記事に詳しくまとまっていますのでご覧ください。 実際にコードを書いてみる 今回は「商品の情報をDBから取得しCSVファイルに書き出す」という例で実装していきます。 処理は3つの部品から構成されます DBから商品の情報を取得するSource 流れてきた商品情報をCSVの1行分に変換するFlow ファイルに流し込むSink これらの部品を実装してつなげることで処理を実装します。 実際にコードを見ていきましょう。 依存関係 今回使用するライブラリをbuild.s

    Akka StreamsでMySQLからデータを取得してCSVに書き出す | DevelopersIO
  • Cloud Composerによるデータバリデーション ~常に正確なデータ集計を実現するために~ - ZOZO TECH BLOG

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

    Cloud Composerによるデータバリデーション ~常に正確なデータ集計を実現するために~ - ZOZO TECH BLOG
  • IoT時代におけるストリームデータ処理と急成長の Apache Flink

    Takanori SuzukiSenior Technical Consultant at Acroquest Technology Co., Ltd.

    IoT時代におけるストリームデータ処理と急成長の Apache Flink
  • 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

    自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

    1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
  • マイクロバッチの人気記事 0件 - はてなブックマーク

    キーボードショートカット一覧 j次のブックマーク k前のブックマーク lあとで読む eコメント一覧を開く oページを開く ✕

  • バッチ ジョブの人気記事 2件 - はてなブックマーク

    CTOの椎名です。最近弊社では家族アプリFammの印刷・配送・通知など様々な処理を使うために AWS LambdaAWS Batch を使う量が増えてきて、ECS Fargate も徐々に導入をはじめてきました。 Lambda も Batch も ECS Task も、何かのジョブを単発/定期でサーバー無しで実行するための手段として似ているところがあります。何かのバッチ/ジョブを作る時に「これはLambdaで作るべきか?Batchで作るべきか?」などで迷う事もあります。もちろん製品名の通り「バッチならAWS Batch」と言う考え方もありますが、AWS Batchではオーバーキルな時もあれば、かゆいところに手が届かない時もあります。 今回はこれらの特徴やメリット/デメリットの比較をまとめます。 AWS Lambda 簡単に言うと「コードだけアップロードして実行トリガーを決めればその通

  • 食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita

    こんにちは、べログシステム部長の京和です。 今年の4月から部長になりました。さらに4月に娘が生まれました エントリではべログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる

    食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
    lilpacy
    lilpacy 2021/01/07
    “イクロサービス化の適切なタイミングやアーキテクチャを設計するには、事業構造や組織構造、そして中長期で事業が目指すべき方向性の理解が不可欠(つまり、逆コンウェイの法則ですね)”
  • Jenkins でバッチを運用する - Qiita

    はじめに 私達は php で書かれたバッチ、500 個ほどを Jenkins で運用しています。 Jenkins でバッチを運用するようになった理由と移行したときに行った設定等をここにまとめます。 発生していた問題 私達はバッチ実行用のサーバー上の cron にすべてバッチを登録することで定期実行させていました。 当時のバッチの数はだいたい 100 個ほどだったと思います。(現在は 500 個ほど) 長い間 cron で管理されいましたが、問題を多数抱えていたので Jenkins でを抱えていたため移行しました。 バッチが正しく動作したのかわからない ログを見るための仕組みがなかったので、バッチのほぼすべてログを書き出さないものとなっていて正しく動作しているのか分かりにくい ログを書き出す仕組みがあってもそれを管理するのは大変 権限周りの管理の問題 管理の都合からルート権限持つ人が cro

    Jenkins でバッチを運用する - Qiita
  • バッチ処理について考える - Qiita

    TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万~数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ?ネットににも答え載ってないよ?低レイヤも意識しないと動かないよ? 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや

    バッチ処理について考える - Qiita
  • レガシーとの向き合い方 〜cron から Rundeck へ〜 - DMM inside

    |DMM inside

    レガシーとの向き合い方 〜cron から Rundeck へ〜 - DMM inside
    lilpacy
    lilpacy 2021/01/07
    "タイムスケジュールによる管理のため、直前のバッチの結果はお構いなしで実行。ひどい日はエラーまみれ。タイムスケジュールで管理していた前後関係のあるバッチをRundeckのJob Workflowsでまとめた"
  • Amazon LinuxのEOLに伴いバッチをサーバレス化しFargateに移行した話 - クラウドワークス エンジニアブログ

    はじめまして、2020年3月に中途入社したSREチームの @bayashiok です。 今回は入社後、Fargateでサーバレスバッチ基盤を構築した話を書いていきます。 目次 目次 経緯 Fargateを選んだ理由 1. リソースの見積もりがCPU/Memoryだけですむ 2.スケーリングを考えなくて良くなる 3. セキュリティレベルの向上につながり管理負荷が減る 現行システムで発生している問題点の解消 構成 FargateのトリガーとしてRundeckを採用 理由1: バッチ実行が行われる場所でログを見たかった 理由2: ジョブ失敗やSlack通知の仕組み、リトライ方法やジョブ連携などの作り込みを簡単にしたかった ecs-taskとの連携について デプロイ 1. wrapperコンテナのデプロイ 2. バッチのデプロイ Fargateタスク実行について 移行後の総括 よかった点 悪かった

    Amazon LinuxのEOLに伴いバッチをサーバレス化しFargateに移行した話 - クラウドワークス エンジニアブログ
    lilpacy
    lilpacy 2021/01/07
    "Fargateを利用すればこういった事を考慮せずに、1. で述べたようにバッチ毎にリソースのスケーリング管理が可能になります。"
  • AWS Batch, Lambda, ECS Task 比較:バッチやジョブにはどれを使う? - Tech Blog

    CTOの椎名です。最近弊社では家族アプリFammの印刷・配送・通知など様々な処理を使うために AWS LambdaAWS Batch を使う量が増えてきて、ECS Fargate も徐々に導入をはじめてきました。 Lambda も Batch も ECS Task も、何かのジョブを単発/定期でサーバー無しで実行するための手段として似ているところがあります。何かのバッチ/ジョブを作る時に「これはLambdaで作るべきか?Batchで作るべきか?」などで迷う事もあります。もちろん製品名の通り「バッチならAWS Batch」と言う考え方もありますが、AWS Batchではオーバーキルな時もあれば、かゆいところに手が届かない時もあります。 今回はこれらの特徴やメリット/デメリットの比較をまとめます。 AWS Lambda 簡単に言うと「コードだけアップロードして実行トリガーを決めればその通

    AWS Batch, Lambda, ECS Task 比較:バッチやジョブにはどれを使う? - Tech Blog
  • GitHub Actionsを使って、個人タスク用のissueを毎日作成する - よしたく blog

    GitHub の issue で個人的なタスクを管理する方法を知った。 プログラマではないので普段から GitHub を使うことはないのだけれども、タスクの管理場所に迷っていたのでひとまず手を出してみようと思う。 毎日issueを作成するのも大変で、少しでもハードルを下げることを意識してGitHub Actionsで毎日自動的に作成するようにしてみた。 今回はその実現方法を記しておく。 issueのテンプレートを作成する まずはissueを作成するためのテンプレートを作成する。 これから始めるのでまずはシンプルなものを作成し、今後必要があればカスタマイズする方向で進める。 今回はworkリポジトリを作成し、配下に.github/ISSUE_TEMPLATE/todolist.mdを作成した。 --- name: TODO リスト about: 今日終わらせることの終了済み状態を書こう ti

    GitHub Actionsを使って、個人タスク用のissueを毎日作成する - よしたく blog
  • ECS Fargate 楽々構築テンプレート|Dentsu Digital Tech Blog

    この記事は電通デジタルアドベントカレンダー2020の22日目の記事になります。前回の記事は「ADH APIを効率的に呼び出すために開発したHooksの紹介」でした。 改めましてこんにちは! Docker使ってますか? AWSDockerを使おうと思うと以下の3つの選択肢があります。 ・Elastic Container Service ・Elastic Kubernetes Service ・EC2に構築する この中でもECSいいですよね、僕も好きです。運用に手間もかからなくて気軽に使えるところに好感もてます。さすがAWSのマネージドサービス。 ただし実際にECSで構築しようとすると周辺のリソースが色々と必要になるので初心者にとってハードルが高く見えるのも事実です。そんなわけで初心者にも使えるようなテンプレートを提供したいと思います。 このテンプレートでは最低限の機能しか提供しません。何

    ECS Fargate 楽々構築テンプレート|Dentsu Digital Tech Blog
  • バッチ サーバーレスの人気記事 8件 - はてなブックマーク

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

  • ECSのScheduled Taskを管理するツールを作った | おそらくはそれさえも平凡な日々

    その名もecschedule。だいぶ前から作っていたのだが、この度実戦投入した。 https://github.com/Songmu/ecschedule Nature社では、ECS上でGoのサービスを動かしており、バッチ系の定期実行タスクもECS Scheduled Taskを利用している。 最近バッチの数が増えてきて管理したくなり、このツールを導入しました。 便利だとは思うが、かなり社内事情にべったりであるため、フィードバック歓迎です。具体的には以下の制約を前提としています。 Rule名がユニークであること RuleにはTargetが1つだけ紐付いており、TaskのContainer Overridesでタスクを実行している ecspressoにかなり影響を受けており、ECS Scheduled Task用のecspressoのような作りになっています。 インストール % brew

    ECSのScheduled Taskを管理するツールを作った | おそらくはそれさえも平凡な日々
  • ecs Scheduled Taskの人気記事 8件 - はてなブックマーク

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