Node.js,mysql,aws_개인프로젝트 진행하며 알게 된 점(+ 복습)
Node.js(express)
__filename, __dirname
// file 명을 포함한 절대경로
console.log(__filename); // /Users/directory.js
// file 명을 제외한 절대 경로 (폴더 경로)
console.log(__dirname); // /Usersmulter 이용 이미지 업로드
Node.js(express)에서 파일을 업로드하기 위해 사용되는 multipart/form-data를 다루기 위한 미들웨어 모듈
폼데이터나 폼 태그를 통해 업로드한 이미지를 올리면 req.file로 정보가 들어오고, dest 혹은 storage 속성에 지정해둔 경로에 이미지가 저장
multer({storage: 저장 함수(ex: diskStorage, multerS3 등..)로 생성한 파일 저장 위치 정보, option(사이즈,필터 등)})파일을 위 multer로 설정한 storage에 저장(만든 multer 인스턴스를 변수로 저장하여 라우터에서 미들웨어로 이용)
서버 DB에 저장
- DiskStorage 함수(다른 storage 가능): 파일을 디스크(서버 폴더)에 저장하는 스토리지 엔진, destination(업로드할 폴더 경로), filename 설정 가능
- 이후 multer 인스턴스를 이용하여 storage에 저장(위 참고)
- 서버 폴더에 저장한 파일을
fs.readFileSync(req.file.path)로 필요한 코드 내에서 읽어올 수 있음 - 서버 db에 저장
S3 버킷에 저장
- multerS3: 파일을 S3에 저장하는 스토리지 엔진, s3,bucket,acl 등 설정값 입력
- 이후 multer 인스턴스를 이용하여 storage에 저장(위 참고)
- S3 버킷에 저장한 파일을
req.file.location으로 해당하는 버킷의 이미지 url 읽어올 수 있음 - 서버 db에 저장
more multer's option..-> multer 깃헙문서
AWS
S3
SDK로 버킷에서 이미지 관리
AWS-SDK(Software Development Kit):
AWS를 프로그래밍적으로 제어하기 편리하도록 제공되는 라이브러리들(개발을 도와주는 키트들)
IAM (Identity and Access Manager)
: AWS의 리소스에 대한 개별적으로 접근제어와 권한을 가지도록 계정 또는 그룹을 생성, 관리하는 서비스.
front-end에서 유저가 업로드한 이미지를 저장할 때
- server에 이미지 저장 폴더를 만들어 클라이언트로부터 요청받은 파일 저장
- 이미지를 저장하는 서버 따로 만듬
- DB에 Blob 타입으로 저장
--> 사용하는 서버, DB, PC의 성능에 따라 퍼포먼스가 달라질 수 있다.
--> AWS의 S3를 이용하면 PC의 성능 고려하지 않아도 되고, 사용한 만큼 비용을 지불하므로 보다 효율적
- 방법
- AWS의 콘솔의 IAM에서 사용자 추가 -액세스 키 ID, 비밀 액세스 키 생성
- (안 만들었다면) S3 버킷 생성
- server 폴더 안에 config/s3.json 만들어 위에서 할당받은 키 ID, 비밀 액세스 키, 리전 입력
- S3 버킷에 접근하는 코드(aws-sdk) + multer(+ multer-s3) 이용 로직 구현
client: 유저 입력에 따라 서버에 이미지 post 요청
server: AWS S3 버킷에 이미지 파일 저장 + DB에 버킷의 이미지 파일 경로(이미지 주소) 저장
client: 이미지 get 요청
server: DB에 저장된 버킷의 이미지 파일 경로를 응답
의도치 않은 API request 급증
- 콘솔을 통해 S3 버킷에 접근하는 거의 모든 행위가 request로 이어지므로 과금방지를 위해 콘솔 직접 접근 자제
- cli 사용
- cloudfront로 데이터 캐싱 - 불필요한 get requests 감소
- RDS 스냅샷 혹은 다른 AWS 서비스 등이 S3버킷에 접근할 수 있으므로 확인
- server access log, cloudtail, const usage 등으로 S3 버킷에 대한 접근 이력, 정보 조회 가능
CloudFront
- CDN을 통한 빠른 전송 속도
- S3에 직접 액세스 하는 것보다 싼 요금
- Cloudfront를 통해 가까운 로케이션에 액세스하므로
- S3에 부하가 몰리지 않고 엣지 로케이션에 캐싱되어 부하 분산
- 커스텀 도메인 사용 가능
- HTTPS 사용 가능
- CloudFront에서 제공하는 각종 통계, 보안 기능 사용 가능.
S3 버킷으로 직접 요청을 받지 않고(S3 버킷 자체에는 퍼블릭 액세스가 전면 차단되어 외부 접근 권한이 없는 상태) CloudFront를 통해서만 파일에 접근할 수 있다.
웹서버의 캐싱과 쿼리 스트링, HTTP 헤더 전달, 리버스 프록시 기능을 일부 가짐
웹사이트 최적화 가능
(캐싱, time to live (TTL) 관련 추가 작성)
ELB(Elastic Load Balancer)
로드 밸런서(Load Balancer): 서버 부하(load)를 적절하게 분배해주는 장치
(트래픽을 여러 Amazon EC2 인스턴스에 자동으로 분산, 또한 비정상 인스턴스를 검색하고 비정상 인스턴스가 복원될 때까지 트래픽을 정상 인스턴스로 다시 라우팅, 트래픽에 맞춰 요청 처리 용량을 자동으로 조정)
- 트래픽 분산
- 자동 확장
- 인스턴스의 상태를 자동 감지해서 오류가 있는 시스템은 배제
- 사용자 세션을 특정 인스턴스에 고정
- SSL 암호화 지원
- SSL의 경유지로 ELB를 사용하는 경우에 SSL 처리에 따른 부하를 ELB가 수용하게 된다.
- IPv4, IPv6 지원
- CloudWatch를 통해서 모니터링
- 사용한 시간과 통과한 트래픽에 따라서 종량제로 과금
Route 53
AWS에서 제공하는 DNS(도메인 이름 시스템)웹 서비스
도메인 등록, 인터넷 트래픽을 도메인의 리소스로 라우팅, 리소스 상태 확인 + 인증서 발급을 위한 필수 요소
- Route 53 라우팅 과정
- 도메인의 트래픽을 CloudFront 배포로 라우팅
- ELB 로드 밸런서로 트래픽 라우팅
- 유지 시간(TTL/time to live):
다음에 누군가가 사이트에 접속할 때 보다 빠르게 응답할 수 있도록 지정하는 일정 기간 동안 사이트(ex: example.com)의 IP 주소를 캐시에 저장
AWS Certificate Manager(ACM)
웹 사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 만들고 관리
-
ACM 통합서비스(ELB, CloudFront, API Gateway 등)와 연동해서 쓸 수 있다.
- SSL/TLS를 통해 콘텐츠 보안 강화하기 위해 ACM와 통합하여 ELB, CloudFront 배포에 ACM 인증서를 배포함
- CloudFront에서 ACM 인증서를 사용하려면 미국 동부(버지니아 북부) 리전에서 인증서를 요청하거나 가져와야 함.
-
만료되는 인증서의 갱신을 자동화하여 보안 관리를 단순화
비대칭 키 암호화 기법
SSL 인증서 작동 방법
- 웹브라우저가 서버 접속 시 서버는 제일 먼저 인증서 제공
- 브라우저는 인증서를 발급한 CA가 자신이 가지고 있는 CA리스트에 있는지 확인
- 리스트에 있다면 해당 CA의 공개키를 이용해 인증서 복호화
- 인증서를 복호화할 수 있다는 것은 해당 인증서가 CA의 비공개키에 의해 암호화된 것을 의미
-> 즉, 데이터를 제공한 사람의 신원 보장
