동기화 서버 개발자로서 구른지 어언 3년.
그 동안 우리 팀은 회사에서 서비스하는 대부분의 동기화 서비스를 담당했다.

수 억 명의 MAU의 요청을 받아내는 동기화 서비스 개발자로서.
나중에 내가 까먹지 않기 위해 동기화 서비스에서 사용했던 노하우들을 적어본다.

interface 관점에서

  • initial changepoint
    • 초기 동기화, 즉 처음부터 받아갈 수 있는 인터페이스를 정의한다.1
    • 우리는 보통 initial changepoint 값을 제공했다.
  • changepoint
    • 클라이언트는 해석할 수 없는 changepoint를 내려준다.
    • 어디까지 받았는지 어떤걸 받아야하는지, 받아 갈 때의 schema와 바뀌진 않았는지 등을 확인할 수 있다.
  • multiple api에 대한 partial error vs full error
    • partial은 성능에 좋지만 이슈 파악에 너무 안좋다
    • 에러가 그렇게 잦을건가? 아닐거다. 라는게 최근 우리의 결론.

code 관점에서

  • 누락없는 get의 관리
    • get의 기준점을 확인하자.
    • modifiedTime이 기준점이라면, 동일한 modifiedTime에 걸친 경우 누락이 생길 수 있는 구조인지 확인한다.
    • 누락이 없을 수 있도록 주의하기.
    • 웹과 다르게 한번 누락이 되면 초기 동기화를 하지 않는한 사용자 입장에선 영구 누락과 같게될 수 있다.
  • 여러 모듈 간의 중복 코드는 하나의 코드를 사용하도록 하자
    • 배치에서 was를 보든지 was의 코드와 같이 하나의 repository에서 관리하든지.
  • gdpr
    • 사용자의 데이터를 관리하는 eu의 법적인 요구사항. 동기화 서비스를 글로벌하게 한다면 필수적인 요소.
    • 서비스 로직의 domain을 그대로 사용하지 않으면 추후 서비스 변경에 따라 관리하기 복잡해진다.
    • hexagonal을 잘 정리한 뒤 도메인 로직은 동일하게 사용한다.

data 관점에서

  • 삭제한 데이터도 row가 남아서 삭제 동기화가 되어야 함 (단말엔 이미 받아져 있으므로, 웹과는 다르다)
    • 단말이 여러개라거나 하는 이슈로 row를 확실히 지울 수 있는 시점을 장담하기 어렵다.
  • 사용자 탈퇴 등으로 데이터가 보여지지 않아야 하는 경우를 위해 sequence(link)를 사용한다.
    • sequence를 올려서 데이터는 남아있지만 사용자가 볼 수 없게. 이 데이터는 배치로 삭제.
  • 실제 데이터의 row 삭제가 필요한 경우 마킹하고 배치로 삭제하자
    • 실제 삭제로 인한 딜레이가 크다.
    • 특히 container에 대한 삭제라면 container 안의 item을 삭제하는 시간까지 굉장하다.
    • 마치 cassandra mv가 delete 요청시 바로 삭제해서 성능 이슈가 생기는 것처럼 서버도 바로 삭제하지 않고 사용자에게 응답하고 나중에 삭제한다.
  • 삭제는 안전하게
    • 모든 서비스가 그렇겠지만 동기화에서는 더더욱이 사용자 데이터를 삭제할 땐 조심해야 한다.
    • 삭제 api가 들어온다면 “제 사진이 지워졌어요!” 같은 이슈를 쉽게 대응할 수 있도록 로그를 남겨야 하고.
    • 배치를 수행한다면 안전하게 지우고 가능하면 딜레이를 주는 것도 좋다.

service 관점에서

  • 단말의 로직에 downsync가 주도되기 때문에 단말 구현이 올바른지 파악이 필요함
    • 단말에서 dirty(수정사항) 체크가 잘 되고 있는지.
    • 단말에서 오구현을 할 경우를 찾기 위한 지표들을 셋업하자.
  • 정책을 결정하기
    • 우리 PM들은 세부 정책들을 결정해주지 않았다.
    • 사용자가 가질 수 있는 달력 일정의 개수라거나, 하루에 생성할 수 있는 item의 개수/사이즈라거나.
    • 인스타그램이나 구글 포토 같은 서비스들은 정책이 결정되어 있다. (일하기 좋겠다..)
    • 정책이 없는 경우, 이로 인한 문제점들을 보게된다. migration 시 비정상적인 item을 갖는 사용자, 기획된 의도와 완전히 다르게 사용하는 어뷰징 유저들.
  • 누구의 동기화인가
    • 누구의 동기화인지도 중요하다. 사용자 혼자 쓰는지. 아니면 누군가와 함께 사용하는지. 아니면 오픈된 동기화인지.
    • 동기화의 종류에 따라 서버에서 마킹하는 데이터가 달라진다. (생성자와 소유권의 관계, 사용량을 점유하는 사용자에 대한 정책들 등)