인프라 기초지식 13. 인프라 운영 part.3

대규모 인프라 관리

대규모 인프라를 관리하려면 시뮬레이션에 바탕을 둔 면밀한 사전 준비와 관리체제를 구축해야한다. 대규모 인프라 관리에서 오해하면 안되는 것은 대규모 인프라 관리를 중소 규모 인프라 관리의 연장선에서 파악하는 것이다.

대규모 인프라는 인적자원, 데이터센터 공간, 서버, 네트워크 장비, 네트워크대역 등 온갖 자원이 동시에 부족해지는 가운데서 우선순위를 매겨 가며 잇달아 대책을 세워야하는 세계다. 중간 규모 이하의 인프라는 임기응변식의 대응으로도 충분히 시간 내에 대응할 수 있을 때가 많다. 하지만 대규모 사이트에서는 면밀하게 계획을 세운 다음 효율을 추구해가지 않으면 계속 증가하는 기기 관리와 장애 건수에 밀려 운영이 파탄난다.

대규모 인프라라는 것은 단순히 서버가 늘어나느 ㄴ것뿐만 아니라 운영 방법 자체가 완전히 달라진다.

말하자면 기기를 한 때씩 관리하는 방법보다는 전체를 통합해 바라보면서 체계를 세우고 관리하는 운영방법을 사용한다.

대규모 인프라를 관리하는 엔지니어는 자산관리, 서버의 물리적 설치, 운영체제 설치, 감시, 장애 처리 등 다양한 업무를 제한된 인원으로 꾸려가그 위해서 관리 체제의 계통을 세워 조직하는 것이 업무의 중요한 주제가 된다.

기술적인 대응도 중요하지만 그이상으로 각중 기획이나 구매 상담, 오퍼레이터에 대한 작업지시 등이 일의 중심이 된다.

인프라 엔지니어의 묘미는 전례가 없는 규모의 인프라를 여러 업체와 함께 모색하면서 개척해 가는 데 있다. 인프라의 규모가 커질수록 구매하는 양도 크게 달라지므로 공급업체측에서도 적극적으로 제안하고 함께 검토해 나간다.

시스템 구성의 결정 포인트

업체 지원의 필요성

업체의 지원이 필요 없으면 관리 비용이불필요한 것을 이용하고, 업체의 지원이 필요하면 유지 보수 서비스가 있는 것을 이용해서 구성한다. 예를 들어 웹 서버는 Cent OS등의 오픈소스로 구축하고, 데이터베이스 서버는 윈도나 레드햇 엔터프라이즈 리눅스 + 오라클로 구축하는 구성을 흔히 볼 수 있다.

사용언어

java, perl, PHP, .Net, Ruby, 등 사용 언어에 따라 시스템 구성이 달라진다. 예를 들어 닷넷을 채용할 때는 자동으로 윈도 서버를 사용한다.

액세스 양

대규모라면 예상되는 부하를 산정해서 하드웨어 자원을 충분히 확보하고 적절히 부하를 분산해줘야 한다.

가용성

어느 정도 서비스를 멈춰선 안되는지를 나나태는 말로서 사용성이라는 말이 있다.

가용성을 높이기 위해서 스케일 아웃 구성에서는 저렴한 서버를 여러 대 준비해서 중복구성 (redundant Configuration ) 한다. 반면 스케일 업 구성에서는 비싸도 잘 고장이 안나는 엔터프라이즈 서버 등을 이용한다.

외부 업자 이용

대귬호 인프라 운영에서 적은 사원 수로 업무를 꾸리려면, 외부 업자를 적극적으로 잘 이용할 필요가 있다.

- 납품 기기의 포장을 뜯고 랙에 마운드

- 배선

- 기기 셋업

- 장애 대응 지원( 운영체제와 미들웨어 등의 프리미엄 지원 계약)

- 서버 룸 청소

- 인프라 운영 시스템 개발

- 하드웨어 고장 시 자동 대응

CDN( Contents Delivery Network )

대규모 사이트에서는 이미지나 실행 파일 같은 정적 콘텐츠 배포에 자주 사용한다.

CDN은 서비스 제공 회사의 서버를 대신해 CDN업체가 제공하는 캐시 서버에 접속해서 사용자가 정적 콘텐츠를 받아가는 구조의 컨텐츠 전송망이다. 사용자는 자신의 단말에서 가장 가까운 캐시 서버에 접속해서 빠르게 컨텐츠를 가져올 수 있는 장점이 있다.

또한 자사로서는 아무리 접속이 증가해도 원서버 대수와 네트워크 대역을 늘리지 않아도 되는 장점이 있다.

CDN의 기본적 구조 .1

CDN 구조 2

DSR 구성을 이용한 부하 분산

DSR( Direct Server Return ) 구성은 L4스위치( 로드 밸런서 )에서 이용되는 부하 분산 기법의 하나다.

일반 웹 사이트에서 부하 분산을 할 때 DSR구성은 거의 채용되지 않지만, 네트워크 트래픽이 대량으로 발생하는 대규모 웹 사이트 등에서는 DSR 구성을 이용하는 것은 상식으로 되어 있다.

일반적인 구성과 DSR 구성의 차이

일반적인 구성에서는 스위치와 서버 사이에 L4스위치를 두는 구성을 한다. 반면에 DSR 구성에서는 상위 스위치 등에 직접 L4스위치를 연결한다.

패킷의 흐름을 살펴보자. 일반적인 구성에서는 들어오는 패킷도 L4스위치를 통해서 서버에 도달하고 돌아가는 패킷도 L4스위치를 통해서 나간다.

그렇지만 DSR 구성에서는 들어오는 패킷은 L4스위치를 통과하지만 돌아가는 패킷은 L4스위치를 거치지 않고 서버에서 직접 돌아간다.

DSR 구성의 장점

- 요청에 대한 L4스위치의 수용력 증가

]일반적으로 웹서버에서는 인바운드와 아웃바운드 트래픽 사이에 큰 차이가 있다.

보통 웹서버는 요청된 트래픽의 몇 배에서 몇십배나 되는 트래픽을 응답으로 반환한다.

일반적인 구성일 때는 L4스위치가 들어오고 나가는 트래픽을 모두 처리한다. 예를 들어 인바운드가 20Mbps이고 아웃 바운드가 120Mbps라고하자 L4스위치가 100Mbps의 FastEther포트를 가지고 있을 때, 인바운드 쪽은 아직 80Mbps나 여유가 있지만 아웃부운드 쪽은 20Mbps 부족하므로 인터페이스를 100Mbps에서 1Gbps로 업그레이드 해야만 한다.

반면에 DSR 구성에서는 인바운드양과 아웃바운드 양이 거의 같아진다. 아웃바운드의 트래픽을 큰 폭으로 절약할 수 있기 때문에 요청에 대한 L4스위치의 수용량이 많이 늘어난다.

- 네트워크 구성이 비교적 자유로워 진다.

일반적인 구성에서는 스위치와 서버 사이에 L4스위치를 넣어야 한다는 제약이 있었다.이 제약은 서버 구성을 변경할 떄나 L4 스위치가 고장날 때 마다 네트워크 구성까지 변경해야만 한다는 것을 의미하ㅏㄴ다.

그 반면, DSR 구성에서는 기본적으로 어느 스위치에 L4스위치를 연결해도 부하 분산이 가능해지므로, 네트워크 토폴러지가 단순해지고 고장낫을때의 처리가 쉬워진다.

- 한포트만 사용한다

일반적인 구성에서는 L4스위치에 많은 스위치나 서버가 연결되기에 포트가 많이 필요해진다. 하지만, 포트가 많은 L4스위치는 매우 고가이므로 일반적으로 L4스위치 아래에 L2스위치를 연결하고 거기에 서버를 달아서 구성한다. 반면 DSR구성에서는 상위스위치에 포트 하나만 사용하면 되므로 매우 경제적이다.

DSR 구성이 일반적이지 않은 이유

일반적인 구성에서는 L4 스위치의 설정만 변경하면 부하 분산 설정이 끝난다. 반면 DSR 구성에서는 L4스위치에 DSR 설정을 하고, 추가로 부하 분산을 하는 모든 서버에 루프백이라고 불리는 가상 네트워크 인터페이스 설정을 해야한다. 루프백에 는 VIP(Virtual IP )라고 불리는 부하 분산용 IP 주소를 기술한다.

이처럼 DSR 구성은 일반적인 구성과 비교하면 설정 항목이 늘어났고, 또한 일반적인 구성이 아니라서 DSR 구성 설정에 익숙하지 않은 사람이 많다. 바로 이런 점들이 DSR 구성이 일반적으로 사용되지 않는 이유가 된다.

리소스 부족 대책

- 인적 리소스 부족

인프라 전체를 관리하는 코어 멤버와 실제 작접을 수행하는 오퍼레이터로 나누어 생각한다. 회사에 따라서는 코어 멤버가 오퍼레이터를 겸하기도 한다.

일반적으로 코어 멤버를 채용하기는 몹시 어렵다. 애초에 대규모 인프라 경험자 자체가 그다지 많지 않은데다 그런 인재는 이직 시장에 거의 돌아다니지 않기 떄문이다. 따라서 코어 멤버의 중도채용에는 상당한 기간이 걸릴 것을 각오해야 한다. 어쩌면 코어 멤버가 될 수 있는 신입사원을 채용해서 몇년간 키우는 쪽이 빠를지도 모른다.

반면 오퍼레이터 채용은 이직 시장에 후보가 될만한 좋은 인재가 많이 있다. 서버와 네트워크 기초를 전체적으로 배운 사람이라면 실무 경험이 없어도 비교적 단기간에 키울 수 있다.

- 데이터 센터 스페이스 부족

대규모 인프라에서 랙 단위나 스페이스 단위, 혹은 룸 다위로 계약한다. 성장세가 두드ㅓ진 웹사이트는 엄청난 기세로 랙 스페이스를 잠식해 들어가고 결국 데이터 센터 자체의 수용 가능량을 넘는 일이 자주 있다. 이런 때는 다른 데이터 센터를 추가로 계약해야 하지만 애초에 시스템 자체를 여러 데이터 센터로 분리할 수 없을 때도 있다. 그러면 모든 서버를 새로운 데이터 센터로 이전하는 것도 검토할 필요가 있다.

새로운 데이터 센터의 계약에는 보통 몇개월이 걸린다. 게다가 새로운 공간에 분전반, 랙, 공조 시스템 등을 새로 설치하는 경우에는 바년ㄴ 정도 거릴 때도 있다. 무사히 새로운 데이터 센터를 확보할 수 있다고해도 그 후로 서버 이전, 오퍼레이터 재배치, 시스템 분리등에 상당한 부하가 걸린다.

- 장비부족

단기간에 장비를 증강해야 할 때, 재고가 있으면 다행이지만 재고가 없다면 새로 사야한다. 대규모 사이트에서는 대량 발주를 하는 일이 많으므로 업체 측과 생산 조절이 필요하다 IT 장비는 해외에서 들여오는 경우가 많은데 국제 정세에 의해 납품이 지연될 때도 있다.

- 네트워크 대역 부족

업링크가 1Gbps를 넘어가면 코어 라우터( 혹은 코어 L3 스위치) 의 업링크도 당연히 1Gbps 보다 늘려야만 한다. 10Gbps로 교체하거나 1Gbps를 묶어 2Gbps로 마드는 등의 방법이 필요하다. 자사의 라우터나 상위 회선 업체의 라우터가 트런킹(Trunking)이나 10Gbps를 지원하지 않는다면 그것이 수용량의 한계가 되기 때문에 상위 회선을 바꿔야 한다. 불가능 하다면 데이터 센터 자체를 변경할 필요가 있다.

-자금 부족

성장기조에 있는 IT 벤처 기업은 자금 부족에 빠지기 쉬워 생각처럼 필요한 IT 인프라에 투자할 수 없을 때가 있다. 이것은 엄밀하게는 인프라 엔지니어의 과제가 아니라 기업 경영의 과제라고 할 수 있다. 그러나 여기서는 자금 부족으로 원하는 대로 필요한 IT 인프라를 투자할 수 없을 때의 대처 방법을 생각해보자.

• 중고장비를 활용한다 : 중고 시장에서 좋은 품질의 장비를 싼 값에 구할 수도 있다.
• 튜닝을 한다 : 하드웨어, 소프트웨어 모두 튜닝할 여지가 있다면 튜닝해서 IT 인프라의 연명 조치를 시행한다.
• 평소 안면 있는 기업에 도움을 청한다 : 상대방이 자금에 여유가 있는 상황이라면 필요한 장비나 인재를 지원해줄 때도 있다.
• 증자를 요청한다 : 경영진에게 증자를 요청한다, 장래성 있는 사업이라면 증자에 응해줄 사람과 기업이 나타나는 법이다.