DevOps 업무개요 2

Dev와 Ops팀의 목표 차이 그리고 상충되는 부분?

Dev(개발팀)의 목표
- 잦은 배포와 업데이트
- 어플리케이션을 통한 쉽게 빠른 리소스 제공

Ops(개발팀)의 목표
- 프로덕션앱(공식 버전)의 안정성
- 인프라 관리
- 모니터링 및 제어

개발팀은 사용자의 요구조건에 맞춰 잦은 '변화'를 지향해야하지만, 운영팀은 '안정'을 목표로 합니다.

IT 서비스에 대해 프로세스, 도구의 차이, 그리고 서로 다른 목적 등으로 인해 개발팀과 운영팀 간에 충돌이 빈번히 발생하게 됩니다. 이러한 고민에서 데브옵스(DevOps)라는 개념이 출현하게 됩니다.

데브옵스(DevOps)는 개발자와 운영자의 소통, 협업 및 통합을 강조하는 문화, 방법론, 프로세스, 도구 모두를 의미합니다.

이렇게 데브옵스의 정의가 폭넓은 이유는 데브옵스의 시작이 개발팀과 운영팀 간의 충돌에 대한 문제 해결이기 때문이며, 근본적인 문제 해결을 위해서는 시스템과 프로그램 도입 이외에, 개발팀과 운영팀의 협업과 소통 및 통합 그리고 문화적 개선 등 다양한 노력을 수반하기 때문입니다. 

https://post.naver.com/viewer/postView.nhn?volumeNo=28690129&memberNo=15488377

 

DevOps를 실현 가능하게 하기 위해 기술이 필요한 부분과, 기술이 아닌 문화로 풀어야 할 부분은 각각 무엇? (CI/CD 파이프라인에 근거해 답하기)

기술적 구성 요소

1. 코드 기반 인프라 (Infrastructure as Code) 관리 
Code 기반으로 시스템 구축과 운영/배포 환경 구축
인프라 운영/관리 소스의 체크인 및 관리 수행

2. 버전 관리
소스 및 빌드 관리를 위한 단일 시스템
변경 사항을 커밋할 때마다 빌드
빌드 검증 테스트를 자동으로 수행
플래그(Flag)를 통해 기능(Features) 활성화

3. One Step 빌드/배포
한번 클릭으로 빌드/배포(수동)
예약 작접을 통한 빌드/배포
검증 실패 시 배포 중지 및 알림

4. 장애 시 빠른 인프라 배포
문제 발생 시 기존 시스템 수정하지 않고, 재배포
환경 설정 스크립트 수정 및 변경

https://velog.io/@hkjs96/DevOps#%EA%B8%B0%EC%88%A0%EC%A0%81-%EA%B5%AC%EC%84%B1-%EC%9A%94%EC%86%8C

기술적 부분 : Code, Build, Test, Release, Deploy

DevOps의 문화는 한 단어로는 '협업', 두 단어로는 '다기능 협업'이라고 요약할 수 있다. 이세상의 모든 도구와 자도오하 시스템은 개발 팀원과 IT/Ops 저문가가 진심으로 협력하고자 하는 마음이 없다면 쓸모 없다.

DevOps는 도구의 문제를 해결하는 것이 아니라, 사람 간의 문제를 해결하기 때문이다.

회사에서는 열린 커뮤니케이션 채널을 갖추고 정기적으로 대화를 진행하며, 모든 사람이 목표를 지정하고 필요에 따라 조정하고, 고객 만족으느 제품관리팀과 개발팀 모두의 책임이라고 생각한다. 즉, DevOps는 한 팀이 하는 일이 아니라 모든 팀이 함께하는 일이라는 것이다.

https://blog.lgcns.com/1755

문화적 부분 : 전체

DevOps 실현을 위해 기술이 필요한 부분

1. 코드기반 인프라 관리
코드를 기반으로 시스템을 구축하고 운영하는 환경 구축 및 인프라 운영과 관리 소스의 확인

2. 버전 관리
변경 사항 커밋시 빌드, 빌드 검증 테스트를 자동으로 수행, 소스 및 빌드 관리를 위한 단일 시스템 운영

3. One Stop 빌드/배포
한 번에 빌드/배포, 검증 실패 시 배포 중지 및 알림

4. 장애 시 빠른 인프라 배포
문제 발생 시 기존 시스템 수정하지 않고 재배포, 환경 설정 스크립트 수정 및 변경

이는 CI/CD 파이프라인에서 Code, Build, Test, Release, Deploy, Operate를 모두 포함합니다. DevOps는 개발과 운영이 통합하여 유기적으로 협업하는 업무 방식 및 철학입니다. 그래서 Dev팀과 Ops팀이 프로세스와 도구의 차이를 극복하고 빠르고, 안정적이게 업무를 진행하기 위해서는 코드를 시작으로 배포 및 운영까지 모든 과정에서 기술적인 부분이 요구됩니다.

마이크로서비스 아키텍처(MicroService Architecture, MSA) by 컴퓨터월드

단일 어플리케이션을 작은 서비스의 집합으로 구축하는 설계 접근방식, 느슨하게 결합하여 자율적인 서비스를 생성하기 위한 새로운 아키텍처 스타일. 애플리케이션을 작은 단위의 서비스들로 나눠 개발, 각 서비스는 독립적으로 배포 및 운영될 수 있으며, 주로 잘 정의된 HTTP 기반 API를 통해 다른 서비스와 통신하는 단일 목적 기능 단위 모듈로 구성된다.

Docker와 같은 컨테이너 기술을 활용, 작은 테스크들에 초점을 맞춘 분산 구조다.
https://www.comworld.co.kr/news/articleView.html?idxno=49187

[커버스토리] 데브옵스와 마이크로서비스 - 컴퓨터월드

서비스 경량화를 위한 MSA 설계 시 고려사항

https://www.samsungsds.com/kr/insights/1239180_4627.html

서비스 경량화를 위한 MSA 설계 시 고려사항

MSA는 서비스별 모듈화로 확장이 용이하며 독립적인 개발·빌드·배포 체계를 갖춰 신속한 딜리버리가 가능하고 개발 생산성이 향상되는 장점을 가지고 있습니다. 반면 모놀리식 아키텍처에 비해 복잡도가 높으며 서비스가 분산되어 있어 트랜잭션 관리, 장애 추적 및 테스트 등이 쉽지 않은 단점도 있습니다.