학습 목표
- 애플리케이션 배포가 어떤 의미인지 설명할 수 있다.
- 전통적인 소프트웨어가 사용자에게 도달하기까지 어떤 과정을 거치는지 설명할 수 있다.
- 현대의 웹 서비스가 사용자에게 도달하기까지 어떤 과정을 거치는지 설명할 수 있다.
- CI/CD 파이프라인에서의 지속적 통합, 지속적 전달, 지속적 배포가 무엇인지 정의할 수 있다.
- CI/CD 파이프라인에서 각 단계의 순서를 기억할 수 있다.
- DevOps라는 개념이 어떻게 생겨났는지 배경을 이해할 수 있다.
- DevOps의 범위가 무엇인지 이해할 수 있다.
애플리케이션 배포
- 고전적인 소프트웨어 배포 방법
- CD/DVD or setup.exe/install.msi 등 설치 파일
- 현대의 웹 애플리케이션은 어떻게 소비자에게 전달되고 있는가? (배포 방법)
- 단점
- 설치의 어려움: 하드웨어의 종류에 따른 별도 SW
- 유지 및 보수의 어려움: 방문, 재설치, 업데이트 등을 통한 유지보수
- 높은 초기 비용
- SaaS : Software as a Service
- 클라우드를 통해 제공되는 SW
- 별도의 설치나 전환 과정 없이 퍼블릭 클라우드에 설치되어 있는 SW를 인터넷을 통해 제공받는 서비스
- 장점
- 간편한 설치: 인터넷 접속만 가능하다면 서비스 이용 가능
- 쉬운 유지보수와 빠른 업데이트
- 낮은 진입 장벽
- 단점
- 데이터 외부 노출: 데이터 처리 및 보관이 외부 클라우드 서비스에서 이루어지기 때문
- 인터넷 필수: 인프라가 외부와 단절되어 있거나 통신 환경이 열악한 곳에서는 이용할 수 없음
- 형태
- 로그인 타입
- 아이디/패스워드 부여 후 홈페이지를 통해 서비스 이용
- 별도의 설치 시간 필요 없음
- 누구나 빠르게 서비스에 접근 가능
- API 타입
- 퍼블릭 클라우드 속에 설치되어 있는 SW 패키지를 API 형태로 제공하여 기업의 서버(ERP 시스템)에 접목한 후 서비스 이용
- ERP 또는 CRM과 연동성 좋음
- 서비스를 바로 이용할 수 없고 특정 시스템과 연동이 반드시 필요하므로 일반 사용자용으로는 제공되지 않음
- 로그인 타입
- 웹 호스팅 / 서버 호스팅 / 클라우드 차이점
서비스가 사용자에게 도달하기까지
전통적인 소프트웨어 전달 방식과 클라우드 서비스 전달 방식의 비교
- 전통적인 소프트웨어 전달 방식
- 출시 기한을 정해놓고 소프트웨어를 완성하는 폭포수 모델
- 출시 시점에 소프트웨어의 신뢰성, 안정성을 보장할 수 없음
- 소프트웨어 안정성 개선을 위하여 베타 버전 등을 통한 테스트
- 사용자가 항상 최신 상태로 업데이트 해야 하기 때문에 패치를 사용자에게 전달하기 어려움
- 클라우드 서비스의 전달 방식
- 고객의 요구에 민첩하게 대응하여 지속적으로 전달하는 애자일 모델
- 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있음
- 사용자 업데이트에 대한 걱정에서 벗어남
- 하루에 여러 번의 릴리즈도 가능하여 빠른 문제 해결이 가능함
- 다양한 배포 방식 적용이나 A/B 테스트가 가능함
- 빠른 배포를 보장함
- 이를 위하여 전달 Workflow가 수립되어야 하며 자동화가 필수적임
- 독립적인 소프트웨어 패키지(빌드)가 배포로 항상 이어지는가?
CI/CD 파이프라인과 Stage
- CI/CD 파이프라인: 지속적 배포 (Continuous Deployment)
- 지속적 배포 = 지속적 통합 + 지속적 전달
- 지속적 배포란, 모든 코드의 변경이 배포로 이어진다는 것이 핵심
- 지속적 통합 (Continuous Integration)
- Code: 개발자가 코드를 코드 저장소에 Push한다.
- Build: 코드 저장소로부터 코드를 가져와서 유닛 테스트 후 빌드한다.
- Test: 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인한다.
- 필요성
- 버그 일찍 발견
- 테스트가 완료된 코드에 대해 빠른 전달 가능
- 지속적 배포 가능
- 지속적 전달 (Continuous Delivery)
- Release: 배포 가능한 소프트웨어 패키지(artifact)를 작성한다. (배포에 적합한 빌드를 선정한다.)
- Deploy: 프로비저닝을 진행하고, 서비스를 사용자에게 노출한다.
- Operate: 서비스에 생길 수 있는 현황을 파악하고 문제를 감지한다.
DevOps
- 소프트웨어 조직의 팀 구성과 목표
- 개발 조직: 빠르게 새로운 기능을 제공하고 버그 수정 → 잦은 업데이트를 통한 제품 변화
- 운영 조직: 서비스의 안정성과 빠른 성능 유지 → 서비스 구성에 변경을 최소화하여 안정성 확보
| 개발팀(Dev)의 목표 | 운영팀(Ops)의 목표 |
| - 잦은 배포와 업데이트 - 애플리케이션을 통한 쉽고 빠른 새로운 기능(리소스) 제공 |
- 프로덕션 앱의 안정성 - 애플리케이션이 아닌 인프라 관리 |
- AWS
- 애플리케이션과 서비스를 빠를 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합
- 이점: 작업 속도 개선, 릴리즈 빈도와 속도 개선, 안정성, 확장, 협업, 보안
- 문화 철학: DevOps 모델을 사용하는 조직은 전체 개발 및 인프라 수명 주기를 스스로의 책임으로 간주하는 팀들로 구성되어 있어 서비스에 대한 완전한 주인의식을 갖게 됨
- 방식: 소규모 업데이트 자주 수행, 마이크로 서비스 아키텍처 사용, 지속적 통합 및 지속적 전달
- MS Azure
- 고객에게 지속적으로 가치를 제공하도록 지원하는 사람, 프로세스, 기술의 합집합
- 개발, IT 운영, 품질 엔지니어링, 보안 등 단절되었던 역할들이 서로 조율하고 협업하여 안정적이고 뛰어난 제품을 생산할 수 있도록 지원
- 이점: 출시 시간 단축, 시장과 경쟁 지형에 따른 유연한 대웅, 시스템 안정성 및 신뢰성 유지, 평균 복구 시간 개선
- 문화: 협업/가시성/조율, 팀 역할 범위와 책임의 변화(주인 의식), 짧은 릴리즈 주기, 지속적인 학습
- 방식: CI/CD, 버전 제어, 애자일, Infrastructure as code, Configuration Management, 지속적인 모니터링
- DevOps는 새로운 부서(팀)가 아니다. 개발자가 서비스 운영을 책임지는 것도, 서비스 운영자가 개발 업무를 맡는 것도 아니다. 특정 도구나 솔루션으로 구현하는 것도 아니다.
- DevOps는 새로운 개발 문화로써, 개발자와 운영자가 서로 존중하며 신뢰하고 각자의 전문성과 책임을 인정해야 한다. 개발에서 운영까지를 하나의 통합된 프로세스로 묶어내고 툴과 시스템을 표준화, 통합하여 의사소통의 효율성을 확보해야 한다. 만약 서비스가 중단된다면, 누구든지 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야 한다. 고로 DevOps팀은 각 기능에 대하여 기본적인 이해와 기술을 갖춘 전문가들로 구성된 팀이 되는 것이다.
- DevOps는 신뢰성과 보안성을 갖추고 개발 및 배포 사이클을 더욱 빠르게 개선하는 것을 목표로 해야 한다. 개발, 품질보증, 운영의 교집합이 되며, 이 셋이 겹치는 기능교차적 역할을 수행하는 것이다.
출처
- https://aws.amazon.com/ko/devops/what-is-devops/
- https://azure.microsoft.com/ko-kr/resources/cloud-computing-dictionary/what-is-devops/
- Devops의 이해와 구현 Part 1 : Devops 이해하기(개발과 운영은 남이 아니다!), 공학 트렌드 제66호, 소프트웨어공학센터, 황순삼, 2013.09.09.
'Code States > TIL' 카테고리의 다른 글
| [0310] 리눅스 운영체제 - 출력 관련 명령어 (1) | 2023.03.10 |
|---|---|
| [0309] 리눅스 운영체제 - 패키지와 패키지 매니저 (0) | 2023.03.09 |
| [0309] 리눅스 운영체제 - CLI 기본 명령어 (0) | 2023.03.09 |
| [0309] 리눅스 운영체제 - 왜 리눅스인가? (0) | 2023.03.09 |
| [0308] 개발 프로세스와 DevOps 업무 개요 - 규모에 따른 운영 (0) | 2023.03.08 |