본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 23일차!
오늘은 커뮤니티 피드 서비스의 확장성을 위한 시스템 재설계 계획을 짜고, 인수 테스트의 개념에 대한 학습을 진행하였다.
먼저, 기준으로 할 수치를 설정하였다.
X(구 트위터) 기준
- 유저: 3억 5천만명
- 글 작성: 초당 4,600회, 피크타임: 12,000회
- 타임라인 조회: 초당 30만회
- 유저당 평균 팔로워 수: 75명
이라고 한다. 상상도 못해 본 어마어마한 크기이다.
이번 커뮤니티 피드 서비스에서는 (유저, 팔로워 수 제외) X의 1/10 수준으로 수치를 설정한다.
저번에 만들었던 user_post_queue 테이블은 id, author_id, post_id, user_id 이렇게 총 4개의 필드를 가지고 있다.
id 하나당 8바이트로 본다면 데이터 한 건당 총 32바이트, 타임라인 정보는 일별 약 12억건 생성되기 때문에 32byte * 12억 = 약 35.8GB가 된다.
이러한 구조는 초당 30만회의 조회를 감당하기 어려울 것이다.
그렇기 때문에 피드 데이터 구조를 변경하고, 캐싱을 도입하여 서비스를 리팩토링하기로 하였다.
이렇게 데이터 구조와 방법이 바뀌었을 때는 인수 테스트를 작성하여 검증함으로써 안정성을 확보할 수 있다.
인수 테스트란 사용자 관점에서 요구사항을 만족하는지 검증하는, 최종 단계의 검증을 말한다.
장점
- 단위 테스트에서 검증할 수 없던 것들을 검증할 수 있음
- 실제 유저들의 목표 달성을 테스트하기 때문에 애플리케이션의 퀄리티가 향상된다
- 애플리케이션 전체 동작을 테스트로 표현 -> 문서화 효과
- 생산성이 좋아짐 (기존에는 postman으로 일일이 요청을 보내고 데이터를 확인하면서 기능이 제대로 동작하는지 확인하였음)
이전에 기능을 구현하며 작성했던 단위 테스트와 비교해보면 이러한 차이가 있다.
인수 테스트
- 범위 및 주요 사항: 유저 관점에서의 전체 애플리케이션 기능
- 목적: 비즈니스 및 유저의 요구사항 만족
- 단위: API
단위 테스트
- 범위 및 주요 사항: 분리된 작은 단위의 소프트웨어의 기능
- 목적: 하나의 기능이 정확하게 동작하는지 확인
- 단위: 메소드
Rest-assured: Java Rest API 확인을 위한 라이브러리로, 이 라이브러리를 사용하여 인수 테스트 템플릿을 작성하면 테스트 코드 유지보수가 편리해진다.
강사님께서 내주신 과제에 대해 생각을 해보았다.
실제 사용자 관점에서 요구사항을 만족하기 위함이면, fake/h2 같은 테스트 환경 vs 실제 api 연동이나 mysql 연동 중 어느 방법으로 해야 할까?
-> h2와 같은 테스트 환경으로 테스트를 진행한다면 실제 사용하는 mysql 등의 상용 환경과의 차이점 때문에 추후 문제가 발생할 수 있을 것 같다. 아무래도 h2 같은 임베디드 DB가 가볍긴 하겠지만, 사용자 관점에서 확인하는 테스트인 만큼 환경을 최대한 맞춰서 진행하는 게 좋지 않을까 싶은 생각이 든다! (어디까지나 나의 생각이기 때문에 아닐수도 있지만...ㅎㅎ)