Spring Camp 2023 - 대규모 엔터프라이즈 시스템 개선 경험기 - 1부

https://www.youtube.com/watch?v=UwAoUshVpgM 

 

임형태 님의 발표를 요약해보고자 합니다.

 

 

흔히 발생할 수 있는 상황

 

장애, 코드리뷰등의 두려움을 매 순간 개발자가 극복해야 합니다.

유지보수성이 중요합니다.

이때 유지보수성이란 두려움, 주저함, 저항감 없이 코드를 변경할 수 있는 능력입니다.

 

 

전통적인 시스템의 높은 결합도

• 데이터베이스 공유
  • 무결성과 공유의 책임을 DB에 위임
  • 조직이 성장하여 특이점을 넘어서면 기술 부채가 급증됩니다.
  • 수정하기가 두려워서 유사한 필드, 유사한 칼럼이 추가되는 경우가 시그널이다.
• 행위 중복
  • 소스코드 1개 & API N개
  • 이메일 유효성 검사 1개, 이메일 입력 API 5개
  • 이러면 이메일 유효성 검사를 수정하면 API를 5개 검증해야 합니다.
  • 소스코드 공유 = 기술부채가 아닐 수 있다.

 

Refactoring vs Rewriting

더 이상 유지보수 되지 않는 개발 도구와 비즈니스 코드와의 결합도가 높았기 때문에 재작성을 선택하였다.

리팩토링을 위한 최소한의 테스트 작성과 실행 비용, 시간, 범위도 예측할 수 없었다.

새롭게 추상화된 구조와 모델이 필요했다.

 

단순함 != 쉽다

• OO, DDD 소프트웨어 설계에 일관성과 맥락을 부여한다
• 일관성 맥락은 추상화의 기본 재료
• 추상화로 얻은 모델은 주요 관심사이며 소프트웨어에 단숨함을 부여한다.
• 하지만 코드 한 줄을 뽑기 위해 체계적이고 논리적인 과정에서 하나씩 발견해나가야 한다.
  
  • 어떤 이유로 이렇게 해야 하는지 매일매일 이야기하고 단순하게 만들어나가야 한다.

 

Event와 인터페이스, 무결성과 Eventual Consistency

구현, 관리의 단순함과 무결성 강도 간의 트레이드오프가 있습니다.

이를 다양하고 풍부한 이벤트로 극복하여 무결성을 유지할 수 있습니다.

 

1. 레거시 시스템에서 두 번 쓰기

흔히 dual write라고 불리는데, 레거시 애플리케이션 와 FIG 애플리케이션 DB 둘다에 쓰기를 수행합니다.

이때 FIG 애플리케이션에는 API로 요청합니다.

 

2. 데이터 마이그레이션

마이그레이션은 반복될 수 있음을 고려해야 합니다.

시스템은 계속 발전될 수 있기 때문입니다.

 

클라이언트 API 새로운 요구사항 추가/수정이 발생하면 read만 하는 경우 Client를 FIG 애플리케이션에 요청하도록 합니다.

이때 CUD는 레거시 애플리케이션에서 수행합니다.

사유로는 레거시 DB에는 데이터가 100% 있지만, FIG DB에는 아직 데이터가 없을 수 있습니다.

 

현재는 READ에는 FIG로, WRITE는 레거시 애플리케이션에 요청을 수행합니다.

WRITE를 옮기지 않는 이유로는 나 말고 다른 사람도 이 테이블에 WRITE 할 수 있고, READ 할 수 있다는 것을 보장할 수 없다.

 

3. 발행 구독 패턴으로 레거시 DB 쓰기

레거시에서 발생하는 WRITE를 FIG 애플리케이션으로 옮기고 발행 구독 패턴으로 레거시 DB에 쓰기를 수행합니다.

이제 primary -> secondary의 형태가 변경됩니다.

 

하지만 이때 pub-sub 패턴을 쓰지 않으면 FIG에 레거시를 위한 기능이 추가됩니다.

Mirror라는 Consumer가 이제 레거시 DB에 write를 수행합니다.

 

Mirror의 책임은 레거시 시스템 데이터 무결성을 보장합니다.

레거시 애플리케이션 소멸 후에도 DB는 남아있을 수 있습니다.

 

낮은 결합도로 인지 과부하를 해결할 수 있습니다.

이제 레거시 DB 쓰기를 제거합니다.

 

하지만 이때 real-time과 near real time은 다릅니다.

 

4. 반복, 반복, 반복

Strangler Pattern처럼 무화과가 나무를 잡아먹는 것처럼 레거시를 말려 죽일 때까지 계속 반복합니다.

전체적인 리소스를 투여하지 않기 때문에 같이하는 동료분들과 더불어 품질과 끈기가 중요합니다.

개발팀으로서 서비스 성장에 높은 품질의 소프트웨어와 개발과정으로 기여하는 것을 중요한 책임으로 여긴다.

애플리케이션과 개발과정 품질을 개선하는데 필요한 기술과 자원은 팀 역량 안에서부터 실행한다!