Room DB를 통한 백업에 대한 고찰

유저가 최근 1시간 이내에 작성한 게시물들을 보여주고 빠르게 수정을 할 수 있도록 개선을 하는 과정을 생각하고 구현해보았다..

 

 

1. 해당 구조를 도입했을 때의 기대

유저 입장에서 최근 작성한 글을 서버에서 불러오는데는 어쩔 수 없이 지연 시간이 발생할 수 밖에 없다.

그러나 1시간 이내에 작성한 글을 서버로 보냄과 동시에 room db에 저장하여 백업을 한다면?

서버를 거치지 않고 내부 db에서 바로 꺼내쓸 수 있을 것이다. 그렇다면 유저 입장에서는 최근 작성 글을 빠르게 수정할 수 있는 경험을 가질 수 있을 것이다.

 

또한 1시간 이내에 작성한 글들을 명시적으로 보여줌으로써 본인의 글을 수시로 확인할 수 있게 하여 앱의 사용 시간을 늘릴 수 있을 것이다.

 

또한 수정이 완료된 이후에는 백업 데이터를 먼저 화면단에 뿌려 이미 게시글이 서버에 수정되어있는 것 처럼 유저에게 보여줄 것이다. 이후 접근에는 서버 데이터를 받을 것이지만.

 

이로 인해 느리게 업로드되는 이미지등의 유저 입장에서는 답답하다는 인식이 어느정도 해소될 것으로 기대한다.

또한 server key값을 복호화하는 연산 시간 또한 필요하기 때문에 실질적인 수정 시간은 길 수 있다. 그런 과정 또한 숨기는데 도움이 될 것이다.

 

이는 '인스타 그램의 전략'에서 영감을 얻은 방식이다.

 

2. 구조

서버에 올라갈 때와 최대한 동일한 구조의 room db를 구성한다.

다만, 수정 시에 필요 없는 부분은 column으로 만들지 않는다.

 

아래는 예시다.

primary key	server key	title	description
해당 백업 db의 고유성을 보장해주는 key	수정이 일어날 당시 서버에 추적할 수 있는 암호화된 key값	글의 제목	본문 내용

 

다만 server에 직접적으로 꽂히는 key값을 room db에 노출시키는 것은 보안적으로 위험할 수 있다.

다른 사용자가 악의적으로 해당 key값을 사용하여 게시글을 수정하는 등의 불상사를 방지하기 위해 roomdb에 저장될 당시에 여러가지 방식으로 한 번 숨겨야할 것이다.

 

3. 주의사항

1. 해당 백업 로직 작동이 성능 저하를 일으켜서는 안된다.

 

유저 입장에서는 최대한 해당 행위가 일어나는지 모르게 하는 것이 좋다.

즉 쓰레드의 관리 구조를 좀 더 주도면밀하게 구성해야할 것이다.

 

또한 데이터를 최소화 함으로써 데이터를 줄인다.

 

따라서 나는 최근 게시물을 1시간으로 설정하며 최대 10개의 게시물까지만 저장해두었다.

 

2. 쿼리 추적을 위한 key값의 암호화

 

서버와의 통신 및 쿼리 추적을 위한 key값의 암호화 로직을 주도면밀하게 짜야할 것 이다.

안드로이드 개발에서는 proguard를 통한 기본적인 난독화를 이뤄낼 수 있지만, 이는 db접근과의 연관성을 생각하면 큰 기대를 하지 않는 것이 좋을 수도 있을 것 같다. 따라서 안전장치를 위한 암호화 로직이 반드시 필요하다. 

 

암호화 - 복호화의 최소화를 위해 대칭 키 암호화 알고리즘에 대한 공부가 수반되어야 한다.

-> 그런데 생각해보면 progaurd를 통한 room db 난독화를 설정해주면 되는 것이 아닌가...?