04-C07 웹서버로 콘텐츠 구분해서 서빙하기 > 2.3 실습 세팅 과 같이 두대의 EC2 서버에
/user , /customer 를 서빙하는 application을 띄운다. 포트번호는 기본(9000).
cd ~/node
nohup node server.js > server.log > 2>&1 & echo $! > run.pid
API Gateway 생성하기
- https://console.aws.amazon.com/apigateway 접속
- Create API
- REST API 선택
- API name 지정
- Entrypoint Type: Regional
- Create API
콘솔에서 View all services
Networking & Content Delivery 카테고리의
Api Gateway를 클릭
create API 클릭
여러가지종류가 있지만 Rest형 API만들 거니까 REST API Build클릭
New API,
API name : de -rest
API endpoint type : Regional
IP address type : IPv4
private은 내부용, 같은 VPC안에서만 쓰는 것
Edge Optimized는 Cloud Front라고 CDN형식의 서비스에 최적화된 것
그 외에는 전부 Regional이라고 보면 됨.
이렇게 세팅하고 Create
create 되었다면 해당 화면이 보일 것.
Resources - 내가 만든 API Gateway이름(유니크 아이디)
이렇게 나올 텐데, 맨 처음 리소스를 만들어야 하니
Create resource 클릭
우리는 /user라는 API를 만들었었다.
그에 맞게 Resource details를 적어놓고
이후 Create resource클릭
CORS가 필요한 사람들은 체크를 하면 된다고 했는데 프론트 실습과 관련있는 기능이다. 이번 실습에서는 관련 없으니 넘어가도록 하자.
API Gateway CORS는 Cross-Origin Resource Sharing(교차 출처 리소스 공유)을 API Gateway에서 처리할 수 있도록 구성하는 것을 의미한다. 이는 웹 브라우저의 보안 정책(CORS 정책)과 관련된 개념이며, 특히 프론트엔드(클라이언트)와 백엔드(서버/API)가 서로 다른 도메인에 위치할 때 발생하는 이슈를 해결하기 위한 메커니즘이다.
이렇게 Resources 생성되긴 했지만
No methods defined.
메소드가 없다고 나온다.
/user를 누르고 create method 클릭
해당 메소드는 HTTP 메소드다.
메소드 타입을 GET 선택.
GET으로 /user라는 path를 요청할 수 있는 게 만들어졌고, 이 친구를 어떻게 연결할 것이냐를 지정.
Mock 을 선택하면 200 OK 만 리턴하는 mock이 만들어 질 수도 있다.
Integration은 HTTP,
HTTP method : GET
Endpoint URL : 1번 서버의 IP주소를 넣고 9000번 포트, /path를 넣어준다.
그 이후 세팅들은 추가하지 않고 create method로 넘어간다.
이런 화면이 나오면 ok.
다시 1,2번 서버로 돌아가서
tail -f server.log 로 리슨 상태를 만들고 들어오는 요청을 확인하자.
위에가 1번 서버, 아래가 2번 서버다.
API Gateway > APIs > Resources 로 가서
Test 버튼 클릭
1번 서버로 연결했으니
{"user":"user1","time":"12:07:54"}
가 반환된 것을 볼 수 있다.
리슨 중인 1번서버의 server.log에도
아마존에서 붙인 헤더들이 붙어서 온 모습을 볼 수 있다.
같은 방식으로 /customer 도 만들어보자.
/ 클릭 후 create resource 버튼 클릭
create
create method
get, HTTP, get,
http://(2번서버주소):(port)/customer
create method
잘 만들어진 모습.
test
2번 서버로 연결했으니
{"customer":"customer2","time":"12:22:26"}
반환된 모습.
리슨 중인 2번서버의 server.log에도
아마존에서 붙인 헤더들이 붙어서 온 모습을 볼 수 있다.
자 그럼 이렇게 테스트가 잘 성공했다고 사용할 수 있냐? 그렇지는 않다 지금 테스트에서 요청이 나간 것이고 실제로 해당 API 들이 밖으로 Exposed 되지 않았다.
/ 클릭 후에 Deploy API 를 클릭.
Deploy API를 하기 위해서는 Stage가 필요하다.
Deploy를 처음한다면 Stage가 없을 테니
New stage를 눌러서 새로운 스테이지를 생성해주자.
Stage name : v1
Deploy 클릭
스테이지는 이렇게 버전을 구분할 때 쓸 수도 있고 환경을 구분할 때 쓸 수도 있다. alpha, beta production 이런 식으로. 보통 서비스에서 프로덕션에 가기 전까지 알파환경은 개발자들끼리 편하게 테스트 하는 환경, 베타 환경은 다른 조직이나 아니면 다른 팀이랑 협업할 때 프론트엔드랑 사전에 협의할 때 쓰는 배포환경 이런 식으로 하고, 성능 테스트는 Stage에서 하고 이이런 환경으로 구분할 수도 있고 버전으로 구분할 수 있는데,
여기선 버전 구분으로 쓰도록 하겠다.
Deploy 로 클릭하면 해당 화면으로 넘어오게 된다.
Invoke URL : 이게 밖으로 노출되는 URL이다.
아까 REST API 만들 때,
API endpoint type을 Pavate으로 생성할 수 있었다. 그걸 해야 외부로 노출되지 않는 API Gateway가 만들어진다.
외부로 노출되는 API Gateway가 만들어진다.
URL을 복사한 다음 mac 터미널로 가서
curl -XGET (Invoke URL)를 입력해보자.
missing authentication token 이라는 메세지가 나오는데
curl -XGET (Invoke URL)/user
curl -XGET (Invoke URL)/customer를 입력해보자.
각각 1번 서버, 2번 서버에서 응답한 것을 볼 수 있다.
API Gateway가 /user, /customer 각 path로 잘 나뉘어서 배포가 되었다.
