Alb, nginx, was에 관하여 질문이 있습니다.

질문자님이 이미 답을 아시는 것 같습니다만, 굳이 확인시켜드리면, 필요 없습니다. 아마, 과거 온프레미스 환경에서 개발하시던 분들이 구성하신 것 같습니다. 하던대로 하시는 습관같은 거니, 내게 주도권이 있는 게 아니라면, 그냥 따라가시는 것도 방법입니다. 어쨌건, 예전에는, 그리고 지금도 자체 인프라 운영하는 곳에서는 웹서버 앞단에 두고, WAS라고 부르는 웹애플리케이션 서버 (스프링 부트 애플리케이션)을 뒤에 두어 구성하는 게 일반적일 것 같습니다. 이게 아직도 유효한 환경도 많이 있을 겁니다. 앞 단에 로드 밸런서가 있다고 하더라도, 보통 자체 인프라를 갖고 있는 회사들은 로드밸런서에 접근권한이 없습니다. 인프라팀이 운영을 해주고, 뭘 바꾸려면 해당팀에 요청을 보낸다거나 하는 식으로 돌아가기도 하구요. 그러면, 개발팀 입장에서 자체적인 L7라우팅 작업을 위해 nginx같은 레이어를 두는 게 편리하죠. 하지만, ELB를 쓰는 환경에서는 보통 개발자에게도 해당 ELB 접근권한이 있으니까, 굳이 별도의 L7레이어를 두지 않아도 됩니다. 또, 정적 파일 서빙을 위해 nginx가 처리해주는 게 부트앱이 해주는 거보다 나을 수도 있습니다만, 뭐 보통 요새는 정적 파일들은 별도로 빼는 게 보통이니, 부트 애플리케이션쪽에 굳이 nginx를 둘 이유는 더더욱 없어졌다고 봐야겠습니다. 근데 뭐 그렇다고, 이걸 꼭 안 된다고도 할 수 없으니, 굳이 태클 걸기도 애매하긴 합니다. 태클 걸어봤자, 왜 있어야 한다는 나름의 근거 있는 답변(내지는 핑계)이 되돌아 올 게 뻔합니다. 굳이 역할을 꼽아보자면... 1. TLS터미네이션 => 이걸 nginx깔고 거기에 직접하는 일은 이제 엄청난 낭비죠. AWS나 GCP환경에서 인증서도 다 발급도 해주고 자동갱신해주는 세상에. 2. 정적파일 서빙 => 차라리 별도의 인스턴스나 S3 버켓 등으로 뿌리는게 더 낫겠죠. 3. 로드밸런싱 => 말씀하신대로 ELB가 하면 됩니다. 4. 액세스로그 남기기 => 클라우드 환경에 로그나 메트릭 취합하는 게 낫겠죠. 이 정도 목적이 생각나네요. 한편, 어차피 스프링부트 애플리케이션이라면 아예 Beanstalk같은 서비스를 쓰는 것도 방법일 것 같습니다.

외부에서 유입되는 트래픽 분산은 Aws 이용한다고하면 ELB/ALB 등 SSL 탑재및 관리도 용이하기 때문에 이것만 이용해도 충분하다고 봅니다. 비용관점에서 고민한다고하면~ 외부가아닌~ 내부간 http통신이 증가한다고 가정해봅시다. 이때도 모든 연결지점을 Aws LB로 모두 구성할수 있지만 사용비용이들게 됩니다. ex> rest 호출이되고 완료까지의 사용시간비용및 커넥션비용을 청구 물론 이 경우도 nginx-ec2 구축 운영비가 더든다고하면 ALB를 선택할수도 있지만 결국 비용이 통제되냐의 문제로 내부통신까지 사용 과금이 예측되지않는점은 트래픽이증가하고 서비스가 복잡해 졌을때 부채이지 않을까? 그래서 나중에 ngunx/haproxy등 내부간 로드밸런스를 위해 설치형 로드밸런스가 활용되지 않을까? 의견을 드려봅니다.

마이너하게는 바이너리 스트림을 수신하는 기능(파일업로드 등)에 제약이 필요한지, concurrency를 endpoint 레벨에서 제어할 필요가 있는지, 인가를 다른 was에 위임할 필요가 있는지, dockerizing을 위한 규격화 등.. 뭐 자잘한 것들이 있겠지만 그런 목적이면 이미 다른 수단이 많기도..