성준이의 개발블로그 성준이의 개발블로그

도입 배경기존 로컬에서 API 개발, 연동을 할 때, 에러가 발생하게 된다면 로그를 보고 에러를 잡았었습니다.배포 환경에서는 VM에 들어가서 에러를 봐야하기 때문에 개발자가 직접 VM에 들어가서 로그를 보는 것이 번거로웠습니다.사실 실무 프로젝트는 아니고 개발자들도 운영환경의 VM에 접근할 수는 있지만, 역할기반제어 차원에서도 prod 환경 VM에 개발자가 접근하는게 좋을 거 같지 않다는 생각도 있었습니다.그리고 가장 결정적으로 서비스에 장애가 발생하였을 때, 빠른 대응을 하는 것이 꼭 필요하기 때문에 도입하게 되었습니다.구현 과정우선 디스코드에 에러가 발생할 때 마다 알림을 보내기 위해서는 다음 내용들이 필요했습니다.Spring 로그에서 ERROR 가 생길 때마다 탐지하고 ERROR 부분 추출하는 로직..

문제 원인맥에서도 크롬 브라우저를 사용해서 발생하는 문제였습니다.IME 관련 문제였는데IME가 뭐냐면IME(Input Method Editor)는 조합이 필요한 글자(영어빼고 웬만한 한국어 중국어 일본어) 작성에 사용되는 에디터입니다.이 에디터에는 조합 여부를 판단하는 "e.nativeEvent.isComposing" 이라는 필드가 있는데 MacOS의 크롬 브라우저에서는 이게 true일 때 엔터를 누르면 두번 입력되는 문제가 발생합니다.자세한 내용은 다음 블로그를 참고하면 됩니다. 아주 잘 정리가 되어있었습니다.https://velog.io/@darr/React-onKeyDown-한글-입력-시-두번-실행되는-문제해결과정TexfField의 OnkeyDown에 !e.nativeEvent.isComposing..

기존 방식기존에는 CODEOWNERS 파일을 만들어 dev 브랜치와 main 브랜치에 다른 리뷰어를 할당하고 있었습니다.dev브랜치 CODEOWERS 파일# .github/CODEOWNERS* @100-hours-a-week/Newsum-Femain브랜치 CODEOWERS 파일# .github/CODEOWNERS* @100-hours-a-week/Newsum-Admin이렇게 할 때 CODEOWNERS 파일에는 조건문 설정이 불가능하기 때문에dev → main 브랜치로 PR을 보낼 때, 파일 내용이 달라서 충돌이 발생하였습니다.그래서 yml 파이프라인을 통해 조건문을 설정하여 브랜치 별로 리뷰어가 다르게 설정하게 수정했습니다.현재 방식현재 방식은 yml 파일로 파이프라인을 만들어 브랜치별로 리뷰어로 할당되..

이전 Infisical을 통한 React + Vite CI/CD의 포스팅의 느낀점으로 썼던 PR돌 때 CI/CD 파이프라인이 전부 도는 것이 이상하다고 생각하고, PR 올라갈때 CI 파이프라인이 돌고, Merge 되었을 때 CD 파이프라인이 도는게 맞다고 생각하여 파이프라인을 분리했습니다.기존 파이프라인은 다음과 같았습니다.기존 통합 파이프라인name: Frontend CI/CD# 풀리퀘 할때 트리거on: pull_request: branches: [ dev ]jobs:# 빌드 과정 build: runs-on: ubuntu-latest steps:# 레포에서 Github Runner 서버로 코드 전송 - uses: actions/checkout@v3 # Infisical ..

목표 아키텍처사용 비용 요약표서비스사용 항목 / 조건월 예상 비용비고S3스토리지 100GB + 요청 110만건 + Select 110GB$3.53Standard, PUT/GET/Select 포함CloudFront300GB 사용자 전송 / 오리진 30GB$1.80캐시 미스율 10%, 아태 리전VPC Peering리전 내 30GB + 아웃바운드 300GB$38.40Spring→AI 통신 포함OpenVPN2명 동시접속, 9~18시 EC2$0.00Free Tier, AMI 포함 2명 무료CodeDeployEC2 배포 (온프레미스 없음)$0.00무료ECR500MB 미만 이미지 1개$0.00리전 내 EC2 Pull, 스프링 전용Route531개 퍼블릭 호스팅 존 + 15만 DNS 요청$0.50쿼리 100만건 프리 ..

구축할 아키텍처현재 구축할 아키텍처는 다음과 같은데요, 구성하기전에 2달에 100만원인 예산에 맞춰서 해야하기 때문에, 먼저 사용자 1000명을 기준으로 AWS calculator로 비용을 대략 계산해 보았습니다. 사용 비용 요약표서비스월 예상 비용 (USD)사용 스펙 요약입니다.S33.53100GB 저장, 100K PUT, 1M GET, S3 SelectCloudFront1.80300GB 전송(캐시 미스 10%), 300K 요청Transit Gateway153.96VPC Attachment 3개, 31.5GB 트래픽OpenVPN0.00EC2 t2.micro, 하루 9시간 (2유저 무료)CodeDeploy0.00온프레미스 미사용 → 무료ECR0.00Spring 이미지 Route530.50퍼블릭 호스팅 존..

문제 상황원래 SpringBoot의 resoureces/static 파일 아래에 React build 결과 나온 파일을 넣어 통합 배포를 하고 있었습니다.이때는 Swagger가 잘 나와서 문제가 없었는데 nginx를 통한 통합 배포를 하며 오류가 발생했습니다.현재 상황은Nginx에 프론트 빌드 파일을 올려 배포하고 nginx의 proxy_pass 설정을 통해 같은 인스턴스의 SpringBoot로 /api 요청이 들어오면 http://localhost:8080/api 로 보내주는 설정을 해두고 있었습니다.location /api/ { proxy_pass ; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-..

문제 상황S3 Public으로 열어두고 특정 도메인에서만 접근이 가능하게 설정을 해두다가, CloudFront를 붙여 CloudFront에 캐시된 이미지만 불러오게 하려고 했습니다. 그래서 DB에 저장되어 있는 이미지 URL을 S3주소에서 CloudFront 주소로 수정해줬습니다. 그랬더니 이미지가 어떤 거는 보이고 어떤 거는 안보이는 문제가 발생했습니다.문제 원인브라우저 콘솔 상에 오류 내용을 확인해보니 CORS 에러가 나오고 있었습니다. 분명 S3에 CORS 설정을 해두었는데 왜 안되지? 싶었습니다.해결 과정그래서 S3 - 권한 - CORS 설정에 들어가보니 잘 구축되어 있었습니다. 그래서 CloudFront도 CORS 설정을 해두어야 이미지가 잘 나오겠다 싶어서 CloudFront에도 CORS 설정..