5. 서비스 아키텍처 구성
간단한 아티클 조회 프로그램을 만들어 보았다. 의도한 대로 서비스는 제대로 동작한다. 이제 추가 / 수정 / 삭제 등의 나머지 기능을 구현할 차례이다.
이번 프로젝트는 서버 운영과 지속적, 무중단 배포를 연습하기 위해, 먼저 서비스 배포를 하고 추가 기능을 구현할 것이다. 그래서 서비스 아키텍처를 구성해 보았다.
1. 기본 서비스 아키텍처
AWS EC2가 기본적으로 제공하는 t2 인스턴스 한 대만 빌리고 톰캣 서비스 서버 또한 한 대만 돌아가는, 가장 기본적인 서비스 아키텍처이다.
사용자 요청 처리 최적화보다는, 배포가 문제없이 수행되는지, 톰캣 서버는 문제없이 작동하는지, 사용자의 요청을 처리할 수 있는지 등 기본적인 세팅 사항 동작 여부를 체크하는 용도로 아키텍처를 설계하였다. 하지만 t2 인스턴스 자체가 1vCPU, 1G 메모리라 하드웨어적 성능이 그닥 좋지 않으니 조금만 트래픽이 많아지더라도 서버가 죽어버릴 가능성이 높다. 따라서 APM을 사용해서 서버 성능을 측정한 뒤, 측정된 정보와 목표하는 트래픽을 고려하여 scale-out 정도를 결정할 것이다.
CI,CD 툴로 깃허브 액션, 젠킨스, 트래비스를 생각하였다. 젠킨스를 사용하기 위해선 aws 인스턴스 위에 젠킨스 깔고 또 젠킨스 서버 띄우는 비용 드는 작업을 수행해야 하므로 이번 프로젝트에서는 사용하지 않기로 했다. 트래비스와 깃허브 액션의 두 선택지 중에서, 나는 깃허브 액션을 택했다. 아무래도 혼자 진행하는 프로젝트다 보니, 간편하게 사용할 수 있는 깃허브 액션이 좀 더 끌렸다.
아티클 CRUD 기능 구현까지는 이 서비스 아키텍처를 사용할 것이다. 이후 사용자 기능을 추가할 땐, 스케일 아웃을 한 다음의 아키텍처를 사용할 것이다. 그 이유는, 복수의 서비스 서버에서 다양한 사용자 인증 방식을 테스트해보고 싶기 때문이다.
2. 로드 밸런서, 서비스 서버 추가
이 아키텍처의 의의는, '복수 서비스 서버에서의 사용자 인증 방식' 이다. 세션을 이용한 방식과 JWT를 이용한 방식 둘 다 사용할 것이며, 세션 이용 방식을 먼저 시도해 볼 것이다.
가장 먼저 각각 톰캣 서버 내에서 세션을 저장하면서, 스티키 세션과 세션 클러스터링 방식을 사용해 볼 것이다. 그 이후엔 Redis 세션 DB를 사용하는 방식 또한 할 것이며,
마지막으로는 JWT를 이용해볼 것이다.
정리하자면,
1. 톰캣 서버 내 세션 저장 - 스티키 세션 방식
2. 톰캣 서버 내 세션 저장 - 세션 클러스터링 방식
3. 세션을 Redis DB에 저장
4. JWT로 사용자 인증
3. 데이터베이스 Replication
마지막으로, MySQL DB를 마스터, 슬레이브로 나누어 DB가 갖는 부담을 줄이도록 아키텍처를 바꿔볼 것이다.
조회 기능은 slave DB에서 담당, CRD 기능은 Master DB에서 담당한다.
대략적인 아키텍처를 구성해 봤는데, 사실 확정적인 건 아니고 변경의 여지는 언제든지 있다.
도커 도입 또한 생각중이며, 데이터베이스 replication이 완료되면 ORM을 Mybatis에서 JPA로 바꿔볼 것이다.
열심히 하자.