NGINX로 Micro-Frontend 배포하기

Open Source 및 Red Hat® 기술을 전문으로 하는 네덜란드 IT 컨설팅 회사인 HCS Company는 다른 접근 방식으로 기관의 프로세스를 디지털화하는 새로운 방법에 NGINX 통합을 시도했습니다.

다양한 이해관계자와 사용자를 보유한 네덜란드의 한 국가 정부 기관은 Workflow를 Paper‑Based 프로세스에서 현대적인 디지털 인프라로 전환하고자 했습니다. 이를 통해 기관은 보다 신속하게 이동하고 사용자와 직원의 삶을 단순화할 수 있습니다.

기관은 각 참여 지역이 다소 고유한 프로세스와 요구 사항을 만들 수 있도록 허용했습니다. 처음에 이 기관은 수많은 사용자 정의가 포함된 포괄적인 Monolithic 애플리케이션을 만들기 위해 많은 노력을 기울였습니다. 첫 번째 노력은 Hyper‑Customization의 수천 가지 요구사항으로 인해 실패했습니다.

목차

1. 간단한 재구성: 구성 가능한 Micro-Frontend, 컨테이너 및 Microservices
2. Windows에서 Linux, .Net Core 및 NGINX Open Source까지
3. 관찰 가능성, 확장성 및 유연성을 위한 설계
4. 기술 스택

1. 간단한 재구성: 구성 가능한 Micro-Frontend, 컨테이너 및 Microservices

기관의 DevOps팀은 HCS의 수석 Site Reliability Engineer(SRE)인 Benoit Schipper와 함께 프로젝트에 참여했습니다. 그들은 함께 그들이 해결하고 있는 문제를 더 깊이 살펴보는 것으로 시작했습니다. 공무원부터 변호사, 회계사, 일반 시민에 이르기까지 사용자는 기관 애플리케이션에 로그인하여 프로젝트 또는 프로세스의 상태를 확인하고 PDF를 업로드해야 합니다. Benoit과 팀은 솔루션의 출발점으로 간단한 기반을 구축하기로 결정했습니다. Benoit는 “우리는 그것을 보고 ‘매우 일반적인 것을 만들고 특별한 요청이 있으면 그 일반적인 기반에서 구축할 수 있습니다.’라고 설명합니다. 또한 DevOps팀은 기존 인프라 내에서 확장성과 향후 필요할 수 있는 추가 위치 및 애플리케이션 모두에 대한 확장성을 보장하여 기반을 미래에 대비할 수 있기를 원했습니다.

Benoit과 팀은 그 미래를 화이트보드로 작성했습니다. Backend에서 작고 개별적인 서비스(Microservices)에 매핑된 다양한 애플리케이션으로 구성될 수 있는 매우 작은(Micro) Frontend의 새로운 아키텍처에 도달했습니다. Benoit는 “우리는 Microservices를 선택했습니다. 그 아키텍처를 사용하면 클라우드로 이동하고 규모가 커질 때 확장할 준비가 되어 있기 때문입니다.”라고 말합니다.” 우리는 퍼즐을 함께 붙일 수 있는 더 작은 조각으로 분리했습니다.”

Diagram of tech stack at Dutch government agency as implemented by IT consultant HCS Company

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

OpenShift를 선호하는 두 가지 강력한 요인이 있습니다. 첫째, RedHat은 오랜 기간 동안 정부와 협력하여 설계에 대한 정부 승인을 쉽게 받을 수 있었습니다. 둘째, OpenShift에는 다음과 같이 Microservices 및 Microservices 아키텍처를 쉽게 구축하고 유지 관리할 수 있도록 설계된 많은 도구와 애플리케이션이 포함되어 있습니다.

  • Red Hat Ceph® Storage – S3 호환 API를 통해 액세스할 수 있는 Blob Storage 서비스
  • Red Hat AMQ Broker – Workload 및 애플리케이션 상태를 관리하고 Worker를 큐(Queue)에 추가하기 위한 메시지 버스 서비스
  • Kubernetes에 대한 기본 제공 인증 지원 – HCS와 기관이 Kubernetes가 컨테이너 오케스트레이션에 적합한 도구라고 판단하는 경우 향후 추가적인 예방을 위해 중요합니다

2. Windows에서 Linux, .Net Core 및 NGINX Open Source까지

컨테이너로 이동한다는 것은 Windows 서버에서 실행되는 기관의 이전 .Net Backend를 교체하는 것을 의미했습니다. 다행히 컨테이너에 최적화된 .Net 버전인 .Net Core로 쉽게 전환할 수 있었습니다. 또 다른 이점은 기관의 개발자가 익숙한 Windows 애플리케이션 언어 및 프레임워크(Famework)로 코딩을 계속할 수 있다는 것입니다.

DevOps팀은 .Net Core Backend 서비스에 액세스하기 위한 핵심 REST API 세트를 구축했습니다. API는 애플리케이션 기능과 로직을 결합하는 Micro‑Frontend를 함께 고정하는 접착제입니다. Frontend 환경의 경우 팀은 정부 기관에서 강력한 커뮤니티가 있는 강력하고 신뢰할 수 있는 JavaScript 프레임워크로 폭넓게 수용되는 AngularJS를 선택했습니다.

Frontend와 Backend 사이에서 오가는 트래픽 및 API 호출을 위한 Cohesive 라우팅 계층을 만들기 위해, 팀은 다양한 옵션으로 인해 NGINX Open Source에 정착했습니다. 기관 웹사이트의 페이지는 콘텐츠 요소를 가져오고 동일한 CSS 로직을 사용하여 여러 Backend 서비스를 “skin” 하여 Micro‑Frontend로 즉석에서 구축됩니다. 사용자에게는 모든 것이 동일한 애플리케이션 내에서 발생하는 것처럼 보이지만 “실제로 우리는 NGINX 로 Smart Proxy 및 Rewrite을 사용하고 있습니다. Frontend에 적합한 정보로 화면을 채우려면 NGINX 를 통해 Backend API 호출을 수행합니다.”라고 Benoit는 설명합니다.

애플리케이션을 Public 인터넷에 Expose 하기 위해 Benoit는 NGINX Plus 인스턴스를 기관의 DMZ에서 실행되는 가상 머신에 웹 서버 및 Reverse Proxy로 배포했습니다. 그는 NGINX Plus가 적합한 이유를 다음과 같이 설명합니다. “우리는 TLS 1.3이 필요했고 빠르게 이동하고 싶었습니다. 전용 Appliances에 비해 저렴하고 라이선스를 쉽게 추가할 수 있었습니다.”

Benoit은 “NGINX 는 애플리케이션 계층을 위한 웹 서버, Proxy 및 기본 API Gateway로 작동합니다. 정말 거의 모든 것을 할 수 있는 Swiss Army Knife™입니다. 그것이 우리가 그것을 사용하는 이유입니다.”라고 말합니다. 예를 들어 업로드된 PDF를 검색하기 위해 사용자는 자신의 계정에 업로드된 문서에서 필요한 PDF를 선택하고 PDF 전달 애플리케이션은 Ceph 개체 저장소에 연결된 Backend PDF 검색 서비스에 요청을 보냅니다. Ceph는 객체 저장소에서 PDF 위치의 고유 URL을 반환하며, 사용자는 이 URL을 클릭하여 보거나 다운로드할 수 있습니다.

애플리케이션이 Mission‑Critical하기 때문에 팀은 모든 애플리케이션이 최소 2개의 클러스터에서 실행되는 Active‑Active 고가용성 아키텍처를 설계했습니다. 이는 모든 서비스, Micro‑Frontend 및 API에 대한 중복성을 제공하여 클러스터 중 하나가 중단되는 경우에도 계속 작동하도록 합니다.

성능을 개선하고 여러 서비스에 걸쳐 있는 복합 애플리케이션에 대한 Control Plane을 활성화하기 위해 팀은 AMQ Broker 메시지 버스를 사용하여 서비스에 대한 주제 및 큐(Queue)을 구성합니다. “그래서 백그라운드에서 실행할 수 있는 것이 있으면 백그라운드에서 실행합니다.”라고 Benoit는 말합니다. “메시지가 들어오고 일부 메서드 데이터를 조정해야 하는 경우 무언가를 처리할 수 있는 Listener가 있거나 프로세스를 실행할 작업자를 찾을 수 있습니다.” 클러스터 전체에서 사용자의 일관된 상태를 보장하기 위해 팀은 Pod 상태를 유지하고 세션 지속성을 활성화하기 위해 기존의 고가용성 Microsoft SQL Server 데이터베이스 인프라를 유지했습니다.

3. 관찰 가능성, 확장성 및 유연성을 위한 설계

관찰 가능성을 위해 Benoit는 Grafana를 클라우드 네이티브 대시보드로 추천했습니다. NGINX 지표를 얻기 위해 DevOps팀은 각 Pod에 페어링 된 사이드카(Sidecar)에서 NGINX Prometheus Expose를 활용합니다. Expose 도구는 NGINX Open Source Stub Status 모듈 및 NGINX Plus API에서 Layer4 지표를 스크랩하고 각각을 문자열과 일치시키고 Key-Value 쌍을 생성한 다음 쌍을 Prometheus로 Push 합니다. 거기에서 쌍은 개발자와 DevOps팀에게만 Expose 되는 별도의 Grafana 인스턴스에 게시됩니다. 모든 NGINX Open Source 및 NGINX Plus 인스턴스의 단일 위치에서 대시보드를 구축하고 지표를 수집할 수 있습니다. DevOps팀이 관리하고 있습니다. 실행 중인 항목을 확인하고 문제에 대한 알림을 받을 수 있습니다.

팀은 또한 애플리케이션의 성능 관리를 위해 지표를 사용합니다. Prometheus는 애플리케이션에서 예외 및 처리되지 않은 연결에 대한 경고를 생성하여 실행 중인 작업자가 충분하지 않다는 신호를 보냅니다. Benoit은 지표를 OpenShift의 자동 스케일링 기능에 연결했습니다. 그는 “특정 수의 작업자에 대해 NGINX 설정을 구성하고 필요한 RAM과 CPU를 계산했습니다. 해당 기준선에 비해 작업량이 너무 많으면 OpenShift가 자동으로 스케일업하고 알림을 전송한다.”라고 설명했습니다.

4. 기술 스택 (With NGINX)

NGINX Plus와 함께 기술 스택을 구축하여 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.