DevOps

데브옵스(DevOps)란?

소프트웨어의 개발(Development)과 운영(Operations)의 합성어로, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 즉 시스템 개발과 운영을 병행 및 협업하는 것이다.

• 개발자는 개발이 완료된 시스템을 운영팀에게 이관하고 운영팀은 개발된 시스템을 배포/관리 운영한다.
• 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것이 목적이다.

특징

서로 주어진 업무로 전문적인 자기 분야에 집중할 수 있기 때문에 높은 퀄리티와 책임감으로 위험 감소가 보장된다. 협업을 위해서 개발자는 운영자를, 운영자는 개발자를 생각하는 오픈 마인드를 가지고 커뮤니케이션 되어야 한다.

데브옵스의 문제

• 시스템 발생 장애 : 서로 책임 전가하느라 클라이언트의 요구사항 반영이 늦어진다.
• 추가되는 이슈와 요청 사항 거절

노옵스 (NoOps)

운영자가 없다는 뜻

개발자가 발전된 인터넷으로 지식, 각종 오픈소스, 클라우드를 통해 시스템 운영자 없이도 네트워크 및 서버 등 다양한 설정을 습득하여 직접 처리

장애 발생 또는 요구사항의 대응과 처리 속도가 빠르고 조금 더 효율적이다.

트렌드

• DevOps Zone

알아가기

• SRE(Site Reliability Engineering) 조대협님 블로그 발췌

DevOps는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다.

DevOps를 실무에 적용하는 방법은 상당히 어려운 문제였고, 여전히 운영팀은 필하였고 그 역할이 크게 바뀌지 않았다. DevOps를 하는 기업들을 보면 기존개발팀/운영팀이 있는데 새롭게 DevOps 팀을 만들거나 운영팀 간판을 DevOps 팀으로만 바꾸는 결과들이 있었다.

개발팀은 주어진 시간내에 새로운 기능을 내기 위해서 개발 속도에 무게를 두고, 운영팀은 시스템 안정성에 무게를 둔다.

DevOps는 이러한 두팀을 한팀에 묶어 놓고 운영하는 문화이자 운영 철학이다. 운영팀과 개발팀을 묶어 놓으면 운영을 하던 사람들은 무엇을 하는가?

그 해답을 구글의 SRE(Site Reliability Engineering)에서 찾을 수 있다. 개발자가 셀프 서비스로 운영을 하려면 그 플랫폼이 자동화 되어 있어야 한다. 애플리케이션을 빌드하고 유연하게 배포하고, 이를 모니터링 할 수 있는 플랫폼이 필요한데, SRE의 역할은 이러한 플랫폼을 개발하고, 이 플랫폼 위에서 개발자들이 스스로 배포, 운영을 하는것이 목표이다. 물론 완벽한 셀프 서비스는 불가능하다. 여전히 큰 장애 처리나 배포등은 SRE 엔지니어가 관여하지만 많은 부분을 개발팀이 스스로 할 수 있도록 점점 그 비중을 줄여 나간다.

1. 가용성에 대한 명확한 정의
2. 가용성 목표 정의
3. 장애 발생에 대한 계획 이러한 원칙에 따라 장애에 대한 책임을 모두 공유한다는 컨셉이다. 즉 장애가 나도 특정 사람이나 팀을 지칭해서 비난 하는게 아니라, 공동책임으로 규정하고 다시 장애가 나지 않을 수 있는 방법을 찾는 것이다.

• SRE engineer의 역할

  • Metric & Monitoring 첫번째는 모니터링 지표를 정의하고, 이 지표를 모니터링 시스템이 올리는 일이다. 구글에서는 서비스에 대한 지표를 SLI (Service Level Indictor)라는 것을 정하고, 각 지표에 대한 안정성 목표는 SLO (Service Level Objective)로 정해서 관리한다. 이러한 메트릭은 시스템을 운영하는 사람과 기타 여러 이해 당사자들에게 시스템의 상태를 보여줄 수 있도록 대쉬 보드 형태로 시각화 되어 제공된다.

  • Capacity Planning 두번째는 용량 계획이다. 시스템을 운영하는데 필요한 충분한 하드웨어 리소스(서버, CPU, 메모리, 디스크, 네트워크 등)을 확보하는 작업이다. 비정상적인 리소스 요청에 대해서도 유연하게 대응할 수 있어야 한다.

  • Change Management 소프트웨어 배포/업데이트 영역 시스템 장애의 원인은 대략 70%가 시스템에 변경을 주는 경우에 발생한다. 그만큼 시스템의 안정성에는 변경 관리가 중요하다는 이야기인데, 이러한 에러의 대부분 사람이 프로세스에 관여했을때 일어나기 때문에 되도록이면 사람을 프로세스에서 제외하고 자동화하는 방향으로 개선 작업이 진행된다.

    1. 점진적인 배포와 변경( 카날리 배포나 롤링 업데이트와 같은 방법 )
    2. 배포시 방애가 발생하였을 경우 빠르고 정확하게 해당 문제를 찾아낼 수 있도록
    3. 문제가 발생하였을때 빠르게 롤백

  • Emergency Response 장애 처리를 뜻한다. 시스템 안정성이란 MTTF(Mean Time to failure : 장애가 발생하지 않고 얼마나 오랫동안 시스템이 정상 작동했는가?) 와 MTTR(Mean time to recover : 장애가 났을때 복구 시간)의 복합 함수와 같은 개념이다. 장애 복구 단계에서 사람이 직접 매뉴얼로 복구를 하게 되면 일반적으로 장애 복구 시간이 더걸린다. 사람이 컨트롤하되 가급적이면 각 단계는 자동화 되는게 좋으며, 사람이 해야 하는 일은 되도록이면 메뉴얼화 되어 있는 것이 좋다. 이것을 "Playbook"이라고 부른다.

  • Culture

    SRE 문화를 전반적으로 만들고 지켜나가는 작업을 해야한다. 전체 조직의 동의와 지원이 필요하고, 특히 경영진으로 부터의 동의와 신뢰가 없다면 절대로 성공할 수 없다. 이런 문화를 만들기 위해서는 크게 3가지 가이드가 있는데 다음과 같다.

    1. 데이타에 기반한 합리적인 의사결정
    2. 서로 비난하지 않고, 장애 원인을 분석하고 이를 예방하는 포스트포턴 문화
    3. 책임을 나눠가지는 문화

• CSP? cloud solution provider의 약자로 다양한 클라우드 환경에서 제공하는 클라우드 서비스 제공업체를 뜻한다.

• 도커란 무엇인가?

docker는 오픈소스 경량 컨테이너 기술이다. 클라우드 및 애플리케이션 패키징 기술이며 응용 프로그램 자동화 또한 적용가능하게 만든다.

• 도커 컨테이너의 장점

1. 효율적이고 쉬운 초기 세팅 제공
2. 애플리케이션 수명주기 명시
3. 구성이 간단하며 docker compose와 상호작용
4. 참고 reference 문서 제공

• 도커의 기능

1. 쉬운 모델링
2. 버전 관리
3. Placement/Affinity
4. 애플리케이션 민첩성
5. 개발자 생산성
6. 운영 효율성

• 도커 단점

1. hostOS에 종속적
2. 컨테이너별 커널 구성 불가

docker로 centos를 설치하면 해당 배포판의 CentOS가 완벽하게 설치되는것으로 아는 분들이 있는데, 배포판은 CentOS가 맞기에 명령어는 CentOS의 명령어를 사용하지만 커널은 HostOS에 종속된다.

ref

• https://yesicando-77.tistory.com/7
• https://www.guru99.com/docker-interview-questions.html
• https://lalla3991.tistory.com/19
• https://blog.neonkid.xyz/85
• https://bcho.tistory.com/1325