들어가며.
Section4의 마지막을 달리고 있다. 스프링 MVC 부터 스프링 Security 까지 다배우고 Spring에서도 Non-Blocking 방식을 지원하는 SpringWebFlux에 대해서도 맛만 보았다. 벌써 4개월의 시간이 거의 끝나간다는게 놀랍다. 실제로 프로젝트로 서비스를 만들려면 복습을 열심히 해야겠다. 어쨋뜬 오늘부터 클라우드 서비스에 실제로 배포하고 어떻게 인프라를 구축하는지에 대해서 배우기 시작했는데 재미있다. 옛날에 고등학생 때 제로보드를 활용해서 웹사이트를 의뢰 받아 제작했던 경험이 있는데 그때는 웹호스팅 업체에 FTP로 파일을 올리고 했던 기억이 있는데 요즘에는 어떻게 실제로 이용자가 서비스를 이용하도록 배포하는가를 명확히 잘 몰랐다. AWS EC2, S3, Netlify, vercel, Kubernetis 와 같은 것들을 들었지만 사실 AWS같은거는 무료여도 언제 과금으로 나갈지 몰라서 잘 시도해보지 못하고 있었다.
이번 챕터를 통해서 어떻게 배포가 되고 하는지에 대해서 감을 좀 잡을 수 있을 것 같다. 물론 큰 규모의 기업이나 이런 개발 팀들이 각각의 파트마다 잘 세분화 되어있는 경우에는 내가 인프라 설정까지 이런 부분들을 다룰 일이 많지는 않을 수 있지만 어떤 기업에 갈지는 모르는거고 또 내가 만든 서비스를 배포하는 것에 대해서 아는 것은 기본이라 생각한다. 그리고 하나의 웹서비스가 만들어져서 최종 배포까지의 모든 프로세스를 다 경험해봐야 협업이나 이런 흐름들을 이해하고 개발할 수 있을거라 생각한다. ( 디자인과 출신이니까 프론트를 공부해야지 하면서 프론트를 공부하다가 백엔드를 공부하게 된 이유이기도 하다 )
우리가 이용하는 웹사이트는 어떻게 주소만 입력하면
우리는 아주 간편하게 많은 서비스들을 이용한다. 앱이든 naver.com 과 같은 자주 가는 사이트이든 그냥 naver.com에 들어가면 모든 기능과 검색을 편하게 만들 수 있다. 그러한 서비스를 제공하는 것에는 여러가지 많은 작업과 경로를 거쳐 사용자가 직접 사용할 수 있게 된다.
1. 웹서버 아키텍처 구조
우리가 naver.com을 입력하면 네이버의 메인화면이 뜨는 것 처럼 보이지만 사실 내부적으로는 정말 많은 작업들이 이뤄진다. 처음에는 이런 것들이 당연하게 여겨졌는데 백엔드 공부를 하면서 이런 내부적인 동작과정을 알게 되니까 신기하기도 하고 더 많이 알고 싶어졌다.
DNS (Domain Name System)
우리가 naver.com이라고 입력하면 가장 먼저 하는 일이 DNS 서버에 요청을 보내는 거다. DNS는 우리가 기억하기 쉬운 도메인 주소를 실제 서버가 위치한 IP 주소로 변환해주는 시스템이다. 마치 전화번호부처럼 도메인 이름과 IP 주소를 매핑해주는 거다.
예를 들어보면:
이런식으로 변환이 되는데, 실제로는 훨씬 더 복잡한 과정을 거친다. 이걸 확인해보고 싶다면 터미널에서 nslookup naver.com 이라고 입력해보면 된다.
웹 서버와 WAS의 구조
DNS를 통해 IP 주소를 알아내면, 이제 실제 서버로 요청을 보내게 된다. 근데 대형 서비스들은 이런 구조로 되어있다:
각각이 하는 일을 살펴보면:
- 로드밸런서: 트래픽을 여러 서버에 골고루 분산시켜준다. 마치 은행 창구 안내 직원처럼 여러 서버에 작업을 배분하는 역할을 한다.
- 웹 서버: 정적인 파일들(html, css, 이미지 등)을 처리한다. nginx나 apache가 대표적이다.
- WAS(Web Application Server): 동적인 내용을 처리한다. 우리가 만든 스프링 부트 애플리케이션이 여기서 동작한다.
- DB: 데이터를 저장하고 관리한다.
실제 서비스는 어떻게 배포될까?
내가 만든 첫 스프링 부트 프로젝트는 그냥 로컬에서 실행했었다. 근데 실제 서비스는 보통 이런 형태로 배포된다:
처음에는 이런 구조가 복잡해 보였는데, 각각의 역할이 명확하게 분리되어 있어서 오히려 관리하기가 더 편하다는 걸 알게 됐다. 예를 들어 트래픽이 갑자기 늘어나면 백엔드 서버만 확장하면 되고, 데이터가 많아지면 데이터베이스 용량만 늘리면 된다.
CI/CD로 자동화하기
예전에는 개발자가 직접 FTP로 파일을 올렸다고 했는데(나도 처음에 이렇게 해봤다), 요즘은 CI/CD 파이프라인으로 이 과정을 자동화한다:
코드를 push하면 자동으로 테스트, 빌드, 배포가 이뤄진다. 처음에는 이런 자동화가 오히려 복잡하다고 생각했는데, 실수도 줄이고 배포도 훨씬 빨라져서 진짜 편하다는 걸 알게 됐다.
다음 글에서는 실제로 AWS를 이용해서 스프링 부트 애플리케이션을 배포하는 방법을 자세히 다뤄보려고 한다. AWS 프리티어로도 충분히 연습해볼 수 있으니 겁먹지 말고 한번 시도해보자!
'개발일지' 카테고리의 다른 글
| [리팩토링] 투두리스트 다크모드 코드 개선하기 feat. react (1) | 2023.06.06 |
|---|---|
| [프로젝트일지 - 에러 해결] JPA 연관관계 맵핑 문제 오류 feat.클래스 이름 바꿀 때는 조심 또 조심! (0) | 2023.05.27 |
| [QnA 게시판 오류일지 - 1] 질문 등록을 위한 HTTP post 요청시 응답 오류 코드 500 해결하기 (0) | 2023.05.15 |
| [KPT] Section3를 마치며 돌아보는 KPT 회고 feat.코드스테이츠 (1) | 2023.05.09 |
| [TIL] Spring Framework 기본 개념 정리 (0) | 2023.03.31 |
