퀴즈세트를 등록하고 나서, 추가 요청이 없는데도 불구하고 이미지 로딩이 안되는 문제가 발생했다. 확인결과 s3에서 원본 파일이 삭제되었다는 것을 확인할 수 있었다.또한, 퀴즈 세트 썸네일을 변경하고 나면 5분 뒤에 변경된 이미지도 삭제되는 현상이 발생했다.현상은, 저번

현재 프로젝트 팀원들은 각자의 할 일을 열심히 하며 별 신경쓰지는 않지만, 현재 배포되어 있는 lambda의 초 회 응답속도가 평균 4~5초가 걸린다.과연 서비스 중인 사이트의 응답속도가 4~5초 걸리는 경우가 얼마나 있을까. 이는 내가 사용하는 lambda의 고질적인

들어가며 aws 클라우드의 모니터링은 자사의 cloudwatch 말고도 아래 등등의 모니터링 플랫폼을 사용할 수도 있다.가장 큰 차이점은 비용일텐데, 가령 cloudwatch는 사용량에 따른 요금을 부과하지만 datadog과 new relic 등은 구독형 지불 방식(

짜잔.. 분명히 구매 후 최대 3일 걸릴거라고 고지했으면서 10분만에 뚝딱해주다니.. AWS는 역시 빠르다. 구입한 도메인은 하나를 api 서버 엔드포인트, 하나는 amplify에 붙여 서비스 도메인으로 사용할 예정이다. amplify는 프론트 파트에서 작업할 것이고

들어가기 앞서.. VPC가 괴롭혀요 오늘이 11일이고, vpc 접근 제한 설정을 시작한 것은 9일이다.. 정말 많은 시간을 할애해서 aws vpc관련된 많은 정보들을 알 수 있었고, 경험했고, 아직 부족함을 뼈저리게 느끼게 되었다. 기능이 어느 정도 구성되고 난 후

나흘 정도 장염에 걸리는 바람에 아무것도 할 수 없었다. 어제야되서 겨우 응급실을 가 진통제를 처방받으니 급진적으로 호전되고 있다. 덕분에 작업을 좀 다시할 수 있을 것 같다!학부생부터 코드를 이리저리 작성하였는데, 돌이켜 본 결과 다른 것들은 차츰차츰 실력이 좋아졌지

성능 테스트의 필요성 catchx2 프로젝트에서 가장 중요한 문제집 작성과 문제집 풀기 로직을 작성하면서, api 호출에 대한 부하 테스트의 필요성을 느꼈다. 특히 하나의 문제집에 10개 내의 문제, 그리고 각 문제에 대해 4개 내의 정답지가 존재하므로 이를 반복함수

대충 프로젝트의 뼈대가 구성된 것 같다. 이제 개발의 프로세스를 확립하여 기존 코드 작성에서는 ci가 수행되도록 하고, 어느 정도의 개발 이후 cd를 추후에 고려해야 할 것이다. 그래서, 오늘은 github action으로 ci 파이프라인을 고려해보고자 한다. 프로젝

여태까지의 개발은 1인 개발이었기도 하고, 기능 구현 우선적인 환경에서 작업하느라 테스트와 관련된 준비를 할 수 없었다. 그래서 테스트라는 것은 내가 따로 프로젝트를 시작하면 가장 하고 싶은 것들 중 하나였다. (다른 것으로는, 자동화, 로그수집 및 분석, 알림 서비스

TypeDI TypeDI는

이전에 SAM으로 관리했던 lambda 서비스의 형태를 다시 생각해보며 기존에 초기화 하였던 프로젝트를 SAM으로 관리할 수 있도록 하기로 했다. AWS 관련 서비스 준비 SAM init으로 접할 수 있었던 위의 초기 프로젝트를 저번에 구축했던 typescript

SAM template.yaml anantomy 분석하기 아래는 SAM 구축에 필요한 template의 명세를 나타낸 것이다. 다른 옵션은 중간에 필요할 때 활용할 수 있을 것 같고, 가장 중요한 Resources 영역을 한번 더 확인해보자. https://docs.

관련 패키지 설치express로 초기화 된 app에 use 함수를 사용하여 등록하는 과정을 거침+ tsconfig.json의 컴파일 옵션에서 "resolveJsonModule": true 설정을 하여야 json을 import 할 수 있음위와 같이 express app에

지금까지 aws 의 각 서비스가 어떤 역할을 하는 지 알아보았다. 사용할 만한 서비스로, 다음과 같은 종류가 있다 1) cloudfront : s3와 같은 storage 파일들을 여러 region에서 캐싱(?) 하여 요청과 가장 가까운 지역에서 파일을 전송해

https://travis.media/developing-aws-lambda-functions-locally-vscode/ 의 내용을 수행하며 정리한 내용이다. sam 설치 docker 설치 - 윈도우는, wsl 2 버전으로의 업데이트를 msi로 꼭 해주어야 도커가

결론적으로 무난하게 사용할 수 있다고 판단되어 구축을 시작하려고 한다. 그전에 확인해야 하는 것은, 기존 nodejs에서 사용하던 것과 다르게 DI, IOC 를 적용하기 위해서 어떤 작업이 필요한지 알아봐야 했다. 이전 지표 상의 이유로 express를 사용하지 않으려

바이럴 컨텐츠를 준비하기 앞서 막상 두려웠다. 그럴 일은 없겠지만, 사용자가 엄청 많아져서… 컴퓨터나 클라우드가 뻗기라도 한다면?? 비용의 문제를 뒤로하고도, 사용자가 많은 서비스는 항상 느려질 수 있는 서버 상황에 대비해야 한다는 것을 너무나 두려워했다.그래서, 가

이번 프로젝트의 가장 큰 목적은 기술 스택의 사용 의미를 명확히 하는 것 + 운영 경험을 갖는 것에 초점을 맞추고 있다. 또한, 바닥부터 진행하는 프로젝트이기 때문에 최대한의 문서화 + 다양한 선택지에 대한 이유와 결과 분석을 포함해야 할 것이다.프로젝트의 전반적인 흐