서론 프로젝트를 진행하면서 HTTP API gateway와 Network Load Balancer를 통합해봤다. 하지만 이 통합 방식에는 단점이 하나 있었는데, API gateway의 라우팅 주소가 실제 어플리케이션 코드에서 라우팅 주소와 정확히 일치해야 정상 작동하는 것이었다. 문제를 그림으로 설명하면 다음과 같다. 현재 프로젝트 서비스 구조는 다음과 같이 세가지 개별적 VPC에 API gateway가 라우팅 하는 형태로 되어있다. API gateway의 리소스 "/customer"에 접근하면, 소비자 서비스의 루트 경로로 들어가고 "/restaurant"에 접근하면, 음식점 서비스의 루트 경로로, "/rider"에 접근하면 배달기사 서비스의 루트 경로로 접근하게 하고 싶다. 원하던 동작 API gat..
서론 지난 글에서 NAT gateway를 사용하여 private subnet에서 Docker Hub에 요청을 보내어 docker image를 가져오는 실습을 진행해봤다. 글을 마치면서 NAT gateway 단점으로 비용이 많이 발생한다는 것을 언급하였다. 실제로 서비스를 이용해보니 NAT gateway의 비용이 상당하게 부과되는 것을 경험하였다. 아래는 글쓴이의 AWS Billing Dashboard의 청구서 페이지를 일부 캡쳐한 것이다. NAT Gateway를 361시간 사용하고 21.3달러가 청구되었다. NAT gateway는 시간당 0.059 달러 비용이 발생하는 것이다. (리전마다 비용이 다르다.) 이는 꽤 부담스러운 가격이다. NAT gateway가 얼마나 비싼지 감이 안 온다면 아래 표도 참고..
오류 CASE 1 입력 상황 AWS ECR에서 제공하는 인증 토큰 가져오는 명령어를 그대로 입력했을 때 해당 오류가 발생했다. 오류 로그 An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: User: arn:aws:iam::ACCOUNT_NUMBER:user/MY_USER is not authorized to perform: ecr:GetAuthorizationToken on resource: * 원인 두 가지 원인이 있다. 첫 번째 원인 액세스 키로 연결된 사용자에게 AWS ECR 권한이 없음 오류 로그에 나온 대로 사용자의 IAM 권한에 ECR에 대한 GetAuthorizationToken..
Private Subnet에서 배포하면서 생긴 문제 프로젝트 진행 중에 AWS ECS가 생성되지 않는 문제가 발생했다. 현재 프로젝트 설계 구조는 다음과 같이 VPC 내 프라이빗 리소스를 통해 API gateway - Load balancer - Container Service 가 연결되어있는 구조다. 보안상의 이유로 어플리케이션인 ECS에는 외부에서 접속하지 못하게 해야한다. 우리 어플리케이션의 인증/인가는 API gateway와 Cognito에서 이뤄지기 때문에 ECS에는 인증/인가 프로세스가 없기 때문이다. 그래서 허가되지 않은 외부 사용자는 ECS에 접근할 수 없어야 한다. Private subnet에서 ECS를 생성하려고 하면 딜레이가 발생하다가 생성되지 않는 문제가 발생한다. 이 문제를 해결하..
서론 Spring 프로젝트를 도커 이미지로 만들어 클라우드에서 구동하려고 했으나 이에 관련하여 one way로 깔끔하게 정리되어있는 문서를 보지 못한 것 같아서 정리해두려고 한다. 또한 코드를 업데이트하고 나서 BootJar로 빌드 하지 않아서 코드의 변경사항이 반영되지 않는 실수를 방지하고자 한다. 해당 글은 build 도구로 Gradle을 사용하며, IDE로 IntelliJ를 사용하는 것을 기준으로 한다. 또한 해당 실습을 하기 위해서는 Docker Hub 계정이 있고, Docker가 local 환경에 설치되어 있어야 한다. Spring Project로 Docker image 만들기 프로젝트 생성 컨트롤러를 생성해서 RestContoller를 사용하여 라우팅한다. 현재 프로젝트는 루트 주소에 대해서만..
서론 Spring을 이제 막 배우던 때에, @RequestMapping 기능을 막 익혔을 때의 이야기다. 다음과 같이 컨트롤러에서 @GetMapping과 @PostMapping의 URL을 "/login"과 "/login/confirm"으로 정했지만, 마음 한 켠 찝찝한 기분이 느껴졌다. > 'URL을 이렇게 정해도 괜찮은 건가?' GET은 로그인 사이트에 사용자가 접속했을 때 보는 정보가 담겨져있고, POST에는 사용자가 로그인을 위해 입력한 ID와 패스워드 정보가 담겨있다. 어쨌든 이 둘의 기능은 이렇게 구분되므로 이렇게 이렇게 "/confirm"이라는 URL로 구분지었지만, 이것이 알맞은 방법인지는 조금 의문이 들었다. 관련된 정보를 알기 위해 'RESTful API' 키워드로 검색했지만, - 동사가..