문제는 현 상태와 목표 상태의 차이를 의미한다. 이것을 다르게 표현하면 문제는 현 상태에 대한 측정(혹은 확인)과 목표 상태에 대한 결정(혹은 설정)에 의해 정의 된다고 볼 수 있다. 성능 문제도 같은 관점에서 정의될 수 있다. 성능 문제는 현시스템에 대한 테스트나 운영 시스템을 모니터링함으로써 현재 상태를 측정하고 목표 성능을 결정함으로써 도출될 수 있다.

사회 현상에서는 문제의 현상태를 정확히 인식하고 목표가 올바르면 쉽게 해결된다. 그러나 시스템에서는 현시스템의 성능 상태가 정확히 측정되어도 된다해도 현상태와 목표만으로 접근되지 않는 요소들이 존재한다. 갑자기 시스템이 다운되었을때, 현상은 비정상적인 시스템 다운이고 목표는 안정된 운영이라고 볼수 있다. 이러한 상황에서는 문제의 원인을 분석하는 것은 어렵고 지루한 일이 된다. 또한 문제가 수치로 정량화되지 못하고 yes/no 형태이기 때문에 몇% 좋아졌다라는 것이 없고 all or nothing이 되기 쉽다. 이런 경우 문제 해결이 컨설턴트 입장에서는 도박과 같아진다.

시스템 최적화

시스템 성능 최적화는 시스템이 지정된 자원에서 최적의 처리상태를 발휘할 수 있도록 하는 것이다. 최적의 성능을 위해서는 자원(CPU,MEM,NET등)을 제외한 모든 병목 구간이 제거되고 장애가 발생하지 않아야 한다. 자원의 병목은 자원을 증설함으로써 해결될 것이므로 더 이상 이슈가되지 않는다(다만 비정상적인 자원 사용은 제외) 장애는 서비스가 불가능한 상태를 의미하며 이것은 버그에 의한 시스템 다운도 포함된다. 시스템 최적화는 일반적으로 처리량을 최대로 끌어 올리기 위한 튜닝이나 장애 등을 해결하는 것을 포괄한다.

장애 해결

장애는 서비스 중지 혹은 과도한 응답시간 지연으로 인한 실질적인 서비스 불가능 상태를 포함한다. 따라서 장애 해결이란 서비스 불능 상태의 원인을 찾아내 제거 하는 것이다. 장애 해결에는 성능 테스트가 반드시 선행되는 것은 아니다. 시스템 다운 이나 Out Of Memory에러, 시스템의 다운등은 대표적인 장애 현상이라 볼 수 있다. 장애는 보통 직관적으로 파악되기 때문에 분석 과정을 거치지 않지만, 인위적인 현상 재연은 중요하다. 필요한 시점에 현상 재연이 가능하면 70~80%는 해결한거나 다름없다. 특히나 개발 서버에서 재연할 수 있다면 논리적 사고만 한다면 누구나 해결할 수 있다.그 만큼 장애 해결을 위해 현상재연은 중요하다.

성능 튜닝

성능은 처리량과 서비스 응답시간으로 표현된다. 서비스의 응답시간을 줄이고 처리량을 늘리기 위한 노력을 튜닝이라 한다. 성능 튜닝을 위해서는 현상태에 대한 측정과 목표 설정이 절대적이다. 따라서 성능 튜닝은 테스팅과 밀접하게 연관되어있다. 보통 성능 튜닝 활동을 병목 구간을 찾아 끊임없이 해결하는 방법으로 진행된다. 때로는 H/W자원을 증설히기도 하고 또는 S/W적 파라미터 값을 조정하는 형태로 진행된다.

최적화 활동의 어려움

응답시간을 개선하거나 처리량을 늘리고 시스템 다운의 원인을 찾아가는 것을 어려움의 연속이다. 그런데 최적화는 단순이 기술적 어려움 뿐만 아니라 상황적 혹은 접근법 때문에 발생하는 어려움이 존재한다.

• 문제 정의가 어려워서(성능 분석이 포함된 경우) 문제가 있는지 조차 불분명한 경우이다. 레거시를 테스트 하지도 않고 느낌으로 시스템 성능 목표를 결정하거나 열악한 환경에서 간단한 테스트나 로그만으로 현 시스템의 성능으로 규정하는 경우에는 문제 정의 자체가 않되어 있는 경우다. 문제의 정의가 불분명한 상태에서 성능을 튜닝한다는 것은 목표를 정하지 않고 달려가는 것과 같다.

• 원인 파악이 어려워서 운영 전 혹은 운영 중인 시스템에서 모두 나타나는 유형으로 현상은 명확한데, 원인을 찾아내기 어려운 경우가 있는데 보통 서버 S/W, H/W, 패키지의 버그인 경우가 많다

• Follow Up 혹은 검증이 어려워서 주로 운영 시스템에서 나타나는 특성으로 장애 원인은 파악하였는데 그것을 해결 하는데 어려운 경우 혹은 장애가 해결 되었는지 확신할 수 없거나 증명할 수 없는 경우를 말한다. 코딩 표준이 잘못되거나 교육이 부족하여 수정해야하는 프로그램이 너무 많은 경우가 이에 해당된다.

다음은 최적화 활동이 어려웠던 사례들이다.

• 불안하니까 시스템을 한번 봐 주세요 =>[문제가 있는지부터 찾아야 함]
• 갑자기 아무 로그도 없이 Down되었습니다 =>[모니터링 툴 설치 후 무작정 기다림]
• 해결을 위해서 해당 코드를 모두 찾아서 수정해야 합니다 => [해결하는데 많은 시간과 인력이 소요됨]
• 수강 신청 때만 나타납니다. =>[검증하기 위해서 6개월을 기다려야 함]

최적화 활동을 위한 조언

최적화 활동의 어려움은 기술적 문제도 있지만 경험이 부족한 경우에 접근법에 대한 부족한 인식에서도 기인한다. 다음의 내용은 최적화 활동시에 유의해야할 사항들이다

관심의 분할은 문제 해결의 기본이다

초기에는 거시적인 관점에서 분석하고 범위를 좁혀야 한다. 시스템,응용,DB혹은 network등 크게 어느 분야에 원인이 있는지를 식별해야 한다. 초기에 거시적으로 접근하지 않고 나타나는 현상 하나에 집착하여 문제 원인을 속단하거나 하나의 현상에만 집착하다 보면 잘못된 결과를 도출하는 경우가 많다. 적절한 시점에 전문가 소싱을 못하게 되는 경우가 많으며 특히 이러한 오류는 고객에게 잘못된 확신을 심어주는 경우가 많아 장애 해결 자체가 실패하거나 장애 해결 담당자의 신뢰성에 치명적으로 손상을 주게 된다. 나는 튜닝을 시작하기 전에 “처음 생각했던 원인의 90%는 잘못된 것이었다” 라고 이야기 한다 이렇듯 장애 해결 초기에 보이는 문제 보다는 거시적인 관점에서 원인을 분석하고 초기에 적절한 전문가를 소싱하도록 하는 것이 중요하다.

- Top Down 방식으로 접근하라

앞에서도 언급되었듯이 지엽적인 현상에 집착하여 원인 전체를 결정하지 말고 전체에서 조금씩 세분화 해가는 것이 좋다. 전체 관점에서 항상 생각하고 발견되는 fact들을 끊임없이 전체의 틀 속에서 해석함으로써 오류를 피할 수 있다.

- 하나 보다는 둘이 낫다

진심으로 협력하는 사람이 많을 수록 문제는 잘 풀린다. 특히 이해 관계가 없는 사람들이 머리는 맞대고 고민 하는 것은 문제 해결에서 가장 중요한 지름 길이다. 이와 연관되어 전문가 들을 여러 회사에서 소싱해서 하는 조직하는 경우 서로간의 이해 관계로 인해 문제 해결이 더디어 지는 경우가 종종 있다 심지어 한 회사의 팀이 다르다는 이유만으로 이러한 현상이 발생하는 경우도 있다.

- 공개된 가설은 모두(이해당사자)를 보호한다

장애 원인은 쉽게 장담할 수 없는 경우가 허다하다. 과도한 확신에 의한 작업 혹은 밀실 작업은 신뢰의 적이며 장애가 해결된다 치더라도 시스템의 원활한 개발/운영에 결코 도움이 되지 않는다. 과도한 확신으로 특정 부분에 문제를 제기 했을때 그것이 원인이 아니라고 결론나게 되면 해당부분의 담당자와는 적이되며 이것은 이후의 진행에 결코 도움이 되지 않는다. 관찰되는 현상에서 fact와 fact가 아닌 것을 분리하고 이것들을 조합하여 논리적인 가설을 수립하여 미리 공개함으로써 각 분야별 담당자들의 관심과 협업을 끌어 내는 것은 무엇보다 중요하다. 이것은 이후에 실제로 가설이 사실로 증명되었을 때도 훨씬 빠른 조치를 가능케한다.

- 눈(모니터링 툴)을 감으면 길(해결 방법)이 보이지 않는다

아무리 기술적 전문가라 할지라도 fact를 수집하지 못하면 장애를 해결 할 수 없다. fact를 수집하기 위해서는 적절한 로그/모니터링 툴이 필수이다 사용자 눈에 보이는 현상만 가지고 장애를 해결해 달라고 요구하거나 혹은 경험/사례를 가지고 해결해 달라고 요구하는 것은 매우 무책임한 행동이다. 심지어 “척보면 알지 않씁니까? 전문가인데…” 이렇게 말 하는 사람도 있다.

- 일정은 장담할 수 없다

3일 안에 해결해라.. 혹은 몇시간에 해결해라.. 물론 비즈니스 적으로 이러한 목표가 있을 수 있으나 어디까지나 목표일 뿐이다. 장애 해결 혹은 성능 튜닝은 최대할 빨리 하기 위해서 노력할 뿐이지 장담할 수 없다. 다만 추정이 있을 뿐이다.

- 문제해결을 찍기에 의존하지 마라

찍기 방식이라 함은 과거의 유사 현상에 비추어 현 시스템의 장애 원인을 감각으로 결정하는것을 말한다. 효과는 맞기만 하면 최상이다. 그러나 틀리면 피해가 크다. 시간을 낭비하는 결과를 낳는다. 문제해결 담당자가 직감을 믿고 과거사례를 기반으로 문제의 원인을 결정하면 초기 한두번은 고객(운영 담당자)의 관심을 유도할 수 있다, 하지만 나중에는 양치기 소년 처럼 신뢰를 잃게 되어 아무것도 할 수 없는 상태에 이르게된다.

글을 마치며

최적화 활동은 여러가지 유형으로 나타난다. 신속하게 해결하는 것이 무엇보다 중요하지만, 절차 또는 대응 방식 또한 중요하다 적절한 사례와 경험들을 조직적으로 축적하여 개발/운영자들이 신속하게 장애를 해결할 수 있도록하는 것이 가장 best이다. 그 이후에 장애 해결 TFT가 구성되면 문제를 속단하지 말고 이해당사자들의 신뢰를 유지하면서 문제를 해결해야 한다.

• 최종 해결은 사람
• 갈림길에서의 선택 능력이 노하우
• 현상이 100%해석(=원인파악)된다면 문제는 100%해결
• 좋은 (결정)은 (경험 + 사례)에 비례
• Fact의 수집(모니터링,모니터링,모니터링)