[우테코] 스탬프크러쉬의 인프라 개선: 현재 아키텍처와 개선 아키텍처 2가지

 

 

 

 

안녕! 

우아한테크코스 5기 [스탬프크러쉬]팀 깃짱이라고 합니다. 

 

스탬프크러쉬 서비스의 소스 코드 바로가기

사장모드: stampcrush.site/admin

고객모드: stampcrush.site

 

💋 인트로

토미의 인프라 개선에 대한 강의 이후에, 우리 팀의 현재 인프라 구조를 분석해보고, 어떻게 개선할 수 있을 지에 대해서 팀원 전체와 고민해봤다.

개선의 포인트는 가용성의 향상으로, 우리 서비스에 장애가 발생해 전체 서비스가 중단되는 상황을 피하는 방향이었다. 

 

💋 우리 서비스에서 특별히 고려해야 할 중요한 기능

• 데이터베이스 상에 저장되는 정보가 카페와 고객 사이에 신뢰를 결정짓고, 금전적인 부분이 연관되어 있어서 절대 데이터를 잃어서는 안된다.

 

💋 현재 아키텍처에서 문제가 될 수 있다고 생각한 부분

현재의 아키텍츠

• 현재 모든 인프라 구성요소에 대해 다중화가 되어 있지 않아서, 각 요소가 모두 SPOF라고 볼 수 있다.
• 우리 아키텍처의 SPOF
• WS(Nginx), WAS(tomcat), DB, 개발자(깃짱, 제나, 하디, 레오, 라잇, 윤생, 레고)

 

💋 문제를 해결하기 위해 적용한 방법

✔️ 개선 아키텍처 1안

 

• WS로 요청을 보내기 위한 로드 밸런서로 AWS ALB 사용
• ALB는 AWS의 서비스로, 높은 가용성을 보장함.

• WS, WAS 다중화
• 각 WS와 WAS를 1:1로만 묶어서 요청을 처리하도록 하면, WS와 WAS가 직렬로 실패하기 때문에, 각 WS에 대해서 모든 WAS로 요청을 보낼 수 있도록 함.
• DB 다중화
  
  • writer DB 1개를 통해서, 모든 데이터 변경 작업을 수행함.
  • reader DB 2개를 통해서, 데이터 조회 작업을 수행함.
    • writer DB가 고장났을 때, 빠르게 1개의 reader DB를 writer DB로 사용하기 위해서 2개 할당함.

 

✔️ 개선 아키텍처 2안

• WS, WAS 도 각각 ALB를 사용하도록 분리
• DB 다중화 (1안의 내용과 중복됨)
  
  • writer DB 1개를 통해서, 모든 데이터 변경 작업을 수행함.
  • reader DB 2개를 통해서, 데이터 조회 작업을 수행함.
    • writer DB가 고장났을 때, 빠르게 1개의 reader DB를 writer DB로 사용하기 위해서 2개 할당함.

  

 

💋 개선한 인프라 아키텍처에서 발생할 수 있을 것으로 예상되는 문제

• writer DB에 반영된 변화를 reader DB에 복제하는 과정이 실시간으로 동작하지 않아 데이터의 싱크가 맞지 않을 수 있음.
• 자연재해, 전쟁 발생 등의 DB 서버 손실 문제
• 모든 WS, WAS 를 각각의 EC2 에 둠으로써 비용 발생

 

💋 위에서 서술한 문제에 대한 해결 방안 아이디어

• 자연재해, 전쟁 발생 시에 대비해 가장 중요한 DB 서버는 각각 지리적 위치를 서울, 천안, 부산(삼천포)으로 분산해 놓는 것이 좋을 것 같음.
• EC2 사용량을 분석해서 사용 리소스에 적절한 인스턴스 유형 선택

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟