일반 - FAQ
로그와 트레이스는 어떻게 다른가요?
로그는 단일 애플리케이션과 해당 애플리케이션에 관련된 이벤트로 제한됩니다. 예를 들어, 사용자가 마이크로서비스 플랫폼에서 호스팅되는 웹 사이트에 로그인하고 해당 사이트에서 구매를 한다면, 여러 애플리케이션에서 해당 사용자와 관련된 로그가 생성될 수 있습니다:
- 프론트엔드 웹 서버
- 인증 서비스
- 재고 서비스
- 결제 처리 백엔드
- 사용자에게 영수증을 보내는 아웃바운드 메일러
이들 각각이 해당 사용자에 대한 무언가를 기록할 수 있으며, 그 데이터는 모두 가치가 있습니다. 그러나 트레이스는 해당 단일 트랜잭션에 걸쳐 모든 개별 구성 요소를 아우르는 사용자의 전체 상호 작용에 대한 단일하고 통합된 뷰를 제공합니다.
이러한 방식으로 트레이스는 단일 활동의 뷰를 보여주기 위해 여러 서비스에서 수집된 이벤트의 모음인 반면, 로그는 해당 로그를 생성한 애플리케이션의 컨텍스트에 종속됩니다.
어떤 신호 유형이 불변인가요?
세 가지 기본 신호 유형(메트릭, 로그, 트레이스) 모두 불변이지만, 일부 구현에서는 이에 대한 보장 수준이 다릅니다. 예를 들어, 로그의 불변성은 많은 거버넌스 프레임워크에서 엄격한 요구 사항이며, 이를 보장하기 위한 많은 도구가 존재합니다. 메트릭과 트레이스도 마찬가지로 항상 불변이어야 합니다.
이로 인해 "잘못된 데이터" 또는 부정확한 데이터를 처리하는 방법에 대한 질문이 생깁니다. AWS observability 서비스에서는 오류로 발생한 메트릭이나 트레이스를 삭제할 수 있는 기능이 없습니다. CloudWatch Logs는 전체 로그 스트림의 삭제를 허용하지만, 수집된 데이터를 소급하여 변경할 수는 없습니다. 이는 의도적인 설계이며, 고객 데이터가 최대한 신중하게 처리되도록 보장하는 중요한 기능입니다.
Observability에서 불변성이 중요한 이유는 무엇인가요?
불변성은 observability에 있어 매우 중요합니다! 과거 데이터를 수정할 수 있다면 시스템과 운영을 발전시킬 때 선택에 영향을 미치는 중요한 오류나 동작의 이상값을 잃게 됩니다. 예를 들어, 시간에 큰 공백을 보여주는 메트릭 데이터 포인트는 단순히 데이터 수집의 부재를 나타내는 것이 아니라 인프라의 훨씬 더 큰 문제를 나타낼 수 있습니다. 마찬가지로, "null" 데이터의 경우에도 빈 시계열조차 가치가 있습니다.
거버넌스 관점에서 애플리케이션 로그나 트레이싱을 사후에 변경하는 것은 부인 방지 원칙을 위반하는 것으로, 시스템의 데이터가 소스 애플리케이션이 의도한 그대로인지 신뢰할 수 없게 됩니다.
폭발 반경(Blast Radius)이란 무엇인가요?
변경의 폭발 반경은 환경에서 잠재적으로 발생할 수 있는 피해 범위입니다. 예를 들어, 데이터베이스 스키마를 변경하면 잠재적 위험에는 데이터베이스의 데이터와 이에 의존하는 모든 애 플리케이션이 포함될 수 있습니다.
일반적으로 변경의 폭발 반경을 줄이는 것이 모범 사례이며, 변경을 더 작고 안전하며 되돌릴 수 있는 단위로 나누는 것이 가능한 곳에서는 항상 권장됩니다.
"클라우드 우선" 접근 방식이란 무엇인가요?
클라우드 우선 전략은 조직이 인프라의 전부 또는 대부분을 클라우드 컴퓨팅 플랫폼으로 이전하는 것입니다. 물리적 서버와 같은 자원을 사용하는 대신 클라우드에 자원을 배치합니다.
코로케이션 하드웨어에 익숙한 사람들에게는 이것이 급진적으로 보일 수 있습니다. 그러나 그 반대도 마찬가지입니다. 클라우드 우선 사고방식을 채택한 개발자들은 서버를 물리적 위치에 묶어두는 것을 상상할 수 없다고 생각합니다. 클라우드 우선 팀은 서버를 개별 하드웨어나 가상 서버로 생각하지 않습니다. 대신, 비즈니스 기능을 수행하기 위한 소프트웨어로 생각합니다.
클라우드 우선은 2020년대에 있어 2010년대의 모바일 우선, 2000년대 초반의 가상화와 같은 것입니다.
기술 부채란 무엇인가요?
Wikipedia에서 인용:
소프트웨어 개발에서 기술 부채(설계 부채 또는 코드 부채라고도 함)는 더 오래 걸리지만 더 나은 접근 방식을 사용하는 대신 지금 쉬운(제한된) 솔루션을 선택함으로써 발생하는 추가 재작업의 암묵적 비용입니다.
기본적으로 레거시 코드, 애플리케이션 또는 수동 프로세스를 제거하지 않고 워크로드에 더 많은 것을 추가하면 시간이 지남에 따라 부채가 축적됩니다. 기술 부채는 절대적 생산성을 감소시킵니다.
예를 들어, 비즈니스에 직접적인 가치를 거의 또는 전혀 제공하지 않는 레거시 시스템의 유지 관리에 시간의 10%를 소비해야 한다면, 그 10%는 지불하는 비용입니다. 기술 부채를 줄이는 것은 가치를 추가하는 새로운 제품을 만드는 효과적인 시간을 늘리는 것과 같습니다.
관심사의 분리란 무엇인가요?
Observability 솔루션의 맥락에서 관심사의 분리란 워크로드 또는 애플리케이션의 기능 영역을 독립적으로 관리되는 개별 구성 요소로 나누는 것을 의미합니다. 각 구성 요소는 별도의 관심사(예: 로그 구조와 로그 발생)를 다룹니다. 기본 코드를 수정하지 않고 구성 요소의 설정을 제어할 수 있다는 것은 개발자가 자신의 관심사(애플리케이션 기능 및 기능 개발)에 집중할 수 있고, DevOps 담당자는 시스템 성능 최적화 및 문제 해결에 집중할 수 있다는 것을 의미합니다.
관심사의 분리는 컴퓨터 과학의 핵심 개념입니다.
운영 우수성이란 무엇인가요?
운영 우수성은 워크로드 운영과 관련된 모범 사례의 수행입니다. AWS는 Well-Architected에 전념하는 전체 프레임워크를 갖추고 있습니다. 운영 우수성을 시작하려면 이 페이지를 참조하세요.