RTO, 온프레미스로 복귀

Source: Dev.to

How we got there

클라우드로 이동하는 장점은 언제나 명확했습니다: 큰 CAPEX 없이 월 사용료만 내면 되고, 누군가가 컴퓨트, 네트워크, 그 외 모든 것을 제공해 주는 것이었습니다. CTO들이 거의 파블로프식 반응으로 “lift and shift” 전략을 제안하기 시작하면서 클라우드 채택은 기본 설정이 되었고, 결국 우리를 무감각하게 만든 유행어가 되었습니다. 우리는 결국 남의 컴퓨터 위에서 비즈니스를 운영하고 있다는 사실을 잊어버렸습니다.

이 무감각함은 그 컴퓨터가 “공유”된다는 사실이 고통스럽게 드러날 때 보통 깨집니다. 2017년, Cloudflare HTML 파서의 단 하나의 버그가 수천 개의 무관한 기업의 개인 메모리를 공개 검색 엔진 캐시로 유출했습니다. 만약 이것이 프라이버시 경고라면, 최근 장애는 가용성에 대한 명확한 교훈이었습니다. React 프레임워크의 취약점을 완화하기 위해 방화벽 조정이 배포되었을 때, 또 다른 파서 버그 때문에 인터넷 절반이 다운되었습니다. 누군가가 React를 사용한다는 이유만으로 내 가게가 다운돼야 할까요? 기술 리더가 이를 방지할 수 있는 방법은 없었습니다. 그리고 고객 데이터가 유출될 것이라는 보장에 대해서는 얘기하고 싶지 않네요(하지만 남을 탓할 수 있잖아요?).

중앙집중식 모델에서는 하드웨어 관리의 번거로움을 통제할 수 없는 폭발 반경 위험으로 교환합니다. 다행히도, 초기 클라우드 마이그레이션 시절과는 달리 상황이 근본적으로 변했습니다. 오늘날 Kubernetes, Terraform, 선언적 프로비저닝 원칙과 같은 기술 덕분에 물리적 랙을 클라우드 리전처럼 취급할 수 있게 되었습니다. 우리는 더 이상 서버를 관리하지 않습니다; 매니페스트를 관리합니다. 이 전환을 통해 완전 자동화되고 자체 복구가 가능한 클라우드 클러스터를 온‑프레미스 환경에 구축할 수 있게 되었으며, 이는 인간의 손길이 거의 닿지 않은 채, 대기업이 사용하는 동일한 GitOps 워크플로우에 의해 완전히 제어됩니다.

우리는 이제 AWS와 전자상거래처럼 가장 큰 경쟁자의 집 안에 디지털 상점을 여는 어색함을 거부할 기술적 성숙도에 도달했습니다.

RTO (Return to On‑premise)는 서버 랙에 대한 약간의 향수이기도 하지만, 무엇보다도 “내가 실수했으니 내려가도 된다”는 권리를 주장할 수 있는 능력에 관한 것입니다.