caffeine-library/release-everything

[keyword] 1장 - 운영 환경의 현실

Closed this issue · 1 comments

주제

  • 대신 할 수 있는 만큼의 조치를 취하고 예방하면서, 정말 심각하고 예상치 못한 피해가 발생하더라도 전체 시스템이 복구될 수 있게 만들어야 한다.(p.35)

꼼꼼하게 설계하고 개발하여 장애가 안 생기는 것이 베스트지만, 누구나 실수를 할 수 있기 때문에 장애는 필연적으로 발생할 수 밖에 없다고 생각합니다. 이러한 장애 상황에 빠르게 대처하고, 후에 동일한 문제가 생기지 않도록 꾸준히 공부해야되겠다는 생각이 들게 해준 문구라서 기록해보았습니다.

  • 다른 기술을 사용하면 10배는 쉬울 일을 회사 표준을 따르느라 어쩔 수 없이 이를 악물고 코딩해야 했다면 상아탑 아키텍트에 희생된 것이다. (p.40)

단순히 구현에 급급한 코드로 방치해두고, 버전 마이그레이션, 리팩터링을 진행하지 않는다면? 위와 같은 문제가 발생할 수 있습니다. 마찬가지로 꾸준히 공부해야 함을 강조하기에 적합한 문구라 생각돼서 적어보았습니다.

연관 챕터

#1

서론

  • 기능 개발 완료 ≠ 운영 준비 완료
    • 개발 ≠ 기능 추가
    • 개발 ⊃ 기능 추가
    • 운영하기 버겁지 않도록 개발해야 함
  • 설계 대상
    • 해야 하는 것만 설계 X
    • 하지 말아야 하는 것도 설계 O
      • 시스템 장애/중단, 데이터 유실, 개인 정보 침해, 금전 손실, 회사 피해, 고객 피해 등
  • 테스트 통과가 본질적인 목표이면 안 된다 (테스트가 커버하지 못하는 영역)
    • 실제 유저 시나리오
    • 막대한 트래픽
    • 변조/어뷰징/바이러스 등 악의적 공격
  • 완벽한 방지는 없다
    • 피해 발생 시, 복구 가능한 설계

1.1 올바른 목표 설정

  • 테스트는 인공 영역이고, 실제 세계를 모두 반영하지 못한다
    • 비슷한 예시 : 90년대 초반의 자동차 설계
      • 현실과 동떨어진 설계
      • 쾌적한 개발 환경에서 잘 돌아가는 것 ≠ 다사다난한 운영 환경에서 잘 돌아가는 것
      • 테스트만으로는 향후 장애 예측 불가
  • 제조업에서 저비용 고품질의 제조 고려 설계(Design For Manufacturability)와 유사한
    운영 고려 설계(Design For Production)라는 개념을 책에서 다룰 예정
  • 개별 시스템이 아닌 상호 의존적인 시스템 전체를 설계해야 함

1.2 도전의 범위

  • 오늘날의 변화
    • 막대한 트래픽
    • 365일 24시간 멈추지 않는 가동시간에 대한 요구 사항
    • 시스템 공격 기술의 발전

1.3 여기도 백만 달러, 저기도 백만 달러

  • 데드라인으로 인해 운영 비용을 포기하고 개발 비용을 줄이는 결정
    • 개발 기간보다 운영 기간이 더 길기 때문에 장기적으로는 손해
    • 코앞의 ROI(=Return On Investment, 투자 대비 수익률)로는 CFO가 거절할지 몰라도
      향후 5년 간의 ROI를 제시하면 CFO가 흔쾌히 승인할 것
    • 이를 기술적 관점과 재무적 관점의 융합이라고 함

1.4 ‘포스’를 사용하라

  • 초기 단계에서의 의사 결정은
    가장 적은 정보량을 토대로 내려야 하나
    최종 모습에 가장 큰 영향을 끼친다는 모순
    → 초능력(포스) 필요
  • 애자일은 운영 환경에 최대한 빨리 배치하여
    현실에서 발생 가능한 문제를 미리 배울 수 있다는 면에서 긍정적
  • 두 가지 의사 결정에 대한
    구현 비용은 비슷하더라도 전체 생애 주기 비용은 극단적으로 다를 수 있어
    → 실제 예시를 다룰 예정

1.5 실용주의 아키텍처

  • 상아탑 아키텍처
    • High Level로 추상화 시키고 Low Level은 최적화하지 않음
    • 비효율적인 리소스 사용에도 표준만을 고수함
    • 시스템 완성 후 개선하지 않음
  • 실용주의 아키텍처
    • Low Level을 최적화함
    • 효율적인 리소스 사용을 위해 주저 않고 구조를 교체함
    • 시스템을 끊임 없이 개선함
  • 이 책은 실용주의 아키텍처에 관한 스킬들을 소개하는 책

마치며

  • 소프트웨어는 운영을 통해 가치를 전달함
  • 개발/테스트는 운영을 위한 사전 단계
  • 2장에서는 운영 시 안정성과 관련하여, 한 항공사 시스템의 버그를 예시로 살펴볼 예정

1장의 키워드는?

  • 운영