ALB Rule
이제 만약에 우리가 만든 서비스가 마이크로서비스라고 가정해 봅시다. 그럼 /order따로 /delivery따로 구동될 것입니다. 당연히 이에 따른 대상 그룹도 2개일 것이고 각각의 대상그룹 안에 여러개의 인스턴스가 존재하게 될 것입니다.
저희는 그리고 각 url마다 매칭시켜줘야 하는 대상그룹이 다를 것입니다. ALB가 /order -> TG1 /delivery -> TG2로 가게해라 라는걸 알기 위해서 작성되야 하는 것이 ALB Rule입니다.
Sticky Session
또한 Sticky Session에 대해서 설명해 보도록 하겠습니다. 만약에 TG가 하나만 있다고 해 봅시다. 세션은 쿠키 형태로 id값만 저장해고 계속 들어올 때마다 자동 로그인이 되게끔 하는 그런 기능?이라고 보시면 되는데, 이를 로드밸런서에 대해서 생각해 봅시다.
새로고침을 할 때마다 다른 서버로 계속 트레픽이 리다이렉션 되는데, 로그인 했었다는 정보가 하나의 서버에만 저장되고 다음에 로그인 할때는 그 정보가 없어서 세션을 활용하지 못하게 되는 상황이 나타날 수 있습니다.
그래서 세션값을 로드벨런서에 저장하고 일정한 텀을 두어서 그 값이 들어오는 한 단일된 서버에 트레픽을 리다이렉션해 주는 쿠키를 Sticky Session입니다.
실습
이번에는 인스턴스를 하나 더 만든다음에 3번째 인스턴스를 tg2에 넣어보도록 하겠습니다. tg2는 tg1과 설정값 다 똑같이 그냥 새로 만들어준 대상그룹 입니다.
저희의 목적은 /delivery/오는 url은 tg2로 보내고 나머지 url는 tg1으로 보내는 것입니다. 우선 로드벨런서의 리스너탭에 들어가서 규칙 편집을 눌러서 다음과 같이 설정해 줍니다.
이렇게 하게되면, /delivery/로 오는건 tg2로 나머지는 tg1으로 설정한 것과 마찬가지 입니다. 이가 정말 잘 작동하는지 확인해 보도록 하겠습니다.
- http://eb1-666088492.ap-northeast-2.elb.amazonaws.com:81/delivery/orders/
- http://eb1-666088492.ap-northeast-2.elb.amazonaws.com:81/order/order/
위 두가지 url을 차례데로 들어 가고 각각의 콘솔에서 띄워지는 값을 확인했습니다.
각각 health-check와 각 요청을 보냈는데 url에 따라 ABL이 로드벨런싱을 제대로 하는 것을 확인할 수 있습니다.