아키텍처정의
우선 전체적인 다이어그램을 그려보면 다음과 같다.
boardmix라는 사이트를 이용해서 그렸고, 큰 관점에서 아키텍처를 정의 했다. 제대로 따지면 프론트엔드 부분도 사실은 쿠버네티스 클러스터 안에 있는 개념인데, 실제 구성과 1:1 동일하게 그리는 것 자체도 불가능하고, 이해하기 쉽게 클라이언트와 서버의 통신 개념을 중심으로 그렸다. 또 쿠버네티스 클러스터도 간단하게 Service 개념으로 나누고 끝냈다.
전체서비스는 클라우드 내 자원에서 가용될 예정이다.
내/외부 통신은 API GateWay를 통해서 이루어진다. DB나 기타 서비스는 쿠버네티스 클러스터 내에는 존재 하지 않기에 외부서비스로 가정했다.(DB 같은 건 이렇게 쿠버네티스 클러스터 외부에 두는 것이 관리 측면에서 더 좋다고 한다.)
Client
Client는 웹 브라우저를 통해서 애플리케이션에 요청을 하고, 응답을 받음
사용자의 접속 디바이스는 PC, Mobile, Tablets 등 웹 브라우저를 사용할 수 있는 기기로 접근이 가능
FrontEnd
사용자가 직접 서비스와 상호작용하는 주체가 된다
웹브라우저를 통해서 접속하여 접근이 가능하다
네이티브 앱 애플리케이션 서비스는 개발 고려 대상에서 제외
HTML, JavaScript, CSS를 통해 구현 되는 웹페이지로, Svelte를 이용하여 이를 구현함
Svlete를 통해 생산성 향상과 동시에, React에 비해 상대적으로 적은 러닝커브로 모던한 웹 개발을 구현 할 수 있을 것으로 판단되어 채택함
구조상 K8s 클러스터 내의 Pod 서비스로 구현되고 위치되어 있으나, 다이어그램 표현 편의상 외부에 표기함
CloudInfrastructure
서비스의 운영과 배포는 클라우드 환경 내에서 구현 된다
구체적으로 운영되는 클라우드 서비스는 DigitalOcean를 선택한다
DigitalOcean을 선택한 이유는 AWS, AZURE, GCP 등 주요 클라우드 서비스와 비교하면 가격적으로 이점이 있기 때문 (토이 프로젝트 및 개인 개발 및 구현에 초점을 맞췄고, 타 서비스의 대략적인 1달 운영 비용 최소 30달러선에서 시작, DigitalOcean 24달러 시작)
Kubernetes Cluster
CloudInfrastructure 내에서 제공하는 관리형 K8s 서비스를 통해 쿠버네티스 클러스터를 구성함
관리형 K8s 서비스는 물리적으로 구축하려면 어려운 K8s 클러스터를 쉽고 빠르게 만들 수 있으며, 관리하기 쉽기 때문
위 CloudInfrastructure에서 DigitalOcean을 채택하였기에, 해당 서비스에서 제공하는 관리형 K8s서비스를 통해 클러스터를 구성함
클러스터 내의 각 서비스는 마이크로서비스로 구성되며, Pod를 통해 구현된다
다이어그램 내에서는 추상화 레벨에서 Pod에 대한 표현은 생략 함
각 마이크로서비스는 서비스 부하에 따라 Scale-Out 방식으로 Auto-Scaling이 가능함
단, 토이프로젝트에서는 서비스 부하에 따른 Scale-Out의 제한을 두기로 한다. (실제 운영이 아님, 비용 문제로 부하테스트 단계에서 제대로 동작하는지 시험만 하고 제한을 두기로 함)
External Service
CloudInfrastructure 내에 포함되어있으나, Kubernetes Cluster에는 포함되어 있지 않은 서비스들의 분류이다
Kubernetes Cluster내에서도 구현이 가능하나, 관리적인 측면에서 외부로 분리하는 것이 유리한 서비스를 구현한다
DB
대부분의 핵심적인 데이터는 관계형DB인 Postgesql을 통해 영속성을 관리한다
세션이나, 캐싱, 일부 대용량 데이터처리 등 구현에 따라 필요한 경우 InmemoryDB인 Redis를 사용한다. 대용량트래픽을 가정하고 NoSql인 MongoDB의 추가구현도 예상하고 있음.
Event & Messaging
비동기 처리가 필요한 로직의 경우 Kafka를 통해서 구현한다
Notification
알림이 필요한 기능으로, 이메일 전송과 관련된 기능은 외부에 구현된 SMTP 서버를 사용한다
FileStorage
파일 저장의 경우, NAS 등의 장치를 사용할 수도 있으나, 추가적인 관리 포인트의 증가와 비용 등을 고려했을 때, 클라우드 내에서 제공하는 파일저장 시스템을 선택하기로 한다
API Gateway
Client와 Kubernetes Cluster의 통신과, CloudInfrastructure 내에서의 Kubernetes Cluster와 External Service 간의 통신을 담당한다. Client와의 통신은 보안과, 로드밸런싱, 라우팅 등에서의 기능적 초점을 맞췄다면, CloudInfrastructure 내부에서는 간접 호출을 통한 추상화와 관리 편의성에서 채택한다
API Gateway는 K8s에서 제공하는 Gateway서비스를 이용하며, 구현체는 Istio를 사용한다.
여기까지 아키텍처정의는 마쳤다. 토이프로젝트를 구상하고, 회사를 다니면서 틈틈이 준비했던 부분은 여기까지다. 앞으로의 단계는 API정의와 DB설계, 화면설계 등이 남아있는데, 이 부분은 과감히 생략하기로 한다. 정확히는 구현을 마치거나, 구현을 하면서 작성해보려고 한다. API 정의는 OpenAPI(구 Swagger)를 통한 API의 스펙과 문서를 정의하면서 설계 해보려고 했는데, 생각보다 배워야하는 부분이 많기도 하고, 처음부터 완벽에 가깝게 정의 해 볼 수 가 없을 것 같다는 생각 (빈번한 수정이 예상된다)에 구현단계에 바로 들어가려고 한다.
사실 토이프로젝트 처음 구상까지만 해도, 완벽하지는 않아도 나름대로 최선의 선택을 한 설계를 하고 시작하자라는 마음이 있었다. 그런데 켄트 백 저서인 'Tidy First?'의 부록에 옮긴이 '안영회' 님이 남긴 글을 보고 마음을 바꾸는 계기를 가지게 되었다.
설계는 코딩을 대신해 주지 않고, 설계는 코딩하기 직전에 무엇을 어떻게 짜야 할지 떠오르지 않을 때, 어떻게 해야 할지 떠오를 정도까지만 한다.
라는 요점을 전달한다.
결국 설계 자체는 현대 소프트웨어 개발에서의 다수의 사람들과 소통하기 위한 일종의 의사소통 방식이며, 설계 자체는 정답을 만드는 일이 아니다.
이 사실에 크게 공감하며, 이제 나는 충분히 어떻게 코딩하면 좋을지에 대한 떠오름은 차고 넘쳤다. 이제는 그것을 코딩으로 서비스의 빌드와 배포를 목적으로 구현하고 완성하려고 한다.
이 구현 과정 자체가 속도를 중요시 하기보다는 제대로를 목표하고 있기에 아마 토이프로젝트에 관련된 포스팅은 한동안 뜸 할 것으로 예상한다. 또 구현 부분에 있어서는 상세한 기술 구현에 대한 내용을 적기보다는 왜 이런 구조와 구현을 하는데 있던 수 많은 선택지 중에서 이런 선택을 했는지에 대한 내용을 중심으로 작성 할 것 같다.
