분포 패턴으로 보는 장애 유형 Part I (수학 이야기보다 더 중요한..)

이전 포스트인 누워서 보는 웹 애플리케이션 성능에 필요한 수학 I – 분포와 평균의 인기에 감사드립니다. 평균의 함정에 대한 설명 및 분포에 대한 이론과 필요성에 대해 말씀 드렸는데요. 많은 분들이 공감해 주셔서 와탭 블로그 포스트 역사상 페이스북에 가장 많이 공유된 글이 되었습니다. 감사합니다.

이전 포스트에서 수학적인 부분을 쉽게 전달하는데 집중한 나머지, 응답시간 분포가 주는 큰 장점, 분포가 가져오는 또 다른 가치가 제대로 전달되지 않은 듯 합니다. 분포의 큰 장점은 트랜잭션의 분포 유형을 패턴으로 인식해, 시스템 내부의 문제를  유추할 수 있다는 점입니다. 이에 실제 분포 유형을 보여 드리고, 어떠한 원인 때문에 이러한 현상이 발생했는지 공유하도록 하겠습니다.

이상적인 응답시간 분포라면..

그림1. 이상적인 트랜잭션 분포

이전 글에서 언급했듯이 응답시간의 분포 유형이 LogNormal을 가지는 것이 좋은 서버라고 할 수 있습니다. 0초에 대부분의 응답시간이 인접해 있으며, 통상 1초를 벗어나지 않는 것이 좋은 서버의 응답시간이라고 보시면 됩니다.

대표적인 장애  유형 2가지 소개

  1. 수직선(Vertical Line)
rain2
그림 2. 수직선 현상

마치 하늘에서 비가 오듯이 막대가 서는 현상을 말합니다. 트랜잭션의 종료시간은 동일하고, 응답시간은 다른 것이지요.

응답이 이러한 현상을 보이면, 먼저 봐야 하는 게 하나의 서버에서만 이러한 상황이 발생했는지? 아니면 여러 대의 서버에서 동일하게 이러한 상황이 발생했는지 파악을 하셔야 합니다.

하나의 서버에서만 이러한 현상을 보인다면, 메소드 락(Java Synchronized)이나 그 애플리케이션 서버만의 문제지만, 여러 대의 애플리케이션 서버에서 동일하게 이러한 수직 선이 생기면, 이건 외부의 문제로 보셔야 합니다. 대부분 데이터베이스와 연관된 문제로 DB Lock, Connection Pool, 또는 공유하고 있는 자원의 부족 문제를 의심해 보셔야 합니다. (또는 특정 외부 http call이 제한된 user만 받거나, 제한된 자원을 쓰고 있는 경우에 호출할 때마다 느려지는 경우 이러한 현상을 볼 수 있습니다.)

하나의 사례를 구체적으로 말씀드리자면, DB의 Lock이 일제히 풀릴 때 이런 현상이 발생하였습니다. 특히 Sybase, MSSQL, DB2와 같은 제품에서 많이 발생하는데요, 이들 데이터베이스는 파일에 직접 데이터를 읽고 씁니다. (Oracle, MySQL은 버퍼풀에서 데이터를 읽고 쓰므로 이러한 현상이 상대적으로 적게 일어납니다.) 그로 인해 이러한 Lock들이 종종 발생합니다. 위 세가지 DB는 물리적 모델링을 꽤 신경쓰셔야 되는데, 행이 특정 개수 이상 Lock이 걸리면 테이블 전체를 Lock하는 현상이 발생합니다. 그러므로 Lock이 걸리지 않도록 물리적 모델링과 with Nolock 등으로 Locking 레벨과 테이블들을 잘 분리하는 것이 정말 중요합니다.

2. 수평선(Horizontal  Line)

timeout
그림 3. 수평선 현상

특정 시간만큼 공백을 이루면서 가로로 선이 계속 발생하는 현상입니다. 위 그림의 예는 20시 2분경, 응답시간 12초 정도쯤에서 에러들이 가로로 쭉 일직선을 이루는 모습을 보실 수 있습니다. 테스트 시 응답시간 3초짜리 트랜잭션(동일 URL)을 반복해서 호출할 때 이런 현상이 발생하죠. 하지만 이런 현상이 서비스 운영 시 발생한다면 다음과 같은 상황을 의심해 봐야 합니다.

  • 자원을 획득하기 위해 반복적으로 재시도 할 때 – 동일 트랜잭션(URL)인 경우 자주 발생합니다. 특정 자원을 획득하지 못 해 3초마다 Sleep을 걸어 재시도를 하는 로직을 넣은 경우입니다.
  • 30, 60, 90초 라인이 형성되는 경우 – DB Timeout을 의심해 봐야 합니다. 30초의 타임 아웃이 풀려, 일제히 찍히는 경우가 발생합니다.

이외에 다양한 장애 유형들 Part I

위의 두 가지 외에도 장애 시에 발생하는 정말 다양한 분포패턴이 있습니다. 다양한 분포패턴이 나오겠지만, 패턴화 할 수 있는 응답시간 분포는 다음과 같습니다.

  1. Influx+Initialize – 다량의 요청이 들어와 초기화와 맞물리면서 일시적으로 Bottleneck이 발생하는 현상
  2. Splash – 마치 물결이 바닥에서 튀어 오르듯 계속 반복되는 현상
  3. Matrix – 매트릭스 화면처럼 수직선이 이곳 저곳에서 나타나는 현상
  4. Flying – 트랜잭션이 바닥에서 서서히 하늘을 날듯이 응답시간이 점진적으로 높아지는 현상
  5. Temporary Bottleneck – 일시적인 병목 현상으로 다수의 Tx가 1초 이하의 응답시간을 보이지만, 많은 수의 Tx가 10초 이후 대에 걸치는 현상.
  6. Wave – 계속 파도가 치는 것처럼 응답시간이 지연되는 현상.

이 중 이번 포스팅에서는  Flying과 Influx라는 재미난 현상을 소개하는 걸로 마무리 하겠습니다.

3. 초기화에 의한 일시적인 병목 현상

hitmap__01_Influx
그림 4. 초기화에 의한 일시적인 병목 현상

위의 그림은 특정시간에 시스템이 오픈 되고, 다수의 사용자가 대기 상태에 있다가 동시에 접속을 시도하면서 발생하는 현상입니다. 약 5분 동안 병목 현상을 보이다가, 서비스가 정상화 되었습니다.

이러한 현상은 대표적으로 수강신청이나 특정 시간에 티켓 발급 시 종종 발생합니다. 사용자의 일순간 급격한 증가가 원인이라면 지속적으로 서비스가 느려져야 하는데, 몇 분 후 다시 응답이 정상상태로 돌아온 것으로 보아, 초기화 과정에서 발생한 일시적인 병목이라고 보는 것이 맞습니다.

일반적으로 Java-Web의 초기화 과정 중 주요한 부하 원인들은 다음과 같습니다.

  • JSP 컴파일
  • Class Loading
  • 메뉴/권한 정보 초기화
  • DB, 외부 연동 POOL 초기화

이러한 일련의 과정 중 통상적으로 초기화 과정이 필요한데, 가장 부하가 심각한 것은 JSP 컴파일입니다. 즉 이벤트 업무 시스템은 초기화 과정을 발생하는 부하에 대해 고려하고, peak time에 초기화가 발생하지 않도록 하는 것이 중요합니다.

4. Flying(응답시간이 비행기처럼 이륙하는 현상)

hitmap_03_flying
그림 5. Flying 현상

이 경우는 부하를 올리면서 동일한 트랜잭션의 Virtual User를 늘려가며 Ramp Up 테스트를 할 때 종종 볼 수 있는 현상입니다.

정상적인 경우라면 사용자가 늘어나면서 응답시간이 늦어지는 것은 당연한 현상이나, 그림 1과 같이 하단에 깔려 있는 파란색 점이 진하게 누적되면서 응답시간이 증가하는 이상적인 형태로 보여야 합니다.

하지만 그림 5를 보면 중간에 붕 떠있는 공간을 보실 수 있습니다. 자원의 부족이 모든 트랜잭션에 일괄적으로 영향을 미친 것을 알 수 있습니다. 재미난 것은 이러한 현상에서는 CPU 사용율도 안 올라간다는 거죠.

이는 성능 튜닝 테스트를 할 때 종종 보이는데, Log를 Debug 모드로 켜놓고 Ramp Up 테스트를 할 때 볼 수 있는 현상입니다. Log의 데이터를 많이 쓰다 보니, 작업이 밀려서 위와 같은 현상이 발생한 것입니다.

분포패턴과 와탭

다양한 응답 분포패턴을 보니 어떠신가요? 분포만으로도 웹 서버의 문제를 어느 정도 알 수 있다는 것이 놀랍지 않나요? 다음 기회에 추가 분포패턴을 더 상세히 설명드리도록 하겠습니다.

APM Open Beta 기간에 많은 기업들이 와탭에 가입하신 후 저희 서비스를 써보고, 성능 튜닝에 대해서 많은 문의를 해주십니다. 설치형 APM이었다면 비싼 관리비와 별도의 컨설팅 비용을 지불해야만 했겠지만, SaaS형인 와탭 APM은 서비스 가입과 동시에 와탭의 전문가들을 내부 성능팀으로 두는 것과 동일한 효과를 얻으실 수 있습니다.

project에서  와탭의 고객지원 계정 help@whatap.io를 추가해 주시면, 와탭 팀이 매 시간 여러분의 서비스를 함께 모니터링하게 됩니다. 장애가 발생하는 종합적인 원인과 여러 유용한 가이드를 리포트 또는 메일로 보내드리고 긴급할 경우에는 전화로 연락드립니다.

추후 포스팅에선 실제 장애가 발생한 경우와, 그에 따라 어떻게 장애 리포트가 발송되었는지 공유하도록 하겠습니다.

 

 

2 thoughts on “분포 패턴으로 보는 장애 유형 Part I (수학 이야기보다 더 중요한..)”

    1. 안녕하세요. 폰으로 보신다는 말씀이죠?
      볼수 있기는 하나, 화면상의 제약으로 카드 단위로 끊겨서 보일듯 합니다.

      ipad mini 이상 버전의 디바이스 부터는 보시는데 무리가 없습니다. 🙂

댓글은 닫혔습니다.