여기서 다루는 내용
· ELB의 추억
· 새로 나온 기능
· 동작 예시
· 마무리
태초에 ELB가 있었으니..
안녕하십니까. GS네오텍 최준승입니다.
오늘은 클라우드 할아버지처럼 옛날 얘기로 시작해 보겠습니다. 너무 멀리는 말고 2015년쯤으로 돌아가보죠. 그때도 ELB 서비스가 있었지만 지금처럼 ALB/NLB/CLB의 라인업은 없었습니다. Type을 선택하지 않고 달랑 Classic Load Balancer만 하나 있었죠. Target Group이란 개념도 없었습니다. 그리고 시간이 흘러 16년 여름쯤 Application LB가 출시되었고. 또 좀 지나서 Network LB가 출시된 것으로 기억합니다. 자연스럽게 AWS는 CLB를 이전-세대로 분류하고 ALB/NLB로의 이전을 권장하는 여러가지 장치(CLB 콘솔 화면에 Migrate ALB/NLB 버튼, CLB의 CloudWatch 메트릭에 "추정 LCU" -ALB/NLB의 과금지표- 추가)를 하기 시작했구요. 그럼에도 불구하고 시장에서 완전히 신세대(ALB/NLB)로 전환되지 않고 CLB가 혼용되어 쓰인 이유는 신세대가 한끝차이로 모자랐던 뭔가가 남아있었기 때문입니다. 그리고 '19년 1월 NLB에서 TLS Termination을 지원하기 시작하면서 적어도 기능적으로는. 제 시각에서는 CLB의 효용이 완전히 사라졌습니다.
다시 한번 2015년 AWS 사용자로 돌아가 보겠습니다. 가장 전통적인 레벨(?)에서 클라우드를 썼다고 칩시다. 이를테면 네트워크를 구성하고(VPC) VM을 만들고(EC2) 앞에 LB를 하나 붙이는(ELB) 간단한 구성에서 ELB의 성능/기능 이슈는 꽤나 자주 등장하는 "단골주제"였습니다. ELB는 일종의 매니지드 서비스임에도 불구하고. 서비스 특성을 이해하지 못하고. 왜 내부 스케일링이 필요한지 / Prewarm은 귀찮게 왜 하라는건지 / 왜 앞단의 VIP를 지원하지 않는지 / 뒷단 라우팅 정책은 왜 조절할 수 없는지 / QoS 정책은 왜 만들 수 없는지 / 웹소켓 프로토콜은 왜 지원하지 않는지 등등 기존 네트웍 장비의 잣대를 들이대며 투덜거리는 고객이 참 많았던 기억이 납니다. 다행히 지금은 사정이 좀 나아졌는데요. 고객의 사고방식도 나름 개선(?)이 됐고. ELB의 기능상으로도 비약적인 발전이 있었죠. 저 개인적인 생각으로는. ELB를 설계/운용하는 입장에서 복수 노드의 객체(CLB/ALB)를 단일 객체로 처리하는데 필요한 수고(설정값 싱크.. 로그/통계 병합 등)의 고달픔이 상상됩니다만. 어쨌든 적어도 이제는 객관적으로 봐도 ELB가 쓸만해졌다고 말할 수 있는 수준까지는 올라왔다고 생각합니다.
늙어서 그런지 말이 많아졌네요. 본론 시작합니다.
Application LB에서 특정 기준으로 분기할때 참조하는 기준값의 범위가 대폭 늘어났습니다.
대체 무엇이 바뀌었길래. 이렇게 호들갑을 떠는것일까요?
Advanced Request Routing for AWS Application Load Balancers
여러분도 아시다시피 Application LB는 L7 Layer에서 각종 요청값을 들여다볼 수 있기 때문에
특정 조건(IF)을 주고 뒷단을 분기(THEN)하는 것을 지원해 왔습니다.
여기서 IF 조건에 넣을 수 있는 조건이 기존에는 Host Header와 Path 2가지였는데요.
이번 업데이트로 기준값이 아래처럼 2가지에서 6가지로 확장되었습니다.
- 기존: Host Header / Path
- 현재: Host Header / Path / HTTP Header / HTTP Request Method / Query String / Source IP
※ IF Condition에 선택항목이 6개로 늘어난것이 보이시나요?
그럼 이것으로 무엇을 할 수 있느냐. AWS 블로그에서 말하는 쓸모를 원문 그대로 옮기면 다음과 같습니다.
- Separate bot/crawler traffic from human traffic.
- Implement A/B testing.
- Perform canary or blue/green deployments.
- Route traffic to microservice handlers based on method (PUTs to one target group and GETs to another, for example).
- Implement access restrictions based on IP address or CDN.
- Selectively route traffic to on-premises or in-cloud target groups.
- Deliver different pages or user experiences to various types and categories of devices.
예를 들면 이런 것이죠.
동일한 LB 아래에 2개의 Target Group을 놓고 (Target-A / Target-B)
예전에는 Host Header로만(또는 특정 Path 기준으로) 각기 다른 Target Group으로 분기할 수 있던 것이.
지금은 특정 Header나 특정 Query String을 가지고 원하는대로 분기하는 것이 가능해진 것입니다.
제 생각에 이것은 매우 큰 변화입니다.
또한 THEN에서 정의할 수 있는 Action 또한 단순히 Target Group으로 넘겨주는 것뿐만이 아니기 때문에
특정 고정응답을 줄 수도 있고. 리다이렉션을 쳐줄수도 있고. 이런 기능과 복합적으로 활용되면. 아주 훌륭한 도구가 되겠죠.
자세한 얘기는 뒤에 다시 하기로 하고. 동작 예시를 한번 살펴보고 넘어가겠습니다.
동작 예시
모든 예시는 편의상 지정된 응답을 주는(Return fixed response) Action으로 구성하였습니다.
1) HTTP Header 조건: who라는 헤더의 값이 cloudgrandfa인 경우 / 지정된 응답을 반환
▶ 요청 테스트
$ curl -H "who: cloudgrandfa" helloalb-1708505182.ap-northeast-2.elb.amazonaws.com
hello grandpapa!
2) HTTP Request Method 조건: FIRE라는 메쏘드로 요청이 들어오면 / 지정된 응답을 반환
▶ 요청 테스트
$ curl -X FIRE helloalb-1708505182.ap-northeast-2.elb.amazonaws.com
This is FIRE method
You can make custom method
여기서 주목할 점은 Custom하게 지정한 메쏘드도 분기값으로 쓸 수 있다는 점이지요.
3) Query String 조건: test라는 쿼리스트링 값이 yes인 경우 / 지정된 응답을 반환
▶ 요청 테스트
$ curl helloalb-1708505182.ap-northeast-2.elb.amazonaws.com?test=yes
your query string(test) is yes
4) Source IP 조건: 사전에 정의한 IP(Range)를 Source IP로 물고 들어온 경우 / 지정된 응답을 반환
▶ 요청 테스트
$ curl ifconfig.co
13.125.113.128
$ curl helloalb-1708505182.ap-northeast-2.elb.amazonaws.com
I know your IP
여기서 중요한 부분은 이런 조건을 OR/AND를 섞어 복합조건으로 정의할 수 있다는 점입니다.
예를 들면 path가 /admin이고 && 특정 Source IP를 물고 들어오는 요청을 기준으로 삼는다거나
요청 헤더 중 User-Agent 값이 OOO이고 특정 Query String이 XXX인 요청을 하나의 단위로 묶는다거나 이런것이 가능해지는 거죠.
좀 더 깔끔한 예시는 AWS에서
데모 페이지를 만들어 놓았으니. 참고하시기 바랍니다.
마치며
앞에서도 언급했던 내용에도 포함되어 있지만.
이 기능을 활용하면 CloudFront와 ALB간의 접근제어를 아주 심플하게 제어할 수가 있습니다.
지정한 조건이 아닐 경우 다른 안내페이지로 Redirect 시켜주거나. 지정한 응답을 반환하는 것도 매우 깔끔하게 처리됩니다.
고정된 User Agent값을 물고 들어오는 Bot 요청도 일부 분리를 시킬 수가 있습니다.
완벽하지는 않겠지만. 특정 Path 조건과 복합적으로 사용하면 더 세밀하게 제어할 수 있을것 같구요.
물론 이런 분기처리를 꼭 Proxy 계층에서 구현해야 되는 것은 아닙니다.
하지만 Proxy 계층에서 뭔가를 처리했을때의 장점은 아마 TLS Termination을 한번이라도 써보신 분이라면 부정할 수 없을거에요.
무엇보다도 이런 형태는 관리-편의성 측면에서 넘사벽의 차이를 보입니다.
새 기능을 적용하는데 있어 좀 더 디테일한 부분도 고려해볼 수 있는데요. 크게 중요해 보이진 않습니다.
- 조건 관련 각종 Limit값이 원하는 구성에 제약이 걸리는지 여부
- Rule 처리량에 따른 과금 문제(LCU 측정 조건 4개 중 하나가 Rule Evaluation 개수)
좀 더 자세한 내용이 필요한 분은
AWS 블로그글 을 참조하시구요.
부디 이 좋은 연장(?)을 여러분의 환경에 맞게 잘 활용하시기를 바랍니다.
읽어주셔서 감사합니다.
끝!
