운영 인식
안정성을 위한 모니터링 작업을 시작하기 위해서는 우선 사전 단계를 거쳐야 합니다. 먼저 합리적인 수준의 운영 인식이 있는지 확인해야 합니다.
간단히 말해 프로덕션 환경에서 시스템의 안정성을 달성하기 위해서는 먼저 해당 시스템을 잘 이해하고 프로덕션 환경에서 어떻게 작동하고 있는지 이해해야 합니다.
현재 구성에 대한 정보 수집
이상하게 들릴 수 있지만 많은 환경에서 제일 먼저 답해야 할 질문은 “프로덕션에서 정확히 무엇이 실행되고 있는가?”입니다. 오늘날의 프로덕션 환경과 프로덕션 배포 경로는 복잡하기 때문에 먼저 약간의 검색이 필요한 경우가 많습니다. 특정 애플리케이션의 구성 요소 부분은 무엇인가? 다른 부분과 통신하는 부분은 무엇인가? 이 애플리케이션의 명확한 종속성과 명확하지 않은 종속성은 무엇인가?
정상 성능과 과거 성능에 대한 정보 수집
이러한 정보를 얻은 다음 시스템 성능과 "정상적인" 동작의 기준을 얻으려 시도해볼 수 있습니다. 이 정보가 필요한 이유는 많지만 적어도 애플리케이션의 문제를 구분할 때 도움이 됩니다. 가동 중지 도중은 80% CPU 사용률로 실행되는 데이터베이스 서버가 적절한지 아닌지 파악하기에 좋은 때가 아닙니다.
이 기준을 알아내면서 과거의 성능을 확인하는 것이 좋습니다. "과거 성능은 미래의 결과를 보장할 수 없다"라는 말은 사실이지만 때로는 기대 사항을 조정하는 데 도움이 될 수 있습니다. 마찬가지로 과거의 서비스 중단이나 문제에 대한 정보에 액세스할 수 있다면 적어도 안정성에 대한 고려 사항에 포함해야 할 잠재적인 장애 모드를 파악할 수 있습니다.
컨텍스트에 대한 정보 수집
마지막으로 시스템에 대한 컨텍스트 지식을 얻으면 도움이 됩니다. 컨텍스트는 다양한 버킷으로 나눌 수 있으며 대부분이 사회 기술적입니다. 예를 들어 사회 측면에서는 서비스 또는 애플리케이션에 관계된 관련자에 대한 유용한 정보를 수집해야 합니다.
특정 앱/서비스를 누가 소유하거나 관리하는지는 명확하다고 생각할 수 있지만 엔터프라이즈 상황이나 기타 복잡한 조직에서는 생각보다 훨씬 어려울 수 있습니다.
나중에 SLI와 SLO에 대해 설명할 때 이유가 분명해지겠지만 슬픈 진실은 관련자가 누구인지를 명확히 알지 못하면 시스템 안정성을 크게 개선할 수 없다는 것입니다.
컨텍스트 질문의 기술적 측면에서 이 애플리케이션이 프로덕션 환경에서 어떻게 수행되었나요?, "에픽" 배포 중에 수동으로 배포되었나요? 아니면 훌륭한 단위 테스트 집합이 있는 자동화된 CI/CD 파이프라인을 통해 배포되었나요?와 같은 기술적 질문에 주의를 기울이는 것이 정말 유용합니다.
안정성을 개선하는 업데이트가 있는 경우 얼마나 쉽게 반복할 수 있는가를 포함하여 이 정보는 여러 영향을 미칠 수 있습니다. 변화를 가져오기 위해 수행할 수 있는 작업의 유용한 지표가 될 수도 있습니다.
운영 인식을 위한 Azure 도구
운영 인식을 얻기는 쉽지 않은 경우가 많지만 이 프로세스에 도움이 되는 Azure에서 제공하는 몇 가지 도구를 살펴보겠습니다. 여기서는 피상적으로 살펴보겠지만 더 깊이 살펴보고 싶다면 이 모듈 끝에 다른 Microsoft Learn 모듈과 설명서에 대한 포인터가 포함되어 있습니다.
Application Insights
처음으로 살펴볼 도구는 “실제로 무엇이 실행되고 있는가?”라는 질문에 도움이 될 수 있습니다. 운영 담당자는 이미 프로덕션 환경에서 실행 중인 애플리케이션을 사용해야 하는 경우가 드물지 않습니다. 이상적으로는 설계 단계부터 시작되는 소프트웨어의 전체 수명 주기에 포함되어야 하지만 항상 그런 것은 아니며 아닌 경우가 많습니다. 이 경우, 특히 더 복잡한 다중 계층 또는 마이크로 서비스 기반 애플리케이션이라면 모든 가동부를 이해하는 것만 해도 많은 노력이 필요합니다.
이 노력을 줄여 줄 뿐 아니라 프로덕션 환경에 있는 애플리케이션의 동작에 대한 정보를 제공할 수 있는 한 가지 도구가 Application Insights입니다. 개발자는 최소한의 노력으로 애플리케이션을 계측하여 Azure에서 실행되는 수집기에 원격 분석 정보를 자동으로 보낼 수 있습니다. Application Insights는 이 정보를 사용하여 애플리케이션 구성 요소의 시각적 맵과 이러한 구성 요소 간 통신을 만들 수 있습니다.
예를 들면 다음과 같습니다.
앞의 그림에서 애플리케이션의 구성 요소뿐 아니라 이러한 구성 요소 간 통신도 볼 수 있습니다. 구성 요소 간 연결 중 하나를 확대하면 구성 요소 간 호출 수와 해당 호출의 평균 대기 시간을 확인할 수 있습니다. 성공한 호출 수와 실패한 호출 수의 표현도 볼 수 있습니다. 이러한 맵 요소 중 하나를 선택하면 Application Insights에서 해당 호출의 성능 및 성공/실패 메트릭에 대한 자세한 통계 정보를 볼 수 있습니다. 이 방법은 애플리케이션 구성 요소의 큰 그림과 이러한 구성 요소의 기본 작동 방식을 이해하는 유용한 방법입니다. 다시 말하지만 중단이 발생하기 전에 애플리케이션 맵과 Application Insights의 모든 기능을 탐색해야 합니다.
Azure Resource Graph
Application Insights는 애플리케이션에 대한 몇 가지 운영 인식을 얻는 좋은 방법이지만 훨씬 더 높은 수준에서 파악하고 구독하고 있는 Azure에서 사용 중인 리소스를 모두 보려면 어떻게 해야 할까요? 과거에는 보고서를 다운로드하거나 PowerShell을 작성하여 이 정보를 수집했지만 이제는 훨씬 더 쉬운 방법이 있습니다.
Azure Resource Graph Explorer는 Azure Portal에서 바로 실행하여 필요한 데이터를 쿼리할 수 있는 대화형 환경을 제공합니다. 현재 사용 중인 리소스를 기반으로 실시간 응답을 반환하는 임의 쿼리를 실행할 수 있습니다. 예를 들어 현재 실행 중인 모든 VM을 보려면 다음 쿼리를 실행할 수 있습니다.
그러면 구독에서 사용되는 VM의 전체 상세 목록이 반환됩니다.
이 환경에서 사용되는 쿼리 언어는 Kusto Query Language(KQL)입니다. KQL에 대해서는 Azure Monitor Log Aanlytics에 대해 논의하는 이 모듈의 뒷부분에서 자세히 설명하겠습니다.
대시보드
운영 인식을 위한 가장 일반적인 운영 도구는 유서 깊은 대시보드입니다. 운영을 수행하는 사람들을 생각할 때 우리는 흔히 큰 모니터 앞에 앉아 그래프, 차트, 카운터로 가득한 대시보드를 뚫어지게 쳐다보고 있는 모습을 상상합니다. 이 모듈에서는 대시보드를 구성, 편집 및 사용하는 방법은 살펴보지 않습니다. 이 작업은 포털 다른 위치의 콘텐츠를 고정한 다음 적합한 곳으로 이동하여 수행됩니다.
대신 일반적으로 사용되지는 않지만 실제로 도움이 되는 두 가지 대시보드 기능을 살펴보겠습니다. 모든 대시보드 상단에서 이러한 기능을 찾을 수 있습니다.
강조 표시된 두 화살표를 사용하여 대시보드의 JSON 표현을 업로드 및 내보내기 할 수 있습니다.
먼저 내보내기 기능부터 시작해 보겠습니다. 내보내기를 선택한 경우 다운로드를 선택하면 현재 대시보드를 나타내는 JSON 파일이 컴퓨터에 다운로드됩니다. 원하는 경우 지금 포털에 로그인하고 제품 메뉴에서 대시보드를 선택한 다음 내보내기>다운로드를 선택하여 이 기능을 사용해 보세요.
이 파일을 사용하면 적어도 두 가지의 편리한 작업을 할 수 있습니다.
이 파일을 원본 코드 제어 시스템에 체크인할 수 있습니다. 이를 통해 다양한 대시보드 버전을 추적하고 대시보드를 사용하려는 다른 사용자가 대시보드에 액세스하도록 허용할 수도 있습니다. 사람에 따라 이를 "코드형 대시보드(dashboard as code)"라고 할 수 있습니다.
이 파일을 새 대시보드의 기반으로 사용할 수 있습니다. 이 학습 경로 뒷부분에서 다시 검토할 구체적인 예는 다음과 같습니다. 지난 주에 발생한 가동 중단 동안 특정 대시보드가 한 시간 동안 어떻게 표시되었는지 동료에게 보여 주어야 한다고 가정해 보겠습니다. 대시보드를 게시하여 정확한 시간과 기간을 선택하도록 요청할 수도 있습니다. 하지만 훨씬 더 쉽고 오류가 적게 발생하는 방법은 필요한 대로 정확히 설정된 대시보드를 다운로드하고 해당 JSON 파일을 공유하는 것입니다. 동일한 대시보드에서 두 번째 기간, 예를 들어 향후 한 시간을 강조 표시하려는 경우 JSON을 편집하기가 쉽습니다.
이것이 내보내기 기능입니다. 이제 업로드 기능 사용을 집중적으로 살펴보겠습니다. 마지막 섹션에서 버전 제어 또는 편집된 파일을 로드할 수 있는 것 외에도 대시보드를 구성할 때 업로드 기능을 사용하여 다른 사용자의 꼼꼼한 작업을 활용할 수 있습니다.
이 단원의 두 가지 아이디어를 깔끔하게 연결하는 이 섹션의 마지막 예를 살펴보겠습니다. JSON 파일
을 컴퓨터에 다운로드한 다음, 대시보드에 업로드하면 다음과 같이 표시됩니다.
이제 구독에서 사용 중인 리소스의 상당히 포괄적인 인벤토리를 보여 주는 라이브 대시보드가 있습니다. 이 대시보드의 데이터는 앞에서 살펴본 Azure Resource Graph Explorer와 동일한 원본에서 제공됩니다. 실제로 타일 중 하나를 선택하면 정보를 생성하기 위해 실행 중인 정확한 쿼리가 해당 사각형에 표시되는 것을 확인할 수 있고 원하는 경우 이를 편집할 수 있습니다. 대단하지 않습니까?
운영 인식에 대한 이러한 도움을 활용하여 안정성 향상을 지원하기 위해서는 무엇을 모니터링할지 살펴보겠습니다.