충남대학교 컴퓨터공학과의 "실전코딩" 강의를 필기한 내용입니다.
이 문서는 보관이 목적이고, 관리되지 않습니다. 따라서 잘못된 정보가 포함되어 있거나 순서가 뒤죽박죽일 수 있습니다.
Scale-up, Scale-out
- Scale-up : 서버컴의 하드웨어적인 사양을 올리는 것
- Scale-out : 서버컴를 여러개 구축해서 분산처리하는 것
- 물리적인 컴퓨터의 갯수로 구분짓는다고 생각하면 된다
Monolithic, Microservice Architecture
- Monolithic Architecture : 하나의 프로젝트로 모든 서비스를 다 처리하는 것
- Microservice Architecture : 서비스마다 프로젝트를를 하나씩 둬서 운용하는 것 - 그래서 요청이 오면 그것을 그에 맞는 처리부로 넘겨주는 역할을 하는 것이 load-balancer이다
- 물리적인 컴퓨터의 갯수와는 상관없이 서비스를 전담하는 서버를 하나의 컴퓨터라도 여러개 구성하는지 하나로 쓰는지로 구분짓는다
Monolithic Architecture의 장단점
- 장점
- 개발과 배포가 쉽다
- 스케일링하기가 비교적 용이하다
- 따라서 거의 모든 서비스가 초기에는 이 방식으로 시작한다
- 단점
- 어떤 코드가 어디 있는지 찾기가 힘들다
- 코드를 컴파일하거나 하는 등의 과정이 아주 느리다 - 코드의 크기가 아주 크기 때문
- 따라서 배포에 걸리는 과정도 오래걸리게 된다
- 새로운 팀원이 들어왔을때 적응하기가 힘들다 - 모든 소스 코드를 다 이해하고 있어야 되므로
- 새로운 플랫폼(프로그래밍 언어, 개발환경)으로 옮겨가는 것이 굉장히 힘들다
- 부분적 스케일링이 불가능하다 - 제공하는 서비스 중 하나만이 부하가 많이 걸려도 서버 전체의 스케일링이 필요하다
- 팀레벨의 스케일링이 힘들다 - 특정 서비스를 전담하는 팀에서 문제가 생기면 모든 서비스가 문제가 생기게 된다
Microservice Architecture의 장단점
- 장점
- 일단 서비스별로 서버가 나뉘어져 있기 때문에 내가 어떤 서비스를 맡았으면 이부분에만 집중하면 된다
- 따라서 내가 관리해야 할 코드의 길이가 현저히 줄어든다 - 이것은 팀에 새로운 팀원이 들어왔을 때에도 이 서비스를 위해 이해해야 할 코드가 적어 적응하는 시간이 적게 걸리게 된다
- 그리고 부분적인 배포의 경우에도 서비스 전체를 컴파일하는게 아니기 때문에 배포의 시간이 적게걸린다 - 또한 컴파일시간이 적게 걸린다는 것은 컴파일 오류가 났을 때 대처하기가 쉽고 지금 내가 하로 있는 일이 뭐였는지 까먹지 않아 길을 안 잃을 수가 있다
- 새로운 플랫폼으로 옮겨가는 것, 부분적인 스케일링을 하는 것 등등의 것들이 더 간편해진다
- 구분이 명확하기 때문에 코드가 어느 서버로 가야 하는지, 이 코드가 이 서버에서는 더이상 사용하지 않아 지워하 하는 놈인지 등등을 판단하기가 쉽다
- Fault isolation : 부분적인 문제가 있어도 시스템 전체가 죽지 않음
- circuit breaker : 해당 서비스가 제대로 작동하는지를 계속 체크해서 문제가 생겼을 경우 빠르게 파악해 낼 수 있음
- 팀레벨의 스케일링이 편하다 - 각 팀이 각자의 스케줄을 갖고 개발을 할 수 있으며 자기 팀과 연관이 없는 코드를 신경 안써도 된다
- 자신의 서비스에 맞는 언어/데이터베이스를 사용할 수 있다
- 서비스 하나가 서버이자 클라이언트이기 때문에 클라이언트 입장에서의 관점을 더 잘 이해해 다른 서버에 요청하고 받는 과정을 구현하는 것이 더 쉬워진다
- 단점
- 디버깅이 어려움 - 여러개의 서버가 얽혀있으니까 디버깅 할때 여러군데를 들러야 한다 - 따라서 어디가 정확하고 어디가 부정확한지를 구분하는 것이 중요하다 - 이걸 알아야 어디를 먼저 테스트해봐야 할 지 알 수 있으므로
- 글로벌한 관점에서 테스트를 하기가 힘들다
- 다른 서비스랑 서버간 통신을 하기 때문에 TCP통신을 사용하므로 Stop-N-Wait ARQ를 사용하게 된다 - 따라서 서비스간의 통신이 상대적으로 느릴 수 밖에 없다 - 대신 통신 과정을 간소화한 것을 개발해 통신속도를 줄이기도 한다
- 서버마다 라이브러리를 import시키기 때문에 라이브러리를 중복해서 import시켜야 된다 - 따라서 코드 양 전체적으로 봤을때 더 많아질 수도 있다 - 내가 라이브러리를 만드는 경우 여러번 만들어야될 수도 있는 것
- 유료 라이선스가 필요한 것을 사용할때 서버마다 라이선스를 지불해야 되기 때문에 비용이 더 많이 청구될 수도 있다
- 시스템 전반적인 감을 잡기가 힘들다
- 데이터베이스간 일관성을 유지하기 힘들다 - 데이버테이스끼리도 통신을 하게 되는 구조이므로 통신 에러가 나면 일관성이 깨지게 된다
- 단순하게 함수 하나 호출하는 작업인 경우에도 이것을 api통신으로 전달해서 실행해야되기 때문에 endpoint(url)이 점점 복잡해지게 되어 나중에는 이 url이 뭐하는놈인지도 헷갈리게 되고 그렇게 될 수도 있다 - 그리고 사용하는 도메인도 많아지기 때문에 인증서 관리 등등 번거로워지게 된다 - 그래서 service discovery라는걸 사용하기도 한다 - 얘는 이제 각 서비스에 도메인을 연결하는 방식이 아닌 도메인은 하나만 연결하고 요청이 들어오면 거거를 도메인 없이 그냥 ip로 변환해 넘겨주게 되는 식으로 작동
- 배포순서도 신경써야 된다 - 다른 서비스가 아직 준비가 안됐는데 먼저 배포를 하게 되면 당연히 에러가 나게 된다 - 따라서 다른 서비스의 하위 버전도 호환 가능하게 하는 코드를 갖고 있다가 그 서비스가 업그레이드 되면 내 서비스도 그걸 제거해서 다시 배포하고 그런식의 불필요한 작업들이 생길 수도 있다
- 항상 구동되어야 하는 경우 다른 서비스가 안될때 나도 죽지 않고 구동되어야 할 플랜B를 항상 마련해두어야 한다
Blue, Green 무중단 배포
- 기존의 서비스를 blue라고 하고 옮겨갈 애를 green이라고 한다
- 그리고 green의 배포가 준비되면 blue에서 green으로 요청 처리 스트림을 옮겨준다
- 이후 blue서비스로 들어오는 요청이 전부 처리되면, blue의 경우 폐기되게 된다
- 이런식으로 서비스의 중단 없이 배포가 가능하다