ポツさんスマートフォン用の表示で見るコンポツさん2016-02-19続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。知識が体系化されてカジュアルに学べない上にそれを知っているだけで飯が食えるとまで言える状況なのか。みたいな熱めの感情が当然湧くわけだ。ちなみにそのコメントを読んだボスの感想はこれ。18ボスは主戦場がJSの人だからね〜。それはさておき、書くべきだった(事故った経験があるのにまとめ忘れていた)ものや抜けていた視点というのもいくつかあったので、それらについても想像力を巡らせてノウハウとしてまとめておくことにしましょう。テクニック実行中の進捗状況を確認できるようにするデータのインポート処理、エクスポート処理、集計処理、なんであれ時間のかかるバッチ処理というものは時に異常に時間がかかることがある。出社したらアラートが飛んでおり日時バッチがさっぱり終わっていないことがわかったとしよう。障害なのはわかったが遅延の状況を知りたいということがある。軽度の遅延であり、すでに90%ほど終わっているのか。10%しか終わっていないし1%進捗するのにO(n2)で時間がかかるようになっているのか。(残念、終わる見込みはない。ジョブをkillして対策を練るプロジェクトチームを結成しよう。ソルジャーではないそのあたりでまごついている人に状況を説明し、障害報告書を書いてもらおう)実行する処理のフェイズやデータ量に対して何%まで処理が進んでいるのかをログにつどつど記録しておけば、障害時にそれを元に判断を下せる。不幸にもログがなくて判断するための材料がない場合は、モニターと上司と同僚の顔を交互に見つめて誰か声を発するのを待つぐらいしかできない。17:18b.hatena.ne.jp異常データ、異常動作のアラートバッチ処理というのはコマンド起動であれ、デーモンであれ、運用時の監視やアラート設定から漏れてしまうことが多い。監視設定から抜けてしまうと、これはユーザーのインタラクションに直接紐付かない場合、誰も気が付かないまま時が過ぎてしまうことがある。みたいな問い合わせが来たりする。俺達はマヌケでありこの集計は冪等に実装されていないので直近1ヶ月の集計しかできない。「実行されているべき時間帯にきちんと正常起動して正常終了した」ということをログから監視できるようにしたうえで、監視を設定してもらう必要がある。Runオプションの用意バッチ処理を実装する際は「処理対象範囲を引数で指定可能にする」ようにしたほうがよいと書いた。引数として与える対象日時を計算しているときに同僚が「障害報告書の雛形どこにある?」とか聞いてくるわけなので、当然計算はミスっている。いざ、本番で再集計を実行しよう。10:15b.hatena.ne.jpリカバリー手順を用意する。リカバリー可能な実装にする「可能であれば冪等に実装する」に似ているが、ちょっと意味が違う。バッチ処理はマスタなどの重要なデータ変更に直結している部分なので、当然ながら慎重にならなければいけない部分だ。失敗時に「マスタデータ全部壊れましたワァ。戻りませんワァ」とか言ってると、こういう場合は障害報告書だけでは済まない。ボスがボスのボスと雁首揃えて顧客に謝罪と迅速な対応と恒久対策の約束をし、ちょっと無理な要件とかもねじ込まれて帰ってくることになる。いうわけでバッチ処理の実行前にマスタ情報などを別の場所にコピーして、バッチ処理が壊れていた時にもリカバリーできるようにしておくと良い。コピーするときはコピーした時の引数や時刻情報も付与して何世代か保持しておくとより安心だ。ポツさん[プログラミング]バッチ処理、マスタ更新とかデータに直結する部分だから、実行怖い印象ある。失敗時のリカバーの方法は考えておかないと。11:37b.hatena.ne.jp開発・テスト時と本番時の環境差分を最小にしておくこれはもうバッチに限らないですね。使うだとかいろいろなツールを駆使し、サーバーの構成からネットワークまで差分を最小にした状態でテストしたいものです。最近はIaaSの時代になって比較的そういうのやりやすくなっていいですね。ポツさん[プログラミング][設計][バッチ][batch]障害起こった時に対応しやすいように融通効かせる設計にするとかログ出力を考えとくしかないのかな。あとテスト環境と本番環境のディレクトリ構成は常に同じにしておくとかそういうのも大事です。12:32b.hatena.ne.jpワーキングディレクトリの扱い方バッチ処理を行うとき、ファイルシステムであれ、RDBMSであれ一時的なデータ領域が必要になる。ワーキングディレクトリにしよう。かち合うことになり、毎時バッチAとBのデータが混ざってつらいことになる。一時ファイル名なり、一時テーブル名なりにデータが混濁しないようにぶつからない名前空間を作ってやる必要がある。「処理対象範囲を引数で指定可能にする」で指定したパラメータをパス名に含めてやるといいですね。同一スキーマに置くのも避けたほうが良い。大量のテーブルやファイルがひとつの名前空間に置かれるとだいたい辛いことになるので。分散バッチはProductionでの経験がないのでちょっとまだノウハウがありません。18ロックファイルについて制御ファイルのロック掴んで残りっぱなし問題は、実際よく聞くんだけどそういうケースを自動でなんとかしちゃうのもなんか怖いので良い答えを持っていない。RDBMSに制御データも持つというのがひとつの答えなのかなぁ。ポツさんよくあるトラブル対策としてまとまってる。あとは制御用ファイル置いとくとエラーで死んだときに残りっぱなしになる問題はあるな。ポツさん[スクリプト]ロックファイル周りは処理が異常終了して解放されず、毎回手作業が発生するトラブルには遭遇したな。09:11b.hatena.ne.jpいろいろ書いたけれどバッチ処理は楽しい!事前条件と事後条件が明らかであり、テストがしやすい。クソみたいに長いSQLを書いて障害を起こして、それを別のクソみたいに長いSQLに書き換えて数百倍のパフォーマンスを得るという最高の体験ができる。大量のデータを扱うことが多いので、単純にワクワクするし、レポート画面がとか出ると価値っぽいものを感じる。実装しているとインクレディブル・マシーンを思い出す。障害を起こさないバッチ処理がかければ最高なんだ。バッチ処理の知見を体系的にまとめて最高の人生を送ろう。00:45続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本Tweet広告を非表示にするもっと読むコメントを書く2016-02-17Web系の自分が想像と障害で学んだバッチ処理・設計の基本バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。してから、出力する」という事になる。INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。バッチ処理を選択する事が多い。実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。利用者の操作に対して対話的・同期的な処理はオンライン処理、そうでない処理はバッチ処理と言われることが多い気がする。してから、出力する」について細かく考えていこう。このあたりを本当は細かく説明したほうがいいのかもしれないけれど、今は気力がない。起動タイミングについては大きく二つ種類がある。定時起動とトリガー起動だ。毎月N日トリガーWebUIの操作WebAPIへのリクエストscpでファイルが置かれるメッセージキューざっくりこんな感じだ。データをロードシステム内部・外部のデータを特定期間・範囲でロードする。ロード元はいろいろあるけどだいたいこのあたりだろう。するロードしたデータを処理していく。処理内容はいろいろあるけど大体このあたりの処理をする。集計データの出力さて、データを加工・集計しても、それをどこかに出力しないと意味がない。出力先はまぁいろいろある。ここが外部へ影響を与える瞬間なので一番怖い。次のバッチを起動するテクニック・運用のためにやっておきたいことさて、ここからがこの記事のメインだ。バッチ処理を実装する際には、結構いろいろなテクニックがある。これらすべてを対応する必要はないかもしれないけど、実装する際に一度は考えておいたほうがいいことばかりだと思っている。ロック範囲が広がるばっかりでデッドロックの温床になったりして何もいいことがない。一時テーブルなどに変更結果やインサートデータを投入しておいて、更新クエリ一発で対象データをガッツリ書き換える様な実装をするほうがよいだろう。ファイルなどの場合も、書き込み途中で次のジョブに参照されるみたいな不幸を避けるために一時テーブルに書き込んでおいて最後にリネームするとかしたほうがよい。可能であれば冪等に実装する冪等についてはいろいろなところでかなり触れられているので、特に言うことは無い。」というつらいことになる。これは設計センスがかなり問われるし、自分も失敗した経験があるので「可能な限りがんばっていきましょう!」みたいな気持ちがある。バッチ処理のフェイズ毎だとかユーザー毎に、影響範囲が重なっていなければ並列で実行することで処理が早く終わることもあるので抑えておきましょう。並列処理すると当然負荷も上がる場合が多いので、主目的のサービスが死なないよう最大同時スレッド数など、実行負荷の調整ができる機構を備えておきましょう。ログやテーブルに記録しよう。ログにはかかった時間も出力するとよい。パフォーマンスの劣化を監視するための指標にできる。計算するのは面倒なので計算してログに出しておこう。RRDToolsなどの運用ツールに放り込みやすいようになってるとよりよい。RDBMSに投入するときは、バッチ処理そのもののトランザクションと実行記録を残すためのトランザクションを同一にしていると、処理失敗時に記録用レコードもロールバックされてしまうので、実行記録はログに出力しておくほうがよいだろう。処理対象範囲を引数で指定可能にする不幸なことに障害が数日続くという時があるかもしれない、問題解消後に日次バッチを手動集計します。みたいなときに助かる。指定しないときは動かないようにするか適切なデフォルト値を自分で判定するかについては、実装者の好みで決めればよい。みたいなファイルがあれば、既にバッチが起動しているので新たに起動したバッチは処理を続行しない。みたいな制御を入れておくと多重起動してはいけない処理を重複して実行されずに済む。ロックファイルではなくて、DBの設定レコードを見るとかでもよいと思う。バッチサーバーが複数台にまたがっている場合などは一台のDBでロックをとるほうが安心だ。みたいなファイルがあれば、メンテナンスモードに入っているため新たに起動したバッチは処理を続行しない。コメントアウトし忘れたり、外部からのトリガーが不意に来たりすることがないのでよい。停止ファイルではなくて、DBの設定レコードを見るとかでもよいと思う。バッチ処理の実行、停止はコントローラブルにしておこう。そのまま残しておくとディスク容量を圧迫するけれど、システムからはほぼ利用される事が無い。いうデータは定期的に消すような処理(これもバッチ処理だ)を忘れずに入れておきましょう。法律的な理由で一定期間残さなければならないだとか、実装後半年たったら本当に消してもいいデータなのかどうかよくわからなくなった。最初からデータのライフサイクルは意識しておこう。デーモンの採用基準バッチの実行プロセスをデーモンにする理由は、単にカッコイイからだとちょっと弱い。感覚の話でアーキテクチャを決めてはいけない。起動処理が遅く、期待するレスポンスタイムを満たせないトリガーの頻度が多く、常時起動のほうが負荷を制御しやすいトリガーとなるアクションを常に監視しなければいけないみたいな理由をでっちあげて君だけのかっこいいデーモンを作り上げよう。webアプリサーバーにエンドポイント作る方法でもいい。webアプリサーバーに組み込んでしまうと複数のバッチ処理をひとつのインスタンスで実行するということになるので、再起動のタイミングなどが少しシビアになってしまうかもしれない。このあたりはトレードオフをきちんと考えておこう。以上、ざっくり踏みまくった地雷から得た知見をまとめたので、各位には「お前の書いていることはインチキだ」だとか「これを読めば全部わかる」だとか「これは間違っている」などどんどん殴って来て欲しい。俺はもうこれ以上障害を起こしたくないんだ!追記はてぶで意見をいっぱいもらったので続きも書きました。23:20Web系の自分が想像と障害で学んだバッチ処理・設計の基本Tweet広告を非表示にするもっと読むコメントを書く2016-02-13Doma勉強会Doma勉強会に行ってきた。kanjava.connpass.com資料はこれDoma実践メモからView層までDomaのエンティティやドメインオブジェクトを持ち込む?うらがみさんとしては結構やってるとのこと。JAX-RSでControllerの引数として受け取るところからドメインオブジェクトにする方法を説明していたので、DB層のエンティティがViewまで来ているというよりビジネスモデルがViewやDBのレイヤでシームレスに扱えてるという事だと思った。Domaがエンティティにドメインオブジェクトを持てることと、黒魔術が無いからこういうことが実現できている気がする。View層やDB層のフレームワークがPOJOをそのまま扱えるように発展してきたからからこそできることっぽい感。Publicフィールド使うほうが多い?(Beanにしないことが多い?)Beanでも別にいい。JPAのようにMethodに@Idや@Columnアノテーションをつけて云々みたいなのはできないみたい。フィールドに詰め込むときは、リフレクションで詰め込んでいるけどもだからといってパフォーマンス的にそこで問題を感じたことは無いとのこと。Domaの設計思想的にあまりサロゲートキーは使わない(使う必要がない?)これは聞き忘れた。複数主キー指定できるのでなくても困らない感じではある。↑↑上記は私が発表を聞いた時に感じた感想で、実際にはサロゲートキーを使われているとのこと。Batch用ConfigとAppServer用Config、両方で使えるDaoって作れるの?使えるよ。DaoにConfig受け取る引数がある複数DBとかもConfig工夫したらいけそうですね。複数につける複合主キーに何か意味があるのかな。組み合わせも問題ないかもしれない。それを使ってくれるのでエエカンジとのこと。プロセッサーを書いているとのこと。ようにあまり高機能でない静的型の言語でORMでいい感じにインピーダンスミスマッチを解消するって言うのはなかなかうまく行かない場合が多いなぁと思っている。SELECT文の結果というのは型がある。SELECT句が動的に変わる場合(JOINとかだね)というのは静的型ではどうやったってミスマッチを吸収できない。HibernateやJPAはSELECT句とEntityをマッピングするわけではなくテーブルとEntityをマッピングするので、テーブル定義とSELECT句が一致する場合は問題ないのだけれども、一致しない場合に途端に辛いことになってくる。言ってないし結果セットをEntityにしてくれるだけというシンプルさがある。SQLを書かせる代わりにメソッドの情報として利用しているのでコンパイル時に強力に型チェックしてくれる。みたいなのはやっぱりいいなぁと思う。ひとつだけ気になっているのはDomaのいろいろ割り切った故のほぼ完成しちゃっている感。うらがみさんにも「今後のロードマップとかあるんですかね?」って聞こうと思ってたけど忘れてた。完成しちゃってメンテナンスフェイズとかに入ると活発に見えなくなっちゃってプロダクトの死に近づいちゃうみたいなの、どうしてもあるので。それはそれとして、今度レイヤードアーキテクチャだとかDDD的な設計とか話したいということもワイワイ話せたので良かった。今度、梅田で夕飯などを食べながら技術を語る会のようなものをできたらいいなぁと思ってます。23:24Doma勉強会Tweet広告を非表示にするもっと読むコメントを書く2016-01-23DevLOVE関西行ってきた。https://devlove-kansai.doorkeeper.jp/events/36446以下、自分の勝手な解釈が多々含まれるけど感じたこと、きいたことをまとめる。「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」というエモーショナルなタイトルで、現場よりの話。仕事のできないメンバーをできるように変えていくにはという話。仕事ができるとは何か。そこからして人によって受け止めかたは様々だろうけどまぁそれはそれ。人から期待した結果を引き出すためその人に変わってもらおうとするとき、どう変えたらいいのか、本当に変えていいのかという不安が出てきがちである。人によってはそれは簡単なことだと感じられ、人によっては困難な道のりに感じられる。その差は人によってそれぞれ抱えるメンタルやとるべき責任、思い込みなどの背景が違うからだという話。それじゃぁ行動を変えるには、習慣化するにはどうすればいいだろう。いうとき、たいてい気合いとか気の持ちようだとかの解決策が提示されがちだが、そういう解決策は実行・継続不可能なことが多い。よって、小さく行動を変えさせ、分かりやすいフィードバックを与えてやり、その射幸性によって習慣付けさせ、その人を期待通りの行動を取ってくれるように計らうのが行動学的に理にかなっているという話。フィードバックは早ければ早い方がよい。動物的なレベルでいうと60秒以内が望ましい。理性的な大人は2週間ぐらいはギリ待てる。雑だし、ソシャゲーみたいな表現になったけど、根本はそんな感じかなと思った。したら「小さく行動を変えさせ」のところは行動を変えさせる必要もなくて、好ましい指標を外部から計測し、公表してあげるだけでもよいかもしれない。いうのは行動科学マネジメントというジャンルらしい。そのまま他人に適用するよりも、まずは自分に適用してみるのがよさそうだと感じた。「人はこういう風に振る舞うんだよ」と、生半可な知識で知った風なことを言って逆鱗に触れてはいけない。「こういう心理作用かあるとのことなので、最近心がけています」みたいな所から始めて効果を確かめつついい感触であれば周囲にも広めていくぐらいが今の自分にはよさそう。して、勉強会のフィードバックを早めに出すことも、今回の勉強会で学んだことだ。いいオチがついたのでそれではまた。00:32DevLOVE関西行ってきた。Tweet広告を非表示にするもっと読むコメントを書く2015-08-31fitdesk使用感日記fitdeskを買ってからというもの、PCに向かうとき=fitdeskぐらいの勢いで乗っている。PCがfitdeskの上においてあるのだから当たり前なんだけど。実際にfitdeskを買うまでは「これはとてもいいものだからオフィスへの導入を考えてもいいものなのでは」ぐらいに思っていたのだが、実際に乗っていると思った以上に汗をかいてしまうので、だいたいパンツ一丁の状態で乗っていることが多い。職場でパンツ一丁で働いているメンバーが居ると辛いものがあるだろうから導入は厳しそうだ。職場への導入は別に真面目に考えてるわけでもないのでそれはそれとして。あるサイクルマシンのように絶対にダイエットするんだ!みたいに強い意志でガツガツ乗る必要がないので気に入っている。PCで作業したければサイクルマシンに乗る事になるので、自然と運動するようになる。いえずっと乗っているとさすがに疲れるのでちょっと疲れた時は普通の机で仕事をする。体重は81kg周辺をさまよっているが、2kgぐらいは普段から増減あるので特に効果は出ていないと言える。78kgぐらいがコンスタントに出るようになってきたら効果が出てきたと言えるんじゃないかなぁと淡い期待を抱いている。13:34fitdesk使用感日記Tweet広告を非表示にするもっと読むコメントを書く2015-08-28トマトジューストマトジュースは健康にもダイエットにもよいということなので安直ながらのみ始めた。娘もちびっ子には珍しくトマトジュースが飲めるっぽいので一緒にのんでいる。健康でも開発でも何事も銀の弾丸はないので継続あるのみなのだ。運動不足きっかけプログラマーは、だいたい運動不足になりやすい仕事だ。PCに向かって色々調べ物している時やプログラミングしている時が一番楽しい時なので、動かなければいけないという差し迫った状況にないと際限なくPCの前で座っている人も少なくない。オフィスで仕事をしているプログラマーであれば出社が必須なので少なくとも通勤という名の運動ができるが、今風に在宅勤務するようなプログラマーというのは本当に運動をする機会がない。私自身、この春から週に一度ずつ在宅勤務をしていたのだが最初の数回は朝時間になったらPCの前に座り、昼休憩以外はずっとPCの前から全く動かないという不健康極まりないありさまだったのだ。いろいろな状況が重なって私は2015年9月から週に3回程度の在宅勤務になる予定だ。なると運動不足が今以上に深刻な問題になってくると思っている。大学入学時に178センチ65キロ程度だったのが、大学卒業時には70キロを超え、中年になった今や83キロもあるのである。18キロ程度、生命活動に不要なことが明らかな肉があるということだ。会社の同僚にも「体脂肪率30%!体の30%が油!」と言われてしまうのだ。これ以上、運動不足な人生を送って贅肉を増やしていくのはリスクしかない。在宅勤務が増えて加速度的に体重を増やしてしまうと、生産性は脂肪による死亡で0になる。人生を変える時が来たのだ。冴えた解決策だいたいにおいて、一人の人間が合理性を追求して出した結論というのは異様に見えることがある。fitdeskという商品はまさにそれであろう。私にとっては合理性の限りを追求するとこの製品のような結論に達するのはごく自然であることに感じられるのだが、世間様の評判を調べると「何たるネタ商品!」みたいな感じの扱いをされてしまっている。言うわけで、我が家にはfitdeskがある。これから、fitdeskに乗りながら本blogを書いていくという算段なのだ。実は昨日書いた記事もこれに乗って書かれている。mitomasan.hatenablog.com食事制限をするつもりはあまりないので、業務中にこの机にまたがっているだけでどれだけの効果があるか、気になるところである。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事システムの利用者に安全に独自のビジネスロジックを定義させるプログラマとミールキットチームのやっていきを言葉にする「コンピュータシステムの理論と実装」をRustで。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。