!devops-개념-및-실천-diagram

DevOps 개념 및 실천

📌 핵심 개념

DevOps는 **Development(개발)**와 **Operations(운영)**의 합성어로, 소프트웨어 개발과 IT 운영 간의 장벽을 허물고 협업을 강화하는 문화이자 실천 방법론입니다.

🎯 실제 사례로 이해하기

사례 1: 넷플릭스의 Chaos Engineering

상황:

  • 넷플릭스는 수백만 명의 사용자에게 중단 없는 서비스 제공 필요
  • AWS 인프라의 특정 구성 요소가 언제든 실패할 수 있음

DevOps 적용:

# Chaos Monkey - 무작위로 프로덕션 서버 종료
class ChaosMonkey:
  def __init__(self):
    self.targets = self.discoverInstances()
 
  def attack(self):
    # 랜덤하게 인스턴스 선택 및 종료
    instance = random.choice(self.targets)
    instance.terminate()
    self.logIncident(instance)

결과:

  • 시스템이 장애를 자동으로 복구하도록 설계됨
  • 개발팀과 운영팀이 함께 복원력 있는 아키텍처 구축

사례 2: 아마존의 Two-Pizza Team

상황:

  • 대규모 조직에서 배포 속도 저하
  • 팀 간 의존성으로 인한 병목 현상

DevOps 적용:

# 마이크로서비스 팀 구조
team:
  name: "Payment Service Team"
  size: 8명 # 피자 2판으로 충분한 인원
  ownership:
    - 코드 작성
    - 테스트 작성
    - 배포 수행
    - 모니터링
    - 온콜 대응
  autonomy:
    - 독립적인 배포 파이프라인
    - 자체 데이터베이스
    - 자율적인 기술 스택 선택

결과:

  • 배포 주기: 월 1회 → 일 100회 이상
  • 팀 자율성 증가로 혁신 속도 향상

사례 3: 에어비앤비의 배포 자동화

Before DevOps:

# 수동 배포 프로세스 (2시간 소요)
1. 개발자가 운영팀에 배포 요청 티켓 생성
2. 운영팀 승인 대기 (평균 30분)
3. 수동으로 서버 접속
4. 코드 다운로드 및 빌드
5. 서비스 재시작
6. 수동 테스트 수행

After DevOps:

# .gitlab-ci.yml - 자동화된 배포 파이프라인
stages:
  - build
  - test
  - deploy
 
deploy_production:
  stage: deploy
  script:
    - docker build -t airbnb/app:$CI_COMMIT_SHA .
    - docker push airbnb/app:$CI_COMMIT_SHA
    - kubectl set image deployment/app app=airbnb/app:$CI_COMMIT_SHA
    - kubectl rollout status deployment/app
  only:
    - main
  when: manual  # 버튼 클릭 한 번으로 배포

결과:

  • 배포 시간: 2시간 → 10분
  • 배포 빈도: 주 1회 → 일 3-5회
  • 롤백 시간: 30분 → 1분

🔧 DevOps 핵심 실천 사항

1. Infrastructure as Code (IaC)

사례: 스포티파이의 테라폼 활용

# main.tf - 인프라를 코드로 관리
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
 
  tags = {
    Name        = "spotify-web-${var.environment}"
    Team        = "streaming"
    CostCenter  = "engineering"
  }
}
 
resource "aws_autoscaling_group" "web_asg" {
  min_size         = 3
  max_size         = 10
  desired_capacity = 5
 
  # 트래픽에 따라 자동 확장
  target_group_arns = [aws_lb_target_group.web.arn]
}

이점:

  • 인프라 변경 이력 Git으로 추적
  • 동일한 환경을 몇 분 만에 재현 가능
  • 코드 리뷰를 통한 인프라 변경 검증

2. 지속적 모니터링

사례: 구글의 SRE 모니터링

# prometheus_metrics.py
from prometheus_client import Counter, Histogram, Gauge
 
# 비즈니스 메트릭
user_login_total = Counter(
  'user_login_total',
  'Total number of user logins'
)
 
# 성능 메트릭
request_duration = Histogram(
  'http_request_duration_seconds',
  'HTTP request latency'
)
 
# 시스템 메트릭
active_users = Gauge(
  'active_users',
  'Number of active users'
)
 
@app.route('/login')
def login():
  start_time = time.time()
 
  # 로그인 로직
  result = authenticate_user()
 
  # 메트릭 기록
  user_login_total.inc()
  request_duration.observe(time.time() - start_time)
 
  return result

알람 설정:

# alertmanager.yml
groups:
  - name: service_alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status="500"}[5m]) > 0.05
        for: 5m
        annotations:
          summary: "높은 에러율 감지"
          description: "5분간 5% 이상의 500 에러 발생"
 
      - alert: SlowResponse
        expr: http_request_duration_seconds{quantile="0.95"} > 2
        for: 10m
        annotations:
          summary: "응답 속도 저하"
          description: "95% 요청이 2초 이상 소요"

3. 협업 문화

사례: 페이스북의 Blameless Postmortem

사고 발생 시 “누구 잘못인가?”가 아닌 “어떻게 개선할 것인가?” 초점

# 장애 보고서 예시
 
## 사건 개요
- 일시: 2024-01-10 14:32 KST
- 영향: 유럽 사용자 30% 접속 불가 (15분간)
- 근본 원인: 데이터베이스 커넥션 풀 고갈
 
## 타임라인
- 14:32 - 알람 발생 (에러율 증가)
- 14:35 - 온콜 엔지니어 확인 시작
- 14:40 - 데이터베이스 커넥션 이슈 확인
- 14:45 - 커넥션 풀 크기 증가 (20 → 100)
- 14:47 - 서비스 정상화
 
## 학습 사항
1. 데이터베이스 커넥션 모니터링 부재
2. 트래픽 급증 시 자동 스케일링 미흡
 
## 액션 아이템
- [ ] 커넥션 풀 메트릭 대시보드 추가 (담당: @john, 기한: 1/15)
- [ ] 자동 스케일링 정책 개선 (담당: @sarah, 기한: 1/20)
- [ ] 부하 테스트 시나리오 추가 (담당: @team, 기한: 1/25)

📊 DevOps 성과 측정 (DORA Metrics)

실제 기업 벤치마크

메트릭Low PerformerHigh Performer예시 기업
배포 빈도월 1회하루 여러 번Amazon, Google
변경 리드 타임1-6개월1시간 미만Netflix, Etsy
MTTR (복구 시간)1주 이상1시간 미만Facebook, Spotify
변경 실패율46-60%0-15%Microsoft, Uber

🚀 DevOps 도입 로드맵

Phase 1: 기초 구축 (1-2개월)

# 1. 버전 관리 시스템 도입
git init
git remote add origin https://github.com/company/project.git
 
# 2. 기본 CI 설정
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm test

Phase 2: 자동화 확장 (3-4개월)

# docker-compose.yml - 로컬 환경 표준화
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/myapp
 
  db:
    image: postgres:14
    volumes:
      - postgres_data:/var/lib/postgresql/data

Phase 3: 문화 정착 (6개월+)

  • 정기적인 회고 (Retrospective)
  • On-call 로테이션 도입
  • 지식 공유 세션 (주 1회)

💡 실무 팁

작게 시작하기

# ❌ 한 번에 모든 것을 자동화하려고 시도
# ✅ 가장 반복적이고 오류가 많은 작업부터 자동화
 
# 예: 매일 수동으로 하던 데이터베이스 백업 자동화
import schedule
import subprocess
from datetime import datetime
 
def backup_database():
  timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')
  filename = f'backup_{timestamp}.sql'
  subprocess.run([
    'pg_dump',
    '-U', 'postgres',
    '-d', 'production_db',
    '-f', filename
  ])
  print(f'백업 완료: {filename}')
 
# 매일 새벽 2시에 자동 실행
schedule.every().day.at('02:00').do(backup_database)

🔗 참고 자료