[항해 14기] 개발일지 56 (실전프로젝트 - 중간 발표)

실전프로젝트 4주차

 

1. 발표자료

- 노션 : https://team-spirits.oopy.io/dawhisky

[Da-Whisky] 위스키 체험을 위한 온라인 플랫폼

- 유저 UI 영상 : 

KakaoTalk_20230609_192623174.mp4

8.87MB

- 점주 UI 영상 :

KakaoTalk_20230609_192707152.mp4

3.71MB

 

 

 

2. 실전프로젝트 시작 이후 작업 내역

- 코드/깃 컨벤션 , api/기술/라이브러리 선정 등

- ERD/아키택쳐/스트럭쳐 설계

- EC2 배포+서버관리
- CI/CD환경 (github actions + aws codedeploy)
- HTTPS (aws Route53+ certificate manager + elastic load balancer)
- node.js+express(기본crud)
- swagger, sentry, socket.io

 

 

 

3. 멘토님 기술 질문-답변

1) AWS Server

🐳 : t2 small이나 medium으로 올렸는데, 나중에 실제 서비스를 한다고 가정했을 때 계속 부하가 증가할 경우 인스턴스를 스케일 업하는데는 한계가 있다. 스케일 업을 더이상 할 수 없는 상황이 된다면 그 이후에는 어떤식으로 확장을 할 예정인지?

🐤 : 일단 스케일 업이 꽤 큰 규모까지 가능한 것으로 알고 있다. 만약 그것으로 감당이 안된다면 로드밸런서를 통한 추가적인 트래픽 분산이나, nginx를 통해서 리버스 프록시를 따로 설정하여 그에 따른 요청 분산 작업들을 해줄 수 있을 것 같다.

🐤 : 우리 서비스 규모 정도에서는 AWS에서 기본적으로 제공하고 있는 스케일 업으로도 충분하다고 생각이 되어서 그 이후까지의 깊은 고려는 아직 해보지 못했다.

🐳 : 스케일 업을 꽤 큰 규모까지 진행할 수 있다고 말씀해주셨는데 그럼 거기까지는 무조건 스케일 업을 하는 방식으로 가는게 맞는지?

🐤 : 스케일 업을 했을 때 드는 비용과 트래픽 분산을 하는 비용을 비교해서 더 합리적인 선택을 하게 될 것 같다.

 

2) DB

🐳 : DB 선정 내용을 보면 수평적 확장의 여지가 거의 없기 때문에 RDBMS를 선택했다고 나와있다. 사용자가 많아졌을 때 웹서버는 비교적 부하 분산 처리가 쉬운데, DB는 그게 쉽지 않다. 보통 트래픽이 몰렸을 때 문제가 일어나는 경우는 DB 문제일 경우가 많다. 이 경우에는 DB를 어떻게 처리할지?

🐤 : 1차원적으로 생각해보면 DB 서버를 늘려서 해결할 수 있을 것 같다.

🐳 : DB 서버를 늘린다는게 수평적 확장이 RDBMS같은 경우는 그냥은 어려운데, 어떻게 할 수 있는건지?

🐤 : 아직 그 부분까지는 고려해보지 못한 것 같다.

 

3) sequelize

🐳 : sequelize.sync는 어떤 역할을 하는지?

🐤 : 설정한 모델과 DB 스키마를 서로 동기화시켜주는 기능으로 알고 있다.

🐳 : 프로덕션에서 사용해도 되는지?

🐤 : sequelize.sync를 프로덕션에서 사용하게 되면 테이블이나 컬럼들에 대한 수정/삭제가 이루어지면서 데이터 유실 이슈가 있을 것으로 예상이 된다. 프로덕션에서는 sequelize.sync를 직접 사용하지 않고 주로 마이그레이션 방식으로, 그래서 스키마에 대한 롤백도 가능하게 되고 스키마들에 대한 추적이나 변경을 좀 더 안정적으로 사용할 수 있다고 생각이 된다. 따라서 마이그레이션을 프로덕션 단계에서 사용할 것 같다.

 

4) CORS

🐳 : FE-BE 연동하면서 CORS 에러가 발생했었는지?

🐤 : 부분적으로 발생하긴 했는데 금방 해결되어서 전체적으로 봤을 때는 이슈가 없었다고 할 수 있을 것 같다.

🐳 : CORS는 왜 발생한다고 판단하는지?

🐤 : 동일 출처 정책에 의해서 서로 다른 도메인에서 리소스가 들어오게 되면 거절이 되는 매커니즘인 것으로 알고 있다.

 

5) que

🐳 : 줄서기 que를 구성했는데 살펴보니 RDBMS를 이용해서 하는 것으로 되어있다. 우리 웹 서버에 동시에 여러 명의 사람이 요청을 보냈을 때 그 요청이 들어온 순서대로 줄서기가 된다는걸 어떻게 보장할 수 있는지?

🐤 : 지금은 보장이 되어있지 않아서 개인 네트워크 상태에 따라 다른 사람이 먼저 신청을 했더라도 늦게 등록되는 이슈가 있을 것으로 예상이 된다. 아직 적용하진 않았지만 이런 것에 대한 보안책으로 트랜잭션을 사용하려고 한다.

🐳 : 트랜잭션을 어느 레벨에서 어떻게 사용할 예정인지?

🐤 : isolation level의 단계별로 얼마나 제한이 들어가는지까지는 정확히 기억나진 않지만, 첫 요청이 들어와 테이블에 대한 커밋, 쿼리가 진행될 때는 바로 요청을 받지 않고 lock을 걸어서 동기적인 처리로 진행될 수 있도록 생각하고 있었다.

🐳 : 그러면 다른 줄서기 요청이 DB에 쓰여지고 있는 상황에서는 중간에 오는 요청들은 뒤에 줄을 서서 순차적으로 처리가 되게 되는지, 아니면 오류가 발생하는지?

🐤 : 줄을 서서 순차적으로 처리되게 구상을 하고 있다.

🐳 : 이 부분은 적용을 해봐야지 대답이 가능할 것 같다.

 

6) internal architecture

🐳 : 백엔드의 internal architecture를 구성한게 쉽게 말하면 폴더 구조다. 이 구성요소들 하나하나를 왜 이렇게 설계했고, 이 구조가 어떻게 우리 앱을 개발하고 서비스하는데 도움이 되는지 설명해달라.

🐤 : 기본적으로는 처음에 3 layer architecture로 선정을 했었고, 선정 이유는 서비스가 작다면 한가지 라우트에 모든 로직을 담아도 생산성이나 유지보수 측면에서 나쁘지 않을 것이다. 하지만 서비스가 점점 커지고 복잡해지고, 로직이 많아지고 개발에 참여하는 인원이 많아질 수록, 즉 로직들에 대한 계층화와 모듈화가 많아질수록 협업 효율이나 생산성, 유지보수에 적합하게 변경이 되어간다고 결론을 내렸다. 무엇보다 테스트코드를 작성할 때 단위 테스트에 용이하다고 생각을 해 3 layer architecture를 선정하게 되었다.

🐤 : controller 같은 경우는 유저와 req, res를 받는 계층이 될텐데 클라이언트와 통신하는 계층의 로직을 넣어두었다. service에서는 대부분의 핵심 로직이 들어가게 된다. repository는 DB와의 통신을 주고 받는 계층으로 구성했다.

🐤 : model은 mysql의 데이터 스키마를 sequelize로 스키마 작업을 하기 전에 설정을 해놓는 폴더로 제작을 했고, module은 다른 계층에서 공통으로 자주 사용하는 로직들을 모듈화시켜서 넣어두자는 의도로 사용했다.

 

7) redis

🐳 : redis도 다양하게 사용할 예정이라고 말씀해주셨는데, redis의 자료구조를 알고 계신대로 설명해달라.

🐤 : redis의 자료 구조 부분까지 고려해서 redis를 선택했다기보다는 redis를 선택하게 된 이유 중 하나가 cache 전략을 사용하기 위해서였다. 질문주신 부분은 좀 더 공부가 필요할 것 같고, cache 전략 부분을 좀 더 말씀드리자면 DB에 자주 사용되는 몇가지의 정보들을 미리 cache화 시켜두면 DB의 부하를 줄일 수 있고 속도를 개선할 수 있다는 내용이 있어서 디바이스 토큰이나 push 알림은 자주 사용될 것으로 예상되는데 업데이트가 크게 필요하지 않은 부분에 cache 전략을 쓰기 위해 redis를 사용했다.

 

8) elastic search

🐳 : elastic search 도입을 하고 있는지?

🐤 : 처음에 준비를 하려고 했으나 생각보다 스코프가 너무 커지는 것 같아 이전 멘토링을 받았던대로 인덱싱 정도로 축소하기로 했다. 인덱싱은 지금 작업 중에 있다.

🐳 : 스코프 내에 괜찮을 것 같은지?

🐤 : 인덱싱은 괜찮을 것 같다. 다음주 중에 적용 예정이다.

 

 

 

4. 향후 방향성

- 스코프의 확장이나 추가적인 기술의 도입도 좋지만, 그동안 진행해온 스코프들에 대한 리팩토링/최적화를 진행하기로 결정