대규모 기술 기업이 독점 솔루션 개발에 집착하는 이유

안녕하세요! 저는 대규모 기술 기업이 인프라를 위한 독점 솔루션 개발에 집착하는 이유에 대해 이야기하고 싶습니다. 대답은 분명해 보입니다. 그것은 NIH 증후군에 지나지 않습니다. 그러나 이 대답은 객관적인 것은 말할 것도 없고 완전하지도 않습니다.

저는 Yandex 플랫폼 엔지니어링 팀의 CTO이며 우리의 목표는 엔지니어가 코드 작성부터 서비스 운영에 이르기까지 전체 개발 주기를 구축하여 보다 효율적으로 만들 수 있도록 지원하는 것입니다. 여기에는 프로세스 간소화가 포함됩니다. 당사는 서비스형 제품을 개발할 뿐만 아니라 회사 내에서 구현하는 데 도움을 줍니다. 이는 Yandex 규모에서 작동합니다. 당사 서비스는 회사 전체의 수천 명의 개발자가 사용합니다.

개발 주기를 구성하는 도구의 예

문제를 해결하기 위해 우리는 기성 도구를 구현하기보다는 독점 도구를 개발하는 경우가 많습니다. 예를 들어, 팀에서 프로그래머로 재직하는 동안 저는 C++ 및 Python으로 정량적 모니터링 시스템을 작업하고 이를 수백억 개의 처리된 측정항목으로 확장하는 데 도움을 주었습니다. 그래서 내 경험을 바탕으로 나는 어떤 동기와 개발 경로가 사내 도구의 출현으로 이어지는지 알고 있습니다. 아래에서는 우리 솔루션을 예로 사용하여 도구가 탄생한 근본적인 이유를 식별하려고 시도할 것입니다.

이야기 #1: Yandex 내부 클라우드

작업을 설정합니다. 내부 런타임 클라우드(RTC)의 목표는 내부 사용자에게 간단한 배포 및 트래픽 관리 도구를 제공하는 것입니다. RTC 사용자는 Yandex 서비스를 개발하는 엔지니어와 동일합니다. 그리고 어딘가에서 만든 수만 개의 애플리케이션을 실행하고, 사용자 요청을 그곳으로 보내고, 로드 균형을 맞추고, 사고를 처리해야 합니다.

내부 클라우드의 필요성은 서비스 수가 이미 수백 개에 달하고 할당된 총 코어 수가 매년 수십%씩 증가했던 2010년대 초반에 나타났습니다. 각 서비스에 대한 전용 서버를 보유하는 것은 엄청나게 비용이 많이 들었고, 단일 서버에서 여러 서비스의 애플리케이션을 실행할 수 있는 도구가 필요했습니다. 처음에는 이러한 도구에 대한 몇 가지 요구 사항이 있었습니다.

• 운영 자원을 절약하고 릴리스 중 사고 수를 줄이려면 일상적인 작업을 자동화해야 합니다.
• 별도의 중요한 작업은 클라우드 활용도를 높이는 것이었습니다. 특히 대부분의 서비스에는 로드에 일일 패턴이 있고 클라우드는 밤에 유휴 상태였기 때문입니다. 해당 기간 동안 모든 Yandex 서비스가 클라우드에서 호스팅되지 않았고 서버 수가 지속적으로 증가하여 문제가 악화되었다는 사실로 인해 상황은 더욱 복잡해졌습니다.
• Yandex 개발 속도에 직접적인 영향을 미치기 때문에 기능이나 버그 수정을 사용자에게 신속하게 출시하는 것이 중요했습니다.
• IPv6 전용 지원이 필요합니다. 포드 간 종단 간 연결을 제공하기 위해 우리 데이터 센터는 IPv6 전용으로 구축되었습니다. 왜냐하면 우리 규모에서는 IPv4 주소 범위가 충분하지 않기 때문입니다.

본질적으로 우리에게는 Kubernetes가 필요했습니다(그리고 시간이 지남에 따라 RTC가 매우 가까워졌습니다). 하지만 문제는 다음과 같습니다. k8s는 2014년에야 발표되었습니다. Apache Mesos는 당시에 존재했지만 초기 단계였습니다.

기본 기능 구현. 우리는 일종의 MVP, 즉 일상적인 작업을 자동화하는 빌딩 블록 세트와 유사한 간단한 도구 세트로 문제를 해결하기 시작했습니다. 예를 들면 다음과 같습니다.

• 클러스터 자원 할당;
• 필요한 버전의 애플리케이션과 다양한 아티팩트를 클러스터에 전달합니다.
• 클러스터에서 필요한 버전의 애플리케이션을 시작합니다.

시간이 지남에 따라 이러한 빌딩 블록을 사용하여 본격적인 서비스 레이아웃 그래프를 구성하는 것이 가능해졌습니다(지속적인 전달과 유사). 몇 번의 반복을 거쳐 2013년 RTC에서 실행되는 서비스를 관리하는 시스템인 Nanny가 등장했습니다.

Nanny의 또 다른 기본 측면은 리소스 소비에 따른 애플리케이션 격리 구현이었습니다. 처음에는 리소스 격리 없이 다양한 서비스에서 애플리케이션을 시작했는데, 이로 인해 수많은 운영 문제와 사고가 발생했습니다.

당시 기성 솔루션은 그때쯤 개발이 중단된 LXC뿐이었고, IPv6 전용을 사용할 수 없고 dockerd 업데이트 시 모든 컨테이너를 다시 시작하는 Docker만 있어서 사용자에게 영향을 주지 않고는 dockerd 업데이트가 불가능했습니다. 그 결과, 우리는 개발을 시작했습니다. 2014년 중반쯤 Linux 커널 cgroup 위에 컨테이너화 시스템이 추가되었습니다. 대부분의 애플리케이션과 서버의 일부 시스템 에이전트는 2015년에 이미 Porto 컨테이너로 이동되었습니다.

활용 문제를 해결합니다. 당시 내부 클라우드의 리소스 관리는 저장소에 대한 커밋을 통해 이루어졌습니다. 그러나 이로 인해 Yandex의 개발 속도가 느려지고 활용도를 높이는 작업과 충돌했습니다. 이 문제를 해결하려면 지도 축소 시스템을 클라우드에 배치해야 했습니다. - 당시 약 7년 동안 개발해 온 빅데이터 저장 및 분산 컴퓨팅을 위한 자체 내부 시스템입니다. 내부 클라우드로 가져와야 했지만 사용자 애플리케이션과 함께 실행되어야 했습니다.

YTsaurus를 RTC로 가져오려면 리포지토리 커밋을 통하지 않고 포드를 동적으로 관리하는 기능이 필요했습니다. 그래서 2018년에 우리는 , 클러스터 컴퓨팅 자원을 관리하는 시스템입니다. Yandex Planner는 기존 Nanny 배포 시스템과 통합되어 YTsaurus 마이그레이션 차단을 해제하고 RTC를 본격적인 클라우드로 전환했습니다. RTC는 당시 수만 대의 서버를 보유하고 있었는데, 맵리듀스가 도입되면서 이 숫자는 크게 늘어났습니다.

새로운 성장통. 같은 기간 동안 k8s는 훨씬 더 성숙한 솔루션으로 발전하여 2017년에 AWS 서비스 중 하나가 되었습니다. 그러나 여전히 우리의 모든 요구 사항을 충족하지 못했습니다.

• 수만 대의 서버 규모 - 하나의 k8s 설치로는 여전히 우리의 규모를 감당할 수 없습니다.
• 듀얼 스택 IPv6 및 IPv4에 대한 지원은 2020년에만 k8s에 나타났으며 IPv6는 처음부터 우리에게 매우 중요했습니다.
• 별도의 배치 및 컴퓨팅 스케줄러를 생성하기로 결정했기 때문에 필요한 중첩 컨테이너 지원. 우리는 이 옵션의 효율성을 어느 시점에서 일반 스케줄러의 효율성과 비교했는데, 모든 것에 대해 일반 스케줄러를 만들려고 하지 않는 것이 더 편리하고 수익성이 있었습니다.

YTsaurus는 단일 스케줄러를 만드는 대신 중첩된 Porto 컨테이너를 만드는 기능을 적극적으로 사용했습니다. 물론 k8s에 동일한 듀얼 스택에 대한 지원을 추가할 수도 있습니다. 그러나 Linux 커널 개발 경험에 따르면 모든 것을 오픈 소스로 보낼 수는 없으며 새 버전으로의 업데이트를 단순화하기 위해 업스트림 커널의 델타를 최소한으로 유지하려고 노력하고 있습니다.

오늘 우리의 솔루션. RTC의 아키텍처는 Kubernetes의 아키텍처와 매우 유사합니다. 사용자는 지정된 애플리케이션을 시작하는 방법과 데이터 센터를 설명하는 일부 사양의 형태로 서비스를 선언적으로 설명합니다. 각 데이터 센터에는 한편으로는 모든 클러스터 개체에 대한 데이터베이스 역할을 하고 다른 한편으로는 포드 스케줄러 역할을 하는 Yandex Planner가 자체적으로 설치되어 있습니다. 데이터 센터의 각 서버는 Yandex Planner로부터 포드 사양을 수신하고 독점 Porto 컨테이너화 시스템을 사용하여 이를 실행하는 에이전트를 실행합니다.

현재 RTC는 수만 개의 서비스를 출시하여 100,000개 이상의 서버에 500만 개 이상의 코어를 할당했습니다. 매일 100,000개 이상의 서비스 사양 변경이 이루어집니다.

계획. k8s가 우리의 규모를 감당할 수 있다면 어떨까요? 특히 k8s 생태계가 어느 시점부터 기능면에서 우리를 능가하기 시작했기 때문에 더욱 그렇습니다. k8s로 전환하고 기성 도구가 결국 우리에게 필요한 볼륨을 제공할 수 있기를 바라는 것이 더 낫지 않을까요? 실제로 우리는 계속해서 k8s의 틈새 소비자로 남아 있습니다. 그 이유는 소수의 회사만이 대규모로 운영되고 각 회사가 자체 사내 클라우드 솔루션을 보유하고 있기 때문입니다.

기억해야 할 또 다른 중요한 점은 마이그레이션 문제입니다. 2018년 7월 기준 보고서에 따르면 최신 애플리케이션의 90%는 2025년까지 계속 사용될 것이며 이러한 시스템 개발을 위한 기술 부채는 IT 예산의 40% 이상을 차지할 것입니다. 사용자 서비스를 Yandex Planner로 마이그레이션한 경험을 바탕으로 볼 때 이는 현실에 가깝습니다. 2023년에는 약 100,000개의 코어가 여전히 Yandex Planner로 이동할 차례를 기다리고 있었습니다.

2021년에 우리는 개발 전략을 선택할 때 한 배포 시스템에서 다른 배포 시스템으로 이동하는 데 드는 비용을 추정했습니다. Yandex를 바닐라 k8로 마이그레이션하는 것은 수백 명의 인력이 소요되는 매우 비용이 많이 드는 작업이 될 것입니다.

이렇게 간단한 방법으로 우리는 그러한 목표를 설정하더라도 향후 5년 내에 버릴 수 없을 것 같은 내부 클라우드를 갖게 되었습니다.

k8s에 비해 내부 클라우드 기능이 부족한 점은 어떻게 해야 할까요? 실제로 고객은 Yandex Cloud에서 관리형 Kubernetes를 사용할 수 있습니다. 이 옵션은 엄격한 규정 준수 요구 사항을 충족해야 하는 프로젝트에 주로 사용됩니다. 이는 1% 미만의 작은 비율의 팀입니다. 위에서 언급한 이유로 인해 나머지 인구는 이사를 통해 큰 혜택을 누리지 못합니다.

동시에 우리는 k8s를 적극적으로 살펴보고 일반적으로 인정되는 표준에 더 가까워지는 방법을 고려하고 있습니다. 우리는 이미 클라우드 부트스트래핑이나 전체 Yandex 규모의 IaaC 구성과 같은 일부 작업에서 k8s를 적극적으로 실험하고 있습니다. 이상적으로는 k8s 인터페이스를 재사용하는 동시에 우리의 요구에 최대한 맞춰진 자체 구현을 유지하고 싶습니다. 남은 것은 실제로 어떻게 수행할지 알아내는 것입니다.

• 다른 사람들은 어떻습니까? 이 기사에서는 일반적으로 빅테크에 대해 논의하고 있으므로 우리의 사례가 고유한 것이 아니라는 점은 주목할 가치가 있습니다. 확인해 보세요 또는 예를 들면.

이야기 #2: 단일 저장소

문제 및 해결 요구 사항 . 우리의 단일 저장소인 Arcadia는 내부 클라우드와 동일한 기본 목표를 공유합니다: 편리한 개발 도구를 제공합니다. 여기에는 저장소의 경우 전체 개발 생태계가 포함됩니다.

• 버전 관리 시스템(Arc),
• 인터페이스(Arcanum),
• 시스템 구축(네가 만들어요),
• CI/CD(NewCI).

Arcadia는 Yandex의 내부 클라우드와 거의 같은 시기에 등장했습니다. 단일 저장소를 만든 이유 중 하나는 Yandex 내에서 코드를 재사용해야 하기 때문입니다. 이는 당시 여러 빌드 시스템으로 인해 방해를 받았습니다. 전체 Yandex 규모에서 작업하려면 효율적인 분산 빌드를 지원하는 통합 시스템이 필요했습니다. 또한 안정적이고 사용 가능해야 합니다.

통합 빌드 시스템 구현. 우리의 독점적인 ya make 빌드 시스템은 C++ 코드 전용이었던 2013년에 데뷔했습니다. 만들기 전에 CMake를 사용했지만 속도 때문에 단일 저장소 규모로 확장할 수 없었습니다. 당신이 만든 독점 제품은 Arcadia에서 훨씬 빠르게 작동했습니다. 우리 문제를 해결할 수 있는 다른 오픈 소스 옵션은 없었습니다. 예를 들어 Bazel은 훨씬 늦은 2015년에 출시되었습니다.

버전 관리 시스템 확장. Yandex는 이전에 SVN을 버전 제어 시스템으로 사용했습니다. SVN은 용량이 크지만 여전히 제한적이고 유지 관리가 어렵습니다. 게다가 우리는 결국 SVN의 성능과 편의성의 한계에 직면하게 될 것임을 알고 있었습니다. 예를 들어 휴리스틱을 사용하여 저장소의 필요한 부분만 다운로드하거나 선택적으로 체크아웃하는 기능을 구현했습니다. 그 결과 2016년부터 우리는 SVN 외에 다른 버전 관리 시스템을 실험하기 시작했습니다.

Mercurial이 첫 번째 선택이었습니다. 하지만 우리가 가진 가장 큰 문제는 속도였습니다. 우리는 Mercurial을 생산하기 위해 1년 반 동안 노력했지만 결과는 실망스러웠습니다. 예를 들어 FUSE를 지원하기 위해 결국 Mercurial의 일부를 다시 작성해야 하거나 전체 저장소를 각 개발자의 노트북으로 가져와야 했습니다.

결국 자체 솔루션을 처음부터 작성하는 것이 더 저렴하다는 사실이 밝혀졌고, 2019년에는 Arcadia 사용자를 위한 Git과 같은 UX를 갖춘 새로운 버전 관리 시스템인 Arc가 등장했습니다. Arc의 기반은 선택적 체크아웃이 아닌 FUSE(사용자 공간의 파일 시스템)입니다. 또한 YDB는 확장 가능한 데이터베이스 역할을 하여 Mercurial에 비해 Arc의 운영을 크게 단순화합니다.

우리는 왜 git을 사용하지 않았느냐는 질문을 자주 받습니다. 규모 및 기능 제한도 있기 때문입니다. Arcadia 트렁크만 git으로 가져오는 경우 이 규모에서는 git 상태에 몇 분이 소요됩니다. 동시에 git 위에 구축된 안정적인 FUSE 구현은 없었습니다. Git용 VFS는 더 이상 개발되지 않으며 EdenFS는 결국 Sapling으로 전환되었지만 이는 훨씬 나중에 발생했습니다.

솔루션의 현황과 향후 계획입니다. 개발을 시작하려면 내부 사용자가 단일 저장소에 폴더를 만들고, 코드를 작성하고, 빌드 매니페스트를 추가하여 애플리케이션을 빌드하는 방법을 알려주면 됩니다. 결과적으로 사용자는 풀 요청, CI 구성 및 회사의 모든 코드를 재사용할 수 있는 기능을 받습니다.

규모 측면에서 트렁크에는 현재 1,000만 개의 파일이 포함되어 있고 저장소 전체가 2TiB를 초과하며 매주 30,000개 이상의 커밋이 이루어집니다.

결과적으로 우리가 만든 생태계에서는 처음부터 많은 구성 요소를 만들어야 합니다. 그러나 이제는 글로벌 표준을 준수하는 방향으로 나아가고 있습니다. 예를 들어 Arc는 미리 정의된 프로젝트 세트에 대해 Git 작업을 지원합니다.

• 다른 사람들은 어떻습니까? 다시 말하지만, 일반적으로 빅테크를 살펴보면 다음 사항에 주의를 기울여야 합니다. 그리고 .

이 이야기들의 공통점은 무엇인가

그렇다면 왜 거대 기술 기업이 자체 솔루션을 개발해야 하며 일반적으로 인정되는 표준을 준수하는 솔루션으로 대체할 수 없는 이유는 무엇일까요?

1. 혁신. 대기업은 미래에 일반화될 문제에 대한 솔루션을 개발해야 하는 경우가 많습니다. 이것이 바로 시장 표준이 될 수 있는 잠재력을 지닌 혁신적인 솔루션이 등장할 수 있는 방법입니다.

   
   

   회사가 해결한 문제가 항상 회사 자체가 아닌 다른 사람과 직면하는 것은 아닙니다. 때때로 특정 문제에 대한 거대 기술의 경험은 완전히 다른 개발 경로를 택함으로써 전체 업계가 해당 문제를 피하는 데 도움이 됩니다. 시장 발전을 예측하는 것이 항상 가능한 것은 아니며, 그 결과 독점 솔루션의 다양한 사례가 매우 다른 결과를 가져왔습니다.

   
   

   ClickHouse는 온라인 분석 처리(OLAP) 분야를 크게 강화한 진정으로 성공적인 혁신 프로젝트의 예입니다. 그러나 모든 프로젝트에 해당되는 것은 아닙니다. 오픈소스 프로젝트로 시작된 포르투는 여러 가지 이유로 관심을 끌지 못했다. 중첩된 컨테이너를 만드는 기능과 같은 일부 기능은 여전히 고유합니다.

   
   

2. 규모. 이 점은 모든 회사가 확장성 문제에 직면하는 것은 아니기 때문에 어떤 면에서는 이전 점과 유사합니다. 모두가 640KB이면 충분했던 시절이 있지 않습니까?

   
   

   실제로 시스템 부하의 기하급수적인 증가는 Arcadia와 내부 클라우드 개발의 가장 중요한 이유 중 하나였습니다. 이것이 Arc와 Yandex Planner가 개발된 이유입니다. Arc는 사용자가 트렁크에 수천만 개의 파일이 포함된 단일 저장소로 어려움 없이 작업할 수 있는 사용자 친화적인 VCS에 대한 요구에 부응하여 만들어졌습니다. Yandex Planner는 수만 개의 노드와 수백만 개의 포드로 구성된 클러스터를 효과적으로 작업해야 한다는 요구에 부응하여 만들어졌습니다.

   
   

   공개 도구에는 계속해서 확장 문제가 있습니다(결국 이는 상대적으로 드문 시나리오이며 이에 대한 투자는 수익성이 없는 경우가 많습니다).

   
   

3. 관성. 회사 내 문제를 해결하는 사내 도구를 생각해 보세요. 이 도구를 적극적으로 사용하는 회사는 이 도구를 필요에 맞게 더 잘 조정하기 위해 자원을 투자하여 결국 고도로 전문화된 도구로 전환할 것입니다. 이 과정은 수년간 지속될 수 있습니다.

   
   

   이제 특정 문제를 해결하기 위해 보편적으로 받아들여지는 표준이 어느 시점에 나타날 가능성을 생각해 보십시오. 이 경우 전문화는 사내 솔루션을 결정하는 데 여전히 중요한 요소일 수 있습니다. 빌드 시스템을 고려하십시오. Google의 Bazel이 있지만 우리는 Arcadia에서 만든 것을 사용합니다. 개념적으로는 유사하지만 세부적으로 살펴보면 각 워크로드의 로드 패턴이 크게 다를 수 있으므로 많은 중요한 시나리오가 다르게 구현됩니다. 결과적으로, 일반적으로 받아들여지는 새로운 표준을 맞춤화하기 위해서는 이미 소비된 자원을 재투자해야 할 것이 거의 확실합니다.

   
   

4. 마이그레이션. 이전 섹션에서 프로젝트를 사용자에 맞게 조정하는 문제를 다루었다면 이제 사용자 자체를 마이그레이션하는 문제를 다루겠습니다. 제 생각에는 기술 분야에서 이름 다음으로 중요한 문제는 마이그레이션이라고 해야 할 것 같습니다. 이미 사내 도구가 있고 이를 표준화된 도구로 교체하고 싶다면 필연적으로 마이그레이션이 필요할 것입니다.

   
   

   우리는 내부 클라우드 개발 경험을 통해 많은 마이그레이션 사례를 알고 있습니다. 대규모 마이그레이션에는 시간이 걸리므로 두 도구 모두 장기간 동안 동시에 지원되어야 합니다. 이 프로세스에 다수의 사용자가 참여하는 경우 관리 문제는 불가피합니다. 사용자 참여 없이 마이그레이션을 시도하는 것은 확실히 가치 있는 일이지만 이것이 항상 가능한 것은 아닙니다.

   
   

5. 비즈니스 연속성. 솔직히 말해서 이 점은 최근에 충분히 중요해졌습니다. 이전에는 공급업체 종속에 대한 우려로 인해 이를 심각하게 받아들이는 기업 수가 훨씬 적었습니다. 언제든지 협업을 종료할 수 있는 공급업체에 중요한 프로세스를 신뢰하는 것은 위험합니다. JetBrains는 IDE 사용을 특정 회사로 제한한 대표적인 예입니다. 또 다른 사례는 러시아 기반 사용자 계정을 정지하기 시작한 Github Enterprise입니다.

   
   

   사내 솔루션은 일반적으로 이 문제에 영향을 받지 않습니다. 한편으로는 여전히 오픈 소스 솔루션이 있습니다. 반면에 오픈 소스 모델이 항상 함께할 것이라는 보장은 없습니다. 예를 들어 Facebook이 자체 개발한 Hadoop MapReduce 스케줄링 소프트웨어 개선 사항인 Corona는 커밋할 수 없기 때문에 처음에 나타났습니다. Hadoop 업스트림을 확장하는 데 필요한 패치.

   
   

   동시에 문제의 법적 측면은 오픈 소스에 영향을 미칩니다. 예를 들어 golang 또는 k8s의 커밋에는 CLA 서명이 필요합니다. 이것이 계속 문제가 될까요?

   
   

6. NIH : 국립보건원. 예, 객관적인 이유 외에도 내린 결정이 실용적이지 않을 수도 있습니다. 그것은 최고의 NIH 증후군입니다.

   
   

   예를 들어, 배치가 컴퓨팅에 미치는 영향을 제거하기 위해 Linux 커널에서 자체 스케줄러를 만들려고 했습니다. 실제로는 좋은 결과가 나오지 않았습니다. Linux 커널의 기존 기능을 사용하여 작업을 수행할 수도 있었습니다. 그러나 인건비가 높을수록 문제를 정교화하고 해결하는 데 더 많은 노력이 들어가고 NIH 증후군에 걸릴 가능성은 낮아집니다.

   
   요약하자면 , 보시다시피 대기업을 위한 사내 솔루션이 필요한 경우가 많습니다. 대부분은 미래에 아직 성숙되지 않은 통합 글로벌 표준 솔루션과 합병될 것이고, 나머지는 역사가 될 것입니다. 어쨌든 독점 솔루션과 기성 솔루션 사이에서 결정을 내리는 것은 먼저 해당 프로젝트의 상황을 이해하고 비용을 추정하지 않고는 대답할 수 없는 어려운 질문으로 남아 있습니다.