Skip to main content

관찰 가능성 엔지니어링

관찰 가능성의 역사 & 개념

관찰 가능성의 목표​

  • 운영 환경에서 문제 발생 시 문제를 식별하기 위해 필요한 증거를 찾기 위해서
  • 정상적이던 서비스에 과부하가 걸리는 이유를 알기 위해서
  • 클라이언트의 특정 조건이 내부 서비스의 비정상적인 작동을 유발할 때 CS 발생 이전에 먼저 체크할 수 있을지

클라우드 네이티브 애플리케이션​

  • 전통적으로 모놀리식 아키텍쳐의 확장 방법은 사용가능한 리소스의 수를 증가시키는 것
    • 수직적 확장 - 클라우드 서비스가 제공하는 리소스의 최대 크기까지만 확장 가능하다는 한계점
  • 모놀리식의 신뢰성을 개선하는 것은 실패가 여러번 발생하더라도 문제가 없도록 여러 개의 인스턴스를 배포하여 다운타임을 회피하는 것
    • 수평적 확장 - 모놀리식의 크기에 따라 다르지만 , 대부분 비용의 증가로 연결됨
    • 모놀리스의 모든 컴포넌트를 필요로 하는 상황이 아니라면 리소스를 낭비할 수 있음
  • 모놀리식 아키텍쳐의 경우, 애플리케이션을 구성하는 서비스들이 강하게 결합되어있고, 동일 경계 내에서 작동한다.
  • 마이크로서비스 아키텍쳐의 경우, 서비스들이 느슨하게 결합되어있고, 각자의 경계안에서 독립적으로 작동한다.
    • 더 높은 부하를 처리해야 할수도 있는 컴포넌트에만 확장성을 선택적으로 제공해서 수평적 확장에 장점을 가지게된다.
    • 모놀리식에서 마이크로서비스로 전환시 생기는 과제
      • 레이턴시 발생 가능
      • 예상치 못한 애플리케이션 실패
      • 서비스 간 의존성 오류 발생 가능
      • 서비스 전반 설정/비밀값 관리가 어렵다
      • 복잡한 서비스 오케스트레이션

관찰 가능성의 역사​

  • 관찰 가능성 : 제어 이론에서 관찰 가능성은 시스템의 외부 출력 정보로부터 시스템 내부 상태를 얼마나 잘 추론가능한지 측정하는 척도

중앙 집중식 로깅​

  • 코드가 작동하지 않을 때 기본적인 디버깅 방법은 구문 출력
    • 확장성에는 한계
    • 애플리케이션이 크거나, 여러 시스템에 분산되어있다면 개별 서버의 로그를 검색하는 것은 비현실적
    • 로그가 유실되는 상황 또한 발생가능성 -> 영구 스토리지 기반으로 구성된 중앙 저장소에 로그를 쌓을 필요성 발생 - 중앙화된 로깅의 시작
  • 전체 시스템 데이터에 대한 메트릭을 생성할 기회 제공해준다.
  • Flutend, Logstash, Apache Flume등이 있다.

메트릭과 대시보드​

  • 메트릭 : 관찰 가능성 세계에서 사용할 수 있는 도구 중 가장 잘 알려진 도구
    • 대표적인 예시로 온도계의 온도, 주행거리계의 속도, 시계의 시간이있다.
  • 시스템의 상태를 모니터링할 때 필요한 그래프로 변환되어 의미있는 시각화 제공
    • 오류 비율이 수용가능한 규모를 넘어가는 것과 같이 임계치 도달 경고를 설정 할때 메트릭이 사용
    • 어떤 환경에서 애플리케이션 인스턴스의 수를 늘리거나 잘못된 배포를 롤백하는 것처럼 시스템의 변화에 대한 대응으로 워크플로의 자동화를 위해 메트릭 사용
  • 프로메테우스, Graphite, StatsD, Grafana 등이 있다.

추적과 분석​

  • 애플리케이션 추적 : 애플리케이션 코드를 실행하고 원하는 작업을 제대로 수행하는지 확인할 수 있는 기능을 갖는 것
  • 개발 진행 과정에서 GDB, PDB와 같은 디버거의 도움을 받아 문제를 추적하는 것이 대표적
    • 네트워크를 통해 다수의 서비스가 서로 다른 서버에서 작동하는 애플리케이션을 디버깅시 사용하기 어려움
    • 구글 -> 내부적으로 만든 대규모 분산 추적 시스템 Dapper에 대한 백서 발간
  • OpenTracing, Zipkin, OpenCensus, 예거 등이 있다.

OpenTelemetry의 역사​

  • OpenTelemetry는 OpenTracing과 OpenCensus 프로젝트의 병합으로 2019년 탄생

OpenTracing​

  • 사용자가 시스템을 더 잘 이해하기 위한 수단으로 분산 추적을 채택하는 비율이 증가하는 것에 따른 문제 해결에 집중
  • 분산 추적에 대한 API 스펙 제공
    • 분산 측정을 생성하는 구현과 독립적으로 활용 가능
    • 기본 no-op 구현 : 계측 시 데이터의 생성,수집 방법에 대해 결정을 하지 않더라도 계측 가능
    • 사용자들이 분산 추적 도입으로 인한 발생 비용/서드 파티 라이브러리 품질 측정의 어려움 해결 목적
  • 시멘틱 표기법 제공
    • 계측으로 수집된 원격 측정 결과의 품질을 개선하기 위한 가이드 라인을 포함

OpenCensus​

  • 애플케이션 개발자가 쉽게 애플리케이션을 추적하고, 메트릭을 생산, 수집 가능하도록 라이브러리 제공
  • 독립적인 에이전트로 동작하면서 애플리케이션의 원격 측정 대상 역할 및 컬렉터를 제공하여 스토리지로 데이터를 전송, 분석하도록 설정 가능
  • 원격 측정 데이터는 OpenCensus에서 정의한 형식으로 가공되어 컬렉터로 전송
    • 애플리케이션 수정 없이도 데이터를 필요에 따라 제어할 수 있다.
  • OpenCensus의 분산 추적 API의 개념은 OpenTracing API와 유사
    • OpenCensus는 OpenTracing과 달리 강결합된 API와 SDK 제공
      • 별도의 구현체 설정 필요 X
    • 애플리케이션 개발자의 UX 단순화시킨 장점
    • 서드파티 라이브러리 개발자에게 SDK 의존성을 따르도록 강제하는 단점
  • OpenTelemetry에서 중요하게 다뤄지는 핵심 개념으로 이어짐
    • 측정값 : 기록된 측정의 결과물 또는 생성된 메트릭 포인트
    • 측정 : 기록 대상이 되는 정의된 메트릭
    • 집계 : 측정값이 집계되는 방식
      • 카운트, 분포, 합계, 최종값등의 집계 방법이 제공
    • 뷰 : 데이터를 내보내는 방식을 결정하기 위한 측정과 집계의 결합

제3자 결제 - 애플​

  • 외부 구입 권한 요청 필요
    • 앱 정보/결제 처리 정보/웹사이트 정보 제공 필요
  • Xcode에서 권한 활성화 ( ios/iPados 15버전 이상 기기에서만 호환 )
    • Entitlement plist 파일에 값 추가
      • Key(키): com.apple.developer.storekit.external-purchase
      • Type(유형): Boolean
      • Value(값): True
    • info.plist 파일에 권한 추가
      • Key(키): SKExternalPurchase
      • Type(유형): Array of String
      • Value(값): KR
  • 앱 내 제3자 결제 시스템 제공
    • 앱 내 모달 시트 표시 필요
      • ios/ipadOs 15.4 이상은 StoreKit External Purchase API로 모달 구현가능
      • 이하 버전들은 모달 디자인/텍스트 기준에 맞춰서 모달 구현 필요
  • 앱 심사 제출시 요구사항
    • 외부 결제를 위한 앱내 모달 시트 구현/테스트 필요
    • PSP가 앱에서 거래 완료 준비(PG 실결제 심사 완료 의미하는거 같네요.)
    • 사용자에게 필수 정보 공개 앱 UI 스크린샷 제출물 필요
    • 앱 사용 가능 여부 - 대한민국으로 한정
    • 기존 앱의 새로운 버전이 제3자 결제를 사용하는 경우, 앱스토어에서 기존 앱 삭제 필요
  • 수수료 및 판매 보고서
    • 애플에 수수료 따로 지불 필요 - 26%
    • 디지털 상품/콘텐츠 개별 판매기록 보고서 매달 15일 이내 제공 필요
    • 보고서 기반으로 애플에서 송장 발급 -> 45일 이내로 애플에 대금 납부 필요