- 열심히 코드를 작성했다면 이를 실행해줄 하드웨어가 필요하다. 그래서 하드웨어를 구입하거나 임대해야 한다. 이것이 서비스형 컴퓨트(Compute as a Service, CaaS)의 본질이다. 여기서 컴퓨트(compute)란 프로그램을 실제로 실행해줄 연산 능력을 뜻한다.
- '내 프로그램을 실행해줄 하드웨어를 주세요'라는 개념이 어떻게 '조직의 발전과 성장에 발맞추어 확장되어 나가는 시스템'으로 만들어지는가?
- 25.1절: 구글이 이 문제의 해법을 도출하는 과정과 CaaS의 핵심 개념들을 설명한다.
- 25.2절: 관리형 컴퓨트 솔루션이 엔지니어의 소프트웨어 제작에 어떤 영향을 주는지 살펴본다. 우리는 '반려동물이 아닌 가축'이라는 개념의 유연한 스케줄링 모델이 지난 십수년 동안의 구글 성고에 밑거름이 되었다고 믿는다. 관리형 컴퓨트 솔루션은 소프트웨어 엔지니어에게 꼭 필요한 무기다.
- 25.3절: 조직이 발전하고 성장함에 따라 다양한 컴퓨트 아키텍처 선택이 어떤 역할을 하는지, 구글에서 배운 교훈 몇 가지를 깊이 파헤쳐본다.
- 25.4절: 자신의 조직에서 사용할 컴퓨트 서비스를 선택해야 하는 엔지니어들을 위한 팁을 제공한다.
- 구글에서 이용하는 Borg 시스템은 쿠버네티스나 Mesos 같은 많은 CaaS 아키텍처의 선구자이다.
- 안일한 솔루션으로는 거대한 시스템을 지탱할 수 없다.
- 하나의 머신에 바이너리를 배포하고 시작시키는 과정은 셸 스크립트로 쉽게 자동화할 수 있다. 그런 다음 유지보수하기 더 쉬운 언어로 이 스크립트를 병렬로 실행하게 만든다. 그러면 배포해야 할 머신 수가 많아져도 바로바로 대응할 수 있다.
- 각 머신을 모니터링하는 일도 자동화할 수 있다. 그러려면 제품 프로세스에서 생존 여부(alive)나 처리한 문서 수 같은 모니터링 지표를 내보내줘야 한다. 이런 정보를 공유 스토리지에 기록하거나 모니터링 서비스에 보내주면 정상 작동 여부를 한눈에 볼 수 있다. 그라파나(Graphana)와 프로메테우스(Prometheus) 같은 오픈소스 모니터링 도구들은 이런 정보를 대시보드에 모아 보여준다.
- 이상이 감지되면 SSH로 해당 머신에 접속하여 프로세스가 살아 있는 경우라면 프로세스를 종료하고 다시 시작해 문제를 해결한다. 다음과 같이 자동화할 수 있다.
- 장애 여부를 사람이 눈으로 모니터링하는 대신 각 머신에 이상 감지용 에이전트를 두고 장애 시 자동으로 프로세스를 종료시킨다.
- 프로세스를 다시 실행하기 위해 머신에 로그인할 필요 없이 전체 실행을 'while true; do run && break; done' 셸 스크립트로 감싸준다.
- 클라우드 세상에서는 헬스 체크(health check)에 실패하면 VM이나 컨테이너를 내렸다가 다시 생성하도록 자동 복구 정책을 설정해두면 된다.
- 사람이 구현한 머신 사용량 제한 메커니즘이나 새 머신으로의 작업 이전 등을 위해서는 더 복잡한 해법이 필요하다.
- 다음 단계로 자동화할 부분은 머신 할당이다.
- 스케줄링을 자동화하려면 다음 조건을 만족하는 중앙 서비스가 필요하다.
- 사용 가능한 머신의 전체 목록을 알고 있다.
- 요청 시 미사용 머신을 선택하여 제품 바이너리를 자동으로 배포한다.
- 다음 단계는 이 스케줄링 메커니즘을 머신 장애 대응에도 활용하는 것이다.
- 머신별 로그를 살펴보다가 디스크 읽기 오류 같은 장애가 확인되면 담당자에게 수리하라고 알리고, 이후로는 장애가 발생한 머신에 작업을 분배하지 않게 한다.
- 조금 더 발전시킨다면 담당자에게 통보하기 전에 자동화 서비스가 간단한 조치를 시도해볼 수 있다. 예컨대 머신을 재부팅하거나 디스크 검사를 해본다.
- 머신이 하나일 때는 SFTP와 SSH만으로 부족함이 없다. 하지만 수백에서 수천 대로 늘어난다면 자동화로 사람을 대체해줘야 한다.
- 지금까지는 편의상 머신과 그 위에서 구동되는 프로그램이 일대일로 대응된다고 가정했다. 하지만 이 구조는 컴퓨팅 자원(RAM, CPU, 디스크 등) 활용 관점에서 매우 비효율적이다.
- 일반적으로 (하드웨어 사양이 다른) 머신의 종류보다 (자언 요구사항이 다른) 작업의 종류가 훨씬 많다. 따라서 많은 종류의 작업을 한 가지 머신에서 구동하는 게 일반적이며, 이 때 자원 요구사항이 가장 까다로운 작업을 기준으로 머신을 준비해야 한다.
- 프로그램 자원 요구사항은 시간이 갈수록 늘어나지만 머신을 새로 구비하는 데는 시간이 걸린다. 만약 막강한 최신 서버 머신들을 새로 구비하는 데 수개월이 걸린다면, 몇 개월 후의 예상 자원 소모량까지 감당할 수 있도록 머신들을 넉넉하게 운용해야 한다. 여유분만큼 컴퓨팅 파워가 활용되지 못하고 있으니 항시 자원을 낭비하고 있는 꼴이다.
- 새 머신들이 구비되더라도 옛 머신들을 바로 처분하기는 어렵다. 버리는 것 자체도 낭비일 수 있다. 결국 다양한 머신들로 구성된 서버 팜을 관리해야 한다.
- 가장 쉽게 떠오르는 해법은 프로그램별로 필요한 CPU, RAM, 디스크 용량 등으로 표현된 자원 요구사항을 명기한 다음, 스케줄러가 머신 풀에서 여유 있는 머신을 선택하여 프로그램을 채워 넣는 방식일 것이다.
- CPU 자원이 부족해지면 같은 머신에서 구동 중이던 다른 서비스는 지연시간이 늘어날 것이다. RAM이 부족해지면 메모리 부족 오류를 내면 커널에 의해 강제 종료되거나 디스크 스왑이 일어나 지연시간이 끔찍하게 늘어날 것이다.
- 함께 구동 중인 다른 프로그램은 같은 의존성의 다른 버전을 요구할 수 있다. 혹은 /tmp 디렉터리 같은 전역 자원의 경우 다른 프로그램도 사용할 수 있다는 사실을 미처 고려하지 못하고 작성된 프로그램도 있다.
- 보안 문제도 생길 수 있다. 민감한 데이터를 다루는 프로그램이라면 같은 머신에서 구동 중인 다른 프로그램이 데이터를 볼 수 없도록 지켜야 한다.
- 멀티테넌트(multitenant) 컴퓨트 서비스는 테넌트들을 일정 수준 격리해 보호해줘야 한다. 즉, 같은 머신의 다른 테넌트로부터 프로세스가 방해받지 않고 안전하게 수행될 수 있게 보장해야 한다.
- 고전적인 격리 기법으로는 가상 머신(Virtual Machine, VM)이 있다. 하지만 부하가 지나치게 크다. 가상 머신 위에서 운영체제까지 돌려야 해서 자원도 많이 쓰고, 운영체제를 부팅해야 해서 구동시간도 느리다. 그래서 적은 자원만 써서 빠르게 처리하고 종료하면 충분한 배치 작업에는 이상적이지 못하다.
- Borg는 결국 cgroups, chroot jail, bind 마운트, (파일시스템 격리를 위한) union/overlay 파일시스템 등을 이용하는 컨테이너로 진화했다.
- 오픈 소스 버전의 컨테이너로는 도커(Docker)와 LMCTFY 등이 있다.
- 시간이 흐르고 조직이 성장하면서 새로운 잠재적 격리 실패 요인이 계속 발견되었다.
- 프로세스 ID 공간이 고갈되어 격리가 실패한다.
- 하나의 복제본(replica)이 운용할 수 있는 프로세스/스레드 수의 제한도 문제가 되었다.
- 자원 요구사항을 사람에게 물어 결정하는 방식은 다소 믿음이 가지 않는다. 사람들이 항시 면밀히 관찰하며 조정해줄 수도 없다.
- 설정 매개변수는 그 자체가 날이 갈수록 효율을 떨어뜨리는 원인으로 변해간다. 서비스 런칭 시 엔지니어들은 이 값을 정하기 위해 시간을 들여야 하고, 조직이 커져 서비스들이 계속 늘어나면 결정 비용도 함께 커진다. 나아가 프로그램 자체는 업그레이드될 때마다 대체로 덩치가 커지지만, 이때 설정 정보까지는 잘 업데이트하지 않는다. 이런 일이 누적되면 결국 운영 중단 사태로 치달을 수 있다.
- 이 문제를 해결하는 가장 자연스러운 방법은 매개변수 설정을 자동화하는 것이다.
- 조직이 커지고 제품들이 많이 사용될수록 다음의 세 요인 모두가 증가한다.
- 관리해야 할 애플리케이션의 종류
- 운영해야 할 애플리케이션 복제본의 수
- 가장 큰 애플리케이션의 크기
- 규모 확장을 효과적으로 관리하려면 이상의 세 요인 모두를 자동으로 관리해야 한다.새로운 형태의 요구사항과 증가하는 규모를 감당하려면 자동화 자체도 더 복잡해진다는 사실을 인지하고 대비해야 한다.