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 클러스터를 쉽게 운영할 수 있음.
Hacker News 의견
RDS 사용의 추가 비용은 그만한 가치가 있음
Google Cloud가 AWS보다 뛰어나다는 것은 인기 없는 의견일 수 있지만, Google Cloud Run을 사용하면 꿈처럼 도커 컨테이너를 클라우드에서 실행할 수 있음. 서비스 이름이 간단하고, AWS의 복잡한 서비스들보다 중요한 서비스가 적으며, UI가 더 직관적임. 커뮤니티 부족으로 인한 튜토리얼 부족, 경험 많은 인력 찾기 어려움, 써드파티 도구 부족이 단점임. 사용해보길 추천함.
EC2 + ASG 사용이 매우 즐거움. 개념적으로 단순함: 이미지를 ASG에 런칭하고, 자동 스케일 정책을 설정함. 걱정할 것이 거의 없음. 반면, k8s 사용은 항상 큰 일임. k8s를 관리하기 위해 전체 팀을 구성함. k8s의 수십 가지 개념을 도입하거나 "플랫폼 엔지니어링"에 사람-년을 투자해 k8s 개념을 숨김. k8s를 "제대로" 사용할 수 있도록 가이드라인과 SDK, 각종 검증기를 출시함. 그럼에도 불구하고 수만 줄의 YAML과 코드를 작성해 오퍼레이터를 구현함. 때때로 k8s가 너무 침입적인지 의문이 듦.
SaaS 제품에 대한 의견
90년대/00년대 개발자가 이 목록을 읽고 복잡성/용어에 혼란스러워할 것을 상상함.
흥미로운 읽을거리지만, 블로그를 쓸 만큼 충분히 후회하는 사람인지 확실하지 않음.
하나의 거대한 $100k 서버로 돌아가 모든 것을 한 상자 안에서 실행하는 것을 실험해보고 싶은 충동을 느낌.
Kubernetes / EKS의 기본을 배우는 데 성공했지만, ECS로 전환할 것을 고려 중임. Kubernetes는 우리의 필요에 비해 너무 복잡함. CloudFormation과 같은 것으로 제어하기 어려움. 부가 기능에서 프로비저닝된 로드 밸런서는 Kubernetes 외부에서 참조하기 어려움. EKS Fargate에서 Cloudwatch로의 로깅은 문서를 따라도 작동하지 않는 것 같음. EKS EC2에서처럼 CPU/메모리 메트릭이 작동하지 않으며, ADOT가 필요한 것으로 보임. ECS에서 환경을 1/10 시간에 재구성하고 모든 것이 잘 작동함.
이 글을 쓴 방식과 내용을 좋아함. 일부 결정과 추천에 동의하지 않지만, 그런 경우에도 이유를 읽는 것은 훌륭함. 비슷한 글을 더 많이 발행하고 비교할 수 있는 방법이 있으면 좋을 것임. 비슷한 글을 쓰도록 영감을 받음.
모두가 사용하는 주방 싱크 데이터베이스는 흔한 문제이지만, 계속해서 반복됨. 성장하면 상당한 기술 부채와 성능 병목 현상이 됨. RDS와 같은 관리형 DB를 사용하면 주요 앱별로 개별 DB 클러스터를 쉽게 운영할 수 있음.