DevOps Engineer/Architect로 성장을 결정짓는 핵심 역량

:money_with_wings: 커리어 성장을 결정짓는 핵심 역량

가장 성공적인 DevOps 전환은 개별 도구를 최적화하는 것이 아니라, 조직적 문제를 기술적 플랫폼으로 해결하는 데 있다.

  • 비용 최적화 및 FinOps

    클라우드 청구 구조를 이해하고, 자동화된 비용 통제 시스템을 구축하며, 인프라 투자에 대한 비즈니스 근거를 만드는 역량이다. 최적화를 시도하기 전에 리소스 모니터링과 비용 귀속(attribution)부터 시작하라.

  • 플랫폼 엔지니어링

    좋은 프랙티스가 기본값이 되는 내부 플랫폼을 설계한다. 신규 배포는 최소 리소스 할당으로 시작하고, Vertical Pod Autoscaler로 최적화 추천을 제공한다. 팀별 실시간 지출을 보여주는 비용 대시보드를 구축한다.

  • 멀티 테넌트 보안

    운영 부담 없이 스케일 가능한 보안 격리 체계를 구축한다. 네임스페이스 쿼터, 네트워크 정책, Kyverno 같은 정책 엔진을 계층적으로 적용하고, 미리 구성된 보안 템플릿을 활용해 셀프 서비스 프로비저닝을 가능하게 한다.

  • Lean Observability (효율적 관측성)

    불필요한 리소스 소모 없이 비즈니스 가치에 집중하는 모니터링 체계를 구현한다. 중요한 지표만 측정하고, 샘플링을 지능적으로 적용하며, 데이터를 적극적으로 아카이빙한다. 모니터링 스택의 클러스터 오버헤드를 15% 이하로 유지하는 것을 목표로 한다.

:money_with_wings: 진짜로 스케일에서 발생하는 문제들

  • 비용 최적화의 함정

    한 팀은 애플리케이션을 위해 10TB의 프리미엄 스토리지를 요청했다. 8년이 지난 지금, 실제 사용률은 0.7%. 월 비용은 $3,200 — 사실상 빈 디스크를 유지하는 데 들어가는 돈이다. 또 다른 팀은 메모리 누수를 고치지 않고 분기마다 RAM 용량을 늘리는 “임시방편”을 택했다. 6개월간의 이런 “빠른 해결책” 비용이 성능 엔지니어 1명을 고용하는 비용보다 더 커졌다.

  • 마이그레이션 조정 문제

    2,500개의 마이크로서비스를 EC2에서 EKS로 무중단 마이그레이션하는 건 기술적으로 복잡하지 않다. 서비스 메시 라우팅과 점진적 트래픽 전환은 이미 잘 문서화된 패턴이다.
    진짜 문제는 53개 개발팀, 12개 타임존, 36개의 “업무시간 중 다운되면 안 되는 핵심 서비스”를 조율하는 일이다.

  • 멀티 테넌트 보안

    운영 부담 없이 스케일링 가능한 격리(아이솔레이션) 제어를 설계해야 한다. 네임스페이스 쿼터, 네트워크 정책, Kyverno 같은 정책 엔진을 계층적으로 적용하고, 미리 구성된 보안 템플릿을 통해 셀프 서비스 프로비저닝을 제공한다.

  • 관측성(Observability) 비용의 함정

    대부분의 팀은 Prometheus, Grafana, Jaeger, Elasticsearch, Fluentd를 모두 설치한다. 6개월 후, 모니터링 인프라가 실제 애플리케이션보다 더 많은 리소스를 먹는다.
    어느 팀의 경우, 애플리케이션은 3코어/6GB RAM을 쓰는 반면, 모니터링 스택은 12코어/48GB RAM을 사용하고 있었다.

[출처] https://medium.com/@osomudeyazudonu/the-hardest-things-ive-implemented-in-devops-1958328804fe

3 Likes

모니터링 스택에 서비스보다 많은 리소스를 먹는게 정말 공감됩니다. 핵심은 발빠르게 대응할 수 있는 장애 대응 문화와 프로세스를 설립하는 것이 더 선행되어야 하는데 기술에 매몰되다 보면 발생할 수 있는 문제 같아요.

3 Likes