NGINX Modern Apps Reference Architecture의 버전 1.0.0 발표

우리는 2021년 8월 스프린트 2.0에서 NGINX Modern Applications Reference Architecture (MARA)를 공개했을 때, 디자인 목표를 솔직하게 밝혔습니다. 우리는 Kubernetes에서 실행되고 보안, 확장성, 안정성, 모니터링 및 내성을 지원하도록 설계된 최신 애플리케이션 아키텍처의 사례를 만들고 싶었습니다. 이 프로젝트는 시간 소모적인 통합 작업 없이 기능적 구성 요소를 결합하는 "플러그 앤 플레이" 방식으로 다양한 인프라에 배포 가능해야 했습니다.

스프린트 이후 몇 달 동안 우리는 로드맵을 추진해 왔습니다. 다른 프로젝트와 마찬가지로, 우리는 성공과 실패를 모두 겪었고, 그 과정에서 얻은 교훈을 MARA에 녹여냈습니다. 이러한 문제점을 기록하고, 이러한 교훈을 염두에 두고 설계함으로써 다른 사람들이 같은 문제에 부딪히지 않도록 할 수 있기를 바랍니다.

최근 MARA 버전 1.0.0 으로 프로젝트 디렉토리를 재구성하고 환경의 인스턴스화 및 삭제 프로세스를 변경하여 이정표에 도달했습니다. 우리는 중복된 코드를 제거하고, 향후 추가 사항을 쉽게 수용할 수 있는 디렉토리 구조를 만들었으며, 관리 스크립트를 표준화했습니다. 이 버전은 MARA 역사상 중요한 시점을 기념하는 만큼, 우리는 잠시 멈춰 커뮤니티에 진행 상황을 보고하고, 이를 통해 얻은 중요한 교훈과 향후 로드맵에 대한 정보를 제공하고자 했습니다.

원격 측정 – 메트릭, 로깅 및 추적

MARA의 핵심 기여자들은 대규모로 소프트웨어를 실행한 경험이 있으며, 운영, 엔지니어링 및 관리 관점에서 서비스를 제공하는 데 필요한 사항을 이해합니다. 그들은 애플리케이션이 제대로 작동하지 않을 때 느끼는 답답함을 알고 있으며, 문제가 정확히 무엇인지 쉽게 파악할 방법이 없습니다. DevOps 세계에서 유포되는 인용문은 이 문제를 간결하게 요약합니다. "마이크로서비스 디버깅은 일련의 살인 미스터리를 푸는 것과 같습니다."

이를 염두에 두고 우리는 단기 로드맵에서 관찰 가능성 추가를 최우선 순위로 삼았습니다. 이 맥락에서 관찰 가능성에는 로그 관리, 측정 항목, 추적 데이터가 포함됩니다. 하지만 단순히 데이터를 수집하는 것만으로는 충분하지 않습니다. 데이터를 파헤쳐 환경에서 무슨 일이 일어나고 있는지에 대해 의미 있는 결정을 내릴 수 있어야 합니다.

추적 옵션을 탐색하던 중 OpenTelemetry (OTEL)를 찾게 되었는데, 이는 원격 측정 데이터, 로그, 메트릭, 추적의 전체 범위를 지원하기 때문입니다. 우리는 OTEL 에이전트가 모든 추적 데이터를 수집, 처리, 중복 제거한 다음 이를 OTEL 수집기로 전달하여 집계하고 내보내는 구현 방식을 구상했으며, 워크플로의 마지막에는 시각화 시스템을 구축하여 데이터를 사용할 수 있도록 했습니다. 이러한 접근 방식은 사용자에게 데이터 표시 및 분석에 대한 가장 광범위한 선택권을 제공하는 동시에 OTEL 표준을 활용하여 초기 단계(수집, 집계 등)를 간소화합니다.

우리는 두 단계로 구현을 구축했습니다.

1. 환경에서 OTEL 수집기를 관리하기 위해 Kubernetes용 OpenTelemetry Operator를 배포합니다.

2. Bank of Sirius 애플리케이션을 도구화하여 추적 및 메트릭을 방출합니다.

MARA의 원래 버전은 로깅을 위해 Filebeat 와 함께 Elasticsearch를 사용했으며, 이를 Grafana Loki 로 대체하는 것도 고려했지만, 당장은 원래 선택을 유지하기로 결정했습니다. 지표 측면에서 우리는 원래 Prometheus 와 Grafana 에 기반한 배포를 수정해야 한다는 것을 깨달았습니다. 이를 위해 처음에 사용하던 맞춤형 Prometheus 구성을 커뮤니티에서 유지 관리하는 kube-prometheus-stack Helm 차트로 대체해야 했습니다. 이 차트는 Grafana, 노드 내보내기 , Kubernetes 환경을 관리하는 데 적합한 일련의 미리 구성된 대시보드와 스크래핑 대상을 포함하는 완전한 Prometheus 환경을 구성합니다. 여기에 F5 NGINX Ingress Controller 와 Bank of Sirius 애플리케이션에 대한 추가 대시보드를 추가했습니다.

이는 OTEL을 구현하는 데 필요한 엄청난 양의 작업에 대한 간략한 요약일 뿐입니다. 다른 사람들이 같은 가파른 학습 곡선을 오르는 수고를 덜어주기 위해, 우리는 블로그의 '현대 앱 참조 아키텍처에 OpenTelemetry 통합 - 진행 상황 보고서' 에서 전체 프로세스를 기록했습니다.

배포 옵션 – Kubeconfig

MARA의 초기 버전에서는 배포 환경으로 Amazon Elastic Kubernetes Service (EKS)를 선택했습니다. 그 이후로 많은 사용자는 비용상의 이유로 실험실이나 워크스테이션과 같이 리소스가 덜 필요한 "로컬" 환경에서 MARA를 실행하고 싶다고 말했습니다. 이식성은 원래 프로젝트의 핵심 목표였고 지금도 그렇습니다. 따라서 이번 기회를 통해 우리는 이식성을 달성할 수 있다는 것을 증명할 수 있었습니다. 작업을 보다 쉽게 하기 위해, 우리는 최소 요구 사항을 충족하는 모든 Kubernetes 클러스터에서 실행할 수 있는 배포 절차를 설계하기로 결정했습니다.

첫 번째 단계로, Kubernetes 클러스터와 통신하기 위해 kubeconfig 파일을 읽는 새로운 Pulumi 프로젝트를 MARA에 추가했습니다. 이 프로젝트는 Pulumi Kubernetes 프로젝트와 인프라 프로젝트(후자의 예로는 AWS와 Digital Ocean 프로젝트) 사이에 있습니다. 실제로 kubeconfig 프로젝트를 만들면 새로운 인프라 프로젝트를 통합하는 데 대한 장벽이 낮아집니다. 인프라 프로젝트가 kubeconfig 파일, 클러스터 이름, 클러스터 컨텍스트를 kubeconfig 프로젝트에 전달할 수 있으면 MARA 배포 절차의 나머지 부분이 원활하게 작동합니다.

테스트를 위해 CPU와 메모리 요구 사항이 작고 설치가 간편한 여러 Kubernetes 배포판을 사용했습니다. 여기에는 K3s , Canonical MicroK8s , minikube가 포함됩니다. 모든 배포판은 2개의 CPU 와 16GB RAM이 탑재된 Ubuntu 21.10을 실행하는 가상 머신(VM)에 배포되었습니다. 또한 모든 배포판은 영구 볼륨과 Kubernetes LoadBalancer 지원을 제공하도록 구성되었습니다.

이 과정에서 가장 어려운 부분은 프로젝트의 일부인 맞춤형 NGINX Ingress Controller에 사용되는 개인 레지스트리를 다루는 것이었습니다. (Mara를 배포할 때는 NGINX Open Source 또는 NGINX Plus 기반의 표준 NGINX Ingress Controller는 물론, 이 맞춤형 NGINX Ingress Controller도 사용할 수 있습니다.) 우리는 더욱 플랫폼에 독립적인 접근 방식을 위해 Amazon Elastic Container Registry (ECR)에서 레지스트리 로직을 분리해야 한다는 사실을 발견했고, 이는 현재 진행 중입니다. 또한 우리는 송신 주소의 호스트 이름을 가져오기 위한 논리가 AWS Elastic Load Balancing (ELB)에만 매우 특화되어 있다는 사실을 깨달았으며, 다른 사용 사례에 적용하려면 이를 다시 작성해야 했습니다.

MARA 관리 스크립트와 풀루미 프로젝트는 현재 위에 설명된 문제를 해결하기 위해 특정 논리를 사용합니다. 지금으로서는 Kubernetes 구성 기반 배포에서는 공식 NGINX 레지스트리의 NGINX Ingress Controller(NGINX 오픈 소스 또는 NGINX Plus 기반)를 사용해야 합니다.

클라우드 기반 배포에 필요한 리소스를 제공하지 않는 로컬 배포를 수용하기 위해 MARA 구성 파일에 여러 튜닝 매개변수를 추가했습니다. 대부분의 매개변수는 Elastic Stack 의 다양한 구성 요소에 대해 요청된 복제본 수와 관련이 있습니다. 테스트가 진행됨에 따라 배포 환경의 리소스 제약에 따라 MARA를 미세 조정할 수 있는 추가 매개변수가 추가됩니다.

이러한 변경 사항을 적용하면 K3s, MicroK8s, Minikube에 성공적으로 배포할 수 있으며 Azure Kubernetes Service (AKS), Digital Ocean , Google Kubernetes Engine , Linode , Rancher's Harvester 에서 해당 논리를 성공적으로 테스트했습니다. 자세한 내용은 MARA 공급자 상태 페이지 와 MARA를 참조하세요. 이제 블로그에서 가까운 워크스테이션에서 실행해보세요 .

파트너와의 협력

저희 파트너들은 MARA와의 협력에 대해 매우 수용적이고 지지적이었습니다. 그들 중 많은 사람들이 이 프로젝트에 대해 자세히 알아보고, 자사 제품에 이를 어떻게 활용할 수 있는지, 심지어 기능을 어떻게 추가할 수 있는지 문의해왔습니다.

우리는 Pulumi를 MARA의 핵심 부분으로 선택했습니다. 사용하기 쉽고 Python을 지원하기 때문입니다. Python은 매우 인기 있는 언어이기 때문에 많은 커뮤니티에서 MARA 코드를 쉽게 이해할 수 있습니다. 또한, 풀루미의 활기찬 커뮤니티와 프로젝트 참여는 MARA를 통해 이루고자 하는 지역 사회 참여의 모델이었습니다.

2021년 후반에 Sumo Logic 과 협력하여 MARA를 NGINX Ingress Controller와 함께 클라우드 모니터링 솔루션 의 일부로 만들었습니다. 이는 MARA가 플러그형이라는 우리의 주장을 시험해 볼 기회였습니다. 이번 과제는 MARA에서 Grafana, Prometheus, Elastic을 Sumo Logic 솔루션으로 대체하는 것이었습니다. 우리는 다른 배포에 사용한 것과 동일한 로직을 사용하여 솔루션을 성공적으로 구축하고, Sumo Logic SaaS에 연결할 수 있을 뿐만 아니라 환경에서 메트릭을 가져오도록 구성하게 되어 기뻤습니다.

OpenTelemetry와의 업무의 일환으로 Lightstep 과 협업하여 OTEL 수집기를 쉽게 재구성하여 추적 및 측정 항목을 Lightstep의 SaaS 제품으로 내보낼 수 있었습니다. 우리는 OTEL이 관찰 가능성의 미래라고 굳게 믿기 때문에 이 분야에 대해 더 자세히 조사하고 싶어합니다.

지금까지 얻은 교훈

지금까지 우리가 얻은 가장 큰 교훈은 모듈식 접근 방식이 현명하다는 것입니다. Sumo Logic과의 작업은 MARA 구성 요소를 성공적으로 혼합하고 일치시킬 수 있음을 보여줍니다. 우리는 OTEL을 환경에 더욱 완벽하게 통합함에 따라 추가적인 확인이 있을 것으로 기대합니다. 우리는 이전에 Elasticsearch를 Grafana Loki로 대체하는 것을 고려하고 있다고 언급했습니다. 이는 스택의 리소스 사용량을 줄이기 때문입니다. 그럼에도 불구하고 우리는 모든 것을 마이크로서비스로 만드는 극단적인 방법보다는 "실용적인 모듈성"을 옹호합니다. 예를 들어, 많은 애플리케이션의 로그를 처리할 수 있는 전문 서비스가 있는 것은 합리적이지만, 로그 수집, 저장 및 시각화를 위한 별도의 마이크로서비스가 필요하다는 것은 덜 분명합니다.

또한 관련 매개변수를 생략하는 것보다 구성에 명시적으로 포함하여 기본값을 설정하는 것이 도움이 된다는 것을 알게 되었습니다. 이것은 관리자에게 두 가지 면에서 편리합니다. 기본값을 기억할 필요가 없고 구성의 올바른 위치에 올바른 구문으로 이미 표시된 매개변수를 수정하기만 하면 기본값을 쉽게 변경할 수 있습니다.

우리가 얻은 또 다른 고통스러운 교훈은 일부 솔루션이 인기 있는 이유는 최고이기 때문이 아니라 설치가 가장 쉽거나 튜토리얼이 가장 훌륭하기 때문이라는 것입니다. 이것이 설계 과정에서 자신의 가정에 의문을 제기하고 동료와 상의하는 것이 매우 중요한 이유입니다. 개방적인 의사소통 문화는 문제를 일찍 식별하고 해결하는 데 큰 도움이 됩니다.

그럼에도 불구하고, 우리는 효과적인 논리를 구현했지만, 오히려 우리를 궁지에 몰거나 다른 문제를 야기하는 경우도 많았습니다. 예를 들어, Pulumi를 통해 애플리케이션을 배포하기 시작했을 때 ConfigMaps 에 대한 YAML 매니페스트를 사용했고 Pulumi 변환을 통해 변수를 업데이트했습니다. 이 방법은 효과적이긴 했지만 여러 가지 이유 때문에 이상적이지는 않았습니다. 그 중 가장 큰 이유는 유지 관리의 어려움이었습니다. 다음 반복 작업에서는 kube2pulumi를 사용하여 매니페스트를 ConfigMaps를 빌드하는 데 사용할 수 있는 Pulumi 코드로 변환하여 코드의 가독성과 유지 관리성을 개선했습니다.

또 다른 교훈은 병합에서 배포 YAML에 잘못된 설정이 삽입되었을 때 시작되었습니다. 우리는 코드가 구문적으로 정확하고 우리가 원하는 대로 동작하는지 확인하기 위해 YAML의 많은 부분을 다시 작성하고 신중하게 검토해야 했는데, 이는 답답하고 시간이 많이 걸리는 과정이었습니다. 향후 문제가 발생하지 않도록 이제 GitHub 푸시 프로세스 중에 일반 YAML과 Kubernetes 관련 린팅 및 검증을 모두 자동화했습니다 .

마지막으로, 처음부터 우리의 목표는 메인라인 브랜치가 항상 실행 가능하도록 하는 것이었습니다. 새로운 프로젝트를 체크아웃할 때 메인라인에서 관리자가 발생시킨 문제를 해결해야 하면 실망스럽습니다. 불행히도, 우리는 이 부분에서 몇 번 실패했습니다. 여기에는 Bank of Sirius 하위 모듈의 예도 포함됩니다.

• 우리는 실수로 URL 체계를 ssh:// 에서 https:// 로 변경하는 것을 잊었습니다. 우리에게는 문제가 되지 않았습니다. 왜냐하면 우리 모두 ssh를 사용해 GitHub에 접속했기 때문입니다. 그러나 GitHub의 SSH 키가 없는 사용자는 하위 모듈을 초기화하려고 하면 오류 메시지에 압도당했습니다.
• 관리 스크립트의 한 릴리스에는 모든 사람의 컴퓨터에 설치되어 있는 것처럼 우리 컴퓨터에도 설치되어 있을 것이라고 잘못 가정한 공통 패키지에 대한 종속성이 있었습니다.
• 우리는 시작 로직을 다시 작성할 때 하위 모듈 소스에 대한 검사를 넣는 것을 잊었습니다. 해당 하위 모듈에는 Bank of Sirius를 배포하는 데 필요한 매니페스트가 포함되어 있지만, 불행히도 이러한 매니페스트를 사용할 수 없을 때 발생하는 오류와 경고는 너무 모호해서 이상한 동작을 디버깅하는 데 며칠이 걸렸고, 결국 근본 원인을 발견하지 못했습니다.

다음은 무엇인가

우리는 향후 몇 달 동안 NGINX Ingress Controller 빌드 리팩토링, 레지스트리 푸시, Ingress 호스트 이름/IP 주소 로직을 포함한 대규모 개발을 계획하고 있습니다.

MARA의 모든 스탠드업에서 우리가 알아차린 한 가지는 NGINX Ingress Controller에 대한 스캔과 공격이 얼마나 빨리 발생하는지입니다. 이로 인해 NGINX Ingress Controller를 MARA의 NGINX App Protect WAF와 통합하기 시작하게 되었습니다. 여기에는 App Protect에서 생성된 로깅을 가장 잘 관리하는 방법을 결정해야 하는 과제와 기회가 함께 제공됩니다.

앞으로 몇 달 안에 우리가 할 계획인 또 다른 변경 사항은 모든 모듈이 Pulumi와 Kubernetes 둘 다가 아닌 Kubernetes에서 비밀을 가져오는 것입니다. 즉, 모든 모듈은 공통적인 비밀 저장소를 사용하고 관리자는 비밀이 채워지는 방식을 제어할 수 있습니다. 우리는 사용자가 선택한 저장소에서 비밀을 읽고 해당 Kubernetes 비밀을 생성하는 새로운 모듈을 작성하고 있습니다.

MARA는 현재 Bank of Sirius를 포크한 원래 Bank of Anthos 앱에 포함된 Locust 기반 도구의 업그레이드되고 약간 수정된 버전인 부하 생성 도구를 포함하고 있습니다. 우리가 작성 중인 새로운 테스트 도구인 Cicada Swarm은 부하를 생성할 뿐만 아니라 메트릭이 설정된 임계값을 넘을 때 이를 추적하고 보고하므로 클라우드에서 소프트웨어 제품의 성능을 빠르게 테스트할 수 있는 프레임워크입니다. 이 솔루션은 병렬화 기술을 사용하여 필요한 신뢰 수준을 갖춘 테스트 결과와 더 높은 정밀도, 그리고 사용자 정의 가능한 회귀 분석을 제공하여 CI/CD 파이프라인에서 빌드의 성공 또는 실패를 판별합니다.

마지막으로, 부하 테스트에 대해 언급하려면 부하 테스트의 영향을 측정하는 방법에 대해 이야기해야 하는데, 이를 위해서는 원격 측정으로 돌아가야 합니다. 우리는 OpenTelemetry의 잠재력에 기대를 걸고 있으며, 곧 좀 더 포괄적으로 구현할 수 있기를 바랍니다. 완벽하게 구현하지 않더라도 테스트를 실행하고, 영향을 측정하고, 데이터가 알려주는 내용을 바탕으로 운영 결정을 내리는 것이 저희의 목표입니다.

언제나처럼 여러분의 풀 리퀘스트 , 이슈 , 댓글을 환영합니다. MARA의 목표는 커뮤니티가 함께 모여 다양한 잠재적 솔루션을 논의하고, 시도하고, 테스트하고, 반복하도록 영감을 주는 것입니다. 이를 통해 최신 애플리케이션을 가장 잘 배포하고 관리하는 방법에 대한 이해를 높이는 것입니다.

관련 게시물

이 게시물은 시리즈의 일부입니다. 시간이 지남에 따라 MARA에 기능을 추가함에 따라 블로그에 세부 정보를 게시하고 있습니다.

• 새로운 오픈 소스 모던 앱 참조 아키텍처
• 최신 앱 참조 아키텍처에 OpenTelemetry 통합 - 진행 상황 보고서
• 마라: 이제 가까운 워크스테이션에서 실행 중
• NGINX Modern Apps Reference Architecture의 버전 1.0.0 발표 (이 게시물)