파이프라인을 변경하기 전, 사실 아키텍처를 먼저 변경을 했다.
(변경은 금방 했지만, VPC 설정이 엄청 오래걸림ㅎ)
아키텍처는 진짜 많이 얘기하고, 계속 바꿨다.
처음에는 ECS로 구현을 했다가, 막상 ECS로 다 만들고나니
테스크 설정 크기로 인해서 강제로 우리 프로젝트에 맞지 않은 EC2 인스턴스 (과한 인스턴스 사용...) 를 사용하게 되었다. 클러스터 별로 EC2 인스턴스를 지정해놨어야했고, (ASG 설정)
하나의 태스크 안에 docker agent가 깔려있어서,
1GB로 태스크 설정을 하면 1GB보다 커야하고,
그럼 2GB인데 태스크가 2개 있으면 4GB 이어야하고,,,
그럼 클러스터를 2개 만들어서 인스턴스 크기를 조절해야하나? 등등 다양한 문제점을 맞이했다.
리더님의 말로는, 이렇게 하면 ECS의 장점은 하나도 사용 안 하고, 단점만 가져가는 상황이라고 하셨었다.
방안은 2개가 나왔었다.
1) EKS 사용
2) 그냥 EC2 사용
출시까지 시간이 촉박한데, EKS 설정은 복잡할 것 같아 2번으로 결정했다ㅎㅎ...
바뀐 아키텍처
진짜... 서브넷 구축하는데 에러가 너무 많이 나서 힘들었다,,,
간단히 설명을 하자면,
2개의 가용영역에 서버를 분리시켜놨다.
private subnet A로 50
privat subnet B로 50씩 ALB를 통해 트래픽을 분산시켜주고 있다.
아키텍처 변경 후에, 어플리케이션 잘 돌아가나 확인을 해봤는데 500 에러가 났다;;;;;;;;;;;;;;;;;;;;;;
진짜 골머리 아팠다.
분명히 alb health 체크 전부 정상이고,
트래픽 분산 잘 되는거 확인하고, 컨테이너 로그 확인해보니 멀쩡했는데, 서버 바꾸니까 500 에러가 났었다.
컨테이너 로그를 살펴보니
[Spring]class java.lang.String cannot be cast to class org.springframework.security.core.userdetails.User유저 관련되서 오류가 발생하고 있었다.
하,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
우선 DB부터 확인을 해봤는데, 그냥 유저 생성이 안 되고 있었다.
코드 변경을 따로 하진 않아서, 코드 레벨의 문제는 아니라고 생각했고, 분명 VPC 관련되어서 네트워크 문제라고 생각했다.
몇 시간 동안 생각해 본 결과 오류 이유를 알 수 있었다.
우리 프로젝트에서는 NAT Gateway를 비용 이슈로 인해 사용하지 않고 있었다.
'외부 자원' 에 어떻게 접근할까 그럼?
외부 자원이 없다고 생각했다.
docker <- ECR Registry로 변경함.
나머지는 뭐 AWS 내부 자원이라고 생각했다.
간과했던 점
'카카오 + 애플 로그인'
예전에 설계한 OAuth를 생각해보면,
카카오에서 Authorization을 code랑 state로 받으면,
카카오한테 '요청'을 보내야한다.
나 권한 있으니까 이 유저 데이터 보게 해주세요~ 이런식으로
(OAuth를 다루는 내용이 아니기에 간단하게 설명)
근데 이 과정에서 카카오에게 요청을 보내야함.
<----------------- 이게 외부 통신,,,,,,,,
결국에 왜 사람들이 NAT Gateway를 사용하는지 알게되었다.
외부 통신을 전부 없애고 필요한건 AWS 내부에서 VPC Endpoint를 통해 접근하려 했는데,
결국 외부 자원을 사용할 수 밖에 없던것이다....
NAT Gateway는 비싸서, NAT Instance를 하나 달아서 외부랑 통신을 연결했다.
결과:
성공...!
최종 변경 아키텍처
이렇게 최종 아키텍처가 나왔다.
최종일까? 모르겠다. 벌써 문제점이 보인다.
가용영역 A 무너지면 그 때를 대비해서 B에 인스턴스 만들어놓은건데 지금 아키텍처에서는 A 무너지는 순간 외부 통신이 끊겨서 500 에러가 날 것이다.
그럼 B에도 NAT Instance 하나 더 달면 되는거 아닌가요?
물론 그럼 좋지만 비용 이슈ㅎㅎ,,, (인스턴스만 5개다 그럼,,,)
위와 같은 이슈는 앞으로도 개선해나갈 문제다.
(+ Bastion Host가 저렴한지, VPC Endpoint가 저렴한지,
DB는 복제본으로만 설정해두고 다중 AZ는 비용 이슈로 설정을 안 했는데, 빠르게 대처할 수 있나? 등등...)
아키텍처 설계는 정말 어렵고 계속 개선해야하는 거 같다ㅜ
(최적의 솔루션으로 하자니 돈이 없고... 타협점 찾는게 참 어려운 거 같다)
오류 정리 및 아키텍처 정리 끝!
