[AWS] API Gateway와 CORS 그리고 Canary 배포

 

 

API Gateway

- AWS Gateway도 하나의 서버라고 생각하면 된다
- 하나의 도메인으로 모았다가 다시 뻗어나가는 거라고 생각하면 된다
- Redirect와 비슷한 개념으로 생각하면 된다
- 본질적으로는 단순한 개념인데, 한 곳에서 관리할 수 있기 때문에 부가적으로 붙여서 사용할 수 있는 기능이 많다.
- API가 지나가는 통로 (반드시 지나야 하는 하나의 gateway) 라는 개념을 갖고 있다.
- API Gateway를 Trigger함으로써 lambda를 실행할 수 있다

 

 

- Rest API는 복잡하고 느리고, customize 할 수 있다
- HTTP API는 단순하다
- CORS (보안)을 설정할 수 있다

 

 

CORS (Cross Origin Resorces Sharing)

- Cross Origin HTTP Request : 다른 도메인에서 호출을 한다.
- 자기가 짠거 내가 호출하는게 아니라, 남이 짠 것을 내가 호출한다. 이러면 보안상에 문제가 생길 수 있다.
- 그런데 마이크로서비스로 만들면 보안 문제가 아닌데, 남이 짠 것을 내가 호출해야하는 경우가 생긴다. 
- 마이크로서비스 아키텍트에서는 흔한 일이다.

 

CORS API 호출 순서
1) Options를 먼저 보낸다
2) 가능한지 응답받는다 (CORS 포함)
3) 그 다음 실제 API를 call

 

 

Canary 배포

Canary 배포를 사용하는 이유
- 업데이트한 기능을 전체에 배포하자니 예상하지 못한 버그가 있을까봐 무섭다
- canary 배포를 하면 100명 중에 90명에게는 업데이트 전 API를 사용하게 하고, 10명에게만 업데이트 API를 사용하게 하는 것
- 잠재적인 위험의 Exposure를 줄이는 것이다
- call 할 때마다 확률적으로 업데이트 전 / 업데이트 후 API를 받기 때문에, 버그가 있다고 해도 특정 사용자가 계속 버그를 만나는 것은 아니다
- A/B 테스트를 하고 싶을 때에도 Canary 배포를 할 수 있다