com4dc’s blog

Javaプログラマーのはずだけど運用してます

Release It! ~ 本番用ソフトウェア製品の設計とデプロイのために

2018年の12月に購入後、社内の読書会等々挟んでようやく読み終えた。

Release It! 本番用ソフトウェア製品の設計とデプロイのために

Release It! 本番用ソフトウェア製品の設計とデプロイのために

ここ3年ほどは、それなりの規模のシステムを開発後、そのまま運用を担当していたため、とても共感できる内容であった。 そのため頷くこと数千回。しかしながら、これも運用を経験していなければまた違った感想になっていただろう。

システムはリリース後からが本番であり、ビジネスの価値を生み出すのは運用フェーズに入ってから。しかしながら開発一辺倒だとこのあたりが実感しづらい。 さらに時間の経過によって、当初目標としていたビジネス的なゴールはすでに変化し、システムを取り巻く環境の変化に適用していかなければならない。

それは技術的な負債であり、ことなかれ主義でその場対応したいびつな対応、開発時には想定していなかった技術的な見落としなどが時間経過とともに重くのしかかってくる。このあたりは実際の業務で激しく実感していた箇所であり、頷きすぎて首がもげるかと思った。

安定性

様々なスケール可能なコンポーネントが寄せ集めたシステムとなっているため、あるコンポーネントの障害から自分自身を守るために、既存のシステム設計とは違った様々な工夫が必要。

  • サーキットブレーカー
  • レートリミット
  • インタフェースのみでやり取りを行う(マイクロサービス的なアプローチかと)

当然だろう、と思う人が多いのかもしれないが、意外とできるからなんでもいいじゃん、と運用を全く考慮しない密結合したコンポーネントを無意識に作り出す人はいそう。 障害が波及してドミノ倒しでシステムが死んでいくなど、あまり設計時から安定性という観点でうまく考えられる人がどれくらいいるのだろうかと感じた(これは自分自身もできているとは言い難い。)

ログ

アプリケーションログについては会社のブログにも書いたり、個人的に様々な記事や意見を見るものの、こうすればすべて解決と言えるほどの正解にたどり着けていない。ログは単に増やせばよいかというと、そうではなく、特にシステムが問題なく動作している時にはストレージの容量を圧迫する単なるゴミデータだ。そのため、とっておく必要性があまりない。

しかし、障害が発生した瞬間にログの価値が一変する。システムが過去に何らかの警告を上げていなかったか、平常時と比べておかしな処理がなかったかなどは、ログが出力されていないと何もわからない。そしてログもただ出力していればよいわけではない。分散システムが常識となった今、TraceIdやRequestIdといった、一連のRequestを串刺ししてFilterできる一意なIDが必要だ。これがなければ、ログをTraceすることは不可能である。

デプロイについて

システムのクリティカルなレベルが上がれば上がるほど、ダウンタイムは許されない。極力短くせねばならないため、運用する際にはアプリケーションのデプロイも様々な工夫が必要になる。 クラウドが前提となった今、インフラストラクチャの更新、アプリケーションのデプロイは以前とは比べ物にならないほど、回数が増えている。 そしてこれらを乗り越えられなければ、変化に適用することができず負債としてビジネスの要求に答えられない、つまり使い物にならないシステムになっていく。

デプロイについては最近会社のブログで書いたら炎上した。 まあ、この本に書かれていることとは直接関係はないのだが、クリティカルなシステムをダウンタイムなしでアプリケーション更新するには色々と考慮すべき点が多いよということを言いたかったのだが。

しかし、今担当している案件でも1ヶ月に1回ないし最低でも2ヶ月に1回はアプリケーションのデプロイ作業を行っている。そのため、アプリケーションデプロイは特別な作業ではなく、日常の運用作業の一部として認識している。

今後も定期的に読み返していきたい。

https://amzn.to/2YZ3wlI

読書中

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

Goならわかるシステムプログラミング

Goならわかるシステムプログラミング

未着手

全裸監督 村西とおる伝

全裸監督 村西とおる伝