대시보드 활용
대시보드는 KIWI의 "조종석"과 같은 곳입니다. 비행기 조종사가 조종석에서 모든 계기판을 확인하듯이, 여러분은 대시보드에서 모든 서비스의 상태를 한눈에 확인할 수 있습니다.
대시보드를 정기적으로 확인하면 문제를 조기에 발견할 수 있습니다. 작은 경고 신호를 무시하면 나중에 큰 장애로 이어질 수 있으니, 하루에 몇 번은 대시보드를 확인하는 습관을 들이는 것이 좋습니다.
대시보드 접근
경로: [대시보드] 페이지 (/dashboard)
로그인하면 자동으로 이동하는 첫 화면입니다. 전체 서비스의 상태를 한눈에 확인할 수 있어요.
탭 구성
대시보드는 4개의 탭으로 구성되어 있습니다. 각 탭은 서로 다른 관점에서 서비스 정보를 보여줍니다.
개요 탭
가장 많이 사용하게 될 기본 탭입니다. 서비스 상태 요약과 빠른 작업 버튼을 제공합니다.
서비스 상태 이해하기
각 서비스는 현재 상태에 따라 다른 색상으로 표시됩니다. 색상만 봐도 상태를 빠르게 파악할 수 있어요.
- Running: 서비스가 정상 실행 중입니다. 그대로 두시면 됩니다.
- Building: 빌드 진행 중입니다. 완료까지 기다려 주세요.
- Deploying: 배포 진행 중입니다. 완료까지 기다려 주세요.
- Build Failed: 빌드가 실패했습니다. 로그를 확인하여 원인을 파악하세요.
- Deploy Failed: 배포가 실패했습니다. 설정이나 리소스 상태를 확인하세요.
- Stopped: 서비스가 중지되었습니다. 필요시 재시작하세요.
- Registered: 등록만 된 상태입니다. 빌드/배포를 실행해 주세요.
빨간색 상태(Build Failed, Deploy Failed)가 보이면 즉시 확인이 필요합니다. 해당 서비스를 클릭하여 로그를 확인하고, 문제를 해결한 후 재빌드 또는 재배포를 실행하세요.
빠른 작업
서비스 목록에서 각 서비스 옆에 있는 버튼을 클릭하면 해당 작업을 바로 실행할 수 있습니다.
-
빌드: 최신 소스코드로 Docker 이미지를 빌드합니다.
- 코드를 수정한 후 새 버전을 만들고 싶을 때 사용하세요
-
배포: 빌드된 이미지를 선택한 환경에 배포합니다.
- 새 버전을 실제 서버에 반영하고 싶을 때 사용하세요
-
재시작: 실행 중인 서비스의 컨테이너/Pod를 재시작합니다.
- 일시적인 문제가 있을 때 빠르게 복구할 수 있습니다.
파이프라인 탭
서비스가 코드에서 실제 운영까지 어떻게 흘러가는지 시각적으로 보여주는 탭입니다.
Source → Build → Deploy → Operate
파이프라인(Pipeline)은 코드가 작성된 후 실제로 서비스가 되기까지의 일련의 과정을 말합니다. 물이 파이프를 통해 흐르듯이, 코드도 여러 단계를 거쳐 최종 서비스로 전달됩니다.
각 단계에서 확인할 수 있는 정보를 알아보겠습니다.
-
Source: 연결된 Git 저장소, 브랜치, 최신 커밋 정보
- "어떤 코드가 사용되고 있는지" 확인할 수 있습니다.
-
Build: 현재 빌드 상태와 생성된 이미지 태그
- "Docker 이미지가 잘 만들어졌는지" 확인할 수 있습니다.
-
Deploy: 배포 대상 환경과 배포 진행 상태
- "어디에 배포되고 있는지" 확인할 수 있습니다.
-
Operate: 실행 중인 Pod 또는 컨테이너의 상태
- "실제로 잘 돌아가고 있는지" 확인할 수 있습니다.
품질 탭
코드의 건강 상태를 보여주는 탭입니다. 여기서 확인할 수 있는 메트릭(지표)들은 코드의 유지보수성을 나타냅니다.
-
테스트 커버리지: 단위 테스트가 코드의 몇 퍼센트를 검증하는지 보여줍니다.
- 높을수록 좋습니다. 80% 이상을 권장합니다.
-
코드 중복: 비슷한 코드가 여러 곳에 반복되는 비율입니다.
- 낮을수록 좋습니다. 중복이 많으면 유지보수가 어려워집니다.
-
기술 부채: 리팩토링이 필요한 코드의 양입니다.
- 기술 부채가 쌓이면 나중에 개발 속도가 느려집니다.
테스트 커버리지가 낮다면 단위 테스트를 추가하세요. 코드 중복이 높다면 공통 함수나 컴포넌트로 추출하는 리팩토링을 고려하세요.
보안 탭
SAST, SCA, DAST 등 보안 분석 결과를 요약해서 보여주는 탭입니다.
- SAST: 소스코드를 분석하여 보안 취약점을 찾습니다.
- SCA: 사용 중인 라이브러리의 알려진 취약점을 검사합니다.
- DAST: 실행 중인 애플리케이션을 공격해보며 취약점을 찾습니다.
-
취약점 현황: Critical, High, Medium, Low 심각도별 취약점 개수
- Critical과 High는 우선적으로 조치해야 합니다.
-
서비스별 분포: 어떤 서비스에 취약점이 많은지 확인
- 취약점이 많은 서비스에 집중적으로 관심을 가지세요
-
최근 스캔: 가장 최근에 실행된 보안 스캔 이력
- 언제 마지막으로 스캔했는지 확인할 수 있습니다.
-
트렌드: 시간에 따른 취약점 수의 변화 추세 그래프
- 취약점이 줄어들고 있다면 좋은 신호입니다.
서비스 목록 테이블
대시보드의 핵심은 서비스 목록 테이블입니다. 여기서 모든 서비스의 상태를 한눈에 확인하고 관리할 수 있습니다.
컬럼 설명
- 서비스명: 등록된 서비스의 이름입니다. 클릭하면 상세 페이지로 이동합니다.
- 상태: 현재 상태를 배지로 표시합니다. 색상으로 빠르게 상태를 파악하세요.
- 취약점: 심각도별 취약점 개수입니다. 클릭하면 보안 탭으로 이동합니다.
- 마지막 빌드: 가장 최근 빌드 시간입니다. 오래되었다면 새 빌드를 고려하세요.
- 마지막 배포: 가장 최근 배포 시간입니다. 배포 주기를 확인할 수 있습니다.
- 작업: 빌드/배포/재시작 버튼입니다. 클릭하면 즉시 실행됩니다.
필터링
서비스가 많아지면 원하는 서비스를 찾기 어려울 수 있습니다. 필터 기능을 활용하세요.
-
상태 필터: Running, Failed, Stopped 등 특정 상태의 서비스만 표시합니다.
- 예: Failed만 선택하면 문제가 있는 서비스만 볼 수 있습니다.
-
검색: 서비스명으로 검색하여 빠르게 찾을 수 있습니다.
- 서비스 이름 일부만 입력해도 검색됩니다.
아침 점검 시에는 Failed 필터를 먼저 적용해서 문제가 있는 서비스부터 확인하세요. 모든 서비스를 하나씩 확인하는 것보다 훨씬 효율적입니다.
메트릭 패널
대시보드 우측에는 팀의 DevOps 성과를 보여주는 메트릭 패널이 있습니다.
DORA 메트릭 패널
DORA(DevOps Research and Assessment) 메트릭은 Google Cloud 연구팀이 정의한 DevOps 성능 지표입니다. 전 세계 수천 개의 팀을 연구하여 만든 기준이라 객관적인 비교가 가능합니다.
DevOps 성능을 측정하는 4가지 핵심 지표입니다.
- 배포 빈도: 얼마나 자주 배포하는지 나타냅니다. 권장 목표는 일 1회 이상입니다.
- 변경 리드 타임: 커밋부터 배포까지 걸리는 시간입니다. 권장 목표는 1시간 이내입니다.
- 변경 실패율: 배포 후 문제 발생 비율입니다. 권장 목표는 15% 이하입니다.
- 복구 시간: 장애 발생 시 복구까지 걸리는 시간입니다. 권장 목표는 1시간 이내입니다.
더 자세한 내용은 DORA 메트릭 가이드를 참고하세요.
배포 메트릭 패널
배포 현황을 한눈에 보여주는 패널입니다.
- 오늘 배포: 오늘 하루 동안 실행된 배포 횟수
- 이번 주 배포: 이번 주에 실행된 총 배포 횟수
- 성공률: 전체 배포 중 성공한 배포의 비율
- 평균 시간: 배포 시작부터 완료까지 평균 소요 시간
배포 성공률이 90% 이하라면 배포 프로세스에 문제가 있을 수 있습니다. 실패한 배포의 로그를 분석하여 공통적인 원인을 찾아보세요.
실제 사용 시나리오
실제로 대시보드를 어떻게 활용하는지 시나리오별로 알아보겠습니다.
시나리오 1: 아침 상태 점검
매일 아침 출근하면 가장 먼저 해야 할 일입니다. 밤사이에 문제가 생겼는지 확인합니다.
밤 사이에 배포가 실패했거나 서비스에 문제가 생겼을 수 있습니다. 아침에 빨리 발견할수록 사용자에게 미치는 영향을 줄일 수 있습니다.
점검 순서:
- [대시보드] 페이지에 접속합니다.
- 서비스 목록에서 상태 컬럼을 훑어봅니다.
- 빨간색(Failed)이 보이면 문제가 있는 것입니다.
- Failed 상태의 서비스가 있다면 해당 서비스를 클릭합니다.
- 빌드 또는 배포 로그를 확인하여 실패 원인을 파악합니다.
- 문제를 해결한 후 재빌드 또는 재배포를 실행합니다.
시나리오 2: 보안 현황 리뷰
보안 취약점은 해커의 공격 대상이 될 수 있으므로 주기적으로 검토해야 합니다.
리뷰 순서:
- **[대시보드]**에서 보안 탭을 클릭합니다.
- 가장 먼저 Critical과 High 취약점이 있는지 확인합니다.
- 이들은 즉시 조치가 필요합니다.
- 서비스별 취약점 분포를 확인합니다.
- 취약점이 많은 서비스에 집중적으로 관심을 가지세요
- 우선순위가 높은 취약점부터 처리합니다.
- 수정 후 재스캔을 실행하여 해결 여부를 확인합니다.
Critical 취약점은 실제 공격에 사용될 가능성이 높습니다. 발견 즉시 해당 라이브러리를 업데이트하거나 취약한 코드를 수정하세요.
시나리오 3: 배포 성과 분석
주간 회의나 월간 리뷰에서 팀의 DevOps 성과를 분석할 때 활용합니다.
분석 순서:
- **[대시보드]**의 DORA 메트릭 패널을 확인합니다.
- 각 지표가 Elite, High, Medium, Low 중 어떤 등급인지 확인합니다.
- Medium이나 Low 등급인 지표가 있다면 개선이 필요합니다.
- 해당 지표를 개선하기 위한 액션 아이템을 정합니다.
- 보라색(Elite): 최고 수준, 현재 상태 유지
- 파란색(High): 좋은 수준, 조금 더 개선 가능
- 노란색(Medium): 개선 필요
- 빨간색(Low): 즉시 개선 필요
인시던트 관리
인시던트란?
인시던트는 "사건" 또는 "문제 상황"을 의미합니다. IT에서는 서비스에 영향을 주는 예상치 못한 문제를 인시던트라고 부릅니다. KIWI에서는 빌드 실패, 배포 실패 등이 자동으로 인시던트로 기록됩니다.
빌드 또는 배포가 실패하면 KIWI가 자동으로 인시던트를 생성합니다. 이를 통해 문제를 체계적으로 추적하고 관리할 수 있습니다.
인시던트에 포함된 정보:
- 제목: 어떤 문제인지 간략히 요약합니다.
- 서비스: 문제가 발생한 서비스 이름입니다.
- 상태: Open(미해결) 또는 Resolved(해결됨) 상태입니다.
- 발생 시간: 인시던트가 생성된 시간입니다.
- 해결 시간: 해결된 시간입니다. (해결된 경우에만 표시)
인시던트 처리 방법
인시던트를 발견했을 때의 처리 순서입니다.
- 인시던트 목록에서 Open 상태인 항목을 확인합니다.
- 인시던트를 클릭하여 상세 정보를 확인합니다.
- 에러 로그, 관련 배포 정보 등을 볼 수 있습니다.
- 로그를 분석하여 문제의 원인을 파악합니다.
- 원인을 해결합니다 (코드 수정, 설정 변경 등)
- 문제가 해결되면 인시던트 상태를 Resolved로 변경합니다.
인시던트를 해결한 후에는 왜 그 문제가 발생했는지, 어떻게 해결했는지를 팀과 공유하세요. 같은 문제가 반복되는 것을 막을 수 있습니다.
베스트 프랙티스
효과적인 서비스 관리를 위한 권장 루틴을 소개합니다.
일일 루틴
아침, 점심, 퇴근 전. 이 세 번의 점검만으로도 대부분의 문제를 빠르게 발견할 수 있습니다.
- 아침: 전체 서비스 상태를 확인합니다. 밤사이 발생한 문제를 빨리 발견할 수 있습니다.
- 점심: 보안 알림을 확인합니다. 새로운 취약점이 발견되었는지 검토합니다.
- 퇴근 전: 배포 현황과 미해결 인시던트를 확인합니다. 내일 출근 전까지 문제가 생기지 않도록 합니다.
주간 루틴
팀 차원의 개선을 위한 주간 점검입니다.
-
월요일: DORA 메트릭을 리뷰하여 지난 주 DevOps 성과를 분석합니다.
- 지표가 악화되었다면 원인을 파악하세요
-
금요일: 한 주간 발생한 인시던트를 회고합니다.
- 재발 방지 대책을 논의하고 문서화하세요
처음에는 번거롭게 느껴질 수 있지만, 이런 루틴이 몸에 익으면 문제를 조기에 발견하고 빠르게 대응할 수 있게 됩니다. 꾸준히 실천해 보세요.