▲

스타트업에서 4년간 인프라를 운영하며 좋았던/후회하는 (거의) 모든 인프라 결정들

 (cep.dev)
87P by xguru 2달전 | favorite | 댓글 4개
  • 모든 선택에 대해서 Endorse(지지)와 Regret(후회)로 표시

AWS 선택

  • AWS 대 Google Cloud 선택: AWS를 선택한 것을 지지함. AWS는 고객에 중점을 두고 있음. Google Cloud는 로봇과 자동화에 의존하는 느낌이 있음.
  • EKS: EKS 사용을 지지함. EKS는 AWS 서비스와의 깊은 통합을 제공하며, Kubernetes도 많은 방면에서 따라잡았음(외부dns를 사용하여 Route53과 통합하는 등)
  • EKS 관리형 애드온: EKS 관리형 애드온 사용을 후회함. 설치를 커스터마이즈해야 할 필요가 있었고, helm 차트로 전환한 이후 더 나은 운영을 경험

데이터베이스 및 캐싱

  • RDS: RDS 사용을 지지함. 데이터는 인프라의 가장 중요한 부분이며, RDS 사용 비용은 가치가 있음
  • Redis ElastiCache: Redis 사용을 지지함. Redis는 캐시 및 일반적인 사용에 매우 효과적임
  • ECR: quay.io에서 ECR로 이전한 것을 지지함. ECR은 더 안정적이고 권한 통합이 더 깊음

네트워크 및 지원

  • AWS VPN: AWS VPN 사용을 지지함. VPN은 설정 및 이해가 매우 간단함. VPN 액세스를 관리하기 위해 Okta를 사용하고 있으며 매우 좋은 경험을 줌
  • AWS 프리미엄 지원: 후회함. AWS 프리미엄 지원 비용이 매우 비싸며, 내부 AWS 지식이 부족하지 않다면 그 가치가 없음
  • Control Tower Account Factory for Terraform: AFT 통합을 지지함. 계정 생성을 자동화하고 태그 표준화에 도움이 됨

프로세스 자동화

  • 슬랙 봇을 이용한 사후 분석 자동화: 사후 분석 프로세스 자동화를 지지함. 사람들이 사후 분석을 작성하도록 유도하는 데 도움이 됨
  • PagerDuty의 사고 템플릿 사용: 사고 발생 시 템플릿 사용을 지지함. Notion의 유연성을 활용하여 약간의 맞춤화가 가능함
  • PagerDuty 티켓 정기 검토: 경보 설정을 정기적으로 검토하는 것을 지지함. 중요하지 않은 경보도 무시되지 않도록 관리함
  • Datadog 또는 PagerDuty에서 사후 분석 관리: 사후 분석을 위한 통합된 관리 도구 사용을 후회함. 둘 다 사후 프로세스를 맞춤화하기가 어려움. Notion과 같은 강력한 도구를 사용하는 것이 더 낫다고 생각함

기타

  • 월간 비용 추적 회의: SaaS 비용을 검토하는 월간 회의를 지지함. 비용이 적절한지 확인하고 필요한 조치를 취함. AWS에서는 항목을 태그별로 그룹화하고 계정별로 구분. AWS에만 그치지 말고 회사가 가지고 있는 모든 주요 지출 지출원을 살펴보는 것을 추천
  • FaaS를 더 많이 사용하지 않음: GPU 작업에는 FaaS 옵션이 없어서 FaaS를 완전히 사용할 수 없었음을 후회함. 많은 CPU 작업은 FaaS로 처리할 수 있었을 것임. Lambda의 또 다른 숨겨진 이점은 높은 정확도로 비용을 추적하는 것이 매우 쉽다는 것
  • GitOps: GitOps 사용을 지지함. 인프라의 많은 부분에 GitOps를 사용하고 있으며, 도구 개발에 투자하여 배포 상태를 이해하는 데 도움을 줌
  • 팀 효율성 우선: 팀의 효율성을 높이는 것을 우선시하는 것을 지지함. 자동화나 문서화에 시간을 투자하는 것을 후회한 적이 없음
  • 여러 애플리케이션이 하나의 데이터베이스 공유: 여러 애플리케이션이 하나의 데이터베이스를 공유하는 것을 후회함. 이로 인해 여러 문제가 발생함

SaaS 도입

  • 아이덴티티 플랫폼 늦게 도입: Google Workspace를 사용하여 권한을 할당하는 데 사용했으나, Okta와 같은 아이덴티티 솔루션을 더 일찍 도입했어야 함을 후회함. Okta는 통합이 잘 되어 있으며, 보안 및 규정 준수 문제를 해결해 줌
  • Notion: 문서 작성을 위해 Notion 사용을 지지함. Notion은 훌륭한 선택이었으며 과거에 사용했던 것(Wikis, Google Docs, Confluence 등)보다 훨씬 쉽게 작동. 페이지 조직을 위한 데이터베이스 개념이 유용함
  • Slack: Slack 사용을 지지함. 의사소통을 위한 기본 도구로서 효과적임

개발 도구 및 서비스

  • JIRA에서 Linear로 이동: JIRA 대신 Linear 사용을 지지함. JIRA는 너무 복잡하고 무겁다고 생각함
  • Terraform Cloud 사용 안 함: Terraform Cloud 비용을 정당화할 수 없어서 사용하지 않음을 후회하지 않음. Atlantis로 이동했으며, 필요한 자동화를 CI/CD 파이프라인에 추가함
  • GitHub Actions for CI/CD: GitHub Actions 사용을 **어느 정도 지지(Endorse-ish)**함. 마켓플레이스의 액션과 문법이 사용하기 쉬움. 자체 호스팅 워크플로우에 대한 지원이 제한적임을 단점으로 봄

기술 선택

  • Datadog: Datadog 사용을 후회함. 비용이 매우 비싸며, Kubernetes 클러스터와 AI 회사에 대한 비용 모델이 부적절함
  • PagerDuty: PagerDuty 사용을 지지함. 제품이 좋고 가격이 적절함
  • 스키마 마이그레이션 by Diff: 스키마 마이그레이션을 위한 도구 사용을 어느 정도 지지함. 데이터가 중요하고 스키마 마이그레이션은 위험할 수 있음
  • Ubuntu for dev servers: 개발 서버로 Ubuntu 사용을 지지함. 잘 지원되고 필요한 대부분의 패키지를 가지고 있음
  • AppSmith: 내부 엔지니어를 위한 프로세스 자동화에 AppSmith 사용을 지지함. 자체 호스팅하며, 충분히 만족스러움. 처음에는 retool을 사용하여 더 깊은 통합을 모색했지만 당시에는 단지 몇 가지 통합에 불과한 가격을 정당화할 수 없었음
  • helm: Helm v3 사용을 지지함. CRD 배포와 개발자 교육에 문제가 있지만, Kubernetes 객체를 패키징하고 배포하는 데 충분히 좋음
  • helm 차트 in ECR(oci): OCI 저장소에 helm 차트를 저장하는 것을 지지함. S3와 플러그인을 사용한 이전 방식보다 문제가 없음
  • bazel: bazel에 대해 확신이 없음. Go 서비스 배포에는 과도한 것 같고, GitHub Actions가 더 많은 엔지니어가 사용하기 쉬움
  • 오픈 텔레메트리 사용 안 함: DataDog API를 직접 사용하여 메트릭을 전송하는 것을 후회함. 오픈 텔레메트리 사용을 시작부터 권장함
  • dependencyabot 대신 renovatebot 선택: 종속성을 최신 상태로 유지하는 것에 대해 더 일찍 생각했어야 함을 후회함. Renovatebot은 맞춤화가 가능하지만 설정과 디버깅이 복잡함
  • Kubernetes: Kubernetes 사용을 지지함. 장기 실행 서비스를 호스팅할 수단이 필요하며, Kubernetes는 인기 있고 잘 작동함
  • 자체 IP 구매: 외부 파트너와 작업할 때 자체 IP 블록을 구매하는 것을 지지함. 이는 외부 파트너에게 더 큰 CIDR 블록을 화이트리스트로 제공하는 데 도움이 됨
  • Flux for k8s GitOps 선택: Kubernetes용 GitOps 도구로 Flux를 선택한 것을 후회하지 않음. 배포 상태를 이해하는 데 도움을 주는 도구 개발이 필요함
  • Karpenter for node management: EKS 사용 시 Karpenter 사용을 지지함. 다른 오토스케일러보다 더 신뢰할 수 있고 비용 효율적임
  • SealedSecrets 사용: SealedSecrets 사용을 후회함. 개발자에게 복잡하고 AWS의 기존 비밀번호 암호 교체 자동화를 잃어버림
  • ExternalSecrets 사용: ExternalSecrets를 사용하여 AWS -> Kubernetes 비밀번호 동기화를 지지함. 개발자에게 이해하기 쉽고 terraform을 사용하여 AWS 내에서 비밀번호를 쉽게 생성/업데이트할 수 있음
  • ExternalDNS 사용: ExternalDNS 사용을 지지함. Kubernetes -> Route53 DNS 항목을 동기화하며 지난 4년 동안 문제가 거의 없었음
  • cert-manager 사용: SSL 인증서 관리를 위한 cert-manager 사용을 지지함. Let's Encrypt 인증서 생성에 매우 직관적이고 문제가 없음
  • Bottlerocket for EKS: Bottlerocket을 사용한 EKS 클러스터 운영을 후회함. 네트워킹 CSI 문제가 자주 발생하고 디버깅이 어려움
  • Terraform 대 Cloudformation 선택: Terraform 사용을 지지함. 다른 SaaS 제공업체로 확장하기 쉽고, CloudFormation보다 읽기 쉬운 구문을 가짐
  • 코드형 IaC 솔루션 사용 안 함: 후회하지 않음 Terraform과 CloudFormation이 데이터 파일을 사용하는 반면, Pulumi나 CDK는 코드로 인프라를 설명함. Terraform의 HCL 제한적인 성격이 복잡성을 줄이는 데 도움이 됨
  • 네트워크 메시 사용 안 함: 후회하지 않음 네트워크 메시는 멋지지만, 회사들이 복잡성을 과소평가하는 경향이 있음. 인프라에 대한 일반적인 조언은 "더 적은 것이 더 낫다"임
  • Nginx 로드 밸런서 for EKS ingress: 후회하지 않음 Nginx 사용을 지지함. 오래되었지만 안정적이고 검증된 기술임
  • homebrew for company scripts: 회사 스크립트 배포를 위해 homebrew 사용을 지지함. Linux와 Mac 사용자 모두에게 스크립트와 바이너리를 배포하는 데 충분히 좋음
  • Go for services: 서비스용 Go 언어 사용을 지지함. 새로운 엔지니어가 배우기 쉽고 전반적으로 좋은 선택임
▲
nicewook 2달전  [-]

본문도 댓글도 모두 가치있는 내용들이네요.

답변달기
▲
mhj5730 2달전  [-]

키야....어디서도 구하기 힘든 실용적인 정보네요

답변달기
▲
xguru 2달전  [-]

Hacker News 의견

  • RDS 사용의 추가 비용은 그만한 가치가 있음

    • RDS를 사용하는 것의 추가 비용은 콜로케이션된 SQL 서버 클러스터를 대체하는 것을 고려할 때마다 비현실적으로 비싸서 웃음만 나옴. 지불할 의향이 있는 것을 훨씬 초과하는 비용으로, 콜로케이션 랙, AWS Direct Connects, 서버, SAN, SQL 서버 라이선스, 유지보수 계약, 그리고 전임 내부 DBA의 급여까지 충당할 수 있음.
    • 12개월 총 비용: 547,441.85 USD
    • 마크업이 하나 이상의 전임 직원의 급여를 지불할 수 있을 정도로 커지면, RDS를 무작정 확장하는 대신 그 대신 직원을 고용하는 것을 고려해야 함. RDS를 사용할 때는 정말 많은 비용을 지불하고 있으며, 창업 초기에 내린 결정을 재평가해야 함.

  • Google Cloud가 AWS보다 뛰어나다는 것은 인기 없는 의견일 수 있지만, Google Cloud Run을 사용하면 꿈처럼 도커 컨테이너를 클라우드에서 실행할 수 있음. 서비스 이름이 간단하고, AWS의 복잡한 서비스들보다 중요한 서비스가 적으며, UI가 더 직관적임. 커뮤니티 부족으로 인한 튜토리얼 부족, 경험 많은 인력 찾기 어려움, 써드파티 도구 부족이 단점임. 사용해보길 추천함.

  • EC2 + ASG 사용이 매우 즐거움. 개념적으로 단순함: 이미지를 ASG에 런칭하고, 자동 스케일 정책을 설정함. 걱정할 것이 거의 없음. 반면, k8s 사용은 항상 큰 일임. k8s를 관리하기 위해 전체 팀을 구성함. k8s의 수십 가지 개념을 도입하거나 "플랫폼 엔지니어링"에 사람-년을 투자해 k8s 개념을 숨김. k8s를 "제대로" 사용할 수 있도록 가이드라인과 SDK, 각종 검증기를 출시함. 그럼에도 불구하고 수만 줄의 YAML과 코드를 작성해 오퍼레이터를 구현함. 때때로 k8s가 너무 침입적인지 의문이 듦.

  • SaaS 제품에 대한 의견

    • JIRA에서 Linear로 이동하는 것에 대해 이해하지 못함. Linear는 괜찮지만, 할 수 없거나 방법을 모르는 것들을 자주 발견함.
    • Terraform Cloud 사용을 일반적으로 추천함. 집에서 자체 시스템을 성장시키는 것은 처음 몇 년 동안은 괜찮을 수 있지만, 장기적으로 비용이 들 수 있음.
    • CI/CD를 위해 GitHub Actions 사용을 어느 정도 지지함. 대신 GitLab을 사용할 것을 제안함.
    • Datadog에 대해 강하게 동의하지 않음. 시장에서 가장 좋은 모니터링/관찰 도구임. 비용이 가장 흔한 불만이지만, 대부분 Datadog 설정을 잘못하여 비용이 폭발적으로 증가하는 경우임.
    • Pagerduty에 대해 지지함. Pagerduty는 Opsgenie보다 약 10배 비싸고 더 나은 기능을 제공하지 않음. Pagerduty와 계약 갱신 시, Opsgenie에 없는 기능이 무엇인지 영업 담당자에게 물었을 때, 그들은 시장에서 고급 브랜드로 자리매김하려고 한다고 답함. 그래서 사건 보고를 위해 일반 브랜드를 사용하는 것에 만족함.

  • 90년대/00년대 개발자가 이 목록을 읽고 복잡성/용어에 혼란스러워할 것을 상상함.

  • 흥미로운 읽을거리지만, 블로그를 쓸 만큼 충분히 후회하는 사람인지 확실하지 않음.

  • 하나의 거대한 $100k 서버로 돌아가 모든 것을 한 상자 안에서 실행하는 것을 실험해보고 싶은 충동을 느낌.

  • Kubernetes / EKS의 기본을 배우는 데 성공했지만, ECS로 전환할 것을 고려 중임. Kubernetes는 우리의 필요에 비해 너무 복잡함. CloudFormation과 같은 것으로 제어하기 어려움. 부가 기능에서 프로비저닝된 로드 밸런서는 Kubernetes 외부에서 참조하기 어려움. EKS Fargate에서 Cloudwatch로의 로깅은 문서를 따라도 작동하지 않는 것 같음. EKS EC2에서처럼 CPU/메모리 메트릭이 작동하지 않으며, ADOT가 필요한 것으로 보임. ECS에서 환경을 1/10 시간에 재구성하고 모든 것이 잘 작동함.

  • 이 글을 쓴 방식과 내용을 좋아함. 일부 결정과 추천에 동의하지 않지만, 그런 경우에도 이유를 읽는 것은 훌륭함. 비슷한 글을 더 많이 발행하고 비교할 수 있는 방법이 있으면 좋을 것임. 비슷한 글을 쓰도록 영감을 받음.

  • 모두가 사용하는 주방 싱크 데이터베이스는 흔한 문제이지만, 계속해서 반복됨. 성장하면 상당한 기술 부채와 성능 병목 현상이 됨. RDS와 같은 관리형 DB를 사용하면 주요 앱별로 개별 DB 클러스터를 쉽게 운영할 수 있음.

답변달기