장애의 원인 분석과 해결의 노우하우. 해결이 먼저인가, 원인분석이 먼저인가..

영상 버전 : https://youtu.be/mzjpuLg4ru4

제 영상을 보면 어떤 큰 장애가 터져도 재섭게 엄청 잘 해결하고 있죠?

하지만 경험이 적었던 시절에는 해결 못한게 더 많았구요, 거의 죽일듯이 절 바라보는 사람들도 있었지요..

시작하기 전에,

일본에서는 장애 라는 표현을 쓰지 않고 장해 라는 표현을 씁니다.

"장애"는 개인이 일상생활에서 특정 기능이나 능력에서 일시적 또는 지속적으로 어려움을 겪는 상태를 가리킵니다. 반면에 "장해"는 기능이나 능력의 손상 또는 손실을 나타내며, 이로 인해 일상생활에 제한이 생길 수 있습니다. 따라서, 장애는 어려움이 발생한 상태를 나타내고, 장해는 그 어려움의 원인인 손상 또는 손실을 의미합니다.

시스템에서의 관점에서, "장애"는 주로 소프트웨어나 하드웨어에서 발생하는 기능적인 문제를 가리킵니다. 반면에 "장해"는 전반적인 시스템의 성능에 영향을 미치는 더 큰 범위의 문제나 결함을 나타낼 수 있습니다. 따라서, 장애는 특정 기능의 동작에 문제가 있을 때 사용되고, 장해는 시스템 전체적인 문제를 나타내는 데 사용될 수 있습니다.

뭐, 이건 chatgpt가 해준 대답일 뿐 제가 찾아본 사전들에선 혼용의 여지가 있습니다.

단지 한국에서의 경험에서는 거의 장애라는 표현으로 통일 되어 내가 장해라고 쓰면 이상하게 쳐다보는 경향이 있지만, 일본은 障害(장해) 라는 표현만 씁니다. 이는 장애인을 뜻하는 장애라는 단어는 사용하기 민감해서 라고 하네요..

제가 너무 단어의 의미에 고집하는 경향이 있는데, 그건 프로젝트에 참여하는 사람들이 많을 수록 애매한 표현이 최종적으로 전혀 다른 결과를 일으킨 경험이 많기 때문에 프로젝트마다 사전을 만들고 인식을 통일시키다 보니 직업병 같은 거리 보시면 됩니다.

고객이 “고급스러운 색감” 이라고 하면 결과물은 빨강이 나올지 녹색이 나올지, 금색이 나올 지 모릅니다.

때문에 고객마다 고객이 원하는 “고급스러운”을 명확히 정의 해야 결과물이 고객의 상상과 달라지지 않게 되겠지요.

너무 샜는데요…

장애가 터지면 

그나마 제일 잘 아는 제게 의지하면서 

그 믿음을 져버리지 않게 하기 위해 엄청나게 노력을 했지만 ,

 결국 해결을 못한 건에 대해서는 그 상실감이 엄청 났답니다.

스트레스 그 자체였고, 

이걸 해결 못하면 손해배상을 청구 하는거 아냐? 하는 불안함과, 상사의 엄청난 강압..

그리고 해결되기까지는 쉬거나 웃는것 조차 용서받지 못하는 분위기 였죠.

장애는 아니지만

저의 첫 좌절은 2002년경 대형 패스트푸드의 공식 웹사이트 구축시 였지요..

그 때 당시 6천만원은 아주 큰 금액이었으나, 다자인을 60번 퇴짜맞고 나니 저 돈이 다 날라갔습니다.

많은 외주 디자이너를 찾아서 정말 다양한 컨셉으로 제안 하였으나 

하나같이 좀 부족해 

라며 리젝 당했을 때는 계약이고 머고 다 내치고 드롭하고 싶었죠.. 

고민끝에 제가 직접 고안한 로고를 화면 가득차게 표시하고 

각 로고의 면에 콘텐츠를 표시하는 플래시 애니메이션으로 

겨우 승인 받았지만 이미 자금은 바닥난 상태였죠. 

추가로 인력을 쓰지 못하고 누님이 디자인을 맡고 

6개월을 두 명이서 거의 철야를 반복하여 만들어 오픈을 해주었습니다. 

하지만 유지보수라는 명목으로 신기능 추가를 강요 받았고, 

이미 자금이 바닥난채 공짜로 몇 달을 더 해주면서 

없는 돈을 구하러 다니던 어느날 모든게 싫어졌습니다.

하루아침의 일입니다. 

전날까지 아무렇지도 않게 열심히 노력하던 제가 있었지요..

그런데 그 날은 아무 연락도 받지 않고 침대에서 나오지 않았죠. 

언제나 긍정적이며 힘들어도 아침형 인간을 유지하며 운동도 게을리 하지 않았던 제게

처음으로 이대로 죽는게 낫다는 생각이 들게 되었던 계기 입니다.

자살하는 사람들의 심정을 알겠더라구요..

3개월 정도를 집의 차고 안쪽에 짐을 쌓아놓던 방애서 누워서 온라인 게임만 하고 폐인 생활을 했죠.

그래도 주변에서 몰아붙이는 사람이 없고 끄집어 내려 하는 

사람이 없어서 오히려 점점 게임속의 활발한 캐릭터가 이입된 거 같습니다. 

참고로 정신적으로 피폐한 상대를 도와준답시고 

억지로 밖으로 끌어내면 오히려 극단적인 선택을 하는것 같습니다. 

사람마다 성향과 피해 정도가 다르니 정설은 없지만, 

상처입은 고양이가 스스로 밥을 먹으러 나올 수 있게 

지켜봐 주는게 좋은 것 같습니다.

전 원래 제가 손해 보더라도 누군가를 돕는걸 좋아하고 

누군가에게 감사하다는 한마디에 치유되는 성격 같아요. 

아마도 남을 속이고 렙업과 공성전에 목숨거는 게임 환경이었지만

누군가를 도와주는 제 성격 때문에 도움받은 사람들의 

감사의 한 마디가 모여서 치유가 된 게 아닐까 하네요.

거기서 일어나 

많은 기업을 전전했고, 장애가 생기면 담당자가 있더라도 

스스로 나서서 장애 원인 분석 및 해결을 도왔지요.. 

그러다보니 어느새 장애 처리는 제가 리드하게 되었고,

장애의 원인 규명과, 일시 해결, 그리고 영구 해결에 대한 구분 및 제안을 잘하게 되었습니다.

장애가 생기면 해결을 해야하잖아요..

하지만 장애가 다시 생길 수 있으니 장애 상황에서 분석도 필요합니다.

많은 곳에서 둘 다 요구를 합니다.

즉 빠른 분리 및 정상화, 

그리고 분리된 인스턴스의 분석으로 가야 합니다.

그럼 어떻게 하는게 좋을까요?

이 때부터 전 MSA구조에 신경을 집중 했지요.

왜 MSA일까요? MSA는 개발에서 고민 해야 하는게 아닌가요?

MSA는 마이크로 서비스 아키텍쳐라고 하여 개발 쪽에서 마이크로 서비스로 만들지 않으면 안된다고 생각 하시는 분들이 많죠.

대규모 개발을 하는 경우에도 처음 개발 환경은 최소로 만들게 됩니다.

웹 서버와 api서버, db 서버를 보통 한 대에 넣고 개발하잖아요?

이 때부터 동일 환경을 세 개  만듭니다.

그리고 1,2 번 서버의 웹서버 프로세스 앞에 application gateway를 넣고 분산도 해보고

다시 2, 3번 서버의 api앞에 application gateway를 넣고 도메인으로 알려주고 개발을 시키는 거죠.

DB는 replication을 해서 1번만 master로 하고 2,3을 read replica로 쓰게 합니다.

그러면 이미 MSA는 준비가 된 겁니다.

서비스의 예상 사이즈를 보고 5대로 서비스 런칭을 하려고 합니다.

개발 서버 이미지를 5대 복제하고 db만 레플리카설정하면 끝.

나머진 5대 모두 application gateway 에 물렸다가 부하 정도에 따라 연결을 끊어주던가 

추가로 vm image를 열고 추가 하면 됩니다.

만약 serverless라면 그에 맞추면 되는거죠.

MSA는 serverless의 경우가 더 귀찮은거 아시나요?

그걸 위해서 cloud formation이나 terraform같은게 인기가 있지만,

생각보다 경직되어 일부만 새로 올리고 교체하는등의 대응에는 

좋지 않아서 구축 초기에는 도입하지만 

운영중에는 오히려 수동이 많아지지요.

특히나 장애 포인트에 따라 못쓸 때가 많습니다.

그럼 쿠버네티스는 어떠냐구요?

매번 소스 업데이트 할 때마다 쿠버 이미지를 잘 먼드는 꼼꼼한 리더가 있다면

가능하갰지만,

현실은 어떠신가요?

최소한 제 주변애서 쿠버로 시작하신 서비스는 봤으나 장애시 쿠버로 대응하신 분들은 못봤네요.

단순VM의 경우 장애가 생기면 

장애가 생긴 노드만 분리합니다. 그리고 추가 인스턴스를 올려서 붙이면 장애 해결 끝.

그리고 분리된 인스턴스에 테스트용 application gateway를 올리고 로그를 분석하면 되지요.

예전에는 이런 환경을 쉅게 만들 수 없어서 미리 예비기를 준비했으나 클라우드는 참 편하네요.

만약DB의 롤백이 필요하거나 한 경우는 미리 롤백 가능한 환경을 준비할 필요가 있지만, 

그런 세세한 거는 여기서 거론하면 끝도 없으니 모두 아시리라 생각하고 넘어갈께요.

물론 vm단위가 무조건 좋다는 것은 아닙니다.

단지 손에 익어서 잘 쓰는거 뿐이죠.

장애시에는 얼마나 상황을 그대로 보존하고 빨리 복구하느냐가 중요합니다.

소스 찾고 있으면 안되는것이죠.

언제든 복구 연습을 해서 손에 악혀두지 않으면 안됩니다.

그리고 모든 단계를 쪼개서 스크립트화를 해서 

필요한 타이밍에 단위별로 실행할 수 있어야 합니다.

Aws나 azure모두 cli가 있고 스크립팅이 가능합니다.

클라우드 이전에는 pxe로 물리서버의 전원을 넣고 ipmi2.0으로 os이미지를 내려서 복구하는 스크립트를 만들어서 썼거든요.

퍼블릭 클라우드 벤더라면 당연히 알고 있는 기술입니다.

수만대에 달하는 물리서버의 장애에 누가 서버들고 달려가서 교체하고 모니터 꽂고 작업하나요?

음… 의외로 수동으로 하시는 분들도 계실지도….

아뭏든 장애 대응 속도는 연습량에 비례합니다.

OS와 하드웨어의 구조를 알고 스크립팅을 해야죠..

Jenkins따위에 의존하면 언됩니다.

Jenkins같은건 스스로 만들 정도는 되어야죠.

인프라 업무가 단순하고 언제나 사간이 없다고 생각하시는 분들은

인프라를 아직 모르시는 거랍니다.

giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/