<aside> ✍️
기고: **@Suhyeoni** 기자, 마케터, 에디터, 데브렐로 끊임없이 변신하며 삶을 즐기고 있다.
</aside>
작은 새들이 거대한 고래를 밧줄로 들어 올리고 있는 예술가 이잉 루(Yiying Lu)의 작품 <꿈꾸는 사람을 끌어올리다>. 이 작품의 또 다른 이름은 'Fail Whale(실패 고래)'이다. 어쩌다 이 작품은 '트위터 장애'의 상징이 되고, 'Fail Whale'이라고까지 불리게 되었을까?
트위터는 모놀리식(Monolithic) 아키텍처로 개발되었었다. 모놀리식은 구조가 단순해 서비스 초기 개발 속도를 높이기에 유리했다. 그러나 2008년경 트위터가 단 1년 만에 1,382% 폭발적으로 성장하자 모놀리식은 한계를 드러내기 시작했다. 모놀리식은 하나의 거대한 코드베이스에 모든 기능이 묶여 있다. 트래픽 증가에 맞춰 특정 기능만 확장할 수 없어 비효율적이었고 막대한 비용이 뒤따랐다.
또 컴포넌트 간 결합도가 매우 높아 작은 버그나 성능 문제가 서비스 전체에 영향을 끼쳤다. 배포 시에도 전체 코드를 다시 빌드해야 해 빠른 대처가 어려웠고, 기술적 유연성도 부족해 성능 최적화에도 제약이 있었다.
2012년 트위터는 결국 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 전환했다. 성공의 대가로 수년간 고통스러운 재설계 작업을 치러야 했다. 트위터 장애의 상징이었던 Fail Whale도 로봇 이미지로 대체되며 역사에서 사라지게 되었다.
출처: https://www.ilyo.co.kr/?ac=article_view&entry_id=160933
<aside> 📖
트위터의 모놀리식 아키텍처 선택은 잘못된 결정이었을까? 아니면 성장 예측의 실패와 대응 실패가 문제였을까? 당신이라면 모놀리식과 마이크로서비스 아키텍처 중 무엇을 선택할 것인가? 또, 기술 부채는 어떻게 관리할 것이고 시스템은 언제 분리할 것인가? 그 이전에 팀은 어떻게 구성하고 기술 스택은 어떻게 선택할 것인가?
끊임없는 선택과 고민의 연속일 수밖에 없는 스타트업 서비스 설계
서비스 성격 파악부터 인력 구성, 기술 선택, MVP 개발과 출시, 기술 부채 관리에 이르는 서비스 생애 주기 전반에서 백엔드 개발자가 챙겨야 할 지점을 안내하는, 《스타트업 서비스 설계는 처음인데요》
| :kyobo_logo: 교보문고
</aside>