Devops란 무엇인가?

💙베하💙 누구든 탑승할 수 있는 유임승차 팀입니다!!💨😉

한 프로젝트를 하나의 팀으로 만들어 개발, 운영, 모니터링, qa 등을 원팀으로 운영함( 속도 향상 )

 

Devops가 대두되는 이유
Git, Docker, Kubernetes, Terraform, MSA, Cloud 등 계속해서 나오는 기술들

리눅스의 namespace 등장으로 리소스들을 분리해 관리할 수 있게 됨

컨테이너 기술이 등장하고 점차 많이 쓰이면서 Docker가 대세로 떠오르고 컨테이너 관리의 필요성을 느낌 → 컨테이너 오케스트레이션 기술이 발달하게 되면서 쿠버네티스가 대중화됨 컨테이너 / 오케스트레이션이 발전하면서 MSA(Micro Service Architecture) 방법이 쉬워짐

waterfall / agile 방식 클라우드의 발전으로 각 업체들은 서버를 직접 관리할 필요성이 없어짐 → 비즈니스 로직에 집중 → 더욱 빠르게 개발 / 배포

⇒ 모든 것은 생산성 향상을 위해, 속도를 높이고 고객에게 좀 더 빠르게 서비스를 제공할 수 있도록 함!

Devops 문화를 이루기 위해서는?

- Flow / 시스템 사고

 업무 시각화

 진행중인 작업(WIP) 제한

 배치 작업의 크기 줄이기

 핸드오프 횟수 줄이기

 제약조건을 지속적으로 확인하고 향상

 가치흐름에서 어려움과 낭비 제거

 

- 피드백

 복잡한 시스템에서 안전하게 작업

 문제를 발생 시점에서 확인

 스워밍으로 문제 해결과 새로운 지식 축적

 품질 활동을 작업단계에 더 가깝게 유지

 다운스트림 워크센터 최적화

 문제의 확인과 해결을 가능하게 하는 텔레메트리 생성

 더 나은 문제 예측과 목표 달성을 위한 텔레메트리 분석

 개발과 운영의 안전한 코드 배포를 위한 피드백

 가설 주도 개발과 A/B 테스팅을 일상 작업과 통합

 현재 작업 품질의 증가를 위한 리뷰 및 조정 프로세스 생성

- 지속적인 학습과 실험

 조직적 학습과 안전한 문화 활성화

 일상 업무 개선을 제도화

 지역적인 발견을 조직 전체의 개선으로 전환

 일상 업무에 탄력성 패턴 적용

 리더가 학습 문화를 강화

Devops를 이룩하는데 도움을 주는 AWS Service

Devops
- Pipeline(CI / CD)

 리소스와 예산의 상당 부분이 무분별한 통합 및 유지 관리에 사용

 개발 코드가 때때로 production에 도달하지 못함 → 기회 비용 손실

 개발자는 비즈니스 로직이 아니라 환경을 걱정 → 생산성 저하, 만족도 저하, SW 신뢰성 저하

- Git

 SVN → Git을 사용함(이제는 필수)

 Git에도 전략이 있음

  - Git Branch 전략

      Git-Flow

          - 엄격한 제어!

          - 긴 브랜치 수명주기

          - 새로운 code changes 검토에 집중

          - 승인된 개발자의 면밀한 검토 후 merge

          - 항시 유지되는 주요 브랜치 master, develop 2가지와 보조 브랜치 feature, release, hotfix 3가지로 구성

          - 대규모 Code Comflict 주의

 

      TBD (Trunk Based Development)

           - 민첩한 전달!

          - 짧은 브랜치 수명주기 (≤ 2일)

          - 충분히 작은 단위로 쪼개서 빠르게 반영 공유

          - PR 이후 merge까지의 시간을 최소화

          - active branch를 3개 이하로 유지 (merge된 branch는 삭제)

          - feature 브랜치에서 master로 바로 merge

          - develop 브랜치 없음 : Feature Flag 활용

 

 

- SSOT(Single Source Of Truth) 원칙 : 신뢰할 수 있는 하나의 소스코드만 관리하자!

          → 관리포인트를 줄이고 잘 되는 하나를 잘 관리하자!

          → 빠르게 배포가능하도록 하자!

 

 

- GitOps

          SSOT 원칙을 지키고, Git 으로 소스코드를 관리하면서 명확한 코드로 관리하자!

          

          항상 단일한 방식의 배포를 지향하자!

             → 사람마다 다른 방식의 배포 (S3 / FTP / …) 를 허용하지 않는다.

             → prod / qa / test / release /dev 등의 브랜치에 따라 다르게 관리하지 않는다. 코드는 동일하고 config 만 따로 설정하도록 한다.

 

           항상 원천의 상태를 완벽히 반영하자!

             → 쿠버네티스를 예로 들면 미리 정의된 yaml 을 git 에 올려놓고 반영하여 미리 정의된 내용이 운영에 반영될 수 있게 하자!

 

           모든 파일을 Git의 Version Control을 사용하여 형상 관리

           GitOps - argoCD

            - GitOps의 구현체 ArgoCD

            - Git을 이용한 배포 버전 관리

            - 변경 사항 운영 반영 자동화

            - 자가 치유 및 이상 탐지

 

- IaC

  IaC(Infra as a Code) : 인프라(하드웨어 리소스) 또한 코드로 관리하자!

 

 

 

 

길다면 길고 짧다면 짧은 글 읽어주셔서 감사합니다.

다음번엔 더욱 유익한 내용으로 찾아오겠습니다.