Kubernetes에서의 종속성 관리

Elasticsearch를 직접 체험해 보세요. Elasticsearch Labs 리포지토리의 샘플 노트북을 살펴보거나, 무료 클라우드 체험을 시작해 보세요. 지금 바로 로컬 컴퓨터에서 Elastic을 사용해 보셔도 좋습니다.

다음은 업데이트를 자동화하고 일반적인 취약성 및 노출(CVE)을 신속하게 해결하며 수천 개의 리포지토리에 새 패키지 버전을 효율적으로 전파하기 위해 Kubernetes, Argo Workflows, Argo Events 및 Renovate CLI로 셀프 호스팅된 종속성 관리 플랫폼을 구축한 방법입니다.

Elastic의 종속성 관리

Elastic에서는 비공개 및 공개를 포함하여 수백 개, 심지어 수천 개의 리포지토리를 관리해야 합니다. 중요한 CVE가 발견되면 여러 질문에 대한 즉각적인 답변과 조치가 필요합니다. '어떤 리포지토리가 취약한가?', '얼마나 빨리 패치를 적용할 수 있는가?' 등이 있습니다. 보안 문제 외에 '수작업에 너무 많은 시간을 들이지 않고 새 패키지 버전의 릴리스를 해당 패키지에 의존하는 모든 리포지토리에 신속하게 전파하는 방법은 무엇인가?'라는 생산성 관련 질문도 제기됩니다.

종속성 관리 방법을 모색하게 된 초기 계기는 CVE 감소를 위해 자동화된 업데이트와 함께 안전한 기반을 구축해야 하는 필요성 때문이었습니다. 종속성 관리 솔루션을 신중하게 검토한 후, 우선 자체 호스팅된 인프라 구축에 착수했습니다. Mend Renovate Community 셀프 호스팅 에디션을 실행하기 위해 자체 Kubernetes 클러스터를 사용하고 있었습니다. 사용자들이 셀프 서비스 방식으로 접근할 수 있는 종속성 관리 플랫폼을 제공하는 것이 아이디어의 핵심이었습니다.

초기 실험이 성공적이었기 때문에 점점 더 많은 팀이 플랫폼에 온보딩하여 일상적인 리포지토리의 수명 주기에서 업데이트 및 CVE 패치에 이를 사용하기 시작했습니다. 이 과정이 너무 빨리 진행되어 곧 자체 호스팅 설치 용량의 한계에 도달했습니다.

과제: 대규모 조직에서 수많은 리포지토리를 관리할 때, 종속성 관리 플랫폼을 어떻게 확장할 수 있을까요?

기존 종속성 관리 플랫폼은 한 번에 하나의 리포지토리만 처리할 수 있었고, 수많은 리포지토리로 인해 순차적 처리 모델로는 대처할 수 없었습니다. 우리는 종속성 관리 도구의 단일 인스턴스로 점점 커지는 리포지토리 목록을 처리할 수 있다는 생각 자체에 문제가 있다는 것을 이미 인식하고 있었습니다. 리포지토리는 대기열에서 기다렸고, 때로는 몇 시간이 걸렸습니다. 매일 50% 이상의 리포지토리가 처리되지 않았습니다. 즉, 리포지토리의 50% 이상이 되기까지 24시간 이상 대기해야 했습니다.

대규모 리포지토리는 방대한 코드베이스와 여러 개의 열린 PR로 인해 더 큰 병목 현상을 일으켰습니다. GitHub 웹훅 이벤트는 시퀀스를 중단시켰습니다. Automerge는 스캔 타이밍을 예측할 수 없기 때문에 신뢰할 수 없었습니다. 사용자들에게 스캔 빈도에 대해 약속했지만, 그 약속을 지키지 못했습니다.

자체 구축 결정: Elastic 고유의 확장성 및 보안 요구 사항 충족

Mend의 Renovate Self-Hosted Enterprise 셀프 호스팅 에디션을 포함한 상용 옵션을 고려하면서, Elastic 내부적으로는 몇 가지 주요 이니셔티브를 강화하고 있었습니다.

Elastic의 타협할 수 없는 특정한 요구 사항을 충족할 수 있는 심도 깊은 맞춤형 솔루션만이 유일한 해결책이라는 인식에 따라 자체 플랫폼을 구축하기로 결정했습니다.

1. 내부 개발자 플랫폼 투자: 당시 내부 개발자 플랫폼에 대해 이미 대규모 투자를 시작한 상태였습니다. 각 서비스를 여기에 조화시키는 방식에 대해 논의하고 설계했습니다. 즉, 자체적으로 만든 종속성 관리 플랫폼의 규칙과 관행을 시험적으로 적용해 보고자 했습니다. 게다가 새로운 가이드라인이 시행될 예정이었기 때문에, 그 전에 플랫폼을 설계하고 싶었습니다.
2. 네이티브 통합 및 워크플로우 맞춤 설정: 내부 도구 및 내부 프로세스와의 간편한 통합이 필요했습니다. 예를 들어, 서비스 카탈로그(Backstage)를 사용하여 구성을 코드로 중앙 집중화하고자 했습니다. Backstage의 사용에 관한 특정 요구 사항이 있었으며 플랫폼이 이러한 요구 사항과 호환되기를 원했습니다. 따라서 Renovate 셀프 호스팅 API를 Backstage 자동화와 함께 사용하는 것이 가능하지만, 이것으로는 내부 프로세스를 완전히 지원할 수 없습니다.
3. Elastic에 특화된 심층 방어 보안: 엄격한 보안 규정 준수를 위해서는 에코시스템에 맞춘 맞춤형 보안 메커니즘이 필요했습니다. 우리는 "비인간 ID"의 사용을 강화하기 위해 노력하고 있었습니다. 이러한 액세스 강화 방식으로 인해 비표준적인 GitHub 인증 수단은 이 내부 구현을 지원하지 않는 기성 도구에서는 작동하지 않았습니다. 워크플로우에는 부모-자식 워크플로우 비밀 암호화 패턴 구현과 일시적인 일회성 GitHub 토큰 사용이 포함되었습니다. 자체 구축이 이러한 고유한 보안 계층을 내장하고 복잡한 멀티클라우드 환경 전반에 걸쳐 공격 표면을 최소화하는 유일한 현실적인 방법이었습니다.

해결책: 종속성 관리를 위한 워크플로우 오케스트레이션

솔루션은 이미 사용 중인 종속성 관리 도구를 대체하거나 다른 솔루션을 찾지 않고 이를 기반으로 구축한다는 데서 출발했습니다. 이는 가능성의 징후를 보였으며, 조직 전반에 걸쳐 다양한 요구에 맞추는 유연성이 중요했습니다. 다양한 솔루션을 고려했으며, 우리가 충족해야 할 중대하고 때로는 특별한 요구 사항을 토대로 결정을 내릴 수 있었습니다. 각 리포지토리가 독립적으로 처리되어 병목 현상이 발생하지 않고 성장을 위한 기반을 제공할 수 있도록 신뢰할 수 있고 확장성 있는 종속성 관리 플랫폼을 구축하기로 결정했습니다.

세 가지 핵심 원칙에 따라 플랫폼을 설계했습니다.

1. 병렬 처리

모든 리포지토리는 자체 종속성 관리 처리 환경을 갖습니다. 더 이상 대기열이 없습니다. 동시성은 사용하는 리소스의 수에 의해서만 제한됩니다. 또한 GitHub 속도 제한을 피하기 위해 스마트 분산 스케줄링을 적용했습니다.

2. 셀프 서비스 가능

서비스 카탈로그(백스테이지)를 사용하여 새로운 리포지토리를 자동으로 온보딩하고 관리합니다. 자체 리소스 정의를 사용하여 최종 사용자에게 리포지토리 처리 빈도, 스케줄에 할당할 리소스 수, 그리고 어떤 이유로든 처리를 끌지 아니면 다시 켤지 선택할 수 있는 옵션을 제공합니다. 사용자 요구 사항이 발전하고 새로운 설치 환경에 익숙해짐에 따라 이러한 방식으로 더 많은 옵션을 추가할 계획입니다.

3. 비밀 범위 축소 및 네임스페이스 격리

보안 강화를 위해, 각 워크플로우 시작 시 생성되는 임시 GitHub 토큰을 종속성 관리 포드에 제공합니다. 그뿐만 아니라, 필요한 비밀 키만 제공받을 수 있도록 워크로드를 특정 네임스페이스로 격리합니다. Kubernetes RBAC를 사용하여 각 종속성 관리 워크플로우에서 액세스할 수 있는 비밀 정보를 제어합니다. 또한 GitHub 토큰을 부모 워크플로우에서 자식 워크플로우로 전파할 때 암호화를 사용합니다.

Kubernetes를 사용하여 플랫폼을 재구축했으며, Kubernetes의 강력한 기능을 활용해 Argo Workflows는 프로세스 로직을 강화하고, Renovate CLI는 한 번에 하나의 리포지토리를 스캔하고 처리하도록 설정되었습니다.

장점: 검증된 오픈 소스 프로젝트를 독창적인 방식으로 활용하여 모든 프로젝트에 대해 새로운 작동 예제를 제공하는 동시에, 개발 속도를 높이고 팀의 CVE 감소를 강화합니다.

종속성 관리 아키텍처: 4개의 마이크로서비스

이 플랫폼은 맞춤 제작된 4가지 구성 요소로 이루어져 있습니다.

워크플로우 오퍼레이터(Go/Kubebuilder)

3가지 맞춤형 리소스 정의(CRD)를 통해 워크플로우 수명 주기를 관리하는 Kubernetes Operator:

• RepoConfig CRD: 리포지토리 구성을 위한 단일 정보 소스입니다.

다음은 오퍼레이터에서 RepoConfig가 정의되는 방식입니다.

다음은 RepoConfig 인스턴스의 모습입니다.

• 부모 CRD: 예약된 스캔을 위한 CronWorkflows를 관리합니다.

부모 컨트롤러의 조정 루프 내에서 워크플로우 설정이 생성되고 최신 상태로 유지되거나, 필요한 경우 삭제되는지 확인합니다.

먼저 워크플로우에 대한 몇 가지 전역 설정을 가져옵니다.

유사한 워크플로우가 동시에 실행되는 것을 방지하기 위해 mutex configmap이 최신 상태인지 확인합니다.

그런 다음 CronWorkflows와 워크플로우 템플릿을 생성하거나 업데이트하는 구조체인 Workflow Manager를 생성합니다.

• 자식 CRD: 리포지토리별 리소스로 워크플로우 템플릿을 관리합니다.

자식 컨트롤러는 부모와 유사한 조정 의무를 가지고 있지만, 이번에는 부모 워크플로우에 의해 트리거될 자식 네임스페이스의 워크플로우 템플릿에 대한 책임이 있습니다.

멀티 컨트롤러 패턴은 명확한 분리를 제공합니다. RepoConfig 컨트롤러는 온보딩/오프보딩을 처리하고, 부모 컨트롤러는 스케줄링을 관리하며, 자식 컨트롤러는 실행 템플릿을 처리합니다.

GitHub Events Gateway(Go)

GitHub 웹훅을 수신하고 서명을 확인하고 조직/리포지토리별로 필터링한 후 Argo Events로 라우팅하는 안전한 웹훅 프록시입니다. 종속성 대시보드 상호 작용, PR 이벤트 및 패키지 업데이트에 반응하는 10개의 서로 다른 센서를 구축했습니다.

이 게이트웨이는 다음을 통해 GitHub 앱과 통합할 수 있도록 지원합니다.

• 보안을 위해 수신되는 GitHub 웹훅 서명을 확인합니다.
• 유효한 이벤트를 모든 관련 헤더 및 인증 정보와 함께 Argo Events EventSource로 전달합니다.
• 또한 EventSource에 authSecret을 구성하고 전달된 요청의 Bearer 헤더로 이를 제공합니다.
• 로깅, 메트릭 및 재시도 로직을 제공합니다.

각 GitHub 이벤트 요청에 대해 다양한 검증을 수행합니다.

일부 HTTP 속성이 있는지 확인합니다:

또한 각 요청의 서명과 그 구성도 검증합니다.

마지막으로 이벤트 유형에 따라 Argo Events로 라우팅됩니다.

Argo Events 측에서는 10개의 센서가 새로운 이벤트를 감지하기 위해 Argo Events EventBus를 모니터링합니다.

그 후 스크립트는 각 센서의 논리를 적용합니다:

Backstage Syncer(Go)

이 작업은 서비스 카탈로그(Backstage)에서 리포지토리 실제 리소스 엔티티를 폴링하고, 이를 RepoConfig CRD로 변환하며, 플랫폼을 구성 변경 사항과 동기화된 상태로 유지합니다. 변경 사항은 3분 이내에 적용됩니다.

마지막으로 해당 데이터를 RepoConfig 인스턴스에 기록합니다.

워크플로우 베이스(혼합: JavaScript, Go, Helm)

기반 레이어에는 Helm 차트, JavaScript 구성, 암호화 지원 기능을 갖춘 Renovate CLI용 Go 래퍼, 그리고 Alpine 패키지용 맞춤형 APK 인덱서가 포함되어 있습니다.

셀프 서비스 구성

팀은 Backstage를 통해 리포지토리를 선언적으로 구성합니다.

리소스 그룹은 리포지토리 크기에 따라 CPU와 메모리를 할당합니다.

• SMALL: 500m CPU, 1Gi 메모리.
• MEDIUM: 1000m CPU, 2Gi 메모리.
• LARGE: 2000m CPU, 4Gi 메모리.

구성은 버전이 제어되고 감사 가능하며 자동으로 적용됩니다.

부모-자식 패턴

실행 모델은 부모-자식 워크플로우 패턴을 사용합니다.

• 부모 워크플로우: 예약된 시간에 실행되는 경량 CronWorkflow입니다. 비밀 정보를 암호화하고, 검사 실행 여부를 결정하며, 구성 정보를 자식 워크플로우에 전달합니다.
• 자식 워크플로우: Renovate CLI가 실행되는 임시 포드입니다. 동적으로 리소스를 할당하고, 격리된 상태에서 비밀 정보를 해독하며, 완료 후 종료합니다.

이러한 분리는 보안(부모 레벨에서 암호화된 비밀), 리소스 최적화(부모 레벨에서 최소한의 리소스 사용), 그리고 확장성(자식 레벨에서 병렬 실행)을 제공합니다.

결과

성능 변환

• 이전: 한 번에 하나의 리포지토리만 처리하고, 일부 리포지토리는 하루 이상 처리되지 않기도 했으며, 하루에 1,000건 미만의 스캔이 처리되었습니다.
• 이후: 100개 이상의 동시 스캔, 하루에 보통 8,000개 스캔, 최대 10,000개의 기록된 스캔이 이루어지며, 사용 가능한 리소스의 양과 GitHub 속도 제한을 처리하는 방법에 의해서만 제한됩니다.

비용 효율성

이상하게 들릴지 모르지만, 하루에 8,000개의 포드를 실행하는 것이 동일한 결과를 달성하기 위해 하나의 장기 실행 포드를 사용하는 것보다 훨씬 저렴할 수 있습니다.

이전 설정에서는 단일 인스턴스를 운영했고, 양호한 날에는 500~600번의 스캔을 수행했습니다. 또한, 서로 다른 종류의 리포지토리가 같은 포드에서 실행되기 때문에 가장 큰 리포지토리에 맞게 포드 크기를 조절해야 했습니다. 이는 포드용 CPU 8개와 16G 메모리를 사용하는 현재보다 훨씬 규모가 커질 수 있습니다.

현재의 일일 출력을 충족하려면 단일 포드는 12일 동안 실행되어야 합니다. 12일 동안 실행되는 단일 포드의 비용을 매일 실행되는 8,000개의 “MEDIUM” 크기 포드와 비교하면, 동일한 스캔 출력에서 새로운 설계가 훨씬 더 효율적입니다.

이제 워크로드 기본값이 "SMALL"로 설정되어 있으며, 대다수가 0.5 CPU와 1G RAM으로 성공적으로 실행되고 소수만 중간, 대형으로 변경해야 하는 경우를 생각해 보겠습니다. 작업 부하의 60%가 "SMALL", 30%가 "MEDIUM", 그리고 10%가 "LARGE"에서 실행된다면 어떻게 되는지 살펴봅시다. 이는 실제 상황에 더 가깝습니다.

동일한 출력을 얻을 때 현재 설정이 훨씬 더 비용 효율적이라는 것을 알 수 있습니다.

보안 강화

• 일시적인 GitHub 토큰(노출 시간이 일 단위가 아닌 분 단위)
• 역할 기반 액세스 제어(RBAC) 경계를 사용한 네임스페이스 격리
• 부모 워크플로우에서 저장 데이터 비밀 암호화
• 직접 볼트 액세스 제거

예측 가능한 성능

스캔 빈도가 보장되어 마침내 서비스 수준 목표(SLO)를 설정할 수 있습니다. Automerge는 안정적으로 작동합니다. 팀은 플랫폼이 약속대로 실행될 것이라고 신뢰합니다.

주요 설계 결정 사항

다음은 플랫폼의 모습을 형성하는 데 중요한 역할을 한 몇 가지 주요 설계 결정 사항입니다.

• 부모-자식 워크플로우를 사용하는 이유는 무엇인가요?

심층 방어 전략을 실행하기 위해 이 패턴을 채택했습니다. 중요한 자격 증명(예: GitHub 앱 비밀)을 잠긴 전용 네임스페이스로 제한함으로써 임시 실행 포드가 민감한 데이터에 임의로 액세스할 수 없도록 하기 위해 RBAC를 사용합니다. 최근의 공급망 취약성(예: "Shai Hulud" 지속적 통합/지속적 배포[CI/CD] 공격)은 자격 증명 저장소에서 동적 스크립트를 실행하는 런타임 환경을 격리하는 것이 얼마나 중요한지를 보여주었습니다.

동시에 이러한 분리를 통해 세분화된 리소스 최적화가 가능합니다. "부모" 워크플로우는 최소한의 풋프린트로 가벼운 오케스트레이터 역할을 하는 반면, "자식" 워크플로우는 컴퓨팅 집약적인 종속성 스캐닝을 처리합니다. 이러한 분리는 수명 주기 관리를 단순화하여 각 계층에 별개의 조정 로직을 적용할 수 있게 하므로, 사용자는 실행 매개 변수(자식)에 대한 제어권을 갖는 반면 관리자는 스케줄링 및 보안 인프라(부모)에 대한 관리 제어권을 유지할 수 있습니다.

• 셀프 서비스를 사용하는 이유는 무엇인가요?

팀이 리포지토리 구성의 병목 현상이 되지 않도록 하는 것은 중요한 요구 사항이었습니다. 다양한 사용 사례를 지원할 수 있는 확장 가능한 셀프 서비스 플랫폼을 구축하는 것이 목표였습니다. 우리는 엄청난 양의 리포지토리를 고려할 때, 모든 구성 변경에 대해 게이트키퍼 역할을 하는 것은 지속 불가능하다는 것을 인식했습니다. 대신, 사용자가 "열차"를 운전할 수 있도록(실행 및 맞춤화) "레일"(인프라 및 가드레일)을 제공한다는 지원 철학을 채택했습니다. 이와 같이 팀 자율성으로 전환하여 사용자가 시스템을 특정 운영 요구 사항에 맞게 조정할 수 있도록 하면 생산성이 크게 향상된다고 믿습니다.

• Kubernetes Operator 패턴을 사용하는 이유는 무엇인가요?

위에서 언급했듯이, 기본적인 설계 원칙은 플랫폼이 완전히 셀프 서비스 가능하도록 하는 것이었습니다. 사용자 의도(스캔 전환, 일정 주기 조정, 런타임 리소스 제한 조정 등)를 파악하고 변경 사항을 기본 워크플로우에 즉시 전파하려면 자동화된 메커니즘이 필요했습니다. 또한 향후 요구 사항을 예상하여 시스템은 쉽게 확장 가능해야 했습니다.

이를 위해 맞춤형 종속성 관리 Kubernetes Operator를 개발했습니다. CRD를 구성 인터페이스로 사용함으로써, Kubernetes 네이티브 조정 루프를 구축했습니다. 이 오퍼레이터는 사용자가 정의한 원하는 상태를 지속적으로 모니터링하고, 워크플로우 인프라에 필요한 업데이트를 자동으로 오케스트레이션합니다. 이를 통해 플랫폼 로직이 모든 복잡한 작업을 백그라운드에서 처리하므로 이벤트 기반의 원활한 작동이 보장됩니다.

• GitHub Events Gateway를 설계하는 이유는 무엇인가요?

플랫폼의 응답성을 위해 이벤트 기반 아키텍처 (EDA) 채택이 필수적이었습니다. CronWorkflows는 신뢰할 수 있는 기준 일정을 제공했지만, 사용자가 대시보드를 통해 수동으로 스캔을 트리거하는 등 임시 실행을 처리할 수 있는 민첩성이 필요했습니다. 이를 위해서는 페이로드 무결성을 검증하고 요청을 지능적으로 라우팅할 전용 수집 게이트웨이가 필요했습니다.

우리는 Argo용 기본 GitHub EventSource를 포함한 기존 솔루션을 평가했지만, 운영 오버헤드 및 엄격한 GitHub API 할당량(예: 리포지토리당 웹훅 제한)과 관련하여 상당한 위험이 있음을 확인했습니다. 결과적으로 이러한 제한으로부터 인프라를 분리하기 위해 맞춤형 게이트웨이를 구축했습니다.

무엇보다도, 이 게이트웨이는 마이그레이션 중에 전략적인 트래픽 제어 지점 역할을 했습니다. 이는 기존 시스템에서 새로운 인프라로 점진적이고 세분화된 배포(트래픽 전환)를 수행할 수 있도록 스위치 역할을 했습니다. 이를 통해 수천 개의 리포지토리를 온보딩하는 과정이 "빅뱅" 전환 방식이 아닌 통제되고 위험 없는 프로세스로 수행되었습니다.

얻은 교훈

우리가 얻은 몇 가지 교훈은 Elastic 소스 코드와 밀접한 관련이 있습니다.

1. 고객 우선: 플랫폼은 사용자를 위해 구축됩니다. 따라서 사용자의 요구를 최우선으로 고려하는 것이 중요합니다. 이를 통해 플랫폼을 효율적으로 설계된 인프라와 애플리케이션으로 형성하여 사용자와의 마찰을 줄이고, 플랫의 확장을 단순화하며 원활한 도입일 촉진할 수 있습니다.
2. 공간, 시간: 저항이 가장 적은 경로는 때때로 불안정한 상황으로 이어지곤 합니다. 처음에는 기존의 순차적 처리 모델을 최적화하려고 했지만, 이것으로 문제를 해결할 수 없었습니다. 오히려 더 많은 복잡성과 미해결 문제를 초래했습니다. 병렬 처리로 플랫폼을 재설계하기로 한 과감한 결정은 상당한 사전 노력을 필요로 했습니다. 하지만 결과적으로 플랫폼의 지속 가능한 성장을 위한 길을 열었고, 지루한 일상적인 관리 업무를 사실상 제거했습니다.
3. IT, 종속성: 플랫폼은 단독으로 운영될 수 없습니다. 플랫폼의 성공은 더 넓은 에코시스템과 얼마나 잘 통합되는지에 달려 있습니다. 이 사례에서는 Backstage와의 통합이 매우 중요했습니다. 원활한 서비스 온보딩을 위한 정보 소스 역할을 하기 때문입니다. 마찬가지로 Artifactory에 연결하여 개인 패키지 업데이트를 효율적으로 관리할 수 있게 되었습니다. 그 외에도 필수 통합 목록은 계속 이어집니다.
4. 발전, 단순한 완벽함: 구현 과정 전반에 걸쳐 초기 가정에 대해 지속적으로 엄격한 테스트를 수행하고 새로운 장벽이 나타나면 이에 맞게 조정했습니다. 완벽주의에 빠지기보다는 반복 접근 방식을 채택하여 과제를 하나씩 해결하고 실제 환경에 맞게 마이그레이션 전략을 조정했습니다.

그럼 이제 무엇을 해야 할까요?

플랫폼 제공은 더 의미 있는 작업을 가능하게 하여 플랫폼의 UX와 효율성을 향상시키는 데 도움이 됩니다. 몇 가지 예는 다음과 같습니다.

• 자동 병합 도입을 늘리고 가드레일 구축

자동 병합 기능은 지루한 수동 작업을 없애 팀의 작업 속도를 크게 향상시킵니다. 하지만 속도 향상으로 인해 보안이 훼손되지 않도록 엄격한 가드레일을 마련해야 합니다.

• 최종 사용자 경험에 대한 통합 가시성 향상

로드맵의 중요한 우선순위는 플랫폼 수준뿐만 아니라 특히 최종 사용자의 관점에서 통합 가시성을 강화하는 것입니다. 인프라 메트릭을 파악하는 것은 간단하지만, 실제 사용자 경험을 이해하려면 더 심층적인 인사이트가 필요합니다. 우리는 사용자 불만으로 이어지기 전에 원격 측정 데이터를 통해 문제점과 성능 문제를 탐지할 수 있도록 사용자 중심의 핵심 성과 지표(KPI)를 정의하고 있습니다.

• 장벽을 제거하여 도입 촉진

앞으로 최우선 과제는 플랫폼 도입을 방해하는 모든 장벽을 파악하고 제거하는 것입니다. 새로운 통합 기능을 개발하든 특정 기능 세트를 배포하든, 데이터 기반 계획 수립에 전념합니다. 확장성을 고려하여 설계된 플랫폼을 성공적으로 구축했으며, 이제 그 잠재력을 극대화하는 데 집중하고 있습니다.

더 큰 그림

종속성 관리 워크플로우 프로젝트는 더 광범위한 원칙을 제시합니다. 오픈 소스 도구를 기본 배포 모델 이상으로 확장해야 할 때 Kubernetes 네이티브 패턴이 해결책을 제시한다는 것입니다.

수용함으로써:

• 구성용 CRD
• 수명 주기 관리를 위한 오퍼레이터
• 응답성을 위한 이벤트 중심 아키텍처
• 배포용 GitOps

관리하는 리포지토리 수와 관계없이 확장 가능한 오케스트레이션을 구축했습니다. 하나의 리포지토리를 스캔하는 성능은 100개를 관리하든 1,000개를 관리하든 동일합니다.

중요한 CVE가 발표되면 이제 몇 시간이 아니라 몇 분 만에 답변을 받을 수 있습니다. 이것이 병목 현상과 경쟁 우위의 차이입니다.

감사의 말씀

이 플랫폼은 뛰어난 오픈 소스 도구를 기반으로 구축되었습니다.

• Kubebuilder: 워크플로우를 부트스트랩하고 오케스트레이션하는 Kubernetes Operator를 시작하는 데 사용한 오픈 소스 프레임워크입니다. [1][2]
• Backstage: 서비스 카탈로그를 구축하는 데 신뢰할 수 있는 정보 소스로 사용한 오픈 소스 프레임워크입니다. [1][2]
• Argo Workflows 및 Argo Events: 복잡한 프로세스를 오케스트레이션하고 이벤트에 기반한 동적 처리를 추가하는 데 사용한 오픈 소스 제품군입니다. [1][2][3][4]
• Renovate CLI: 리포지토리를 처리하는 오픈 소스 종속성 관리 도구입니다. [1][2]

* AWS Fargate 가격 모델이 단일 포드의 비용을 참조하는 데 사용되었지만, 워크로드가 반드시 AWS에서 실행되는 것은 아니며 완전한 Kubernetes 클러스터에서 실행되고 있습니다.