[IAteIt] 앱소개와 대망의 서버 이관 선언!!

IAteIt 로고

 

 

 

iOS 개발을 즐기는 사람들이 모여 만든 앱 "IAteIt"을 소개하며 앞으로 IAteIt이 발전하는 방향과 내용을 기술해보려 합니다.

 

 

 

 현재 "IAteIt"은 서버 리소스가 거의 없기에 Firebase의 Firestore 서비스를 DB 저장소로 이용하고 있습니다.

 

Firebase Firestore는 RDB(Relational Database)라기보단 우리가 컴퓨터에 파일을 정리하는 것과 유사하게 데이터를 저장합니다.

마치 폴더 안에 파일을 저장하고 또 다시 폴더를 저장할 수 있는 형태죠. 이를 곧 NoSQL 데이터 베이스 라고 부릅니다.

 

 이런 성격덕에 간편한 서비스를 구축하는데에는 저장한 path만 있으면 되기에 둘도 없이 좋고 접근성이 좋은데요, 서비스에 살이 붙기 시작하면 그 path들의 의존관계가 복잡해지고 데이터를 기다리기 위한 시간이 증가하기 시작합니다.

 

 

 

위와 같은 이유로 크게 2가지가 있는데 아래의 실예시에서 확인해보겠습니다.

 

 

 앱 사용자인 User가 있습니다. 해당 User는 글을 작성할 수 있고, 작성한 User를 포함한 다른 모든 User는 글에 댓글을 달 수 있다고 생각해봅시다.

 

Firebase의 Firestore의 경우, NoSQL로 마치 폴더의 계층구조로 파일이 저장되는 것과 유사하게 데이터를 저장하고 탐색하는데요, 

여기서의 폴더와 파일은 각각 Firestore에서는 collection, document 에 대응하는 단어입니다.

 

기존의 저장방식에서는 사용자가 업로드한 데이터가 혹여라도 변경되지 않아야 하기 때문에 각각의 User, Post(글), Comment(댓글) collection으로 나뉘어 있습니다.

 

 하지만 이렇게 나뉘어 저장하다보면 쿼리가 복수로 나가야 하는 비즈니스 로직, 예를 들어 사용자가 글을 삭제할때, 글에 속해 있는 댓글도 함께 삭제 해줘야 하는데요. RDB를 사용했다면, 외래키로 데이터들을 찾아 지워나가면 되는 것을 NoSQL에서는 각 데이터가 가지고 있는 path만이 유일한 연관관계이므로 그 복잡성이 증가하게 됩니다.

 

여기서 나온 첫번째 문제로.

 

문제점 1. Firestore의 NoSQL 데이터베이스 저장방식은 RDB에서 사용하는 외래키(Foreign Key)를 사용한 방식이 아니기 때문에 파일 읽는 비용이 굉장히 증가합니다. 모든 파일의 내용 전부를 스캔하는 경우가 많고(GET과 같은 조회 쿼리), 외래키의 역할을 하는 path의 복잡성이 증가하기 때문입니다. 

 

 문제점1 의 문제 중 파일 읽기 비용의 증가를 막기 위해서

저희 팀은 일부 메인 비즈니스에서 떨어진 collection들은 bulk로 데이터를 저장하고 있습니다.

 

bulk로 저장하고 있다는 것의 의미는 복수의 쿼리가 나가지 않게 하나의 파일에 많은 정보를 포함하고 있는 것입니다.

이는 파일 읽기 비용을 줄이는 데에는 효과가 있을 수 있지만 단점도 존재합니다.

 

문제점 2.  Bulk로 저장하는 방식은 데이터의 무결성에 안좋은 영향을 미치게 됩니다.

 

 단일로 존재해야 하는 데이터에 필드가 추가되고 변경이 이루어 진다면, 이미 사용자가 사용할때에는 내가 처음에 저장해둔 정보가 아닌 추가로 쿼리에 도움이 될법한 값들을 가지고 있는 더러워진 객체(dirty)가 되는 것이지요. 

 

 

 이러한 문제들에 대한 팀원들과의 회의로, "IAteIt" 의 서버를 Firebase Firestore의 의존성에서 벗어나 직접 서버를 구축하기로 결정했습니다!!!

 

짞짞짞짞짞!!!!!!🙌

 

 

 우선적으로 Firebase를 DB + 서버 의 개념으로 사용하던 데에서 벗어나 둘을 분리하는 것을 큰 이점이라 생각했습니다. 이전에는 DB와 서버의 분리가 아니라 혼재되어 있는 느낌이었는데 레이어를 나누니 깔끔해지고, 배포에도 도움을 줄 것 같습니다. 

 

 또한 직접 서버를 구축해 RDB의 장점을 살려 테이블을 나누고 외래키를 사용해 데이터를 가져오고 저장하는 방식으로 위에서 일어나고 있던 상당의 문제점을 해소할 수 있을 것이라 생각이 듭니다. 더불어 페이지 분할(Pagination)과 유사한 동적인 쿼리를 자유롭게 사용할 수 있는 장점이 있다고 생각이 들어 이와 같이 결정하게 되었습니다. (사용자도 처음보다 많이 늘었구요..)

 

 

물론 지금까지 저장되어 있는 데이터들을 이관하는 등의 쉽지 않아보이는 작업이 예상되지만,,

이 앱을 개발하는 것이 재밌기 때문에 즐기며 백로그를 채우고 있습니다.

 

 

 

 사실 ㅎㅎ 벌써 마주친 어려움이 많은데요, 앞으로도 많을 것이라 생각이 듭니다. 

이런 저희 앱의 실서버 이관 과정을 블로그에 계속 작성해볼 생각이니, 많이 봐주시고 실제 사용도 해봐주시면 감사하겠습니다!!

 

 

다음글 스포를 해보자면,,ㅎ

""Session과 Jwt 토큰" 사용자 인증하는 법으로 어느 것을 선택할까?" 가 그 첫번째 주제입니다.

 

앞으로의 좌충우돌 및 고민되었던 지점들은 앞으로 올라올 글들에서 정리해 작성해보도록 하겠습니다!!

 

 

 

"IAteIt" 은 현재 앱스토어에서 만나보실 수 있습니다!! 많은 관심 부탁드려요~~~~~~

 

https://apps.apple.com/kr/app/i-ate-it/id6456377313

‎I ate it.