HCS, NGINX로 유연한 프런트엔드 애플리케이션 계층 구축

다양한 이해 관계자와 사용자를 보유한 네덜란드의 한 국가 정부 기관은 업무 흐름을 종이 기반 프로세스에서 최신 디지털 인프라로 전환하고자 했습니다. 이를 통해 기관은 더욱 신속하게 움직일 수 있고 사용자와 직원의 생활도 간소화될 것입니다.

도전은? 이 기관은 각 참여 지역이 다소 독특한 프로세스와 요구 사항을 만들 수 있도록 허용했습니다. 처음에 이 기관은 다양한 사용자 정의가 가능한 모든 것을 포함하는 일체형 애플리케이션을 만드는 데 많은 노력을 기울였습니다. 첫 번째 시도는 과도한 맞춤화의 무게로 인해 실패했습니다. "천 가지 요구 사항에 따른 죽음"이었습니다. HCS 회사오픈 소스 및 Red Hat® 기술을 전문으로 하는 네덜란드 IT 컨설팅 회사는 다른 접근 방식으로 기관의 프로세스를 디지털화하는 새로운 방법을 시도하기 위해 선정되었습니다.

간단한 재구축: 구성 가능한 마이크로 프런트 엔드, 컨테이너 및 마이크로서비스

해당 기관의 DevOps 팀은 HCS의 수석 사이트 안정성 엔지니어(SRE)인 Benoit Schipper와 함께 프로젝트를 진행했습니다. 그들은 함께 자신들이 해결하고자 하는 문제를 더 깊이 살펴보기 시작했습니다. 공무원부터 변호사, 회계사, 일반 시민까지 다양한 사용자는 기관 앱에 로그인하여 프로젝트나 프로세스의 상태를 확인하고 PDF를 업로드해야 합니다. 베누아와 그의 팀은 솔루션의 출발점으로 간단한 토대를 구축하기로 결정했습니다. Benoit는 "우리는 그것을 보고 '아주 일반적인 것을 만들어 보자. 그리고 특별한 요청이 있을 경우 그 일반적인 기반을 바탕으로 구축할 수 있다'고 말했습니다."라고 설명합니다. DevOps 팀은 또한 기존 인프라 내에서뿐만 아니라 향후 필요할 수 있는 추가 위치 및 애플리케이션에 대한 확장성을 보장하여 기반을 미래에도 사용할 수 있도록 만들고자 했습니다.

Benoit와 팀은 그 미래를 화이트보드로 그려서 백엔드의 작고 개별적인 서비스(마이크로서비스)에 매핑된 다양한 애플리케이션으로 구성할 수 있는 매우 작은(마이크로) 프런트엔드의 새로운 아키텍처를 도출했습니다. Benoit는 "우리는 마이크로서비스를 선택했습니다. 이 아키텍처를 사용하면 클라우드로 이동하여 규모가 매우 커질 때 확장할 준비가 되어 있기 때문입니다."라고 말했습니다. "우리는 퍼즐을 서로 붙일 수 있는 작은 조각으로 나누었습니다."

구현과 관련된 첫 번째 결정은 전용 환경의 Microsoft Windows 서버에서 구성 가능하고 유연한 마이크로서비스에 더 적합한 클라우드의 컨테이너 기반 환경으로 전환하는 것이었습니다. 팀은 컨테이너 플랫폼으로 Red Hat OpenShift®를 선택했습니다.

OpenShift가 유리한 데에는 두 가지 강력한 요소가 있었습니다. 첫째, RedHat은 정부와 협력한 오랜 경험을 바탕으로 설계에 대한 정부 승인을 쉽게 받을 수 있었습니다. 두 번째로, OpenShift에는 마이크로서비스 및 마이크로서비스 아키텍처의 손쉬운 구축 및 유지 관리를 위해 설계된 많은 도구와 애플리케이션이 포함되어 있습니다. 여기에는 다음이 포함됩니다.

• Red Hat Ceph® Storage – S3 호환 API를 통해 액세스 가능한 Blob 스토리지 서비스
• Red Hat AMQ Broker – 작업 부하 및 애플리케이션 상태를 관리하고 작업자를 대기열에 넣기 위한 메시지 버스 서비스
• Kubernetes에 대한 내장형 인증 지원 – HCS와 기관에서 Kubernetes가 컨테이너 오케스트레이션에 적합한 도구라고 판단하는 경우 향후 추가 보호를 위해 중요함

Windows에서 Linux, .Net Core, NGINX 오픈 소스까지

컨테이너로 전환한다는 것은 Windows 서버에서 실행되던 기존 기관의 .Net 백엔드를 대체하는 것을 의미했습니다. 다행히도 컨테이너에 최적화된 .Net 버전인 .Net Core 로의 전환은 쉬웠습니다. 또 다른 이점은 해당 기관의 개발자들이 익숙한 Windows 애플리케이션 언어와 프레임워크로 코딩을 계속할 수 있다는 것입니다.

DevOps 팀은 .Net Core 백엔드 서비스에 액세스하기 위한 핵심 REST API 세트를 구축했습니다. API는 애플리케이션 기능과 로직, 마이크로 프런트 엔드를 연결하는 접착제입니다. 프런트엔드 환경에서 팀은 정부 기관에서 강력하고 안정적인 JavaScript 프레임워크로 널리 받아들여지고 강력한 커뮤니티를 갖춘 AngularJS를 선택했습니다.

프런트엔드와 백엔드 간의 트래픽과 API 호출을 위한 통합된 라우팅 계층을 만들기 위해 팀은 다양한 옵션을 탐색한 후 다재다능한 NGINX 오픈 소스를 선택했습니다. 대행사 웹사이트의 페이지는 콘텐츠 요소를 가져오고 동일한 CSS 논리를 사용하여 여러 백엔드 서비스를 "스킨"하여 마이크로 프런트 엔드로 즉석에서 구축됩니다. 사용자에게는 모든 것이 동일한 애플리케이션 내에서 일어나는 것처럼 보이지만, "사실 우리는 NGINX로 스마트 프록싱과 재작성을 사용하고 있습니다. 프런트 엔드에 적합한 정보로 화면을 채우기 위해 NGINX를 통해 백엔드 API 호출을 수행합니다."라고 Benoit는 설명합니다.

애플리케이션을 공개 인터넷에 노출시키기 위해 Benoit는 F5 NGINX Plus 인스턴스를 웹 서버로 배포하고 기관의 DMZ에서 실행되는 가상 머신에 역방향 프록시를 설치했습니다. 그는 NGINX Plus가 적합한 이유를 다음과 같이 설명합니다. “우리는 TLS 1.3이 필요했고 빠르게 움직이고 싶었습니다. 전용 기기에 비해 저렴했고 라이센스를 쉽게 추가할 수 있었습니다."

Benoit는 기관의 경우 "NGINX는 애플리케이션 계층을 위한 웹 서버, 프록시 및 기본 API 게이트웨이로 작동합니다. 사실 이것은 거의 모든 것을 할 수 있는 스위스 군용 칼™입니다. 그래서 우리는 그것을 사용하죠." 예를 들어, 업로드된 PDF를 검색하려면 사용자가 자신의 계정에 업로드된 문서에서 필요한 PDF를 선택하고 PDF 전달 애플리케이션은 Ceph 객체 저장소에 연결된 백엔드 PDF 검색 서비스에 요청을 보냅니다. Ceph는 개체 저장소에서 PDF 위치의 고유 URL을 반환하고, 사용자는 이를 클릭하여 보거나 다운로드할 수 있습니다.

해당 애플리케이션이 미션 크리티컬하기 때문에 팀에서는 모든 애플리케이션이 최소 두 개의 클러스터에서 실행되는 액티브-액티브 고가용성 아키텍처를 설계했습니다. 이를 통해 모든 서비스, 마이크로 프런트 엔드 및 API에 중복성을 제공하여 클러스터 중 하나에서 중단이 발생하더라도 계속 작동할 수 있습니다.

여러 서비스에 걸쳐 있는 복합 애플리케이션의 성능을 개선하고 제어 평면을 활성화하기 위해 팀은 AMQ 브로커 메시지 버스를 사용하여 서비스의 토픽과 대기열을 구성합니다. "그래서 백그라운드에서 무엇이든 실행할 수 있다면, 우리는 백그라운드에서 그것을 실행합니다."라고 Benoit는 말합니다. "메시지가 들어오고 일부 메서드 데이터를 조정해야 하는 경우, 무언가를 처리하거나 프로세스를 실행할 작업자를 찾을 수 있는 리스너가 있습니다." 클러스터 전반의 사용자에게 일관된 상태를 보장하기 위해, 팀은 기존의 고가용성 Microsoft SQL Server 데이터베이스 인프라를 유지하여 Pod 상태를 유지하고 세션 지속성을 활성화했습니다.

관찰성, 확장성 및 유연성을 위한 설계

관찰 가능성을 위해 Benoit는 클라우드 기반 대시보드로 Grafana를 권장했습니다. NGINX 메트릭을 얻기 위해 DevOps 팀은 각 Pod와 페어링된 사이드카에서 NGINX Prometheus Exporter를 활용합니다. Exporter는 NGINX 오픈 소스 스텁 상태 모듈 과 NGINX Plus API 에서 레이어 4 메트릭을 스크래핑하고 각각을 문자열과 일치시키고 키‑값 쌍을 생성한 다음 쌍을 Prometheus 에 푸시합니다. 여기에서 해당 쌍은 개발자와 DevOps 팀에게만 공개되는 별도의 Grafana 인스턴스에 게시됩니다. “정말 놀랍죠. 모든 NGINX 오픈 소스 및 NGINX Plus 인스턴스에서 대시보드를 구축하고 메트릭을 한곳에서 수집할 수 있습니다. DevOps 팀이 통제하고 있습니다. Benoit는 "그들은 무엇이 실행 중인지 보고 문제에 대한 알림을 받을 수 있습니다."라고 말했습니다.

또한 팀은 애플리케이션의 성능 관리를 위해 측정 항목을 활용합니다. Prometheus는 애플리케이션에서 예외 및 처리되지 않은 연결에 대한 알림을 생성하는데, 이는 실행 중인 작업자가 충분하지 않다는 신호입니다. Benoit는 해당 지표를 OpenShift의 자동 확장 기능과 연결했습니다. 그는 "저는 특정 수의 작업자에 맞게 NGINX 설정을 구성하고 필요한 RAM과 CPU를 계산했습니다. 기준선에 비해 일이 너무 바빠지면 OpenShift가 자동으로 확장되어 알림을 보냅니다."

침투 테스트에서 애플리케이션이 강력한 콘텐츠 보안 정책(CSP)을 사용하지 않는다는 사실이 확인되자, 해당 팀은 CSP를 인라인으로 시행하기 위한 정책으로 NGINX Open Source 및 NGINX Plus를 구성할 수 있었습니다. 또한 컨테이너 플랫폼에서 JSON 로깅 정보를 가져와 Splunk 로깅 플랫폼으로 전송하여 과거 분석 및 기록 보관을 위한 사용자 지정 구성을 설정했습니다.

개발자 경험 개선

Google Analytics와 Lighthouse를 사용하는 프런트엔드 개발자의 경우 HCS는 NGINX 구성에 코딩된 Lighthouse 검사를 기관의 파이프라인에 포함할 수 있도록 했습니다. Benoit는 "GZIP 압축 라이브러리로 변경하면 상당한 성능 향상이 가능하다는 것을 금방 깨달았습니다."라고 말하며 그 결과 애플리케이션 대기 시간이 60% 향상되었습니다.

또한, 새로운 아키텍처를 사용하면 개발자는 실시간 동작에 대한 세부적인 가시성을 확보할 수 있으므로 이제 최종 사용자와 직접 접촉할 수 있습니다. "피드백 루프가 훨씬 빠르고, 무슨 일이 생겨서 변경이 필요하다면 단 하루 만에 생산에 투입할 수 있습니다. Benoit는 "정부 입장에서는 매우 빠른 속도입니다. 과거에는 변화가 몇 달 또는 몇 년이 걸렸습니다."라고 말했습니다. "저희 개발자들에게는 이는 밤과 낮과 같습니다."

기술 스택

• 백엔드 – .Net Core
• 프런트엔드 – AngularJS
• 네트워킹 (웹 서버, 역방향 프록시, API 게이트웨이, Ingress 컨트롤러, 글로벌 로드 밸런서) – NGINX 오픈 소스 , NGINX Plus , F5 BIG‑IP , HAProxy (OpenShift에서)
• 데이터베이스 – Microsoft SQL Server , Red Hat Ceph Storage , Lighthouse 데이터용 InfluxDB
• CI/CD – Azure DevOps
• 인프라 – Red Hat OpenShift , Linux 컨테이너
• 메시징 – Red Hat AMQ Broker (Active MQ 오픈 소스)
• 관찰 가능성 및 메트릭 – Grafana , Prometheus
• 로깅 – Splunk

시작하기

NGINX Plus에 기술 스택을 구축하여 이 프로젝트의 훌륭한 결과를 재현하고 싶으신가요? 오늘 30일 무료 체험판을 시작하거나, 당사에 문의하여 사용 사례에 대해 논의해 보세요 .