다양한 이해 관계자와 사용자를 보유한 네덜란드의 국가 정부 기관은 워크플로를 종이 기반 프로세스에서 최신 디지털 인프라로 옮기고 싶어했습니다. 이를 통해 기관은 더 빠르게 움직이고 사용자와 직원의 삶을 단순화할 수 있었습니다.
과제는? 기관은 각 참여 지역이 다소 고유한 프로세스와 요구 사항을 만들 수 있도록 허용했습니다. 처음에 기관은 수많은 사용자 정의를 통해 모든 것을 포함하는 모놀리식 애플리케이션을 만드는 데 많은 노력을 기울였습니다. 첫 번째 노력은 과도한 사용자 정의의 무게로 실패했습니다. "천 가지 요구 사항에 의한 죽음"이었습니다. 오픈 소스 및 Red Hat® 기술을 전문으로 하는 네덜란드 IT 컨설팅 회사인 HCS Company는 다른 접근 방식으로 기관의 프로세스를 디지털화하는 새로운 방법을 시도하기 위해 선정되었습니다.
간단한 재구축: 구성 가능한 마이크로 프런트 엔드, 컨테이너 및 마이크로 서비스
기관의 DevOps 팀은 HCS의 수석 사이트 안정성 엔지니어(SRE)인 Benoit Schipper와 함께 프로젝트를 진행했습니다. 그들은 함께 해결하고 있는 문제를 더 자세히 살펴보는 것으로 시작했습니다. 공무원부터 변호사, 회계사, 일반 시민에 이르기까지 다양한 사용자가 기관 앱에 로그인하여 프로젝트나 프로세스의 상태를 확인하고 PDF를 업로드해야 합니다. Benoit와 팀은 솔루션의 시작점으로 간단한 기반을 구축하기로 결정했습니다. 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 게이트웨이로 작동합니다. 사실상 거의 모든 것을 할 수 있는 Swiss Army Knife™입니다. 그래서 사용하는 것입니다."라고 강조합니다. 예를 들어 업로드된 PDF를 검색하려면 사용자가 계정에 업로드된 문서에서 필요한 PDF를 선택하고 PDF 전달 애플리케이션은 Ceph 객체 저장소에 연결된 백엔드 PDF 검색 서비스에 요청을 보냅니다. Ceph는 객체 저장소에서 PDF 위치의 고유 URL을 반환하고, 사용자는 이를 클릭하여 보거나 다운로드합니다.
애플리케이션이 미션 크리티컬하기 때문에 팀은 모든 애플리케이션이 최소 두 개의 클러스터에서 실행되는 액티브-액티브 고가용성 아키텍처를 설계했습니다. 이를 통해 모든 서비스, 마이크로 프런트 엔드 및 API에 대한 중복성을 제공하여 클러스터 중 하나에서 중단이 발생하더라도 계속 작동할 수 있도록 합니다.
성능을 개선하고 여러 서비스에 걸친 복합 애플리케이션에 대한 제어 플레인을 활성화하기 위해 팀은 AMQ Broker 메시지 버스를 사용하여 서비스에 대한 토픽과 대기열을 구성합니다. Benoit는 "그래서 백그라운드에서 실행할 수 있는 것이 있다면 백그라운드에서 실행합니다."라고 말합니다. "메시지가 들어오고 일부 메서드 데이터를 조정해야 하는 경우, 무언가를 처리하거나 프로세스를 실행할 작업자를 찾을 수 있는 리스너가 있습니다." 클러스터 전체에서 사용자에게 일관된 상태를 보장하기 위해 팀은 기존의 고가용성 Microsoft SQL Server 데이터베이스 인프라를 유지하여 포드 상태를 유지하고 세션 지속성을 활성화했습니다.
관찰성, 확장성 및 유연성을 위한 설계
영어: 관찰 가능성을 위해 Benoit는 클라우드 네이티브 대시보드로 Grafana를 권장했습니다. NGINX 메트릭을 얻기 위해 DevOps 팀은 각 포드와 페어링된 사이드카에서 NGINX Prometheus Exporter를 활용합니다. Exporter는 NGINX Open Source Stub Status 모듈 과 NGINX Plus API 에서 레이어 4 메트릭을 스크래핑 하고 각각을 문자열과 일치시키고 키-값 쌍을 생성한 다음 쌍을 Prometheus 로 푸시합니다 . 거기에서 쌍은 개발자와 DevOps 팀에만 노출되는 별도의 Grafana 인스턴스에 게시됩니다. Benoit는 "놀랍습니다. 모든 NGINX Open Source 및 NGINX Plus 인스턴스에서 대시보드를 빌드하고 단일 위치에서 메트릭을 수집할 수 있습니다. DevOps 팀이 제어합니다. 실행 중인 항목을 보고 문제에 대한 알림을 받을 수 있습니다."라고 말합니다.
팀은 또한 애플리케이션의 성능 관리를 위해 메트릭을 사용합니다. 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
다양한 이해 관계자와 사용자를 보유한 네덜란드의 국가 정부 기관은 워크플로를 종이 기반 프로세스에서 최신 디지털 인프라로 옮기고 싶어했습니다. 이를 통해 기관은 더 빠르게 움직이고 사용자와 직원의 삶을 단순화할 수 있었습니다.
과제는? 기관은 각 참여 지역이 다소 고유한 프로세스와 요구 사항을 만들 수 있도록 허용했습니다. 처음에 기관은 수많은 사용자 정의를 통해 모든 것을 포함하는 모놀리식 애플리케이션을 만드는 데 많은 노력을 기울였습니다. 첫 번째 노력은 과도한 사용자 정의의 무게로 실패했습니다. "천 가지 요구 사항에 의한 죽음"이었습니다. 오픈 소스 및 Red Hat® 기술을 전문으로 하는 네덜란드 IT 컨설팅 회사인 HCS Company는 다른 접근 방식으로 기관의 프로세스를 디지털화하는 새로운 방법을 시도하기 위해 선정되었습니다.
간단한 재구축: 구성 가능한 마이크로 프런트 엔드, 컨테이너 및 마이크로 서비스
기관의 DevOps 팀은 HCS의 수석 사이트 안정성 엔지니어(SRE)인 Benoit Schipper와 함께 프로젝트를 진행했습니다. 그들은 함께 해결하고 있는 문제를 더 자세히 살펴보는 것으로 시작했습니다. 공무원부터 변호사, 회계사, 일반 시민에 이르기까지 다양한 사용자가 기관 앱에 로그인하여 프로젝트나 프로세스의 상태를 확인하고 PDF를 업로드해야 합니다. Benoit와 팀은 솔루션의 시작점으로 간단한 기반을 구축하기로 결정했습니다. Benoit는 "우리는 그것을 살펴보고 '매우 일반적인 것을 만들고, 특별한 요청이 있을 경우 그 일반적인 기반을 기반으로 구축할 수 있습니다'라고 말했습니다."라고 설명합니다. DevOps 팀은 또한 기존 인프라 내에서와 미래에 필요할 수 있는 추가 위치 및 애플리케이션 모두에 대한 확장성을 보장하여 기반을 미래에 대비하고자 했습니다.
Benoit와 팀은 그 미래를 화이트보드로 표시하고 백엔드의 작고 개별적인 서비스(마이크로서비스)에 매핑된 다양한 애플리케이션으로 구성할 수 있는 매우 작은(마이크로) 프런트엔드의 새로운 아키텍처에 도달했습니다. Benoit는 "마이크로서비스를 선택한 이유는 그 아키텍처를 사용하면 클라우드로 이동하고 매우 커질 때 확장할 준비가 되어 있기 때문입니다."라고 말합니다. "우리는 퍼즐을 서로 붙일 수 있는 더 작은 조각으로 나누었습니다."
구현에 대한 첫 번째 결정은 전용 환경의 Microsoft Windows 서버에서 구성 가능하고 유연한 마이크로서비스에 더 적합한 클라우드의 컨테이너 기반 환경으로 이동하는 것이었습니다. 팀은 컨테이너 플랫폼으로 Red Hat OpenShift®를 선택했습니다.
OpenShift에 유리한 두 가지 강력한 요소가 있었습니다. 첫째, RedHat이 정부와 협력한 오랜 경험 덕분에 설계에 대한 정부 승인을 쉽게 받을 수 있었습니다. 둘째, OpenShift에는 마이크로서비스 및 마이크로서비스 아키텍처의 손쉬운 구축 및 유지 관리를 위해 설계된 많은 도구와 애플리케이션이 포함되어 있습니다. 여기에는 다음이 포함됩니다.
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 게이트웨이로 작동합니다. 사실상 거의 모든 것을 할 수 있는 Swiss Army Knife™입니다. 그래서 사용하는 것입니다."라고 강조합니다. 예를 들어 업로드된 PDF를 검색하려면 사용자가 계정에 업로드된 문서에서 필요한 PDF를 선택하고 PDF 전달 애플리케이션은 Ceph 객체 저장소에 연결된 백엔드 PDF 검색 서비스에 요청을 보냅니다. Ceph는 객체 저장소에서 PDF 위치의 고유 URL을 반환하고, 사용자는 이를 클릭하여 보거나 다운로드합니다.
애플리케이션이 미션 크리티컬하기 때문에 팀은 모든 애플리케이션이 최소 두 개의 클러스터에서 실행되는 액티브-액티브 고가용성 아키텍처를 설계했습니다. 이를 통해 모든 서비스, 마이크로 프런트 엔드 및 API에 대한 중복성을 제공하여 클러스터 중 하나에서 중단이 발생하더라도 계속 작동할 수 있도록 합니다.
성능을 개선하고 여러 서비스에 걸친 복합 애플리케이션에 대한 제어 플레인을 활성화하기 위해 팀은 AMQ Broker 메시지 버스를 사용하여 서비스에 대한 토픽과 대기열을 구성합니다. Benoit는 "그래서 백그라운드에서 실행할 수 있는 것이 있다면 백그라운드에서 실행합니다."라고 말합니다. "메시지가 들어오고 일부 메서드 데이터를 조정해야 하는 경우, 무언가를 처리하거나 프로세스를 실행할 작업자를 찾을 수 있는 리스너가 있습니다." 클러스터 전체에서 사용자에게 일관된 상태를 보장하기 위해 팀은 기존의 고가용성 Microsoft SQL Server 데이터베이스 인프라를 유지하여 포드 상태를 유지하고 세션 지속성을 활성화했습니다.
관찰성, 확장성 및 유연성을 위한 설계
영어: 관찰 가능성을 위해 Benoit는 클라우드 네이티브 대시보드로 Grafana를 권장했습니다. NGINX 메트릭을 얻기 위해 DevOps 팀은 각 포드와 페어링된 사이드카에서 NGINX Prometheus Exporter를 활용합니다. Exporter는 NGINX Open Source Stub Status 모듈 과 NGINX Plus API 에서 레이어 4 메트릭을 스크래핑 하고 각각을 문자열과 일치시키고 키-값 쌍을 생성한 다음 쌍을 Prometheus 로 푸시합니다 . 거기에서 쌍은 개발자와 DevOps 팀에만 노출되는 별도의 Grafana 인스턴스에 게시됩니다. Benoit는 "놀랍습니다. 모든 NGINX Open Source 및 NGINX Plus 인스턴스에서 대시보드를 빌드하고 단일 위치에서 메트릭을 수집할 수 있습니다. DevOps 팀이 제어합니다. 실행 중인 항목을 보고 문제에 대한 알림을 받을 수 있습니다."라고 말합니다.
팀은 또한 애플리케이션의 성능 관리를 위해 메트릭을 사용합니다. 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는 말합니다. "저희 개발자에게는 밤과 낮과 같습니다."
기술 스택
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기