안녕 AWS
작은 서비스를 배포하기 위해서 가장 좋은 방법은 무엇일까?
작은 서버를 사서, 처음부터 올리는 것도 좋은 공부가 되겠지만, 많이 배울 수는 있어도 나중에 써먹기는 힘들다.
프로그래밍의 분야가 세분화되고 있는 지금 그렇게까지 리눅스를 파서 공부할 필요가 있을까? 오히려 클라우드를 경험해보는 것이 더 좋지 않을까? 물론 아키텍처쪽으로 지망하면 처음부터 올려보는 것이 좋겠지만, 나는 웹 백 혹은 프론트할 생각이고 다른 팀원들도 아키텍처는 관심이 없다.
고맙게도, 42서울은 훌륭한 보상제도(발표 혹은 봉사시 주는 달러)를 가지고 있고, 그 보상제도 안에는 AWS 크레딧이 존재한다.
GCP, Azure 등등 거의 모든 클라우드 플랫폼의 크레딧을 구매할 수 있지만, 우리는 접근성 및 학습을 이유로 AWS을 사용하기로 마음을 먹었다.
우리는 42서울이라는 뒷배를 잘 이용하여 100만원짜리 크레딧을 얻었고, AWS 구축에 열을 올렸다.
어떻게 구축할 것인가?
우리의 고객들(Client)의 수는 어떻게 되는가?
우리의 고객은 매일 이용하며, 오전 9시에 50 ~ 150회의 접속이 이루어지고, 오후에는 간혈적으로 접속이 이루어질 것이라고 생각된다.
동시 접속자는 최대 50명 이내일 예정이다.
DNS서비스는 어떻게 정할 것인가?
감비아와 같이 DNS 대행 업체들이 존재하지만, 우리가 사용하고 있는 AWS에서도 제공해준다.
더욱이 가지고 있는 크레딧을 DNS에 사용할 수 있기에 우리는 Route53을 선택했다.
(가격은 조금 더 비싸다, 다른 곳은 3년에 2만원 선이지만 이곳에서는 12개월에 12~15달러선)
인스턴스 IP는 어떻게 할 것인가?
AWS에서 제공하는 Elastic IP로 설정하여 DNS와 연결할 것이다. 인스턴스 IP는 종료후 재 시동할 때마다 변경되기 때문
어떤 OS를 사용할 것인가?
42서울 인원들은 모두 Born2BeRoot라는 프로젝트를 통해 VM에 데비안을 올려본 경험들이 있다.(소수는 레드햇OS)
AWS에서 제공하는 OS중에 Ubuntu는 내가 실제로 2017년 한 해동안 사용해본 경험이 있고, 데비안 유저들도 쉽게 사용할 수 있을거란 판단이 들었다. 그래서 아키텍처 담당으로서 전체 구성원들의 사용편의성을 위해 Ubuntu로 결정했다. (맥OS가 있어서 잠깐 혹했다)
어떤 데이터베이스를 사용할 것인가?
우리는 ERD를 경험해보고 공부도 할 요량으로 Postgresql을 골랐다.
서버는 몇 개를 쓸 것인가?
서버는 처음에는 EC2 2개를 이용하려고 했다. 왜냐하면 일반적인 프로덕션 레벨에서 프론트 서버와 백엔드 서버가 구성되어있기 때문이다.
로드밸런서를 이용, Route53에 들어오는 요청을 적절하게 분배해줌으로써 기능을 하려고 했다. 하지만 결국 EC2 1개를 사용했다.
그렇다면 왜 2개로 하지않았는가?
첫번째로는 비용의 문제가 있었다. AWS의 철학 OnDemand에 따라 2개를 쓰면 비용도 2배로 는다. 게다가 이 새로운 계정은 프리티어도 적용되어있어서 EC2 1개를 쓰면 비용도 나오지 않는다. 프로젝트에서 예산을 아낄 수 있다면 아끼는 것이 좋겠다고 생각해서 1개 쓰는 방법을 고민했다.
두번째로는 네트워크 비용에 대한 고민이 있었다. 42서울 과정을 밟다보면 IO과정 그리고 네트워크의 비용이 얼마나 큰지 느낄 수 있다. 이 곳에서 사용하는 C언어들은 워낙 빠르기 때문에 OS단에서 이루어지는 느린 일들(Page Fault, I/O, Network 통신) 등등에 대해 매우 민감하게 반응하도록 사람이 바뀐다. 그래서 서버가 2개면, 둘 간의 통신하는 비용이 발생할 것이라고 생각하여 그것을 없애기 위해 하나의 서버에서 해볼까라는 고민을 했다.(멘토링 후에는 기업들이 괜히 2개로 하는 것이 아니라는걸 알았다)
왜 상용서비스를 이용하지 않았는가?
AWS에서 제공하는 RDS 혹은 S3 아니면 Vercel과 같은 방식으로 구축하면 더 쉬웠을 수 있는데, 이 방법을 취한 이유는 학습때문이었다.상용서비스를 이용하더라도 그것이 실제로는 어떻게 돌아가는지 직접 이해하고 싶었고, 그렇기 때문에 하나하나 올려보는 과정을 거쳐봤다.실제로 올려보니 패키지 의존성 및 포트와 라우팅 문제등 하나하나 핸들링 하기 정말 힘들었지만, 그래도 어찌 돌아는 갔다.
향후 어떻게 할 것인가?
엎어버리고 상용 서비스 사용할 예정이다.(S3 + Route53 + EC2 + RDS)
실패록
너무많은 실수들이 있었다.
나는 2016~2017년 학교에서 진행한 프로젝트들 그리고 해커톤에 나갈 때마다 사용해본 AWS경험들이 있었지만, 또 다시 하려니 쉬운일은 아니었다. 매번 할 떄마다 '이걸 왜 실수하지?!' 라고 외치지만 또 하고 있는 내 모습은 내가 봐도 신기하다.
첫 실수 "아 리전 잘못 정했다"
AWS에는 2가지 중요한 영역이 있다.
리전(Region)과 가용역역(AZ)이 그것인데 이 둘은 내 서버가 위치할 공간을 의미한다.
하나의 리전에는 여러 물리 서버들이 존재하는데, 이 것들을 지정함으로써 내 서버의 위치를 지정할 수 있다.
내가 서울 리전을 지정하면 내 서버는 목동에 있을 수도 일산에 있을 수도 있지만, 하여튼간에 일단 서울 주변에 있다.
그래서 리전이 틀리면 뭐가 안좋은데?
첫째로, 가장 중요하게도 네트워크 응답속도가 느리다!
내가 만들 서비스의 주 사용자들은 개포동 42학생들인데, 이 사람들이 클릭할 때마다 도쿄리전을 찍고오게할 수 없지않은가?
서비스를 쓸 때마다 굳이 가까운 슈퍼마켓 두고 먼 슈퍼마켓으로 보내는 격이다(실제로 파는 것은 동일한데도 불구하고!!)
그렇기 때문에 이건 당장 바꿀 수 밖에 없는 실수였다.
게다가, 서울 리전을 써야 서울 리전에서 다른 서비스들을 이용할 수 있는데, 만약 도쿄로 하면 그 동네에서 다른 서비스들도 다 써야되기 때문에 향후에도 꾸준히 문제를 야기할 것이다. 왜냐하면, 서버는 서울에 두고 도쿄에 데이터베이스를 두면 쿼리 날릴 때마다 얼마나 코스트가 크겠는가? 서버를 서울에 열어야 나중에 다른 것들 붙일 때도 서울에서 만들 수 있다.
옛날에는 분명 리전 옮기려면 온갖 오류가 다 나서 그냥 처음부터 올려버렸던 것 같은데
불행 중 다행히도 이미지로 구워서 다시 서울 리전에서 인스턴스 생성함으로써 해결했다.
두번째 실수 "Nginx가 왜 API 요청을 안하지..?"
리액트를 "npm run build" 한 후 Nginx 위에 올려두었더니 이 충실한 웨이터는 내가 잘 만들어둔 프론트 컴포넌트들을 고객님들께 서빙해줬다. 근데 문제가.. 이 친구는 프론트 컴포넌트만 서빙을 해주는 외골수라는 것이다.
Nginx가 POST를 안해요..
42서울 과제 중에 Nginx만드는 과제가 있어 기본적인 개념을 이해하고 있어서 나는 당연히 될줄 알았다. 하지만, 모든 것이 잘 되어가면 꼭 의심해보라는 선조들의 말씀답게 이 Nginx는 백엔드 API를 이악물고 무시했다. Nginx는 80(HTTP), 443(HTTPS) 포트만 듣고 3000으로 들어가는건 백엔드로 가라고 해놨더니 문 가장 앞에서 다 자기가 먹고있다. API로 가야되는 요청들을 Nginx가 가로챈다음 '이게 뭔지 모르겠으니 안함~'혹은 '이건가? 리액트 받아라!!'하고 있으니 복창터지는건 어쩔 수 없었다.
결국 conf 파일들어가서 온갖것들을 하나하나 수정함으로써 수정을 해냈지만, 장기적으로는 관리가 불가능할 것이라고 판단.
아예 아키텍처 전반을 엎어버리는 것으로 결론냈다.
자잘한 실수들
자잘한 실수들은 너무 많아서 셀 수도 없다.
처음에는 사실 VPC와 로드밸런서도 써보고 싶어서 온갖것들을 다 만져봤지만, 결국 나의 기술부채 문서만 추가할 뿐이었고
초창기 네트워크 포트 설정을 서버에서만 하고 AWS 방화벽은 안건드려서 반나절 고민한 적도 있었다.
SSL 설정은 인증서도 다 받았는데, EC2님 입맛에 안맞으셨는지 하도 뱉으셔서 결국 CertBot으로 선회해서 적용했다.
너무많은 실수들이 있었지만, 너무나도 고통스러운 기억이기에 머리 속에 깊이 남았다.
앞으로 어떻게 할 것인가?
- 돌아가는 것에 대해서 잘 배우자!
- Nginx만드는 Webserver 잘 만들어보자
- 네트워크 정확하게 이해하자
- 패키지 매니징 및 코드 관리 신경쓰자
- 상용 서비스 잘 이용하자
아직 배포못한 서비스는 S3 + EC2 + Route53 혹은 Vercel로 보내야겠다
'프로젝트 > 42프로젝트' 카테고리의 다른 글
15분이면 충분하다 배포방법(AWS EC2, Vercel) (0) | 2023.03.31 |
---|---|
비용을 아끼자(모닝글로리 웹페이지 제작 5) (0) | 2023.03.17 |
개발을 해보니 알 수 있는 아쉬움(모닝글로리 웹페이지 제작 4) (2) | 2022.11.29 |
어떻게 개발할 것인가?(모닝글로리 웹서비스 제작2) (0) | 2022.11.17 |
첫 회의와 Figma와의 첫만남(모닝글로리 웹서비스 제작 1) (0) | 2022.11.07 |