DevOps Concept

최완식·2022년 1월 27일
0

Tech Talks

목록 보기
1/23
post-thumbnail

DevOps라는 단어는 들어봤지만, 그리고 CI/CD라는 단어 역시 들어봤지만 제대로 적용해보지 못했다. 이전 프로젝트에서도 적용하려 했으나, 당장 개발에 급급해서 우선순위에서 밀렸던.. 경험이 있다. 시스템을 만들어두는 것에 관심이 많던 나로서는 정말 아쉬웠다. 이번 기회에 이런 기술, 단어가 나오게 된 이유를 이해하면서 "왜?"와 "어떻게"에 대한 이론적인 부분을 건들여보려고 한다. 빠른 이해를 위해 개조식으로 글을 작성했다.

DevOps란?

  • 서비스 개발과 운영을 통합
  • 왜 필요할까?
    • 개발과 운영이 분리된 전통적 방식
      • 개발팀, 운영팀 분리 되어 있음
      • 개발팀에서 배포 파일을 운영팀에 전달
      • 운영팀에서 배포
      • 운영팀은 모니터링을 통해 개발팀에게 피드백 전달
      • 이렇게 되는 경우 배포사이 개발팀과 운영팀의 커뮤니케이션 비용 증가
      • 문제가 발생했을 때 현상/원인 파악이 어려움
        • 서비스 개발자는 서비스 코드를 잘 알지만 운영 환경에 익숙하지 않음
        • 시스템 운영자는 운영 환경에 익숙하지만 서비스 코드를 잘 모름
      • 긴 주기 배포
      • 하지만 각 분야 전문가가 배치되어 있어 보다 안전하다고 할 수 있음
      • 현재는 빠르게 변화하는 서비스 환경 때문에 다른 방안이 필요
  • DevOps
    • 개발자가 서비스 개발과 운영을 같이 수행
    • 커뮤니케이션 비용 최소화
    • 개발 -> 배포 -> 운영 프로세스 경량화
    • 문제 발생시 원인/현상 파악이 쉬움
      • 모두 잘 아는 개발자가 해결
    • 자동화를 통해 운영 공수를 줄임
    • 짧은 주기 배포 가능
  • 왜 진작 안했을까?
    • 이전에는 서비스 운영에 서비스 개발만큼 혹은 더 많은 지식과 공수를 요구했음
    • 클라우드 환경 보편화
      • 인프라 추상화 레벨의 상승
      • 손쉬운 운영 환경 구성
      • 인프라와 어플리케이션 경계가 희미해 짐
    • 자동화 지원 DevOps 도구들의 개발
    • 모니터링 도구/방식의 발전
    • 운영 공수 경감
  • DevOps의 범위
    • 코드 병합 및 퀄리티 유지
    • 자동화된 코드 배포
    • 모니터링 및 알림
  • 결국 핵심은 모든 개발자가 DevOps가 되는 것이 맞다!

Continuous Integration

  • 코드 병합 및 퀄리티 유지
  • 문제가 있는 코드를 배포하지 않으면 운영 공수를 아주 많이 줄일 수 있음
  • 문제 상황을 빨리 체크하기 위한 시스템
  • 방법
    • 테스트 코드 작성
      • 테스트 코드는 특정 코드가 변경되었을 때 위력 발휘
    • 코드 리뷰
      • 사람이 직접 검증
      • 리뷰는 자동화 어려움
      • 관련 설정을 잘 해두자.
    • 자동화 (CI Tools)
      • 코드 컴파일 및 테스트 코드 실행
      • 코딩 컨벤션 준수 확인
      • 잠재 결함 분석
      • 종류
        • Jenkins
          • 설치형 CI 도구
            • 설치형이기 때문에 설치된 서버를 개발자가 관리해 주어야 함
          • Github hook 연동
            • PR 생성/수정/머지 등 이벤트 발생시 빌드
          • 다양한 플러그인
          • 플러그인 및 서버 관리 필요
  • 권장하는 CI Flow
    • PR 열기 전 코드 작성자가 관련 테스트도 함께 작성
    • PR 열 때 리뷰어 지정, 리뷰어는 코드 리뷰
    • PR open, commit 시 CI Tool에서 자동 PR 빌드 수행 및 리포트
  • Tips
    • 개발자가 자동 수행 작업의 결과를 쉽게 알고 확인할 수 있어야 함

Continuous Delivery

  • 자동화된 코드 배포
  • 적은 공수로 쉽게 배포할 수 있도록 함
  • 어디에 배포할 것인가?
    • Virtual Machine/ Phisical Machine
  • 배포할 환경에 따라 배포 도구 선택
  • 사용 예
    • develop 브랜치에 코드가 머지되면 자동으로 그 시점의 코드를 빌드해서 dev 환경에 배포
    • main 브랜치에 코드가 머지되면 자동으로 그 시점의 코드를 빌드해서 alpha 환경에 배포
    • deploy-beta pipeline을 선택하면 선택한 이미지를 beta 환경에 배포
    • deploy-real pipeline을 선택하면 선택한 이미지를 real 환경에 배포
    • main 브랜치에 코드가 머지되면 자동으로 deploy workflow 실행
    • deploy workflow는 그 시점의 코드를 빌드해서 alpha/beta/real 환경에 배포
    • 각 환경에 배포하는 동작은 수동 approve 요구

Observablity

  • 모니터링 및 알림
  • 시스템 컴포넌트의 각 부분에서 발생하는 일을 외부에서 얼마나 잘 관측할 수 있는지
  • 확보 방법
    • 다양한 방식의 모니터링
      • 로그
      • 트레이스
      • 매트릭
      • 인프라 상태
    • 이상 발견시 자동 알림
    • DevOps에 미치는 영향
      • 모니터링 자동화
      • 문제 발생시 빠른 대응 가능
  • 알림 Tip
    • 알림 정제
      • 설정 이후 지속적인 룰 수정 필요
    • 알림 분류
      • 인지는 하나 바로 수정하거나 대응하지 않아도 되는 알림
      • 바로 대응해야 하는 알림
    • 피로도가 쌓이지 않도록 하는 것이 중요
    • 개발 환경에도 알림 걸어 놓기
    • 개발환경의 시그널을 무시하지 않기

요약

  • DevOps 프로세스 구축
    • 코드 병합 및 퀄리티 유지 (CI)
    • 자동화된 코드 배포 (CD)
    • 모니터링 및 알림
  • 부족한 부분은 그때그때 임기응변 후 DevOps 프로세스에 녹이자
  • 다양한 플랫폼을 적극적으로 활용해서 공수를 줄이자
profile
Goal, Plan, Execute.

0개의 댓글