dummy GA 新しいURLに転送しています… https://stockmark-tech.hatenablog.com/entry/2023/12/05/130000...
みずほ銀行が鬼門のバッチ処理でつまずいた。3月11~12日に起きた外貨送金のトラブルは、ディスク装置の故障が発端だった。バックアップ装置への切り替えに失敗し、データの不整合も重なって夜間のバッチ処理が朝までに終わらなかった。みずほ銀行のシステム障害はこの2週間で4度目となる。しかも夜間バッチ処理の失敗は、2002年4月と11年3月に起こした2度の大規模障害でもあった。これを防ぐために勘定系システムを作り直した経緯があり、今回の障害は重い意味を持つ。【関連記事】・・・異例の2度目の謝罪会見「断腸の思いだ」。12日夜、東京・千代田のみずほ銀行本店で開いた緊急記者会見で、藤原弘治頭取はこう絞り出した。藤原頭取は2週間ほど前の1日、まったく同じ場所で記者会見をしたばかり。システム障害を理由に、これほどの短期間でメガバンク首脳が2度も謝罪会見の場に立つのは異例
システムプラットフォームチームで SRE をしている id:chaya2z です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の6月号です。先月は id:MysticDoll さんの Postfixのログ監視で注意すべきSMTPのステータス仕様について でした。 ECS で実行するバッチ処理を、インスタンス数を最適化する仕組みである ECS Cluster Auto Scaling を使ってコスト最適化した取り組みを紹介します。 ECS の起動タイプに EC2 を使う背景 はてなでは、ECS の起動タイプとして Fargate ではなく EC2 を使用しているサービスがあります。そのサービス例として、バッチ処理があります。バッチ処理のジョブには数秒・数分で終わるものもあれば、数時間かかるものがあります。 EC2 起動タイプを選ぶ理由は、タスク終了までのタイムアウト待
これはPTAアドベントカレンダーの7日目の記事です。 5年間運用されてきたバッチ処理系を刷新し、Argo Workflowを用いたバッチ処理系に移行したのでその紹介記事です。 背景 GKE上でバッチ処理のワークロードを実行しており、ワークフローエンジンとしてDigdagを採用していました。ユースケースとしては定期実行のバッチ処理、ETL、機械学習等。 Digdagを用いたワークフロー定義はシンプルかつ運用に必要な機能を提供してくれています。実際のワークフロー内部の処理としては、ワークフローの各タスクにおいては基本的にはロジックは持たずKubernetes Jobの実行のみを行います。そのためにDigdagとKubernetes Job間で協調動作するための仕組みが独自で用意されていました。このようなバッチ処理系が約5年程運用されてきました。 この仕組で今まで元気に動いてはいたのですが次のよ
こんにちは。Nulab Appsチームの小松です。 本ブログでは、バッチ処理の実装を通じて得た知見について共有したいと思います。 TL;DR Spring BootとSpring Batchを使用したバッチ処理の実装 AWSのマネージドサービスを使用したデータ運搬 要件 実現したいことは、Webアプリケーションで管理しているデータをSalesforceへ同期することです。 Salesforceへの同期のタイミングは、アプリケーションでのデータ変更に連動して行われることが望まれており、ある程度のリアルタイム性が求められていました。 Salesforce上のモジュール間には関連を定義することができ、今回は、その関連を多用する仕様となっていました。そのため、同期処理時に更新したSalesforceのオブジェクトのID管理やその紐付けなど、独自のロジックの実装が必要でした。 多くのデータを1日何度
はじめに この記事は、Merpay Tech Openness Month 2022 の7日目の記事です。 こんにちは。メルペイのBackendエンジニアの@kaznishiです。 この記事では、私が所属しているチームで担当している加盟店精算のマイクロサービスにおけるバッチ処理のリグレッションテスト自動化の取り組みを紹介します。 まだBackendエンジニアしかテストシナリオの整備ができるようになっていなかったり、開発フローが整備しきれているわけではないですが、現時点でどのようなテストを回しているか、そして今後どのように改良していきたいかを述べたいと思います。 前提知識 加盟店精算のマイクロサービスの性質として、毎月決まったタイミングでの締め処理があります。この締め処理の中で、メルペイを導入してくださっている加盟店さまの売上を集計し、加盟店さまの銀行口座へ振込する金額の計算を行っています。
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が失敗したら、リト
2020/4/5更新 コマンドをコピペすると"--"(連続ハイフン)がWordpressの仕様によりダッシュに変換され、バッチが正常に動作しない問題を修正しました。 AviUtlの拡張プラグインでNVEncの設定画面を開くと、以下のような設定一覧が表示されます。 この画面中の下のほうに、何やらコマンドの羅列が見えます。 このコマンドオプションを元にバッチファイルを作成して、その上にエンコードしたい動画をDrag&Dropで重ね合わせると自動的にエンコード処理が始まります。 そんなの別にいいよと思うかも知れませんが、バッチファイルでやるとAviUtlでエンコするよりも倍近く時間短縮が可能になります。 上の設定で、50分ほどのTS動画を使ってNVEncのエンコード速度比較をしてみると、 ①AviUtl:6分40秒(220fps前後) ②バッチ処理:3分30秒(410fps程度) という結果にな
[昨年に引き続き] Tsurugiについて 詳細は以下 okachimachiorz.hatenablog.com ・これは前回の繰り言 要するにRDBを作りましょう、という話。いろいろインメモリーでメニーコアとか、ECC(Epoch-based Concurrency Control)とか、いろいろ特長はあるけど、目標としている機能の一つに「writeバッチ処理に強い」というものがある。 ■バッチ処理の困難さ このあたりも繰り言にもなる。基本的にまず、そもそも論としてwrite処理は既存RDBとは相性が良くない。これは単純に整合性を持たせる(serializable)ためのコストが大きいことによる。そもそも相性の良くないwriteをさらに大量に、かつ一度に書き込むバッチはさらに重ねて相性が良くない。 以下、今年一年の進捗的な話 ■Tsurugiの現状として 現在、Tsurugiでは本格的
こんにちは, メディア開発部の今村です. この記事は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. とあるように, こ
SharePointのAPIからファイル情報を取得したり、ファイルをダウンロードする。 簡単そうなことなのに、いかんせん情報が少なかったりガセネタばかりで手こずったので、ここに詳しく記録しておく。 前提条件確認、下準備 仮に、テナント名を{{MYTENANT}}、サイト名を{{MYSITE}}としよう。 ブラウザでSharePointの画面を閲覧する際は以下のようなURLになる。 https://{{MYTENANT}}.sharepoint.com/sites/{{MYSITE}} 「ドキュメント」をクリックすると以下のようなURLに飛ぶ。 https://{{MYTENANT}}.sharepoint.com/sites/{{MYSITE}}/Shared%20Documents/Forms/AllItems.aspx 「Shared Documents」がURLエンコードされて「Sh
はじめに バッチ処理を作る際に検討項目が多く手が動かない。。。。 そんな状況にならないためにフォローできる記事になれば良いと思い書き込んでみました。 そもそもバッチ処理とは 簡単にいうと一定量のデータを集めて、一括で処理する方法のことです。 主にユーザアクションに起因しない処理です。 実行についても定期実行、手動実行など様々な用途で用いられます。 バッチ処理にするメリット 大量のデータを一括で処理できること 稼働する時間を調整できる。(業務システムが稼働していない夜間などに処理を行える) バッチ処理の構成 基本としてバッチ処理は以下の構成となっている。 入力して加工して出力する 例 入力 DBのデータ CSVファイル 加工 抽出する 削除する 集計する マージする 出力 DBに登録する CSVファイルに書き起こす メール送信 ファイル作成して転送 バッチを作る際の検討事項 構築する際に迷っ
#1 処理時間とレスポンス時間 #2 バッチ処理とオンライン処理 #3 バッチ処理を設計するときの注意点(本記事) #4 オンライン処理とUXの工夫 #5 Railsのジョブ管理システムと注意点 #6 バッチ処理ですぐに使えるノウハウ、まとめ バッチ処理を設計するうえでの注意点 バッチ処理を設計する際は、処理時間がどの程度になるのかを事前に計測・見積し、その結果を元に実行計画を立てるのが重要です。少なくとも、所要時間の見通しもなくバッチ処理を作成するのは危険です。 一般的にはデータ量が増えれば処理時間も増えるので、データ量が増えたときに処理時間がどのように延びるかは予め見積もっておきます。たとえば「データが1万件のときは20分、件数が倍になると処理時間が4倍増える」といったように、データ増加に応じた処理時間を予測できるように計測やベンチマークを事前に実施しておく必要があります。 データ量と
本記事は、AWS Summit Japan 2021のセッション動画、「PAR-29: サーバー⽴てっぱなしはもったいない︕ サーバーレスのみで構築する 中頻度&短時間バッチ処理」のレポート記事です。 セッション概要 10 分に一度しか動かさないバッチ処理のためにずっと起動しっぱなしのサーバーを見てもったいないと感じたことはないでしょうか。 しかもその処理が 2,3 分もあれば全て終わってしまうとなれば尚更です。 本セッションでは AWS Step Functions を中心にサーバーレスなサービスを使用することで無駄な待機コストを無くし、かつレイテンシとスループットをできる限り上げたアーキテクチャを実際に設計・開発して得られた知見をご紹介いたします。 スピーカー 株式会社ゆめみ マーケティングソリューション事業部 遠藤 大輔 氏 セッションページURL https://summits-j
はじめに こんにちは, 基盤開発チームの奥山(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 で実行していました.
ITベンダーの間では、かねて『なぜみずほは、わざわざ高齢のエンジニアを雇ってまでCOBOLを使い続けるのか』が疑問視されていました といった、ITジャーナリストの発言を掲載している。 しかしながら、銀行業務の中ではバッチ処理が適した性質のものも多いだろうし、過去の資産を使いまわさないといけない局面はたくさんあるのだからCOBOLエンジニアが必要(たとえそれが他の言語に移植する仕事だとしても)だろうし、上記2点がみずほ銀行のシステムの「爆弾」だとは言い過ぎの気がするがどうだろうか。
はじめに こんにちは。 プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアばばです。 2023 年 1 月に中途入社としてジョインいたしました。 前職では不動産テックのエンジニアとして、データの各種エンジニアリング(クローリング、取り込み、集計処理)や機械学習ロジックのサービスへの組み込みを行っておりました。 overflow では、先日オープンβ版を発表いたしましたプロダクト開発支援組織の生産性最大化を支援するサービスである「Offers MGR」の開発を担当しております。 一見まったく別のプロダクトに見えますが、やっていることは案外共通点があり興味深く毎日開発をしています。 ただ、いまだジョインしたて業務に直結したことを書くネタはないので、Ruby on Rails(以下 Rails)のバッチ処理の概要をまとめてようとおもいま
「話を聞いたときは『やった!』と思いました」 そのとき、インテック ソリューション パワーの福井謙二氏は、心の中でガッツポーズをした。コニカミノルタが、複合機のデータ分析基盤「FDAS」(Field Data Analysis Services/エフダス)をMicrosoft Azureに移行すると決め、同社に直接支援を求めてきたからだ。2016年のことだった。 単に仕事が増えたことを喜んでいたわけではない。実は刷新するFDASは、2004年にインテック ソリューション パワーが構築したもの。以来12年間にわたって機能追加/運用を支援してきたのは福井氏のチームだった。しかし、2014年に行われたコンペでMicrosoft Azureへの移行プランを提案した同社ではなく、別のベンダーが提示したクラウド移行プランが採用された。 ところが、そのプロジェクトがうまくいかず、今度はインテック ソリュ
表計算ならExcel、写真の編集ならフォトショップなど、作業ごとの定番ソフトがあるものです。 しかし大量の画像の一括処理(バッチ処理)の定番は?と聞かれたら思いつかないかもしれません。 そんなときに無料の画像編集ソフト「GIMP」のプラグイン「BIMP」を使うのは選択肢としてありだと思います。 特に、普段GIMPを使っている人にとってはかなり使いやすいですし、GIMPで出来る高度な画像処理もほとんどそのまま可能です。 BIMPの使い方やインストールについて紹介したいと思います。 BIMPの使い勝手・操作の流れ インストール方法は後ほど紹介するとして、BIMPの大まかな操作の流れを紹介します。 GIMPとBIMPを正しくインストールすると、メニューの「ファイル」に「Batch Image Manipulation…」という項目が出現。 これをクリックするとBIMPのウィンドウが表示されます。
出典:日経クロステック、2020年4月7日 (記事は執筆時の情報に基づいており、現在では異なる場合があります) 「クラウドの利用コスト削減策では、サーバーレスが本命」。野村総合研究所 マルチクラウドインテグレーション事業部の遠山陽介GM(グループマネージャー)はこう話す。「AWSの利用料金の削減が期待できるだけでなく、サーバーを維持管理する費用を削減できる効果が大きい」。 サーバーレスとは何か。アマゾン ウェブ サービス ジャパン 事業開発本部 プラットフォーム事業開発本部 本部長の大久保順氏は「サーバーレスはユーザーがサーバーを立てる手間なく、必要な機能が使える。処理の増減に応じてキャパシティーを見積もる必要もない」と説明する。 AWSのサービスでは、イベント駆動型コード実行「AWS Lambda」、オブジェクトストレージ「Amazon S3」、NoSQLデータベース「Amazon Dy
1. ストリーム処理とバッチ処理の基本概念1.1 バッチ処理とはバッチ処理は、一定期間に蓄積されたデータを一括で処理する方式です。典型的には、1日、1時間、またはそれ以上のスパンでデータを集め、その後一度に処理を行います。 バッチ処理のメリットは、データを一気に処理するためスケーラビリティが高く、リソースの使用効率も比較的高いことです。 また、システムの停止やエラーが起きた際にリカバリーが比較的容易です。しかし、リアルタイム性がないため、即時反応が求められるケースには不向きです。 バッチ処理のメリット: 大量のデータを一括で処理できる。 処理の実行タイミングを自由に調整できる。 システム障害やエラーのリカバリーが容易。 バッチ処理のデメリット: リアルタイム処理ができない。 大量のデータが一度に処理されるため、ピーク時の負荷が高くなる可能性がある。 1.2 ストリーム処理とはストリーム処理
後編(冪等性の設計導入)へ はじめに こんにちは。タイミーのバックエンドエンジニアの中野です。よくGopherくんに似てると言われます。 本記事では月次で実行している「締め」のバッチ処理に関する一連の技術的改善について掲載します。弊社のプロダクト「タイミー」は著しい事業成長に伴いデータ量が急増してきています。そこで今回はデータ量の急増を背景とした中長期的なバッチ処理の設計改善にどのように取り組んできたのかをご紹介したいと思います。バッチ処理に関する技術的改善の記事は前編・後編の2部構成をとっています。前編はバッチ処理におけるトランザクションの改善をテーマに、後編ではバッチ処理に冪等性の設計を導入したことをご紹介したいと思います。 今回は前編のトランザクションの改善をテーマにご紹介します。すでに本番稼働しているアプリケーションにおいてトランザクションの範囲が大きい場合にどのような問題が発生し
概要 応答速度の改善を目的にシステムに非同期処理を組み込むことはよくあることかと思います。AWSでもSQSを利用することで比較的簡単にジョブキュー処理を実現することができます。一方で、バッチ処理との組み合わせも踏まえると、AWSのサービスの選択肢は複数存在するため分かりにくいです。 そこで、本記事では以下を整理してみました。 本記事で得られる内容 非同期処理のメリット・デメリット AWSで非同期処理・バッチ処理を実現する方法 実際にSQS × lamda × EventBridgeの組み合わせでサンプルアプリを作成 知識整理編 まず、前提となる基礎知識や非同期処理・バッチ処理を実現するために必要なAWSリソースを簡単に整理してみます。ここで紹介する内容は概要に留めるため、より詳細を知りたい方はAWSの公式ドキュメントやBlackBelt等の資料をご確認ください。 非同期処理 非同期処理とは
batch バッチ処理とは、複数の処理をまとめて一括で処理する方法のことだ。複数の処理をバラバラで実行するよりも、まとめて実行した方が効率的ということがよくあるので、そういう時に使われる。 ところでバッチというのは聞き慣れない言葉だ。バッチの英語での綴りは batch である。バッジ badge ではない。 Batch processing が日本語でいうところのバッチ処理だ。 Computerized batch processing is the running of "jobs that can run without end user interaction, or can be scheduled to run as resources permit." (https://en.wikipedia.org/wiki/Batch_processing) 動詞 batch や動名詞
こんにちは, メディア開発部の今村です. この記事はGunosy Advent Calendar 2022の6日目の記事です. 昨日の記事は村田さんの「Digdag が突然止まった障害を受けて」でした. この記事 (前編) と明日の後編では, EventBridgeとECSでバッチ処理基盤を整備した話を紹介します. 背景 & 技術選定 スケジューリング 実行環境 監視 タスク管理リポジトリの作成 構成 ecspressoでタスク定義を管理する より開発しやすくするために おわりに 背景 & 技術選定 最近はプッシュ通知送信システムのリプレイスを行なっており, その一環でEC2インスタンス上のcronで動くバッチ処理を移行することになりました. これまでチームとして決まったバッチ処理置き場を持っておらず, LambdaやEKS CronJobなどバラバラな環境を使っていたため, これを機に共
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
最近、同僚の@sunakujira(F.Shibusawa)と共にバッチ処理を書くことが多いので備忘録も兼ねてバッチ処理を書く上で意識していることを紹介したいと思います。 大きくは以下の3点を意識してます。 1. 再実行(リカバリ)する前提で考える 2. 処理の実行時間は問題ないか 3. サーバー負荷は問題ないか 今回は再実行(リカバリ)する前提で考えるに絞って紹介しようと思います。 内的要因、外的要因問わずエラーは必ず起こるものだと想定し、再実行(リカバリ)できるようにしておくことはバッチ処理の最たる要件の一つと言えるでしょう。具体的には以下を意識しています。 冪等性を考慮した設計 冪等性とは、何度実行しても同じ結果が得られることを指します。例えば、デイリーの売上を計算しDBに結果を保存するようなバッチ処理を仮定すると、冪等性を担保するためには、対象データが存在する場合に削除する処理を仕
はじめに バッチ処理とcronの書き方について本やネットの情報から調べて理解したことをまとめました。 もし、書いていることに何か間違いがある場合はご指摘いただけると嬉しいです。 バッチ処理とは バッチ処理とは、一定の時間に対象のデータをまとめて処理することです。 バッチ処理の具体例 毎朝今日の天気を知らせるメールを送る 毎日その日の終わりに売上の集計を行う 毎日決まった時間にTwitterでツイートする バッチ処理の流れ 大まかな流れは以下になります。 1.実行のタイミング トリガー起動 前提となる処理が完了したときに開始するもの 時間起動 毎日0時や5分毎になど、決まった時間に開始するもの 2.処理の実行 3.バッチ処理終了時に成功、失敗のログを出力 cronとは 定期的に自動で処理を実行させるプログラムです。 「1分毎に〇〇の処理を実行する」「毎日0時に〇〇の処理をする」など、設定した
Kubernetes上で動かしているバッチ処理の監視をCloud Monitoringで行なおうと思ったのですが、素朴にやるとちょっと困りました。一工夫したので、メモを残しておきます。 背景 Cloud Monitoringで素朴にバッチ監視を行なう これだと困る...! 次のバッチが成功するまでインシデントが閉じないようにする 背景 Webサービスの監視と同様にバッチ処理についても監視は必要です MackerelなどのSaaSを使うと、バッチ処理についても簡単に監視できます 最近の砂場活動その10: songmu/horensoを使ってバッチの処理時間をMackerelのサービスメトリックに記録する - yasuhisa's blog ただ、仕事のチームではMackerelを今は使っていません。GCPを使っているので、Cloud Monitoringでやるかなーという感じ メトリックやダ
リンク マネー現代 これから「みずほ銀行」に起こる、ヤバすぎる現実…システムの「爆弾」を誰も処理できない(週刊現代) @moneygendai 今年8月に発生したみずほ銀行のシステムトラブル。実は19年前にもこれに似たケースが起こっていたことを【前編】「「みずほ銀行」のシステム障害はなぜ防げなかったのか…エンジニアを見下す「悪しき体質」」で報じた。多発する「システム障害」の爆弾を抱えた同行は今後どうなっていくのか…? 267 users 1216 九八式計算機 @IJtyp98computer >>バッチ処理自体、とっくの昔に時代遅れになった手法ですが、(略) 「バッチ処理」は「時代遅れ」なんかになってませんよ。まさか「バッチ処理=COBOL」と思ってるの? 現代でも、JavaやPythonで書いた「バッチ処理」がバリバリ稼働してますからね。😳 gendai.ismedia.jp/art
みずほ銀行の本を読んでいて、バッチ処理は鬼門だなと感じた。 みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 作者:日経コンピュータ,山端 宏実,岡部 一詩,中田 敦,大和田 尚孝,谷島 宣之発売日: 2020/02/14メディア: Kindle版 システム障害はなぜ二度起きたか みずほ、12年の教訓(日経BP Next ICT選書) 作者:日経コンピュータ発売日: 2014/02/28メディア: Kindle版 個人的な経験でもバッチ処理で悩まされた事は多いので俺的バッチ処理ベストプラクティスを考える。 考慮不足もあるかもしれないので、もしなんかあればツッコミがほしい感じ。 その1:できるだけバッチ処理は減らす その2:1処理1トランザクションにする その3:異常発生時、正常に処理できるものは処理してしまうようにする その4:バッチ処理再実行時、未処理デ
今回はAmazon Web Services(AWS)でのバッチ処理コストの削減方法を取り上げる。オンプレミス環境だけでなくAWSでも、日立製作所の「JP1」やユニリタの「A-AUTO」といった統合運用管理ツールを使ってバッチジョブをコントロールしている企業は少なくないだろう。バッチジョブのコントロールをAWS Step Functions(以下、Step Functions)などのマネージドサービスによって実現すれば、コストを削減できる可能性がある。 AWSのマネージドサービスを使ってジョブのコントロールを実現するには、さまざまな手法がある。例えばStep Functionsや「AWS Batch」、「Amazon MWAA(Amazon Managed Workflow for Apache Airflow)」などを利用する方法だ。筆者は、AWSの各マネージドサービスと従来の運用管理ツ
まとめ 使うべきサービスは AWS Batch GPUあり/なしで挙動が変わるライブラリに注意 DockerHubにGPUあり版のイメージがある場合はそれをbaseにすると楽 例: PyTorch 背景 以下の要件を満たすシステムをAWS上に組みたい 毎日/毎週1回のみ動かし、他の時間は課金しないで欲しい スポットインスタンスが使えると嬉しい GPUは必須 例: https://zenn.dev/miyatsuki/articles/0d66daf6615962 それができそうなサービスがいろいろあるがどれを使えばいいのかよくわからない Fargate ECS SageMaker AWS Batch (採用) なぜAWS Batch? Fargate GPUが使えないのでNG CPUだけなら、Fargateでもいいと思います ECS GPUインスタンスを立ち上げ続ける必要があるのでNG S
こんにちは! エス・エム・エスキャリア開発者の石塚です。 今回社内で利用するバッチ処理基盤として、Google Cloud Platformのプロダクト、Cloud Composerを導入したので、 その事例について紹介します。 なぜGoogle Cloud Platformなのか Google Cloud Platform(以下GCP)と他のクラウドサービスを比較して、一番の特徴は、BigQueryの存在だと考えてます。 Salesforce、Webのログ、その他様々な場所にあるデータをBigQueryに蓄積し、データ分析基盤として利用するためにGCPを使っています。 今回導入したCloud Composerも、主にGCPを中心としたデータ連携基盤として運用しています。 Cloud Composerとは Cloud Composerとは、GCP上でApache Airflowというワーク
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く