System Compleat.

Diagnostics, in computer engineering - DiagnOPs

Techs


(정윤진, younjin.jeong@gmail.com) 

Apple Service Diagnostic, ASD

http://www.macrepaircentral.us/powerbook-g4-15-inch-double-layer-sd-10-2005/apple-service-diagnostic-asd.html

2013년 즈음의 일이다. 아마존 웹 서비스에서 솔루션 아키텍트라는 일을 하고 있었을 때다. 저녁에 갈매기살을 구워서 소맥이랑 먹으면 참 좋은 계절이었던 기억이 아마도 가을이었나 보다. 그런 가을날, 나는 어느 대기업의 미팅룸에서 오후 6시에 잡힌 장애 원인 분석과 관련된 미팅에 앉아있었다. 해당 대기업은 아마존 웹 서비스의 고객이었는데 어떤 모바일 서비스의 업데이트에 일반적인 3계층 구조의 서비스를 운영중이었는데 어느날 부터인가 데이터베이스 부하가 한도를 넘기 시작해서 인스턴스 타입을 가장 높은 것으로 옮긴지 얼마 되지 않는 이력을 가지고 있는 서비스였다. 오후 6시부터 미팅을 시작하는 것도 사실 뭐 썩 기쁜 순간은 아니었지만, 그 미팅 시작으로 부터 약 2시간 동안 벌어진 일은 나름 인생의 얇은 고민중의 하나가 되었다. 

회의에는 약 20여명의 엔지니어들과 두어명의 사업 담당이 있었다. 엔지니어들의 구성은 ELB (로드 밸런서) 전문 팀, EC2 (서버) 전문팀, WAS (Web application server) 전문팀, DBA팀, 애플리케이션을 개발했던 개발팀, 그리고 해당 시점의 상황을 해결하기 위해 투입된 "문제 분석" 팀이 있었다. 각각은 약 3~5 명으로 이루어져 있었으며, 회의의 시작은 문제 분석팀에서 지난 1주일간 수집한 각종 서비스 지표를 공개하고 이를 나머지 팀들과 공유하고 토론하는 형태였다. 

서비스에 발생한 문제는 이런식이었다. 밸런서에서는 내부로 포워딩한 요청에 에러가 지속적으로 발생하는 상태였고 (5xx), 인느 웹 애플리케이션 서버로 부터의 응답 지연으로 인한 것이었으며, 이는 데이터베이스로 부터의 응답에 지연이 발생하는 것이었다. 하지만 데이터베이스 팀에서는 우리의 디비 서버는 CPU 자원이 놀고 있는 상태므로 이건 데이터베이스의 문제가 아니다 라고 하는 내용의 회의가 1시간 반동안 진행되었다. 사실, 아마존 웹 서비스의 솔루션 아키텍트는 어떤 문제에 대해 고객이 스스로 문제를 찾게끔 서비스에 대한 이해를 높이는 방식으로 접근해야 한다. (아니 했었다) 따라서 나에게 질문이 돌아오기 전 까지 나는 침묵을 지킬수 밖에 없었고, 회의 시작 15분 후에 공개된 여러가지 서비스 지표에서 이미 답이 나온 것으로 내심 확정하고 있었던 나는 나머지 1시간 30분이 매우 답답할 수 밖에 없었다. 

결론부터 말하면, 문제는 주기적으로 발생하는 EBS 볼륨의 부하였다. 지금은 그런 문제가 별로 없지만 마그네틱 볼륨이 주를 이루던 때였고, 기억을 더듬어 보면 당시 4000이 최고이던 PIOPS 볼륨에 IO queue length 가 매우 높은 상태였지만 EC2 인스턴스에서는 부하 지표가 관찰되지 않는 그런 류의 성능 문제였다. 따라서 나의 권고는 EBS optimized 인스턴스를 사용할것, 필요하다면 EBS PIOPS 볼륨을 여러개 만들어 데이터베이스에 table space 를 적용할 것 여기에서 더 많은 IO가 필요하다면 EBS 볼륨 몇개를 스트라이핑 하여 table space 로 할당하여 사용하되, 주기적 백업을 절대 소흘히 하지 말 것 이었다. 

http://theevansconsultinggroup.com/2015/05/21/the-dangerous-case-of-the-endless-meeting/

이 회의에서 나는 수많은 팀의 수많은 인원들이, 그리고 해당 클라우드 서비스를 충분히 숙지한 사람들이 왜 그렇게 서로 답이 없는 회의를 길게 하는지 몰랐다. 아니 몰랐다기 보다는 이해할 수 없었다. 서비스의 흐름상 디스크 부하가 발생하면 데이터베이스의 응답이 느려지고 이는 모든 서비스의 이상을 설명할 수 있다. 하지만 각각을 담당하는 팀은 자신의 서비스에 문제가 발생했음을 부인하고 있었고 문제 해결을 위해 투입된 팀은 이 팀들에게 직접적으로 어디가 잘못되었다 하고 이야기 할 수 없는 기술적/정치적 상황에 놓여 있었던 것 같다. 


또 다른 일은 2008년 즈음의 일인것 같다. 당시엔 기본적으로 베오울프의 모델을 따르는 분자식 모델을 만드는 계산 클러스터를 모 업체의 요청에 따라 아파트형 공장에 앵글을 짜 넣어서 만들고 있었다. 이 전에 동일한 업체에서 요구했던 60대 클러스터의 성능을 기록적으로 향상 시켜주었던 전례가 있어 해당 업체의 카이스트 출신 사장님께서는 나를 전폭적으로 믿고 클러스터 구현의 용역을 맡겼다. 당시에 계산에 사용하던 툴은 가우시안과 PC Gamess 라는 툴이었는데, 원래 20초 정도 걸려야할 간단한 H2O 계산이 30분이 지나도 안끝나자 사업 진행에 큰 문제가 발생해 해결을 위해 이업체 저 업체 찾아 다녔지만 누구도 답을 주지 못했다고 했다. 그래서 지푸라기라도 잡는 심정으로 당시 개인적으로 상심하여 장돌뱅이처럼 떠돌던 나와 첫 미팅을 하게 되었고, 미팅 시작 20분여만에 답을 주었다. 

이 베오울프 아님

사장은 믿지 않았고, 내가 말한 방법으로 해결 될 수 있는지 확인하고 싶어 했다. 그러자며 나는 콘솔을 달라고 했고, 그 업체 방문전 일하던 회사에서 동일한 문제로 3주를 삽질하다 얻은 결과를 커널 컴파일 옵션에 적용했다. 멀티 코어가 처음 나오던 시절 즈음이었던 것 같은데, 아무튼 커피 한잔과 담배 한대 태울동안 컴파일은 종료되었고, 재시작 된 PC급 서버에서 계산을 돌려보라고 콘솔을 물려주고 난 5분 후 나는 사장의 동그래진 눈과 함께 이후 40분 동안 그 회사의 사업 설명을 들어야 했다. 음, 계산은 20초 정도가 정상으로 추정 했었지만 5초만에 종료 되었고 그 회사의 물리학 박사님 께서는 내가 무슨 옵션을 조정했는지 받아적고 싶어 했다. 기분 참 좋은 묘한 순간으로 기억난다. 

그런 과거로 인해 사장님은 이번에는 250대 규모로 클러스터를 확장하고 싶어했고, 그걸 나에게 맡겼다. 따라서 나는 간단한 BOINC 기반의 리눅스 클러스터를 만들었는데, 그때 기억나는 것이 하드웨어 였다. 당시 나는 검증이 되고 이미 사용중인 하드웨어를 구매하자고 했었으나, 사장은 이번에 AMD에서 새로 나오는 멀티 코어를 (쿼드 코어 초기 제품이었던 것 같다) 싸게 공급 받을수 있다고 해서 그걸 구매하려고 했다. 대당 단가 15~19만원 선의 무지막지한 가격으로 준비된 250대의 서버 같은 PC 를 구성 완료해서 시험 가동하는 순간, 나는 스스로 멋있다는 생각을 하지 않을 수 없었다. 당시 많지 않던 네트워크 부팅, 비지 박스를 사용한 언제든 업데이트 할 수 있는 자동화 구성, 각각 켜지고 꺼지는 상황을 모니터링 할 수 있고, 샘플로 주어진 H2O 계산을 주어진 큐를 통해 내려 받아 완벽히 끝내는 200여대의 아주 저렴한 기계들. 프로젝트 완료는 약 1.5주 정도 소요되었고, 나머지 0.5주는 검사에 사용했다.  

하지만 문제가 찾아왔다. 15분 이상의 작업을 수행하자, 250대중 몇대가 랜덤하게 전원이 꺼졌다. 정말 문제를 찾아내기 위해 수백번은 클러스터 설정을 변경하고 재시작하는 과정을 거쳤던 것 같다. 하지만 이 문제는 특정 서버에서만 발생하는 것이 아니었다. 또 하지만, 반드시 몇대에서는 발생하는 문제였다. 나중에 표를 그려보니 거의 모든 서버에서 발생했다. 

콘솔은 메인 컨트롤 머신에만 있었으므로 커널 패닉이 나는 순간 리모트 로깅 방법도 없었다. 하여 머신 하나가 꺼질때까지 반복적으로 계산을 돌린 결과, 역시 답을 알 수 없었다. 커널의 스택 트래이스는 얻었지만 원인을 알 길이 없었다. 문제를 사장에게 알리고, 하드웨어 점검이 필요하다고 했다. 대량으로 구매한 하드웨어에서 동시에 발생한 문제였기 때문에, 당시의 나는 소프트웨어 문제인지 하드웨어 문제인지 확신할 수 없었다. 그래서 기존에 문제가 없던 60대 중 20여대를 옮겨와 새로운 클러스터에 붙이고 돌렸지만 그 20대에서는 문제가 없었다. 즉, 동일한 소프트웨어에서 문제가 없고 새로운 하드웨어에서 같은 소프트웨어를 사용했을때 문제가 발생한 것이다. 

그 후로 나는 소프트웨어적으로 결함이 없음을 해당 회사의 엔지니어와 함께 확인하고, 그 동안 발생한 문제의 범인을 프로세서로 압축한 후 메인 보드 제작 업체와 프로세서 관련 업체에 압박을 넣어보자고 사장님께 말했다. 그리고 얼마후에 전화를 받았다. (거의 1주일 정도 간격). AMD에서 사람이 와서 프로세서가 불량임을 확인했고 전량 교체받기로 했다고, 수고 했다고. 역시 IT 세상에서는 초도 물량을 대량 구입하는 게 아니..


또 다른 기억나는 사건은 국내 텔레콤 업체의 퍼블릭 클라우드를 만들때다. 당시 SugarSync 라는 도구로 파일 관련 클라우드 서비스를 제공하고 있었는데, 이를 오픈스택의 스위프트로 바꾸는 작업을 하고 있었다. 홀로 지방의 데이터센터에 내려가 추운 환경에서 자동화 코드를 만들고 돌리고 하는 일을 반복적으로 하고 있었다. 지금이야 아마존 S3가 어떻게 만들어져 있는지 관심이 많지 않지만, 2011년 즈음만 해도 클라우드를 만드는 방법에 대해 사람들이 많은 관심을 가지고 있었을때다. 

구조적으로는 단순하게 특정 도메인에 연결된 다수의 프락시 서버가 있고, 이 프락시 서버에서는 주어진 키를 기반으로 업로드된 파일 (또는 오브젝트)을 내부의 단순 jbod 스토리지를 물고 있는 스토리지 서버에 분산 저장하는 형태로 구동 되었다. 다른 것이야 뭐 오픈스택의 패키지와 문서를 자세히 살펴 보면 알 수 있는 것이지만, 이 때 발생한 문제중의 하나는 바로 네트워크 이슈였다. 지금 생각해 보면 구조적으로 BGP v4 가 일부 가능한 L3 스위치가 기본으로 매달려 있었으므로 스토리지 서버와 프락시 서버간 iBGP 와 ECMP 를 사용한 구성을 사용하면 좋았겠지만, 뭐 기본적으로는 단순 chef 에 dhcp 를 묶어 하드웨어를 준비하는 그런 구성이었다. 당연하지만 상용 리눅스를 사용하는 것이 아니었으므로, OS 및 드라이버에 지원을 받기 보다는 가장 무난한 구성을 선택하는 쪽으로 방향을 잡고 진행중이었다. 

문제는 10Gbit Intel NIC 에서 발생했는데, 고가용성을 위해 bonding 과 함께 묶어서 사용하게 되면 간헐적으로 네트워크가 중단되는 현상이었던것 같다. (정확한 문제는 가물가물) 이때는 네트워크에 발생하는 문제가 명확했기 때문에 특정 버전의 커널과 드라이버를 바꾸는 형태로 진단을 수행했고, 결과 문제가 되지 않는 구성을 발견했다. 이때도 정말 다양한 방법으로 문제를 추적했었는데, ethtool 을 사용한 각종 파라메터 변경, 인텔 드라이버의 최신, 구버전 확인, 하드웨어의 직접 교체, 스위치에 딸린 GBIC 교체, 케이블 교체 등을 포함한다. 문제의 진단과 확인에는 서버와 연결된 네트워크 장치의 로그까지 취합하여 함께 확인했고, 결국엔 원인이 드라이버에 있음을 찾아 전체 반영했다. 이것도 일주일 정도 소요 되었던 것 같다. 

https://regmedia.co.uk/2011/03/28/arista_7050_10ge_switch.jpg

사실은 지난 15년 넘는 시간 동안 이쪽 일을 하면서 겪은 장애와 말도 안되는 해결 방법을 목격한 것은 한두번이 아니다. 2000년대 중반에 어떤 회사에서는 닷넷의 소프트웨어적으로 발생한 문제에 윈도우 서버의 모든 시스템 파일을 엎어치워 버리는 무식한 방법을 목격한 적도 있다. 당연히 문제는 해결되지 않았다. 그리고 이런 문제는 매우 다양한 곳에서 발생한다. 캐시의 효과, 디스크의 효과, 프로세서의 효과, 그리고 네트웍과 이들 위에서 돌아가는 각종 소프트웨어들, 데이터베이스 이런 것들은 언제나 문제를 발생시킨다. 이 블로그에서도 psgql의 장애 추적과 윈도우 시스템 메모리 관련 내용이 있다. 밤잠을 설쳐가면서 찾았던 문제들, 하지만 이제는 세월이 흘러 그 문제 해결의 방법이 그대로 적용되지 않을 수 있는 것들. 

진단이란, 여러가지 충분한 지표를 가지고 어떤 문제나 현상을 정상적으로 만들 수 있는 해결 방법을 내어 놓을 수 있어야 한다. 그리고 이것은 데브옵스의 시대라고 해서, 클라우드의 시대라고 해서 서비스 공급자가 다 해결해 주는 그런 양상의 문제가 아니다. 소프트웨어 내부적으로, 또 예기치 못한 새로운 종류의 하드웨어 문제로 인한 문제들. 거의 대부분의 경우는 일반적으로 알려진 문제 해결 방법 (재부팅이라던가) 이 적용되는 경우도 있지만, 그렇지 않은 경우가 더 많은 것 같다. 이는 매우 중요한 서비스 경험이고, 매우 많은 사전 지식과 경험을 요구한다. 하지만 대부분의 현장에서 문제의 해결은 지표와 데이터에 기반하기 보다는 각 개인의 경험있는 "감"에 의지하곤 한다. 이것은 그 해결이 효과를 보았다고 해도 옳은 방향은 아니라고 생각한다. 해결 방법에는 그에 걸맞는 이유가 있어야 한다. 그 이유를 얻기위한 각종 지표가 충분하지 않다면 실험을 통해서라도 그 지표를 얻는 노력이 필요하다. 그리고 조금 더, 아니 아주 많이 복잡해질 근 미래의 소프트웨어 서비스에서는 이런 일을 전문으로 하는 팀이 있어야 하지 않을까 하는 생각을 해 본다. 

DiagnOPs 라는 조직. 개발, 프로세스, 운영등 각각의 단계에서 발생하는 문제에 대해 실험과 테스트를 통해 적절한 해결 방법을 제안할 수 있는 그룹, 팀이 필요하다는 생각이다. 그리고 이 팀의 전문성은 전체 서비스에 문제가 발생하는 동안, 그 중 일부 또는 테스트 환경에서 문제를 재현하고 합당한 해결 방법을 내어놓고, 또 적용할 수 있는 실행력이 있어야 하는 팀이다. 나중에 누가 물어보면 내가 처음 만든 말이라고 해야지. 

그래서 결국 하고 싶은 말은, 이 바닥에도 Dr. House와 그의 팀이 필요하다는 말. 왜냐 하면, 거의 모든 서비스 담당자와 운영자와 개발자는 문제 발생시 거짓말을 하니까. - "우린 아무 문제가 없어요" 


생각나는대로 쓰다 보니 뭐 그냥 그렇지만, 어쨌든 이런 역할이 필요하다는 거. 진단, 분석, 올바른 해결 방법. 그리고 적용 권한. 이것들은 서비스에 대한 사전 및 사후 테스트를 통해 겹겹이 쌓인 해당 서비스에 대한 전문성이 뒷받침 될때 가능하지 않을까 생각해 본다. 

(정윤진, younjin.jeong@gmail.com) 

저작자 표시 비영리
신고

티스토리 툴바