인프런 아키텍처의 과거와 현재, 그리고 미래. - 이동욱
시즌 2
Fx 시리즈로 통일함.
하지만, Fx시리즈는 생소한 문법을 사용하고, 레퍼런스가 부족하다.
Form Validation Video와 같은 라이브러리들은 전부 React 기반이라 바닐라 JS로 구성된 인프랩 서비스에 적용하기 힘듦.
단일 프로젝트에 FE와 BE가 같이 있었는데, 모노레포로 구성하지도 못했다. 따라서 백엔드도 리로딩되어야해서 console.log만 추가하더라도 20초를 기다려야할 정도로 무거운 프로젝트로 구성되었다.
jQuery로 인해서 Component 구조로 개발이 불가능하였다.
문제점 : 심리적 안정감이 낮음, 높은 진입 장벽, 독립성(FE, BE가 독립적으로 실행 가능해야함.)
시즌 3
문제 해결
심리적 안정감을 높인 요소 : Class 및 Type, 테스트코드 및 정적분서, eslint 및 prettier
낮은 진입장벽 : 대중적인 기술스택을 선택함 (Ex, Layerd Arch, DI 도입)
독립성 : FE BE의 계층 분리, Api 명세 기반 개발, 분리된 저장소
어떻게 전환해??
| 빅뱅 | 점진적 개편(교살) |
|---|---|
| 서비스 개선을 멈춤 | 서비스 개선과 개편을 동일하게 진행함. |
대부분의 스타트업 대표는 서비스 개선을 멈추고 진행해야하는 이유를 모름.
백엔드는 신규 Repo를 만들고, 서비스를 분리함.
기존 코드는 Api Gateway로 사용.
시즌 4
데이터베이스 분리는 시즌 5에 진행하는 것으로 왜 why 레거시 개편이 이루어지지 않았기 때문.
100만 회원 서비스에서 DB, Redis, NoSQL, ES를 가지고 가는게 Best지만 쉽지않다.
기술의 가지수를 최소화, 가장 좋은 아키텍처/기술 보다는 2~3년을 버틸 수 있는 적정 기술을 선택.
따라서 ES와 Dynamo를 MongoDB Atlas로 검색엔진 Data Lake, 실시간 데이터처리를 한 번에 해결(Best는 아닌데 시간이 없기 때문에 최고의 답안은 아니지만, 적정한 답안을 선택하게됌).
SNS를 통해서 멀티 구독을 사용함. SQS를 이용해서 최종적 일관성 보장. Q) 중복은 어떻게 처리하는가?
Spring Boot를 통한 SQS 배압 조절(Back Pressure)
Zero Payload를 통해 이벤트 순서를 보장한다.
Node -> SNS로 이벤트 발행이 실패하면? 이벤트 저장소를 중간에 두면 해결이 되지만! 아ㅣㅋ텍처 복잡도가 너무 높아짐.
이 시즌에서는 에러 로그 발생하면 수동으로 재발행한다.
검색엔진이라는 추가 시스템 의존성이 생겼지만, 기존 서비스와 장애 격리된 구조로 변경함.
“위대한 글쓰기는 존재하지 않는다. 오직 위대한 고쳐 쓰기만 존재할 뿐.” - 엘윈 브룩스 화이트
아키텍처를 개선할 때 처음부터 Best로 가면 좋겠지만, 현실적인 여건, 사용자에게 지속적인 서비스 제공을 하기 위해서 어쩔 수 없이 빠르게 개발하고 개선하는 것이 좋다.
시로 질문 : 테스트코드를 작성하고 옮긴 것인가?
제가 현재 다니는 회사는 DB가 너무 크고 정규화되어있지 않아서 제약조건을 레거시 코드상에서 많이 가지고있어서 코드도 같이 더러워 지는 것 같은데, DB 리팩토링을 진행하기에는 너무 큰 규모다. 인프런에서는 어떻게 진행할 것인가?