Devops 2일차 - 개발 프로세스와 DevOps 업무 개요

문한성·2023년 3월 8일

devops

부트캠프

목록 보기

2/123

사용자가 서버에 들어오는 과정

https://www.neighbor.tk/login 에 접속한다고 가정
- 위의 URL에서 www.neighbor.tk 부분인 도메인 이름을 IP주소로 변경
- 인터넷 서비스에서 DNS 서비스를 제공
- 웹서비스가 하는 일이 아님(서버에서 만드는 시스템이 아니다)
  - DNS 서버란 무엇입니까?
    
    DNS는 도메인 이름 시스템(Domain Name System)의 약자이며 인터넷 전화번호부와 비슷합니다.
    
    DNS 서버는 FQDN(정규화된 도메인 이름)의 디렉터리와 해당 도메인에 해당하는 공용 IP 주소를 포함하는 컴퓨터 서버입니다.
    
    정규화된 도메인 이름은 호스트 이름, 도메인 이름 및 hostname.domain.tld 형식인 경우 최상위 도메인(TLD)이며 인터넷에서 장치/컴퓨터를 식별하기 위한 인간 친화적인 방법으로 사용됩니다.
    
    DNS 서버는 도메인 이름을 IP 주소로 변환하여 궁극적으로 액세스하려는 웹 콘텐츠를 볼 수 있도록 합니다.
- 서버에 도달 (서버에 도달한 후 부터 서버의 몫)

수직확장 수평확장

https://www.haedongg.net/?p=179

수직확장
- 하드웨어를 기준으로 하드웨어의 사양을 늘린다. (램을 추가하고, HDD를 추가하고, CPU를 추가하는 등)
- 확장에 한계가 있다는 단점과 경우에 따라서는 특정제조사 전용 장비만 써야 하는 등의 단점이 있다.
- 어플리케이션을 수정할 필요는 없다는 장점이 있다. 어플리케이션의 수정, 업데이트가 쉽다.
수평확장
- 기존의 하드웨어는 그대로 두고 장비를 추가하여 소프트웨어적으로 하나처럼 묶는다. 클러스터링 하려는 소프트웨어만 구동할 수 있으면 되기 때문에 하드웨어 종속성이 덜하다.
- 이론상으로는 무한한 확장이 가능하고, 쿠버네티스 같은 오케스트레이션을 이용해 중단 없는 자동확장도 가능하다.
  일반적으로 네트워크로 연결 되므로 네트워크 환경이 좋지 않으면 확장이 불가능하거나, 확장을 해도 원하는 성능을 못 얻는 경우가 있다.
- 어플리케이션의 수정이 필요한 경우가 많고, 각 노드의 반영해야 하므로 작업략이 늘어난다.

분산 시스템

https://iskull-dev.tistory.com/216

분산 시스템은 분산 컴퓨팅(distributed computing) 또는 분산 데이터베이스(distributed databases)로 알려져 있다. 하나의 분산 시스템은 서로 다른 머신들에 위치해 있는 독립된 컴포넌트들의 묶음이다. 이 묶음은 하나의 공통된 목적을 달성하기 위해 서로 메시지를 주고받는다.
분산 시스템은 엔드포인트에서는 하나의 인터페이스 처럼 나타내어진다. 분산 시스템은 하나의 시스템에서 장애가 발생해도 서비스의 가용성에 영향을 미치지 않는것 처럼 리소스를 극대화 할 수 있다.
분산 시스템의 예시
- 네트워크(Networks) - 초기의 컴퓨터들은 로컬 IP 주소로 다른 시스템들에게 메시지를 전송할 수 있었다. Peer-to-peer 네트워크의 발전, 이메일과 인터넷의 발은 모두 분산 시스템의 예시이다.
- 통신망(Telecommunication networks) - 전화와 셀룰러 네트워크는 분산시스템의 한 예시이다.
분산 시스템의 장점
- 수평적 확장이 가능하다 - 머신들을 필요에 의하여 추가할 수 있다.
- 낮은 lantency - 머신을 물리적으로 유저와 가깝게 위치 시킴으로서 지연을 낮춘다.
- fault tolerance - 하나의 서버가 다운되면 다른 서버들이 그 일을 대신 처리할 수 있다.
분산 시스템의 단점
- 분산시스템의 가장 큰 단점은 복잡성이다. 많은 머신들이 존재할수록 더 많은 메세지와 더 많은 데이터들을 서로 주고 받게 된다.
  - 데이터 통합, 일치 - 데이터와 애플리케이션의 상태를 분산시스템에서 동기화 하기 까다롭다. 특지 노드들이 시작할때, 멈출때, 실패했을때는 더욱 그렇다.
  - Network and communication failure - 메시지들이 올바른 노드에 도달하지 않거나 순서가 틀릴경우 통신과 기능 장애를 초래할 수 있다.
  - Management overhead - 더 많은 모니터링, 로깅, 로드 밸런싱이 가식성을 위해 분산 시스템의 연산과 실패에 투입되어야 한다.
분산 시스템의 특징
- 분산 시스템은 반드시 모든 컴포넌트들(머신, 하드웨어, 소프트웨어)이 연결된 하나의 네트워크를 가져야 하고 이를 통해 메시지로 서로 커뮤니케이션을 할 수 있어야 한다.
- 머신들 사이에서 전송되는 메시지들은 이스템이 공유하길 원하는 데이터의 형식(파일, 객체 등)을 포함하고 있어야 한다.
- 분산 시스템을 디자인 할때 고려해야할 주된 trade-off는 복잡도와 퍼포머스이다.

IT 자동화

IT 자동화는 반복 가능한 프로세스를 대체하고 수동 개입을 줄이기 위해 소프트웨어와 시스템을 만드는 프로세스입니다.
IT 자동화는 이전에 사람의 손길이 필요했던 수작업을 자동화하여 IT 인프라와 애플리케이션을 더욱 신속하게 제공합니다.
IT 자동화의 사용 이유
- 자동화는 시간이 많이 소요되는 작업을 대체하고 IT 직원이 IT 운영 및 클라우드 인프라의 증가하는 규모와 복잡성을 따라잡을 수 있도록 하는 데 유용합니다.
- 최신 IT 환경에서는 서비스의 속도와 규모가 너무 커서 대규모의 전담 팀이 관리하기가 어렵습니다. IT 자동화를 통해 팀은 수천 대의 서버를 설정하고 구성하는 등의 작업을 수행하는 것이 일반적이지 않은 환경에서 운영할 수 있습니다.
- 자동화를 적용하는 일반적인 경우
  - 클라우드 자동화
  - 리소스 프로비저닝
  - 구성
  - 네트워크 관리
  - 보안 자동화(모니터링 및 대응)
IT인프라의 자동화를 돕는 툴
- https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=seek316&logNo=222286397839
- Puppet
- Chef
- Ansible
- Saltstack
- Docker
프로비저닝이란?
- 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해두고 필요에 따라 즉시 사용할 수 있는 상태로 준비 시켜두는것이다.
- 프로비저닝의 종류
  - https://blue-mina.tistory.com/34
  - 서버 자원 프로비저닝 - PU, Memory, IO 등의 자원을 할당, 배치하여 운영할 수 있게 제공해주는 것을 말한다. 새로운 시스템을 생성한 후 가동 상태로 만드는 데 필요한 모든 작업과 상태를 정의하는 작업도 포함된다.
  - OS 프로비저닝 - OS를 서버에 설치하고, 구성 작업을 통해 OS를 사용할 수 있도록 제공하는 것을 말한다.
  - 소프트웨어 프로비저닝 - 소프트웨어(WAS, DBMS, 어플리케이션 등)을 시스템에 설치 및 배포하고 필요한 구성 셋팅 작업을 통해 실행할 수 있도록 제공하는 것을 말한다.
  - 계정 프로비저닝 - 근 권한을 가진 계정을 제공해주는 것을 말한다. 직무변경 및 인사이동이 있을 때 접근 권한을 변경하거나 필요 계정을 생성하는 것을 말한다. 롤 기반 액세스 제어(Role-Based Access Control, RBAC) 설정이 그 에시이다. 이는 사용자는 하나 이상의 그룹에 할당되고, 그룹에는 롤이 할당되며, 롤은 권한으로 구성되는 설정을 말한다.
  - 네트워크 프로비저닝 - 사용자, 서버, 컨테이너, IoT 기기가 액세스할 네트워크를 설정하는 것을 말한다. 흔히 통신 업계에서 사용되며, 사용자 무선환경 서비스 활성화도 포함된다.
  - 서비스 프로비저닝 - 서비스 설정과 관련된 데이터를 관리하는 것을 말한다. 주로 고객을 위한 서비스나 클라우드 인프라를 설정하는데 사용되며, 사용자가 IT 직원의 도움없이 셀프 서비스 포털을 통해 클라우드 서비스를 이용할 수도 있다.

Dev vs Ops

https://www.kovair.com/blog/the-battle-dev-vs-ops/

Dev(개발)의 목표

배포 시기전 까지 끊임 없이 개발

Ops(운영)의 목표

배포하기 전에 안전성을 테스트하기 위해 확실한 테스트 수행

Dev와 Ops의 충돌

배포시기에만 Dev와 Ops가 소통을하여 배포전까지 지속적인 개발을한 개발팀과 배포전에 기능을 검증을 다 해봐야하는 운영팀이 충돌이 일어났습니다.

개발 관점에서의 해결책

운영팀과 효과적인 협업을 구축해야 합니다.
Ops가 품질을 모니터링하기 위해 고객 생산 시스템에서 추적해야 하는 품질 메트릭을 파악하는 데 효과적이고 효율적인 참여.
개발자는 코드를 작성하여 현장을 떠날 수 없습니다. 그들은 프로덕션 환경에서 코드가 작동하는 방식을 이해해야 하므로 자신의 코드 테스트에 더 많이 참여해야 합니다.

운영 관점에서 해결책

개발팀과 효과적인 협업을 구축해야 합니다.
운영팀은 빈번한 변경 사항을 보다 유연하게 수용해야 합니다.
스테이징 또는 프로덕션과 같은 모든 실행 환경을 엄격하게 모니터링하여 문제가 발생하거나 생성되는 결함에 즉시 대응할 수 있습니다.
Dev 팀에서 나오는 모든 릴리스 및 빌드의 구조적 관리.

DevOps의 기술적부분과 문화적부분(CI/CD 파이프라인에 근거)

기술 요구 사항

자동화: 기술은 테스트, 빌드, 패키징 및 배포를 포함하여 코드 커밋에서 생산 배포에 이르는 소프트웨어 제공 프로세스의 자동화를 가능하게 해야 합니다.
모니터링: CI/CD 파이프라인은 프로덕션 환경에서 파이프라인 상태 및 애플리케이션 성능에 대한 실시간 가시성을 제공해야 합니다.
확장성: CI/CD 파이프라인은 더 많은 사용자, 더 많은 파이프라인 및 더 많은 배포를 허용하도록 수평으로 확장할 수 있어야 합니다.
보안: 파이프라인에는 코드에 대한 무단 액세스를 방지하고 애플리케이션에 취약성이 도입되는 것을 방지하기 위한 보안 조치가 있어야 합니다.

문화적 측면

https://www.atlassian.com/ko/devops/what-is-devops/devops-culture

커뮤니케이션 및 협업: DevOps는 단지 기술에 관한 것이 아닙니다. 또한 개발자, 운영 및 기타 이해 관계자 간의 커뮤니케이션 및 협업에 관한 것입니다. 팀 구성원은 함께 작업하여 병목 현상과 개선이 필요한 영역을 식별하고 모든 사람이 같은 페이지에 있는지 확인해야 합니다.
지속적인 개선: DevOps는 지속적인 개선 프로세스입니다. 팀은 파이프라인을 개선하고 더 효율적이고 안정적이며 안전하게 만드는 방법을 지속적으로 찾아야 합니다.
소유권: 팀은 파이프라인과 애플리케이션에 대한 소유권을 가져야 합니다. 모두가 애플리케이션의 품질과 성능에 대해 책임을 져야 하며 비즈니스와 최종 사용자의 요구 사항을 충족하도록 협력해야 합니다.
신뢰: DevOps는 팀 구성원 간에 높은 수준의 신뢰가 필요합니다. 개발자는 작업이 코드를 올바르게 배포할 것임을 신뢰해야 하며, 작업은 개발자가 테스트를 거쳐 배포할 준비가 된 코드를 제공할 것임을 신뢰해야 합니다.
요약하면 기술은 DevOps 및 CI/CD 파이프라인의 중요한 측면이지만 문화도 똑같이 중요합니다. DevOps를 실행 가능하게 만들기 위해 팀은 기술과 문화 모두에 집중하여 고품질 소프트웨어를 대규모로 구축, 테스트 및 배포할 수 있는 올바른 도구, 프로세스 및 사고 방식을 확보해야 합니다.