오늘날 소프트웨어 시스템이 점점 더 복잡해지면서 애플리케이션 성능 및 장애 원인에 관한 ‘관찰가능성(Observability)’ 확보가 갈수록 중요해지고 있다.
엔터프라이즈 기술이 계속해서 복잡해지고 있다. 이에 따라 관찰가능성 또는 옵저버빌리티(Observability)라고 부르는 용어가 (갈수록 더) 분산된 인프라를 관리해야 하는 상황에서 인기를 얻고 있다. 다시 말해, 관찰가능성의 필요성이 명확해지고 있다. 현대 경영학의 아버지 피터 드러커가 말했던 ‘측정할 수 없으면 관리할 수 없다(You can’t control what you can’t measure)’라는 격언이 소프트웨어 비즈니스 분야 종사자들에게 이처럼 적절했던 때가 없다.
지난 2020년 3월 대부분의 사람이 레딧(Reddit)의 ‘r/wallstreetbets(위험 투자를 하는 사용자들이 모여 정보를 공유하고 노는 주식 서브레딧(게시판))’가 무엇인지 또는 게임스톱(GameStop) 주식이 얼마에 거래되는지 모르던 시절, 인기 주식거래 앱 로빈후드(Robinhood)는 잦은 서비스 중단으로 고군분투하고 있었다.
당시 로빈후드의 공동창업주 바이주 바트와 블라디미르 테네프는 “(2020년 3월에) 여러 차례 발생한 서비스 중단은 인프라에 가해진 전례 없는 부하 때문”이라고 공식 블로그를 통해 밝혔다.
이는 분명히 비즈니스에 좋지 않다. 로빈후드가 자사 시스템을 통해 이뤄지는 모든 거래에서 소액의 수수료를 받고 있기 때문이다. 또한 인터넷을 통해 주식 거래를 민주화하려는 기업으로써 이는 빈후드의 평판에도 좋지 못하다. 심지어 이런 서비스 중단은 고점에서 매도하지 못하거나 저점에서 매수하지 못해 불만을 품은 사용자들의 소송으로 이어질 수도 있다.
따라서 인프라에 가해지는 부하가 고객에게 영향을 미치기 전에 이를 찾아내거나 혹은 최소한 이런 사건의 범위를 제한할 수 있는 역량이 경영진 사이에서 우선순위로 떠오르고 있다. 로빈후드와 같은 기업에서는 더욱더 그렇다.
클라우드 기반 소프트웨어의 복잡성을 통해 오늘날 기업들은 디지털 서비스를 효과적으로 확장할 수 있지만 반대로 이런 복잡성으로 인해 예측하거나 즉시 해결하기 어려운 병목현상과 종속성이 발생한다.
美 클라우드 기반 애플리케이션 성능 관리(APM) 솔루션 기업 뉴렐릭(New Relic)의 유럽, 중동, 아프리카 지역 CTO 그렉 윌론은 “매일 수천 개의 마이크로서비스, 수백 개의 릴리즈, 수십만 개의 컨테이너가 생성되는 상황에서 인간의 눈이 이 어마어마한 복잡성에 대처할 방법은 없다”라고 말했다.
‘관찰가능성’을 통해 오늘날의 IT 복잡성을 활용할 수 있다
관찰가능성은 외부 출력을 사용해서만 시스템의 내부 상태를 관찰할 수 있다는 제어 이론(Control Theory)에 뿌리를 두고 있다. 특히 소프트웨어 부문에서 이는 지표, 이벤트, 로그, 추적의 원시 데이터를 가져와 시스템 성능과 문제가 발생할 수 있는 지점을 실시간으로 파악할 수 있도록 하는, 모니터링의 자연스러운 발전이다. 이를 통해 개발자들은 복잡한 시스템을 감싸고 있는 블랙박스를 벗겨낼 수 있다.
이와 관련해 대부분 기업에서 직면하는 과제는 대규모로 분산된 시스템에서 생성되는 데이터의 양이 엄청나다는 것, 그리고 사용자가 영향을 받기 전에 충분히 신속하게 문제를 파악하고 대응할 수 있는 확장 가능한 방법을 찾는 것이다.
네트워크 및 애플리케이션 성능 모니터링 부문을 전문으로 하는 가트너 애널리스트 조쉬 체스맨은 “컨테이너와 마이크로서비스는 너무 복잡하다. 인터랙션도 매우 방대하다. 이를 이해하기란 사실상 불가능하다. 더 많은 도구를 추가하면 데이터가 더 많이 늘어나고 그 누구도 모든 데이터를 살펴볼 수 없게 된다. 모래사장에서 바늘 찾기다. 관찰가능성이 중요한 이유다”라고 전했다.
팬데믹 위기는 어떻게 관찰가능성을 발전시켰나?
코로나19 사태로 인해 클라우드 지출이 전반적으로 증가했다. 이는 점점 더 많은 기업이 클라우드에 수반되는 복잡성을 모니터링하고 해결하게 될 것이라는 의미다.
윌론은 “훨씬 더 복잡한 IT 및 개발 환경 내에서 그리고 지속적인 클라우드 마이그레이션과 가속화된 애플리케이션 현대화 과정에서 전체 소프트웨어 인프라를 확인하는 것은 필수가 됐다”라고 언급했다.
분산 추적 솔루션 스타트업 오미니션(Ominition)의 공동설립자 스파이로스 잔토스는 분산 소프트웨어 시스템을 효과적으로 모니터링하는 데 필요한 도구를 수년 동안 개발해왔다. 이 회사는 지난 2019년 스플렁크(Splunk)에 인수돼 그는 현재 스플렁크의 제품 관리, 관찰가능성 및 IT 운영 부문 부사장으로 재직하고 있다. 그는 2020년 한 해 동안 관찰가능성에 관한 고객들의 관심이 높아졌다고 밝혔다.
그는 “2018년에 기술 부문의 많은 클라우드 네이티브 기업들이 관찰가능성에 관해 이야기했었다. 그리고 지난해 대기업들이 클라우드 네이티브 기술을 채택하고 관찰가능성에 관심을 가지면서 이것이 점차 주류가 되어가고 있는 모양새다”라고 말했다.
한편 영국의 TSB 은행은 2018년 핵심 뱅킹 시스템 마이그레이션 실패로 최악의 서비스 중단 참사를 겪고 난 이후, 경영진 차원에서 안정성 및 사고 대응을 최우선 순위로 삼았다. TSB의 최고운영책임자(COO) 수레시 비스바나단은 “대규모 시스템 중단이 없고 있다 하더라도 소수의 고객에게만 국한되도록 클라우드에 맞춰 시스템을 구성하고 싶었다”라고 전했다.
TSB는 더 이상 데이터센터를 소유하거나 운영하지 않는다. 따라서 이 회사의 콜센터 시스템은 BT의 클라우드에 있고, CRM은 마이크로소프트 다이나믹스 365(Microsoft Dynamics 365)이며, 핵심 뱅킹 시스템은 IBM이 관리하고 있다. 몇 가지 주요 파트너만 언급하긴 했지만 이 모든 것이 마이크로서비스와 API로 복잡하게 연결돼 있다. 그리고 이는 관찰가능성이 필요한 좋은 예다.
비스바나단은 “이론적으로 보면 이러한 플랫폼들을 모두 교체할 순 있지만 그 사이에서 무엇이(예: 장애) 발생할지 파악할 수 있는 도구가 없었다”라며, 그래서 다이나트레이스(Dynatrace)의 모니터링 솔루션을 사용해 가시성을 확보하고 있다고 밝혔다.
이어서 그는 “관찰가능성은 단순한 도구가 아니다. 문화적 여정이다. 이를 통해 고객들에게 어떤 일이 일어나고 있는지 추적하고 이를 관리할 수 있다. 문제를 선제적으로 파악하기 위해서 중요하다”라고 덧붙였다.
관찰가능성을 달성하는 3대 요소를 넘어서
클라우드 기반 애플리케이션 모니터링 솔루션 업체 데이터독(Datadog)의 CEO 올리비에 포멜은 지난 2018년 이 회사가 개최하는 대시(Dash) 컨퍼런스에서 일반적으로 관찰가능성을 달성하는 3대 요소라 불리는 ‘지표(metrics), 추적(traces), 로그(logs)’를 설명했다. 각 요소는 시스템을 모니터링하는 범주를 나타낸다. 이 요소들을 한데 모으면 관찰가능성에 도달할 수 있다.
英 여행 예약 플랫폼 트레인라인(Trainline)의 엔지니어링 책임자 댄 타일러는 “개발자들의 경우 이 세 가지를 오랫동안 확인해왔기 때문에, 부르는 이름을 달리한다고 해서 딱히 도움이 되진 않는다. 개발자들에게 있어서 핵심은 이 세 가지 기술적 부분을 넘어서 개별 구성 요소가 아닌 전체적인 관점으로 시스템을 살피는 것”이라고 말했다.
트레인라인은 외부 여행업체들이 해당 예약 플랫폼에 연결될 수 있도록 하는 상호연결형 마이크로서비스와 수백 개의 API로 구성돼 있다. 오늘날 복잡한 애플리케이션의 전형이라고 할 수 있다. 이로 인해 일관된 방식으로 관찰하기 어려운 수많은 종속성이 발생한다. 특히, 개발팀에 소프트웨어 관리 방법에 관한 자율성을 제공하고 싶은 경우에는 더욱더 그렇다.
테일러는 “얼마나 많은 것을 기록해야 하는지 또는 어떤 지표가 중요한지 알려주는 것보다는 이것들이 고객 및 기업에 미치는 영향을 이해하고 연계시키는 것이 중요하다”라고 조언했다. 다시 말해, 도구는 시작에 불과하다. 이 정보의 가치를 이해하고, 이것이 고객 및 엔지니어들에게 어떻게 도움을 줄 수 있는지 파악하는 것이 더욱더 중요한 부분이다.
이를테면 포르쉐 산하 소프트웨어 회사 포르쉐 인포매틱(Porsche Informatik)의 인프라 및 클라우드 서비스 책임자 피터 프리드와그너에 따르면 “고객들은 서비스를 24시간 내내 사용하길 원한다. 이를 위해서는 고객이 문제를 인지하기 전에 문제의 근본 원인을 파악해야 한다. 인프라 전반에 걸쳐 모든 구성 요소에 관한 통합 모니터링이 필요했다”라고 언급했다.
이 회사는 유럽 전역에서 5,000명의 자동차 딜러들이 사용하는 딜러 관리 시스템을 호스팅하고 있으며, 이 시스템은 업타임(가동 시간)이 중요하다. 최근에는 이 단일 온프레미스 애플리케이션을 마이크로소프트 애저 퍼블릭 클라우드와 온프레미스 모두에서 레드햇 오픈시프트를 사용하여 컨테이너 전반에 걸쳐 호스팅되는 마이크로서비스로 분리했다. 이런 마이크로서비스 간의 통신 패턴을 이해하기가 여전히 쉽지 않은 상황이고, 관찰가능성 도구를 통해 이를 파악할 계획이라고 회사 측은 전했다.
관찰가능성이라는 유행어를 주의하라
체스맨은 “1년 전만 해도 관찰가능성은 유의미하게 사용되는 용어였지만 지금은 유행어가 되고 있다. 많은 벤더가 관찰가능성이라는 이름을 무작정 쓰는 행태는 이를 입증한다”라고 지적했다.
기술 블로거 어니스트 뮬러는 2018년에 “그 어떤 도구도 관찰가능성을 제공하지 못할 것이다. 이는 무엇인가를 판매하고 싶은 사람들에게서만 완벽한 해결책이라고 들을 수 있을 것이다”라고 언급한 바 있다.
따라서 기업들은 관찰가능성을 높이기 위해 자체적으로 노력해야 한다. 옐프(Yelp)의 엔지니어링 인프라 부문 부사장 조지 바시는 “관찰가능성을 구매한다는 것은 주객전도나 마찬가지다”라고 말했다.
이러한 이유로 옐프는 제품 오너십을 믿고 개발자들이 자신의 서비스를 책임질 수 있도록 하고 있다. 바시는 “개발팀이 무엇인가를 소유할 때 대부분 그 이유는 성능, 안정성, 비용 때문이었다. 이제 우리는 개발팀의 손에 데이터를 넘겨줬다. 개발팀은 의사결정을 내릴 수 있는 도구를 확보한 셈이다”라고 덧붙였다.
관찰가능성의 미래
관찰가능성의 미래에 관한 대화에서 빠지지 않고 등장하는 것이 있다. 바로 머신러닝을 기반으로 한 자동화된 인사이트 도출 및 복원이다. 비스바나단은 “인텔리전스를 통해 주요 문제를 파악하고 자체 복원 키트를 적용할 수 있는 도구를 원한다. 따라서 시스템은 우리가 눈치채지 못하는 사이에 자동으로 복구된다. 우리가 원하는 방향이다”라고 말했다.
이는 또한 벤더들이 원하는 방향이기도 하다. 잔토스는 “관찰가능성과 관련해 드디어 머신 기반 인텔리전스에 충분히 가까워졌다. 머신러닝을 적용하여 효과적으로 상관관계를 파악할 수 있다. 일단 이를 파악할 수 있으면 자동 복구로 나아갈 수 있다”라고 전했다.
하지만 기계에서 이를 받아들일 준비가 아직은 되지 않았을 수 있다. 이와 관련해 소프트웨어 개발자 신디 스리다란은 자신의 저서(Distributed Systems Observability)에서 엔지니어 주도 관찰가능성(engineer-led observability)을 다음과 같이 언급했다.
운영 중인 시스템의 특이점 이면에서 가능성 있는 답을 추론하기 위해 찾아야 할 정보, 그리고 이를 검토하는 방법을 파악하는 프로세스는 여전히 시스템과 도메인을 잘 알고 있어야 할 뿐만 아니라 충분한 직관력도 필요하다.
‘관찰가능성’의 궁극적인 목표는 결국 운영 중인 환경과 관계없이 엔지니어가 알아차리기 전에 자동으로 문제를 발견하고 해결하는 시스템이다. 체스맨은 “이런 수준에 도달하기 위해서 벤더들은 방대한 데이터 더미를 통합하고 이해할 수 있는 도구와 함께 인텔리전스 및 자동화 기능을 갖춰야 할 것”이라고 말했다. ciokr@idg.co.kr