좌충우돌 웹서비스 프로젝트 수행기 – 2.아키텍처 상세

정보제공 웹 서비스를 위한 아키텍처 개요

---

draw.io로 열심히 그린 이번에 우리 회사에서 서비스할 금융정보 웹 서비스의 전반적인 아키텍처

혼자서 아키텍처 정의 다했다…

경계가 분명한 것은 아니지만 다양한 관점에서 이 정보제공 웹 서비스의 Action flow를 생각해볼 수 있을 것이다.

1. 사용자 관점
2. Backend Engineer 관점
3. Frontend 개발자 관점
4. Infra Engineer 관점

각 관점에서의 Action flow를 나열해보자. 너무 구체적이기보단 개괄적으로. 상세적인 지식은 이어지는 글들에서 담도록 하자.

사용자 Action flow

---

예상되는 사용자 Action flow는 이렇다.꽤나 네트워크 적인 관점이긴 하지만…

1. 사용자가 Web Browser로 우리 도메인에 접근.
2. 이는 공인 네임서버를 통해 우리 Gateway(Or Reverse Porxy)에 연동되고 traefik 등의 서비스 디스커버리를 통해서 React 서버로 라우팅.
3. React는 javascript를 클라이언트 Web Browser로 넘겨주고 이를 렌더링.
4. 로그인 정보를 입력하면 게이트웨이를 통해서 인증/인가 API 서버에 접근하여 액세스 토큰을 받고, 클라이언트 이를 보관하여 요청마다 토큰을 동봉.
5. React 서버나 백엔드 API 요청 시 토큰을 동봉하고, 이를 서버 단에서 인증/인가 서버를 통해 검증하며 작업을 수행한다.

Backend Engineer Action flow

---

개발과 유지보수 관점일 것이다. 그리고 DA와 역할을 굳이 분류하지 않았다.

개발

1. 신규 개발 서비스 기획 분석
2. 필요 API 정의, 필요 데이터 정의, 필요 테이블 정의,데이터 파이프라인(ETL) 설계
3. mocking API 우선 개발로 frontend 개발 소스 우선 제공
4. 테이블 반영, ETL 개발, API 개발
5. OTel 연동
6. 테스트 케이스 작성 및 CI/CD 연동
7. 배포

유지보수

1. OTel을 통해 모니터링(Grafana, Alertmanager, Prometheus)을 수행.
2. 문제가 metric 등을 통해 자동으로 식별되면 이를 loki와 tempo를 통해 로그와 trace를 추적하여 문제 식별.
3. 문제에 대한 해결과 hotfix 배포 시행.
4. 자동화된 CI/CD가 빌드, 테스트, 배포까지 수행하여 docker swarm 클러스터에 API 배포.

Frontend 개발자 action flow

---

Backend Engineer와 거의 흡사하다. 개발과 유지보수 관점일 것이다.

개발

1. 신규 개발 서비스 기획 분석
2. 필요 화면 정의, 필요 컴포넌트 정의
3. mocking API를 기반으로 화면 레이아웃 및 컴포넌트 기능 개발
4. 디자이너가 기획 초안을 바탕으로 시안 작성
5. 퍼블리셔가 이를 기 개발된 화면에 적용
6. 테스트 케이스 작성 및 CI/CD 연동
7. logging, tracing OTel 연동
8. 배포

유지보수

1. OTel을 통해 모니터링(Grafana, Alertmanager, Prometheus)을 수행.
2. 문제가 metric 등을 통해 자동으로 식별되면 이를 loki와 tempo를 통해 로그와 trace를 추적하여 문제 식별.
3. 문제에 대한 해결과 hotfix 배포 시행.
4. 자동화된 CI/CD가 빌드, 테스트, 배포까지 수행하여 docker swarm 클러스터에 frontend server 배포.