패스트캠퍼스 환급챌린지 3일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://fastcampus.info/4n8ztzq

 

 

안녕하세요 :)

오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 세번째 날입니다.

 

두번째 날에는 Monolithic, MSA, Hybrid 아키텍처에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.

 

 

오늘 학습할 내용의 제목은,

Part 1.프로젝트 개요와 목표 >  03. 은탄환은 없다. 트레이드 오프의 이해

입니다.

---

• 지난 시간에는 Monolithic, MSA, Hybrid 아키텍처에 대해 배웠고, 오늘은 트레이드 오프에 대해 배운 날이였습니다. 클립의 러닝 타임은 정말 짧았지만 꽤나 강렬한 인사이트를 얻을 수 있었습니다.

 

• 트레이드 오프
  
  • 1986년 프레드 브룩스 라는 분이 쓴 논문에 “은탄환은 없다(No Silver Bullet)” 라는 언급된 바가 있음
    • 소프트웨어 개발의 복잡성을 한 번에 해결할 수 있는 마법 같은 해결책(은탄환)은 존재하지 않는다” 라는 의미
    → 모든 것은 트레이드 오프
  • 간단히 RDB 로 예를 들면,
    • 테이블에 인덱스를 추가하면 조회 성능이 올라가지만, 데이터를 추가하고 업데이트 하는데 오버헤드가 생기면서 인덱스가 없을 때보다는 느려짐.
  • 자주 사용하는 캐시로 예를 들면,
    • 캐시 레이어를 통해 읽기 성능이 마찬가지로 올라가지만 DB 와 캐시 간의 데이터가 일시적으로 어긋나는 데이터 정합성 문제도 따라옴.
  • MSA 로 예를 들면,
    • 각 서비스가 독립적인 데이터 관리 책임을 가지면서 서비스의 독립성이 강화되고, 확장성을 확보하면서 개별 서비스 차원에서 데이터 일관성과 고립성을 얻을 수 있음.
    • 하지만 전체 시스템 관점에서는 데이터 일관성을 맞추기가 어려워지면서 강한 일반성을 잃게 됨.
    • 또, MSA 에서는 각 서비스가 네트워크로 통신하면서 독립성과 확장성이라는 장점을 얻음. 하지만 이와 동시에 통신이 실패할 수도 있는 가능성과 데이터 간의 순서 문제가 발생할 수 있음.
    • 네트워크 통신에 따른 오버헤드로 성능이 일부 저하되고 서비스 간의 데이터 흐름을 추적하는데 어려움이 생길 수도 있음.
  • 코드 레벨에서 살펴보면,
    • 비동기로 무언가를 처리하면 이번에도 성능을 얻을 수 있지만 코드의 복잡도와 디버깅 난이도도 같이 올라감.
    → 이런 식으로 무언가를 내가 얻어내면 무언가를 잃어버리는 것이 트레이드 오프라는 것을 배운 시간이였습니다. 앞으로는 코드 레벨에서도 인프라 레벨에서도 내가 하는 어떤 선택이 어떤 트레이드 오프를 하는지 이해하는 것이 중요하다는 것을 인지하고 개발을 해나갈 수 있도록 해야겠다는 생각이 들었습니다.