배포에는 두 가지 관점이 있다고 한다.
로컬에서 사용하기 위한 배포 방식
사용자에게 어떤 패키지를 전달해서 사용자가 그걸 설치해서 사용하는 방식의 배포
예를 들어, CD로 스타크래프트 했던 건 CD를 통해 배포하는 것.
앱스토어에서 앱을 다운받아서 로컬에서 사용하도록 앱파일을 배포하는 것.
로컬에서 사용하지 않는 배포 방식
서버, 사용자 단말기에서 서버에다가 요청해서 뭔가를 받아온다
요즘 앱들의 대부분이 이렇게 운영된다, 인터넷에 접속하지 않는 앱은 없다고 봐야 한다.
특히 우리가 집중하는 건, 웹은 거의 99.9%가 인터넷에 접속해서 서버에 뭔가를 요청해서 응답을 받아온다.
그런 역할을 하는 게 서버라고 함.
서버를 세팅하는 걸 서버 배포, 클라이언트 앱을 배포하는 걸 클라이언트 배포라고 한다면은,
기본적으로 클라우드의 경우에는 서버 배포를 뜻하는 것. 특히 그래서 웹에 포커스가 되는 것.
(그래서 요즘 springboot에 대한 관심, java에 대한 관심이 많아지는 건가? 암튼.)
1. 클라우드와 서버 배포의 관계
클라우드는 본질적으로 IT 인프라(서버, 네트워크, 스토리지)를 가상화하여 제공하는 서비스입니다. 클라우드 환경에서 서버 배포는 애플리케이션이나 웹 서비스가 작동할 수 있는 기반을 마련하는 핵심 작업입니다. 이 과정에서 웹 서버, 애플리케이션 서버, 데이터베이스 서버 등을 설정하고 배포하는 일이 주요 작업으로 자리 잡습니다.
2. 웹 중심의 서버 배포
- 오늘날의 많은 애플리케이션은 웹 중심으로 설계되어 있습니다. 특히, 클라이언트는 주로 브라우저 또는 모바일 앱을 통해 서버와 통신하며, 서버는 데이터 처리, 비즈니스 로직 실행, 데이터 저장 등의 핵심 역할을 담당합니다.
- 서버 배포는 이러한 웹 애플리케이션의 "뇌" 역할을 하는 백엔드 인프라를 준비하는 과정입니다. 예를 들어:
- API 서버를 설정(Swagger/OpenAPI 기반의 REST API 또는 GraphQL API)
- 데이터베이스 연결
- 로드 밸런싱과 같은 네트워크 구성
3. Spring Boot와 Java의 관심 증가
- 최근 Spring Boot와 Java에 대한 관심이 증가한 것은 클라우드, 특히 웹 애플리케이션 배포와 밀접하게 관련이 있습니다.
- Spring Boot는 RESTful 웹 서비스나 마이크로서비스 아키텍처를 구축하는 데 탁월한 프레임워크입니다.
- Java는 안정성과 확장성이 뛰어나 대규모 트래픽을 처리하는 백엔드 서버를 개발하는 데 선호됩니다.
- 클라우드 환경(특히 Kubernetes나 Docker)을 활용한 컨테이너 기반 배포와 잘 맞아떨어집니다.
4. 클라이언트 배포는 상대적으로 단순
- 클라이언트 배포(Client Deployment)는 사용자 디바이스에 애플리케이션을 배포하거나, 웹 브라우저를 통해 애플리케이션에 접속할 수 있도록 하는 과정입니다.
- 웹 앱의 경우: 클라이언트 배포는 HTML, CSS, JavaScript 파일들을 CDN(Content Delivery Network)에 업로드하고 브라우저에서 로드하는 방식.
- 모바일 앱의 경우: App Store나 Google Play에 업로드.
서버 배포와 달리 클라이언트 배포는 고정된 환경(사용자의 브라우저 또는 모바일 디바이스)에 맞춰 최적화하는 작업이므로, 클라우드에서의 배포와 비교했을 때 상대적으로 덜 복잡한 경향이 있습니다.
5. 결론
- 클라우드가 중심이 되면서 서버 배포가 중요해졌고, 이는 자연스럽게 **백엔드 개발 기술(Spring Boot, Java)**에 대한 관심으로 이어지고 있습니다.
- 클라이언트 배포는 중요하지만, 클라우드의 핵심 가치는 서버와 데이터 관리 및 확장성에 있기 때문에 상대적으로 서버 배포에 더 많은 관심이 쏠리는 것이 자연스럽습니다.
클라우드라는 건, 개발한 서비스를 배포하기 위해서
서버 역할을 대신 해주는 것이라고 생각하면 되는걸까?
네, 클라우드를 그렇게 이해하는 것이 기본 개념을 잡는 데 매우 유용합니다. 클라우드는 개발한 서비스를 배포하고 운영할 수 있는 서버 역할을 대신하거나, 더 나아가 확장성과 관리의 편의성을 제공하는 환경으로 생각할 수 있습니다. 이를 조금 더 구체적으로 설명하자면:
1. 클라우드는 서버 역할을 대신한다
- 과거에는 서비스를 배포하려면 물리적인 서버를 구입하고, 네트워크와 스토리지를 설정한 뒤 서버실을 운영해야 했습니다.
- 클라우드는 이러한 물리적인 서버의 역할을 가상화하여 제공하므로, 물리적인 인프라를 관리할 필요가 없습니다.
- 예: Amazon Web Services(AWS), Microsoft Azure, Google Cloud
2. 서비스 배포를 간소화
클라우드는 개발자가 코드를 작성한 후 서비스를 배포하기 위한 다양한 도구와 환경을 제공합니다.
- 서버 설정 (IaaS): 가상 머신을 만들어 직접 운영 체제부터 설정 가능
- 플랫폼 제공 (PaaS): 코드를 업로드하면 자동으로 실행 환경과 배포를 처리
- 완성형 소프트웨어 (SaaS): 이미 준비된 소프트웨어를 바로 사용
3. 더 나은 확장성과 관리
- 클라우드는 단순히 "서버 역할"을 대신할 뿐만 아니라, 서비스의 규모가 커지거나 줄어들 때 필요한 자원을 자동으로 조정할 수 있습니다.
- 예: 사용자가 증가하면 서버 수를 자동으로 늘리고, 트래픽이 줄면 다시 줄이는 오토스케일링.
- 이 외에도 데이터 백업, 보안, 모니터링 등 서버 운영의 부가적인 작업을 쉽게 처리할 수 있는 도구를 제공합니다.
4. 그럼 클라우드는 무엇을 더 해주는가?
클라우드는 단순히 서버를 대체하는 것을 넘어 개발과 운영에 필요한 다양한 기능을 제공합니다:
- 배포 자동화: CI/CD 도구를 통해 배포 과정을 자동화.
- 보안 관리: 클라우드 보안 도구를 통해 데이터 보호.
- 데이터 분석: 빅데이터 분석과 같은 고급 기능도 클라우드에서 지원.
- 지역 확장: 세계 여러 지역에 데이터 센터를 활용해 글로벌 서비스 제공.
5. 결론적으로
클라우드는 "개발한 서비스를 배포하기 위해 서버 역할을 대신한다"는 기본 개념에 추가로:
- 확장성, 관리 효율성, 글로벌 접근성을 제공하는 강력한 플랫폼이라고 이해할 수 있습니다.
- 단순한 서버 대체가 아니라, IT 운영 전반을 쉽게 관리하고 서비스를 더 빠르고 효율적으로 운영하도록 돕는 역할을 합니다.
지금 너가 답변해준 내용을 더 잘 이해하기 위해서, 2번의 iaas, paas, saas를 좀 더 이해하기 쉽게 설명해주면 좋겠고, 4번의 배포 자동화 라는게 어떤 의미인지 쉽게 설명해주면 좋겠어.
2번: IaaS, PaaS, SaaS를 쉽게 이해하기
IaaS, PaaS, SaaS는 각각 클라우드에서 제공하는 서비스의 레벨을 뜻합니다. 이를 실제 생활에 비유해 보면 더 쉽게 이해할 수 있습니다:
IaaS (Infrastructure as a Service)
"내 집을 직접 짓는 것"
- 클라우드가 제공하는 "뼈대"만 사용하고, 나머지(운영체제, 소프트웨어 등)는 내가 직접 설치하고 관리합니다.
- 비유: 빈 땅을 제공받아서, 내가 직접 집 설계부터 짓고 관리까지 다 해야 하는 경우.
- 예: Amazon EC2(가상 서버), Microsoft Azure VM
PaaS (Platform as a Service)
"아파트를 임대해서 사용하는 것"
- 클라우드가 운영체제, 데이터베이스 등 기본적인 환경까지 준비해 주기 때문에, 나는 애플리케이션만 개발하면 됩니다.
- 비유: 아파트에 들어가서 필요한 가구만 놓으면 바로 살 수 있는 상태.
- 예: Heroku, Google App Engine, Microsoft Azure App Service
SaaS (Software as a Service)
"호텔에서 숙박하는 것"
- 클라우드가 모든 것을 준비해 놓고, 나는 서비스를 그냥 사용하기만 하면 됩니다.
- 비유: 호텔에서 모든 것이 준비되어 있어서, 나는 짐만 가져와서 머물면 되는 상태.
- 예: Gmail, Microsoft 365, Zoom
핵심 비교
- IaaS: 내가 다 해야 함. (서버 설치, 운영 등)
- PaaS: 기본적인 것은 제공되므로 개발만 하면 됨.
- SaaS: 그냥 쓰기만 하면 됨.
4번: 배포 자동화란 무엇인가?
배포란?
- 애플리케이션이나 서비스를 실제로 사람들이 사용할 수 있는 환경에 올리는 과정입니다.
- 예를 들어, 내가 만든 웹사이트를 인터넷에 공개하거나, 모바일 앱을 배포하는 것.
배포 자동화란?
- 배포 과정을 사람이 수작업으로 하지 않고, 자동화된 도구와 프로세스를 통해 쉽게 처리하는 것.
- 예를 들어:
- 코드를 작성하면 자동으로 빌드(컴파일)되고,
- 테스트가 자동으로 실행되며,
- 클라우드 서버에 코드가 자동으로 배포되는 과정.
비유: 손으로 배달 vs 자동화된 배달 시스템
- 손으로 배달: 내가 직접 물건을 준비하고 포장해서 배송하는 일.
- 자동화된 배달 시스템: 주문만 입력하면 물류 시스템이 자동으로 물건을 포장하고, 트럭이 배송을 맡아주는 것.
배포 자동화는 이와 비슷하게, 개발자가 코드를 입력하기만 하면, 그 뒤의 모든 과정(빌드, 테스트, 배포)을 자동으로 처리해주는 시스템입니다.
대표적인 배포 자동화 도구
- CI/CD 파이프라인 도구:
- CI (Continuous Integration): 코드를 변경하면 자동으로 테스트하고 빌드.
- CD (Continuous Deployment): 테스트를 통과한 코드를 자동으로 배포.
- 예: Jenkins, GitHub Actions, GitLab CI/CD
왜 배포 자동화가 중요한가?
- 시간 절약: 사람이 직접 하지 않아도 되므로 시간을 아낄 수 있음.
- 에러 감소: 사람이 실수로 놓칠 수 있는 부분을 자동으로 처리.
- 일관성 유지: 모든 배포 과정을 동일한 방식으로 수행.
배포라는게, 처음 한 번 하고 나면 끝이 아닌거야? 왜 배포를 자동화해야 하는거지?
배포가 처음 한 번 하고 끝나는 작업이 아닌 이유와 배포 자동화가 필요한 이유를 단계별로 설명해볼게요.
1. 배포는 왜 한 번으로 끝나지 않을까?
소프트웨어 배포는 단순히 "한 번 끝내는 작업"이 아닙니다. 계속 업데이트가 필요한 작업이기 때문이에요.
1) 버그 수정
- 배포 후 사용자들이 사용하는 과정에서 예상치 못한 버그가 발견될 수 있습니다.
- 발견된 버그를 고치고 다시 배포해야 합니다.
2) 기능 추가
- 고객의 요구 사항이 변하거나, 새로운 기능을 추가해야 할 때 기존 코드를 업데이트하고 다시 배포해야 합니다.
3) 성능 최적화
- 서비스가 성장하면서 더 많은 사용자를 지원하기 위해 성능을 개선하거나 서버 환경을 바꿔야 할 수 있습니다.
4) 보안 업데이트
- 새로운 보안 위협이 나타나면 이를 막기 위한 패치를 적용해야 합니다.
2. 배포를 자동화해야 하는 이유
(1) 수작업 배포는 시간이 많이 걸림
- 개발자가 변경된 코드를 하나씩 서버에 업로드하고 설정을 바꿔야 한다면, 시간이 오래 걸립니다.
- 사람이 직접 하면 실수가 발생할 가능성도 높아집니다.
(2) 배포 과정은 반복적이고 귀찮은 작업
- 배포는 단순히 한 번 하고 끝나는 게 아니라, 위에서 말한 이유들로 인해 계속 반복적으로 해야 합니다.
- 매번 수작업으로 한다면 개발자들이 불필요한 일에 많은 시간을 소비하게 됩니다.
(3) 팀 협업에서 중요한 역할
- 여러 명이 동시에 코드를 수정하는 경우, 누가 어떤 변경을 했는지 관리하기 어려워집니다.
- 자동화된 배포 프로세스는 팀원들이 변경한 코드를 자동으로 테스트하고, 충돌 없이 병합하고, 배포하도록 도와줍니다.
(4) 배포의 속도와 신뢰성 향상
- 자동화된 배포를 사용하면, 변경된 코드가 몇 분 만에 테스트되고 안전하게 배포됩니다.
- 속도가 빨라지면서 사용자들은 더 빠르게 새로운 기능과 개선 사항을 경험할 수 있습니다.
3. 자동화된 배포가 어떻게 이루어지나?
예시: CI/CD 파이프라인
- 코드 작성 및 커밋
- 개발자가 코드를 수정하고 Git 저장소에 커밋하면 자동화된 프로세스가 시작됩니다.
- 자동 테스트
- 코드가 제대로 작동하는지 확인하기 위해 자동화된 테스트가 실행됩니다.
- 빌드 및 패키징
- 테스트를 통과한 코드가 실행 가능한 형태로 빌드되고, 필요하면 컨테이너(Docker 이미지 등)로 패키징됩니다.
- 배포
- 패키징된 코드가 서버(예: 클라우드)로 자동으로 배포됩니다.
- 여기서 무중단 배포(사용자 서비스에 영향을 주지 않는 배포)도 가능합니다.
도구 사용
- 도구: Jenkins, GitHub Actions, GitLab CI/CD, CircleCI 등
- 설정: 한번 배포 프로세스를 설정해 두면, 이후에는 변경된 코드만 자동으로 처리됩니다.
4. 결론적으로 배포 자동화가 필요한 이유
- 반복적인 작업을 줄여 생산성 향상: 개발자는 코드를 작성하는 본질적인 작업에 더 집중할 수 있습니다.
- 속도와 신뢰성: 빠르고 일관성 있는 배포로 사용자에게 빠르게 새로운 기능을 제공합니다.
- 오류 방지: 사람이 수작업으로 하는 실수를 줄이고, 테스트와 배포가 표준화됩니다.
- 팀워크 개선: 팀원 간 코드 충돌이나 혼란을 줄이고 협업을 원활히 진행할 수 있습니다.
한 번 배포로 끝난다면 자동화는 필요 없겠죠. 하지만 소프트웨어는 항상 변화하고 개선되어야 하기에, 배포 작업을 자동화하면 개발과 운영 모두에서 효율성을 크게 높일 수 있습니다. 😊
클라우드라는 건,
- 최적화의 관점에서 규모의 경제를 이루는 것. 자원이 무한하지 않기 때문에 10명이 각각 10대씩 사용하면 100대 인데, 그냥 100대를 중간에 놓고 돌아가면서 쓰면 100명이 쓸 수도 있다. 예를 들어, 미국인이 쓸 때는 한국인은 자고 있고, 미국인이 자고 있을때 한국인이 쓰고 있는 것으로 최적화의 관점에서 효율적인 활용이 가능해짐.
- 복잡성 관리의 관점에서 클라우드가 편리하고 편안하게 클라우드가 다양한 서비스를 제공해주고 있어서 관리가 편해진다.
클라우드 사용이 처음에는 어려운 이유가, 서비스가 수백 가지가 되어서 그렇다.
그 수백 가지의 서비스 중에서 조합을 잘 해서 클라우드 서버를 구성하는 것.
클라우드 조합 설계
- 머리가 복잡할 때는 사용자에서 시작
- 데이터 흐름과 처리를 도식화
- 클라우드 서비스 및 패턴 탐색
- 비용과 유연성 고려
- 최종 스택 화정
Monolithic vs. Micro Service Architecture(MSA)
이거는 둘 중에 하나를 선택하는게 아니고 스펙트럼 같은 것. 수직선에서 왼쪽에서 오른쪽으로 옮겨가며 조정하면 된다.
되도록이면 적은 수의 클라우드 서비스들을 써서 구성하겠다면 Monolithic Architecture (PaaS 위주)
클라우드에서 제공해주는 서비스들을 많이 써서 구성하겠다면 Micro Service Architecture (Saas 위주)
복잡성 관리는 MSA가 쉽다. 최적화의 관점에서 자원의 효율적인 사용, 비용적인 측면을 위해서는 Monolithic이 좋다.
Monolithic Architecture와 Microservice Architecture(MSA)는 애플리케이션을 설계하고 배포하는 방식에서 중요한 차이를 가지고 있습니다. 각각의 특징, 장단점, 그리고 언제 사용하는 것이 좋은지 설명하겠습니다.
1. Monolithic Architecture
특징
- 단일 애플리케이션: 모든 기능이 하나의 코드베이스와 프로세스로 통합되어 있습니다.
- 단일 배포 단위: 하나의 애플리케이션으로 배포됩니다.
- 데이터베이스도 주로 단일 DB로 관리됩니다.
- 전통적인 방식으로, 초기 웹 애플리케이션 설계에서 많이 사용됨.
장점
- 단순한 설계: 이해하기 쉽고, 작은 팀에서도 빠르게 개발할 수 있음.
- 단일 배포: 모든 것이 하나의 배포 단위에 포함되므로 배포와 관리가 단순.
- 성능: 컴포넌트들이 한 프로세스 안에서 작동하기 때문에 통신 비용이 적음.
- 테스트 용이: 모든 코드가 한 코드베이스에 있기 때문에 테스트 환경 구성도 단순함.
단점
- 유지보수 어려움: 코드가 방대해지면 수정과 확장이 어렵고, 하나의 수정이 전체 애플리케이션에 영향을 미칠 수 있음.
- 확장성 문제: 특정 기능만 확장하기 어렵고, 전체 애플리케이션을 확장해야 함.
- 의존성 문제: 모든 기능이 강하게 결합되어 있어 부분적인 업데이트가 어려움.
- 비효율적인 배포: 작은 변경 사항도 전체 애플리케이션을 재배포해야 함.
언제 사용하는 것이 적합한가?
- 작은 규모의 프로젝트: 초기 단계의 스타트업이나 단순한 애플리케이션.
- 팀 규모가 작고 개발 속도가 중요할 때.
- 복잡한 기능이 많지 않은 애플리케이션.
2. Microservice Architecture (MSA)
특징
- 독립적인 서비스: 애플리케이션이 여러 개의 작은 서비스로 나누어짐. 각 서비스는 고유한 기능을 담당.
- 개별 배포 단위: 각 서비스는 독립적으로 개발, 배포, 확장 가능.
- 분산 시스템: 서비스 간 통신은 주로 HTTP REST API, 메시지 큐, 또는 gRPC를 통해 이루어짐.
장점
- 유지보수 용이: 서비스가 분리되어 있어, 특정 기능만 수정하거나 확장 가능.
- 확장성: 자주 사용되는 서비스만 개별적으로 확장 가능(예: 데이터 처리 서비스).
- 독립적 개발: 각 서비스는 별도의 팀에서 독립적으로 개발할 수 있음.
- 기술 다양성: 각 서비스가 다른 기술 스택(언어, 데이터베이스 등)을 사용할 수 있음.
- 탄력적 배포: 특정 서비스만 업데이트하거나 배포 가능.
단점
- 복잡성 증가: 서비스 간 통신, 데이터 동기화, 모니터링 등 관리가 어려움.
- 분산 시스템의 어려움: 네트워크 장애, 데이터 일관성 문제 발생 가능.
- 초기 구축 비용: 초기 설계와 인프라 설정이 복잡하고 시간이 더 걸림.
- 테스트 어려움: 각 서비스가 독립적이므로 통합 테스트가 복잡함.
언제 사용하는 것이 적합한가?
- 대규모 프로젝트: 기능이 많고, 지속적인 확장이 필요한 경우.
- 팀이 크고, 여러 팀이 병렬로 작업할 때.
- 서비스가 다양한 트래픽 패턴을 가질 때(특정 기능만 자주 사용됨).
- 지속적인 기능 추가와 빠른 배포가 중요한 경우.
3. 주요 차이점 비교
항목Monolithic ArchitectureMicroservice Architecture (MSA)
| 구조 | 단일 코드베이스 | 여러 개의 독립 서비스 |
| 배포 | 전체 애플리케이션을 한 번에 배포 | 각 서비스 별도로 배포 가능 |
| 확장성 | 전체 확장 필요 | 특정 서비스만 확장 가능 |
| 기술 선택 | 단일 기술 스택 | 각 서비스별로 다른 기술 스택 가능 |
| 복잡성 | 낮음 | 높음 |
| 의존성 관리 | 강한 결합 | 약한 결합 |
| 팀 작업 | 협업 어려움 | 팀별 독립 개발 가능 |
| 트래픽 처리 | 전체 시스템 성능에 의존 | 서비스별로 독립적으로 트래픽 처리 가능 |
4. 선택 기준
- Monolithic을 선택해야 할 때:
- 빠른 프로토타입 개발이 필요한 경우.
- 소규모 팀, 제한된 자원.
- 단순한 요구 사항의 애플리케이션.
- MSA를 선택해야 할 때:
- 대규모 서비스로 확장 계획이 있는 경우.
- 다양한 기술 스택을 사용해야 하는 경우.
- 특정 기능의 독립적 개발과 배포가 중요한 경우.
5. 결론
- Monolithic은 단순함과 빠른 개발에 유리하지만, 시스템이 커질수록 유지보수가 어려워집니다.
- MSA는 확장성과 유연성이 뛰어나지만, 초기 설계와 운영이 복잡합니다.
현재의 요구 사항과 팀의 역량을 고려해 선택하는 것이 중요하며, 점진적으로 Monolithic에서 MSA로 전환하는 경우도 많습니다.
Docker
- Monolithic은 한 곳에다가 모든 설치를 해야 해서 관리가 복잡하다는 어려움이 있다. 서비스가 분리되어 있으면 설명을 적어놓은 파일을 읽어보면 되는데, monolithic의 경우에는 코드도 기억해야 하고 어디에 뭐가 설치되어 있는지를 기억해야 한다.
- 그래서 Docker는 OS레벨부터 해서 Application레벨까지 전체를 하나로 포장을 해가지고 그 컴퓨터를 클라우드에다가 끼워주는 걸 해준다
- 하나 하나씩 옮기는게 아니라, 그냥 통째로 옮겨줘서 "이게 너야" 라고 도와주는 기능을 제공한다.
- 그러니까 Docker를 통해서 배포 시간을 굉장히 줄여줄 수 있다. 하나씩 설치해서 서버 세팅을 하는게 아니라 통째로 옮겨서 클라우드에 끼워주니까 배포 시간이 감소해서 서버 다운 타임을 감소시켜준다
- 예를 들어, <로컬에서 Docker를 만들어서 클라우드 서비스에 10초만 서비스 중단 시키고 원래 있던 부분은 빼고 지금 만든 Docker로 갈아끼워줘, 통째로 교체할게요.>하는 것과, <하나하나 서비스 접속해서 서버 다운 시켜놓고 Python 패키지 업그레이드 하고, PostgreSQL 업데이트하고.....> 하는 것 중에 당연히 전자가 훨씬 빠르다.
- Docking이라는 단어가 도킹, 끼는 것. 뺐다끼우는, 미리 준비해서 뺐다 끼우는 것.
- 관리의 개념, Monolithic에서 관리의 개념으로 docker가 있다는 것.
Docker의 역할
- Docker는 애플리케이션과 필요한 모든 환경(운영 체제, 라이브러리, 종속성 등)을 **컨테이너(Container)**라는 독립된 단위로 묶어줍니다.
- 이렇게 묶인 컨테이너는 어디서든 동일하게 실행할 수 있습니다.
- 로컬 개발 환경에서 실행하던 Docker 컨테이너를 클라우드나 다른 서버로 그대로 옮겨서 실행 가능.
- 컨테이너 자체가 "완성된 패키지" 역할을 하기 때문에, 추가적인 설정이 필요 없습니다.
배포 시간 단축과 다운타임 감소
- 전통적인 배포 방식에서는 다음과 같은 작업이 필요합니다:
- 운영 체제 설치 및 설정.
- 애플리케이션 실행에 필요한 패키지 설치(Python, PostgreSQL 등).
- 기존 데이터를 새 환경으로 옮기고 테스트.
- 설정 충돌이나 의존성 문제 해결.
- Docker 방식에서는:
- 로컬 환경에서 컨테이너를 미리 준비(Docker 이미지 생성).
- 클라우드나 서버에 컨테이너를 그대로 옮겨서 바로 실행.
- 필요하면 기존 컨테이너를 멈추고 새 컨테이너로 교체하는 방식으로 배포.
- 예: Blue-Green Deployment로 다운타임 없이 배포 가능.
Docking의 개념
- Docker 이름의 유래처럼, 컨테이너를 끼우는(Docking) 개념으로 생각할 수 있습니다.
- 미리 준비된 컨테이너를 마치 레고 블록처럼 클라우드나 서버에 끼우는 방식으로 작업.
- 기존 컨테이너를 "뺐다 끼우는" 작업이 가능해 유지보수와 배포가 단순화됩니다.
Docker가 제공하는 관리의 이점
- Monolithic 환경에서도 유용: Docker는 MSA뿐만 아니라 Monolithic 환경에서도 유용합니다.
- Monolithic에서 발생하는 "설정 복잡성"을 해결해 줍니다.
- 애플리케이션과 필요한 환경을 하나로 묶어 관리하기 때문에, 어떤 환경에서도 동일하게 실행 가능.
- 배포 자동화와 결합 가능: Docker는 CI/CD 파이프라인과 잘 어울려 배포를 자동화하고 다운타임을 줄입니다.
결론
- Docker는 Monolithic에서의 관리와 배포 문제를 해결해 주는 도구입니다.
- 로컬에서 준비한 컨테이너를 클라우드로 빠르게 옮길 수 있어, 배포 시간을 줄이고 서버 다운타임도 크게 감소시킬 수 있습니다.
- Docker는 Monolithic 아키텍처에서도 효과적이지만, **Microservices Architecture(MSA)**와 결합하면 더욱 강력해집니다.
알아 두면 좋은 핵심 클라우드 서비스 - 컴퓨팅
| Elastic Compute (EC2) | Lightsail | Lambda |
| - 일반 "컴퓨터" + 오토스케일링 - 가장 많이 쓰임 |
- EC2의 경량화 버전 - 블로그 등 연상량이 작은 서비스 - 실험/교육용에도 쓰임 (비용 저렴) |
- 컴퓨터 X - 특정한 이벤트가 있을 때에 함수 실행 - 호출양 종량제(함수 실행된 것만 비용) |
알아 두면 좋은 핵심 클라우드 서비스 - 통신
| Route 53 | API Gateway |
| - 도메인 관리를 종합적으로 하는 것 - 도메인 구입 - 도메인 - 서비스 연결 - DNS 관리 |
- API 처리는 그냥 하면 되지만 - 명시적으로 API를 정리해놓으면 - 어떤 API를 사용하고 있는지 소개 가능 - API 생성 및 관리를 해주는 것 |
알아 두면 좋은 핵심 클라우드 서비스 - DB 및 저장소
| DynamoDB | RDS | S3 Bucket |
| - NoSQL 데이터베이스 - 표 단위로 관리 - 가볍고 쉬움 - 종량제 지원 |
- 관계형 데이터베이스 - MySQL/ PostgreSQL 등 지원 |
- 간단한 파일 저장소 |
알아 두면 좋은 핵심 클라우드 서비스 - 파이프라인
| Code Pipeline | CloudFormation |
| - 코드 변경 시 자동 업데이트 - GitHub 등과 연동 - Master Branch Merge 트리거 |
- 마이크로서비스 구조 묶음 관리 |