최종 프로젝트 회고 (MSA 설계 배경)

웹 크롤링

웹크롤링은 Java-selenium 과 Jsoup을 이용하여 구현하였고 또 스프링 스케쥴러를 사용해서 원하는 시간마다 yes24 공연 예매 사이트를 확인하여 새로운 공연정보가 올라올때마다 크롤링을 해서 정보를 추출할수 있었다.

 

스케쥴러 사용법

1) 주기적으로 실행시킬 메서드에 @Scheduled 어노테이션을 붙임

@Scheduled(cron = "0 */2 * * * ?")
    public void createCrawling()

 

2) 스케쥴러를 사용하기위해 애플리케이션에 @EnableScheduling 어노테이션을 붙여줌

@EnableScheduling
@SpringBootApplication
public class CrawlingApplication {

	public static void main(String[] args) {
		SpringApplication.run(CrawlingApplication.class, args);
	}

}

 

크롤링 서버의 분리

그런데 문제가 발생했다. 성능이 좋은 컴퓨터인 로컬에서도 크롤링할때 상당한 부하가 가면서 cpu 사용률을 100% 찍게 되었다.

AWS EC2 프리티어로 크롤링을 했다간 서버가 다운될 정도로 부하가 걸렸고 실제로도 서버가 다운되는것이 확인되었다.

따라서 크롤링으로 인해 메인 서버에 가해지는 부하를 줄이기 위해 새로운 서버를 만들 필요성이 생겼고 이 서버는 프리티어보다 성능이 더 좋아야했다. 마침 멋쟁이 사자처럼 부트캠프에서 네이버 클라우드 플랫폼(NCP) 크레딧을 20만원 지원해주었기 때문에

 NCP에서 성능이 좋은 유료서버를 구할수가 있었고 이렇게 해서 크롤링 서버가 메인 서버로부터 처음으로 분리 되었다.

 

알람 서버의 분리

크롤링 서버를 분리하는데 성공하고 나서 그럼 메인 서버에 상당한 부하가 가는 비동기 알람기능도 분리할수 있지 않을까 생각이 들었고 크롤링 서버를 분리한것과 같은 방식으로 NCP에서 새로운 서버를 구했고 알람 서버도 분리하는데 성공하였다. 그다음 알람 서버와 메인 서버, 알람 서버와 크롤링 서버 간에 통신을 하기위해서 메세지 브로커 미들웨어인 RabbitMQ도 도입하게 되었다. 이렇게 과부하가 발생 할수있는 부분을 기능별로 나누어서 서버로 분리하여 메인 서버는 오직 메인 비지니스 로직만을 담당하도록 설계했다. 그렇게해서 총 3개의 서버로 분리되게 되었으며 아키텍처 구조는 다음 사진과 같다.

 

 MSA와 쿠버네티스

서버가 분리된것은 단순히 서버의 안정성 증가와 성능 향상이 된것 뿐만아니라 쿠버네티스의 도입도 가능하게 했다.

기능별로 서버를 분리했기 때문에 어떤 서버에 트래픽 과부하 발생시에 모든 서버를 증설하는것이 아니라 해당 서버만 증설하는 것이 가능해졌다. 마찬가지로 트래픽 감소시 모든 서버를 축소하는것이 아니라 해당 서버만 축소하는것이 가능해졌다. 다시 말해서 서버는 비용이 많이드는 자원이기 때문에 많은 서버를 유지하기 힘든 상황에서 한정된 서버들을 가지고 트래픽 변화에 따라 증설과 축소를 유연하게 하면서 최대한의 효율로 서버를 사용할수 있게 되었다. 이것을 자동화 하기위해 쿠버네티스를 사용하였고 새로운 아키텍처 구조도는 다음과 같다.

 

쿠버네티스로 증설된 서버를 그림으로 표현했다. 마지막으로 쿠버네티스을 사용했기때문에 무중단 배포(CI/CD) 또한 가능해졌다.

 

정리

맨 처음 크롤링의 부하로 부터 시작한 서버의 분리가 이렇게 쿠버네티스까지 사용하여 고도화하게 되었다. 그 중간중간에는 시스템 전체 구조를 확인해가면서 기능별로 분리하고 조립해보는 시간들이 필요했다. 그 과정들에서 시스템을 설계하는 능력과 큰 구조를 보는 시야를 기를수가 있었다. 끝나고 나서 보니 그때 그때 떠오르는 아이디어를 실제로 실행해 보았던 실행력이 전체 구조에 대해 큰 변화를 가져왔다고 생각이 들었다. 확실히 서버가 분리된 상태에서 통합테스트를 하기가 더 까다로웠지만 그만큼 결과적으로 더 좋은 성능을 얻게 되었다. 이번 프로젝트 고도화에 대한 성공은 내 개발 실력에 대해 큰 자신감을 가져와 주었던것 같다.