バッチプログラムの運用と監視について検討しよう | メルカリエンジニアリング
こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 バッチプログラムのお話、今回は運用・監視についてお話したいと思います。当社はすべての業務が24時間行われていますので、システムがオンラインのときに動作するバッチプログラムについてのみ議論します。 過去の記事はこちらにあります。 運用に備えて バッチプログラムの運用について、「プリモーテム」「実行管理」そして「ログ管理」の3点について述べていきます。 プリモーテム ポストモーテムという言葉を聞いたことがある方はいらっしゃるかと思います。ポストモーテムとは、GoogleのSRE本の15章*1によれば、障害などの失敗を振り返り、今後に活かすプロセスの総称と捉えることができます。 さて、プリモーテム(プリモータム)とは何でしょうか。この言葉は、私が最近読んだThe Manager’s Path*2*3で使
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
実録!!データ構造リファクタリング -- 僕とメッセージ機能の300日戦争 - Qiita
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の
そのメールアドレス、現在も使っていますか？ - クックパッド開発者ブログ
こんにちは。ユーザーファースト推進室ディレクターの大黒です。 ありがたいことにクックパッドは今年で20年目をむかえ、数多くのユーザーに利用されるまでに成長しました。それ故に発生する課題もあり、今回はその中でもユーザー登録に使われているメールアドレスの課題と対策をご紹介したいと思います。 ユーザー登録の仕組み クックパッドのユーザー登録では、下記の項目が必要となります。 メールアドレス パスワード 郵便番号 生年月日 ※iOSアプリでは郵便番号と生年月日は任意入力となります SNSアカウント認証や認証コードでのアクティベートを採用するサービスが今では主流ですが、20年続くサービスであれば一般的なユーザー登録フローではないでしょうか。しかしながら最近のスマートフォンユーザーの多くはメールを使わないという実態も分かっているため、ユーザー登録にメールアドレスを使い続けるかどうかは、別途議論を進めて
強制バージョンアップの話。 - なるようになるかも
という記事を見かけたので。 このライブラリの実装の問題点 key description type 基本的には強制バージョンアップを行うことを前提に解説していますが、SRGVersionUpdaterではキャンセルボタン付きの告知アラートを表示することも出来ます。強制アップデートの場合は"force" を任意でのアップデートの場合は"optional"を入力して下さい。 これ、設計ミスってません？ 一度致命的なバグを出して"force"で通知したら、それ以降二度と"optional"は使えません。「必ず一定以上のバージョンを使って欲しいけど、最新版の通知もしたい」ようなユースケースに対応できないなら、"optional"の存在意義はない気がします。 あと、「評価が付くまで様子見ユーザー」層は毎回"optional"の通知を繰り返し見せられて離れます。開発者がいいと思ったアップデートが必ずし
うさぎとSEのブログ: ログに対する認識の甘さ
ソフトウェアを開発する方ならば、多くの方はログをプログラムから出力しているかと思います。 ログは例えばリリースした後に客先で動作しないなどの何らかの不具合が発生した際に、原因等を探るとても重要な情報源です。そのため、ログを適切に出力、保存されなければ、そのログはただ要領が大きいだけのゴミにしかなりません。 ただ、ログを出力するということは、 1. 何を出力するべきなのか？ 2. いつ、だれが、何に利用するのか？ 3. いつ出力するのか？ 4. 何を出力してはいけないのか？ 等を考えながら出力している方は少ないように思います。 ログを出力するときに、ログに対してもみなさんは設計書を作成していますか？ ばかばかしい、ログなんてメインの業務処理から考えればオプションのような位置づけだと思うかもしれません。 ですが、ログ出力を正しく行わないと、私の周りでは、今までこういった問題が発生してきました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
