Zenn
🐒

あとで読むをいま読む(1)

2024/06/12に公開
バッチ処理
ADR
idea

まえおき

タイトル意味わからなくてすみません。皆さんはあとで読んでいますか？私は読んでいません。

弊社ではアウトプット時間というものが業務時間内に設けられており、主に技術ブログを書いたりするために使われています。詳しい話はまたどこかで書きます。

この時間を使って、あとで読むつもりになっているが一生読まないものを読んで何かしらの形でアウトプットしようというのが、このシリーズの目的です。

参照させてもらう記事は、比較的最近目にした記事で私がまだ読めていない記事です。印象的だった箇所を抜き出したり、勝手にコメントしてみたりして、自分なりにまとめました。

『組織が記憶喪失になるのをどうすれば ～ ryuzee技術顧問にきいてみた』

https://engineers.ntt.com/entry/2024/06/10/091000

メモ

  • 何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていないことを、本記事では「組織が記憶喪失になる」と呼んでいる
  • ryuzee氏のアドバイス: ADR: Architectural Decision Records
    • アーキテクチャ上重要な決定そのものと、どういう理由があってその決定をしたのかをまとめた記録
  • ADR の実践
    • How ではなく Why(=Issue) を書く
      • その変更をするに至った背景、なぜ必要と思ったかなど
    • GitHub なら PR に書く
    • GitHub に書けないものもどこかに書き残しておく
      • 「簡単に書けることと簡単に検索できること、この2点を満たすことがとても重要」

感想

私たちも同じようように組織の記憶喪失については悩んでおり、その結果、PR には背景などを明記することをルール化していたので納得感のある話でした。

コードコメントにしろ、アーキテクチャにしろ Why を記録するのは重要ですね。引き続きやっていきたいと思います。

『大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』』

https://techblog.zozo.com/entry/batch-development-guideline

メモ with my comments

  • 「AZの障害発生時に別のAZにてバッチを実行出来る」
    • 基本マルチ AZにしているので問題ないはずだが、あまり意識していなかった
    • AZ 障害を再現するサービスがあるようなのでそのうちやってみる
  • 「依存関係を把握する」
    • 勉強になる。仮にバッチが失敗した場合に、どの機能がどうなるとか、あまり気にしていなかった
  • 「依存処理がある場合は待ち合わせ処理を実装する」
    • たしかに。何も考えないと、ある時間内に終わることだけを前提に他のバッチを動かしたりしてしまうので重要そう
  • 「新規開発・修正をした直後のバッチ実行時には立ち会って実行ログや動作結果を確認する」
    • 極力利用者が少ない時間に実行したほうが良さそうと思っていてバッチを夜間に実行しがち
      • この場合何かあったときにすぐには対応できないので、日中できるものは日中にしたほうがいいいいのかもしれない
  • 「バッチの設定をアプリケーションと同じリポジトリで管理する」
    • アプリケーションとインフラのリポジトリが別れている場合、例にあるバッチ設定などはアプリケーションの環境変数にするなどで対応できそうな気がした
  • 「処理ごとにコンピュートリソース(CPU/メモリ/ストレージ)を選択できる」
    • コスト面、パフォーマンス面の最適化に繋がりそう

感想

日頃あまり意識できていなかったことを、抜粋させてもらいました。こういったルールがあると実装もレビューも効率化されて良さそうですね。勉強になりました。

Discussion