NGINX에서 최신 애플리케이션을 개발하기 위한 원칙. 1 부

안녕하세요 친구. 코스 개강을 앞두고 PHP 백엔드 개발자, 전통적으로 유용한 자료의 번역을 귀하와 공유합니다.

소프트웨어는 점점 더 복잡해지는 동시에 점점 더 많은 일상 업무를 해결합니다. Marc Andressen이 말했듯이 그것은 세상을 소비합니다.

그 결과 지난 몇 년 동안 애플리케이션을 개발하고 제공하는 방식이 크게 바뀌었습니다. 이것은 일련의 원칙을 낳은 구조적 규모의 변화였습니다. 이러한 원칙은 팀 구축, 설계, 개발 및 최종 사용자에게 응용 프로그램 제공에 도움이 되는 것으로 입증되었습니다.

원칙은 다음과 같이 요약할 수 있습니다. 응용 프로그램은 작고 웹 기반이어야 하며 개발자 중심 아키텍처를 가져야 합니다.. 이 세 가지 원칙을 염두에 두고 최종 사용자에게 빠르고 안전하게 제공할 수 있고 쉽게 확장할 수 있는 강력한 엔드 투 엔드 애플리케이션을 만들 수 있습니다.

제안된 각 원칙에는 각 원칙이 유지 관리 및 사용이 쉽고 신뢰할 수 있는 응용 프로그램의 신속한 제공이라는 궁극적인 목표에 어떻게 기여하는지 보여주기 위해 논의할 여러 측면이 있습니다. 우리는 그것이 의미하는 바를 명확히 하기 위해 그 반대와 관련하여 원칙을 살펴볼 것입니다. 작음 원리".

이 기사가 계속 성장하는 기술 스택의 맥락에서 디자인에 대한 통합된 접근 방식을 제공할 최신 애플리케이션 구축을 위해 제안된 원칙을 사용하도록 권장하기를 바랍니다.

이러한 원칙을 적용하면 소프트웨어 개발의 최신 동향을 활용하는 자신을 발견하게 될 것입니다. 개발자 애플리케이션 개발 및 제공, 컨테이너 사용(예: 도커) 및 컨테이너 오케스트레이션 프레임워크(예: Kubernetes), 마이크로서비스 사용(마이크로서비스 아키텍처 포함) NGINX и 네트워크 통신 아키텍처 마이크로서비스 애플리케이션용.

최신 애플리케이션이란 무엇입니까?

최신 애플리케이션? 모던 스택? "현대"란 정확히 무엇을 의미합니까?

대부분의 개발자는 최신 애플리케이션이 무엇으로 구성되어 있는지에 대한 일반적인 아이디어만 가지고 있으므로 이 개념을 명확하게 정의할 필요가 있습니다.

최신 앱은 React JavaScript 라이브러리 사용자 인터페이스, Android 또는 iOS 모바일 앱, 다른 API에 연결하는 앱 등 여러 클라이언트를 지원합니다. 최신 애플리케이션은 데이터 또는 서비스를 제공하는 클라이언트의 무한한 수를 의미합니다.

최신 애플리케이션은 요청된 데이터 및 서비스에 액세스하기 위한 API를 제공합니다. API는 변경 불가능하고 일정해야 하며 특정 클라이언트의 특정 요청에 대해 특별히 작성되지 않아야 합니다. API는 HTTP(S)를 통해 사용할 수 있으며 GUI 또는 CLI에서 사용할 수 있는 모든 기능에 대한 액세스를 제공합니다.

데이터는 JSON과 같이 일반적으로 허용되고 상호 운용 가능한 형식으로 제공되어야 합니다. API는 RESTful API 또는 GraphQL과 같이 깨끗하고 체계적인 방식으로 개체와 서비스를 노출하여 적절한 인터페이스를 제공합니다.

모던 애플리케이션은 모던 스택 위에 구축되며, 모던 스택은 각각 그런 애플리케이션을 지원하는 스택이다. 이 스택을 통해 개발자는 HTTP 인터페이스 및 명확한 API 엔드포인트를 사용하여 애플리케이션을 쉽게 생성할 수 있습니다. 선택한 접근 방식을 사용하면 애플리케이션에서 JSON 형식의 데이터를 쉽게 받고 보낼 수 있습니다. 즉, 모던 스택은 Twelve-Factor Application의 요소에 해당합니다. 마이크로서비스.

이 스택 유형의 인기 있는 버전은 다음을 기반으로 합니다. 자바, Python, 노드, 루비, PHP и Go. 마이크로서비스 아키텍처 NGINX 언급된 각 언어로 구현된 최신 스택의 예를 나타냅니다.

Microsoft는 독점적인 마이크로서비스 접근 방식을 옹호하지 않습니다. 많은 사람들이 진화해야 하는 모놀리식으로 작업하고 있는 반면, 다른 사람들은 마이크로서비스 애플리케이션으로 확장되고 진화하는 SOA 애플리케이션을 다루고 있습니다. 여전히 다른 사람들은 서버리스 애플리케이션으로 이동하고 있으며 일부는 위의 조합을 구현하고 있습니다. 이 문서에 설명된 원칙은 약간의 수정만 거치면 이러한 각 시스템에 적용됩니다.

원칙

최신 애플리케이션과 최신 스택이 무엇인지 공통적으로 이해했으므로 이제 최신 애플리케이션을 개발, 구현 및 유지 관리하는 데 도움이 되는 아키텍처 및 개발 원칙에 대해 자세히 알아볼 차례입니다.

원칙 중 하나는 "작은 응용 프로그램 만들기"처럼 들립니다. 작음 원칙. 많은 움직이는 부분으로 구성된 매우 복잡한 응용 프로그램이 있습니다. 결과적으로 작고 개별적인 구성 요소에서 응용 프로그램을 구축하면 전체적으로 설계, 유지 관리 및 작업하기가 더 쉬워집니다. (우리는 "단순화"가 아니라 "단순화"라고 말했습니다).

두 번째 원칙은 개발자가 구현하는 동안 인프라 및 CI/CD 문제에서 벗어나 개발 중인 기능에 집중할 수 있도록 지원하여 개발자 생산성을 높일 수 있다는 것입니다. 따라서 간단히 말해서 우리의 접근 방식은 개발자 중심.

마지막으로 애플리케이션에 대한 모든 것이 네트워크에 연결되어야 합니다. 지난 20년 동안 우리는 네트워크가 더 빨라지고 응용 프로그램이 더 복잡해짐에 따라 네트워크화된 미래를 향해 큰 진전을 이루었습니다. 지금까지 살펴본 바와 같이 최신 애플리케이션은 다양한 클라이언트가 네트워크를 통해 사용해야 합니다. 아키텍처에 네트워크 사고를 적용하면 다음과 잘 어울리는 상당한 이점이 있습니다. 작음 원칙 접근 방식의 개념, 개발자 중심.

응용 프로그램을 설계하고 구현할 때 이러한 원칙을 염두에 둔다면 제품 개발 및 제공에서 부인할 수 없는 이점을 갖게 될 것입니다.

이 세 가지 원칙을 자세히 살펴보겠습니다.

작음 원리

인간의 뇌는 동시에 많은 양의 정보를 인식하기 어렵습니다. 심리학에서 인지 부하라는 용어는 기억에 정보를 유지하는 데 필요한 정신적 노력의 총량을 의미합니다. 전체 애플리케이션의 현재 복잡한 모델과 개발 중인 기능을 머릿속에 유지하는 대신 문제 해결에 집중할 수 있기 때문에 개발자의 인지 부하를 줄이는 것이 우선 순위입니다.

애플리케이션은 다음과 같은 이유로 분해됩니다.

• 개발자의 인지 부하 감소
• 테스트 가속화 및 단순화
• 응용 프로그램의 변경 사항을 빠르게 전달합니다.

개발자의 인지 부하를 줄이는 방법에는 여러 가지가 있으며 여기에서 소형화 원칙이 적용됩니다.

따라서 인지 부하를 줄이는 세 가지 방법이 있습니다.

1. 새로운 기능을 개발할 때 고려해야 하는 시간 프레임을 줄입니다. 시간 프레임이 짧을수록 인지 부하가 ​​낮아집니다.
2. 일회성 작업이 수행되는 코드의 양을 줄입니다. 코드가 적고 부하가 적습니다.
3. 애플리케이션을 점진적으로 변경하는 프로세스를 간소화합니다.

개발 기간 단축

방법론이 사용되던 시절로 돌아가 봅시다. waterfall 개발 프로세스의 표준이었고 애플리케이션 개발 또는 업데이트에 XNUMX개월에서 XNUMX년의 시간 프레임이 일반적이었습니다. 일반적으로 엔지니어는 먼저 제품 요구 사항(PRD), 시스템 참조 문서(SRD), 아키텍처 청사진과 같은 관련 문서를 읽고 이러한 모든 것을 하나의 인지 모델로 결합하기 시작합니다. 요구 사항과 결과적으로 아키텍처가 변경됨에 따라 인지 모델 업데이트에 대해 전체 팀에 알리기 위해 진지한 노력을 기울여야 했습니다. 이러한 접근 방식은 최악의 경우 단순히 작업을 마비시킬 수 있습니다.

애플리케이션 개발 프로세스의 가장 큰 변화는 애자일 방법론의 도입이었다. 방법론의 주요 기능 중 하나 agile 반복 개발이다. 이는 결국 엔지니어의 인지 부하 감소로 이어집니다. 개발팀이 하나의 긴 주기로 애플리케이션을 구현하도록 요구하는 대신, agile 접근 방식을 사용하면 빠르게 테스트하고 배포할 수 있는 소량의 코드에 집중하면서 피드백도 받을 수 있습니다. 대형 앱에 대한 보다 모호한 이해를 목표로 하는 XNUMX주 추가 또는 기능 변경에 대한 엄청난 양의 사양으로 앱의 인지 부하는 XNUMX개월에서 XNUMX년 기간으로 이동했습니다.

대규모 애플리케이션에서 XNUMX주 스프린트 내에 완료할 수 있는 특정 소형 기능으로 초점을 이동하고 다음 스프린트 전에 하나의 기능만 염두에 두는 것은 중요한 변화입니다. 이를 통해 지속적으로 변동하는 인지 부하를 줄이면서 개발 생산성을 높일 수 있었습니다.

방법론에서 agile 최종 응용 프로그램은 원래 개념을 약간 수정한 버전이 될 것으로 예상되므로 개발의 끝점이 모호할 수밖에 없습니다. 각 특정 스프린트의 결과만 명확하고 정확할 수 있습니다.

작은 코드베이스

인지 부하를 줄이는 다음 단계는 코드베이스를 줄이는 것입니다. 일반적으로 최신 애플리케이션은 방대합니다. 강력한 엔터프라이즈 애플리케이션은 수천 개의 파일과 수십만 줄의 코드로 구성될 수 있습니다. 파일이 구성되는 방식에 따라 코드와 파일 간의 링크와 종속성이 명확할 수도 있고 그 반대일 수도 있습니다. 디버깅 코드 실행 자체도 문제가 될 수 있습니다. 사용되는 라이브러리와 디버깅 도구가 라이브러리/패키지/모듈과 사용자 지정 코드를 얼마나 잘 구별하는지에 따라 달라집니다.

애플리케이션 코드의 작업 정신 모델을 구축하는 데는 상당한 시간이 소요될 수 있으며 다시 한 번 개발자에게 큰 인지적 부담을 줍니다. 이것은 많은 양의 코드가 있고 기능적 구성 요소 간의 상호 작용이 명확하게 정의되지 않고 기능적 경계가 존중되지 않기 때문에 주의 객체의 분리가 종종 모호한 모놀리식 코드 베이스의 경우에 특히 그렇습니다.

엔지니어의 인지 부하를 줄이는 효과적인 방법 중 하나는 마이크로서비스 아키텍처로 이동하는 것입니다. 마이크로서비스 접근 방식에서 각 서비스는 하나의 기능 세트에 중점을 둡니다. 서비스의 의미는 일반적으로 정의되고 이해할 수 있습니다. 서비스의 경계도 명확합니다. 서비스와의 통신은 API를 통해 이루어지므로 한 서비스에서 생성된 데이터를 다른 서비스로 쉽게 전달할 수 있습니다.

다른 서비스와의 상호 작용은 일반적으로 REST 사용과 같이 간단하고 깨끗한 API 호출을 사용하는 소수의 사용자 서비스 및 소수의 공급자 서비스로 제한됩니다. 이는 엔지니어의 인지 부하가 ​​크게 줄어드는 것을 의미합니다. 가장 큰 과제는 서비스 상호 작용 모델과 여러 서비스에서 트랜잭션과 같은 일이 발생하는 방식을 이해하는 것입니다. 결과적으로 마이크로서비스의 사용은 코드의 양을 줄이고 명확한 서비스 경계를 ​​정의하며 사용자와 공급자 간의 관계에 대한 이해를 제공하여 인지 부하를 줄입니다.

작은 증분 변경

원칙의 마지막 요소 소 변화관리이다. 개발자가 코드 베이스(어쩌면 자신의 오래된 코드일 수도 있음)를 보고 "이건 쓰레기야. 전부 다시 작성해야 해."라고 말하는 것은 특히 유혹적입니다. 때로는 이것이 올바른 결정이고 때로는 그렇지 않습니다. 이는 개발 팀에 글로벌 모델 변경의 부담을 주며, 이는 막대한 인지 부하로 이어집니다. 엔지니어는 스프린트 중에 수행할 수 있는 변경 사항에 집중하여 점진적이기는 하지만 필요한 기능을 시기 적절하게 롤아웃할 수 있습니다. 최종 제품은 사전 계획된 제품과 유사해야 하지만 고객의 요구에 맞게 약간의 수정 및 테스트가 필요합니다.

코드의 많은 부분을 재작성할 때 다른 시스템 종속성이 작용하기 때문에 변경 사항을 신속하게 전달할 수 없는 경우가 있습니다. 변경 흐름을 제어하기 위해 기능 숨기기를 사용할 수 있습니다. 원칙적으로 이것은 기능이 프로덕션에 있지만 환경 변수 설정(env-var) 또는 일부 다른 구성 메커니즘을 사용하여 사용할 수 없음을 의미합니다. 코드가 모든 품질 관리 프로세스를 통과하면 잠재적인 상태로 생산에 들어갈 수 있습니다. 그러나 이 전략은 기능이 최종적으로 활성화된 경우에만 작동합니다. 그렇지 않으면 코드를 복잡하게 만들고 개발자가 생산성을 유지하기 위해 처리해야 하는 인지 부하를 추가할 뿐입니다. 변경 관리 및 증분 변경 자체는 개발자의 인지 부하를 저렴한 수준으로 유지하는 데 도움이 됩니다.

엔지니어는 간단한 추가 기능 도입에도 많은 어려움을 극복해야 합니다. 경영진의 입장에서는 핵심 기능 요소에 집중할 수 있도록 팀의 불필요한 부담을 줄이는 것이 현명할 것입니다. 개발 팀을 돕기 위해 할 수 있는 세 가지가 있습니다.

1. 방법론 사용 agile팀이 주요 기능에 집중해야 하는 시간 프레임을 제한합니다.
2. 애플리케이션을 여러 마이크로서비스로 구현합니다. 이것은 구현할 수 있는 기능의 수를 제한하고 인지 부하를 계속 작동시키는 경계를 강화합니다.
3. 크고 다루기 힘든 것보다 점진적인 변경을 선호하고 작은 코드 조각을 변경하십시오. 기능 숨기기를 사용하여 변경 사항이 추가된 직후에 표시되지 않더라도 변경 사항을 구현하십시오.

작음의 원칙을 작업에 적용하면 팀이 훨씬 더 행복해지고 필요한 기능을 구현하는 데 더 집중할 수 있으며 질적 변화를 더 빨리 출시할 가능성이 높아집니다. 그러나 이것은 작업이 더 복잡해질 수 없다는 것을 의미하지는 않으며 때로는 반대로 새로운 기능을 도입하려면 여러 서비스를 수정해야 하며 이 프로세스는 모놀리식 아키텍처에서 유사한 것보다 더 어려울 수 있습니다. 어쨌든 소규모 접근 방식의 이점은 그만한 가치가 있습니다.

첫 번째 부분의 끝.

곧 번역의 두 번째 부분을 게시할 예정이며 이제 귀하의 의견을 기다리고 있습니다. 오픈 데이, 오늘 20.00에 진행됩니다.

출처 : habr.com