Skip to content

Cloud Computing

클라우드컴퓨팅의 상세 분야

클라우드 컴퓨팅(영어: cloud computing)은 인터넷 기반(cloud)의 컴퓨팅(computing) 기술을 의미한다. 인터넷 상의 유틸리티 데이터 서버에 프로그램을 두고 그때 그때 컴퓨터나 휴대폰 등에 불러와서 사용하는 웹에 기반한 소프트웨어 서비스이다.

Software architecture

서비스 제공 업체 목록

platform as a service

  • Vercel - 무료 Next.js 호스팅
  • Fly.io - 빠르고 간편한 컨테이너 배포
    • <del>shared-cpu-1x, RAM 256MB VM 3대 무료<del> - 종료
  • Netlify
  • Render - 무료 100GB Bandwidth, Docker 이미지 돌릴 수 있음
  • Koyeb
    • Docker image build 지원
    • GitHub 저장소 또는 사전 빌드된 컨테이너 사용
    • API, 풀스택 웹 서비스 또는 작업자
    • 전 세계 3개 지역
    • 한 번의 클릭으로 20개 이상의 앱
  • Heroku
  • Railway - https://railway.app/
    • Github Repo로 쉽게 Deploy
    • 512MB RAM / 1GB Disk 무료 - 종료된듯? 확인 필요.

Container Registry

Managed Service Provider (MSP)

MSP란 Managed Service Provider의 약자로 클라우드 매니지드 서비스 업체를 의미합니다.

Cloud Service Provider (CSP)

서비스별 무료 대역폭 한도

서비스별 무료 대역폭 한도

  • Cloudflare Pages: 무제한
  • GitHub Pages: 소프트 100GB
  • GitLab Pages: X,000 요청/분
  • Netlify: 100GB
  • AWS S3: 100GB

클라우드 서비스 변경 이슈

AWS,Azure,Google 등의 클라우드 간에 옮겨본 이유와 경험을 묻는 HN의 질문과 답변들

  • 내 클라이언트의 환경을 AWS → Google, 그리고 Google → Hetzner로 제로 다운타임 이관 했음
    • 주요 이유는 가격. AWS/Google의 무료 크레딧을 다 쓴후에 Hetzner로
    • 크레딧을 사용하여 절약한 비용이 마이그레이션 비용의 20배
    • 마이그레이션 진행은 각 환경에서 리버스 프록시를 이용해서 백엔드와 연결 후, 서비스간 VPN을 설정한 뒤에 DNS를 변경
    • 가장 까다로운 부분은 데이터베이스 Failover 였고, 마스터 전환 후에 업데이트가 재시도 되도록 하는 것
    • 이를 통해서 클라이언트는 클라우드 제공자에 구애 받지 않는 설정을 가지게 되었고, 자신들이 가진 무료 크레딧을 잘 활용했음
    • 기술 상세
      • haproxy, nginx 등의 리버스 프록시 + Hashicorp Consul + ngx_mruby
      • 각 클라우드간 VPN 구성하여 리버스 프록시가 양쪽의 백엔드에 접속 가능
      • 새 클라우드로 데이터베이스 복제
      • 앱이 어떤 데이터베이스를 마스터로 사용할 건지 선택하는게 가능하도록 할 것(Consul)
      • 앱이 데이터베이스 오류에 대해 gracefully 처리하도록 할 것. 이 부분이 가장 까다로움
      • DNS TTL 작게 설정
      • 새로운 백엔드를 리버스 프록시에 연결하고 에러가 없는지 확인
      • 새 리버스 프록시를 환경에 추가하도록 DNS 업데이트
      • 새 클라우드에 있는 복제본을 마스터로 Promote
      • 기존 백엔드에 있는 커넥션들 줄이기
      • 최종적으로 기존 리버스 프록시를 DNS에서 제거
      • 모두 확인후 기존 환경을 제거하고 DNS TTL을 복구
  • GitLab 은 AWS에서 Azure로 갔다가 다시 Google Cloud로 갔음(몇년 전에)
    • 처음엔 다들 그러듯이 AWS로 시작했지만, 돈이 엄청 들어감 (돈을 불태운다고 표현)
    • YC 멤버에게 Azure 크레딧을 준다고 해서 계산해보니 1년정도의 사용금액인듯 해서 옮겼음
    • 하지만 옮기는 것은 고통스러웠고, Azure 사용 기간중엔 아무도 만족하지 못했음. 추가로 무료 크레딧도 꽤 빨리 소모되었음.
    • GCP로 이동한 이유는 정확히 기억 안나지만, 꽤 오랜 시간이 걸리는 상당히 어려운 과정 이었음
    • GCP 경험은 훨씬 더 좋았지만, 완벽하다고 말할 수는 없음.
    • 특히 GCP는 명확한 이유 없이 VM을 무작위로 종료하는 경향이 있었음
    • 때로는 깔끔하게 종료되지만, 다른 경우엔 일종의 중간상태로 끝나버려서 다른 시스템이 연결을 시도하게 되어 바로 오류가 발생하는 대신 연결 시간초과가 발생
    • 기억하기론 시간이 지나면서 좋아지긴 했지만 "뭔가 고장 났지만, 이유를 알려줄수 없습니다." 라고 말하는 매우 Google 스럽게 느껴졌음
    • 돌이켜 보면, 다시 회사를 차린다면 아마도 Hetzner나 다른 저렴한 베어메탈 프로바이더 같은 회사를 고수할 것
    • 클라우드 서비스는 가능한 최대로 활용한다면 훌륭하지만, 90%의 경우에는 이점없이 그냥 쓰고 있고 비용만 많이 내고 있을 것
  • Google Cloud → Digital Ocean → OVH
    • 고성능 서버에서 우리것을 운영하는 것은 생각보다 문제가 적고 쉬움
    • git push로 배포하고, 컨테이너를 빌드하는 것은 "Set it and forget it" 수준
    • 테라바이트 용량의 PostgreSQL 데이터를 가지고 있어서, 대부분의 클라우드에서 엄청나게 비쌈
    • 클라우드가 먹게 좋게 썰린 빵 같다고 생각하는 사람도 있는 것 같지만, 개발자의 시간을 실제로 줄여주지는 못함
    • 클라우드는 서버운영보다 비싸고 많이 느리다. 중간 규모의 워크로드에서는 클라우드를 이용하는 것의 장점이 없다

가장 투표를 많이 받은 3개 답변만 추렸습니다. 위 답변에는 또 다양한 질문,의견 및 반론 댓글이 달려있으니 같이 참고하세요.

스타트업에서 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 언어 사용을 지지함. 새로운 엔지니어가 배우기 쉽고 전반적으로 좋은 선택임

Favorite site

References

  1. Oss_kr-CloudStack,Eucalyptus,OpenStack,vCloud.pdf ↩