13. Architecture

1차 아키텍처

Warm Up!

1.Event Storming

이번 프로젝트에 개별 서비스를 소규모 모듈로 구성하여 배포할 수 있도록 Microservice architecture를 도입하기로 하였다.

서비스를 분리하기 위해 팀원들과 함께 DDD의 전략적 설계인 이벤트스토밍을 통해 마이크로서비스를 도출하였다.

이 활동을 통해 다음과 같이 서비스를 분리하기로 하였다.

• Authentication Service (인증토큰관리)
• User Service (사용자관리)
• Team Service (팀관리)
• Document Service (문서관리)
• Document History Service (문서이력관리)
• Editor Service (공동문서작성)
• Video Conference Service (화상채팅)
• Chat Service (채팅)

2.Data Modeling

각 서비스마다 어떤 데이터를 관리해야하는지 상세화하기 위해 monolithic이라 가정하고 aquery tool을 이용하여 database를 설계를 해보았다.

Architecturing

'microservice = 서비스 분리'라는 것에 초점을 두어 클라이언트는 하나로 개발하되 서버 쪽은 서비스마다 모두 분리시켰다.

bbzzkk 팀원 모두 AWS EC2를 이용하여 배포한 경험이 있다. 따라서 클라이언트는 하나의 EC2 인스턴스에, 서버는 서비스 별로 EC2 인스턴스를 생성하여 생성하였다.

• Client: React + Nginx
• Document Service: SpringBoot + MySQL
• Authentication Service: Express + MongoDB
• User Service: Express + MongoDB
• Team Service: Express + MongoDB
• Editor Service: Express + MongoDB
• Video Conference Service: Express
• Chat Service: Express

서비스가 분리되어 Client에서 여러 개의 서버를 호출한다. 중앙에 API GATEWAY를 두어 client가 하나의 url로 여러 endpoint api를 호출을 할 수 있도록 하였다. Express Gateway와 AWS API Gateway 둘 중에 하나를 고민했었다. Express Gateway에서 socket 연결을 지원하지 않아 AWS Gateway로 선정하였다.

사용자 인증 방식으로 중앙 Session Storage을 두어 Session 방식으로 하는 것이 아닌 로그인 시 JWT를 발행하여 JWT 인증 방식을 도입하기로 하였다. 각 서비스에서는 우선적으로 JWT를 확인하여 인증된 사용자인지 확인하고 request 처리할 것이다.

고찰

1. 하나의 AWS EC2에 server 코드와 database를 같이 배포했을 경우 microservice 장점을 최대화하지 못한다.

해당 인스턴스(노드)에 3 tier layer를 구성하면 어떻게 될까?

첫 번째, 해당 인스턴스에 문제가 생기면 사용자는 해당 서비스를 사용하지 못한다. 두 번째, 해당 인스턴스 가 죽게 되면 database가 초기화 되어 저장된 정보가 사라질 수 있다.

두 번째 문제점을 해결하고자 현재 사용하고 있는 database를 따로 서비스로 분리하는 게 좋을 것으로 판단했다.

• MySQL Service
• MongoDB Service

2. command를 하나씩 입력해서 nginx를 구성하였다. 환경 설정 자동화가 정-말 필요하다고 느꼈다. nginx와 같은 middleware와 service 관련 config를 AMI나 docker image로 구성해서 빠르게 쓸 수 있도록 해야겠다는 생각을 하였다.

2차 아키텍처

1. 데이터베이스를 분리하여 각 데이터베이스에 대응하는 EC2 인스턴스를 만들었다.
2. 데이터베이스가 있는 EC2 인스턴스에 문제 발생 시 데이터 초기화에 대응하기 위해 외부 스토리지 EBS를 사용하였다.
3. EC2 인스턴스끼리 연동을 우선적으로 처리하기 위해 API Gateway를 제외하여 아키텍처를 단순화하였다.

3차 아키텍처

1. 각 서비스마다 Auto scaling group을 만들었다. 고유 AMI(Amazon machine image)로 만들어 특정 서비스 ec2 인스턴스의 cpu 사용률이 80% 이상일 때 해당 AMI를 사용하여 EC2 인스턴스를 생성하도록 하였다.

4차 아키텍처

팀원 중에 과정에서 배웠던 k8s 개념을 복습하고 더 깊이 공부하고 싶다는 팀원이 있어 쿠버네티스 클러스터 환경을 통해 첫 번째 문제점을 해결점을 찾고자 했다. 사용자에게 무중단 서비스를 제공할 수 있도록 이번 프로젝트에 클라우드 환경에서 k8s 환경을 구성할 수 있는 AWS EKS를 도입하기로 하였다.

• 하나의 k8s 클러스터 안에 Client와 모든 서비스를 운영하기로 하였다. 따라서 사용자가 하나의 EKS ingress point로 요청을 하면 되기 때문에 AWS API Gateway를 제외시킬 것이다.
• eks를 지원하는 CI로 circle CI를 도입할 예정이다.
• eks 클러스터에 접근하는 사용자를 구분하기 위해 openID를 이용할 수 있다는 것을 알게 되었다.

AWS EKS google OpenID connect

하나의 k8s 클러스터 안에 Client와 모든 서비스를 운영할 예정이다. EC2에 배포된 각 서비스들은 쿠버네티스 클러스터에서 Deployment와 Service 객체의 쌍으로 구성된다. 즉, 클러스터에서 가장 작은 서비스 기능 단위는 Deployment + Service이다. ingress controller는 nginx-ingress 이용하고 컨트롤러에는 ssl 인증을 적용할 예정이다. 사용자의 요청은 하나의 EKS nginx ingress 컨트롤러로 전달된다.

하나의 서비스당 각 DB로 구성하는 것이 바람직한 MSA 아키텍처라고 배웠다. 하지만 굳이 물리적으로 DB를 분리해야하는가? 각 서비스별로 독립적으로 collection을 이용하면 되지 않는가라는 의견이 나왔었다. 이를 반영하여 데이터베이스 자체를 하나의 서비스 단위로 분리하기로 했다. 이번 프로젝트에서 사용하는 데이터베이스는 mongo db와 mysql로, 데이터베이스를 관리할 수 있도록 서비스 단위로 분리하였다. 즉, 실질적으로 MongoDB에 접근하는 각 서비스는 각자 독립적인 collection을 이용하는 것이다.

google client id, aws s3 client id, db password와 같은 정보를 저장하고 있는 .env, application.properties 파일은 외부에 노출이 되면 안된다. .gitignore 파일을 활용하여 github에 해당 파일이 올라가지 않도록 하였다. 하지만 클러스터를 구성하여 서비스화하기 위해서 해당 비밀정보가 필요하다. 이를 어떻게 하면 좋을까하는 고민을 강훈기 멘토님께 공유했었다. k8s에서 지원하는 configmap 객체를 통해 클러스터에 있는 각 서비스에서 환경변수를 사용하는 것처럼 해당 정보를 쓸 수 있다는 것을 알게 되었다.