안녕하세요 HN, Datree의 Shimon과 Eyar입니다.

제가 400명의 개발자를 위한 ironSource (NASDAQ:IS)의 인프라 엔지니어링 매니저(Engineering Manager)로 재직할 당시, 한 개발자의 실수로 인해 설정 오류(misconfiguration)가 프로덕션(production) 환경에 도달했고, 이로 인해 회사의 인프라에 심각한 문제가 발생한 적이 있습니다.

실수는 언제나 발생합니다. 우리는 실수로부터 배우고 다시는 같은 실수를 하지 않기를 바랍니다. 하지만 어떻게 하면 프로덕션 이슈의 재발을 막을 수 있을까요? 혹은 더 큰 도전 과제로서, 어떻게 하면 다음 실수를 처음부터 방지할 수 있을까요?

저희의 경우, 개발자들에게 이메일을 보내고, 위키(Wikis)를 작성하며, 미트업(meetups)과 라이브 세션을 개최하여 개발자들을 교육하려고 시도했지만, 그것만으로는 메시지를 확실히 전달하기 어렵다고 느꼈습니다. 개발자가 기억해야 할 것이 너무나 많은 상황에서, 어떻게 개발자가 Kubernetes 워크로드에 대해 liveness probe를 설정하거나 메모리 제한(memory limit)을 설정하는 것을 기억할 수 있을까요? 인프라(Infra)는 그들의 주된 관심사가 아닙니다.

오늘날 조직들은 코드형 인프라(infrastructure-as-code)의 책임을 개발자에게 위임하고 싶어 하지만, 딜레마에 직면해 있습니다. 아주 작은 설정 오류만으로도 심각한 프로덕션 이슈를 일으킬 수 있기 때문입니다. 일부 기업들은 인프라 변경 사항을 잠가두고 운영(ops) 팀이 모든 변경 사항을 검토하도록 요구하는데, 이는 양측 모두를 좌절시킵니다.

개발자들은 인프라를 기다리지 않고 기능을 출시하고 싶어 합니다. 그리고 인프라 팀은 하루 종일 설정 파일을 검토하며 설정 오류를 잡아내는 인간 디버거(human debuggers) 역할을 수행함으로써 개발자들을 "보살피는(babysit)" 일을 하고 싶어 하지 않습니다.

그것이 제가 Eyar와 팀을 이루어 Datree를 설립한 이유입니다. 우리의 미션은 엔지니어링 팀이 Kubernetes 설정 오류가 프로덕션에 도달하는 것을 방지하도록 돕는 것입니다. 우리는 개발자에게 가드레일(guardrails)을 제공하는 것이 그들의 인프라 변경 사항을 보호하고, DevOps 팀이 가장 중요한 일에 집중할 수 있도록 해준다고 믿습니다.

Datree는 Kubernetes 매니페스트 (manifests) 및 Helm 차트 (charts)에 대해 자동화된 정책 검사 (policy checks)를 실행하고, 그 안의 설정 오류 (misconfigurations)를 식별하며, 이를 수정하는 방법을 제안하는 CLI 도구 (https://github.com/datreeio/datree)를 제공합니다. 이 도구에는 프로덕션 (production)에 영향을 미칠 수 있는 가장 흔한 실수들을 다루는 수십 가지의 사전 설정된 베스트 프랙티스 (best-practice) 규칙이 포함되어 있습니다. 또한, 사용자의 정책을 위한 커스텀 규칙 (custom rules)을 작성할 수 있습니다.

저희의 내장 규칙은 수백 건의 Kubernetes 사후 분석 (post-mortems)을 기반으로 하여 리소스 제한/요청 (resource limits/requests) (MEM/CPU), liveness 및 readiness 프로브 (probes), 리소스의 레이블 (labels), Kubernetes 스키마 검증 (schema validation), API 버전 지원 중단 (deprecation) 등의 문제 예방을 보장합니다.

Datree는 중앙 집중식 정책 대시보드 (policy dashboard)를 제공하여 인프라 팀이 개발 단계 중 개발자의 컴퓨터에서 실행되는 규칙뿐만 아니라, CI/CD 프로세스 내에서도 실행될 규칙을 동적으로 구성할 수 있도록 합니다. 이 중앙 제어 지점은 회사 내의 모든 개발자 및 머신에 정책 검사를 자동으로 전파합니다.

저희는 처음에 Datree를 모든 종류의 규칙을 구성할 수 있는 범용 정책 엔진 (general purpose policy engine)으로 출시했으나 (저희의 YC 런칭 https://news.ycombinator.com/item?id=22536228 참고), 시장의 흐름에 따라 인프라 코드화 (infrastructure-as-code)와 더 구체적으로는 개발자와 인프라 팀 사이에서 가장 고통스러운 마찰 지점 중 하나인 Kubernetes에 집중하게 되었습니다.

Kubernetes 중심의 제품으로 조정하면서, 저희는 기존의 하향식 (top-down) 영업 중심 모델에서 사용자 중심의 상향식 (bottom-up) 채택 중심 모델로 피벗 (pivot)했습니다.

저희의 새로운 개발 도구는 셀프 서비스 (self-served) 방식이며 오픈 소스 (open-source)입니다. 수백 개의 기업이 Kubernetes 설정 오류를 방지하기 위해 이 도구를 사용하고 있으며, 결과적으로 GitHub에 이슈 (issues)를 제기하고 풀 리퀘스트 (pull requests)를 제출함으로써 도구의 개선을 돕고 있습니다. 저희 제품은 자기 평가 (self-evaluation)와 즉각적인 가치 전달에 매우 적합합니다. 데모 호출은 필요 없습니다. 직접 제품을 체험해 볼 수 있는 간단한 2단계 과정만 있습니다!

TechWorld with Nana에서 저희 제품에 대한 심도 있는 기술 리뷰를 진행했으며, 해당 영상은

에서 시청하실 수 있습니다.

여러분의 피드백을 기다리고 있으며, 궁금하신 점에 대해 답변해 드릴 수 있기를 기대합니다. 감사합니다 :)