[부하 테스트] 트래픽 증가에 따른 시스템 설계 및 확장

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.

---

• 부하 테스트를 하면서 목표로 설정해놓은 Throughput, Latency를 달성하기 위해 성능 개선을 해야 한다.
• 병목 지점이 어디서 발생하느냐에 따라 성능 개선의 방법이 달라진다. 

 

병목 지점에 따른 성능 개선

EC2(WAS)가 병목 지점일 경우

1. 애플리케이션 로직에서 비효율적인 부분 개선
2. 정적 파일 서버(S3, Cloudfront) 분리
3. 로드밸런서(ELB)를 활용해 수평적 확장
4. 수직적 확장

 

RDS(데이터베이스 서버)가 병목 지점일 경우

1. 비효율적인 쿼리 개선 (인덱스 활용, SQL문 튜닝, 역정규화 등)
2. 수직적 확장
3. 읽기 전용 데이터베이스(Read Replica) 도입
4. 캐시 서버 도입

주의
위 순서가 절대적인것은 아니다. 일반적으로 이런 순서를 지키는 것이 좋다는 것이다.

 

 

트래픽 증가에 따른 시스템 확장

모놀로식 아키텍쳐

• EC2 서버 한 대에 프론트엔드, 백엔드, 데이터베이스에 관련된 프로그램을 다 실행시키는 형태의 구성
• 이 형태의 장점은 하나의 서버에서 모든 리소스를 관리하기 때문에 관리 및 조작하기가 심플하다. 또한 다양한 리소스를 쓰지 않기 때문에 비용이 적게 나오는 편이다.
• 하지만 위의 구성으로 실제 서비스를 운영하다보면 데이터베이스가 생각보다 많은 컴퓨팅 자원(CPU, 메모리, 디스크)을 사용한다. 데이터베이스로 인해 웹 애플리케이션의 성능에 악영향을 줄 수 있기 때문에 별도의 서버를 분리하는 형식을 많이 가져간다.

 

데이터베이스 분리

• WAS와 데이터베이스를 분리한 인프라 구성
• 위 인프라 구성에서 트래픽이 많아지면 정적 파일(이미지, 비디오, 웹 페이지 등)을 제공하는 부분에서 문제가 될 가능성이 크다.
• 일반적으로 정적 파일은 용량이 크기 때문에 컴퓨팅 자원을 많이 소모해서 서버에 과부하가 걸릴 가능성이 크다. 
• 이를 해결하기 위해 정적 파일을 제공하는 서버만 별도로 분리하는 구성을 많이 가져간다.

 

정적 파일 서버 분리 및 CDN 구축

• S3를 활용해 정적 파일만을 제공하는 별도의 서버를 구축
• 하지만 정적 파일은 용량이 큰 경우가 많기 때문에, 정적 파일을 제공받는 곳이랑 거리가 멀면 멀수록 응답 속도가 오래 걸릴 수 밖에 없다. 
• 이를 해결하기 위해 캐싱의 원리가 적용된 CDN을 활용해서 정적 파일 전송 속도를 향상시킨다.

 

WAS 수평 확장

• 사용자 요청이 더 많아져서 EC2 인스턴스 한 대로 모든 요청을 처리할 수 없는 상황이 왔다고 가정
• 이런 경우에는 EC2를 확장해야 한다.
• 시스템 이중화의 장점 때문에 EC2를 확장할 때는 수평적 확장의 방식을 많이 활용한다.(수직적 확장도 동시에 적용시키는 경우도 많다.)
• 하지만 사용자보고 여러 서버에 골고루 알아서 요청을 보내라고 시킬 수는 없다. 사용자의 요청을 여러 대의 웹 애플리케이션 서버에 골고루 전달하기 위한 장치가 필요하다. 그게 바로 로드밸런서(ELB)이다. 

 

로드 밸런서 도입

• 로드 밸런서를 도입함으로써 수평적 확장을 한 여러 대의 EC2에 골고루 트래픽을 분산시킬 수 있다.
• 하지만 늘어난 웹 애플리케이션 서버에 따라 많은 수의 요청이 DB에 몰리게 된다.
• DB에서 병목 현상이 발생하면 DB 자체적으로 성능 개선할 수 있는 부분은 없는 지를 먼저 고려한다. DB 자체적으로 성능 개선하는 방법에는 인덱스 활용, 역정규화, SQL문 튜닝 등이 있다. 이 방식으로 최대한 개선을 했는데도 DB에 병목 현상이 발생할 수도 있다. 그러면 수평적 확장의 방식을 고려해봐야 한다.
• DB에 수평적 확장의 방식을 적용시키는 건 어려운 점이 많다. 왜냐하면 기존에 저장되어 있는 데이터를 수평적 확장한 모든 DB에 복사해서 관리해야 한다. 데이터의 변경이 일어날 때마다 여러 대의 DB가 동기화 작업을 해야 한다. 동기화 작업은 DB 성능 저하를 유발하기 때문에 오히려 장점보다 단점이 더 큰 확장 방식이라고 판단했다. 이 때문에 DB는 수평적 확장보다는 수직적 확장의 방식으로 성능을 개선한다. 
• 만약 DB를 최대한으로 수직적 확장을 했음에도 추가적인 성능 개선이 필요하다면 읽기 전용 데이터베이스(Read Repica) 도입을 고려한다.

 

읽기 전용 데이터베이스(Read Replica) 도입

• DB를 수평적 확장을 하지 못했던 이유는 데이터의 동기화의 어려움 때문이다.
• 하지만 실제 서비스에서 사용하는 쿼리 중 일부는 정밀한 데이터 동기화가 필요 없는 경우가 많다. 따라서 정밀한 데이터 동기화가 필요 없는 쿼리를 실행시킬 때 읽기 전용 데이터베이스(Read Replica)를 많이 활용한다. 
• 원래 하나의 데이터베이스가 모든 트래픽을 처리했어야만 했는데, 읽기 전용 데이터베이스(Read Replica)를 도입함으로써 트래픽을 나눠서 처리할 수 있게 됐다. 
• 이와 같은 방식으로 고사양의 데이터베이스를 사용하다보면 문제가 되는 게 비용이다. AWS의 다양한 서비스 중 RDS(데이터베이스)는 비싼 자원에 속한다. 그래서 비용 절감과 성능 향상을 위해 캐시 서버를 많이 활용한다.

 

캐시 서버 도입

• 데이터를 조회할 때 항상 DB로 요청을 보냈었다면, 캐시 서버를 도입함으로써 데이터 조회 요청의 응답을 DB 서버와 캐시 서버가 나눠서 처리할 수 있게 된다.
• 즉, 캐시 서버를 활용해서 DB 부하를 줄일 수 있다.