서비스 규모에 따른 인프라 결정

개요

경험이 없는 팀은 서비스 초반에 인프라 결정장애를 겪는다

하나하나 만들어 쓰면 싸고? 좋아 보이는데
좋은 유료 서비스를 쓰면 시간이 절약된다

  • aws
    • k8s
    • ecs
    • elastic beanstalk
    • rds
  • sentry
  • github + action
  • quay
  • bintray
  • heroku

k8s가 좋다고 하지만 숙련된 개발자가 없으면 안쓰니만 못하고
간단한 서비스의 경우 heroku 정도를 쓰는게 나을 수 있다

rabbitmq, kafka 매니지드는 비싸서 소규모일 때는 설치해서 쓰고싶은 유혹이..

인프라 결정 기준

  • 개발인원에 따라 1~5인, 10인, 100인…
  • 서비스 사용자 규모 100명, 1000명
  • 인프라 비용
  • 무정전 서비스가 필요

다양한 요건이 있는데 인프라 비용에 따라 결정하는게 속편하고 빠르다.

할 줄 안다고 하나하나 직접 하다보면 그것만 하다가 본업을 할 수 없게 되니까
기준을 넘어서는 경우 다음 단계로 올라가기 위한 작업을 하면 된다

결정이고 뭐고 필수사항

  • Container – 보통 Docker
  • IaC – 인프라 코드화
  • Git – github을 많이 쓰는데 gitlab.com은 무료에 빠르다
  • 로깅 – Sentry

인프라 월비용에 따른 결정

간단한 웹서비스의 경우

무료 ~ 30만원

모놀리스로 프로토타입 개발하는 시간
또는 잘 설계된 애플리케이션 초반 개발

헤로쿠 heroku.com
AWS 최소인프라로 사용

30만원 ~ 100만원

서서히 기술욕심이 생기는 단계
매니지드 k8s를 사용해볼만하다
헤로쿠는 국내서버 제공이 안되고 느리기도 하니까

GCP, AWS, AZURE, DigitalOcean 매니지드 k8s

금지항목

  • EB(ElasticBeanstalk)
  • ECS
  • GoogleAppEngine

위 항목은 속터지는 것에 비해 편리하지 않다

CloudFunctions, Lambda 등은 생각보다 설계 자체가 어렵고 디버깅도 어렵고 관리도 힘들다
연습용 으로 한두개 추가하기는 괜찮느데 초기 서비스에는 오히려 적합하지 않다

100만원 ~ 1000만원

서버 비용을 걱정하기 시작해야 할 단계

중소 클라우드 업체랑 계약 잘 하면
몇달정도 공짜로 쓰게 해준다
다 쓰고나서 눌러앉아도 되고 옮겨도 된다
어차피 k8s는 다 있으니까 상관없다

네이버 클라우드같은 경우는 IaC가 잘 안되는 문제가 있다.
많이 쓰는 TerraForm 지원이 거의 없다.

서버 API는 잘 돼 있긴한가 모르겠다

1000만원 ~

멀티클라우드

MSA – 의존성 관리 방법

Global Dependency Dictionary System 정도로 불러도 되려나

MSA로 서비스를 구성할 때 발생하는 문제가

어떤 서비스를 Deprecated를 시켰을 때 이전 버전을 언제까지 유지시켜야 할지가 애매하다.

즉각적으로?

한달이상 호출이 없을 때?

모니터링 툴 돌리다가 수동으로?

그냥 소스코드 내부에 /v1 /v2 /v20171001 같은식으로 계속 유지시켜버릴까?

이런 방법은 다 확살하지 않거나 관리가 불편하거나 다양한 문제가 있다.

디비를 변경해야 하는경우에 버전업을 할 때 오류발생 가능성도 있고

 

배포시에 사전을 만들고 의존성을 갖는 프로젝트간의 관계를 가지고 있는게 좋을 것 같다.

일반적인 형태의 라이브러리나 프레임워크로 만들기는 힘들 것 같고

규칙성을 갖게 버저닝을 하고 배포를 해야할 것 같다.

v{메인버전_호환안될수있음}-버그픽스

v1_20171001-1

v1_20171001-2

버전 표기방식으로 흔히 쓰는건 이정도 아닌가

 

버그픽스버전의 경우

3번째칸은 변경되도 호환성에 문제가 없어야하고 1,2번칸이 변경될 경우 호환이 안될 가능성이 생기는걸로

버그픽스 버전이 배포되는 경우 유닛테스트 실행. 이상이 없어야만 배포허용.

 

버전업이 되는 경우

배포시 의존성을 갖는 서비스의 관리자에게 알림이 가고

유닛테스트가 실행. 오류가 나면 오류알림(해당서비스와 의존성을 갖는 서비스의 담당자)

의존성을 갖는 서비스의 담당자는 일정시일(1개월?)이내에 업데이트 권장

긴급수정 사항은 바로 업데이트

 

이 경우 배포툴에 각 개발자의 정보가 담겨있어야한다.