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

🎓 이 글은 인프런에서 제공하는 "대규모 트래픽 처리를 위한 부하 테스트 입문/실전" 강의를 수강하면서 정리한 내용을 바탕으로 작성한 글입니다.

https://inf.run/jBYVR

대규모 트래픽 처리를 위한 부하테스트 입문/실전 강의 | JSCODE 박재성 - 인프런

 

---

트래픽 증가에 따른 시스템 설계 및 확장 방법

병목지점이 어디서 발생하느냐에 따라 성능 개선의 방법이 달라진다. 

이 방법에 대해 대략적으로 알면 성능 개선을 수월하게 할 수 있다.

 

✅ 가장 간단한 형태

위 그림은 EC2 서버 한 대에 FE, BE, DB 관련 프로그램을 다 실행시키는 형태의 구성이다.

장점은 하나의 서버에서 리소스가 다 있어서 관리 / 조작이 쉽다.

하지만 이 구성으로인해 실제 서비스를 운영하다 보면 DB 가 생각보다 많은 컴퓨팅 자원(CPU, 메모리,디스크)를 사용한다. DB로 인해 성능에 악영향을 줄 수 있기 때문에 별도의 서버를 분리하려는 형식을 많이 가진다.

 

✅ DB 분리

웹 서버와 DB를 분리한 인프라 구성

트래픽이 많아지면 정적파일을 제공하는 부분에서 문제가 될 가능성이 크다.

일반적으로 정적 파일은 용량이 크기 때문에 컴퓨팅 자원을 많이 소모해서 서버에 과부하가 걸릴 가능성이 크다.

이를 해결하기 위해 정적 파일을 제공하는 서버만 별도로 분리하는 구성을 많이 갖는다.

 

✅ 정적 파일 서버 분리

 

S3를 활용해 정적 파일만을 제공하는 별도의 서버를 구축했다. 

하지만 정적 파일은 용량이 큰 경우가 많기 때문에, 정적 파일을 제공받는 곳이랑 거리가 멀면 멀수록 응답 속도가 오래 걸릴 수 밖에 없다.

이를 해결하기 위해 캐싱의 원리가 적용된 CDN을 활용해서 정적 파일 전송 속도를 향상시킨다.

 

✅ CDN 서버 활용

 

이제 S3에 바로 접속해서 파일을 받아오는 것이 아니라 CloudFront 를 통해 가까운 임시저장소에서 파일을 가져오게 됐다.

이번에는 사용자가 많아져 EC2가 병목지점이 되었다. 이 경우에는 EC2를 확장해야 한다 (수직적 확장 vs 수평적 확장)

보통 시스템 이중화의 장점 때문에 EC2를 확장할 때는 수평적 확장의 방식을 많이 활용한다.

 

✅ 웹 애플리케이션 서버의 수평적 확장

 

EC2 서버를 여러대로 늘렸지만 사용자보고 여러 서버에 골고루 알아서 요청을 보내라고 시킬 수없다.

사용자의 요청을 여러대의 웹 애플리케이션 서버에 골고루 전달하기 위한 장치가 필요하다. 로드밸런서를 도입해보자.

 

✅ 로드 밸런서 도입

 

로드 밸런서의 도입으로 여러대의 EC2에 골고루 트래픽을 분산시킬 수 있게 됐다.

그러나 늘어난 웹 애플리케이션 서버에 따라 많은 수의 요청이 DB에 몰리게 된다.

 

DB 병목현상 발생 시 1️⃣ DB 자체적으로 성능 개선할 수 있는 부분은 없는지를 먼저 고려한다.

• 인덱스 활용
• 역정규화
• SQL 튜닝

이 방식으로 최대한 개선했는데도 DB 에 병목 현상이 발생하면 2️⃣ 수평적 확장 방식을 고려한다.

 

왜 수직적 확장 방식이 아니고 수평적 확장방식일까 ? 

DB를 여러개 둔다면(수평적 확장) 모든 DB에 데이터를 복사해서 관리해야 한다.

그럼 데이터 변경이 일어날때마다 여러대의 DB 가 동기화 작업을 해야한다.

동기화 작업은 DB 성능 저하를 유발하여 장점보다 단점이 더 큰 확장 방식이라고 얘기를 하는 편이다 (DB 를 늘리면 늘릴수록 동기화하는데 시간이 더 오래 걸려서 결과적으로는 크게 개선되지 않음. 그리고 문제는 더 많이 발생함) 이런 이유 때문에 수평적 확장 방식 보다 수직적 확장의 방식으로 성능을 개선한다.

 

1️⃣ , 2️⃣ 이후에도 추가적인 성능 개선이 필요하다면 3️⃣ 읽기전용 DB(Read Replica) 도입을 고려한다.

 

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

 

정밀한 데이터 동기화가 필요없는 쿼리를 실행시킬때 읽기 전용 DB를 많이 활용한다.

ㄴ 정밀한 데이터 동기화가 필요없는 쿼리란 ?

ㄴ 예를 들어, 게시글을 작성하고나서 작성된 게시글을 바로 보지 않으면 큰일나나 ? 그렇지 않다. 게시글 작성 후 10초 있다가 글을 봐도 큰 문제가 없다. 이런 데이터의 경우 읽기 전용 DB 를 사용하는 것이다. 

 

이 같은 방식으로 DB를 사용하다보면 비용이 문제가 된다. AWS 의 RDS는 비싼 자원에 속하기 때문에 비용 절감과 성능 향상을 위해 캐시 서버를 많이 활용한다.

 

✅ 캐시 서버 도입

데이터베이스를 확장하고 바로 동기화 할 필요 없는 것들은 캐시를 통해 조회할 수 있도록 만든다.

 

이렇게 했을 때 성능에 부하가 줄어들 수 있는 이유는 

기존엔 100만건의 요청 처리를 Master, Replica 두개의 DB가 나눠서 처리를 했다면 이젠 캐시 서버가 함께 나눠서 가져갈 수 있게 되기 때문이다. 

 

캐시 서버를 도입함으로서 데이터 조회 요청의 응답을 DB 서버와 캐시 서버가 나눠서 처리할 수 있게 된다. 이처럼 캐시 서버를 활용하면 DB서버 부하를 줄일 수 있고, 전체 Throughput 이 증가하게 된다.

 

 

병목 지점에 따른 성능 개선 방법

위에서 설명한 시스템 설계 및 확장 방법만 알고 있어도 충분하다.
이번에는 병목 지점의 관점으로 성능 개선 방법을 정리해보자

 

1. EC2 가 병목 지점일 경우

• 애플리케이션 로직에서 비효율적인 로직 개선하기
• 정적파일 서버(S3, CloudFront) 분리하기
• 로드밸런서(ELB) 를 활용해 수평적 확장하기
• 수직적 확장하기

 

2. RDS가 병목지점일 경우

• 비효율적인 쿼리 개선
• 읽기전용 DB 도입
• 캐시 서버 도입