1P by neo 4달전 | favorite | 댓글 1개

쿠버네티스로의 11주간 이전 후 회사, 존재 이유를 잊어버림

  • 실리콘밸리의 신생 스타트업 Xenobroom Inc.는 2020년 5월 서버 인프라 업그레이드 과정을 시작함.

  • 전 세계적인 팬데믹 상황에서 일일 사용량이 급증하자, 기존 인프라를 쿠버네티스로 이전하기로 결정함.

  • 단순한 배시 스크립트와 VPS 머신을 재고하고 재설계하는 데 예상보다 오래 걸림.

  • 회사는 소프트웨어 의존성과 라이브러리를 업그레이드할 좋은 기회로 여김.

  • 단일 머신에서 운영되던 PostgreSQL 데이터베이스의 큰 부분을 AWS의 유연성을 활용한 분산 KV 스토리지로 변환함.

  • 'develop' 브랜치에서 일일 배포를 수행하는 일반 스테이징 서버를 CI가 가능한 프로덕션 전용 워크플로우로 대체함.

  • 이전 과정이 완료되었을 때, 회사의 누구도 제품의 목적을 기억할 수 없게 됨.

  • 사용자와 투자자 모두 원래 제품을 이해하지 못했으며, 몇 주간의 다운타임 이후 제품의 의미를 복원하는 것은 사실상 불가능함.

  • CEO는 구글의 메시징 앱 시장 점유율 증가를 도운 것으로 알려진 심령 전문가 Phutar Afrayughum의 도움을 구함.

GN⁺의 의견

  • 이 기사는 쿠버네티스로의 마이그레이션 과정이 기업에 미치는 영향을 풍자적으로 다루고 있음. 현실에서도 기술 이전은 기업의 운영에 큰 변화를 가져오며, 때로는 본래의 목표를 잃어버리는 경우가 있음.
  • 기술 이전을 고려할 때는 기술적인 측면뿐만 아니라 조직의 비전과 목표에 대한 명확한 이해가 필요함. 이는 기술이 조직의 목적을 지원해야 한다는 원칙을 강조함.
  • 쿠버네티스는 많은 기업에서 선호하는 컨테이너 오케스트레이션 플랫폼이지만, 도입 전 충분한 준비와 전문 지식이 필요함. 그렇지 않으면 복잡성과 관리 부담이 증가할 수 있음.
  • 이 기사는 기술 도입이 항상 긍정적인 결과만을 가져오는 것은 아니라는 점을 상기시켜 줌. 때로는 기술이 조직의 본질적인 가치와 목표를 흐릴 수 있음을 경고함.
  • 쿠버네티스와 유사한 기능을 제공하는 다른 플랫폼으로는 Docker Swarm, Apache Mesos 등이 있으며, 이들은 상황에 따라 쿠버네티스의 대안이 될 수 있음.
Hacker News 의견
  • 중간 관리직 20% 해고로 개발 생산성 3배 향상된 사례

    한 회사가 중간 관리직 20%를 해고함으로써 우연히 개발 생산성을 3배 향상시킨 사례가 있음.

  • Kubernetes로의 마이그레이션 경험 공유

    현재 진행 중인 Kubernetes로의 마이그레이션은 2년이 지났지만 30%도 완료하지 못했으며, 처음에 Kubernetes를 강력히 주장했던 사람들이 이제는 LLMs에 관심을 가지고 있음을 지적함. 새롭고 반짝이는 것을 좋아하는 사람들이 있으며, 이러한 역할이 자체적으로 유용할 수 있음을 시사함.

  • Theolognion 블로그의 재미있는 글들

    Theolognion 블로그에는 여러 재미있는 글들이 있으며, 특히 '완벽한 노트 취합 시스템을 개발한 개발자'와 '해커뉴스 댓글을 분석한 AI가 모든 정치, 경제, 의료 문제를 해결'하는 글이 재미있음.

  • 실패의 원인에 대한 농담

    실패의 원인을 분석하는 포스트모템(post-mortem)에서는 회사가 소프트웨어 의존성과 라이브러리를 업그레이드할 좋은 기회로 여겼을 것이며, 단일 머신에서 실행되는 PostgreSQL 데이터베이스의 상당 부분을 AWS의 유연성을 활용하여 분산 KV 스토리지로 변환할 수 있었을 것이라는 가정이 나옴.

  • 실제 Kubernetes로의 11주 마이그레이션 성공 사례

    실제로 11주 안에 Kubernetes로 마이그레이션하는 것이 큰 성공으로 인정받을 일임.

  • Kubernetes로의 서비스 마이그레이션 팁

    복잡한 기술은 먼저 배우고, 중요하지 않은 작은 서비스부터 시도해야 함. 한 번에 한 가지 일을 하고, 간단하게 시작해야 함. 저자는 Kubernetes로 서비스를 마이그레이션하는 데 문제가 없었으나, 이는 2년간의 학습과 시도, 그리고 인터넷에서 찾을 수 없는 가장 적합한 접근법을 찾기까지 여러 접근법을 시도한 결과임. 저자는 gitops를 자동화 없이 사용하며, 필요한 것을 kubectl apply -k로 적용함. 이제 수십 개의 서비스와 충분한 이해를 갖고 있어서 flux 도입을 고려 중임.

  • 시스템 운영의 용이함과 저렴함

    시스템을 운영하는 것이 그 어느 때보다 쉽고 저렴해졌지만, 엔지니어들은 종종 복잡하고 비효율적인 방법을 선택하여 간단한 작업을 수행하는 경향이 있음.

  • 기술 선택과 관련된 업계의 문제점

    GraphQL/React/Next와 같은 기술을 도입하여 완벽하게 기능하는 애플리케이션을 마이그레이션하는 것에 대해, 업계에서 오랫동안 일한 사람으로서 많은 사람들이 무엇을 하고 있는지 모르고 있다는 인상을 받음.

  • 클라우드 스토리지로의 마이그레이션 경험

    자체 호스팅된 MinIO에서 관리되는 blob 스토리지로 500,000개의 blob을 이동하기 위해 4개월 동안 밤낮으로 싸웠지만, 실제 생산적인 작업은 정치나 관료주의와 관련 없는 1주일 미만이었으므로, 11주 안에 Kubernetes로 마이그레이션하는 것이 큰 성공으로 보임.

  • 1970년대 변호사 사무실의 컴퓨터 도입 경험담

    1977년 젊은 변호사로 일하며 시간당 요금제로 청구했던 경험과, 1979년 Tandy I 컴퓨터를 구입하여 Foxbase와 같은 데이터베이스 프로그램을 사용한 경험을 공유함. 1981년 자신의 법률 사무소를 개업하고, 당시에는 팩스 기계와 전기 타자기가 사무실 생산성을 높이는 최신 기술이었지만, 개인용 컴퓨터는 사용하지 않았음. 저자는 모든 비서에게 Compaq 컴퓨터를 구입하고, 수작업으로 이루어지던 청구 시스템을 대체할 시간 및 청구 프로그램을 작성하는 데 많은 시간을 할애했으며, 네트워크도 설치함. 그러나 이러한 기술에 집중하다 보니 변호사로서의 업무나 비즈니스 고객과의 관계 유지에 소홀했고, 결국 1994년에 사무소를 폐업함. 당시에는 모든 사무실이 워드 프로세싱을 위해 컴퓨터를 사용했지만, 상용 청구 프로그램은 존재하지 않았고, 다른 법률 사무소의 변호사들이 저자의 청구 프로그램을 원했지만, 저자는 프로그래밍을 즐기는 데 집중하면서 사업을 망친 경험을 공유했음.