5월 14일과 15일에 코엑스에서 AWS SUMMIT 행사가 진행됐습니다. 너무 즐겁게 다녀와서 블로그를 꼭 써야지! 했는데,,,7월이 되어버렸지만 뒤늦은 후기라도 올려봅니다.
🧐 가장 기억에 남는 강연은?
우선 강연 목록은 여기에서 확인하실 수 있습니다.
저는 개인적으로 "AWS가 알려주는 분산 시스템 안정화" 에 대한 강의를 재밌게 들었습니다. 레벨 300이라 다 이해는 못했지만, 저희 회사에서 겪었던 문제들에 적용할 수 있는 부분인 것 같아서 재밌었습니다.
재밌었던 관계로 강연에 대한 내용도 덧붙이겠습니다.
재시도를 할 경우, 부하의 양상
- 부하 -> 타임아웃 발생 -> 성공 횟수 줄어들기 시작 -> 점차 통과되기 시작하며 회복
- 부하 + 재시도 -> 타임아웃 발생 -> 복구안됨. 재시도로 인해 트래픽이 늘어남
이렇게 단순하게 실패 시 재시도를 하도록 한다면, 이로 인해 부하가 더 커지고 해소되지 않는 최악의 문제를 초래할 수 있습니다.
- 재시도 회피: 시스템 장애 시 good. 상황을 악화시키지 않음. 일시적 장애 시 bad
- 재시도 3회: 시스템 장애 시 bad. 일시적 장애 good
재시도를 하거나 안하거나 이것만 있나? 어떻게 재시도 전략을 세우는 게 좋을까?
"적응형 재시도"라고 재시도를 위한 조건을 설정하는 방법론에 대해서도 설명해주셨습니다. 토큰을 이용하는 건데, 버킷에 토큰이 있는지, 최대 횟수 미만인지 확인하여 적용하는 것입니다.
재시도 전략
- 지수 백오프: 재시도 간격을 늘려가며 재시도를 수행. 트래픽이 몰려 실패한 상황에서 동시에 재시도하는 것을 막을 수 있고, 점진적으로 부하를 줄여줍니다.
- Jitter: 지수 백오프를 사용하더라도 동시에 재시도를 시도하게 되면 서버에 부하가 집중될 수 있기 때문에, 약간의 무작위성을 추가한 것입니다.
지수 백오프와 Jitter는 장애 대응에 효과적일까?
이건 시스템 유형에 따라 다르다고 합니다.
- 개방형 시스템: 다수의 사용자가 언제 접속할지 모름
- 폐쇄 시스템: 클라이언트를 느리게 하면 부하가 줄어듬
Backoff는 위에 말한 것처럼 동시에 재시도를 할 경우 부하가 갈 수 있기 때문에, 폐쇄 시스템에서는 좋으나 개방형에서는 안좋다고 합니다.
서킷 브레이커
서킷 브레이커의 역할은 아래와 같습니다.
- 수확량 감소. 과부하 상태일 때 필수적이지 않은 기능을 제거하여 가용성을 유지함
- 부하 차단. 하부 연계된 시스템으로의 트래픽을 줄이기 위해서 가용성을 희생하고 경합을 줄임
시스템이 과도한 혼잡으로 인해 무너지는 것을 막아주긴 하지만, 신뢰성을 감소시킬 수 있기 때문에 주의해서 사용해야합니다.
특히 서로 의존성이 있는 여러 시스템이 있다고 하면, A 시스템에서 과부하로 인해 차단이 되었을 때 다른 시스템에도 영향을 미칠 수 있기 때문에, 영향 반경이 큰 서킷 브레이커 사용은 배제해야한다고 하셨습니다.
tail 처리
설명해주신 자료가 없어서 gpt 를 통해 만들어봤습니다.
x축은 응답 시간, y축은 누적 비율입니다.
이 그래프를 기준으로 보면, 전체 요청의 90%가 500ms 안에 처리되었다는 겁니다.
tail latency랑 가장 느린 구간에서의 지연시간을 뜻하는데, p90, P99, P999 이런식으로 표기합니다. 이 그래프에서는 p90이 500ms 인거죠.
예를 들어 아래와 같은 상황이라면,
- 평균 응답시간: 150ms
- p90: 300ms
- p99: 1,500ms → tail latency
10% 사용자는 평균 응답시간보다 2배 느리게 응답을 받고, 1% 사용자는 10배 느리게 응답을 받는다는 건데요.
이 이미지를 보면, 초록색 라인은 P99가 1초 정도 됩니다. 대부분의 사용자가 1초 안에 응답을 받고 있습니다. 하지만, 노란색과 빨간색의 경우, y 가 0.9인 지점이 보이지도 않죠. p99가 1000ms 이상이라는건데, 여기서 x 축의 범위를 더 늘리면 p99가 나오겠지만, 아무튼 이 말은 대부분의 사용자가 느린 응답을 받고 있다는 겁니다.
사용자 경험을 향상시키기 위해서는 이러한 tail 을 어떻게 처리할 것이냐가 중요합니다.
이를 위하여 다음과 같은 방법을 소개해주셨습니다.
- 헤징(Hedging): 같은 요청을 여러 번 보낸 후, 가장 먼저 온 응답을 사용하는 방식
- 조건부 헤징: 한 개의 요청 송신. 일정 시간 내에 응답이 없으면 두 번째 요청. 서비스가 힘들 때 더 많은 부하
- Erasure coding: N번의 요청 송신 중에 일부만 받아도 결과를 재조합. 가장 느린 tail 을 안받아와도 되기 때문에 효과적. 한 서버가 다운되어도 다른 서버에서 결과를 받을 수 있음
- Nudge: 작업의 순서를 재배치하여 tail latency를 줄이고, 효율성을 높이는 방식. 빨리 끝나는 거 먼저.
시스템에 따라 어떤 방식이 더 효율적인지는 테스트를 해봐야할 것 같습니다. 이런 전략들이 오히려 더 느려지게 되는 케이스가 발생할 수도 있을테니까요.
저희 회사의 시스템은 시스템이 재시도를 하는 것은 아니었지만, 일부 응답이 느리다보니 사용자가 재시도를 하게 되고, 이로 인해 부하가 지속되는 케이스였습니다.
아마 Nudge 기법을 사용한다면, 부하가 지속되는 시간을 줄이고 대부분의 사용자에게 빠른 응답을 줄 수 있을 것 같긴한데, 그러면 또 소수의 사용자는 더욱더 느린 응답을 받을 수 있겠죠..? 어떤 전략을 시도하던 해당 전략에 대한 리스크를 고려해서 적용하긴 해야할 것 같습니다.
💛 가장 흥미로웠던 부스는?
굉장히 다양한 부스가 있었는데요!
그 중에서 저에게 베스트가 있습니다. 주저하지 않고 고를 수 있어요. 바로 "스케치랩"입니다.
그림을 그리고
그걸 가지고 게임에 참여할 운송수단을 만들었습니다!
그리고 난 후에는 이렇게 게임에 참여하는데요.
앞에 보이는 빨간 센서를 이용해서 이동시킬 수 있는데, 벼랑 끝까지 가장 가깝게 붙일 수록 점수가 높습니다.
1등하면, 이런 키캡을 주는데요. 얼마나 탐이 나던지... 아주 매우 열심히 했답니다. 행복했어요🥹
물론 이것때문에 가장 좋았던 건 아니구요.
스케치한 그림을 가지고 원하는 느낌으로 이미지를 생성할 수 있다는 서비스의 특성을 직관적으로 알 수 있었기 때문에, 가장 잘 구성한 부스가 아닌가 싶었습니다.
부스 보면, 홍보고 설명이고 뭐고 그냥 사람들 정보 모을 수 있는 설문조사 + 상품 이렇게만 구성한 곳이 많았거든요.
어떤 서비스인지 왜 좋은지 직접 말해주시는 것도 좋았지만, 자연스럽게 게임을 통해서 알 수 있어서 더 좋았습니다.
⭐️ 끝!
위에 말한 것처럼 부스를 알차게 즐기느라 까먹고 놓친 강의들이 있어서 아쉬운 마음이 있습니다. 유튜브에 다시보기 영상이 올라올 줄 알았는데 아직 없네요.. 제가 작년에도 다녀왔었는데, 이번에 느꼈던 감정은 좀 달랐어요. 그래서 블로그도 쓰고 있는건데요. 작년에는 취업한지 1년도 안돼서 강연에서 필요성에 대해 말할 때 공감할 수 없었어요. 이해도 안됐구요.
레벨도 레벨이지만, 그 강의를 내 것으로 만드려면 공감할 수 있어야한다고 생각하거든요. 제가 위에 말했던 기억에 남는 강연도 레벨 300이었고, 이해하지 못하는 부분도 많았지만, 문제에 대해 공감하고 이해했기에 흥미롭게 들을 수 있었고, 모르더라도 찾아볼 수 있는 키워드에 대해 힌트를 얻을 수 있었어요. 그래서 공감할 수 있던 그 자체가 전 기뻤습니다. 내가 허투루 시간을 보내지는 않았구나 하는...느낌?
그리고 부스에서도 제가 회사에서 담당하고 있는 서비스에 적용할 수 있는 기능을 발견해서 기뻤는데, 그렇게 좀 더 주도적으로 부스를 돌아볼 수 있는 그 자체도 기뻤어요.
내년에 가면, 또 어떤 감정을 느끼고 어떤 것들을 느낄까 기대가 됩니다. 점점 더 많은 것을 얻을 수 있길 바라면서 마치겠습니다!
혹시 강연 내용 중 잘못된 부분 발견하시면 말해주세요. 감사합니다.
