1.0.7 (2024.02.04)

DOM 조작 방식 변경, 렌더링 성능 최적화, 리스트 가상화 도입, DB 캐시 구조 변경

Refactor

DOM 조작 방식 변경

• 문제
  • innerHTML을 사용하면서 아래 이슈가 발생함
    • XSS 취약점: 사용자 입력이 HTML로 직접 파싱되어 스크립트 실행 위험이 존재함
    • 불필요한 리렌더링: 텍스트 변경시 텍스트 전체 DOM을 재파싱하고 있음
• 해결
  • 브라우저 렌더링 파이프라인을 innerHTML에서 documentFragment로 변경
    • HTML 파싱 → DOM 트리 구성
      • innerHtml을 사용하게 되면 전체 DOM을 다시 파싱해 기존 DOM을 완전히 덮어쓰기 때문에 텍스트의 양이 많아질 경우 성능상 문제 발생
      • documentFragment를 사용할 경우 DOM을 가상 메모리 내에서 수정하고, 기존 DOM과 비교 후 필요한 부분만 갱신함
      • 이를 통해 전체 DOM이 다시 파싱되지 않으므로 불필요한 연산을 제거해 DOM 업데이트 횟수 감소
    • Layout 계산 → 리플로우 발생
      • DOM 트리의 모든 노드를 새로 계산하기 때문에 텍스트를 입력할때마다 리플로우 발생
      • documentFragment를 사용해 기존 DOM과 새로운 DOM을 비교해 차이가 있을때만 업데이트 하도록 수정
    • Paint → 리페인트 발생
      • 텍스트의 스타일이 적용되어 있을 때, 텍스트를 입력할때마다 리페인트 발생
      • documentFragment를 사용해 한 번의 페인트 작업만 수행하게 되어 불필요한 중간 렌더링 횟수를 줄임
• 과정
  • innerHTML 문자열을 생성하는 부분을 document.createDocumentFragment로 변경
  • 문자열의 span 태그, 텍스트 노드를 추가하는 방식을 fragment.appendChild를 사용하는 방식으로 변경
  • 기존 노드와 새로운 노드를 비교해 변경이 있을 때만 업데이트하도록 수정
• 결과
  • XSS 취약점 제거
  • DOM 파싱 및 빌드 비용 절감

렌더링 성능 최적화

• 문제
  • 페이지의 크기를 변경할 때, 페이지 내부 에디터 및 블록 모두가 리렌더링 되는 문제 발생
  • 이로인해 불필요한 리렌더링 및 리플로우가 발생함
• 해결
  • React memo, useMemo를 학습해 페이지 리사이징 중에는 에디터 및 블록이 리렌더링 되지 않도록 변경
  • 리플로우/리페인트 최적화 방법을 학습해 오버레이 스크린이 보일 때는 transform: scale(0) 속성을 통해 페이지 컴포넌트가 보이지 않도록 변경
  • 브라우저 성능 측정 도구를 분석해 Chrome react devtool 사용
    • profiler를 통해 렌더링 파이프라인을 분석해 렌더링에 걸리는 시간 측정
• 과정
  • 오버레이 스크린 도입을 통해 페이지 크기 변경시 페이지가 한번만 렌더링되도록 수정
  • 에디터, 블록을 React.memo를 통해 메모이제이션 적용
    • 이를 통해 텍스트 정보가 변하지 않을 경우 리렌더링 방지
• 결과
  • Render: 11.3ms → 4.9ms (약 56.6% 향상)
  • Layout effects: 1.3ms → 0.6ms (약 53.8% 향상)
  • Passive effects: 1ms → 0.6ms (약 40.0% 향상)
  • 총합: 13.6ms → 6.1ms (약 55.1% 향상)
• 추가 논의점
  • 스켈레톤UI는 사용자경험(UX)에 있어서는 좋지않다고 판단함
  • 추후 디바운싱 및 스로틀링을 통해 에디터와 블록의 width를 변경하도록 수정해 리플로우 횟수를 줄이면서 리사이징 중에도 문서 내용을 파악할 수 있도록 수정할 예정

리스트 가상화

• 문제
  • 페이지 크기를 조정할 때, 안보이는 블럭까지 모두 재렌더링됨
  • 이는 안보이는 블럭이 DOM 에는 존재하기 때문에, 페이지 크기(width)를 바꾸면 자식 요소인 블럭까지 재렌더링이 되는 문제로 파악됨
• 해결
  • 리스트 가상화 기법을 도입해 보이지 않는 블록을 DOM에서 제거하도록 수정
• 과정
  • 이분 탐색을 사용해 화면에 보여야 할 첫 번째 item 탐색
  • 스크롤 위치를 기반으로 화면에 보여야할 첫 번째 item, 마지막 item을 구하여 정적 높이 기반의 리스트 가상화 구현
  • 각 블럭의 높이가 동적으로 변하기 때문에 동적 높이를 지원하는 TanStack Virtual 라이브러리 도입
• 결과
  • 화면에 보이는 블럭들만 DOM에 존재하도록 수정

DB 캐시 구조 변경

• 문제
• Nocta는 문서 편집에 CRDT 알고리즘을 적용해 클라이언트가 문서를 편집하면, 해당 편집 내용은 CRDT 연산 단위로 서버와 다른 클라이언트에게 전송됨
• 이 과정에서 사용자가 문자를 입력할 때마다 연산이 매우 빈번하게 발생해 만약 모든 CRDT 연산을 DB에 즉시 반영한다면, 잦은 읽기/쓰기 때문에 DB 부하가 크게 증가함
• 이를 완화하기 위해 인메모리 캐시에 편집 내용을 모아뒀다가 일정 주기마다 한꺼번에 DB에 저장하는 방식을 도입해 DB 읽기/쓰기 비용을 줄였으나 다음 문제가 발생함
  • 메모리 사용량 증가: 전체 워크스페이스 데이터를 서버 메모리에 통째로 보관하다 보니, 서버 메모리 사용량이 불필요하게 커짐
  • 장애 시 데이터 손실: 서버 장애가 발생하면 캐시에만 존재하던(아직 DB에 동기화되지 않은) 변경 내역이 사라짐
  • 과거 기록 추적 어려움: 연산을 즉시 적용하다 보니, 어느 시점에서 어떤 연산이 있었는지 추적하기 어려움
• 해결
  • 워크스페이스 전체 데이터를 캐시하지 않고 클라이언트로부터 발생하는 CRDT 연산 단위만 별도로 캐싱하는 구조로 변경
  • 위 로직을 구현하기 위해 이벤트 소싱 패턴(Event Sourcing Pattern)을 도입. 이벤트 소싱 패턴은 다음과 같이 동작함
    • 이벤트 스토어에 연산 누적: 서버는 클라이언트가 보낸 CRDT 연산(이벤트)을 이벤트 스토어에 쌓음
    • 스냅샷 생성: 일정 주기마다 이벤트 스토어에 기록된 연산을 DB 스냅샷에 재생(Replay)하여 최신 상태를 DB에 저장함
    • 최신 상태 제공: 클라이언트가 최신 상태를 요청하면, 서버는 DB 스냅샷에 저장된 상태를 가져온 뒤 이후에 발생한 이벤트를 추가로 재생해 최신 정보를 제공
  • Nocta의 CRDT는 연산 기반이므로, 클라이언트가 문서를 편집하면 그 CRDT 연산을 이벤트로 보관함
  • 서버는 받은 연산을 이벤트 스토어에 저장하고, 동시에 다른 클라이언트에게 브로드캐스트함
  • 일정 주기로 이벤트를 재생하여 DB에 새로운 스냅샷을 저장함
• 과정
  • 클라이언트로부터 받은 연산을 인메모리 워크스페이스 데이터에 즉시 적용하는 로직을 제거하고 연산 자체를 이벤트 스토어에 저장하고 브로드캐스트하도록 수정
  • 일정 주기마다 이벤트 스토어에 쌓인 연산을 재생해 워크스페이스 상태를 업데이트(스냅샷 생성)하고 DB에 반영
  • 클라이언트가 특정 페이지를 요청하면 DB에 저장된 스냅샷과 이벤트 스토어에 적재된 연산을 조합해 최신 상태를 반환
• 결과
  • CRDT 연산을 이벤트로 저장하는 구조로 전환하면서 아래 이점 확보
    • 메모리 사용량 감소: 워크스페이스 전체 데이터를 메모리에 두지 않고, 연산만을 보관하기 때문에 메모리 부담이 크게 감소
    • 이력 추적 및 복구 용이: 이벤트가 순차적으로 기록되어 있으므로, 과거 변경 내역을 쉽게 재생 가능\
      • 이는 향후 버전 관리나 장애 복구 로직을 추가하기에 유리함
    • Redis 적용 시 효율성 증가(확장성): 추후 Redis 등 외부 캐시를 도입하더라도 전체 데이터가 아닌 연산만 저장하므로, 캐시 용량을 효율적으로 활용할 수 있음