메인스트림 마이크로서비스 매니아: 채택으로 인해 증가하는 과제

불과 몇 년 전만 해도 마이크로서비스는 개발자들 사이에서 초보 앱 아키텍처가 제시하는 가능성과 기회에 설렘을 느끼며 논의되는 호기심의 대상이었습니다.

요즘은 네트워크에 능숙한 우리들조차도 이에 대해 이야기합니다 . Lightstep의 최신 연구 에 따르면 이러한 기술이 기업에서 주류가 되었기 때문입니다. 진지하게. 2018년 애플리케이션 제공 현황 보고서에 따르면 네트워크 관련 직무조차도 애플리케이션 서비스를 컨테이너에서 제공하기를 원한다고 밝혔습니다. 따라서 앞서 언급한 Lightstep 설문 조사에서 응답자의 91%가 마이크로서비스를 사용하고 있거나 사용할 계획이라고 답했을 뿐만 아니라, 86%가 5년 내에 마이크로서비스가 기본이 될 것으로 예상한다는 결과는 놀라운 일이 아닙니다.

그렇다고 해서 어려움이 없다는 것은 아닙니다. 실제로 Lightstep 설문조사에 참여한 응답자의 99%가 마이크로서비스를 사용할 때 어려움을 겪었다고 보고했습니다. 응답을 종합해 보면, 마이크로서비스에서는 거의 모든 것이 더 어렵고 때로는 비용이 많이 든다고 합리적으로 말할 수 있습니다.

조사에서는 로그 집계 비용 증가(21%)부터 데이터 증가에 대한 대처 방법 불확실(17%), 문제 해결 어려움(73%)까지 다양한 비즈니스 및 운영적 과제가 지적되었습니다.

그러나 더욱 우려스러운 것은 "마이크로서비스 환경에서 문제의 근본 원인을 식별하는 데 어려움을 겪는 사람의 98%가 이것이 직접적인 비즈니스 영향을 미친다고 보고한다"는 사실입니다.  

이는 일반적으로 네트워크 쪽에 있는지 아니면 DevOps에 매달려 있는지에 따라 "가시성" 또는 "관찰 가능성"이라는 용어를 사용하여 다른 곳에서 반향을 일으킨 주요 과제 중 하나입니다.

둘 다 기본적으로 동일한 기능을 설명합니다. 즉, 클라이언트에서 서비스로, 그리고 다시 클라이언트로 메시지가 네트워크를 통과할 때 무슨 일이 일어나고 있는지 볼 수 있는 기능입니다. 컨테이너 환경 내에서는 관련 서비스의 범위와 규모 때문에 이러한 작업이 특히 어렵습니다.

기존의 3계층 웹 앱에는 추적해야 할 로그 세트가 세 개, 시스템이 세 개 있습니다. 웹 및 모바일 클라이언트에서 모두 사용할 수 있는 API가 전면에 배치된 마이크로서비스 아키텍처를 사용하면 추적해야 할 수십 또는 수백 개의 다양한 서비스가 있을 수 있습니다.

확장 모델은 여전히 동일합니다. 즉, 복제본을 사용하여 수평적으로 확장(아웃)합니다. 그러나 컨테이너 환경 내의 규모가 훨씬 더 큽니다. 그것은 마치 10개의 구멍 대신 100개의 구멍으로 두더지 때리기 게임을 하는 것과 같습니다. 어떤 거래가 어떤 경로를 거쳐 이루어졌는지 파악하는 건 적어도 말로 표현하기 어려울 겁니다. 특히 길이 사라졌을 수도 있을 때요. 결국, 대부분 컨테이너 환경의 전제는 수동 개입을 기다리기보다는 빠르게 실패하고 인스턴스를 교체하는 것입니다.

이런 문제를 해결하는 방법은 여러 가지가 있습니다. 가장 중요한 것은 추적 및 문제 해결에 도움이 되는 계측기입니다. 이런 접근 방식은 새로운 것은 아니지만 컨테이너 환경의 불안정한 특성으로 인해 더욱 어려워졌습니다. 그럼에도 불구하고, 추적 요소(고유 식별자가 있는 사용자 지정 HTTP 헤더 등)를 삽입하면 오류나 성능 문제를 추적할 때 운영에 큰 도움이 될 수 있습니다. 일반적으로 기본 컨테이너 확장 옵션의 기능은 아니지만, 서비스 메시가 제공하는 서비스의 일부로 다루고 있는 기능 중 하나 입니다.

두 번째는 문제가 있는 마이크로서비스를 격리하여 운영 및 개발자가 실패 원인 상태에서 시스템을 조사할 수 있는 기능입니다. 격리는 기본적으로 문제가 있는 컨테이너를 활성 환경에서 제거하여 더 이상 호출이 전송되지 않도록 하지만 분석 및 검사를 위해 활성 상태로 유지합니다. 

마법의 지팡이는 없지만 마이크로서비스 기반 배포에서 컨테이너를 추적하고 격리할 수 있다면 평균 해결 시간(MTTR)을 크게 줄이고 비즈니스에 미치는 영향을 줄이는 데 도움이 될 수 있습니다.