6️⃣ [12.12] Week6 Day1 발표 내용 정리

프로젝트에서 어떤 기술적인 경험을 했는가?

프로젝트 과정에서 어떤 문제 상황을 겪었고, 어떤 방법으로 해결했는가

CRDT 구현하면서 나왔던 구현적인 고민도 좋지만 CRDT 그 자체에 대한 문제 상황과 우리는 어떻게 그걸 도전했는가 쪽으로 풀어가도 좋을듯요, 한정된 시간, 부족한 인원, 어려운 기술에 대해 도전해야 할 때 겪은 어려움

파트 1에서 문제상황 → 해결방법

파트 2에서 문제상황 → 해결방법

문제 상황

• 근데 제가 생각했던 것처럼 그냥 CRDT 도전하면서 생긴 어려움이나 그런거 이야기 할때에는 여기에 맞추지 않아도 되지 않나

해결 방법

프로젝트 과정에서 어떤 문제 상황을 겪었고, 어떤 방법으로 해결했는가.

• 기술적인 어려움 (구현적인 어려움)

• 프로젝트 소개

  • 팀원 소개 (1문장)
  • 프로젝트 주제 (Codocs)
    • 시각적인 자료

• CRDT 구현이 왜 필요했는지 설명 ( 방금거 빼고 그냥 무슨 내용 들어갈 건지를 구체적으로 좀 적어야 될 것 같아용! ) 방금도 이제 이거 들어갈것같다 하고 결국에 한줄로 끝이었잖아요. 그러니까 좀 더 고민해서 뭐 들어갈지를 생각했으면 좋겠다~람쥐! (제일 중요한 파트 같아서) ⇒ 여기서 대충 넘어가면 뒷 내용 다 이해 안될 가능성 높음

  • 실시간 공동 편집시 conflict 해결을 위해서 OT와 CRDT 방법이 있다.

    • 중앙 집중적인 OT 대신 서버에 부담을 덜어줄 수 있는 CRDT 를 선택했습니다. OT 에 대한 설명을 하면 너무 길어지니까 줄이겠습니다.
    • 이 자리는 기술적인 경험을 공유하는 자리이니만큼 CRDT 를 구현하면서 겪었던 문제점을 위주로 설명드리겠습니다.

  • CRDT 는 뭐다~ ( 진짜 쉽게 ) ( 30초~ 1분 )

    • 고유성 ( 인덱스 ), 교환법칙이

      ⇒ 핵심은 CRDT 를 이해시킨다기 보다

      왜 우리가 고유한 인덱스에 집착할 수 밖에 없었는지 인덱스의 중요성만 주입시키고 넘어가면 될 것 같아서 짧게 하면 되지 않을까~? 했어요

    • CRDT 알고리즘(알고리즘 아니고 데이터타입임)의 핵심은 각 유저가 입력한 글자가 교환법칙이 성립하는 고유한 인덱스를 가지도록 하여 모두가 글자들을 같은 순서로 정렬할 수 있어야 한다는 것입니다.

    • 제일 중요한건 우리는 알고 있는데 어짜피 / 그 듣는 사람도 대충 이해는 할수있어야 한다~

    • 일단 만들고 잘 읽히냐고 물어보는 것도 좋을 듯

• 문제 상황 - 해결 ( CRDT를 어떻게 만들었는가 발전과정 )

1. 고유성 보장

   1. 1차 ( 실수, 비교 불가 )

   2. 2차 ( 추상 자료형, 개느림 ) ⇒ (둘이 합쳐서)

      • 앞서 말씀드린 것처럼 CRDT 의 고유성을 어떻게 구현할 것인지에 집중했습니다. ⇒ 실수 자료형 구현 방식 설명

      • 근데 오류가 발생 ( 부동소수점 오류 )

      • 추상 자료형의 탄생

      • 이 버전은 글자 사이에 글자를 입력할 때마다 실수의 자리수가 늘어나는 성능적인 결함이 존재

        ⇒ 늘어난 인덱스 때문에 소켓으로 전달하는 데이터 크기의 증가 + 인덱스를 비교하는 연산에 의한 실행 시간 증가

   3. 3차 결과 ( WOOT ) ⇒ 벤치마크

      • 이 문제를 해결하기 위해 CRDT를 기반으로 한 공동 편집 알고리즘을 참고하기로 결정

        ⇒ WOOT

      • WOOT에서는 실수 인덱스 사용하지 않고 UUID 기반으로 양 옆 노드를 기반으로 삽입됨

      • 또한 기존 배열은 삽입할 때 시간 복잡도가 많이 발생함

        • 무조건 배열이든 연결리스트든 선형 탐색을 해야된다. ⇒ 배열이여도 인덱스로 접근이 불가능하다

      • 그래서 연결리스트로 바꿈

        • 굿 빨라짐

          ⇒ 기존에 있었던 인덱스 비교 연산 안해도 되고 + 인덱스 길이가 일정하기 때문에 글자가 늘어나도 데이터 크기가 일정함

   4. 결과 확인을 위해 벤치마크 스크립트 작성

      • 벤치마크 결과 빨라짐 ㅎㅎ
      • 패킷 사이즈도 Stable 해짐 ㅋㅋ

2. 다만들었는데 이제 실시간성 보장하기 위해서는 뭘 더 노력했는가?

   1. 자동 저장
      • 자기 팀에서는 혼자쓰는 에디터에서는 자동저장을 몇 초마다 저장한다 → 이게 실시간이 되면 저장을 바로바로 안해주면 중간에 누가 들어왔을 때 저장 안된 문서를 받아서 싱크가 안맞을 수 있다
      • 이래서 대충 만들수가 없었다
      • 어떻게 해야할까? ⇒ 이래서 그냥 모든 입력 오퍼레이션을 저장할 수 밖에 없었다.
      • 근데 이러니깐 DB I/O가 너무 잦은 문제가 발생!!
      • 레디스를 쓰자~

   b. 디바운싱 ⇒ 커서 디바운싱

   • 커서를 왜 디바운싱 해야 하는가?

     • 그냥 커서만 디바운싱 하면 어색하지 않냐
       • 사용자들이 실시간으로 같이 편집하고 있다는 느낌을 주기 위해서 커서 위치를 공유하게 했는데
       • 렌더링 성능을 개선할 수 있을 것으로 생각해 적용했다.
         • 실제로 235ms ⇒ 70ms 으로 렌더링 시간을 줄였다. ( ㅁ을 한줄로 쭉~~~ 입력했을때 )
         • 쭉 입력했을때 렌더링 성능을 측정해보았습니다.
       • 한글 입력시에 의미없는 이벤트가 발생하는데, 주기를 아주 짧게 주고 디바운싱하면 사용성을 크게 해치지 않고 이걸 막을 수 있다
       • 실시간성 보장을 위해서 (실제로 가장 중요한건 문서 입력 이벤트인데, 소켓 이벤트가 동시에 너무 다발적으로 발생하면 영향을 끼칠 수 있다) 소켓 이벤트 발생 빈도를 줄였다.

   • 렌더링이 너무 잦게 발생해서

     • cursorActivity라는 이벤트가 입력할떄도 발생하거든요?
     • 근데 이게 한글이면 아마 기존거 지울떄도 똑같은 커서 위치로 이벤트 재발생할거같은데
     • 안 ⇒ ㅇ 아 안 ⇒ 3번 날아갈거같음, cursorActivity라는 이벤트를 쏘는데 (같은 위치로 3번 발사) ⇒ 디바운싱이 될 수 있다

   • 커서 디바운싱으로 위치를 늦게 보내주도록 함

     • 결과물 → 렌더링

   • 주기를 잘 해주면 그렇게 어색하지 않게 하면서 렌더링을 빠르게 할 수 잇음

   의미가 있는거는 굉장히 빠른 주기로 발생하는 의미없는 이벤트를 차단

   c .무중단 배포

   1. 프로그램을 업데이트하는 도중에 사용자가 접속한다면?? 이라는 상황
      1. 누군가 문서 작성하고 있는 도중에 배포하면? 이 더 좋을듯
   2. 블루-그린 무중단 배포로 해결 ^_^
      1. 끊김없는 실시간 공동 편집~
   • 저장도 그렇고 소켓도 그렇고 중앙 서버에 의존하는 상황
   • 근데 사용자가 프로그램을 사용하고 있는 도중에 새로운 기능을 배포한다면??
   • 그 중간 사이에 서버가 끊어져서 실시간 문서 편집에 문제가 생길 수 있다
   • 이걸 막고, 사용자의 실시간성을 보장하기 위해 무중단 배포 도입~

• 못해본게 너무 많아서 아쉬웟다

• CRDT 구조 개선 - 트리 구조 적용

• 저장 방식을 오퍼레이션 큐를 통한 스냅샷 생성 방식으로 개선

• CRDT Rust로 포팅, 웹 어셈블리 적용

• 코드 컴파일 기능 지원

• 에디터 CodeMirror5 ⇒ CodeMirror6로 마이그레이션

• 편집 권한 기능 추가

• 일렉트론을 사용하여 데스크탑 앱 버전 배포

• 구현한 CRDT 모델을 NPM에 라이브러리로 배포

프로젝트 아이디어 회의 중에 나온 내용들…

한 번쯤 해보고 싶었던 기능들…

지속적인 개발

Codocs 는 계속된다

일주일마다 스터디를 하면서 지속적으로..

많관부

라고 할뻔 ㅋㅋ

• 감사합니다 땡큐

---