일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- https
- wil
- nginx
- Load Balancer
- MYSQL
- JavaScript
- Nodejs
- reduce
- TypeScript
- it
- 노마드코더
- npm
- elb
- nomadcoder
- 조건문
- 프로그래머스
- mongoose
- mongodb
- 자바스크립트
- Joi
- AWS
- 항해99
- JWT
- 메소드
- 타입스크립트
- Node.js
- ubuntu
- CORS
- 생활코딩
- java
- Today
- Total
V-logue
[항해99] WIL(Week I Learn) - 13주차 본문
항해99 실전주차가 끝나고 최종 프로젝트 발표까지 나름 성공적으로 마쳤다.
더 많은 기술을 사용하고 싶었고, 더 퀄리티 있는 코드를 짜보고 싶었지만 시간상의 여건으로 다 구현할 수는 없었다.
Project renDev
Project renDev는
랑데브는 포트폴리오를 위한 협업 프로젝트를 찾는 개발자와 디자이너를 매칭해주는 서비스다. 사이드 프로젝트를 해보고 싶을 때, 비전공자나 이제 갓 개발에 입문한 사람들은 팀원을 구할 곳이 부족하다는 점을 깨달았고, 이런 개발자들을 위해 함께 프로젝트를 진행할 팀원을 구할 수 있는 서비스를 만들어보자는 생각에서 랑데브 프로젝트를 만들게 됐다.
항해99 7기 B반 2조 프로젝트 renDev - YouTube
내가 담당한 작업은
- 서비스의 유저와 관련된 전반적인 API 개발
- 이메일 인증 기능 개발
- Refresh Token을 사용한 로그인 기능 개발
- 마이페이지의 예약과 관련된 기능을 제외한 API 개발
- 서버 보안과 관련된 모듈 작업(Cors, Bcrypt, Helmet 등)
- Node.js + AWS ELB + Nginx를 활용한 HTTPS 서버 구축
- Artillery를 통한 스트레스 테스트 결과를 토대로 response 속도 개선
- Array 함수를 이용한 필터링 형식의 검색 기능 개발
내가 담당한 작업은 위와 같은 정도가 있다.
일단 기본적으로 더 많은 기능을 담당하기에 우리 프로젝트는 각자간 분업이 확실하게 잘 되있는 편이었고,
시간적으로도 거창한 기능을 개발해 프로젝트에 접목시키기에는 어려웠기 때문에 저정도가 한계였다.
이번 프로젝트를 진행하면서 나를 제일 괴롭혔던 것은 Refresh token 작업이었다.
httpOnly로 진행하고 크로스 도메인이라는 개념에 대해서 문외한이었고, 마냥 그렇게만 작업해야 한다는
인식만 가지고 있었기 때문에 너무 많은 시간을 헤매게 됐다.
애초에 서버는 배포된 EC2 환경이고 클라이언트인 프론트 작업은 각자의 집에서 로컬로 하고 있으니 설정을
비교하기가 참 곤란한 상황이 맞았다.
Elasticsearch를 활용한 통합로그시스템을 구축하고도 싶었고, Nginx로 로드밸런싱도 대신 해보고 싶었다.
이것 말고도 소셜로그인 기능도 완전히 작동되게 만들어보고 싶었고 하고 싶었던 것은 정말 너무 많았다.
이번 프로젝트를 진행하면서 제일 아쉬웠던 것은 Typescript를 사용하지 못한 것이다.
프로젝트 초반부터 했으면... 하는 이런 가정은 시간이 지났으니 의미없어서 논외로 하고,
일단 TS를 배워보고 이번 renDev 프로젝트를 TS로 바꿔보는 작업을 시도해볼 생각이다.
서비스 아키텍쳐
FE
간단하게 설명 프론트 UI/UX 제작 라이브러리는 리액트를 사용하고 리덕스로 상태관리. https로 배포하기 위해 AWS의 CloudFront를 사용하고 S3로 배포
BE
Node.js Express 프레임을 기본으로, 따로 툴 설치가 필요 없는 Github action 및 AWS로 관리가 가능한 CodeDeploy와 CodePipeline을 이용해 CI/CD를 구축하여 배포를 자동화하고 PM2를 사용하여 무중단 서비스를 유지
서비스 내 다양한 조건 쿼리와 프로젝트와 다수의 참조관계로 인한 릴레이션의 필요성, 데이터 정합성에 대한 요구로 RDBMS 도입을 결정하고 정규화를 진행, 병목 완화를 위해 인메모리 저장소 캐싱을 검토하며 다양한 자료형을 사용할 수 있는 Redis를 사용하는 것이 합리적이라고 판단, 주요 조회 응답을 Cache - Aside 방식으로 캐싱 그리고 완전 관리형 서비스로 Azure Cache for Redis를 도입
Nginx는 외부에서 요청이나 응답이 어디에서 온 것인지 알 수 없게 들어온 정보를 nginx의 80포트 proxy서버로 먼저받아 서버가 사용하는 실제 포트를 숨겨주는 nginx의 보안기능과, http 80포트로 요청이 들어오면 https 443포트로 Redirect 해주기 때문에 https 서버를 구축, 지원하는 등의 목적으로 사용
WebRTC 기반의 영상통화 기능은, 혹시 발생할지 모를 서버 성능의 이슈를 고려하여 백엔드의 메인 node.js 서버와 별개의 인스턴스에 구현하는 것으로 결정
참고로 서비스 아키텍쳐는 내가 만들었다.
GTQ를 따고 어디다 쓸곳이 없다고 생각했는데, 막상 이럴때 사용하고나니
세상에 배워서 쓸모없는 것은 아무것도 없다는 생각이 들었다.
🔧 기술적 의사결정
CloudFront | 사용자에게 제공되는 정적 컨텐츠의 전송 속도를 높이고 https를 적용시키기 위해 사용하였습니다. |
MySQL (RDS) | 서비스 내 검색, 매칭 기능 등 다양한 조건에서의 조회 쿼리와 프로젝트와 지원자 간의 ‘지원 관계’, ‘매칭 관계’, ‘제안 관계’ 등 다수의 참조관계로 인한 릴레이션의 필요성, 데이터 무결성 - 정합성에 대한 요구로 RDBMS 도입을 결정하고 데이터베이스 정규화를 진행하였습니다. AWS RDS for MySQL을 도입함으로써 추후 단계적 스케일링 측면과 자동 백업, 복원 등 데이터 관리를 용이하게 하였습니다. |
sequelize | Node.js 환경에서 RDB 사용에 있어 자바스크립트 객체와 테이블을 매핑하는 모델을 생성하여 직관성과 재사용성을 갖추고, RAW QUERY와 sequelize 메서드를 적절하게 혼용하여 생산성을 증대했습니다. |
Redis (Azure) | Cache - Aside 정책으로 서비스 내 주요 조회 관련 비즈니스 로직 데이터를 인메모리 저장소에 캐싱함으로써, 지역성을 고려하여 파레토 법칙에 의해 최소한의 캐시 관리 비용으로 서버 - DB간 네트워크 부하 분산과 조회 성능을 크게 개선하였습니다. 완전 관리형 서비스로 Azure Cache for Redis로 Redis를 이관함으로써 추후 확장성과 클러스터링을 고려하였습니다. |
Jest - Supertest | CI / CD와 테스트 피라미드를 고려한 유닛 테스트, 통합 테스트 작성을 위해 Jest와 Supertest 라이브러리 메서드를 이용했습니다. 유닛테스트의 경우 mocking을 이용해 인프라 독립적인 테스트 환경을 조성하고, 통합테스트의 경우 테스트 스크립트 실행 시 인프라 환경을 분리 자동화하였습니다. |
CI - github action | Github 자체적으로 지원해주는 CI기능을 사용하여 pull request시 충돌을 자동으로 확인 해주는 workflow를 사용했습니다. |
CD - AWS CodeDeploy - CodePipeline | CI부분 기능이 끝난 후 AWS에 CodePipeline을 사용하여 Github 웹후크를 설정하여 main 브랜치에서 변경되는 코드가 발생 시 EC2 메인서버에 변경된 코드를 배포할 수 있게 자동화 했습니다 |
nginx | elb를 통해 전달된 트래픽이 서버 앞단에 위치한 Nginx로 들어오고, nginx가 뒤쪽의 서버에 전달시켜주는 방식으로 사용, Nginx가 서버 앞단에 위치했기 때문에 데이터를 먼저 받아주고 걸러주기 때문에 보안적으로 더 우수하고, https 통신이 아니라면 http통신으로 Redirect 해주는 장점이 있습니다. |
socket.io | 인터뷰 기능의 텍스트채팅 및 WebRTC 영상통화를 위한 시그널링, Room 기능을 통한 인터뷰 방 관리에 활용하였습니다. |
WebRTC | 영상통화 기능의 구현, Kurento나 openVidu 등을 사용하지 않고 WebRTC의 기본 기능으로 해결하였습니다. |
coturn | 공개 STUN/TURN 서버들의 안정성이 낮아, coturn을 활용하여 자체적으로 TURN 서버 구축하였습니다. |
서비스 설명은 여기까지.
참 아쉽다면 아쉽고, 만족스럽다면 만족스러운 실전 6주차의 시간이었다. 미니와 클론코딩 때 못느꼈던 위기감과 협업이라는 것의 진정한 의미, 발표가 끝나고 드디어 끝났다는 성취감과 안도감 등
많은 감정을 느끼게 했고, 좋은 경험을 한 시간이었다. 더 많은 기능을 했으면 좋겠지만, 이건 내 욕심이고
앞으로 더 많은 도전과 공부를 통해서 지금보다 더 수준 높은 서비스를 만들어 보고 싶다는 욕심이 들었다.
어렵고 힘든 것들을 뒤로하고, 우리 팀정도면 나쁘지 않았다라는 오히려 그 중에는 잘한 것 같다는
뿌듯한 생각과 함께 6주간의 실전프로젝트가 마무리됐다.
항해99는 지원주차를 포함해 딱 일주일이 남았다.
처음 시작할 때는 이렇게 지능이 낮아도 괜찮은가 싶었지만, 하다보니 CRUD 머신이 되버렸고 새로운 것을
배우고 적용시키려는데 주저하던 마음이 사라졌다. 이렇게 해서 개발자가 될 수 있을까 싶던 생각들이
앞으로도 열심히만 하면 될 수 있을 것 같다는 긍정적인 방향으로
자리잡았다.
남은 일주일 지원주차도 잘 마무리해서 좋은 결과를 얻을 수 있으면 좋겠다고 생각한다.
끝
'항해 99 > Week I learned(WIL)' 카테고리의 다른 글
[항해99] WIL(Week I Learn) - 8주차 (0) | 2022.07.04 |
---|---|
[항해99] 항해 Week 1 (0) | 2022.05.15 |