데브옵스 스터디 13~14 장

13장 - 위험도가 낮은 출시를 위한 아키텍처

• 과도하게 결합된 아키텍처

  • 배포 어려움.
  • 유지 보수, 코드 수정에 대한 검증이 어렵고 시간이 많이 소요됨.
  • 변화를 두려워하게 됨.

• 진화적 아키텍쳐
  서비스는 규모가 커짐에 따라 변화해야 한다.

• 교살자 어플리케이션 패턴

  • 기존 기능을 유지한 채, 신규 기능 개발 => API 호출 부에서 교체하여 신규/기존 기능을 공존시킨다.
  • 튼튼한 결합도를 가진 모놀리틱 서비스를 부분적으로 느슨한 결합으로 바꾸는데 용이함.

생산성, 테스트 용이성 및 안전성을 향상하는 아키텍처

• 느슨하게 결합한 아키텍쳐는 모듈이 연결되는 방법을 강제하여 생산성과 안정성을 높인다.
• 서비스 단위로 안전하고 독립적인 배포가 가능한 소규모 팀으로 분할 가능
  • 서비스 지향 아키텍처(SOA)
  • 테스트가 더 편하며 기능 별 SLA 를 좀더 명확히 할 수 있다.
  • 소규모 팀인 만큼 생산성을 향상 시킬 수 있다.

아키텍처의 아키타입 - 모놀리스 vs 마이크로서비스

모놀리스

• 요구사항이 명확하고 빠른 개발이 필요한 경우에 적합하다.
• 하지만 규모가 커짐에 따라 복잡도가 증가하고 유지보수가 어려워진다.

마이크로 서비스

• 각 서비스의 단위가 간단하여 확장 및 테스트가 용이하다.
• 각 서비스 간 네트워크 통신 비용이 발생할 수 있으며, 설계가 복잡하여 초기 개발 비용이 많이 발생한다.

결론

• 모든 제품과 규모에 완벽한 아키텍처는 없다.
• 서비스가 발전하고 변함에 따라 아키텍처도 같이 변화할 수 있다.

엔터프라이즈 아키텍처의 안전한 진화를 위한 교살자 애플리케이션 패턴을 사용하라

• 기존의 강결합 서비스에 대해 적용 가능

• 기존 기능을 유지한 채, 신규 기능을 만들고 두 개를 유지시킨다.
  => API 버전 분리하여 호출
  => 버전을 갖는 서비스 Or 불변 서비스 라고 함.

• 효과
  신규 기능 개발 부담을 줄이고 새로운 아키텍처나 기술로 이전시킬 수 있다.
  기존 기능을 유지하기 때문에 신규 기능에 집중할 수 있으며, 점진적인 이관으로 운영 환경에 대한 영향을 줄일 수 있다.

• 빌딩 블록
  더 크고 복잡한 구조나 시스템을 구성하기 위한 기본 단위나 요소
  예) FE 개발에서 컴포넌트

결론

• 서비스가 운영되는 아키텍처는 운영 시간에 따라 레거시한 아키텍처가 되어 유지보수 시간이 증가한다.
• 이를 해결하기 위해 교살자 패턴 등을 통해 아키텍처를 점진적으로 변경하여 대응해야 한다.

---

14장

문제 확인과 해결을 가능케 하는 텔레메트리를 생성하라.

• 텔레메트리
  원격 장비나 시스템에서 수집된 데이터를 자동으로 전송해 모니터링 및 분석할 수 있게 하는 기술
• 운영 환경에서 텔레메트리를 생성하여 문제를 빠르게 감지하고 해결해야 한다.

엣시의 데브옵스 트랜스포메이션

• 인프라스트럭쳐 변경에 대한 검증 및 확신을 위해선 많은 지표가 필요하다.
• 개발자가 일상 업무의 일부로 기능에 텔레메트리를 추가하고, 안전하게 배포할 수 있도록 추적 및 측정함.
• 이러한 텔레메트리 지표를 바탕으로 사용자가 인지하기 전 빠르게 변화를 감지하고 대응할 수 있게 됨.

중앙 집중식 텔레메트리 인프라스트럭처를 구축하라.

비즈니스 로직, 애플리케이션, 환경 계층에서의 데이터 수집

• 문제가 발생할 때마다 확인할 수 있도록 애플리케이션과 환경을 설계하고 개발해야 한다.
• 애플리케이션과 환경이 충분한 텔레메트리를 생성해야 한다.

이벤트와 지표의 저장을 담당하는 이벤트 라우터

• 생성된 텔레메트리를 수집 및 저장하고 집계해 분석과 상태 점검의 정확도를 높인다.
  예) 프로메테우스, DataDog
• 집중화된 로그를 계산해 지표로 변환하여 시각적인 데이터로 표현하고 이를 통해 데이터 흐름 및 특이점을 좀더 빠르게 찾아낼 수 있다.
  예) CPU/네트워크 등 데이터 사용률의 급격한 증가 확인
• 빌드와 테스트 시간도 수집하여 빌드/테스트 시간 증가 등 문제 상황을 감지하고 프로덕션 배포 전 수정할 수 있다.

프로덕션에 유용한 애플리케이션 로깅 텔레메트리를 생성하라.

• 프로덕션에 배포될 정도로 중요한 기능은 충분한 프로덕션 텔레메트리를 생성해야 한다.
  => 이를 통해 일관되게 동작하는지, 문제는 없는지 확인하고 확신을 가질 수 있다.
• 개발, 운영, 보안 등 다양한 영역에서 발생하는 텔레메트리를 지원하기 위해 로깅 수준(레벨)이 다양해야 한다.
  • DEBUG, INFO, WARN, ERROR, FATAL, etc...

텔레메트리를 사용해서 문제 해결을 안내하라

• 텔레메트리를 통해 수집된 로그, 지표를 바탕으로 문제점을 추적하여 문제에 대한 신뢰성을 높일 수 있다.

일상 업무에서 프로덕션 지표 생성을 활성화하라

• 프로덕션 환경에서 지표를 생성하는 것을 일상 업무에 포함해야 한다.
• 그러기 위해선 누구나 손 쉽게 지표를 생성할 수 있는 방법을 제공해야 한다.
  예) StatsD(에이전트) => Graphite => Grafana

텔레메트리와 정보 방열기에 접근하기 위한 자체 서비스를 생성하라

• 정보 방열기
  팀 내에서 정보를 효과적으로 공유하고 가시성을 높이는 시각적인 도구
• 관계자들에게 시각화된 텔레메트리 정보를 제공할 수 있도록 서비스를 구축해야 한다.
  => Grafana, etc...
• 이로 인해 팀은 텔레메트리를 통해 탐지된 문제를 관계자들에게 공유하고 문제를 올바르게 해결할 수 있게 된다.

텔레메트리의 부족한 점을 파악하고 보완하라

• 애플리케이션 지표와 비즈니스 지표 등 다방면에 걸쳐 구체적인 텔레메트리를 생성해야 한다.

• 개발 관점

  • 인프라 장애를 모니터링해 보안 관련 이벤트를 감지할 수 있다.
    예) 운영 서버 외부 접근 시, 감지 및 알림 발송
  • 애플리케이션 오류 등 문제를 조기에 감지하고 수정하여 영향 받는 고객 수를 줄일 수 있다.

• 비즈니스 관점

  • 사이트에 머문 시간, 제품 링크 클릭 수, 장바구니 제품 수 등 고객 취득 퍼널 데이터를 수집하여 비즈니스에 활용할 수 있다.
  • 사용자 당 검색 시간을 측정하고 검색 시간을 단축하여 사용감을 높이고 구매를 유도할 수 있다.
  • 참고) 퍼널 데이터
    사용자가 특정 목표에 도달하기까지 거치는 단계별 행동 흐름을 측정한 데이터
    각 단계에서의 전환율과 이탈률을 분석해, 서비스의 병목 지점이나 개선 포인트를 찾는 데 활용됨.
    예) 방문 10,000명 → 회원가입 3,000명 → 결제 500명
  • 비즈니스 지표 생성
    예) 회원가입 로그 기록 -> 통계 SQL 작성 -> SuperSet 등 BI 툴로 SQL 결과 제공
    예2) StatsD 로 회원 가입 로그 메트릭 생성 -> Grafana 로 조회(UI 툴 통일)

• 인프라스트럭처 관점

  • 인프라 내부 문제를 파악한다.
    예) 데이터 베이스 SQL 지연, OS, 네트워크 통신 등

결론

• 신속하게 문제 원인을 찾아 해결하기 위해선 텔레메트리 수집이 필요하다.
• 애플리케이션, 데이터베이스, 환경 관계없이 분석할 수 있는 텔레메트리를 생성하고 광범위하게 사용할 수 있어야 한다.
• 이를 통해 고객 만족도를 높이고 문제의 양과 위험도를 감소시킬 수 있다.