1. CS 리팩토링 계획

🏃‍♂️ 전체 계획

E2E 크로스 브라우징 및 유저 과부하 테스트 최적화

• 문제 :
  • 성능 개선을 해야하지만, 수치적 기준이 없는 문제
  • 크로스 브라우징(사파리, 파이어폭스, 익스플로러)별 테스트를 진행하지 않은 문제
  • page 및 workspace의 동시접속 부하 테스트를 진행하지 않은 문제
• 원인 :
  • E2E 테스트 툴 미숙지
  • 부하 테스트를 진행하지 않아 개선을 진행하지 못함
• 해결 : 테스트 코드 및 Playwright 등을 이용하여 과부하 테스트 진행
  • 1개의 workspace에서 10개 page, 사용자 10명 동시입력 측정
  • 1개의 workspace에서 100개의 page, 사용자 100명 동시입력 측정
  • 10개의 workspace에서 100개의 page, 사용자 100명 동시입력 측정
• 주의할 점 : 반드시 측정한 수치를 숫자로 나타낼 것, 이를 개선하기 위한 방법을 기록하고 실천할 것

리스트 가상화

• 문제 : 화면에 보이지 않는 블럭까지 렌더링이 일어남
• 원인 : 보이지 않는 블럭도 DOM에 존재했기에 재렌더링이 일어남을 확인
• 해결 : 리스트 가상화를 도입해 화면에 보이는 블럭만 DOM에 존재하도록 수정
• 주의할 점 : 반드시 before, after를 나타낼 수 있는 수치를 기록할 것

Caret 동일 블럭 입력 처리

• 문제 :
  • 동일한 블럭에 입력했을때 caret이 이상한 곳으로 이동하는 문제
  • 한글 컴포징중일때 컴포징 이벤트가 종료되는 문제
• 원인 :
  • 원격 연산이 발생했을 때 블록이 리렌더링 되어 캐럿의 위치가 초기화됨
  • 블록이 리렌더링되면서 컴포징 이벤트가 종료됨. 이로 인해 컴포징중이던 글자가 그대로 입력됨
• 해결 :
  • 캐럿 관리 로직 개선을 통해 원격연산을 통한 리렌더링이 발생해도 캐럿의 위치를 정확하게 위치시키도록 수정
  • 한글 컴포징중일 경우 원격 연산에 의한 리렌더링을 막고 별도의 버퍼에 연산을 저장해 두고 컴포징이 완료되면 해당 연산을 적용하는 방식 적용
  • 주의할 점 :
    • 반드시 동일 블럭 캐럿이 정상적으로 관리 안될때와 관리 될때의 영상을 기록할 것
    • 구체적으로 어떤 방식들을 시도했는지 기록할 것

프론트엔드 성능 최적화

• 문제 : 불필요한 리렌더링이 발생하여 DOM에 부하 발생
• 원인 : remote 수신시 페이지 내부 컴포넌트가 전부다 리렌더링 됨 + 부모인 페이지 사이즈를 줄임에 따라, 자식인 블럭까지 리렌더링 됨
• 해결 :
  • 클릭on을 시작으로 클릭off일때 resize 일어나게 수정
  • 클릭on, 클릭off 사이에 스켈레톤 UI를 추가
  • 디바운싱/쓰로틀링 도입하여 DOM 부하 감소
• 주의할 점 : 반드시 before, after를 나타낼 수 있는 수치를 기록할 것

CRDT 네트워크 성능 모니터링

• 문제 : 백엔드 로직 상에서 어떤 부분을 어떻게 최적화해야 할 지 감을 잡을 수 없음
• 원인 : 정확한 서버 모니터링 수단 부재
• 해결 :
  • 서버 네트워크 모니터링 시스템 구축
  • CRDT 로직에 맞는 성능 측정 기준 확립

Tombstone 처리 추가

• 문제 : CRDT는 순서에 상관없이 입력이 되어야 하는데 순서에 영향을 받는 문제
• 원인 : LinkedList내의 nodeMap에서 Node를 삭제 해버려서 Node가 존재하지 않을 경우 에러가 발생
• 해결 :
  • Tombstone을 처리하여 nodeMap에서 delete 하지말고 flag 방식을 도입
    • 이에 따른 디버깅 및 캐럿 관리와 block의 string 처리가 필수
• 주의할 점 : 반드시 이전에 일어났던 버그가 현재는 일어나지 않음을 기록할 것

DB 안정성 보장

• 문제 :
  • 서버가 의도치 않게 닫히면 데이터가 날아가는 문제
• 원인 :
  • 서버는 변경 사항을 인메모리로 갖고 있다가 DB에 데이터를 주기적으로 업데이트하는데, 서버가 닫히면 업데이트하기 전의 변경 사항이 사라짐
  • 하나의 서버로 동작해 별도의 안전 장치나 백업 수단 없음
• 해결 :
  • DB 업데이트 주기 변경
  • 다중 서버? ← 비용 문제, 인프라적 요소를 최대한 배제하고 백엔드적으로 해결할 수 있을까?

Redis 마이그레이션

• 문제 : 서버 인스턴스를 class로 관리하고있음
• 원인 : redis로 관리하면 더 효율적일 것이라는 의견을 제시받음, redis의 장점을 활용
• 해결 :
  • 인메모리를 Redis로 마이그레이션하기
  • Redis의 메모리 관리 기능 활용
• 주의할 점 :
  • 반드시 class로 쓸때와 redis를 쓸때를 비교할만한 수치를 기록할 것
  • Redis를 쓸때 더 좋다면, 왜 Redis를 쓸때 더 좋은지(메모리 저장 관리 방식)를 기록
  • socket 통신 주고 받는것, 직렬화, mongoDB등의 저장 방식등의 도구로 측정하여 기록 必