01. 클라우드
● 클라우드 (Cloud)
- 정식 명칭 : Cloud Computing
- 인터넷을 통하여 CPU, 메모리, 데이터 스토리지, 네트워크 같은 서비스를 제공하기 위한 컴퓨팅 자원을 제공
● 장점
- 유연성
-- 필요한 만큼 서버를 증설 가능
-- 사용하지 않을 때는 얼마든지 반납 가능
- 비용 추산
-- 사용하는 만큼 비용이 청구되기 때문에 비용을 계획 가능
-- 관리자는 언제든지 현재 사용하고 있는 자원들의 비용을 모니터링하고, 기업은 비용을 미리 예측 가능
- 가용성
-- 인터넷이 되는 곳이라면 장소와 시간에 구애받지 않고 서버 모니터링 가능
- 글로벌 서비스
-- 클라우드 사업자는 전 세계에 데이터 센터를 보유하고 있고, 전 세계에 서비스를 제공함
-- 시간과 거리에 구애받지 않으면서 빠르고 효율적인 서비스를 이용 가능
- 보안의 안전성
-- 클라우드 사업자는 데이터 유출 방지 및 보안을 철저히 하고 있음
-- 데이터의 유실을 막기 위해 데이터를 안전한 여러 곳에 저장해서 언제든지 복구 가능
- 인력의 활용성
-- 과거의 온프레미스 (On-premise) 에서 한 서비스를 운영할 때는 인력이 많이 필요했음
-- 클라우드에서는 온프레미스에서 하던 작업을 훨씬 빠른 시간 내에 운영, 점검, 설치 가능 + 많은 인력 필요 없음
● 고려사항
- 클라우드 서비스 사용 비용은 경우에 따라 합리적이지 않을 수 있음
● 국외 클라우드
- AWS (Amazon Web Service)
- Azure
- GCP (Google Cloud Platform)
● 국내 클라우드
- NCP (Naver Cloud Platform)
- KT Cloud (Korea Telecom Cloud)
- Toast (Toast Cloud)
- Kakao Cloud
- Gabia Cloud
02. GIT
● GIT
- 리눅스 커널 프로젝트 관리를 위해 개발한 분산 버전 관리시스템 (DVCS)
- 파일 변경 이력을 추적하고 사용자 간의 효율적인 공동 작업을 도와주는 오픈 소스 소프트웨어
- 여러 개발자가 함께 프로그램을 만드는 프로젝트에서 협업을 할 때 필수적으로 사용되는 툴
-- 병력적인 개발을 가능하게 하는 핵심 툴
-- 개인 프로젝트로 개발할 때도 GIT 을 이용하면 효율적인 버전 관리가 가능하기 때문에 많은 개발자가 사용하고 있음
● 중앙 집중식 버전관리시스템 (CVCS, Centralized Version Control System)
- 원격 저장소에 모든 버전의 파일을 저장해 두고 수정이 필요한 일부 파일만 받아 업데이트하는 방식
- 대표적인 프로그램 : SVN
- 작업할 파일만 가져와 작업하는 방식은 효율적이긴 하지만 원격 저장소에 문제가 생기면 작업 진행이 중단된다는 치명적인 단점이 있음
● 분산형 버전관리시스템 (DVCS, Distributed Version Control System)
- 원격 저장소에 저장해 둔 데이터베이스 전부를 로컬 저장소에 받아 작업하는 방식
- 각 로컬 저장소가 원격 저장소의 데이터베이스 전부를 가지고 있기 때문에 원격 저장소에 문제가 생기더라도 작업 진행에 문제가 없으며 오프라인 작업이 가능
- 대표적인 프로그램 : GIT
● GIT 을 사용하는 이유
- 버전 관리
-- 파일의 변경 사항이 발생했을 때 또는 수정이 적더라도 그 이전의 파일과 구분해야 할 때 GIT 의 Commit 과 Push 과정을 통해 수정 내용을 설명하는 코멘트와 간단한 기록을 남길 수 있음
-- 나중에 파일을 되돌려야 할 상황이 생기더라도 정리된 각 코멘트를 보고 돌아가고 싶은 지점을 쉽게 찾을 수 있음
- 협업
-- 다수가 동시간대에 작업할 수 있는 비선형 워크플로우 (Non-linear Workflow) 를 지원
-- 브랜치 (Branch) 를 이용하여 비선형적 개발이 가능
-- 각 브랜치가 완성되면 다른 브랜치와 병합 (Merge) 하여 하나로 만드는 협업이 가능
● GIT 사용 순서
1. INIT 또는 CLONE
2. ADD
3. COMMIT
4. PUSH
5. PULL
● GitFlow
- GIT 브랜칭 전략
- 메인 브랜치로 master 와 develop 두 개만을 두고 feature, hotfix, release 등의 네이밍을 가진 브랜치를 사용
● CLI GIT 과 GUI GIT
- CLI GIT : Terminal 방식을 사용
- GUI GIT : 그래픽을 접목해서 GIT 을 더 간편하게 다룰 수 있도록 함
-- ex. Source Tree, Git kraken
● Github
- GIT 을 위한 서버를 대신 운영하고 무료로 쓸 수 있게 해주는 (웹 호스팅을 지원하는) Github 가 등장
03. 데브옵스
● 데브옵스 (DevOps)
- 개발 (Development) 과 운영 (Operations) 의 합성어
- 클라우드로 인해 코드로 인프라 관리가 가능해졌고, 운영의 많은 부분이 자동화됨
- 데브옵스 엔지니어가 구축한 자동화 파이프라인을 통해 지속적인 통합, 배포, 테스팅, 모니터링을 접할 수 있음
- 데브옵스는 비즈니스 측면의 가치를 높이기 위해 개발 (Dev) 과 운영 (Ops) 의 유기적입 협업 (collaboration) 을 강조하는 도구, 프로세스, 방법론, 문화, 철학, 전문적 운동 모두를 포괄하는 것
● 장점
- 협업 강화, 속도, 신속한 제공
- 안정성, 확장, 보안
● 단점
- 데브옵스를 올바르게 적용하는 것이 쉽지 않음
● 데브옵스 툴체인 오픈소스 도구
04. 도커
● 도커 (Docker)
- 컨테이너에서 다양한 서버의 자원들을 원하는 대로 묶어서 손쉽게 실행하고 배포하는 가상화 플랫폼
- 도커는 컨테이너라는 독립된 공간에서 여러 개의 자원들을 원하는 대로 묶어 이미지를 만들고, 이 이미지를 배포해 운영함
- 여기서 이미지는 특정 프로세스를 실행하기 위한 모든 파일 (설치 프로그램, 소스코드, 라이브러리, 환경 설정값 등) 을 하나로 묶은 형태를 의미하고, 도커파일 (Dockerfile) 을 만든 뒤 빌드하면 생성되는 파일
- 따라서 엔지니어가 소프트웨어를 각각 설치하지 않고 매번 설치하는 소프트웨어를 이미지로 만들어 배포하면 손쉽게 설치할 수 있음
- 도커 플랫폼에서는 빌드 및 소스코드를 담고 있는 도커 파일을 Push 함
- 그리고 해당 이미지는 도커 레지스트리에 저장되고, 엔지니어와 개발자들은 해당 이미지를 사용할 수 있음
- 통합 테스트 중 에러가 발생하면 에러 발생 이전 시점의 이미지를 가져와서 다시 사용하는 롤백 (Rollback) 기능을 제공함
● 특징
- 쉽고 빠른 실행 환경 구성
-- 도커 파일을 이용하면 쉽고 빠르게 실행 환경을 구성할 수 있음
-- 원하는 소프트웨어를 묶어서 배포하면 여러 소프트웨어를 설치하지 않고 하나의 이미지로 설치가 가능함
- 가벼운 용량, 비용 절감 효과
-- 도커 컨테이너는 물리적인 서버에 비해 상대적으로 가벼움
- 공유 환경 제공 (Docker Hub)
-- 미리 만들어진 명령어로 손쉽게 내가 원하는 경로에 원하는 버전의 소프트웨어를 배포하고 사용 가능
-- 도커는 공유 서비스인 도커 허브 (Docker Hub) 를 제공함 ▶ 일반적인 GIT 역할을 제공함
- 쉬운 배포
-- 프로그램 개발이 완료되고 솔루션이 만들어지면 해당 환경을 동일하게 배포 가능
-- 이때 도커를 사용하면 개발팀 전원이 동일한 개발 환경을 빠르게 구축하고 만들 수 있음
- 리눅스 친화적
-- 윈도우에도 도커를 설치할 수는 있지만, 결국 도커 파일을 수정하고, 이미지를 빌드하고, push 하는 작업은 리눅스에서 실행해야 함
05. 쿠버네티스
● 쿠버네티스 (Kubernetes)
- 구글에서 개발한 오픈소스 기반의 컨테이너 오케스트레이션 (Container Orchestration)
- 그리스어로 키잡이를 뜻함
- 모놀리식 (Monolithic) 을 마이크로서비스로 나누거나 마이크로서비스 기반 시스템을 처음부터 구축할 때 수많은 서비스만큼 수많은 컨테이너가 생성됨
- 이런 분산 시스템에서 정신없이 많은 컨테이너들을 능숙하게 관리하는 쿠버네티스를 만날 수 있음
● 개념
- 선언적 구성과 컨트롤러
-- 사용자가 원하는 상태 (Desired State) 를 선언해 두면 쿠버네티스가 능동적으로 조치함
-- 컨트롤러는 선언문 (YAML) 이 원하는 상태를 확인하고 현재 상태를 관찰한 후 불일치할 경우 자동으로 조치를 취함
- 암시적 / 동적 그룹화
-- 쿠버네티스의 암시적 / 동적 그룹화는 레이블 (Label) 과 레이블 셀렉터 (Label Selector) 로 수행됨
● 특징
- 지원하는 앱의 유형을 제약하지 않음
- 소스코드를 배포하지 않으며 앱을 빌드하지 않음
- 앱 레벨의 서비스를 제공하지 않음
- 로깅, 모니터링 또는 경보 솔루션을 포함하지 않음
- 기본 설정 언어 / 시스템을 제공하거나 요구하지 않음
- 포괄적인 머신 설정, 유지 보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않음
● 장점
- 서비스 디스커버리와 로드 밸런싱
-- 쿠버네티스는 DNS 이름이나 자체 IP 주소로 컨테이너를 노출할 수 있음
-- 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드 밸런싱하여 배포가 안정적으로 이루어지게 함
- 스토리지 오케스트레이션
-- 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있음
- 자동화된 롤아웃과 롤백
-- 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며, 현재 상태를 원하는 상태로 설정한 속도에 따라 변경 가능
- 자동적인 빈 패킹 (bin packing)
-- 컨테이너가 필요로 하는 CPU 와 메모리 (RAM) 를 쿠버네티스에게 지시하면, 쿠버네티스는 컨테이너를 노드에 맞춰서 리소스를 효율적으로 관리해 줌
- 자가 치유 (self-healing)
-- 쿠버네티스는 컨테이너에 문제가 발생해 죽더라도 시스템에서 현재 상태와 원하는 상태를 비교하여 실패한 컨테이너를 스스로 다시 시작
- 시크릿과 구성 관리
-- 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 가능
● 단점
- 배우기가 어려움
- 지금도 빠르게 변화하며 새로운 API 와 개념들이 추가 및 삭제되고 있으며, 다양한 기술들이 혼재되어 있어 불안정한 모습도 보임
● 쿠버네티스 클러스터
- 컨트롤 플레인과 노드 두 개의 컴포넌트로 분리됨
- 컨트롤 플레인 (Control Plane)
-- 쿠버네티스 클러스터 전체를 컨트롤하는 시스템
-- 컨트롤 플레인은 API 서버, 스케줄러, 컨트롤러 매니저, 클라우드 컨트롤러 매니저, etcd 로 구성
-- API 서버 : 쿠버네티스는 REST API 로 통신하는데, API 서버가 중심이 됨
-- 스케줄러 : 파드 (Pod) 를 적절한 노드에 할당하는 역할
-- 클라우드 컨트롤러 매니저 : 클라우드 플랫폼에 특화된 리소스를 제어하는 역할
-- etcd : 설정값이나 클러스터의 상태를 저장하는 서버
- 노드 (Node)
-- 컨트롤 플레인의 명령을 받고 실제 워크로드를 생성 및 서비스함
-- Kubelet, Kube-proxy, Container runtime 로 구성
-- Kubelet : API 서버와 통신하면서 노드에 할당된 파드와 컨테이너의 생명 주기를 관리함
-- Kube-proxy : 컨테이너의 네트워킹을 담당하며 서비스마다 개별 IP 를 가지게 하고 클러스터 내/외부의 트래픽을 파드로 전달하도록 패킷을 라우팅함
-- Container runtime : 실제 컨테이너를 실행하는 컨테이너 실행 환경
● 쿠버네티스 사용을 돕는 도구
- 헬름 (Helm)
-- 쿠버네티스의 패키지 매니저. 쿠버네티스의 각종 설정을 담고 있는 YAML 파일들을 차트라는 패키지로 쉽게 관리하는 도구
- Weave Scope
-- 시각화 및 모니터링을 위한 도구이며, 컨테이너로 설치 가능
- 랜처 (RANCHER)
-- 컨테이너 워크로드의 관리를 돕는 오픈소스 형태의 멀티 클러스터 관리 플랫폼
06. CI / CD
● CI (Continuous Integration) / CD (Continuous Deployment, Continuous Delivery)
- CI 와 CD 는 지속적인 통합과 지속적인 배포로서, 개발 생산성을 위해 자동화하는 과정을 의미
- CI 가 사용되는 가장 대표적인 공간은 Github
- CI / CD 는 개발 프로세스에 많은 시간을 단축해 주고, 개발자들이 온전히 개발에만 집중할 수 있게 함
● CI
- 지속적인 통합
- 개발자들은 GIT 을 사용함으로써 코드들을 메일 혹은 카카오톡 등을 통해 공유하지 않고 빠르게 합칠 수 있음
- 대표적인 CI 툴 : Jenkins CI, Travis CI, Github Action, TeamCity
● CD
- 지속적인 배포
- CI 로 개발자들이 작성한 코드들을 하나로 묶어 완성된 코드를 사용자에게 자동으로 제공함
- CD 는 서버에 하나로 묶은 파일을 올리는 작업을 자동으로 진행함
● 컴파일 (Compile)
- 개발자가 작성한 코드를 컴퓨터가 이해할 수 있는 언어로 변환하는 과정
● 빌드
- 개발한 코드들을 사용자가 실행 가능한 하나의 가공물로 생성하는 과정
07. CDN
● CDN (Contents Delivery Network)
- 교환되는 정보가 대용량일 경우 데이터를 언제 어디서든 지연 없이 처리하기 위해 등장한 것
-- ex. 온라인 동영상 스트리밍 서비스
- 보안을 강화하고 싶을 때도 활용
- 콘텐츠를 사용자에게 빠르고 안전하게 전달하는 기술
- 서버 분산 네트워크라고도 부르는 CDN 은 본 서버의 기능과 데이터를 분산시켜서 지리적 제약 없이 사용자에게 콘텐츠를 제공함
● 장점
- 대역폭 (동시에 많은 데이터를 보낼 수 있는 정도) 비용이 크게 절감
- 본 서버의 부담을 줄이면서 가용성과 안정성도 향상됨
● 원리
- CDN 은 사용자에게 제공할 콘텐츠와 데이터만 따로 각 지역 서버에 저장해 두는 방식
- 클라이언트가 요청하면 그 클라이언트와 제일 근접한 CDN 서버에서 콘텐츠와 데이터를 제공함
-- 여기서 지역별로 존재하는 CDN 서버를 엣지 (Edge) 라고 함
-- 본 서버에서는 캐싱 (Caching) 을 통해 엣지에 저장함
08. 클라우드 서비스 모델
● 클라우드 서비스 모델 종류
- 어떤 서비스를 제공하는지에 따라 여러 모델이 존재함
- IaaS (Infrastructure as a Service)
- PaaS (platform as a Service)
- SaaS (Software as a Service)
09. 마이크로서비스
● 마이크로서비스 (Microservice)
- 앱은 수많은 기능들의 집합인데, 이 기능들을 작은 서비스 단위로 분리한 것
- 독립적으로 배치될 수 있고 단독 실행이 가능
- 개발 언어가 달라도 상관없음
- 데이터베이스도 각각 자체적으로 보유하고 관리함
- 각 마이크로서비스는 REST API 같은 인터페이스로 느슨하게 결합됨
- 마이크로서비스 덕분에 앱의 배포 주기가 혁신적으로 빨라짐
- 마이크로서비스 아키텍처는 특정 마이크로서비스가 중단되어도 전체 서비스는 중단되지 않도록 설계됨
● 특징
- 서비스를 통한 컴포넌트화 (Componentization via services)
-- 교체 가능한 각 부품처럼 서비스를 모듈화함
-- 부품처럼 존재하는 서비스를 REST API 같은 인터페이스로 연결해서 전체 애플리케이션을 완성
- 비즈니스 역량 기반 팀 (Organized around business capabilities)
-- 역할 또는 기술별로 팀이 존재 (개발팀, 운영팀 등) 하는 것이 아니라, 업무 중심으로 다양한 역량을 가진 사람 (기획자, 디자이너, 프런트엔드 개발자, 백엔드 개발자, 설계자, 테스터 등) 들이 팀을 이루어 서비스를 만드는 것을 의미
-- 팀 구성이 8 명 이내이기 때문에 빠른 커뮤니케이션이 강점
-- 다기능 팀으로서 서비스를 만드는 모든 기술을 갖추고 있음
- 프로젝트가 아니라 제품 (Products not Projects)
-- 프로젝트에서는 개발과 운영이 별개의 개념임
-- 반면 마이크로서비스 팀의 개발은 운영을 포함한 소프트웨어의 전체 라이프 사이클을 책임져야 함
- 똑똑한 끝 지점 단순한 파이프 (Smart endpoints and dumb pipes)
-- 각각의 서비스는 응집도 높게 존재하고, 서비스 간 연결 (결합도) 은 느슨해야 한다는 것을 의미
-- 서비스 도메인 로직은 그 자체로 똑똑한 기능 처리를 하고, 서비스 간 연결은 REST API 와 같은 인터페이스로 단순하게 함
- 분권 데이터 관리 (Decentralized Data Management)
-- 서비스별로 데이터베이스를 갖도록 설계함
-- 따라서 서비스가 독립적으로 존재함
-- 하지만 다른 서비스의 저장소를 쿼리문으로 직접 호출할 수 없고 API 를 통해서만 접근하기 때문에 데이터 일관성 문제가 발생함
-- 그래서 두 서비스의 데이터가 일시적으로 불일치하더라도 결과적 일관성을 갖도록 함
- 분권 거버넌스 (Decentralized Governance)
-- 마이크로서비스 팀으로 구성된 조직은 중앙에 강력한 표준이나 절차의 준수를 강요하지 않음
-- 마이크로서비스 팀은 빠르게 제품을 만드는 것을 목적으로 스스로 효율적인 방법론과 도구, 기술을 찾아 적용함
-- 따라서 서비스별로 목적과 용도에 맞는 다양한 기술과 언어의 활용이 가능함
- 인프라 자동화 (Infrastructure Automation)
-- 클라우드 인프라 내에서 이루어지는 코드형 인프라 (IaC), 지속적인 통합 (CI), 지속적인 배포 (CD), 등 데브옵스 환경은 팀에게 인프라 자동화를 제공하여 개발과 운영을 빠르고 손쉽게 함
- 실패를 위한 설계 (Design for failure)
-- 마이크로서비스는 독립적인 서비스로 존재하기 때문에, 해당 서비스의 중단 (실패) 이 전체 앱 중단으로 이어지지 않음
-- 이것이 가능한 이유는 실패나 오류를 감안한 설계 때문
-- 각각의 서비스를 모니터링하고 있다가 하나의 서비스가 다운되면 이를 호출하는 서비스의 연계를 차단함
- 진화하는 디자인 (Evolutionary Design)
-- 마이크로서비스는 호환성을 중시하는 모듈 방식 설계로서의 이점을 가지고 있음
● 장점
- 크고 복잡한 앱을 지속적으로 통합 / 배포 (CI / CD) 할 수 있음
-- 이는 인프라 자동화에 의한 것
- 서비스 규모가 작아 관리하기 쉬움
-- 이는 서비스를 통한 컴포넌트화, 비즈니스 역량 기반 팀, 분권 거버넌스에 의한 것
- 서비스를 독립적으로 배포 확장할 수 있음
-- 이는 서비스를 통한 컴포넌트화, 분권 데이터 관리에 의한 것
- 마이크로서비스 아키텍처 덕분에 팀이 자율적으로 움직임
-- 이는 비즈니스 역량 기반 팀, 분권 거버넌스에 의한 것
- 결함 격리가 잘됨
-- 이는 똑똑한 끝 지점 단순한 파이프, 분권 데이터 관리, 실패를 위한 설계에 의한 것
- 새로운 기술을 실험하고 도입하기 쉬움
-- 이는 비즈니스 역량 기반 팀, 프로젝트가 아니라 제품, 진화하는 디자인에 의한 것
● 단점
- 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어려움
-- 지속적 통합 및 배포가 마이크로서비스의 큰 강점인데, 역설적이게도 개발, 테스트, 배포가 어렵다고 지적함
- 여러 서비스에 걸친 기능을 배포할 때 잘 조정해야 함
-- 데이터베이스도 서비스 단위로 분할되어 있기 때문에 협력하고 있는 서비스들 사이에서 일어나는 트랜잭션의 일관성 문제가 발생할 수 있음
- 딱 맞는 서비스를 찾기가 쉽지 않음
-- 비즈니스 특성에 맞지 않는 분할은 시스템 전체를 다시 설계해야 할 수도 있음
- 마이크로서비스 아키텍처 도입 시점을 결정하기 어려움
-- 스타트업과 같이 어떤 경우에는 모놀리식이 더 효과적일 수 있음
참고문헌
● 개발자가 되기 위해 꼭 알아야 하는 IT 용어 : https://product.kyobobook.co.kr/detail/S000061352646
