<19년 차 개발자가 실무에서 맞닥뜨린 기술 이슈들>

2010년 즈음 소켓 라이브러리 개발 중에 발생한 이슈이다. 한데 인접한 버퍼에 여러 스레드가 동시에 액세스 할 때 급격히 느려지는 로그를 발견했다.

• 성능 측정을 위한 profiler
• 자체적인 로그 모두에서 이상 현상이 보였다.

정상적인 상황에서 ms 이하의 시간이 소요되는데 초단위 이상의 시간이 소요되는 현상으로 인해 latency가 발생하고 있었고, 이로 인한 간헐적 지연에 최우선 대응 과제가 되었다. 관련한 상황에 대해서 사내 여러 개발자분들께 물어보게 되었으며, 동료분들과 코드와 로그를 같이 보게 됐다. 

그러던 중 한 개발자분이 False Sharing 아니냐며 링크를 던져주셨다.(해당 블로그는 당시 링크는 아니지만 잘 설명된 글이라 가져와보았다.) C++ false sharing이란?(거짓 공유) (tistory.com) 

요약하자면 캐시간 데이터 공유를 위해 시간을 소모하는 과정이라고 볼 수 있다. 멀티 스레드간 인접 메모리 접근이 안되게끔 메모리 영역에 패딩을 주어 크게 잡으니 해결되었고, 같은 버퍼에 대해서 접근이 있을 경우에는 순차 접근하도록 sequencial한 동작이 이뤄지게끔 큐로 처리했다. 당시 C++을 이용했기 때문이기도 하지만, 소켓 라이브러리 자체를 직접 구현하게 되면서 컴퓨터 구조나 운영체제에 대한 높은 이해가 필요했다.

CPU에 대한 이해도, 그리고 캐시가 어떤 의미를 가지는지 좀 더 잘 알았어야 했는데, 이러한 부분에 대한 학습이 부족해서 생긴 이슈라고 볼 수 있겠다.

이때 컴퓨터 구조와 운영체제에 대한 높은 이해가 low level 프로그래밍 (운영체제나 메모리를 직접 다루는 쪽에 근접한 작업)을 하는 데에 중요하다고 느끼고 조금 더 학습에 매진했는데, 이러한 부분이 high level 프로그래밍(이미 개발된 기술을 활용하거나, 잘 만들어진 패키지나 라이브러리를 가져다가 비즈니스 로직을 구현하는 일)을 하게 된 이후에도, 각종 장애 현상이나, 동작 원리를 이해하는 데에 큰 도움이 되었다.

나는 low level 프로그래밍 과정에서 니즈를 느꼈지만, high level 프로그래밍을 주로 한다고 해도 컴퓨터 구조나 운영체제에 대한 높은 이해가 큰 도움이 된다.

소켓 서버 앞단에 L4 스위치 도입 시 생겼던 이야기

System Engineer 관점에서 트래픽 폭발을 대응하고자 하는 차원에서 L4 스위치가 점검 시간에 도입이 됐다.

• 네트워크 트래픽 제어는 기존 라우터에서 중간 L4 스위치를 하나 더 거치게 됐다.
• 브로드 캐스팅 대상을 좁히기 위함이라고 생각하면 그럴 수는 있을 것 같았다. 나중에야 알게 된 사실이지만, 개발팀 누구도 L4 스위치 도입 시 검토해야 될 이슈나, 설정값 검토, QA 서버에 선 도입해 볼 생각을 하지 못했고, 그렇게 위험을 감지도 불안정한 상태에서 L4는 도입됐다.
• 도입되자마자 이슈가 터졌고, 커넥션 유실이 두 종류가 발생했다.

디비 커넥션 유실

하나는 디비 커넥션이 끊어지면서, 나약하게 짜여 있던 ODBC로 작성된 코드 중 커넥션 유실 시 재접속 하는 코드에서 무한루프가 돈 것이다. 장애가 나고 나서야 덤프를 떠서 확인하고, 처리했다.

커넥션이 유실 된 이유는 커넥션풀을 이용하고 있었는데 해당 풀에서 꺼내 사용하는 방식이 최근 반환됐던 커넥션 위주로 재 사용되는 큐구조였고 그렇다 보니 트래픽이 지속 유입되고 DB 쿼리를 수행했음에도 큐 끝 쪽에 있는 사용되지 않는 상황이 벌어졌다.

이로 인해 해당  커넥션이 alive check에걸리면서 L4가 유효하지 않은 커넥션으로 판별해 연결을 해제 한 것이다.

이로 인해 당시 ODBC 라이브러리는 범용이 아닌 사내에서 작성된 코드였는데 ODBC의 재접속 시도 처리에 대한 로직에서 while 문의 종료 조건이 잘못되어서 다시 연결에 성공했음에도 루프를 빠져나오지 못하고 무한 루프가 발생해, 시스템 장애로 이어지게 되었다.

사용자와의 커넥션 유실

L4 스위치 자체에서 일정 시간 이상 지난 커넥션을 자동으로 제거했기 때문이다. 제거 원인은 배포된 클라이언트나 서버에서 지정된 KeepAlive 패킷을 주고받는 주기보다 L4 스위치에서의 KeepAlive 유효성 판단 주기가 짧아 발생했다.

발견이 조금 늦은 이슈였는데, 사용자가 액티브한 동작을 하지 않으면 Alive Check 패킷만 주고받게 되는데, 이 경우에만 커넥션이 끊어졌고, 이로 인한 사용자 불편으로 인한 이슈가 발생했다. 그나마 다행인 것은 위 이슈와는 다르게 해당 이슈는 장애로 이어지지는 않았으며, 서비스를 지속적으로 사용하는 유저에게는 발생하지 않는 이슈였다는 점이다.

L4 스위치의 KeepAlive 유효성 판단에 대한 설정값을 늘림으로써 임시적으로 해결됐지만, 과연 이 L4 도입 이슈가 소켓 서버의 경우에도 적절했는가에 대한 생각을 떨칠 수 없었다. 물론 현재는 온프라미스로 구축된 서비스를 잘 하지 않고, 심지어 이것이 레거시 환경이라고 불리기도 한다. 왜냐면 트래픽 폭발에 유연한 대응이 잘 안되기 때문이다. 

하지만 이 이슈와 같은 케이스는 L7 혹은 ALB, NLB라고 해도 상황은 달라지지 않는다. 그리고 중요한 것은, 기존 환경에서 변화가 일어날 때 어떠한 영향이 있을지 충분히 검증이 되지 않았다는 점이다. 대부분 기본 옵션으로 도입되었고, 사내에 다른 서비스에 도입된 장비라고 해도 충분한 검토와 검증을 거쳐야 된다는 점, 그리고 소켓 서버의 특수성을 이해하는 것, 웹 서버가 자체적으로 해주는 작업 (Keep Alive), Stateless 기반의 환경의 유연함 등이 주는 차이도 체크했어야 했다.

DB 처리 속도 급감 이슈, 배포 자동화 시스템 오류 등

더 많은 기술 이슈와 해결 과정이 궁금하다면? 👇🏻