horensoで作るモダンなcronスクリプト監視環境 - ZOZO TECH BLOG
こんにちは。 モルトとシガーで生きてます。インフラエンジニアの光野（@kotatsu360）です。 先日、crontabで管理しているバッチ処理の監視にhorensoというツールを導入したのですが、 監視の品質が向上 毎分届く大量の実行結果メールから開放されQoL向上 という効果がありました。本日はその取り組みについてご紹介いたします。 ジレンマ：動作監視と大量のメール 冒頭の通り、VASILYでは定期的に実行したいバッチ処理をcrontabで管理しています。 真新しさはありませんが、実行時間の指定が簡潔かつ柔軟で未だに愛用しています。 2016年12月現在、crontabは120行ほどです。 さて、そんなcrontabによる処理で前々から課題になっていたのが、 crontabで管理しているスクリプト達（以下cronスクリプト）の動作監視です。 当時、VASILYのcronスクリプトは3箇
horensoのSlack reporterを書いた
すっかり季節は年度末ですね〜。なんと明後日には新年度で新入社員が入社してくるぞ!! ということで新卒研修の準備に追われてる今日この頃ですが、みなさまいかがお過ごしでしょうか。 さて、研修準備も長々やると疲れてくるのでちょっと現実逃避に…というわけではないんですが、最近horensoというGoogleじゃないほうのcronなどでコマンドをwrapして成功失敗の通知を仕組み化するツール(詳しくは作者のSongmuさんのブログをご参照ください)用にSlack Reporterを書きました。ちなみにGoogleのhorensoは漢字入力システムです。 で、きっと今どきのWeb系の会社はSlack使ってるところ多いし、社内の各プロジェクトで汎用的に使えるように作ったから勢いよく全世界に公開しておくか〜と思った次第なので、この記事を(現実逃避に)書いてます。この前とある勉強会に行ったときも自席から前側
20191004_AWSサービスで実現するバッチ実行環境のコンテナ/サーバレス化_2
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. T O K Y O 2 0 1 9 . 1 0 . 0 3 - 0 4 AWS / © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. T O K Y O 2 0 1 9 . 1 0 . 0 3 - 0 4 AWS / G - 5 6,000 91 1.5 650 0 450,000 900,000 1,350,000 1,800,000 2 0 1 4 / 4 2 0 1 4 / 5 2 0 1 4 / 6 2 0 1 4 / 7 2 0 1 4 / 8 2 0 1 4 / 9 2 0 1 4 / 1 0 2 0 1 4 / 1 1 2 0 1 4
Step Functions & Fargate バッチでやらかしたこと - Qiita
この記事について この記事は Opt Technologies Advent Calendar 2019 17日目の記事です。 担当プロダクトで利用したStep Functionsにて、失敗を通じて得た知見をまとめたものです。 自分について 中途入社して1年ちょっとのエンジニア。チームマネージャになって半年くらい。 入社してからクラウドインフラを学習し始め現在もチーム内で主に担当をしていますが、アプリケーションコードも状況に応じて実装する感じです。 昨年はこんな記事書きました。 やらかし背景 著者の担当プロダクトにて、外部APIから取得できるそこそこのサイズのデータをプロダクト側のDBに格納する処理があります。 ELT的なステップを踏んで処理することを検討しStep Functionsを採用しました。 Extractorが外部APIからデータファイル(csv)を取得しS3バケットに格納 L
Serverless連載6: AWSのStep FunctionsとLambdaでServelessなBatch処理を実現する | フューチャー技術ブログ
Serverless連載6: AWSのStep FunctionsとLambdaでServelessなBatch処理を実現する はじめにAWS StepFunctionsとLambdaを活用してバッチ処理を行う記事です。サーバレス連載企画の6回目です。 2020年はServerlessアーキテクチャが当たり前のように採用される時代になってきていると実感します。フロントエンドからアクセスされるBackendのAPIはAWS環境だと、AppsyncやAPI Gateway+Lambaの利用、IoTなどイベントドリブンなメッセージに対してはAWS IoT、その後続はKinesisを使い、さらにその後続でLambdaやKinesis AnalyticsでETL処理を行い、データストアとしてDynamoDBやS3に格納するといった一連の流れ全てフルマネージドなサービスに寄せて構築することも当たり前で
バッチ処理のスケジューリングパターン
この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、８パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng
horenso v0.9.0でより便利になりました | おそらくはそれさえも平凡な日々
https://github.com/Songmu/horenso v0.9.0なので、version 1を出す前のRC的な気持ちでいます。アップデートは以下のとおりです。 設定ファイル(yaml形式)サポート($HORENSO_CONFIG) ログファイル指定オプション(--log/-l) verboseログを出せるように(--verbose/-v/-vv) タイムスタンプのフォーマット変更 type Report struct の型情報の非互換修正 設定ファイル(yaml形式)サポート 設定ファイルは環境変数 $HORENSO_CONFIG にファイルパスを指定します。設定項目は大体コマンドラインオプションに対応していて以下のような具合です。 noticer: /path/to/basic-noticer reporter: - /path/to/basic-reporter こういう
Amazon ECS ScheduledTaskで実現するスマートなDockerベースのバッチ実行環境 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 コネヒトでは、開発環境に続き、続々と本番サービスにもDockerを導入しています。 今回は、中々運用が大変なcronでスケジュール管理するような定期的なバッチ処理を、Amazon ECSのScheduledTaskを使ってDocker駆動な環境で構築した話です。 他の方法との比較やどのように実現しているのかについて紹介したいと思います。 今回対象とするバッチの種類 今回対象とするバッチ処理は、俗に言うスケジュール系のバッチ処理で、毎日00時00分や10分毎にサイクル起動等、事前に定義した時間に正確に動くことが期待されているものです。 ※ジョブキュー形式のバッチだと、AWS BatchやEBのWorkerもしくは、SQS + Cron on EC2で処理するほうがスマートかと思います。 実行方式の選定 上記要件のバッチを実現する基
ストリーム処理とは何か？＋2016年の出来事 - Qiita
その対処で全部に対応するのは無理なんじゃないの？ Watermark、Trigger、Accumulationの機構が導入されればストリーム処理は全て対応可能かというと、 そんなことはありません。 何故なら、下記のような問題が発生してくるからです。 Watermarkを実時刻からどれくらい遅らせて設定すればいいのか？ 遅れを大きくすれば正確性は増しますが、遅延時間は大きくなります。 Accumulationのためにウィンドウの集計結果をどれだけ保持すればいいのか？ 保持する時間が長いほど、ストリーム処理を行うシステムのリソースが必要となります。 データ処理システム（バッチ、ストリーム含む）には下記の３要素のトレードオフがあるとされています。 完全性(Completeness) 低遅延(Low Latency) 低コスト(Low Cost) この３要素を全てに満たすことは出来ず、全てのデータ
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
This document provides an overview of Elastic Load Balancing (ELB) on AWS. It discusses the different types of ELBs (Application Load Balancer, Network Load Balancer, Classic Load Balancer), their key features and how they can be used to build scalable and highly available systems by distributing traffic across multiple Availability Zones and targets like EC2 instances or ECS containers. It also c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cloud Schedulerへの期待とマネージドジョブ実行基盤の今後