Devops 운영진 티타임

Devops 운영진 티타임

운영진 티타임때 이야기를 나누었던 Devops 내용에 대해 간략히 정리해보았습니다. 이야기를 들으면서 빠르게 정리한 것이라 어순이 이상할 수도 있습니다. 양해부탁드립니다.

윈도우 개발 사이클이 3년이다.
waterful, agile 등 의 개발 모델이있다.

원래는 3년 이후의 개발 계획을 세웠다. 좀더 효율적이기위한 개발 모델이 나왔다.
2000년대 초에 agile 개발 모델이 나왔다.

원하는 날짜에 release하기가 쉽지 않았다.

프로세스를 간단화하는 방법? 테스트를 자동화하면된다. 테스트를 코드로 짜서 검사를 자동화 시키면된다.

처음에는 개발자가 테스트 코드를 짜서 사용했다.
요즘에는 테스트 코드가 없고, 커버리지가 70 ~ 80 이되지 않으면 프로그램으로 치지도 않는다.

개발이 끝난다면, 배포를 한다. 배포팀이 따로 있고, 배포를 해주는 사람들이다. 그런데, 배포를 해달라고 개발팀에서 주면 잘 안해준다. 고객과 밀접히 연관되어 있고, 프로그램이 고장나면 대응하기 힘들기 때문이다. 굉장히 보수적이다. 그러나 주기적으로 배포를 해줘야한다. 안그러면 시장 경쟁력이 떨어진다.

요즘 배포, 운영, 관리도 자동으로 할수 없는가? → Devops가 나온 이유이다.

Devops가 신입사원이 하기에는 힘든 직종이다. 아예못하진 않는다고 한다.

Agile 문화 (방법론)

1. 프로세스만들지 말고, 대화를 통해 해결해라.
2. 문서만들지말고 소프트웨어로 해결하라
3. 회사간의 팀원간의 다투지말고 고객이 원하는것으로 나아가자.
4. 자꾸 플랜을 따르고자하는데, 시간이 지남에 따라 트랜드가 변한다. 그러므로 플랜을 따르지말고 변화를 적용하자.

전통적인 운영팀의 역할
운영팀은 다음과 같은 시스템 안전성 중심의 역할을 수행했다.

1. 주요 책임

• 서버 관리: 물리/가상 서버 설치, 설정, 패치
• 프로비저닝: 필요한 리소스를 수동으로 생성 (새 인스턴스 설치)
• 네트워크 설정: 방화벽/보안 정책 적용
• 모니터링: 시스템 상태, 트래픽, 리소스 사용률
• 배포 작업 지원: 수동 또는 배치 스크립트를 통한 릴리스
• 장애 대음 및 복구: 로그 분석, 서비스 복원 등

2. 특징

• 수작업 중심
• 개발팀과 분리된 조직
• 변경을 신중하게 최소화하는 문화
• 자동화보다는 체크리스트 기반 작업 방식

예산을 잡을때, 피크타임 기준으로 잡아야한다. 안그러면 서버가 다운될 수도 있으니까.

대표적으로 아마존에서는 블랙프라이데이때만 서버 사양이 부족하여 가상화라는 방법을 썻다.

서버실에 있는 서버들은 생각보다 많이 죽는다. 즉, 하드디스크가 많이 날아간다. 이걸 대응해야한다.
그렇기 때문에 모니터링을 해줘야한다.

특정한 URL에 Ping 테스트를 하는 것을 통해 모니터링을 한다. 로그들을 수집하여 파싱하고 데이터를 보여주는 방법으로 모니터링할 수 있다.

웹사이트를 배포할 떄는 어떻게 하는가? → 회사마다 standard(규격)이 있다. 그러므로 그것에 따라서 배포를 진행하게된다. 회사의 정책에 따라야한다. 개발자는 그 규정을 지키면서 개발 해야한다.

장애대응을 어떻게 빨리 하는가? → 장애를 얼마나 빨리 복구할 수 있는가?가 중요하다.

투피자팀을 만든다.

Multifunctional team은 팀의 구성원들이 모두 개발자가 아니다. 모두 운영자, 테스터, UX/UI 등 다양한 사람들과 함께 한다.

운영도 개발자가 해야한다.

내가 없더라도 다른 사람이 이해할 수 있도록 코드를 짜야한다. 문서를 만든다던가… 진행척도를 작성한다던가… 본인에게 어떤 일이 생길지 모르기 떄문이다.

데브옵스는 CI/CD처럼 코드를 커밋하자마자 배포도 할 수 있게끔하는 역할도 한다.

3. 핵심개념

• CI/CD: 지속적 통합 및 배포를 통해 빠른 릴리즈 실현
• 자동화: 테스트, 빌드, 배포 자동화로 품질 향상 및 시간 절약
• 협업: 개발 팀과 운영팀 간 장벽을 허물고 공동 책임 문화 조성.
• 모니터링: 실시간 시스템 상태 파악 및 빠른 문제 해결. (로그 기반의 시스템)

4. 주요기술

• CI/CD 도구: Jenkins, Gitlab CI, GitHub Actions
• 인프라 자동화: Terraform, ansible, Chef
• 컨테이너/오케스트레이션: Docker, Kubernetes
• 모니터링/로깅: Prometheus, Grafana, ELK Stack

팀내에서는 다음과 같은 역할들을 해줘야한다.

서버가 응답이 5초 이상이면 서비스 효용성이 없다고 본다. 그러므로 라이트하고 빠르게 증설할수 있게 하는것이 container라는 개념이다.

로그를 저장하는 것도 쉬운일이 아니다. 왜냐하면 분석하려면 파싱해야되기도하고 전세계 대상으로 서비스를 하면 몇 TB의 로그들이 생성되기 때문이다.

나만무때는 Devops가 없기때문에 어떻게 해결할지 고민을 해봐야한다.

5. Devops가 가져한 변화

• 배포 주기가 몇 개월 → 하루 단위로 단축.
• 장애 대응 시간이 단축되고, 롤백이 쉬워짐
• 개발-운영-보안팀 간 협업 강화, DevSecOps로 확장 중

빠르게 배포를 할 수 있게끔 노력한다.

MLOps: 프로덕션 환경에서 기계 학습 모델을 안정적이고 효율적으로 배포하고 유지하는 것을 목표로 하는 패러다임이다.

데브옵스와 agile에 대해서 공부를 하고 싶다면, The Phoenix Project 책을 읽으면 하는 일이나 IT 전반적으로 어떻게 일하고 해결을 하는지 알 수 있는 기회가 될 것이다.

회사마다 쓰고 있는 Devops의 개념이 다르다. 운영팀에서 Devops를 하는데도 있고, 개발팀에서 Devops를 하는 데도 있다. 그래서 회사에 상황에 따라 맞춰서 지책을 나아가야한다.

만약에 알고 싶다면, AWS 라이센스를 공부해보면서 Devops에 대해서 알아보는 것도 좋다.

스크럽: 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중의 하나이다. 소프트웨어 개발 프로젝트를 위하여 고안되었지만 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

CI/CD중에 나만무에서 CI정도는 나만무때 하는게 좋을 것 같다.

본인 코드에 대한 테스트 코드가 있어야한다! → 근데, 교육을 아직 안받았음. 그래도 도전해보는 것이 좋지 않을까 싶다. 그러나 못할 것이라고 생각하신다고한다.