서비스 메시 및 앱 현대화
컨테이너 열풍은 끊이지 않고 있다. 하지만 이는 애플리케이션과 아키텍처 측면에서 여러분이 생각하는 것과 다를 수 있습니다.
컨테이너를 마이크로서비스와 동일시하는 경향이 여전히 있습니다. 그리고 동일시한다는 것은 "교체해서 사용하다"는 뜻입니다.
이는 잘못된 가정입니다.
오늘날 컨테이너의 상당 부분은 실제로 기존 애플리케이션을 배포하는 데 사용되고 있습니다. Container Journal에 따르면 IDC 조사에 따르면 컨테이너의 절반(46%)도 안 되는 양이 새로운 용도로 사용된 것으로 나타났습니다. 나머지는 기존 애플리케이션을 실행하고 있었습니다. (원천: IDC 설문 조사에 따르면, 미션 크리티컬 앱을 구동하는 컨테이너가 핵심 요소입니다.) 이 이상한 조합에 대한 자주 인용되는 설명은 무엇일까요? 현대화.
클라우드 기반으로 구축되는 "새로운" 애플리케이션의 수는 여전히 비교적 적다는 점을 지적하는 수많은 연구와 조사가 있습니다. Cap Gemini의 연구에 따르면 그 수는 5개 중 1개 미만입니다. Diamanti의 최근 연구에 따르면 IT 리더의 31%가 레거시 애플리케이션을 현대화할 목적으로 컨테이너를 고려하고 있는 것으로 나타났습니다. 이는 놀랄 일이 아닙니다. 우리는 다섯 가지 세대의 애플리케이션 아키텍처를 지원하는 다세대 IT 시대에 살고 있습니다.
따라서 기존 앱이 많이 나와 있고, 앞으로 더 많이 나올 앱이 컨테이너에 배포될 가능성이 있습니다.
저는 이것이 좋은 일이라고 생각합니다. 컨테이너와 서비스 메시와 같은 관련 기술은 실제로 현대화 작업에 도움이 될 수 있기 때문입니다.
서비스 메시를 사용한 모니터링 현대화
익숙하지 않다면 관찰 가능성은 Cindy Sridharan이 " 분산 시스템 관찰 가능성 "에서 자세히 설명한 것처럼 일반적으로 수용되는 세 가지 기둥으로 구성됩니다.
- 이벤트 로그
- 메트릭
- 흔적
이 주제에 대한 내용은 풍부합니다. 여기에는 로그에서 생성되는 대규모 운영 데이터와 원격 측정 데이터의 방출에 내재된 과제도 포함됩니다. 따라서 여기서는 다루지 않겠습니다. 즉, 관찰 가능성의 잠재력을 최대한 실현하려면 세 가지가 모두 필요하다는 말입니다.
또한 이 최신 사항(추적)에 관해서는 기존 및 레거시 애플리케이션이 불리한 입장에 있다는 점도 언급할 만합니다. 아시다시피 대부분의 시스템에서는 거래가 발생부터 이행까지 진행되는 동안 거래를 추적하는 데 필요한 원격 측정 데이터를 수집할 수 있는 장비가 없었습니다. 이벤트 로그와 메트릭은 애플리케이션 아키텍처와 환경에 관계없이 생성하고 얻는 것이 훨씬 쉽습니다. 이러한 옵션은 거의 모든 웹 및 애플리케이션 플랫폼에서 표준으로 제공됩니다. 하지만 계측은? 이는 일반적으로 실시간 트래픽을 파악할 수 있는 내장된 코드나 에이전트를 의미합니다.
이는 서비스 메시가 제공할 수 있는 것 중 하나입니다.
기억하시겠지만 서비스 메시는 주로 컨테이너 오케스트레이션 환경 내의 사이드카 프록시로 구성됩니다. 이러한 프록시는 기본적으로 컨테이너 간의 모든 통신을 프록시합니다. 이를 통해 이러한 프록시는 서비스를 확장할 뿐만 아니라 전체적인 관찰을 가능하게 하는 목적으로 트래픽을 계측할 수 있는 완벽한 장소를 제공합니다. 이들은 컨테이너 환경을 통과하는 메시지를 풍부하게 만들어 시스템이 여러 시스템과 서비스 간의 트래픽을 추적하고 상관관계를 파악할 수 있도록 하는 상세한 태그와 기타 메타데이터를 포함할 수 있습니다.
가장 좋은 점은 애플리케이션을 거의 수정하지 않고도 이를 달성할 수 있다는 것입니다. Java 앱의 경우와 같이 코드를 수정하지 않고도 적절한 기능을 주입할 수 있는 구성 기반 옵션이 있는 경우도 있습니다.
기존 애플리케이션에서 추적 정보를 내보내는 기능은 진정한 관찰 가능성을 추구하는 데 있어 핵심적인 역량입니다. 기존 애플리케이션을 컨테이너에 배포할 경우 서비스 메시가 이를 현대화하는 데 어떻게 도움이 될 수 있는지 고려하세요.