📚 TIL
📌 서버리스 백엔드 복습
✔ aws lambda
- 서버리스 컴퓨팅 플랫폼
=> 즉 개발자가 서버의 존재를 신경쓰지 않고 코드에만 신경을 쓰면 된다
=> 특정한 시기에만 코드를 호출하는 경우에 사용한다
✔ aws vpc
- aws 계정 전용 가상 네트워크
- VPN : 가상 사설망으로 예를 들어 , 회사의 네트워크에서 보안상의 이유로 몇몇 직원들의 네트워크를 분리하고 싶을 때 VPN을 사용한다 - VPC를 이용하면 VPC별로 네트워크 구성을 할 수 있고 설정을 VPC별로 할 수 있음
- VPC 구축을 위해서는 사설 아이피 대역VPC의 아이피범위를 RFC1918이라는 사설아이피대역에 맞추어 구축해야 하는데 사설아이피란 우리끼리 사용하는 아이피주소 대역이다. 즉 내부 네트워크에서 위치를 찾아갈 때 사용한다. 외부와 통신할 때는 퍼블릭아이피 사용!!
- 각 VPC는 하나의 리전에 종속되므로 각각의 VPC는 완전히 독립적이라고 볼 수 있다. 만약 VPC간 통신을 원한다면 VPC 피어링 서비스를 고려해볼 수 있다고 한다.
서브넷
VPC를 만들었다면 이제 vpc안에 서브넷을 만들 수 있다. 서브넷은 VPC를 잘개 쪼개는 과정으로 서브넷은 VPC안에 있는 VPC보다 더 작은단위이기때문에 서브넷마스크가 더 높게되고 아이피범위가 더 작은값을 갖게됩니다.
이와 같이 서브넷을 나누는 이유는 더 많은 네트워크망을 만들기 위해서라고 한다.
각각의 서브넷은 가용영역안에 존재하며 서브넷안에 RDS, EC2와같은 리소스들을 위치시킬 수 있다.
aws region > VPC > 여러 개의 서브넷들 > 서브넷 안에는 ec2 , rds 같은 리소스
라우팅테이블과 라우터
- 라우터 : 목적지
- 라우팅테이블 : 각 목적지에 대한 이정표
vpc안의 서브넷간의 네트워크 요청 발생 -> 데이터는 라우터로 향하게 되며 네트워크 요청은 정의된 라우팅테이블에 따라 작동된다
같은 vpc안의 서브넷간 네트워크 요청은 로컬에서 찾도록 되어있지만 그 외의 외부로 통하는 네트워크 요청은 처리할 수 없음 => 이 때 인터넷 게이트웨이를 사용
인터넷 게이트웨이
- vpc와 인터넷을 연결해주는 관문이라고 생각하면 된다.
- 인터넷과 연결되엉 있는 서브넷을 퍼블릭서브넷 , 인터넷과 연결되어 있지않는 서브넷을 프라이빗 서브넷이라고 한다.
네트워크 ACL과 보안그룹
- 네트워크 ACL과 보안그룹은 방화벽과 같은 역할을 하며 인바운드 트래픽과 아웃바운드 트래픽 보안정책을 설정할 수 있음
- 네트워크 ACL은 서브넷 외부의 방화벽으로 서브넷 단위로 적용되며 , 보안그룹은 서브넷에도 설정가능 하고 각각의 ec2인스턴스에도 적용이 가능하여 네트워크 ACL과 보안그룹이 충돌한다면 보안그룹이 더 높은 우선순위를 갖는다
NAT 게이트웨이
- NAT 게이트웨이는 프라이빗서브넷이 인터넷과 통신하기위한 아웃바운드 인스턴스이다.
- 프라이빗 서브넷 특성상 외부에서 요청되는 인바운드는 필요 없더라도 외부로 표출되는 아웃바운드 트래픽은 허용되어야할 경우가 있는데 이 때 퍼블릭 서브넷상에서 동작하는 NAT 게이트웨이는 프라이빗 서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 인터넷 게이트웨이와 연결한다.
📌 서버리스 배포
✔ aws sam
- Serverless Application Model 은 빌드하는데 사용할 수 있는 오픈 소스 프레임워크
lambda를 효율적으로 관리할 수 있게 해줌
requirements 는 라이브러리들의 모음
app.py로 코드만들어서 deploy하고 람다함수들어가서 api 확인하면 결과 출력
template.yml - 인프라를 만들어서 코드로 배포하면
cloudformation - 스크립트를 읽어서 리소스(인프라)들을 디플로이 인프라배포 자동화
📌 flask conversion
튜터님께서 2차 프로젝트까지 했던 것 코드를 잠깐 리팩토링 해주셨는데 우리 프로젝트는 토큰에서 문제가 있다고 하셨다.
서버사이드렌더링은 요즘 트렌드에도 맞지않고 서버리스를 사용하기 위해서는 백엔드와 프론트엔드를 완전히 분리해야하기 때문에 서버사이드렌더링을 제거해야한다고 하셨다.
✔ 토큰 전달 문제
- 나는 쿠키에 토큰을 넣어서 서버와 클라이언트에서 서로 전달하는 방식을 사용하였다
- 예전의 부끄러운 내 코드
$.cookie('mytoken', '{{ token }}', {path: '/3page'}); //로그인시 3페이지로 가능이 방식은 토큰을 전달한다는 방식보다는 토큰을 쿠키에 넣어 서버와 클라이언트가 쿠키를 공유하는 방식이라고 했다. 요즘은 프론트엔드와 백엔드가 다른 도메인을 사용하는 경우가 많은데 쿠키를 사용하는 경우 다른 도메인에서는 사용을 할 수가 없다고 한다.
토근 전달 해결방법
로컬스토리지 : 프론트페이지의 데이터베이스
http 헤더에 토큰을 저장하면 모든 도메인에서 토큰을 사용가능하다
$(document).ready(function () {
$.ajaxSetup({
error: function (jqXHR, exception) {
switch (jqXHR.status) {
case 401:
alert('인증 에러!!');
break;
}
},
beforeSend: function (xhr) {
if (localStorage.getItem('token') != null) {
xhr.setRequestHeader('Authorization', localStorage.getItem('token'));
} else {
xhr.setRequestHeader('Authorization', 'anonymous');
}
}
});
$("#header").load( "header.html" );
getArticle(getParam('idx'));
});
//api를 호출하기 전에 
Hongik Univ 💻