2011.06.09

기고 | 클라우드 컴퓨팅에서의 에러 로깅 전략

David Taber | CIO

에러(Error) 처리는 일상적이고 진부한 문제다. 당연하다고 여길지도 모르겠다. 트랜젝션과 트레이스 로그도 마찬가지다. 간단한 가상화 클라우드(예, MySQL 서버)에서는 몇몇 계층의 소프트웨어 스택에서 저수준(低水準)의 에러 로깅을 당연시하기도 한다.

그러나 이것이 이들 로그의 존재를 당연시해도 된다는 의미는 결코 아니다. VM을 제대로 설정하지 못하거나, VM이 붕괴됐을 클라우드 호스팅 공급자에 요금을 지불하지 않는다면 로그가 없어질 수 있다. 이들 서버 쪽에 로그가 없다면, 문제해결에 오랜 시간이 걸리게 된다.

무인 시스템에 로그가 부족한 것은 심각한 문제다. 장기간 로그를 아카이빙 하고 싶어하는 데에는 이유가 있기 마련이다. 따라서 이 부분에 인색하게 굴어서는 안 된다.

클라우드 기반의 애플리케이션에서는 상황이 더욱 재미있어진다. 일부에는 서버 측면에서의 로깅이라는 게 전혀 없다. 심지어는 최상의 클라우드 애플리케이션도 잠시 동안만 완전한 형태의 로깅을 제공하며, 자세한 설명 없이 로깅을 꺼버리곤 한다.

최상급 클라우드 애플리케이션이라면 디버깅 이력이 훌륭할 것이다. 그러나 몇 시간 전 발생한 에러 상태를 재구성한다고 가정해보자. 글쎄다. 운이 좋다면 에러 스택을 추적할 수 있는 이메일을 받아보는 수준일 터다 .

즉 클라우드에서는(특히 클라우드 간에는) 서버(또는 서비스) 측면의 에러 로깅에 의지할 수 없다. 서버 트랜젝션과 관련해 실제 어떤 일이 벌어지고 있는지 알고 싶다면 독자적으로 서버 측면의 에러 쓰로잉(erro-throwing) 코드를 써야 한다.

일반적으로는 서버 클라우드에서 일어나는 에러를 ‘Splunk’나 ‘Exceptional’, 또는 ‘SysLog’ 기반 제품 같은 에러 로깅 서비스 요청을 통해 보완하고 싶어한다. 상대적으로 저렴하기 때문이다.

더 나아가 요청자(또는 클라이언트)에 초점을 맞추는 클라우드 로깅 전략을 개발할 필요가 있을 수도 있다. 그렇다면 이런 로깅 코드를 개발해야 하는 이유는 뭘까?

• 요청자 측면에서, 본인만이 에러가 발생한 애플리케이션 수준의 정황을 알 수 있다. 서버 측면에서는, 서비스가 알 수 있는 부분은 요청자의 URL/IP 주소, 콜 파라미터, 타임 스탬프이다. 물론 클라이언트 측면의 쓰레드 식별자를 각 서버 요청에 포함할 수 있을 것이다. 그러나 양 측면에서 모두 로깅을 하지 말라는 법이 어디 있을까?

• 요청자만이 '응답하지 않는 서버' 에러를 로그 할 수 있다. 또 당연히 요청자만이 서버가 사일런트 모드가 됐을 경우의 트랜젝션 복구 전략을 시작하거나 재시도 할 수 있다.

• 요청자는 특정 오류에 어떤 트랜젝션, 사용자, 레코드가 영향을 받는지 정확히 알 수 있다. 요청자의 에러 처리 코드는 서버 응답 없이 애플리케이션의 요건(예, 트랜젝션을 'on hold' 상태로)을 충족시키는 전략을 이행할 수 있다.

적어도 애플리케이션 데이터를 일관성 있는 상태로 만들어 서버에서의 에러가 애플리케이션 전반에 걸친 붕괴로 확대되지 않도록 할 수 있을 것이다. 또 요청자는 복구와 문제해결을 앞당기기 위해 원하는 만큼 많은 트랜젝션과 히스토리를 로컬 로그 파일에 집어 넣을 수 있다.

그러나 불행히도 클라이언트 측면의 에러 처리 및 로깅은 많은 개발자들에게 '새로운 요구사항'이 될 가능성이 크다. 코드 주석 등과 마찬가지다. 개발자들은 불가피한 부정적인 사례 (또는 '아무것도 일어나지 않는' 사례)를 다루기보다는 긍정적인 사례를 만족시키는데 중점을 두곤 한다.

그러나 클라우드 애플리케이션 개발자들은 더 나은 에러 처리 습관을 기를 필요가 있다. 지저분한 업무에 있어서는 서버 로그에 의존할 수 없는 경우가 종종 있기 때문이다.

요청자/ 클라이언트 측면의 에러 관리를 위해서는 로그를 어디에 유지해야 할지 고려해 보는 게 좋다. 전통적인 '텍스트 파일에 메시지를 포함시키기' 전략은 가상화 환경에서는 그다지 적합하지 않다. 이런 텍스트 파일은 또 다른 VM에 위치할 수 있기 때문이다.

경우에 따라선 한달 이상 추적이 힘들 수도 있다. (물론 전략을 세울 때는 몇 개월 동안의 문제해결/디버깅 필요를 모를 수도 있다고 가정해야 한다. 에러 로그가 일정 수준의 포렌직스를 지원할 필요가 있기 때문이다.)

자세한 에러 정보를 관련 레코드에 저장 하는 건 어떨까? J2EE를 생각해보기 바란다. 스택 트레이스(stack trace)가 크다면 공간을 눈깜짝할 사이에 잡아먹을 수 있다. 그러나 디스크 공간은 디스크 공간이다. 소수의 ‘BLObs’가 데이터베이스를 느리게 만들지는 않을 수도 있다.

이런 전략에 있어 문제점은 "특정 단일 레코드와 관련된 두 번째(또는 관련) 에러에 어떤 일이 발생할 것인가?"하는 부분이다. 개발자들은 프로그래밍 측면에서 도전이 됐던 과거의 에러들을 어떤 방식으로 보관할지 현명하게 파악해야 한다.

에러 로깅에서 마지막 영역은 통보다. 다른 누군가가 문제를 어떤 방식으로 찾을 것인가 하는 것이다. 많은 클라우드 환경은 이와 관련해 충분한 기능을 제공하고 있지 않다.

즉 에러 상태가 지속적으로 축적되거나, 관리자나 개발자들이 정기적으로 귀찮은 업무를 수행해야 한다는 의미다. 메시지를 트위터 피드로 보내고 싶든, 라바 램프에 연결된 USB 포트를 켜든, 에러 억제와 빠른 복구의 첫 번째 단계는 실시간 통보다.

*David Taber는 '세일즈포스닷컴 성공의 비밀'의 저자이자 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr




2011.06.09

기고 | 클라우드 컴퓨팅에서의 에러 로깅 전략

David Taber | CIO

에러(Error) 처리는 일상적이고 진부한 문제다. 당연하다고 여길지도 모르겠다. 트랜젝션과 트레이스 로그도 마찬가지다. 간단한 가상화 클라우드(예, MySQL 서버)에서는 몇몇 계층의 소프트웨어 스택에서 저수준(低水準)의 에러 로깅을 당연시하기도 한다.

그러나 이것이 이들 로그의 존재를 당연시해도 된다는 의미는 결코 아니다. VM을 제대로 설정하지 못하거나, VM이 붕괴됐을 클라우드 호스팅 공급자에 요금을 지불하지 않는다면 로그가 없어질 수 있다. 이들 서버 쪽에 로그가 없다면, 문제해결에 오랜 시간이 걸리게 된다.

무인 시스템에 로그가 부족한 것은 심각한 문제다. 장기간 로그를 아카이빙 하고 싶어하는 데에는 이유가 있기 마련이다. 따라서 이 부분에 인색하게 굴어서는 안 된다.

클라우드 기반의 애플리케이션에서는 상황이 더욱 재미있어진다. 일부에는 서버 측면에서의 로깅이라는 게 전혀 없다. 심지어는 최상의 클라우드 애플리케이션도 잠시 동안만 완전한 형태의 로깅을 제공하며, 자세한 설명 없이 로깅을 꺼버리곤 한다.

최상급 클라우드 애플리케이션이라면 디버깅 이력이 훌륭할 것이다. 그러나 몇 시간 전 발생한 에러 상태를 재구성한다고 가정해보자. 글쎄다. 운이 좋다면 에러 스택을 추적할 수 있는 이메일을 받아보는 수준일 터다 .

즉 클라우드에서는(특히 클라우드 간에는) 서버(또는 서비스) 측면의 에러 로깅에 의지할 수 없다. 서버 트랜젝션과 관련해 실제 어떤 일이 벌어지고 있는지 알고 싶다면 독자적으로 서버 측면의 에러 쓰로잉(erro-throwing) 코드를 써야 한다.

일반적으로는 서버 클라우드에서 일어나는 에러를 ‘Splunk’나 ‘Exceptional’, 또는 ‘SysLog’ 기반 제품 같은 에러 로깅 서비스 요청을 통해 보완하고 싶어한다. 상대적으로 저렴하기 때문이다.

더 나아가 요청자(또는 클라이언트)에 초점을 맞추는 클라우드 로깅 전략을 개발할 필요가 있을 수도 있다. 그렇다면 이런 로깅 코드를 개발해야 하는 이유는 뭘까?

• 요청자 측면에서, 본인만이 에러가 발생한 애플리케이션 수준의 정황을 알 수 있다. 서버 측면에서는, 서비스가 알 수 있는 부분은 요청자의 URL/IP 주소, 콜 파라미터, 타임 스탬프이다. 물론 클라이언트 측면의 쓰레드 식별자를 각 서버 요청에 포함할 수 있을 것이다. 그러나 양 측면에서 모두 로깅을 하지 말라는 법이 어디 있을까?

• 요청자만이 '응답하지 않는 서버' 에러를 로그 할 수 있다. 또 당연히 요청자만이 서버가 사일런트 모드가 됐을 경우의 트랜젝션 복구 전략을 시작하거나 재시도 할 수 있다.

• 요청자는 특정 오류에 어떤 트랜젝션, 사용자, 레코드가 영향을 받는지 정확히 알 수 있다. 요청자의 에러 처리 코드는 서버 응답 없이 애플리케이션의 요건(예, 트랜젝션을 'on hold' 상태로)을 충족시키는 전략을 이행할 수 있다.

적어도 애플리케이션 데이터를 일관성 있는 상태로 만들어 서버에서의 에러가 애플리케이션 전반에 걸친 붕괴로 확대되지 않도록 할 수 있을 것이다. 또 요청자는 복구와 문제해결을 앞당기기 위해 원하는 만큼 많은 트랜젝션과 히스토리를 로컬 로그 파일에 집어 넣을 수 있다.

그러나 불행히도 클라이언트 측면의 에러 처리 및 로깅은 많은 개발자들에게 '새로운 요구사항'이 될 가능성이 크다. 코드 주석 등과 마찬가지다. 개발자들은 불가피한 부정적인 사례 (또는 '아무것도 일어나지 않는' 사례)를 다루기보다는 긍정적인 사례를 만족시키는데 중점을 두곤 한다.

그러나 클라우드 애플리케이션 개발자들은 더 나은 에러 처리 습관을 기를 필요가 있다. 지저분한 업무에 있어서는 서버 로그에 의존할 수 없는 경우가 종종 있기 때문이다.

요청자/ 클라이언트 측면의 에러 관리를 위해서는 로그를 어디에 유지해야 할지 고려해 보는 게 좋다. 전통적인 '텍스트 파일에 메시지를 포함시키기' 전략은 가상화 환경에서는 그다지 적합하지 않다. 이런 텍스트 파일은 또 다른 VM에 위치할 수 있기 때문이다.

경우에 따라선 한달 이상 추적이 힘들 수도 있다. (물론 전략을 세울 때는 몇 개월 동안의 문제해결/디버깅 필요를 모를 수도 있다고 가정해야 한다. 에러 로그가 일정 수준의 포렌직스를 지원할 필요가 있기 때문이다.)

자세한 에러 정보를 관련 레코드에 저장 하는 건 어떨까? J2EE를 생각해보기 바란다. 스택 트레이스(stack trace)가 크다면 공간을 눈깜짝할 사이에 잡아먹을 수 있다. 그러나 디스크 공간은 디스크 공간이다. 소수의 ‘BLObs’가 데이터베이스를 느리게 만들지는 않을 수도 있다.

이런 전략에 있어 문제점은 "특정 단일 레코드와 관련된 두 번째(또는 관련) 에러에 어떤 일이 발생할 것인가?"하는 부분이다. 개발자들은 프로그래밍 측면에서 도전이 됐던 과거의 에러들을 어떤 방식으로 보관할지 현명하게 파악해야 한다.

에러 로깅에서 마지막 영역은 통보다. 다른 누군가가 문제를 어떤 방식으로 찾을 것인가 하는 것이다. 많은 클라우드 환경은 이와 관련해 충분한 기능을 제공하고 있지 않다.

즉 에러 상태가 지속적으로 축적되거나, 관리자나 개발자들이 정기적으로 귀찮은 업무를 수행해야 한다는 의미다. 메시지를 트위터 피드로 보내고 싶든, 라바 램프에 연결된 USB 포트를 켜든, 에러 억제와 빠른 복구의 첫 번째 단계는 실시간 통보다.

*David Taber는 '세일즈포스닷컴 성공의 비밀'의 저자이자 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr


X