김성조 // 자바서비스컨설팅 제품개발팀 기술이사
sjkim@javaservice.com
웹기반 시스템 하에서의 애플리케이션성능관리(APM)를 진행함에 있어서 성능 최적화 활동을 위한 기본적인 가이드라인은 무엇일까. 문제 해결과 시스템에 대한 성능 최적화의 정의와 관련 개념에 대해서 알아본다. <편집자>
문제는 현 상태와 목표 상태의 차이를 의미한다. 이것을 다르게 표현하면 문제는 현 상태에 대한 측정과 목표 상태에 대한 결정에 의해 정의 된다고 볼 수 있다. 성능 문제도 같은 관점에서 정의될 수 있다. 성능 문제는 테스트나 운영 시스템을 모니터링함으로써 현 상태를 측정하고 목표 성능에 대한 결정함으로써 도출될 수 있다.
사회 현상에서는 문제의 현상태를 정확히 인식하고 목표가 올바르면 쉽게 해결된다. 그러나 시스템에서는 현시스템의 성능 상태가 정확히 측정된다해도 현상과 목표만으로 접근되지 않는 요소들이 존재한다. 갑자기 시스템이 다운됐을 때, 현상은 비정상적인 시스템 다운이고 목표는 안정된 운영이라고 볼 수 있다.
이러한 상황에서는 현상 측정보다는 문제의 원인을 분석하는 것이 오히려 어렵고 지루한 일이 된다. 또한 문제가 정량화되지 못하고 ‘예스/노’ 형태이기 때문에 컨설턴트 입장에서는 도박과 같은 일을 해야 한다. 즉 이런 상황에서는 몇 % 좋아졌다라는 것이 없고 ‘올 오어 낫씽(all or nothing)’이기 때문이다.
시스템 성능 최적화
성능 최적화는 시스템이 지정된 자원에서 최적의 처리상태를 발휘할 수 있도록 하는 것이다. 최적의 성능을 위해서는 자원(CPU, MEM, NET 등)을 제외한 모든 병목 구간이 제거되고 장애가 발생하지 않아야 한다. 자원의 병목은 자원을 증설함으로써 해결될 것이므로 더이상 이슈가 되지 않는다(다만 비정상적인 자원 사용은 제외) 장애는 서비스가 불가능한 상태를 의미하며 이것은 버그에 의한 시스템 다운도 포함된다.
따라서 성능 최적화는 성능 문제 해결과 장애 해결이라고 정의할 수 있다. 혼용해 사용하는 경우가 많은데 성능문제 해결과 장애 해결은 다르다.
성능 문제 해결
시스템의 성능문제 해결이란 성능 문제의 원인을 파악하는 과정으로. 시스템의 병목 구간을 찾아내어 성능 문제의 원인을 규명하는 것이다.
예를 들어 쓰레드 행(Hang)같은 경우는 성능문제해결 영역에 포함되지는 않는다. 그러나 버블소트를 퀵소트로 변경하는 것은 성능 문제 해결 영역에 포함되지만 장애해결영역에는 포함되지 않는다.
성능 분석은 시스템의 현 상태를 측정하고 목표 상태를 결정하여 이들간의 GAP 즉 성능을 분석해가는 행위라면 성능문제 해결은 이러한 성능 문제의 원인 파악하는 행위라는 점에서 구별된다.
장애 해결
장애는 서비스 중지 혹은 과도한 응답시간 지연으로 인한 실질적인 서비스 불가능 상태를 포함한다. 따라서 장애 해결이란 서비스 불능 상태의 원인을 찾아내는 활동이다. 장애 해결에는 성능 테스트가 반드시 선행되는 것은 아니다. 장애는 서비스 불능상태의 원인을 찾아서 해소하는 것이기 때문에 추가적인 장애가 발생하지 않는 것을 확인하는 방법으로 검증하는 것이 일반적이다.
테스트 시에는 주로 성능문제가 발생하고 운영시에 문제가 발생했다는 것은 보통 장애를 의미하는 경우가 많다. 장애는 보통 현상적으로 혹은 직관적으로 파악되는 것이 일반적이다. 시스템 다운이나 메모리 아웃(Out of Memory) 에러 등은 대표적인 장애 현상이라 볼 수 있다.
장애 현상재연의 중요성
장애는 보통 직관적으로 파악되기 때문에 분석 과정을 거치지 않지만, 인위적인 현상 재연은 중요하다. 필요한 시점에 현상 재연이 가능하면 70~80%는 해결한 것이나 다름없다. 특히나 개발 서버에서 재연할 수 있는 장애는 논리적 사고만 한다면 누구나 해결할 수 있다.그만큼 장애 해결을 위해 현상재연은 중요하다.
성능 최적화 활동
성능 최적화 활동은 성능문제와 장애를 해결하기 위한 활동으로 매우 높은 전문성을 필요로 한다. 그럼에도 실제 현장에서 최적화 활동은 쉽지 않다. 어려움에 봉착한 최적화 활동의 원인은 다음과 같이 분류할 수 있다.
1.문제 정의가 어려워서(성능 분석이 포함된 경우) 문제가 있는지조차 불분명한 경우이다. 레거시를 테스트 하지도 않고 느낌으로 시스템 성능 목표를 결정하거나 열악한 환경에 서 간단하게 테스트하고 그것이 현 성능 상태로 규정하는 경우에 많이 발생한다.
2. 원인 파악이 어려워서 운영 전 혹은 운영 중인 시스템에서 모두 나타나는 유형으로 현상은 명확한데, 원인을 찾아내기 어려운 경우다. 보통 서버 소프트웨어, 하드웨어, 패키지의 버그인 경우가 많다
3. 검증이 어려워서 주로 운영 시스템에서 나타나는 특성으로 장애 원인은 파악했는데 그것을 해결 하는데 어려운 경우 혹은 장애가 해결됐는지 확신할 수 없거나 증명할 수 없는 경우를 말한다. 보통 프로그램 변경이 많이 발생하는 경우이다.
성능 최적화 활동을 위한 조언
최적화 활동의 어려움은 기술적 문제도 있지만 경험이 부족한 경우에 접근법에 대한 부족한 인식에서도 기인한다. 다음의 내용은 최적화 활동 시 유의해야 할 사항이다.
1. 관심 분할은 문제 해결의 기본이다
초기에는 거시적인 관점에서 분석하고 범위를 좁혀야 한다. 시스템, 응용, DB혹은 네트워크 등 크게 어느 분야에 원인이 있는지를 식별해야 한다.
초기에 거시적으로 접근하지 않고 나타나는 현상 하나에 집착해 문제 원인을 속단하거나 하나의 현상에만 집착하다 보면 잘못된 결과를 도출하는 경우가 많다. 적절한 시점에 전문가 소싱을 못하게 되는 경우가 많으며 특히 이러한 오류는 고객에게 잘못된 확신을 심어주는 경우가 많아 장애 해결 자체가 실패하거나 장애 해결 담당자의 신뢰성에 치명적으로 손상을 주게 된다.
필자는 입버릇처럼 “처음 생각했던 원인의 90%는 잘못된 것이었다”라고 이야기한다. 이렇듯 장애 해결 초기에 보이는 문제보다는 거시적인 관점에서 원인을 분석하고 초기에 적절한 전문가를 소싱하도록 하는 것이 중요하다.
2. 탑 다운 방식으로 접근하라
앞에서도 언급했듯이 지엽적인 현상에 집착해 원인 전체를 결정하지 말고 전체에서 조금씩 세분화해가는 것이 좋다. 전체 관점에서 항상 생각하고 발견되는 사실들을 끊임없이 전체의 틀 속에서 해석함으로써 오류를 피할 수 있다.
3. 하나 보다는 둘이 낫다
진심으로 협력하는 사람이 많을수록 문제는 잘 풀린다. 특히 이해관계가 없는 사람들이 머리는 맞대고 고민하는 것은 문제 해결에서 가장 중요한 지름길이다. 이와 연관돼 전문가 들을 여러 회사에서 소싱해 조직하는 경우 서로간의 이해관계로 인해 문제 해결이 더뎌 지는 경우가 종종 있다. 심지어 한 회사의 팀이 다르다는 이유만으로 이러한 현상이 발생하는 경우도 있다.
4. 공개된 가설은 모두(이해당사자)를 보호한다
장애 원인은 쉽게 장담할 수 없는 경우가 허다하다. 과도한 확신에 의한 작업 혹은 밀실 작업은 신뢰의 적이며 장애가 해결된다 치더라도 시스템의 원활한 개발/운영에 결코 도움이 되지 않는다.
과도한 확신으로 특정 부분에 문제를 제기했을 때 그것이 원인이 아니라고 밝혀지면 해당부분의 담당자와는 적이 되며 이것은 이후의 진행에 결코 도움이 되지 않는다.
관찰되는 현상에서 팩트(fact)와 팩트가 아닌 것을 분리하고 이것들을 조합해 논리적인 가설을 수립해 미리 공개함으로써 각 분야별 담당자들의 관심과 협업을 끌어내는 것은 무엇보다 중요하다. 이것은 이후에 실제로 가설이 사실로 증명됐을 때도 훨씬 빠른 조치를 가능케 한다.
5. 눈(모니터링 툴)을 감으면 길(해결 방법)이 보이지 않는다
아무리 기술적 전문가라 할지라도 팩트를 수집하지 못하면 장애를 해결 할 수 없다. 팩트를 수집하기 위해서는 적절한 로그/모니터링 툴이 필수이다.
사용자 눈에 보이는 현상만 가지고 장애를 해결해 달라고 요구하거나 혹은 경험/사례를 가지고 해결해 달라고 요구하는 것은 매우 무책임한 행동이다. 심지어 “척보면 알지 않습니까? 전문가인데…” 이렇게 말 하는 사람도 있다.
6. 일정은 장담할 수 없다
3일 안에 해결해라. 혹은 몇시간에 해결해라. 물론 비즈니스적으로 이러한 목표가 있을 수 있으나 어디까지나 목표일뿐이다. 장애 해결 혹은 성능 튜닝은 최대할 빨리 하기 위해서 노력할 뿐이지 장담할 수 없다. 다만 추정이 있을 뿐이다.
만약 장애 해결 담당자가 너무 짧은 시간을 약속하게 되면 필연적으로 찍기 방식을 적용할 수밖에 없다. 찍기 방식이라 함은 과거의 유사 현상에 비춰 현 시스템의 장애 원인을 결정하는 방식으로 맞기만 하면 매우 빠른 방식이다. 그러나 틀릴 경우에 피해가 크며 특히 시간을 낭비하는 결과를 낳는다. 찍기 방식의 적용은 초기 한두번은 운영 담당자의 도움을 유도할 수 있지만, 나중에는 아무것도 할 수 없는 상태에 이르게 된다.
또한 찍기 방식은 장애 해결 담당자의 개인적 스킬업에 결코 도움이 되지 않는다. 인터넷이나, 다른 사람 혹은 자신의 경험을 기반으로 분석 없이 결론을 만들게 됨으로 해결 되든 되지 않든 남는 것이 없다. 나아가 조직의 문제해결 역량에도 도움이 되지 않는다. 정말 어쩔 수 없는 상태가 아니면 장애 해결을 위해 찍기 방식을 사용해서는 안된다.
간혹 최적화 활동 초기에 절차적으로 접근하다가 일정에 쫓겨 찍기 방식으로 돌아서면 비참해 진다 따라서 항상 이점에 주의해야 한다.
그럼에도 찍기 방식이 사용되는 이유는 일치하기만 하면 가장 빠른 길이기 때문이다. 따라서 이것을 조직적으로 관리하는 것은 문제 해결에 많은 도움이 된다. 조직적으로 관리한다는 것은 사례를 수집하고 공유해 장애해결 담당자가 아닌 일반 운영자에 의해 이러한 사례를 적용해 문제를 해결하는 것이 좋다.
글을 마치며
성능 최적화는 여러 가지 유형으로 나타난다. 신속하게 해결하는 것이 무엇보다 중요하지만, 절차 또는 대응 방식 또한 중요하다.
적절한 사례와 경험들을 조직적으로 축적해 개발/운영자들이 신속하게 장애를 해결할 수 있도록 하는 것이 가장 최선이다. 그 이후에 장애 해결 TFT가 구성되면 문제를 속단하지 말고 이해당사자들의 신뢰를 유지하면서 문제를 해결해 가기 바란다.
