[릴리즈의 모든 것] 1장. 운영 환경의 현실

스터디 메인 페이지

목차

- ☆ 표시가 붙은 부분은 스터디 중 나온 얘기 혹은 제 개인적인 생각이나 제가 이해한대로 적어놓은 것으로, 책에 나오지 않는 내용입니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

- 모든 이미지의 출처는 Release의 모든 것(마이클 나이가드 지음) 책 입니다.

 

---

 

1장. 운영 환경의 현실

• 개발에는 단순히 모든 기능을 추가하는 것 외에도 훨씬 더 많은 작업이 포함된다. 운영 조직이 개발자의 도움 없이 몰려드는 대규모 현실 사용자를 상대할 수 있을까?
• 프로젝트 팀은 자주 운영 상황에서 발생할 문제대 대비하는 대신 QA부서의 테스트를 통과하는 것을 목표로 삼는다. 테스트 만으로는 충분하지 않다.
• 할 수 있는 만큼의 조치를 취하고 예방하면서, 정말 심각하고 예상치 못한 피해가 발생하더라도 전체 시스템이 복구될 수 있게 만들어야한다.
• 소프트웨어는 운영을 통해 가치를 전달한다.
• ☆ 개인적으로 첫인상을 별로인 것 같다. 내용은 괜찮은 것 같은데, 번역이 뭔가 이상하다고 느꼈다`. 1장이 문맥이 잘 안읽히는 느낌인게 꽤 있었다. 예를들어 37p에 나온 "소규모 워드프레스 웹 사이트에 적합한 설계는 트랜잭션을 보장하고, 분산되어 있으며, 대규모 시스템에서 터무니 없는 장애를 일으킨다." 보다는 "소규모 워드프레스 웹 사이트에 적합한 설계는 트랜잭션을 보장하고, 분산되어 있다. 하지만 대규모 시스템에서 터무니 없는 장애를 일으킬 수 있다." 가 훨씬 이해하기 쉬울 것 같다. 일반적으로 트랜잭션을 보장하고 분산되어 있는게 대규모 시스템일꺼라 예상되니 처음 읽을땐 "트랜잭션을 보장하며 분산되어 있는 대규모 시스템에서.."를 잘못 쓴게 아닌가 싶었다. 사실 근데 저걸로 이해하는게 더 문맥상 어울리지 않나 생각된다. 소규모 시스템이 왜 분산되어 있는지 잘 모르겠다.

 

올바른 목표 설정

• 며칠 또는 길어야 몇 주의 테스트만으로 향후 수년간 어떤 일이 일어날지 예측하는 건 불가능하다.
• 오늘날 우리의 상황 : 반쯤 만들다 만 상태로 성급하게 내보냈던 프로젝트 때문에 계속해서 지원 요청이 온다. 결국 새 시스템을 일정에 따라 만들지 못한다.
• 운영 고려 설계 (design for production)가 필요하다.

 

도전의 범위

• 오늘날엔 활성 사용자가 전체 대륙의 인구보다 더 많은 경우를 흔히 본다.
• 소규모 웹 사이트에 적합한 설계는 트랜 트랜잭션을 보장해야하고 분산되어야 하는 대규모 시스템에서 터무니 없는 장애를 일으킨다.

 

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

• 시스템은 개발 기간보다 운영 기간이 훨씬 길다. 한 번 지출되는 개발 비용을 줄이려고 반복적으로 지출되는 운영 비용을 발생시키는 일은 설득력이 없다.
• 어떤 시스템이 새로 배치될 때마다 5분씩 작동이 중단되어야 한다고 하고, 5년동안 매달 출시된다고 하자. 이 경우 분당 3천달러로 계산하면 총 300분 동안 백만 달러 정도 손해가 발생한다. 5만달러를 투자해 출시 때마다 서비스가 중지되지 않게 할 수 있다면 어떨까?

 

'포스'를 사용하라

• 초기에 내리는 결정은 시스템의 최종 모습에 가장 큰 영향을 미친다.
• 의사 결정이 내려지는 극초반이 가장 정보가 부족한 때라는 사실은 끔찍한 모순이다.
• ☆ 초기가 제일 중요한데 초기에 가장 정보가 부족하니, 스타워즈의 '포스'를 사용해야 한다는 말인가? 뭔가 비유같긴한데, 제목과 내용이 무슨 상관인지 이해가 안됨. 아시는분 댓글좀요 ㅠ

 

실용주의 아키텍처

• 상아탑 아키텍트 : 높은 수준의 추상화를 추구하여 플랫폼 간의 이식성이 높고 / 하드웨어, 네트워크, 전자, 광자 같은 복잡한 세부 요소와는 관련이 적다. 다른 기술을 사용하면 10배는 쉬울 일을 회사 표준을 따르느라 어쩔 수 없이 이를 악물고 코딩해야 했다면 상아탑 아키텍트에 희생된 것이다.
• 실용주의 아키텍트 : 코더와 어깨를 나란히 하고 그 자신이 코더이기도 하다. 추상화의 뚜껑을 열어 세부 사항을 들여다보거나 그것이 적합하지 않는다면 내던져버리기도 한다.