[목표]
AWS 오토스케일링 적용하기(CORS 해결하기)
멘토님께 메일 보내기
과부하 발생기 확인을 위한 비주얼 도구 도입
MVP 2차 발표진행
피드백 정리해서 뭘해야할지 정하기
10:30 ~ 12:00
발표준비를 진행중이다. 어제 작성한 스크립트를 확인하고 있다. 그냥 스크립트를 읽어보니, CI/CD 로직 설명까지 6분정도 걸린다. 근데, 직접 시연하면서 진행하면 간당간당할 것 같기도 하다… 여러번 연습해서 제시간 안에 할 수 있도록 준비해보겠다.
12:00 ~ 13:00
식사를 하고 왔다.
13:00 ~ 14:00
MVP 2차 발표를 대비하고자 여러번의 발표 시뮬레이션을 진행했다.
MVP 2차 발표 (14:00 ~ 16:00)
1조
스타일링 스티커 메모가능, 아바타 2D 렌더링 가능, 토스API를 통해 결제 또한 가능.
기술적 챌린지
Nextjs, nodejs, spring, mysql, FastAPI 를 사용중이다.
모델 추론과 무거운 작업의 응답성을 저해하고 있다.
기술적 챌린지
이미지 최적화, 많은 수의 정적 제품 이미지 -> 작은 이미지의 경우 리사이즈, 자주 표시될 인기 상품은 캐싱
서버부하 문제
비동기처리와 캐싱
피드백
웹브라우저 기반으로 돌아가죠 폼팩터가 다양할 수도 있는데, 어떻게 구현할지?
→ 폴리싱에서 동적으로 구현하여 모바일에서 사용가능하게 만들 예정
이미지 같은 경우 어떻게 가져올 예정인지?
→ 무신사에서 스크랩을 통해 데이터를 확보하고자 한다.
렌더링 화면에서 새로고침하면 어떻게 되나요?
→ 새로고침하면 계속해서 렌더링되고, 모두 완료되면 보여준다.
2조 (우리조)
기능이나 개발이 엄청 많이 되고 풍부한건 이해가 간다.
그러나...
1. 어떤걸 어려워했고 어떻게 해결해 나갔는지에 대해 설명할 것
2. 내용이 많아서 이해가 잘 되지 않는다. 지라와 같은 서비스를 구현했다고 언급하기
3. 이슈 처리 프로세스에 대해서 더 명확히 설명하는게 좋겠다. 너무 빨라서 이해가 잘 되지 않는다.
4. 너무 양도 많고 어느정도 이해 안되는 부분이 많아 피드백을 할 수가 없다.
5. 사용자 시점에서와 프로젝트 자체에서의 관점을 나누어서 극명하게 설명하는 것이 좋다. 처음 보는 사람이 보았을때에는 사용자인지 CI/CD에서 검사되는 것인지 잘모르겠다.
6. 구현과정에서 어떤 문제가 발생했고, 어떻게 해결했는지에 대해서 보강하자.
7. 소나큐브나 이런 검사는 했다라는 의미로 충분할 듯하다.
→ 일단 양이 너무 많아서 정신없이 이야기한 감이 있다. 그래서 처음보는 사람 입장에서는 이해못할 것이다. 난 저번주에 기술적 챌린지나 어떤 서비스인지에 대해 설명을 모두 했기 때문에 어두 다 짤라먹고 바로 이슈 처리에 대해 설명했는데, 생각해보니 처음보는 사람은 모를 수 있겠다는 생각이 들었다. 이해가 잘 안되서 주력적인 피드백을 받지 못한게 아쉽다. 아이텐티티가 필요하다.
시나리오 재점검해야한다!
나중에 밤에 오셔서 동석코치님께서 따로 피드백해주셨다 :)
3조
3조 같은 경우 내용이 풍부했는데, 우리 피드백 적느라 작성하질 못했다.
기술적 챌린지
동시 편집에서 커서를 함부로 조작하지 않게끔 어떻게 구현할 것인가?
4조
핵심 기능
러닝크루 기능
자유모드와 트랙모드 사용가능
봇과의 대결이나 유저끼리의 대결 가능
트랙의 종류
로컬 트랙과 서버 트랙이 있다.
초기 시작시, 트랙 추적과 대결 모두 가능하다. 달리기가 완료되면 랭킹 올리는것도 가능하다.
경로에 벗어날 경우 자동 정지된다.
직접 시연
로컬에 있는 트랙과 용인시에서 제공하는 서버 트랙이 있다.
친구 사이의 거리도 볼 수 있다.
문제들
GPS가 간헐적으로 연결이 안된다.
지동 경로에 따라 봇이 움직여야 하는 문제(시뮬레이션)
수많은 트랙을 어떻게 저장하는가? 목록 불러올시 시간이 너무 오래 걸린다. → 시간 단위로 마커를 통해 트랙을 가져오고 저장하도록 구현
폴리싱
속도 초과시 중단, 포인트 상점, 친구와의 대결 등을 구현할 예정이다.
5조
음악 플랫폼이다.
메인 화면에서 공연 정보들 확인가능하다.
바이닐: 릴스와 비슷하다. 그런데 합주 기능이 들어간 릴스? 약간 에프리씽 같은 느낌인것 같다.
인코딩이 엄청 오래걸린다…
FFmpeg를 사용해서 인코딩을 해야하는데, 서버보다 각 디바이스 환경에서 실행되도록 했다.
자신이 파생된 부모 영상을 재귀적으로 모두 찾아 편집 시에 사용
정확한 목표 파이프 라인 소개를 해야할 것 같다.
주력적으로 미는 서비스가 뭔지 잘 모르겠다.
동영상 합주인지 뭔지…
채팅과 바이닐(동영상) 등 너무 다양하면 어디가 주력인지 파악하기 어렵다.
서비스의 아이덴티티를 정해서 그부분을 완벽하게 구현해서 결과를 내보내는게 좋겠다.
다른 레버런스 사이트와 단점을 열거 했으면, 다음장에는 우리 사이트의 장점에 대해서 어필해야되야 하지 않았나.
그럼 그 사이트보다 더 나은 부분을 디테일하게 설명해야한다.
다른 사이트 저격하는건 좋지 않다.
리엑트 네이티브 왜 썻나?
→ [답변] 모바일 최적화를 위해서 각종 포퍼먼스를 위해서 했다.
→ [코치님] 조작성 엉망이고 모바일이 더 힘들다. 그럼 모바일을 꼭 써야하는 이유를 가져오던가 아니면 웹으로 가져오던가 해야한다.
기술을 쓰려면 이유가 있어야한다.
16:00 ~ 20:00
발표를 끝내고 휴식기를 가졌다. 게임도 하고 식사도 하며 시간을 보냈다.
20:00 ~ 22:00
전화통화를 좀 오랫동안 했다.
22:00 ~ 24:00
오토스케일링을 하기 전에 지금까지의 내용을 정리해서 벨로그에 올려 보겠다.
할려고 했는데, 동석코치님이 오셔서 오늘 발표에 대한 피드백을 구체적으로 하셨다. 자동화에 있어서 어떤 문제가 있는지, 각 역할별로 쓰는 방법과 칸반보드의 진행 척도가 다를수도 있다는 등의 피드백이 있었다.
해당 사항에 대해서 팀단위 회의를 했다.
지금까지 생각한 프로젝트의 아이덴티티는 뭔지, 어떤 방향성을 가질 것인지. 시나리오를 어떻게 작성하는게 좋을지 고민을 해보았다.
→ 공통적으로 생각한건 Jira를 공부하여 우리만의 방식으로 재해석하는 것이라는 포인트이다. 우리는 현업적 관점보다 우리와 비슷한 미니 프로젝트를 진행하는 사람들을 위해 좀 더 간편한 이슈트레킹 서비스를 제공함에 있다는 것이다. 그래서 우리는 해당 흐름을 코치님들이나 오신분들을 이해시키기 위해 적합한 시나리오(스토리)를 구상하기로 했다.
내일 점심 먹고 다같이 이야기 하기로 했다.
24:00 ~ 02:00
이제 방금 코치님과 팀원들과 이야기한 내용을 정리하고, 지금까지 밀렸던 벨로그를 올려보도록 하겠다.
다쓰고 일찍 일어나 너무 졸려서 자러가야겠다.
AutoScaling 지금까지 진행된 내용 요약
시점을 바꿔서 AWS 자체에서의 문제점이 있는지 확인해보았다. 생각을 해보니 도메인으로 들어오는건 같은데, 아이피를 따로 한다는게 말이 안된다. 그래서 CloudFront의 도메인이 접속되는지 확인해보았다. 확인결과 접속이 되지 않았다. 더 자세히 찾아보니, CloudFront에서부터 따로 나눠져서 보여지면 안된다. 들어오는 입력은 같은 도메인으로 들어가고, 로드밸런스까지 와서 분배되어야한다.
결론적으로 CloudFront 도메인을 하나만 남기고, Nginx로 80번포트로 매핑해도 안되니, Amazon Q의 조언대로 기존의 EC2 AMI를 그대로 복사하여 오토스케일링하니 정상작동 했다. 그 내용을 적어보았다.
[문제1] 초기 문제
- CloudFront 도메인 d1yf3se408yzed.cloudfront.net에서 간헐적으로 접속 문제 발생
- 브라우저에서 HTML 대신 React Server Components(RSC) 원시 데이터가 표시됨
- d2djc852ku1iix.cloudfront.net은 Staging 배포로 접속 불가
수행한 해결 작업
- CloudFront 설정 최적화
- 캐시 정책을 CachingOptimized에서 CachingDisabled로 변경 (동적 콘텐츠용)
- SSL 프로토콜 최적화 (SSLv3 제거)
- 전체 캐시 무효화 실행 (/*)
- Staging 배포 정리
- d2djc852ku1iix.cloudfront.net 배포 비활성화 (Staging 배포였음)
- 인프라 문제 해결
- ALB와 타겟 그룹 상태 확인 (정상)
- 오토스케일링 그룹 상태 확인
[문제2] 핵심 문제 발견
오토스케일링으로 생성된 새 EC2 인스턴스에서 RSC 데이터 반환
- 기존 인스턴스: 정상 작동
- 새 인스턴스: RSC 데이터 반환
- ALB 로드밸런싱으로 간헐적으로 문제 인스턴스에 요청 전달
[문제3] 근본 원인 파악
프론트엔드 nginx.conf 파일의 하드코딩된 IP 주소 문제
- nginx 설정에 특정 EC2의 IPv4 주소가 하드코딩됨
- 새로운 인스턴스에서는 백엔드와 통신 불가
- 결과: Next.js SSR 실패 → RSC 데이터 반환
해결 방법 적용
- 정상 인스턴스 기반 AMI 생성: ami-0b60678d2e83db79e
- Launch Template 업데이트: 새 AMI 사용하는 버전 10 생성
- 오토스케일링 그룹 업데이트: 새 Launch Template 버전 적용
- 인스턴스 새로고침: 기존 문제 인스턴스를 새 AMI 기반으로 교체
사용자 발견한 해결책
"프론트엔드 nginx.conf 파일에 해당 EC2 IPv4 주소를 입력하고 npm 빌드와 pm2로 실
행하니 오토스케일링 서버도 정상 작동!"
[문제4] 현재 남은 문제
- CloudFront에서 여전히 간헐적으로 RSC 데이터 반환
- 캐시 무효화를 했음에도 text/x-component 타입이 캐시됨
- 직접 인스턴스 접속은 정상, CloudFront를 통한 접속에서만 문제
현재 상태: 근본 원인은 해결했지만, CloudFront 캐시 문제가 완전히 해결되지 않은 상황입니다.
문제4 해결은 피곤하여 내일로 미뤘다. CloudFront 헤더값 지정으로 해결했다.
