2011.03.08

[IDG 블로그] 시스템 관리의 퇴보와 추락

Paul Venezia | InfoWorld

지난 주, 문제가 생겼을 때 원인을 파악하기 전에 무조건 유닉스 서버를 재부팅하는 것이 왜 좋지 않다는 포스팅을 올렸다. 이는 필자가 20년간 유닉스 및 리눅스 서버와 씨름을 한 끝에 얻어낸 결론이었다. 악의 없이 쓴 글이었는데, 결과적으로는 벌집을 건드린 격이 되었다.

 

무수히 쏟아지는 쓰레드와 이메일을 통해 받아 본 피드백들은 유닉스 관리자들이 눈 뜨자마자 하는 일이 서버를 재부팅하는 일이라고 생각하는 듯 했다. 물론 내 말을 이해한 사람들로부터는 응원의 메시지가 오기도 했다. 하지만 많은 사람들이 아직도 재부팅이 최선의, 그리고 가장 많이 사용되는 방법이라 생각하는 듯 했다(일부 가동시간 수치에 대한 언급에 대해서는 전혀 관계없는 문제이기 때문에 대답할 가치도 느끼지 못했다).

 

필자로서는 이해가 되지 않는다. 시스템 관리에 도대체 무슨 문제가 있는 것인가?

 

받아본 답변 중에는 가상화가 도래한 이후로 어떤 것을 바꾸려 할 필요가 없어졌다는, 좀 더 귀 기울일 만한 의견도 있었다. 문제가 생기면 오리지널 템플릿을 재사용하고 옛날 가상머신은 쓰레기통에 던져버리면 된다는 것이다. 좋다. 완전히 멈추는 것. 노트북이나 데스크톱은 분명 서버와는 다르고, 서버라고 해도 그런 식으로 사용해선 안된다. 하지만 문제는 이것이 전부가 아니다.

 

필자는 요즈음 최신 서버 가상화 기술이 실제 서버 관리 기술을 퇴보시키는 데 일조하고 있다는 생각이 든다. 물론, 템플릿을 재사용하는 데에는 10분이면 된다. 하지만 이는 인프라의 다른 곳에서 데이터를 받아 서버 팜에서 사용하는 무상태(Stateless) 서버일 경우에만 가능한 해결책이다. 약간의 문제만 발생했는데 무조건 데이터베이스 서버를 재사용할 사람은 없지 않은가? 물론 그런 일이 가능한 구조를 만들 수도 있지만, 수십 수백 개의 데이터베이스 서버가 존재하는 거대 인프라가 아닌 이상 그게 무슨 의미가 있을까?

 

답이 없는 윈도우 관리에 대해 흔히 이런(대부분의 경우 부당하다 할 수 있는) 농담을 한다. 고칠 수 있는 능력이 한정돼 있기 때문에 그 능력을 다 써버리고 나면 조금씩 고쳐나간다는 것이다. 유닉스의 경우 그런 개념이 처음부터 비웃음을 사 왔지만, 리눅스가 주류에 편승하고 리눅스 관리자의 수가 늘어감에 따라 그런 생각도 합리적인 것으로 받아들여지게 됐다.

 

최악인 것은 이런 생각들이 단순히 올바른 재부팅 에티켓에 한정되는 것이 아니란 것이다. 많은 IT 부서에서 유닉스를 잘못 사용하고 있는 것을 볼 수 있다. 필자가 보기에 이런 상황은 매우 불안정하며, 특히 유닉스 관리의 주요 원칙들이 운영체제의 올바른 관리를 목적으로 설계되었다는 점에서 더더욱 그러하다.

 

가장 간단하게는 파일 시스템 구조를 꼽을 수 있다. 설정 정보(configuration info)는 /etc에, 로그(logs)는 /var에, 로컬 파일(local file)은 /usr/local에, 라이브러리는 /lib과 /usr/lib에 놓는 것 등등이 그렇다. 물론, 잡다한 것들을 디스크 여기저기에 널어놓을 수는 있지만, 제대로 분류해 놓으면 더욱 간편하고 깔끔해진다.

 

하지만 (분명히 자신이 무엇을 하고 있는지 아는 누군가가 만들어 놓은)복제 서버 인스턴스를 띄우기 위해 v스피어의 윈도우 기반 클라이언트에 클릭 몇 번만 하면 된다면, 뭐가 문제라고 생각하는가? 편리하고 간단한데 말이다.

 

그렇지 않다. 그 토대를 이해하지 못하면 전체적 내용도 오해할 수밖에 없다. 누구나 운전을 할 수는 있지만, 시동이 걸리지 않는다면 어찌할 도리가 없다. 만약 돈을 받고 자동차를 고쳐줘야 하는 입장이라면, 이런 상황은 참 난감하지 않을까?  editor@idg.co.kr



2011.03.08

[IDG 블로그] 시스템 관리의 퇴보와 추락

Paul Venezia | InfoWorld

지난 주, 문제가 생겼을 때 원인을 파악하기 전에 무조건 유닉스 서버를 재부팅하는 것이 왜 좋지 않다는 포스팅을 올렸다. 이는 필자가 20년간 유닉스 및 리눅스 서버와 씨름을 한 끝에 얻어낸 결론이었다. 악의 없이 쓴 글이었는데, 결과적으로는 벌집을 건드린 격이 되었다.

 

무수히 쏟아지는 쓰레드와 이메일을 통해 받아 본 피드백들은 유닉스 관리자들이 눈 뜨자마자 하는 일이 서버를 재부팅하는 일이라고 생각하는 듯 했다. 물론 내 말을 이해한 사람들로부터는 응원의 메시지가 오기도 했다. 하지만 많은 사람들이 아직도 재부팅이 최선의, 그리고 가장 많이 사용되는 방법이라 생각하는 듯 했다(일부 가동시간 수치에 대한 언급에 대해서는 전혀 관계없는 문제이기 때문에 대답할 가치도 느끼지 못했다).

 

필자로서는 이해가 되지 않는다. 시스템 관리에 도대체 무슨 문제가 있는 것인가?

 

받아본 답변 중에는 가상화가 도래한 이후로 어떤 것을 바꾸려 할 필요가 없어졌다는, 좀 더 귀 기울일 만한 의견도 있었다. 문제가 생기면 오리지널 템플릿을 재사용하고 옛날 가상머신은 쓰레기통에 던져버리면 된다는 것이다. 좋다. 완전히 멈추는 것. 노트북이나 데스크톱은 분명 서버와는 다르고, 서버라고 해도 그런 식으로 사용해선 안된다. 하지만 문제는 이것이 전부가 아니다.

 

필자는 요즈음 최신 서버 가상화 기술이 실제 서버 관리 기술을 퇴보시키는 데 일조하고 있다는 생각이 든다. 물론, 템플릿을 재사용하는 데에는 10분이면 된다. 하지만 이는 인프라의 다른 곳에서 데이터를 받아 서버 팜에서 사용하는 무상태(Stateless) 서버일 경우에만 가능한 해결책이다. 약간의 문제만 발생했는데 무조건 데이터베이스 서버를 재사용할 사람은 없지 않은가? 물론 그런 일이 가능한 구조를 만들 수도 있지만, 수십 수백 개의 데이터베이스 서버가 존재하는 거대 인프라가 아닌 이상 그게 무슨 의미가 있을까?

 

답이 없는 윈도우 관리에 대해 흔히 이런(대부분의 경우 부당하다 할 수 있는) 농담을 한다. 고칠 수 있는 능력이 한정돼 있기 때문에 그 능력을 다 써버리고 나면 조금씩 고쳐나간다는 것이다. 유닉스의 경우 그런 개념이 처음부터 비웃음을 사 왔지만, 리눅스가 주류에 편승하고 리눅스 관리자의 수가 늘어감에 따라 그런 생각도 합리적인 것으로 받아들여지게 됐다.

 

최악인 것은 이런 생각들이 단순히 올바른 재부팅 에티켓에 한정되는 것이 아니란 것이다. 많은 IT 부서에서 유닉스를 잘못 사용하고 있는 것을 볼 수 있다. 필자가 보기에 이런 상황은 매우 불안정하며, 특히 유닉스 관리의 주요 원칙들이 운영체제의 올바른 관리를 목적으로 설계되었다는 점에서 더더욱 그러하다.

 

가장 간단하게는 파일 시스템 구조를 꼽을 수 있다. 설정 정보(configuration info)는 /etc에, 로그(logs)는 /var에, 로컬 파일(local file)은 /usr/local에, 라이브러리는 /lib과 /usr/lib에 놓는 것 등등이 그렇다. 물론, 잡다한 것들을 디스크 여기저기에 널어놓을 수는 있지만, 제대로 분류해 놓으면 더욱 간편하고 깔끔해진다.

 

하지만 (분명히 자신이 무엇을 하고 있는지 아는 누군가가 만들어 놓은)복제 서버 인스턴스를 띄우기 위해 v스피어의 윈도우 기반 클라이언트에 클릭 몇 번만 하면 된다면, 뭐가 문제라고 생각하는가? 편리하고 간단한데 말이다.

 

그렇지 않다. 그 토대를 이해하지 못하면 전체적 내용도 오해할 수밖에 없다. 누구나 운전을 할 수는 있지만, 시동이 걸리지 않는다면 어찌할 도리가 없다. 만약 돈을 받고 자동차를 고쳐줘야 하는 입장이라면, 이런 상황은 참 난감하지 않을까?  editor@idg.co.kr



X