Rules and Scalability
Techs( younjin.jeong@gmail.com, 정윤진 )
한동안 바쁘기가 그지 없었다. 스토리지 클라우드 인프라의 아키텍팅, 자동화 코드 작성, 그리고 새로 시작한 고객사에서의 생활 등, 삶의 또 다른 한 사이클이 왔나 싶을 정도의 격한 생활을 지낸지 얼추 두어달 정도 되는 듯 하다.
이렇게 살면서 가장 힘든일이 무엇인가 생각해 보면, 각 기업에서 기존에 수행하던 방식의 모든 인프라 구성 방법과 다른 것이 바로 클라우드이다 하는 사실을 조직에 받아 들이게 하는 것이 가장 힘든 일이 아닌가 생각해 본다. 아주 간단한 호스트 이름을 짓는 방법 부터, IP 할당 계획을 수립하는 것, 그에 따른 네트워크 구조를 만들어 내는 것 모두가 클라우드의 방식을 따르자면 모두 함께 Scale-out 을 고려 해야 하는데, 여기에 기존에 수십대의 서버를 사용하는 환경에서 사용하던 룰을 적용 하려는 경우가 많아 어려움을 겪는 경우가 많다.
이는 비단 한 두명의 관리자 때문만은 아니며, 클라우드 솔루션을 만들어 납품해야 하는 대상, 즉 또 다른 고객이 이 새로운 환경에 대해 준비가 되어있지 않기 때문에, 인프라 구성에 있어 기존의 패턴을 요구하기 때문에 발생하는 연쇄적이고 뿌리가 깊은 사이클에 기인하는 것으로 보여진다. 이 기존의 패턴이라는 것은 바로 고사양의 하드웨어에 치밀한 이중화를 준비 해 두어야만 데이터센터에 수용이 가능하다 라는 요구조건과 비슷한 것이 된다.
하지만 클라우드는 이러한 기존의 패턴으로는 비용 효율성 측면에서 난관에 봉착하게 될 것임을 인지해야 한다. 한가지 더, 고비용의 시스템을 준비한다고 해서 획기적으로 좋은 성능을 만들어 낼 수는 없다. 클라우는 원래 생겨먹은게 가능한 "많은" 자원을 가지고 문제를 해결해야 한다. 그런데 이러한 것들은 모두 기존의 관리 패턴과 충돌하는 것이기 때문에 도입이 쉽지 않아진다. 대규모 클라우드를 처음부터 대규모로 만들 수 있는 것은 거대한 자본을 가진 기업만이 가능하다. 하지만 아무리 거대한 자본을 가진 기업일지라도 현재 시장의 표준이 되고 있는 아마존 클라우드보다 비용이 높아지게 되면 서비스의 중요성이 아무리 높다 한들 사업부의 동의를 구하기 힘들어지게 된다. 기존의 패턴에 의존할 확율이 높은 거대 기업이 자본을 믿고 고사양의 시스템으로 클라우드를 구축했다가 어이쿠 하고 빠지는 경우를 종종 보게 된다. 개인적으로 보기엔 이러한 이유들이 가장 크게 작용하고 있기 때문이라 생각되며, 따라서 클라우드 환경에 맞는 올바른 인식을 가지고, 그 그림을 공유하는 것이 성공적인 서비스 구성으로 가는 지름길이 아닐까 생각 해 본다.
예를 들어 컴퓨팅 클라우드의 컴퓨트 노드, 즉 하이퍼바이저 노드의 경우, 이는 엄청난 숫자로 서버가 확장될 가능성이 있으며, 따라서 기존에는 아무것도 아닌 것 같은 NTP, DNS, DHCP, TFTP, 각종 서비스 설치에 필요한 Mirror Site 등의 자원에 대한 내부 구성이 중요해 진다. 더군다나 여기에 관리용 도메인/호스트 네임의 할당과 이와 관련된 IP 적용 규칙등을 모두 복합적으로 함께 고려하고, 이를 클라우드 제반 시스템 내부로 수용해야만 한다. 따라서 컴퓨트 클라우드는 단순히 하이퍼바이저의 집합이 아니라, 빌링과 자동화된 배포, 로깅, 모니터링 등을 처리해야만 하는 잘 조직된 관리용 서버 팜과, 이 컴퓨트 클라우드에서 사용될 이미지등이 저장될 스토리지 클라우드, 그리고 컴퓨트 클라우드 자체의 구성, 이 세가지가 모든 측면에서 고려되어야 한다.
위에 열거된 대부분의 내용은 바로 올바른 규칙의 설정에 그 핵심이 있다. 네트워크는 수평적으로 확장이 가능해야 하고, 기하 급수적으로 증가하는 서버를 일정한 규칙을 통해 배포하는 것이 중요하다. 여기에 필요한 규칙을 만드는 것, 그것이 바로 클라우드를 만드는 첫걸음이 아닌가 생각해 본다.
호스트명을 예로 들어 보자. 별도의 매핑 시스템이 존재하는 경우가 아니라면 클라우드에서는 호스트명 그 자체로 이 서버가 지역적으로, 그리고 물리적으로 데이터센터 내에서 어디에 위치하는지 즉각적으로 식별이 가능하도록 작성할 필요가 있다. 이는 서브도메인을 사용하는 방법과 호스트명에 직접 표기하는 두가지 방법이 있을 수 있는데, 이는 다음과 같다.
* 서울 데이터 센터의 3층에 위치한 랙 40번의 아래에서 5번째 위치한 서버. 도메인은 a.com 이라 하자.
예1) seoul-f3-r40-05.a.com
예2) f3-r40-05.seoul.a.com
* 위 예의 fqdn 을 가지고 서버의 IP 를 즉각적으로 유추해 내도록 망을 설계 할 수도 있다.
서울 : 10.
3층 : 10.3
랙 : 10.3.40
순서: 10.3.40.5
이는 극단적으로 단순한 예이다. 데이터 센터는 1개 층밖에 사용하지 못하는데 층을 기반으로 IP 할당 계획을 세운다면 IP가 모자르게 될 가능성도 있다. 따라서 가장 많이 증가 할 수 있는 자원을 기반으로 적절하게 서브네팅과 IP 계획을 세워 줄 필요가 있다. 이는 일견 간단해 보이지만, 직접 해 보면 쉽지 않은 일임을 알 수 있다. 하지만 이러한 예가 의미하는 바는 바로 약속이다. 이 약속의 내용을 알고 있다면 가급적 최대한 쉽게 식별이 가능하도록 만드는 것이 매우 중요하다는 말이다.
사실 이러한 내용은 그저 많은 약속 중의 단 하나일 뿐이다. 이러한 제한 조차 감당하기 어려운 경우에는, 별도의 호스트명 - IP 의 맵핑 로직을 만들어야 한다. 따라서 몇몇 대규모 클라우드 호스팅 업체의 경우 호스트명으로 아예 MAC 을 사용하는 경우도 있다.
랙 한두개로 클라우드를 모방하는 것은 기술적인 측면에서나 서비스적인 측면 모두에서 사실 별 일은 아니다. 이는 그저 시작일 뿐이며, 자그마한 유닛을 가지고 PoC 정도를 수행하는 것에 지나지 않는다. 물론 이러한 작업조차 하지 않는 경우가 대부분이긴 하지만, 수백, 수천대, 또 지역적으로 글로벌하게 서비스해야 하는 클라우드를 설계하는 경우라면 이러한 작은 차이들이 보다 수월한 자동화와 관리 시스템을 만들어 낼 가능성이 높다.
가장 중요한 것은, 이것은 기존의 방식과는 다르다 라는 것을 인지하는 것이 아닐까 한다. 하드웨어의 선정과 네트워크 구성은 절대 기존의 방식을 따라서는 안되며, 나아가 확장을 기본적으로 염두해 두지 않는다면 비용/관리/운영 모든 측면에서 눈덩이처럼 불어나는 이슈들을 감내하기가 분명 쉽지 않을 것이다.
Flat 네트워크나 Open vSwitch 와 같은 기술적인 내용의 수용에 앞서, 이러한 기본적인 내용을 이해하는 것이 무엇보다 중요하지 않을까 한다. 물론, 내가 지향하는 방법과 다른 방법이 분명 있을 수 있고, 그 방법이 보다 효율적이라면 따르지 않을 이유가 없지만 이러한 구성들은 한번 고려해 봄직 하지 않나 싶다.
졸립고 피곤한데 뭔가 한마디 쓰고 싶어 끄적인게 또 두서없이 길어져 버렸다. 쓰다보니 이런 글이 과연 도움이 될까 싶은 의문이 드는 밤이다.
( younjin.jeong@gmail.com, 정윤진 )
한동안 바쁘기가 그지 없었다. 스토리지 클라우드 인프라의 아키텍팅, 자동화 코드 작성, 그리고 새로 시작한 고객사에서의 생활 등, 삶의 또 다른 한 사이클이 왔나 싶을 정도의 격한 생활을 지낸지 얼추 두어달 정도 되는 듯 하다.
이렇게 살면서 가장 힘든일이 무엇인가 생각해 보면, 각 기업에서 기존에 수행하던 방식의 모든 인프라 구성 방법과 다른 것이 바로 클라우드이다 하는 사실을 조직에 받아 들이게 하는 것이 가장 힘든 일이 아닌가 생각해 본다. 아주 간단한 호스트 이름을 짓는 방법 부터, IP 할당 계획을 수립하는 것, 그에 따른 네트워크 구조를 만들어 내는 것 모두가 클라우드의 방식을 따르자면 모두 함께 Scale-out 을 고려 해야 하는데, 여기에 기존에 수십대의 서버를 사용하는 환경에서 사용하던 룰을 적용 하려는 경우가 많아 어려움을 겪는 경우가 많다.
Lighter Side of Cloud 이미지는 내용과 관계 없음
Image From : http://www.cloudtweaks.com
이는 비단 한 두명의 관리자 때문만은 아니며, 클라우드 솔루션을 만들어 납품해야 하는 대상, 즉 또 다른 고객이 이 새로운 환경에 대해 준비가 되어있지 않기 때문에, 인프라 구성에 있어 기존의 패턴을 요구하기 때문에 발생하는 연쇄적이고 뿌리가 깊은 사이클에 기인하는 것으로 보여진다. 이 기존의 패턴이라는 것은 바로 고사양의 하드웨어에 치밀한 이중화를 준비 해 두어야만 데이터센터에 수용이 가능하다 라는 요구조건과 비슷한 것이 된다.
하지만 클라우드는 이러한 기존의 패턴으로는 비용 효율성 측면에서 난관에 봉착하게 될 것임을 인지해야 한다. 한가지 더, 고비용의 시스템을 준비한다고 해서 획기적으로 좋은 성능을 만들어 낼 수는 없다. 클라우는 원래 생겨먹은게 가능한 "많은" 자원을 가지고 문제를 해결해야 한다. 그런데 이러한 것들은 모두 기존의 관리 패턴과 충돌하는 것이기 때문에 도입이 쉽지 않아진다. 대규모 클라우드를 처음부터 대규모로 만들 수 있는 것은 거대한 자본을 가진 기업만이 가능하다. 하지만 아무리 거대한 자본을 가진 기업일지라도 현재 시장의 표준이 되고 있는 아마존 클라우드보다 비용이 높아지게 되면 서비스의 중요성이 아무리 높다 한들 사업부의 동의를 구하기 힘들어지게 된다. 기존의 패턴에 의존할 확율이 높은 거대 기업이 자본을 믿고 고사양의 시스템으로 클라우드를 구축했다가 어이쿠 하고 빠지는 경우를 종종 보게 된다. 개인적으로 보기엔 이러한 이유들이 가장 크게 작용하고 있기 때문이라 생각되며, 따라서 클라우드 환경에 맞는 올바른 인식을 가지고, 그 그림을 공유하는 것이 성공적인 서비스 구성으로 가는 지름길이 아닐까 생각 해 본다.
예를 들어 컴퓨팅 클라우드의 컴퓨트 노드, 즉 하이퍼바이저 노드의 경우, 이는 엄청난 숫자로 서버가 확장될 가능성이 있으며, 따라서 기존에는 아무것도 아닌 것 같은 NTP, DNS, DHCP, TFTP, 각종 서비스 설치에 필요한 Mirror Site 등의 자원에 대한 내부 구성이 중요해 진다. 더군다나 여기에 관리용 도메인/호스트 네임의 할당과 이와 관련된 IP 적용 규칙등을 모두 복합적으로 함께 고려하고, 이를 클라우드 제반 시스템 내부로 수용해야만 한다. 따라서 컴퓨트 클라우드는 단순히 하이퍼바이저의 집합이 아니라, 빌링과 자동화된 배포, 로깅, 모니터링 등을 처리해야만 하는 잘 조직된 관리용 서버 팜과, 이 컴퓨트 클라우드에서 사용될 이미지등이 저장될 스토리지 클라우드, 그리고 컴퓨트 클라우드 자체의 구성, 이 세가지가 모든 측면에서 고려되어야 한다.
위에 열거된 대부분의 내용은 바로 올바른 규칙의 설정에 그 핵심이 있다. 네트워크는 수평적으로 확장이 가능해야 하고, 기하 급수적으로 증가하는 서버를 일정한 규칙을 통해 배포하는 것이 중요하다. 여기에 필요한 규칙을 만드는 것, 그것이 바로 클라우드를 만드는 첫걸음이 아닌가 생각해 본다.
호스트명을 예로 들어 보자. 별도의 매핑 시스템이 존재하는 경우가 아니라면 클라우드에서는 호스트명 그 자체로 이 서버가 지역적으로, 그리고 물리적으로 데이터센터 내에서 어디에 위치하는지 즉각적으로 식별이 가능하도록 작성할 필요가 있다. 이는 서브도메인을 사용하는 방법과 호스트명에 직접 표기하는 두가지 방법이 있을 수 있는데, 이는 다음과 같다.
* 서울 데이터 센터의 3층에 위치한 랙 40번의 아래에서 5번째 위치한 서버. 도메인은 a.com 이라 하자.
예1) seoul-f3-r40-05.a.com
예2) f3-r40-05.seoul.a.com
* 위 예의 fqdn 을 가지고 서버의 IP 를 즉각적으로 유추해 내도록 망을 설계 할 수도 있다.
서울 : 10.
3층 : 10.3
랙 : 10.3.40
순서: 10.3.40.5
이는 극단적으로 단순한 예이다. 데이터 센터는 1개 층밖에 사용하지 못하는데 층을 기반으로 IP 할당 계획을 세운다면 IP가 모자르게 될 가능성도 있다. 따라서 가장 많이 증가 할 수 있는 자원을 기반으로 적절하게 서브네팅과 IP 계획을 세워 줄 필요가 있다. 이는 일견 간단해 보이지만, 직접 해 보면 쉽지 않은 일임을 알 수 있다. 하지만 이러한 예가 의미하는 바는 바로 약속이다. 이 약속의 내용을 알고 있다면 가급적 최대한 쉽게 식별이 가능하도록 만드는 것이 매우 중요하다는 말이다.
사실 이러한 내용은 그저 많은 약속 중의 단 하나일 뿐이다. 이러한 제한 조차 감당하기 어려운 경우에는, 별도의 호스트명 - IP 의 맵핑 로직을 만들어야 한다. 따라서 몇몇 대규모 클라우드 호스팅 업체의 경우 호스트명으로 아예 MAC 을 사용하는 경우도 있다.
랙 한두개로 클라우드를 모방하는 것은 기술적인 측면에서나 서비스적인 측면 모두에서 사실 별 일은 아니다. 이는 그저 시작일 뿐이며, 자그마한 유닛을 가지고 PoC 정도를 수행하는 것에 지나지 않는다. 물론 이러한 작업조차 하지 않는 경우가 대부분이긴 하지만, 수백, 수천대, 또 지역적으로 글로벌하게 서비스해야 하는 클라우드를 설계하는 경우라면 이러한 작은 차이들이 보다 수월한 자동화와 관리 시스템을 만들어 낼 가능성이 높다.
가장 중요한 것은, 이것은 기존의 방식과는 다르다 라는 것을 인지하는 것이 아닐까 한다. 하드웨어의 선정과 네트워크 구성은 절대 기존의 방식을 따라서는 안되며, 나아가 확장을 기본적으로 염두해 두지 않는다면 비용/관리/운영 모든 측면에서 눈덩이처럼 불어나는 이슈들을 감내하기가 분명 쉽지 않을 것이다.
Flat 네트워크나 Open vSwitch 와 같은 기술적인 내용의 수용에 앞서, 이러한 기본적인 내용을 이해하는 것이 무엇보다 중요하지 않을까 한다. 물론, 내가 지향하는 방법과 다른 방법이 분명 있을 수 있고, 그 방법이 보다 효율적이라면 따르지 않을 이유가 없지만 이러한 구성들은 한번 고려해 봄직 하지 않나 싶다.
졸립고 피곤한데 뭔가 한마디 쓰고 싶어 끄적인게 또 두서없이 길어져 버렸다. 쓰다보니 이런 글이 과연 도움이 될까 싶은 의문이 드는 밤이다.
( younjin.jeong@gmail.com, 정윤진 )
