관측 가능성 아키텍처: 금융 결제 사례

성공적인 결제 솔루션의 요소를 파악하는 개략적인 다이어그램을 통해 오픈 소스 클라우드 기반 o11y 금융 결제 아키텍처를 살펴봅니다.

클라우드 네이티브 기술은 결제 서비스의 설계 방식을 변화시켜 왔습니다. 2020년에 결제 서비스 현대화를 위해 오픈 소스 및 클라우드 네이티브 기술을 채택한 실제 구현에서 일련의 통찰력을 제시했습니다. 

제시된 아키텍처는 컨테이너, 마이크로서비스 및 Kubernetes 기반 컨테이너 플랫폼과 같은 오픈 소스 클라우드 네이티브 기술을 기반으로 했습니다. 이 시리즈에서 주요 누락 사항은 클라우드 네이티브 관찰 가능성 측면에 대한 논의를 피하는 것이었습니다. 이 시리즈에서는 DevOps 팀이 금융 결제 아키텍처를 위해 클라우드 네이티브 세계의 속도, 규모 및 복잡성을 제어하는 데 도움이 되는 오픈 소스, 표준 기반의 클라우드 네이티브 관찰 가능성 플랫폼을 통해 이러한 누락을 해결하는 방법을 살펴봅니다.

 

 

2023년 성능 및 사이트 안정성 전망

 2022년 성능 및 사이트 안정성 보고서는 관찰 가능성의 현재 상태, 분산 추적, 일반적인 SRE 관행 및 흠 없는 사후 문화를 통해 실패에서 얻은 교훈에 대해 개발자 중심의 평가를 수행합니다.

1부에서는 기본 아키텍처에 대해 설명하고, 지불 프로젝트를 정의하며, 논리적 및 물리적 아키텍처에 관찰 가능성을 추가하는 데 있어 이 시리즈에 대한 계획을 공유했습니다. 2부에서는 금융 결제 솔루션에 클라우드 네이티브 관찰 가능성을 추가하는 데 필요한 공통 아키텍처 요소에 대해 알아봤습니다. 이 글에서는 금융 결제 물리적 아키텍처에 대해 살펴보고, 확장 가능한 클라우드 네이티브 관찰 가능성을 추가하는 방법과 지불 관찰 가능성 솔루션에 대한 다양한 구축 옵션을 설명합니다.

 

 

일반 아키텍처 배경

참고로, 여기서 다루는 아키텍처 세부 사항은 오픈 소스 기술을 사용하는 실제 고객 통합 솔루션을 기반으로 하며, 여기서는 일반 아키텍처에 클라우드 네이티브 관찰 기능을 추가하는 것에 대해서만 논의합니다.

여기에 제시된 시나리오는 고객 솔루션을 연구하는 과정에서 발견된 일반적인 공통 아키텍처입니다. 이는 아키텍처에 가이드를 제공하고 기술적인 세부 사항이 너무 많지 않습니다.

이 섹션은 제시된 시각적 표현을 다룹니다. 이 아키텍처에서 각 요소를 나타내는 여러 가지 방법이 있지만 아이콘, 텍스트 및 색상을 선택하여 흡수하기 쉽도록 했습니다. 피드백과 함께 이 게시물 하단에 자유롭게 댓글을 게시하십시오.

이제 이 아키텍처에 클라우드 네이티브 관찰 기능을 추가하는 것과 관련된 세부 정보를 살펴보고 이 예제에서 클라우드 네이티브 관찰 기능이 어떻게 적용되는지 설명하겠습니다.

 

 

즉시 지불

아래 그림에 나타낸 예시적인 아키텍처는 즉시 지불 솔루션이 물리적 아키텍처에 적용되는 방법을 설명합니다. 이 다이어그램은 즉시 지불 솔루션의 가장 높은 수준과 이 프로세스에 적용되는 요소 그룹에 초점을 맞추고 있습니다. 

 

관측 가능성 아키텍처: 금융 결제 사례

 

여기서는 컨테이너 플랫폼의 오른쪽 하단 모서리에 표시된 클라우드 네이티브 관찰 가능성의 추가에만 초점을 맞추고자 합니다. 수신되는 네트워크 세부 정보 없이 크로노스피어 수집기가 표시됩니다. 이는 Collector가 클라우드 네이티브 애플리케이션에 의해 노출되는 Prometeus 기반 서버를 검색하고 긁어내기 위해 설계된 독립형 애플리케이션이라는 사실을 나타냅니다. 이러한 모든 연결을 보여주기 위해서는 컨테이너 플랫폼 자체를 포함하여 모든 구성 요소, 서비스 및 애플리케이션을 도면으로 표시해야 하는데, 이는 압도적일 것입니다. 이 보다 명확한 아키텍처 표현은 사용자가 이 사실을 이해하고 있다고 가정하고 수집기에서 사용할 수 있는 Prometeus 기반 엔드포인트가 있는지 확인하는 세부 정보를 남깁니다.

그림과 같이 Collector는 검색된 데이터를 보안 연결을 통해 단일 테넌트 인스턴스로 관리되는 크로노스피어 플랫폼으로 보냅니다. Collector가 특정 작업이나 구성 요소에서 데이터를 수집할 수 없는 경우 수동으로 이를 푸시할 수 있습니다.

 

컬렉터는 메트릭 수집 외에도 다음을 수행할 수 있습니다: 

표준 레이블 지정 규칙을 사용하여 데이터를 통과하는 데이터 필터링, 이름 변경 및 삭제

수집된 모든 데이터에 전역 레이블 추가

OTEL(Open Telemetry) 범위 및 Jaeger 및 Zipkin과 같은 기타 유명한 오픈 소스 형식과 같은 서비스에서 추적 수신

 

사용자의 요구에 따라 위에서 언급한 데이터 수집을 달성하기 위해 아키텍처에 Collector를 배치하는 옵션에 대해 알아보겠습니다.

 

 

컬렉터 세부 정보

컬렉터의 세부 사항에 대한 초기 소개는 2021년에 발표되었지만 모든 기술과 마찬가지로 그 이후로 컬렉터가 발전했습니다. 세부 사항을 검토한 다음 수집기가 아키텍처에서 가질 수 있는 유연한 범위를 보여주기 위해 몇 가지 배포 옵션을 공유하겠습니다.

컬렉터는 클러스터, 노드 및 포드 내의 최신 정보 소스로 Kubernetes 및 서비스(서비스 모니터 및 포드 모니터)를 사용합니다. 이 정보는 수집기의 처리 계층으로 수집되어 메트릭 데이터를 수집할 애플리케이션이나 포드를 결정합니다.

원격 측정 또는 추적 데이터를 수신하기 위해 Collector를 서비스를 앞에 두고 Kubernetes Deployment로 설정하여 추적 데이터를 수신할 수 있습니다. 그런 다음 응용 프로그램이 추적 데이터를 서비스로 푸시하고, 이 서비스에서 Collector가 데이터를 수신합니다. 기본적으로 크로노스피어 플랫폼 및 Collector는 OTEL(OpenTelemetry)의 개방형 표준 형식으로 기본 설정되지만 Jaeger 또는 Zipkin과 같은 다른 지원 형식을 사용하도록 구성할 수 있습니다.

 컬렉터는 메트릭을 수집하고 데이터를 추적한 후 이를 크로노스피어 플랫폼으로 전송하여 분석, 처리 및 최종 저장을 위해 크로노스피어 메트릭을 수집합니다.

 

 

규모에 맞는 유연한 O11y

컬렉터 사용에 대한 기본 사항은 언급했지만 어떤 종류의 세부 사항도 언급하지 않았습니다. 이 섹션에서는 규모에 맞게 효과적인 클라우드 네이티브 관찰 가능성을 보장하는 동시에 잠재적인 아키텍처 요구 사항을 충족하기 위해 사용할 수 있는 옵션을 공유하고자 합니다. 

이렇게 하려면 컬렉터를 설정하는 방법에 대한 세 가지 옵션이 있습니다.

 

 

기본 사용 사례

첫 번째 사용 사례는 클라우드 네이티브 애플리케이션 메트릭 데이터를 수집하기 위한 짧은 대기 시간(지연)을 찾는 경우입니다. 이 경우는 Kubernetes가 로드가 높아지면 클러스터를 자동으로 확장하기 때문에 관찰 가능성을 수평으로 확장하려는 경우이기도 합니다. 이 경우는 Collector를 설치할 때 기본 권장 사항으로, 각 노드가 Collector 복사본을 실행하여 다음과 같이 해당 노드 내의 포드 및 애플리케이션에서 모든 메트릭을 끌어옵니다. 각 노드는 Collector 복사본을 실행하여 해당 노드 내의 포드 및 애플리케이션에서 모든 메트릭을 끌어옵니다

노드당 단일 Collector가 있으므로 단일 Collector에 과부하가 걸릴 가능성이 적고 노드를 손실하면 전체 클러스터가 아닌 해당 노드에서만 메트릭 데이터가 손실됩니다. 또한 일부 환경에서는 DaemonSet으로 배포할 수 없으므로 다른 옵션 중 하나를 검토해야 합니다. 일반적으로 이 배포 방법은 관리하기가 가장 쉽습니다.

 

 

대용량 사용 사례

이 사용 사례는 사이드카로 배포하여 가장 잘 처리됩니다. 즉, 각 Kubernetes Pod에 Collector를 설치합니다. 이는 각 애플리케이션의 전용 리소스가 되며 대용량 메트릭 데이터 생성 애플리케이션에 이상적입니다. 또한 Collector와 애플리케이션이 단일 Pod 내의 컨테이너에서 실행되고 있으므로 Pod에 대한 리소스를 최적화할 수 있습니다.

Collector와 애플리케이션이 단일 포드 내의 컨테이너에서 실행되고 있습니다. 노드 내의 특정 애플리케이션에 대해 메트릭 수집을 사용자 지정하려는 경우 이를 애플리케이션별로 수행하는 것이 완벽한 방법입니다. 각 Collector에 대한 관리가 있으므로 관리 오버헤드가 증가합니다. 또한 메모리 오버런으로 인해 Collector에 장애가 발생할 경우 해당 Pod 내의 컨테이너가 중단될 수 있습니다.

다음 아키텍처는 지금까지 설명한 기본 및 대용량 사용 사례를 모두 보여줍니다. 여기서 메트릭 데이터 흐름은 Collector에서 Chronosphere 플랫폼으로 표시됩니다:

이제 푸시 기반 수집이 필요할 때 사용되는 최종 사용 사례를 살펴보겠습니다.

 

 

푸시 기반 사용 사례

원격 측정 및 메트릭 데이터가 클라우드 네이티브 애플리케이션에서 푸시될 때 Collector를 배포로 배포할 수 있습니다. 이 방법을 사용하면 수집기 수와 할당된 리소스를 사전에 결정하여 제어할 수 있습니다.

아래에서 모든 원격 측정 및 메트릭 데이터가 Kubernetes 서비스로 푸시되고, 이 서비스는 미리 지정된 수집기와 공유됩니다.

모든 원격 측정 및 메트릭 데이터는 Kubernetes 서비스로 푸시되며, Kubernetes 서비스는 사전에 설정된 수집기와 공유합니다

이는 분산 추적 데이터 및 높은 카디널리티 메트릭 끝점에서 잘 작동하며 Prometeus Service Discovery를 사용하여 구성할 때 효과적입니다.

이 배포 유형은 배포 내의 수집기 간에 메트릭 로드가 분할되는 방식을 관리하고 제어하기 위해 추가적인 오버헤드를 필요로 합니다. 예를 들어 워크로드에 맞게 수집기 크기를 축소하는 경우 메모리 부족으로 인해 지연, 스크랩 지연 또는 실패가 발생할 수 있습니다. 또한 애플리케이션별로 수집기의 푸시 구성을 사용자 지정할 수 없습니다.

이것이 어떻게 보일 수 있는지 더 자세히 알려면 아래의 아키텍처를 참조하여 관찰 가능성 원격 측정 및 메트릭 데이터 흐름이 녹색 선으로 표시됩니다:

이 개요를 통해 조직의 아키텍처에서 규모에 맞게 클라우드 네이티브 관측 가능성을 위해 이 솔루션을 적용하는 방법에 대한 좋은 느낌을 얻을 수 있기를 바랍니다.

 

 

결제 프로젝트 사용

아키텍처 컬렉션은 2019-2022년 사이에 연구된 모든 방식의 사용 사례와 산업에 대한 통찰력을 제공했습니다. 아키텍처는 각각 전체 프로젝트뿐만 아니라 각 다이어그램 요소에 대한 이미지 컬렉션을 제공하여 사용자가 적합하다고 생각하는 대로 사용할 수 있도록 합니다.

금융 결제 프로젝트를 살펴보면 가장 관심 있는 주제나 사용 사례로 바로 이동할 수 있는 목차가 표시됩니다. 각 섹션을 스크롤하여 원하는 시간에 탐색할 수도 있습니다.

다이어그램 열기 링크를 클릭하면 생성에 사용한 다이어그램 툴링에서 사용 가능한 모든 논리적, 개략적 및 상세 다이어그램이 열립니다. 이를 통해 자체 아키텍처에서 사용하기에 적합하다고 판단되는 모든 수정에 쉽게 사용할 수 있으므로 언제든지 사용 및 수정하십시오!

마지막으로 다이어그램 도구 사용에 초점을 맞춘 무료 온라인 초보자 가이드 워크샵이 제공됩니다. 전문가로부터 팁과 요령을 배우려면 탐색하십시오.

 

 

시리즈 개요

금융 결제 아키텍처에 클라우드 네이티브 관찰 기능을 추가하는 것에 대한 이 관찰 가능성 아키텍처 시리즈의 개요는 다음과 같습니다:

금융결제소개

금융 결제 공통 관측 가능성 요소

금융 결제 예에 관찰 가능성 추가(이 기사)

재무 계산 예제에 관측 가능성 추가

 

위 링크 중 하나를 팔로우하여 놓친 기사를 따라잡으세요. 이 시리즈의 다음은 재무 계산 예제에 클라우드 네이티브 관찰 가능성을 추가합니다.