프로젝트를 시작하며, 기획을 정하고 인프라 예산을 짜기 위해서 기능, 비기능 요구사항을 정리하고 아키텍처를 확정 지어보는 과정
요구사항
"개발자 알고리즘 학습 게임 플랫폼"
우리 프로젝트는 개발자가 즐기면서 코딩 능력을 향상 시킬 수 있는 게임 서비스를 제공한다.
코드 받아쓰기
혼자서 즐길 수 있는 게임으로 간단하게 https://typing.works/ 처럼 적혀져 있는 코드를 칠 수 있는 기능이다.
알고리즘 문제 풀기
https://programmers.co.kr/ 처럼 알고리즘, 언어에 해당하는 문제를 풀 수 있는 기능이다. 솔로 플레이와 멀티 플레이를 지원한다.
릴레이 문제 풀기
https://garticphone.com/ko 처럼 알고리즘 문제를 하나의 에디터에서 돌아가면서 풀고 협력해서 문제를 해결할 수 있는 게임이다.
인프라 스펙
"EC2 9대를 통한 장애격리와 독립 배포"
일단 고가용성을 최대 가치로 생각하였다. 만약에 릴레이 게임 서버가 다운 되었을 때 사용자들이 받아쓰기 기능, 랭킹 조회, 채팅 등 다른 기능을 무리 없이 사용할 수 있는 것이 최대 가치였다.
그렇기에 받아쓰기, 릴레이 게임, 문제 풀이 게임 Server를 각각의 EC2로 분리시켜 장애 격리를 시켰다.
또한 아직 어떤 서비스가 가장 인기를 얻을 지 트래픽이 몰릴 지 예상이 가지 않는 상황에서 독립적인 스케일 업이 가능하도록 설계하였다.
또한 메인 페이지에서 조회를 통해 보여줘야 하는 서비스들은 API Gateway와 함께 묶어 배포 하여 중요한 묶어 주었다.
아키텍처 수정
단일 장애점과 보안에 대한 추가 고려사항
API Gateway를 하는 역할의 서버는 모든 서버로 가는 통로이자 단일 장애점이다.
단일 장애점이라 함은 여기가 장애가 나는 순간 모든 서비스가 마비된다. 그렇기에 다른 비즈니스 로직을 추가하지 말고 단일 + 좋은 EC2를 부여하면서 관리하였다.
그리고 인증 기능을 원래는 따로 분리하여 인증만을 위한 서버를 구축해야 하지만, 우리는 결제 기능이 없어서 높은 보안 레벨이 필요하지 않고, 간단히 토큰을 통해 어떤 사용자인지 식별하는 기능만 필요하기 때문에 높은 인증/인가가 필요하지 않아서 Gateway와 인증 역할을 하나로 spring cloud에 담았다.
만약 결제 기능이 추가된다면 인증 서버를 따로 구축하여 네트워크 인바운드 설정을 통해 Gateway에서만 접근할 수 있도록 하여 보안을 관리할 수 있도록 해야한다.
그리고 Redis나 Message Queue가 단일 장애점이 될 수 있기 때문에 따로 설정을 해줘야 할 것 같다.
결론
EC2 12대...?
일단 MSA를 위한 설계를 하였지만, 우리의 예산으로 EC2 9대가 최대이기 때문에 장애격리, 서비스 특성을 고려해서 서비스를 합쳐야 한다.
기획이 세세하게 확정이되고 트래픽 예상이 된다면 아키텍처를 맞춰서 수정해야한다.
또한 이 많은 EC2를 관리하기 위해 쿠버네티스를 적용할 것 같다.
지금은 논리적 설계만 완료한 상황이고, 추후 물리적 설계도 완료해서 포스팅 할 계획입니다.
EC2 관리하는 남자 너무 멋있어요