시스템에 장애가 생겼을 때, 여러분은 어떻게 하고 계신가요? 당황스럽고, 어디에서부터 확인을 해야 할지 막막하지는 않으셨나요? 오늘은 시스템 장애, 문제에 대해 알아보고자 합니다. 시스템 장애란 무엇이며, 어떤 방식으로 문제를 해결하는 것이 좋을까요?
성능 튜닝에 성능 장애가 발생한 경우, 어떤 관점에서 문제를 바라보고 접근을 해야 하는지 혼란스러울 때가 많습니다. 이럴 경우에 우리는 어떤 관점에서 봐야 하는지 이론적으로 설명을 드리고자 합니다.
먼저 문제(장애)란 무엇일까요? 문제란 현재 상태와 목표 상태의 불일치하는 상태를 뜻합니다. 그렇다면 여기에서 뜻하는 현재 상태란 무엇일까요? 현재 상태란 그 말 그대로 성능 관점에서 보는 성능의 현재 상태를 뜻합니다. 현재 처리량이 얼마인지, 어떤 속도를 가지고 있는지 등의 상태를 말한다고 생각하면 쉽습니다.
문제가 정의되기 위해서는 현재 상태에 대한 측정이 굉장히 중요한데요. 아까 문제(장애)는 목표 상태와 현재 상태의 불일치라고 말씀드렸습니다. 이 문제를 정의하기 위해서는 목표 상태에 대한 결정이 필요합니다. 예를 들면 현재 처리량은 10TPS이고, 목표 처리량은 100TPS라고 가정할 경우, 90TPS 미달되고 있는 것이 문제라고 정의를 내릴 수 있습니다.
하지만 실질적으로 성능 테스트를 거치지 않으면 처리량과 같은 현재 상태의 파악이 어렵고, 레거시 시스템에 대한 성능 분석과 추가되는 여러 사실들을 종합해야만 목표 수립이 가능합니다. 그래서 일반적으로 문제를 정의하는 것은 어려운 일입니다.
지금까지 문제(장애)의 정의에 대해 알아보았는데요. 우리는 이 문제를 해결하는 것이 목표입니다. 문제(장애)를 해결하는 방법을 알기 전에, 문제(장애) 해결이란 무엇인지 그 정의부터 알아보고자 합니다. 문제(장애) 해결이란 장애의 원인, 그 이유를 파악하는 것입니다.
여기에서 많은 분들이 궁금해하시는 부분이 문제(장애) 해결이 성능 분석과는 어떻게 다른지 질문을 주십니다. 성능 분석이란 시스템의 현재 상태와 목표 상태를 정의하는 것입니다. 문제를 정의하기 위해 필요한 조건에 속하는 것이라고 보면 좋을 것 같습니다. 특히 성능 분석의 경우 수치적으로 떨어지지 않는 경우가 있다는 것이 차이점입니다. 시스템이 다운되어(현재 상태) 시스템을 재가동시키는(목표 상태) 것과 같이 행위가 목표가 되는 경우가 있습니다. 성능 분석과 장애 해결은 비슷해 보이지만 분명 다르다는 점, 꼭 알고 가셨으면 좋겠습니다.
장애 해결에는 다양한 활동 유형이 있는데요. 크게 세 가지 단계로 나누어 볼 수 있습니다.
먼저 문제 정의 자체가 어려운 경우입니다. 예를 들면 불안하니까 시스템을 한 번 봐 주세요 라는 의뢰가 이 유형에 해당됩니다. 이럴 경우 어떤 일이 발생한 것도 아니기 때문에 하나하나 문제를 찾고 정의해야 합니다. 하지만 숨어 있는 문제를 찾아내서 정의하기가 쉽지 않습니다.
문제 정의는 했으나, 원인 파악이 어려운 경우다음은 문제 정의까지는 되었으나 원인 파악이 어려운 경우입니다. 예를 들어 갑자기 시스템이 다운되는 상황이 발생했습니다. 하지만 어떤 로그도 남지 않은 상황이라면 어떨까요? 시스템이 다운되었다는 문제 정의는 할 수 있었지만, 어떤 로그도 남지 않았기에 원인 파악은 할 수 없습니다. 이럴 경우에는 모니터링을 설치한 후, 다시 문제가 일어나 해당 원인을 파악할 때까지 기다리는 방법밖에 없습니다.
문제 정의, 원인 파악이 되었지만 원인 제거, 파악된 원인이 맞다는 검증 같은 조치를 취하기 어려운 경우마지막은 문제 정의와 원인 파악까지 다 되었지만 원인을 제거하거나 파악한 원인이 맞다는 검증 조치를 취하기 어려운 경우입니다. 예를 들자면 원인을 제거하기 위해 해당되는 모든 코드를 찾아서 수정해야 하는 시간과 인력이 다수 소모되는 상황이 있을 수 있습니다. 또는 문제가 특정한 때에 발생하는 경우가 있습니다. 이럴 경우 원인 파악과 제거까지 다 진행하더라도 특정 때에만 문제가 발생하니, 제대로 조치가 취해졌는지 검증하기 위해서는 다음 시기까지 기다린 후, 검증을 진행해야 합니다.
다양한 장애 해결 활동의 유형과 어려움까지 같이 확인해보았는데요. 그렇다면 장애를 해결할 때 주의해야 할 점, 여섯 개의 팁을 함께 알아보실까요?
너무 큰 관점에서만 보면 빠르게 문제를 찾아낼 수 없습니다. 1차 원인을 빠르게 식별하고 범위를 좁히는 세분화가 필요합니다. 시스템, 응용, DB 등의 범위를 좁히고 그 안에서 찾는 것이 문제를 더욱 빠르게 파악할 수 있습니다.
탑다운 방식으로 접근하라.1번과 이어지는 팁으로 시스템 전체를 보고 의심을 하면서 영역을 좁히고, 문제를 찾는 것과 같이 탑다운 방식으로 접근해야 합니다. 지역적으로 포인트를 찍고 접근할 경우 오류에 빠질 가능성이 높기 때문에 그 부분을 유의해야 합니다.
진심으로 협력하는 사람들과 같이 진행해라.어떤 일을 진행하던 진심으로 협력하는 사람들과 같이 일하는 것은 매우 중요한 일입니다. 같이 가설을 세우고, 문제를 발견하고 해결하는 과정에서 서로 충분히 의사소통을 하고 같이 진심으로 협력하는 사람들과 진행한다면 더 수월하게 문제를 해결할 수 있을 것입니다.
세운 가설은 이해 당사자들과 공유하라.문제의 원인은 장담할 수 없습니다. 혼자만의 가설로 확신에 차 진행하는 작업 혹은 혼자 생각만 하고 이해 당사자들 몰래 진행하는 작업은 마찰이 생길 수 있기 때문에 항상 가설은 공개하고 공유해야 합니다.
적절한 툴을 이용해라.문제를 찾고 해결하기 위해서는 적절한 툴을 사용하는 것이 중요합니다. 로그를 확하거나 모니터링툴을 이용하여 이상치를 확인하는 것과 같은 적절한 도구를 사용하지 않으면 문제 해결에 시간이 많이 소요됩니다. 문제를 쉽게 해결하려면 도구를 필수적으로 사용해야 합니다.
일정을 장담하지 마라.문제 해결을 장담하여 일정을 약속한 경우, 시간 내에 해결하면 다행이지만 시간이 부족한 경우가 발생하기도 합니다. 시간이 부족하면 조급함에 문제의 원인을 절차적으로 접근하지 않게 되기 쉽습니다. 절차적으로 접근하지 않고 문제의 원인을 대충 감으로 찍게 되는데, 그럴 경우 사람들의 신뢰를 점점 잃는 것은 물론, 실력에 대한 자괴감 또한 느끼는 경우가 발생하게 됩니다.
마지막으로 시스템 장애 해결을 위해 기억해야 할 것들은 무엇이 있을까요?
모든 업무가 그렇지만 문제 해결 또한 사람과 사람이 만나 하는 일입니다. 툴은 그저 도움을 줄 뿐, 해결은 사람이 한다는 본질적인 부분을 잊으면 안 됩니다. 문제를 잘 해결하고 싶다면 사람들과의 협업 또한 잘해야 문제 해결도 잘할 수 있습니다.
우선순위를 잘 선택하는 것이 능력이다.문제 해결을 위한 브레이크 다운을 하다 보면 어쩔 수 없이 가설의 우선순위를 정해야 할 때가 생깁니다. 이럴 때 어떤 방식으로 문제를 브레이크다운 해 갈 것인가 선택을 해야 합니다. 진정한 문제 해결 전문가는 이럴 때 가설의 우선 순위를 정하고, 방식을 정하는 것에 뛰어납니다. 잘 선택하는 것이 능력이 되는 것입니다.
현상, 즉, 문제의 원인이 100% 해석되면 문제는 100% 해결된다.문제의 원인이 100% 파악되면 그 문제는 무조건 해결됩니다. 역으로 말하자면 문제가 100% 해결되지 않았다는 것은 원인이 100% 해석, 파악되지 않은 것입니다. 그렇기 때문에 문제 해결을 위해서는 적절한 사람이, 최선의 인사이트를 가지고, 현상을 100% 해석하려고 노력해야 합니다. 이럴 때 장애의 원인에 접근할 수 있게 됩니다.
좋은 결정은 경험과 사례에 비례한다.2번과 연관된 이야기로 무언가를 결정할 때 경험과 사례가 많은 도움이 됩니다. 따라서 경험이 많은 사람들이 성능 문제 해결에 참여하는 것이 중요합니다. 같은 팀으로 참여하는 것으로 배울 수 있으며, 서로가 가지지 못한 시각과 인사이트로 문제를 해결할 수 있기 때문입니다.
끝없는 팩트 수집을 위해서는 반드시 모니터링을 해야 한다.장애를 해결하기 위해서는 얼마나 광범위하고 디테일하게 팩트를 수집하느냐가 중요합니다. 팩트를 수집하기 위해서는 기본적으로 데이터가 필요하며, 그 데이터를 수집하기 위해서는 모니터링이 꼭 필요합니다.
지금까지 시스템 장애의 정의부터 시작해 해결을 위한 팁까지 알아보셨습니다. 시스템에 장애나 문제가 생겼을 때, 어떻게 해결해야 할지 감이 조금 잡히셨나요? 이 내용을 영상으로 보고 싶다면 아래의 링크를 클릭해 주세요!