티스토리 오류를 보고 왜 문제가 발생했는지 추측해보기

 

0. 이 글을 쓰는 이유

오늘 두 차례 티스토리 문제를 겪고 나서 과연 뭐가 문제인지 추측을 하는 과정이 재미있어 정리를 해보고자 한다.

 

1. 문제 상황

크롬 브라우저에서는 티스토리에 대한 특정 url에 대해 문제가 발생한 후 새로고침을 해도 계속해서 페이지에서 400에러를 리턴하는 상황 

하지만 다른 브라우저에서는 정상적으로 동작하거나 크롬 자체를 재부팅할 시 정상 동작을 함

 

 

2. 문제 의심

400에러가 왜 발생하는가에 집중을 해보자.

모질라에서는 400에러에 대해 발생 이유를 이렇게 설명해주고 있다.

보통 요청을 보낼 때 사용자에 대한 인식을 어떻게 하는지 상상을 해보면 브라우저의 쿠키에 저장한 후 해당 쿠키를 기준으로 판별을 진행한다.

과연 이 쿠키에서 문제가 발생하면 어떻게 될까?

 

아마 정해진 형식 혹은 알고 있는 쿠키가 아닌 경우 잘못된 요청으로 인식하지 않을까 한다. 그로 인해 400에러가 발생한다고 생각한다.

 

그러면 왜 나는 크롬 브라우저에서만 해당 현상이 발생했는가?

 

우선 크롬 브라우저가 내 주 사용 브라우저이다. 그 말은 여기서 티스토리에 자주 접근하며 많은 쿠키가 쌓여있고 다른 확장프로그램도 같이 사용하면서 충돌이 발생했을 수 도 있다.

 

 

3. 만약 이게 500에러 였다면?

여기부터는 좀 재미있게 생각을 할 수 있을 것 같다.

티스토리의 내부 서버구조는 잘 모르겠지만 분산 및 이중화가 되어있고 load balancder가 있다고 예를 들어 생각을 해보자.

 

출처 : https://aws.amazon.com/ko/blogs/korea/new-aws-application-load-balancer/

로드 밸런서가 과연 어떤 방식으로 트래픽을 분배해 줄까는 방식에 따라 다르겠지만 만약 동일 사용자에게 동일한 인스턴스로 빠지게 해 놓았다고 가정해 보자.

동일 사용자에 대한 구별은 위에서 언급한 것처럼 쿠키로 구별할 것이다. 그렇다면 사용자는 계속해서 문제가 있는 인스턴스로 요청을 보내게 되지 않을까

 

물론 이 현상에 대한 전제는 내부적으로는 문제가 있지만 인스턴스 자체에 대한 접근에는 문제가 없다고 판별했고 aws의 인스턴스 진단상에도 문제가 없다는 것이 있어야 한다.

 

4. 마무리하며

개발자로 일을 하며 이런 일들이 발생하면 아주 잠깐이라도 뭔가를 생각하게 되는 게 직업병인 것 같다.