‘관찰 가능성을 개발 표준으로’ 데브옵스 모범 수칙 4가지

관찰 가능성은 수많은 마이크로 서비스로 이루어진 현대 클라우드 네이티브 환경에서 꼭 챙겨야 하는 요소다.
 

오늘날 소프트웨어 개발 주기에 관찰 가능성에 대한 수칙을 확립하는 일이 그 어느 때보다 더 중요하다. 미션 크리티컬한 고객과 직원 경험을 제공하기 때문이다. 개발팀은 위급한 사건을 해결하는 시간을 단축하는 데만 신경 쓸 것이 아니라 애플리케이션과 서비스의 관찰 가능성을 높여 안정과 사용 편의성을 끊임없이 개선하는 데도 힘써야 한다. 

로우코드 플랫폼 제공업체 뉴젠(Newgen)의 소프트웨어 개발 수석 부사장 아르빈드 자는 “탄탄한 데브옵스 수칙을 확립하는 일이 최우선이다. 기업이 고객, 직원, 파트너를 위한 디지털 워크플로우와 셀프서비스 옵션을 강화하면서 IT 전문가들은 수많은 애플리케이션을 관리, 유지해야 함은 물론 보안을 공고히 하고 규정을 준수해야 하는 과제를 떠안았다”라고 밝혔다. 

오늘날의 클라우드 네이티브 애플리케이션은 데이터 센터에서 구동되는 이전 세대의 2계층 및 3계층 애플리케이션보다 훨씬 더 복잡하다. 하나의 트랜잭션이 여러 마이크로서비스를 넘나들며, 여러 데이터베이스에 쿼리하고, 타사의 서비스형 소프트웨어와 상호 작용한다. 여러 클라우드에서 구동되기도 한다. 애플리케이션에 오류가 발생하거나 성능이 떨어지는 등 사용자 환경에 문제가 생겼을 때 이를 신속히 해결하려면 모든 데이터가 집약된 단일 정보원이 필수다. 

구체적으로 탄탄한 관찰 가능성 수칙은 다음과 같은 용도에 유용하다.

• 성능 병목 현상을 일으키는 마이크로 서비스 및 API 파악 
• 응용프로그램 오류를 발생시키는 사용자 입력 검토
• 고객 여정을 추적해 사용자가 어려움을 겪고 있는 위치 파악
• 보안 침해 시 인식 및 포렌식 수집
• 개선된 데이터 검증을 통해 해결해야 할 데이터 문제의 원인 파악

다음은 개발팀이 애플리케이션, 마이크로서비스 및 데이터베이스에 관찰 가능성을 확립하는 데 따라야 할 4가지 모범 수칙이다. 
 

1. 데이터 수집 최적화를 위해 협업하기  

모든 앱과 서비스 간에 오가는 JSON 페이로드를 로깅하는 것은 생각보다 좋은 방법이 아니다. 데이터가 너무 많아지면 문제 해결 속도가 느려지거나 근본 원인을 찾는 데 어려움을 겪을 수 있다. 그렇다면 데브옵스 팀은 어떤 데이터를 얼마 동안 수집하고 보관해야 할까? 

인포시스 코발트(Infosys Cobalt)의 부사장 아난트 아디야는 “애자일 개발팀은 개발자와 이해관계자들과 긴밀하게 협력해 목표를 일치시켜야 한다. 그래야 목적에 부합하지 않거나 원하는 결과를 도출하지 못하는 데이터를 수집하지 않을 수 있다”라고 설명했다. 

비즈니스 이해 관계자와 소통해야만 전략을 수립하고 더 높은 서비스 수준 목표에 도달해야 하는 사용자 활동을 파악할 수 있다. 또한 개발자는 민감한 데이터는 배제할 줄 알아야 한다. 이런 데이터는 로그, 데이터베이스 및 관찰가능성 도구에서 수집하기 전에 마스킹하거나 빼야 한다. 

퍼시스턴트 시스템즈의 사전 판매 및 솔루션 글로벌 책임자 아난드 크리슈난은 “관찰가능성에서는 시간과 위치뿐만 아니라 무엇을 기록하느냐가 중요하다. 사용자가 시스템과 애플리케이션을 비롯해 이곳저곳 남긴 흔적을 연결해 중앙 저장소에 모아야 한다”라고 말했다. 

관찰 가능성 데이터를 중앙 집중화하는 작업은 대규모 개발자 팀에게 큰 부담이 되기도 한다. 이런 팀은 빅팬다(BigPanda), 데이터도구(Datadog), 다이나트레이스(Dynatrace), 무그소프트(Moogsoft), 뉴렐릭(New Relic), 옵스램프(OpsRamp) 및 스플렁크(Splunk) 같은 애플리케이션 성능 관리와 AI옵스(AIOps) 플랫폼을 활용할 수 있다. 

오토래빗(AutoRabit)의 고객 성공 담당 부사장 프라샨스 사무드라라는 “품질과 생산성에 대한 명확한 수치로 목표를 설정하고, 핵심 문제를 이해하기 위해 기술 부채를 자주 점검하며 팀의 문제 해결 능력을 끊임없이 발전시켜나가는 것”이 가장 바람직한 관찰 가능성 수칙 중 몇 가지라고 말했다. 
 

2. 운영 문제를 해결하는 데 그치지 않기  

사이트 안정성 엔지니어(SRE), 네트워크 운영 센터(NOC) 및 데브옵스 개발팀은 흔히 애플리케이션 로그, 인프라 경고 및 기타 원격 데이터를 사용해 사고를 관리한다. APM(애플리케이션 성능 관리) 도구, IT 서비스 관리(ITSM) 플랫폼, 자동화 기능 및 AIOps 솔루션을 사용해 사건을 해결하고 근본 원인을 분석한다. 

하지만 SRE나 데브옵스 팀은 더 능동적으로 나설 필요가 있다. 관찰 가능성 데이터와 도구를 사용해 애플리케이션을 개발하고 시험해야 한다. 만타(Manda)의 설립자이자 CEO인 토마스 크라트키는 “관찰 가능성은 QA의 일부다. 사고를 더 빨리 감지하고 해결하는 데 화룡점정이다”라고 강조했다. 

일단 관찰 가능성 데이터와 도구의 사용자를 명확히 구분해야 한다. 자체적으로 구성된 팀은 어떤 개발자, QA 엔지니어, SRE 혹은 사건 관리자가 도구를 담당해 개발팀에 피드백을 제공하고 개선에 책임질지 정해야 한다. 지속적 테스팅 전략에서 관찰 가능성 개선이 빠져서는 안 된다. 

코랄로직스의 개발자 애드보케이트 크리스 쿠니는 “고성과 팀에서 흔히 찾아볼 수 있는 관찰 가능성 방식은 풀스택 관찰 가능성이다. 데이터를 사일로를 방지하는 방법이다”라며 “로그는 한 시스템에, 수치는 다른 시스템에, 트레이스는 또 다른 시스템에 저장하는 대신 모든 것을 한 곳에서 렌더링한다”라고 말했다. 
 

3. 관찰 가능성으로 지속적 개선 추구하기 

특정 엔지니어 그룹이 소프트웨어 품질을 책임지더라도 지속적인 개선을 위해서는 개발팀 전체가 동참해야 한다. 퀄리(Quali)의 R&D 부사장 데이티브 벤 샤밧은 “기업은 내가 ‘표준으로서의 관찰 가능성’이라는 것을 확립하는 데 가담해야 한다. 이를 통해 처음부터 끝까지 팀 전체가 품질과 개선을 책임지는 문화를 조성할 수 있다”라고 말했다. 

로그 같은 관찰 가능성 데이터에 대한 형식을 표준화해 책임 문화를 퍼뜨리는 것이다. 또한 애자일 개발팀은 매 스프린트마다 로그를 검토하고 새로운 오류 경고를 추가할 팀을 지정해야 한다. 샤밧은 이에 더해 “로그와 수치를 표준화해 모니터링 하면서 최대한 많은 프로세스를 자동화하라”라고 덧붙였다. 

애셀데이터(Acceldata)의 공동 설립자이지 CTO인 애쉬윈 라지브도 자동화가 관찰 가능성에 빠질 수 없는 요소라는 데 동의했다. 라지브는 “요즘 데브옵스 관찰 도구는 CI/CI 도구와 통합돼 관련 데이터 소스를 분석하고 자동화로 인사이트와 실시간 권장사항을 제공한다”라고 설명했다. 
 

4. 모니터링과 관찰 작업 통합하기 

과거 모니터링 도구와 관찰 가능성 도구는 별개로 여겨졌다. 모니터링 도구는 NOC, ITSM 및 기타 IT 운영팀의 전유물이었으며, 관찰 가능성 도구는 개발자가 애플리케이션 로그 파일을 한데 모아 문제를 해결하는 데 활용됐다. 하지만 이제 데브옵스 팀은 이 두 가지 도구를 모두 사용해 총체적인 접근방식을 취한다. 

크리슈난은 오류 알림과 모니터링을 통합하는 일이 중요하다고 강조했다. 그는 “원래라면 개발자에게 오류를 알리기 위해 이메일을 보내거나 코어 덤프(core dump)를 만들어야 했다”라며 “그러나 요즘에는 개발자 생태계나 프로덕션 지원 시스템에 이 모든 작업을 통합해야 한다”라고 말했다. ciokr@idg.co.kr