모던 애플리케이션 개발 원칙

모던 애플리케이션 개발 원칙은 작게 유지하고 , 개발자를 위해 설계 하고, 네트워크로 연결하는 것으로 요약할 수 있습니다 . 이 세 가지 원칙을 사용하면 빠르고 안전하게 제공하고 쉽게 확장하고 간단하게 확장할 수 있는 강력하고 복잡한 애플리케이션을 설계할 수 있습니다.

소프트웨어는 점점 더 유능해지고 있으며 점점 더 복잡해지고 있습니다. Marc Andreessen의 유명한 말처럼 소프트웨어가 세상을 집어삼키고 있습니다.

그 결과 지난 몇 년 동안 애플리케이션 개발 및 제공에 대한 접근 방식이 크게 바뀌었습니다. 이러한 변화는 구조적 범위였으며 팀을 구성하고 디자인을 구현하고 최종 사용자에게 애플리케이션을 제공할 때 매우 유용한 일련의 원칙으로 이어졌습니다.

이러한 각 원칙에는 유지 관리가 쉬운 강력한 애플리케이션을 신속하게 제공하는 최종 목표에 각 원칙이 어떻게 기여하는지 보여주기 위해 논의할 고유한 측면이 있습니다.
NGINX는 “최소한의 원칙을 사용하여 디자인을 확실히 하라” 와 같은 말을 할 때 각 원칙을 반대되는 것과 대조하여 그것이 무엇을 의미하는지 명확하게 할 것입니다.

해당 포스트를 통해 모던 스택에 의해 생성된 맥락에서 엔지니어링에 대한 통합 접근 방식을 제공하는 모던 애플리케이션 구축을 위한 일련의 원칙을 채택할 수 있기를 바랍니다.

이러한 원칙을 구현하면 애플리케이션 개발 및 제공에 대한 DevOps 접근 방식, 컨테이너 (Docker 등) 및 컨테이너 Orchestration Framework (Kubernetes 등), Microservice (NGINX Microservice Reference Architecture 포함) 및 Microservice 애플리케이션을 위한 Service Mesh 아키텍처를 비롯한 소프트웨어 개발의 가장 중요한 최신 동향을 활용할 수 있습니다.

목차

1. 모던 애플리케이션 이란 무엇일까요?
2. 개발 원칙에 대해서
3. 모던 애플리케이션 개발 원칙 1: 소형화
 3-1. 개발 기간 단축
 3-2. 코드 용량 단축
 3-3. 변경 최소화
  3-3-1. 소규모 원칙
4. 모던 애플리케이션 개발 원칙 2: 개발자 중심
 4-1. 개발 환경 구축
 4-2. 아키텍처 및 코드 표준 수립
  4-2-1. Microservice 애플리케이션
 4-3. DevOps 도구
5. 모던 애플리케이션 개발 원칙 3: 네트워크
 5-1. 네트워킹 우려사항
 5-2. 복원력 향상
 5-3. 구현 용이
 5-4. 관리 용이성
6. NGINX의 모던 애플리케이션 개발 적합성
 6-1. NGINX가 무엇일까요?
 6-2. 모던 애플리케이션 개발에 NGINX가 필요한 이유
7. 결론

1. 모던 애플리케이션 이란 무엇일까요?

최신 애플리케이션, 모던 스택, “Modern” 은 정확히 무엇을 의미할까요?
대부분은 모던 애플리케이션을 구성하는 요소들에 대해 알고 있지만 토론을 위해 정의를 내릴 필요가 있습니다.

모던 애플리케이션은 클라이언트가 React JavaScript 라이브러리를 사용하는 UI든, Android 또는 IOS에서 실행되는 모바일 앱이든, API를 통해 애플리케이션에 연결하는 Downstream 애플리케이션이든 여러 클라이언트를 지원하는 것입니다.
모던 애플리케이션은 정의되지 않은 수의 클라이언트가 제공하는 데이터와 서비스를 소비할 것으로 예상합니다.

모던 애플리케이션은 해당 데이터 및 해당 서비스에 액세스하기 위한 API를 제공합니다. API는 애플리케이션에 액세스하는 다른 클라이언트에 맞춤화 되지 않고 일관성이 있습니다. API는 HTTP(S)를 통해 사용할 수 있으며 GUI 또는 CLI를 통해 사용 가능한 모든 기능에 대한 액세스를 제공합니다.

데이터는 JSON과 같은 일반적이고 사용 가능한 형식으로 제공됩니다. API는 개체와 서비스를 명확하고 체계적인 방식으로 나타냅니다. RESTful API 또는 GraphQL은 적절한 종류의 인터페이스를 제공하는데 효과적입니다.

모던 애플리케이션은 모던 스택 위에 구축되며 모던 스택은 이러한 유형의 애플리케이션을 직접 지원하는 것입니다.
스택은 개발자가 HTTP 인터페이스와 명확한 API Endpoint를 사용하여 애플리케이션을 쉽게 만들 수 있도록 지원합니다.
애플리케이션에서 JSON 데이터를 쉽게 사용하고 내보낼 수 있습니다. 이 말은 즉, Twelve‑Factor App for Microservices 의 관련 요소를 준수한다는 것입니다.

이 스택 유형의 대중적인 버전은 Java , Python , Node , Ruby , PHP 및 Go를 기반으로 합니다. NGINX 마이크로서비스 참조 아키텍처 (MRA)는 이러한 각 언어로 구현된 최신 스택의 예를 제공합니다.

Microservice 기반의 애플리케이션 접근 방식을 극단적으로 옹호하는 것은 아닙니다.
많은 사람들이 진화해야 하는 모놀리식으로 작업하고 있는 반면, 다른 사람들은 마이크로서비스 애플리케이션으로 확장되고 진화하는 SOA 애플리케이션을 가지고 있습니다.
또 다른 사람들은 서버리스 애플리케이션으로 이동하고 있으며 일부는 위의 모든 조합을 구현하고 있습니다. 이 토론에서 설명된 원칙은 약간의 조정을 통해 이러한 각 시스템에 적용될 수 있습니다.

2. 모던 애플리케이션 개발 원칙에 대해서

이제 최신 애플리케이션과 최신 스택에 대한 이해를 공유했으므로, 이제 최신 애플리케이션을 설계, 구현 및 유지 관리하는 데 도움이 되는 아키텍처 및 개발 원칙에 대해 살펴보겠습니다.


모던 애플리케이션 개발의 핵심 원칙 중 하나는 “작게 유지하라” 또는 “단순하게 유지하라”라고 요약할 수 있습니다. NGINX는 수많은 복잡한 구성 요소로 이루어진 애플리케이션을 가지고 있습니다.
작고 독립적인 구성 요소로 애플리케이션을 구축하면 전체적인 애플리케이션의 설계, 유지보수 및 관리가 더욱 쉬워집니다. (“쉬워진다”고 말하고 있는데 “쉽다”고 말하는 것은 아닙니다.)

두 번째 원칙은 개발자의 생산성을 극대화할 수 있다는 것입니다.
개발자들이 개발하는 기능에 집중하고 인프라와 CI/CD에 대한 걱정으로부터 해방될 수 있도록 도움을 주는 것입니다. 따라서 NGINX의 접근 방식은 개발자 중심입니다.

마지막으로, 애플리케이션의 모든 요소는 네트워크화되어야 합니다.
지난 20년 동안 네트워크가 더욱 빨라지고 애플리케이션이 더욱 복잡해지면서 네트워크화된 미래로 나아가고 있습니다.
앞서 논의한 대로, 모던 애플리케이션은 다양한 클라이언트를 통해 네트워크 상황에서 사용됩니다. 아키텍처 전체에 네트워크 마인드셋을 적용하는 것은 작고 개발자 중심적인 접근 방식과 잘 조화되며 상당한 이점을 제공합니다.

작게 유지하고 개발자 중심적이며 네트워크화된 원칙을 애플리케이션 설계 및 구현 시 염두에 두면 애플리케이션을 발전시키고 제공하는 데 있어서 앞서 나아갈 수 있습니다.

이러한 원칙들을 자세히 살펴보겠습니다.

3. 모던 애플리케이션 개발 원칙 1: 소형화

인간의 두뇌는 너무 많은 정보를 소화하는 데 어려움을 겪습니다.
심리학에서 인지 부하(cognitive load)는 작업 메모리에 정보를 보존하기 위해 사용되는 총 정신적 노력을 의미합니다. 개발자의 인지 부하를 줄이는 것은 유익합니다. 왜냐하면 개발자들은 특정 문제를 해결하는 동안 전체 애플리케이션의 복잡한 모델과 미래의 기능을 머릿속에 유지하는 대신 주어진 문제를 해결하기 위해 에너지를 집중할 수 있기 때문입니다.

개발자가 유지해야 하는 인지 부하를 줄이는 몇 가지 방법이 있으며, 여기에서 “소형화”라는 원칙이 작용합니다.

개발팀의 인지 부하를 줄이는 세 가지 방법은 다음과 같습니다:

  1. 새로운 기능을 구축하는 데 고려해야 하는 시간을 줄입니다. 시간이 짧을수록 인지 부하가 낮아집니다.
  2. 작업 중인 코드의 크기를 줄입니다. 코드가 적을수록 인지 부하가 낮아집니다.
  3. 애플리케이션에 점진적인 변경을 적용하는 프로세스를 단순화합니다. 프로세스가 간단할수록 인지 부하가 낮아집니다.

3-1. 개발 기간 단축

과거에 워터폴 개발이 표준 개발 프로세스였던 시절에는 애플리케이션을 개발하거나 업데이트하는 데 6개월에서 2년의 시간이 소요되는 것이 일반적이었습니다.
엔지니어들은 일반적으로 제품 요구 사항 문서(PRD), 시스템 참조 문서(SRD), 아키텍처 계획과 같은 관련 문서를 읽고, 이러한 요소들을 하나로 통합하여 인지 모델을 형성한 후 코드를 작성했습니다.
요구 사항이 변경되고 아키텍처와 구현이 변경되면 팀의 업무 업데이트와 최신 인지 모델 유지 작업은 마비 상태까지 부담이 되었습니다.

애플리케이션 개발 프로세스에서 가장 큰 변화는 애자일 개발 방법론의 채택이었습니다.
애자일 방법론의 주요 특징 중 하나는 반복적인 개발입니다. 이를 통해 엔지니어가 지닌 인지 부하가 줄어들게 되었습니다.
애플리케이션을 장기간 동안 한 번에 처리하는 것이 아니라, 작고 소형의 청크에 초점을 맞추어 빠르게 테스트하고 배포할 수 있는 애자일 접근 방식은 고객으로부터 유용한 피드백을 얻을 수 있도록 해주었습니다.
애플리케이션의 인지 부하는 큰 세부 사항을 갖춘 6개월에서 2년간의 애플리케이션 개발 시간으로부터, 모호한 개념의 큰 애플리케이션을 대상으로 한 구체적인 2주간의 기능 추가 또는 변경으로 전환되었습니다.

대규모 애플리케이션에서 2주간의 스프린트 동안 완료될 수 있는 기능으로 초점을 옮기고, 최대한 다음 스프린트의 기능을 염두에 둔 것은 중대한 변화이며, 엔지니어들이 생산적이며 변화하는 인지 부하로부터 해방되도록 허용해주었습니다.
애자일 개발에서는 애플리케이션이 초기의 구상에서 변화할 것으로 가정되므로 최종적인 구현은 필연적으로 모호합니다. 각 스프린트의 구체적인 결과물만이 완전히 명확할 수 있습니다.

3-2. 코드 용량 단축

엔지니어의 인지 부하를 줄이는 데 다음 단계는 코드베이스의 크기를 줄이는 것입니다.
모던 애플리케이션은 일반적으로 대규모입니다. 견고하고 기업급의 애플리케이션은 수천 개의 파일과 수십만 줄의 코드를 가질 수 있습니다. 코드와 파일의 상호관계와 의존성은 파일 구성에 따라 명확하거나 그렇지 않을 수 있습니다.
코드 실행을 추적하는 것은 코드 라이브러리와 디버깅 도구가 얼마나 잘 라이브러리/패키지/모듈과 사용자 정의 코드를 구분하는지에 따라 문제가 될 수 있습니다.

애플리케이션 코드의 작동하는 인지 모델을 구축하는 것은 상당한 시간이 소요되며, 다시 말해 개발자에게 상당한 인지 부하를 지우는 작업입니다.
특히 코드 베이스가 거대하고 기능적인 구성 요소 간의 상호작용이 명확하게 정의되지 않으며, 관심사의 분리가 강력하게 강제되지 않을 때는 모놀리식 코드 베이스의 경우에 특히 그렇습니다.

엔지니어의 인지 부하를 크게 줄이는 가장 효과적인 방법 중 하나는 마이크로서비스를 사용한 개발로 전환하는 것입니다.
마이크로서비스를 사용하면 각 서비스는 한 세트의 기능에 매우 집중할 수 있습니다.
서비스 도메인은 일반적으로 명확하고 이해하기 쉽습니다. 서비스 경계도 매우 명확합니다.
기억하세요, 서비스와의 통신은 API 호출을 통해서만 이루어질 수 있으며, 한 서비스의 내부 작업으로 생성된 효과는 쉽게 다른 서비스로 누출되지 않을 수 있습니다.

다른 서비스와의 상호작용은 REST와 같은 방식으로 명확하고 이해하기 쉬운 API 호출을 통하여 일부 소비자 서비스 및 일부 공급자 서비스로 제한됩니다.
이는 엔지니어의 인지 부하를 크게 줄여줍니다.
가장 큰 과제는 서비스 간의 상호작용 모델과 여러 서비스 간의 트랜잭션이 어떻게 발생하는지를 이해하는 것입니다.
전반적으로, 마이크로서비스의 사용은 총 코드 양을 줄이고, 명확하고 강화된 서비스 경계를 갖추며, 소비자와 제공자 간의 명확한 관계를 설정함으로써 인지 부하를 크게 줄입니다.

3-3. 변경 최소화

소규모 원칙의 마지막 요소는 변화를 관리하는 것입니다. 개발자들은 종종 코드베이스를 보고 (특히 자신의 오래된 코드일 경우) “이건 전체를 다시 작성해야 한다”라고 선언하는 유혹에 빠집니다.
때로는 그게 맞는 일일 수도 있지만, 때로는 그렇지 않습니다.
이는 엔지니어링 팀에 대규모 모델 변경의 부담을 지우며, 이는 다시 큰 인지 부하 문제로 이어집니다.
엔지니어들이 스프린트에서 영향을 줄 수 있는 변경에 집중하고 이를 시간을 투여하여 제공한다면, 최종 제품은 원래 구상된 변경과 유사하게 되지만 고객 요구에 맞게 테스트하고 수정하며 개발됩니다.

대규모 코드의 재작성은 때로는 다른 시스템에 대한 종속성으로 인해 기능을 제공할 수 없는 경우가 있습니다.
변경 흐름을 유지하기 위해 기능을 숨기는 것도 괜찮습니다. 기본적으로, 이는 기능을 운영 환경에 배포하지만 환경 변수나 기타 구성 메커니즘을 통해 액세스할 수 없게 만드는 것을 의미합니다.
이 코드가 운영 품질이고 모든 품질 절차를 통과했다면, 숨겨진 상태로 배포하는 것은 괜찮습니다.
그러나 이 전략은 기능이 최종적으로 활성화되어야만 작동합니다. 그렇지 않으면 코드에 불필요한 부분이 추가되어 유용한 작업을 수행하는 동안 개발자의 인지 부하를 더해줍니다.
변화를 관리하고 수정 사항을 점진적으로 유지하는 것은 개발자의 인지 부하를 합리적인 수준으로 유지하는 데 도움이 됩니다.

3-3-1. 소규모 원칙

엔지니어들은 기능을 구현하는 것만으로도 많은 복잡성을 다루어야 합니다.
엔지니어링 리드로서 불필요한 인지 부하를 제거하면 팀이 기능의 핵심 요소에 집중할 수 있습니다. 개발 팀을 돕기 위해 엔지니어링 매니저로서 할 수 있는 세 가지는 다음과 같습니다:

  1. 애자일 개발 프로세스를 사용하여 팀이 기능을 제공하기 위해 집중해야 하는 시간을 제한합니다.
  2. 애플리케이션을 일련의 마이크로서비스로 구현하여 기능의 범위를 제한하고 구현 중에 인지 부하를 줄이는 경계를 강제화합니다.
  3. 대규모 변경보다는 점진적인 변경을 촉진하며, 변경을 작고 소형화된 단위로 유지합니다.
    기능을 숨길 수 있도록 하여 변경을 구현할 수 있게 합니다. 이렇게 하면 변경이 추가된 후에 즉시 노출되지 않더라도 구현할 수 있습니다.

소규모 원칙으로 개발 프로세스에 접근한다면 팀은 더 행복해지고 필요한 기능을 구현하는 데 집중하며, 보다 빠른 고품질 코드를 제공할 가능성이 높아집니다.
이는 복잡성이 없을 수 없다는 것을 의미하는 것은 아닙니다. 실제로, 여러 서비스를 수정해야 하는 기능을 구현하는 것은 단일체(monolith)에서 수행하는 것보다 실제로 더 복잡할 수 있습니다.
그러나 소규모 원칙을 따르는 전반적인 이점은 그 가치가 있을 것입니다.

4. 모던 애플리케이션 개발 원칙 2: 개발자 중심

빠른 개발을 위한 가장 큰 병목 현상은 종종 아키텍처나 개발 프로세스가 아니라 엔지니어들이 작업하는 기능의 비즈니스 로직에 얼마나 많은 시간을 소비하는지입니다.

난해한 코드베이스, 과도한 도구/프레임워크 사용, 그리고 일반적인 사회적인 방해 요소는 모두 개발팀의 생산성을 떨어뜨리는 요소입니다. 개발 프로세스를 개발자 중심으로 만들 수 있습니다.
즉, 개발자들이 방해 요소로부터 해방되어 현재 집중해야 할 작업에 더욱 집중하기 쉽게 만들 수 있습니다.

팀에서 최상의 작업을 수행하려면 애플리케이션 에코시스템이 다음에 중점을 두는 것이 중요합니다.

  • 작업하기 쉬운 시스템 및 프로세스
  • 이해하기 쉬운 아키텍처 및 코드
  • 도구 관리를 위한 DevOps 지원

4-1. 모던 애플리케이션 개발 환경 구축

만약 개발자의 환경이 이러한 원칙을 반영한다면, 문제를 해결하고 새로운 기능을 생성하며, 기능 간에 원할하게 전환할 수 있는 생산적인 팀을 갖게 될 것입니다.

작업하기 쉬운 개발 환경의 예시:

개발자가 GitHub 저장소를 클론(Clone)합니다.
makefile에서 몇 가지 명령을 실행합니다.
테스트가 실행됩니다.
애플리케이션이 실행되고 접근할 수 있습니다.
코드 변경 사항이 실행 중인 애플리케이션에서 나타납니다.

반면, 데이터베이스, 지원 서비스, 인프라 구성 요소, 애플리케이션 엔진과 같은 시스템을 설정하는 데 상당한 노력이 필요한 개발 환경은 생산성에 큰 장애물이 됩니다.

4-2. 아키텍처 및 코드 표준 수립

시스템이 가동된 후에는 애플리케이션 코드와의 표준 인터페이스 방식을 갖는 것도 매우 중요합니다. RESTful API에는 공식적인 표준은 없지만, 일반적으로 다음과 같은 몇 가지 특징이 있어 작업하기 쉽게 만듭니다:

  • 엔드포인트는 명사로 표현됩니다. 예를 들어, 이미지에 액세스하는 엔드포인트는 /image와 같이 표현됩니다.
  • 생성, 읽기, 업데이트 및 삭제(CRUD) 작업은 HTTP 동사를 사용합니다:
    • 데이터를 검색하기 위해 GET을 사용합니다.
    • 새로운 구성 요소를 생성하기 위해 POST를 사용합니다.
    • 구성 요소를 추가하거나 업데이트하기 위해 PUT을 사용합니다.
    • 구성 요소의 하위 요소를 업데이트하기 위해 PATCH를 사용합니다.
    • 구성 요소를 삭제하기 위해 DELETE를 사용합니다.
  • API에 접근하기 위해 HTTP(S) 프로토콜을 사용합니다.
  • 데이터는 JSON 형식으로 전달됩니다.
  • OpenAPI(일반적으로 Swagger로 알려진) UI 또는 유사한 도구를 통해 API 문서, API 사용 예제 및 API 테스트 필드를 확인할 수 있습니다.

이러한 요소들은 RESTful API의 일반적인 표준 요소이며, 개발자들은 기존의 지식과 도구(브라우저, curl 등)를 활용하여 시스템을 이해하고 조작할 수 있습니다.
이와는 대조적으로, RPC 형식의 프로토콜을 사용하는 프로프라이어터리 바이너리 프로토콜을 사용하는 경우 개발자들은 새로운 도구를 필요로 할 것입니다(만약 찾을 수 있다면). API는 명사와 동사가 혼합된 형태일 수 있으며, API 호출은 다양한 옵션으로 오버로드되어 있고, 명확하지 않은 부작용을 가질 수 있으며, 반환된 데이터는 이진/인코딩/압축/암호화되거나 해독할 수 없는 형태일 수 있습니다.

물론, RESTful API의 단점 중 일부를 해결하는 GraphQL과 같은 새로운 표준이 등장하고 있습니다.
특히, 여러 개체에 대한 액세스와 쿼리 기능을 갖추고 있습니다.
하지만 애플리케이션에서 API의 명확성을 확보하기 위해 REST에 초점을 맞추는 것은 좋은 시작점입니다.

4-2-1. Microservice 애플리케이션

Microservice 애플리케이션은 일반적으로 다음과 같은 특징을 갖습니다.
구성 요소와 인프라는 컨테이너화되어 있으며(Docker 이미지 등), 서비스 간의 API는 RESTful하며 데이터는 JSON 형식으로 포맷됩니다.
적절한 기구화(instrumentation)가 이루어진 경우, 개발자가 작업하기에 상당히 쉬운 시스템입니다.

쉽게 이해할 수 있는 것은 위에서 언급한 ‘쉽게 작업할 수 있는’ 개념과 밀접한 관련이 있습니다.
그러나 쉽게 이해할 수 있는 것이 정확히 무엇을 의미하는지는 어떤 면에서 코드가 이해하기 어려울 수 있는 다양한 방법이 있습니다.
알고리즘은 복잡할 수 있고, 구성 요소 간의 상호작용은 난해할 수 있으며, 논리적인 모델은 다차원적일 수 있습니다.
이 모든 것들은 본질적으로 코드의 복잡한 측면이며, 거의 항상 개발자들이 집중해야 할 복잡성입니다.

코드와 아키텍처를 이해하기 쉽게 만드는 핵심은 관심사의 명확한 분리와 관련이 있습니다.
사용자 관리 서비스는 사용자 정보 관리에 집중해야 합니다. 청구 관리 서비스는 청구에 초점을 맞춰야 합니다.
청구 관리 서비스가 작업을 수행하기 위해 사용자 정보가 필요한 경우라도 사용자 관리 서비스가 코드에 묶여 있어서는 안 됩니다.
관심사의 명확한 분리는 코드와 아키텍처를 명확하게 만드는 데 중요합니다.

4-3. DevOps 도구

앱을 이해하기 쉽고 작업하기 쉽게 만드는 것을 넘어, 엔지니어링팀의 생산성을 향상시키는 한 가지 방법은 개발자들이 자체 인프라에 소요하는 시간을 줄이는 것입니다.
처음부터 쉽게 작업할 수 있는 환경을 갖추지 않은 개발자들은 반드시 시간을 투자하여 환경을 자신에게 맞게 쉽게 작업할 수 있는 상태로 만들어야 합니다.
엔지니어들이 시스템을 가동하고 유지하기 위한 책임, 스크립트 유지, Makefile 작성, CI/CD 파이프라인 유지 등으로 인해 미로처럼 복잡한 작업에 시간을 낭비하는 것은 DevOps의 역할이어야 할 영역에서 엔지니어들이 길을 잃게 만드는 효과적인 방법입니다.

보다 바람직한 대안으로 DevOps를 엔지니어링 팀에 포함시키는 것은 개발 인프라의 보다 복잡한 측면을 관리하는 데 전담하는 개인 또는 그룹이 있음을 의미합니다.
특히 마이크로서비스 애플리케이션과 같은 복잡한 시스템으로 작업할 때 개발 환경 인프라 관리에 집중하는 사람을 두는 것이 중요합니다. DevOps는 다양한 요구 사항을 보장하는 데 집중할 수 있습니다.

  • makefile은 모든 구성 요소를 설치합니다.
  • 모든 서비스가 제대로 구축됨
  • 오케스트레이션 파일은 올바른 순서로 컨테이너를 로드합니다.
  • 데이터 저장소가 초기화됨
  • 최신 구성 요소가 설치되어 있습니다.
  • 안전한 관행을 따르고 있습니다.
  • 배포 전에 코드 테스트
  • 프로덕션을 위해 코드가 빌드되고 패키징됩니다.
  • 개발 환경은 프로덕션을 최대한 미러링합니다.

인프라 관리를 엔지니어에서 DevOps로 전환하면 엔지니어가 yak shaving 이 아닌 기능 개발 및 버그 수정에 계속 집중할 수 있습니다 .l

5. 모던 애플리케이션 개발 원칙 3: 네트워크

애플리케이션 디자인은 시간이 지남에 따라 변화해왔습니다. 이전에는 애플리케이션이 해당 시스템에서 사용되고 실행되었습니다. 메인프레임/미니컴퓨터 애플리케이션, 데스크톱 애플리케이션, 심지어 유닉스 CLI 애플리케이션은 로컬 컨텍스트에서 실행되었습니다. 네트워크 인터페이스를 통해 이러한 시스템에 연결하는 것은 점차적으로 기능으로 추가되었지만, 종종 필수적인 악으로 간주되며 일반적으로 “느린” 것으로 여겨졌습니다.

그러나 애플리케이션이 점점 커짐에 따라 개발과 전달도 점점 분산화되고 있습니다.
모든 종류의 네트워크의 속도와 신뢰성이 증가함에 따라 애플리케이션은 점점 더 네트워크화되어 왔습니다.
먼저 단일 서버에서 3계층 아키텍처로 전환하고, 서비스 지향 아키텍처(SOA)로 이동하였으며, 현재는 마이크로서비스로 진화하고 있습니다.
그러나 애플리케이션을 네트워킹하는 것이 “속도를 늦추는” 문제에 대한 우려는 여전히 남아 있습니다.

네트워크는 로컬 컨텍스트에서의 통신보다는 느릴지라도 (하지만 예전만큼은 아닙니다), 애플리케이션은 점점 더 네트워크화되고 있습니다.
이는 애플리케이션 아키텍처를 네트워킹함으로써 견고성이 향상되고 배포와 관리가 더욱 쉬워지기 때문입니다.

애플리케이션 아키텍처를 네트워킹하는 것과 관련된 우려 사항에 대해 알아보기 전에, 네트워킹의 이점에 대해 언급하는 것이 가치가 있습니다.

네트워킹에 대한 가장 큰 우려 중 하나는 속도에 관한 것입니다. 네트워크를 통해 컴포넌트에 접근하는 것은 여전히 메모리 내에서 동일한 컴포넌트에 접근하는 것보다 한 차원 느립니다. 그러나 현대의 데이터 센터는 가상 머신간에 고속 네트워킹을 제공하며, 이전 세대의 네트워킹보다 훨씬 빠릅니다. Google과 같은 회사들은 네트워킹 요청의 지연 시간을 메모리 내 요청과 비슷하게 만들기 위해 노력하고 있습니다.

5-1. 네트워킹 우려사항

과거에는 매우 느렸던 타사 서비스에 대한 액세스도 현재는 훨씬 더 빨라졌습니다. 피어링 연결은 1 Gbps보다 훨씬 더 빠릅니다.
가장 인기 있는 타사 서비스는 전 세계의 POP(접속점)에 호스팅되어 있으므로 서비스까지의 네트워크 호핑은 일반적으로 몇 개의 단계로 이루어집니다.
또한, AWS와 같은 공용 클라우드에 애플리케이션을 호스팅하면 다른 많은 서비스가 애플리케이션과 동일한 데이터 센터에서 실행되는 이점을 얻을 수 있습니다.
속도는 이전과 같은 문제가 아니며, 쿼리 최적화와 다중 레벨 캐싱과 같은 기술을 사용하여 크게 최적화할 수 있습니다.

네트워킹에 대한 다른 우려 중 하나는 네트워크 프로토콜이 불투명하다는 것입니다.
과거에 널리 사용되던 네트워크 프로토콜은 종종 독점적이거나 애플리케이션에 특화되어 있어 디버깅과 최적화가 어려웠습니다.
그러나 HTTP의 보편성과 최신 버전에서 추가된 강력하고 접근성 높은 기능 덕분에 HTTP 네트워킹은 브라우저를 가진 누구나 또는 curl 명령을 실행할 수 있는 사람에게 여전히 접근 가능한 기능입니다.
엔지니어들은 연결, 데이터 전송, 헤더 수정, 데이터 라우팅, HTTP 연결의 로드 밸런싱 방법을 알고 있습니다. HTTP의 광범위한 배포로 인해 네트워킹은 일반 사용자에게 접근 가능해졌습니다. SSL/TLS와 압축을 통해 보안이 유지되고 이진 효율적인 프로토콜을 사용할 수 있으며 (개발자 중심의 아키텍처를 구축하는 데 도움이 됨), 사용하기 쉽습니다.

이제 속도와 불투명성에 대한 주요 우려사항을 다루었으니, 애플리케이션의 탄력성이 향상되며, 배포 및 관리가 더욱 용이해지는 네트워크 아키텍처의 장점을 살펴보겠습니다.

5-2. 복원력 향상

네트워킹을 아키텍처에 깊게 통합함으로써, 특히 Twelve-Factor App for Microservices에서 설명한 원칙을 사용하여 설계하는 경우, 애플리케이션을 더욱 탄력적으로 만들 수 있습니다.
애플리케이션 구성 요소에 Twelve-Factor 원칙을 구현함으로써, 가로로 쉽게 확장할 수 있는 애플리케이션을 얻을 수 있으며, 요청 부하를 분산할 수 있습니다.

즉, 애플리케이션 구성 요소의 여러 인스턴스를 동시에 실행할 수 있으며, 그 중 하나의 장애가 전체 애플리케이션의 중단을 야기할까 두려워하지 않아도 됩니다. NGINX와 같은 로드 밸런서를 사용하여 서비스를 모니터링하고, 요청이 정상적으로 처리되는 인스턴스로 전달할 수 있습니다. 실제로 부하가 걸리는 시스템 병목 지점을 기반으로 애플리케이션을 쉽게 확장할 수 있습니다. 모노리틱 애플리케이션의 경우와 달리 모든 애플리케이션 구성 요소를 동시에 확장할 필요가 없습니다.

5-3. 구현 용이

애플리케이션을 네트워킹하면 배포가 더 간단해집니다. 단일 서비스의 테스트 절차는 모놀리식 애플리케이션에 필요한 전체 회귀 테스트 과정보다 훨씬 작거나 간단합니다.
서비스 테스트는 모노리스에 필요한 전체 회귀 테스트 과정보다는 유닛 또는 기능 테스트와 더 유사합니다.
마이크로서비스를 채택하는 경우, 애플리케이션 코드는 신뢰할 수 있는 DevOps팀에 의해 한 번 빌드되고 수정 없이 CI/CD 파이프라인을 통해 전달되며 빌드된 상태로 프로덕션 환경에서 실행됩니다.

5-4 관리 용이성

애플리케이션을 네트워킹하면 관리가 더욱 쉬워집니다.
단일한 모놀리식 애플리케이션과 비교하여 네트워크로 연결된 마이크로서비스 중심의 애플리케이션은 관리하기 쉽습니다. 구성 요소는 이제 개별적이며 더 쉽게 모니터링할 수 있습니다.
구성 요소 간의 상호 통신은 HTTP를 통해 이루어지므로 모니터링, 활용, 테스트하기가 쉽습니다.
네트워크로 연결된 애플리케이션은 모놀리식 애플리케이션에 비해 많은 이점을 제공하며, 모던 애플리케이션 환경에서 네트워크 애플리케이션에 대한 우려 중 일부는 근거가 없는 것으로 판명되었습니다.
적절한 설계로 네트워크 애플리케이션은 시작부터 높은 가용성을 제공하여 더욱 견고합니다.
네트워크 애플리케이션은 배포하기 쉽습니다. 일반적으로 단일 구성 요소만 배포하면 되므로 단일 서비스를 배포할 때 전체 회귀 과정을 거치지 않아도 됩니다. 마지막으로, 네트워크 애플리케이션은 관리하기 쉽습니다.
애플리케이션을 더 많은 트래픽을 처리할 수 있도록 확장하는 것은 일반적으로 전체 애플리케이션을 확장하는 것보다 개별 서비스를 확장하는 과정이 됩니다.
또한 현대의 데이터 센터 하드웨어, 네트워크 최적화 및 서비스 피어링을 고려하면 성능과 관련된 우려는 크게 줄어들거나 완전히 사라집니다.

6. NGINX의 모던 애플리케이션 개발 적합성

모던 애플리케이션 개발을 용이하게 하는 여러 도구들이 있습니다.
하나는 컨테이너인데, 도커(Docker) 컨테이너의 배포는 많은 애플리케이션 개발 및 배포에서 표준적인 방법이 되었습니다.
또 다른 도구는 클라우드와 클라우드 서비스인데, 아마존 웹 서비스(Amazon Web Services, AWS), 구글 클라우드 플랫폼, 마이크로소프트 애저(Microsoft Azure)와 같은 공개 클라우드 제공업체들이 인기를 얻고 있습니다.

NGINX도 이러한 도구 중 하나로, 개발과 배포 모두에서 사용됩니다. NGINX, 도커, 공개 클라우드는 함께 성장해왔으며, 예를 들어 NGINX는 Docker Hub에서 가장 인기 있는 다운로드로, AWS의 배포의 40% 이상을 NGINX 소프트웨어가 담당하고 있습니다. AWS는 AWS 네트워크 로드 밸런서(Network Load Balancer, NLB)와 NGINX를 결합한 인기있는 로드 밸런싱 구현을 직접 지원합니다.

하지만 NGINX가 어떻게 이렇게 인기를 얻게 되었으며, 이것이 모던 애플리케이션 개발의 핵심 원칙과 어떻게 부합하는지 알아볼까요? 저희는 최선을 다해 이야기하겠지만, NGINX 사용자는 각자의 도입 이유를 가지고 있습니다.

6-1. NGINX가 무엇일까요?

NGINX 오픈 소스는 2003년에 처음으로 출시되었으며, 상용 버전인 NGINX Plus는 2013년에 처음으로 출시되었습니다. NGINX 소프트웨어의 사용은 계속해서 증가하였고, 현재 NGINX는 가장 인기 있는 웹사이트 중 대다수에서 사용되고 있으며, 이 중에서도 트래픽이 가장 많은 10,000개 사이트 중 약 1/3가 NGINX를 사용하고 있습니다.

이러한 성장 기간은 모던 애플리케이션 개발의 출현과 소규모, 개발자 중심, 네트워크 등의 원칙과 거의 정확히 일치합니다. NGINX는 왜 이 기간 동안 이렇게 빠르게 성장했을까요?

이 경우 상관 관계는 인과 관계가 아닙니다. 적어도 완전히는 아닙니다.
대신에, 모던 애플리케이션 개발의 성장과 NGINX의 사용 증가의 근본적인 이유는 동일합니다.
그것은 인터넷의 믿을 수 없을 정도로 빠른 성장입니다. 현재 미국 소매업의 약 10%는 현재 온라인으로 이루어지며, 온라인 광고는 대부분의 구매에 영향을 미칩니다.
지난 수십 년 동안의 대부분의 성공 사례는 인터넷을 통해 가능해졌으며, Facebook, Apple, Netflix, Google(지금은 알파벳 주식회사(Alphabet)의 핵심)과 같은 세계에서 가장 가치 있는 회사들의 등장을 포함합니다. 아마존과 최근에 급격히 성장한 마이크로소프트는 추가적인 인터넷 기반의 성공 사례입니다.

6-2. 모던 애플리케이션 개발에 NGINX가 필요한 이유

NGINX는 인터넷의 성장으로부터 혜택을 받는 이유는 매우 빠른 사용자 응답 시간을 제공하는 활발하고 빠르게 성장하는 사이트를 구동하는 데에 굉장히 유용하기 때문입니다. 두 가지 사용 사례가 있습니다. 첫 번째는 NGINX가 아파치(Apache) 또는 마이크로소프트 인터넷 정보 서버(IIS) 웹 서버를 대체하여 훨씬 더 우수한 성능, 용량 및 안정성을 제공하는 경우입니다.

두 번째 사용 사례에서는 NGINX가 기존 웹 서버(아파치, 인터넷 정보 서버, NGINX 자체 또는 거의 모든 것) 앞에 리버스 프록시 서버로 배치됩니다. 이렇게 하면 리버스 프록시 서버가 인터넷 트래픽을 처리하고 대부분의 웹 서버보다 더 능숙하게 처리하며, 웹 서버는 애플리케이션 서버 및 East-West 정보 전송 업무만 처리하면 됩니다. NGINX는 리버스 프록시 서버로서 트래픽 관리, 로드 밸런싱, 캐싱, 보안 등의 기능을 제공하여 애플리케이션 및 기타 내부 서버에 추가적인 부하를 덜어주게 됩니다. 이로써 전체 인프라가 더욱 원활하게 작동하게 됩니다.

두 사용 사례 모두 소규모 웹사이트보다는 트래픽이 많은, 대형 웹사이트에서 더욱 매력적입니다. 이것이 바로 Netflix와 같이 트래픽이 많은 사이트들이 NGINX를 더 많이 사용하는 이유이며, 대부분의 세계적인 대형 웹사이트가 NGINX를 실행하는 이유입니다.

6-3. 추가적인 NGINX 사용 사례

추가로 NGINX의 사용 사례를 보완하자면 공개적으로 이용 가능한 콘텐츠 배포 네트워크 (CDN)의 핵심으로 NGINX를 사용하는 것과, 대형 웹사이트의 사적인 사용을 위해 구축된 내부 CDN을 포함합니다.
이러한 대부분 NGINX 기반의 CDN은 인터넷 전체의 성능, 용량 및 안정성에 큰 기여를 하였습니다.

웹 서버, 리버스 프록시 서버 및 많은 CDN의 핵심인 NGINX의 이러한 사용은 인터넷의 성장에 헤아릴 수 없이 기여했습니다. NGINX 덕분에 사람들이 매일 사용하는 인터넷은 더욱 빠르고 안정적이며 신뢰성이 높고 보안이 강화되었습니다.

하지만 NGINX는 애플리케이션 개발의 핵심 원칙을 지원하기 때문에 직접적으로 성장한 부분도 있습니다.

  • 가벼움: NGINX는 매우 가볍기 때문에 작고 집중된 서비스와 잘 작동합니다. 또한 매우 빠르기 때문에 무거운 부하에도 거의 느려지지 않습니다. 이는 작은 애플리케이션 서비스, API Gateway, 그리고 물론 마이크로서비스의 배포를 장려합니다. NGINX는 다양한 마이크로서비스 네트워크 아키텍처, Kubernetes의 Ingress Controller로 사용되며, 자체 Fabric Model 및 Service Mesh 모델에서 사이드카 프록시로 사용됩니다.
  • 개발자 중심: 이것은 NGINX 성장의 큰 이유 중 하나입니다. NGINX를 사용하면 개발자는 애플리케이션 개발 및 배포 과정 전반에서 로드 밸런싱을 직접 관리할 수 있습니다. 이는 온프레미스, 클라우드 또는 둘 다에 있는 앱의 경우에도 적용됩니다. ADC(Application Delivery Controller)라고도 하는 하드웨어 로드 밸런서인 경우 네트워크 담당자가 변경 사항을 구현하기 전에 상세하고 시간 소모적인 절차를 따라야 합니다. NGINX를 사용하면 개발자는 즉시 변경 사항을 적용하여 유연성을 확보하고 제어를 유지할 수 있습니다.
  • 네트워크 연결: 애플리케이션들이 더 많은 서비스 간 트래픽을 네트워크 상으로 전송하게 되면서 NGINX가 서비스 연결에 대한 제어력을 가지는 방식은 개발자들 사이에서 매우 인기가 있습니다. NGINX는 HTTP에 대한 매우 높은 수준의 제어를 항상 허용하였으며, 최근에는 SPDY(HTPP/2의 이전 버전)와 HTTP/2를 지원하는 데 주력하였습니다. 또한 TCP와 UDP 지원도 추가되었습니다.

이 모든 기능을 제공하는 동시에 작은 메모리 공간, 빠른 성능, 보안 및 안정성을 유지하면서 다양한 적용 사례에서 NGINX의 사용은 인터넷의 성장에 매우 큰 영향을 미치며 모던 애플리케이션 개발의 등장을 강력하게 지원하는 힘이 되었습니다.

7. 결론


모던 애플리케이션을 구축하는 원칙은 꽤 간단합니다.
이를 요약하면 작게 유지하고, 개발자를 위해 설계하며, 네트워크 기반으로 만드는 것입니다. 이 세 가지 원칙을 따르면 견고하고 복잡한 애플리케이션을 빠르게 제공하고, 쉽게 확장하고, 효과적으로 보안하며, 간편하게 확장할 수 있습니다. NGINX 소프트웨어는 이러한 원칙을 구현하기 위해 널리 사용되는 도구입니다.

NGINX 및 NGINX Plus를 시작하려면 NGINX STORE에 문의 해보세요.