LEO Devlog LEO Devlog

*잘못된 AccessKeyId로 접근했을 때 *잘못된 AccessKeyId로 접근했을 때 올바른 AccessKeyId로 요청할 때랑 잘못된 AccessKeyId로 요청할 때 에러가 다른 걸로 보아 코드 상에 문제라기보다 설정 방법이나 호스트 단에서 에러가 났을거라고 생각이 들어 자료를 찾아보았다. AWS SES를 이용하는 것중에 aws-sdk에 있는 ses를 사용해 transporter를 적용해도 되지만 근본적인 서비스인 nodemailer의 example을 보고 그대로 해보았다. import { BadRequestException, Injectable } from '@nestjs/common'; import * as nodemailer from 'nodemailer'; @Injectable() expo..

EC2를 사용할 때 가장 흔하게 t2.micro 프리티어를 사용한다. cpu 성능을 제공하는 방식이 조금 특별하다. 일반적으로 CPU 성능이 정해져있어서 24시간 같은 성능을 제공할 것이라 생각하지만, T계열 인스턴스들은 기본 성능을 제공하다가, 유저들이 몰리거나 하는 등 기준 이상의 성능이 필요할 경우 버스트 기능이 동작하게 된다. 물론, 공짜는 아니고 인스턴스 사양마다 제공되는 크레딧이 다르고 그 크레딧이 남아있는 동안 버스트 기능을 사용할 수 있다. 기준 이하 성능 사용을 지속할 경우 크레딧이 쌓이고(한계치 있음), 그 이상의 성능을 사용할 경우 크레딧을 소모시킨다. 크레딧이 다 소모되면, 기준 이상의 성능을 발휘하지 못하고 성능은 급격히 떨어지게 된다. 이러한 특성은 평소에는 CPU사용률 저조하다..

ec2에 cloud-init 설치 ec2~ubuntu에서 sudo apt-cache search cloud-init 설치되지 않았다면 sudo apt-get install cloud-init EC2 인스턴스 중지 (종료 X) 중지 후 “중지됨”으로 상태가 변할 때까지 대기한다. 중지되었다면 [작업 - 인스턴스 설정 - 사용자 데이터 편집]으로 들어간다. 스크립트 하단 #!/bin/bash 아래부터 작성해나간다. *sudo, root폴더 기준임에 유의하여 작성한다. * Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 --// Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: ..

ec2에서 mongodb를 설치하고 mongosh을 눌렀을 때 정상적으로 접속이 가능한 상태가 전제이고 MongoDB compass를 연결해보는 작업이다. 우선 사용하고자 하는 DB로 바꿔준다. show dbs use test db.getUsers() db.createUser({ user: ‘testUser1`, pwd: ‘’password77, roles: [{role: 'readWrite', db: 'test'}]}) db에 접근할 user를 만들어주었다. 다시 한번 db.getUsers()를 통해 잘 만들어졌는지 체크한다. db.getUsers() // -> 결과 { users: [ { _id: 'test.testUser1, userId: new UUID("bdsdwfad-adad-9999-fje0..

(총 관리를 하게될) ec2 생성 ec2 접속 sudo apt-get update curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash nvm ls (comment not found 뜨면 ssh 껐다가 다시 재접속해보기) nvm install v14.16.1 nvm use v14.16.1 sudo apt-get install nginx sudo service nginx start mkdir app cd app 터미널에서 pem 키가 있는 파일로 이동 ( /project/ssh ) chmod 400 YOUR_PROJECT.pem ssh -i "YOUR_PROJECT.pem" ubuntu@ec2--*--.ap-north..

- HTTP 5XX 에러 유형 HTTP 502 Bad Gateway HTTP 503 Service Unavailable HTTP 504 Gateway Timeout 원인 분석 HTTP 502 Bad Gateway – 백엔드 인스턴스로부터 온 응답을 ELB가 받지 못할 경우 발생 HTTP 503 Service Unavailable – 인스턴스가 한 대도 등록되어 있지 않을 경우 발생 – 모든 인스턴스가 Unhealthy 상태일 경우 발생 – 짧은 시간에 Request가 급격하게 들어온 경우 HTTP 504 Gateway Timeout – 인스턴스의 요청 처리 시간이 ELB Timeout 보다 길 경우 HTTPCode_ELB_5XX 및 Latency Metrics 동시 증가 – 인스턴스가 ELB 요청을 Cl..

서로 다른 EC2 인스턴스를 생성 후 ELB를 적용 1. EC2 인스턴스 생성 ELB에 연결할 2개의 EC2 인스턴스를 생성한다. 두 인스턴스의 서브넷(가용영역) 위치를 다르게 설정하기 ap-northeast-2a 서브넷으로 지정된 첫번째 인스턴스 ap-northeast-2c 서브넷으로 지정된 두번째 인스턴스 2. Load Balancer 적용 EC2 서비스페이지에서 좌측 메뉴 하단에 로드 밸런싱->로드밸러서를 클릭해서 접속한다. classic Load Balancer를 선택한다. 로드밸런서 이름 -> next 보안 그룹 할당 기존에 생성되어있는 보안 그룹을 할당시켜줬다. 80 HTTP만 설정되어있으면 된다. 상태검사 구성 로드밸런서에 연결할 인스턴스의 헬스체크와 관련된 설정이다. 기본값으로 두고 넘어간..

EC2 생성하고(t3.micro) 30Gb 설정 (pem파일 잘 저장해놓기) 웹스톰 Tools - Start SSH session 클릭해서 edit Host -> EC2 퍼블릭 IPv4주소 Username -> 쓰고 싶은 이름 Authentication type: Key pair Tools - Deployment - Connection 클릭 Type -> SFTP SSH configuration -> SSH session 네임 클릭 Test Connection 해보고 Root path는 /home/ubuntu 로 진행하면 된다. 우분투 접속 후 터미널에 차례대로 입력 sudo apt-get update curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0...