소프트웨어 확장성이란 무엇이며 회사에서 이를 심각하게 받아들여야 하는 이유는 무엇입니까?

경험이 풍부하고 성공적인 회사라도 확장성 문제에 직면할 수 있습니다. 디즈니의 Applause 앱을 기억하시나요? 이를 통해 사용자는 다양한 디즈니 쇼와 상호 작용할 수 있습니다. 앱이 Google Play에 등장했을 때 엄청난 인기를 끌었습니다. 하지만 그렇게 확장 가능하지는 않습니다. 많은 수의 팬을 처리할 수 없어 사용자 경험이 좋지 않았습니다. 사람들은 분노했고 Google Play에 부정적인 피드백과 별점 1개를 남겼습니다. 이 부정적인 홍보에서 앱은 결코 회복되지 않았습니다.

직접 구현하든 소프트웨어 엔지니어링 서비스를 사용하든 개발 초기 단계에서 소프트웨어 확장성에 주의를 기울이면 이와 같은 문제를 피할 수 있습니다.

그렇다면 소프트웨어의 확장성이란 무엇입니까? 솔루션이 확장 가능한지 확인하는 방법은 무엇입니까? 언제 스케일링을 시작해야 합니까?

소프트웨어 확장성이란 무엇입니까?

Gartner는 확장성을 처리 요구의 변화에 ​​대응하여 성능 및 비용을 감소 또는 증가시키는 시스템 능력의 척도로 정의합니다.

소프트웨어 개발 맥락에서 확장성은 최소한의 비용으로 사용자를 추가하거나 제거하면서 워크로드 변동을 처리하는 애플리케이션의 기능입니다. 따라서 확장 가능한 솔루션은 예상이든 자발적이든 급격한 워크로드 증가 후에도 안정적으로 유지되고 성능을 유지할 것으로 예상됩니다. 증가된 워크로드의 예는 다음과 같습니다.

• 많은 사용자가 동시에 시스템에 액세스
• 스토리지 용량 요구 사항의 확장
• 처리 중인 트랜잭션 수 증가

소프트웨어 확장성 유형

애플리케이션을 수평 또는 수직으로 확장할 수 있습니다. 각 접근 방식의 장점과 단점이 무엇인지 살펴보겠습니다.

수평적 소프트웨어 확장성(스케일링 아웃)

더 높은 부하를 처리하기 위해 추가 노드를 시스템에 통합하여 소프트웨어를 수평으로 확장할 수 있습니다. 이는 시스템 전체에 분산되기 때문입니다. 예를 들어 애플리케이션이 지연되기 시작하면 다른 서버를 추가하여 확장할 수 있습니다.

수평적 확장성은 애플리케이션이 향후에 처리해야 하는 부하량을 예측할 수 없을 때 더 나은 선택입니다. 또한 다운타임 없이 빠르게 확장해야 하는 소프트웨어를 위한 이동 옵션이기도 합니다.

이익:

• 실패에 대한 탄력성. 한 노드가 실패하면 다른 노드가 여유를 가져옵니다.
• 새 노드를 추가하는 동안 기존 노드를 비활성화할 필요가 없으므로 확장 중 다운타임 기간이 없습니다.
• 이론적으로 수평 확장 가능성은 무한합니다.

제한 사항:

• 복잡성이 추가되었습니다. 워크로드가 노드 간에 분산되는 방식을 결정해야 합니다. 부하 관리에 Kubernetes를 사용할 수 있습니다.
• 더 높은 비용. 새 노드를 추가하면 기존 노드를 업그레이드하는 것보다 비용이 더 많이 듭니다.
• 전체 소프트웨어 속도는 노드 통신 속도에 의해 제한될 수 있습니다.

수직 소프트웨어 확장성(스케일링 업)

수직 확장성은 기존 하드웨어에 더 많은 성능을 추가하는 것입니다. 수평적 확장성으로 애플리케이션의 부하를 처리하기 위해 다른 서버를 추가하려는 경우 여기에서 더 많은 처리 능력, 메모리 등을 추가하여 기존 서버를 업데이트합니다. 또 다른 옵션은 이전 서버를 제거하고 대신 더 발전되고 기능이 있는 서버에 연결하는 것입니다.

이 확장성 유형은 통합해야 하는 추가 로드의 양을 알고 있을 때 잘 작동합니다.

이익:

• 업데이트된 인프라에 적응하기 위해 구성이나 애플리케이션의 논리를 변경할 필요가 없습니다.
• 다른 기계를 추가하는 것보다 업그레이드 비용이 적게 들기 때문에 비용 절감

제한 사항:

• 업그레이드 프로세스 중에 가동 중지 시간이 있습니다.
• 업그레이드된 시스템은 여전히 ​​단일 실패 지점을 나타냅니다.
• 하나의 장치를 업그레이드할 수 있는 양에는 제한이 있습니다.

소프트웨어의 수직적 확장성과 수평적 확장성

다음은 두 소프트웨어 확장성 유형의 다양한 측면에 대한 개요를 제공하는 표 비교입니다.

언제 확장성이 절대적으로 필요합니까?

많은 회사에서 비용 절감과 소프트웨어 개발 수명 주기 단축을 위해 소프트웨어 엔지니어링의 확장성을 무시합니다. 그리고 확장성이 필수적인 시스템 품질 속성이 아닌 경우가 몇 가지 있지만 대부분의 경우 제품 수명 주기의 초기 단계에서 확장성을 고려해야 합니다.

소프트웨어 확장성이 필요하지 않은 경우:

• 소프트웨어가 개념 증명(PoC) 또는 프로토타입인 경우
• 직원만 사용하는 중소기업용 내부 소프트웨어 개발 시
• 백엔드가 없는 모바일/데스크톱 앱

나머지는 때가 되면 준비할 수 있도록 확장성 옵션을 살펴보는 것이 좋습니다. 확장해야 할 때인지 어떻게 알 수 있습니까? 성능 저하가 감지된 경우. 다음은 몇 가지 징후입니다.

• 애플리케이션 응답 시간 증가
• 동시 사용자 요청을 처리할 수 없음
• 연결 실패 및 시간 초과와 같은 오류율 증가
• 병목 현상이 자주 발생합니다. 데이터베이스에 액세스할 수 없거나 인증에 실패했습니다.

확장성이 뛰어난 소프트웨어 구축을 위한 팁

소프트웨어 확장성은 소프트웨어 개발 초기에 고려할 경우 훨씬 저렴하고 구현하기 쉽습니다. 구현 중에 필요한 조치를 취하지 않고 예기치 않게 확장해야 하는 경우 프로세스에 훨씬 더 많은 시간과 리소스가 소요됩니다. 이러한 접근 방식 중 하나는 코드를 리팩터링하는 것인데, 이는 새로운 기능을 추가하지 않기 때문에 중복 작업입니다. 단순히 개발 중에 수행해야 하는 작업을 수행합니다.

아래에서 향후 확장하기 쉬운 소프트웨어를 구축하는 데 도움이 되는 8가지 팁을 찾을 수 있습니다. 아래 표는 팁을 여러 소프트웨어 개발 단계로 나눕니다.

팁 #1: 더 나은 소프트웨어 확장성을 위해 클라우드에서 호스팅을 선택하십시오.

클라우드 또는 온프레미스에서 애플리케이션을 호스팅하는 두 가지 옵션이 있습니다. 또는 하이브리드 접근 방식을 사용할 수 있습니다.

온프레미스 모델을 선택하면 자체 인프라에 의존하여 애플리케이션을 실행하고 데이터 스토리지를 수용하게 됩니다. 이 설정은 확장 능력을 제한하고 더 많은 비용을 초래합니다. 그러나 규제가 심한 부문에서 운영하는 경우 온프레미스 호스팅을 통해 데이터를 더 잘 제어할 수 있으므로 선택의 여지가 없을 수 있습니다.

또한 뱅킹과 같은 일부 부문에서는 트랜잭션 처리 시간이 매우 중요하므로 클라우드가 응답하거나 클라우드 제공업체의 중단 시간을 용인할 때까지 기다릴 여유가 없습니다. 이러한 산업에서 운영되는 회사는 특정 하드웨어를 사용하도록 제한되며 클라우드 공급자가 제공하는 모든 것에 의존할 수 없습니다. 자동화된 차량과 같이 시간에 민감한 미션 크리티컬 애플리케이션도 마찬가지입니다.

클라우드 컴퓨팅 서비스를 선택하면 인프라를 사용하는 대신 타사 리소스에 액세스할 수 있습니다. 클라우드를 사용하면 서버 및 기타 하드웨어에 투자하지 않고도 확장 및 축소할 수 있는 거의 무제한의 가능성이 있습니다. 클라우드 공급업체는 또한 인프라를 유지하고 보호할 책임이 있습니다.

의료 산업에서 일하는 경우 의료 부문의 클라우드 컴퓨팅에 대한 기사를 확인할 수 있습니다.

팁 #2: 로드 밸런싱 사용

수평으로 확장하기로 결정한 경우 로드 밸런싱 소프트웨어를 배포하여 들어오는 요청을 처리할 수 있는 모든 장치 간에 분산하고 서버가 과부하되지 않도록 해야 합니다. 한 서버가 다운되면 로드 밸런서는 서버의 트래픽을 이러한 요청을 처리할 수 있는 다른 온라인 시스템으로 리디렉션합니다.

새 노드가 연결되면 자동으로 설정의 일부가 되고 요청도 받기 시작합니다.

팁 #3: 가능한 한 많이 캐시하십시오.

캐시는 사용자가 다시 계산할 필요 없이 액세스할 수 있는 정적 콘텐츠 및 미리 계산된 결과를 저장하는 데 사용됩니다.

가능한 한 많은 데이터를 캐싱하여 데이터베이스 부하를 줄이십시오. 거의 변경되지 않지만 자주 읽는 데이터를 분산 캐시에서 검색할 수 있는 방식으로 처리 논리를 구성합니다. 이것은 모든 간단한 요청으로 데이터베이스를 쿼리하는 것보다 빠르고 저렴합니다. 또한 무언가가 캐시에 없지만 자주 액세스되는 경우 애플리케이션이 이를 검색하고 결과를 캐시합니다.

이것은 얼마나 자주 캐시를 무효화해야 하는지, 캐시에 복사하기 위해 데이터 조각에 액세스해야 하는 횟수 등과 같은 문제를 야기합니다.

팁 #4: API를 통한 액세스 활성화

최종 사용자는 다양한 클라이언트를 통해 소프트웨어에 액세스할 것이며 모든 사람이 연결하는 데 사용할 수 있는 API(애플리케이션 프로그래밍 인터페이스)를 제공하는 것이 더 편리할 것입니다. API는 두 애플리케이션이 대화할 수 있도록 하는 중개자와 같습니다. 스마트폰, 데스크톱 앱 등 다양한 클라이언트 유형을 고려해야 합니다.

API는 보안 취약성에 노출될 수 있음을 명심하십시오. 너무 늦기 전에 이 문제를 해결하십시오. 보안 게이트웨이, 강력한 인증, 암호화 방법 등을 사용할 수 있습니다.

팁 #5: 비동기 처리의 이점

비동기 프로세스는 백그라운드에서 작업을 실행할 수 있는 프로세스입니다. 클라이언트는 결과를 기다릴 필요가 없으며 다른 작업을 시작할 수 있습니다. 이 기술은 응용 프로그램이 더 많은 스레드를 실행할 수 있도록 하여 노드가 더 확장 가능하고 더 많은 로드를 처리할 수 있도록 하므로 소프트웨어 확장성을 가능하게 합니다. 그리고 시간이 많이 걸리는 작업이 들어오면 실행 위협을 차단하지 않고 애플리케이션이 다른 작업을 동시에 처리할 수 있습니다.

비동기 처리는 시스템에 중요하지 않은 경우 다음 단계를 시작하기 전에 한 단계가 완료될 때까지 기다릴 필요가 없을 때 프로세스를 여러 단계로 분산시키는 것입니다. 이 설정을 통해 하나의 프로세스를 여러 실행 스레드에 분산할 수 있으므로 확장성도 용이해집니다.

비동기식 처리는 코드 및 인프라 수준에서 달성되는 반면 비동기식 요청 처리는 코드 수준에서 이루어집니다.

팁 #6: 가능한 경우 확장하기 쉬운 데이터베이스 유형을 선택하십시오.

일부 데이터베이스는 다른 데이터베이스보다 쉽게 ​​확장할 수 있습니다. 예를 들어 MongoDB와 같은 NoSQL 데이터베이스는 SQL보다 확장성이 뛰어납니다. 앞서 언급한 MongoDB는 오픈 소스이며 일반적으로 실시간 빅데이터 분석에 사용됩니다. 다른 NoSQL 옵션은 Amazon DynamoDB 및 Google Bigtable입니다.

SQL은 읽기 작업을 확장할 때 잘 수행되지만 ACID 원칙(원자성, 일관성, 격리 및 내구성)을 준수하기 때문에 쓰기 작업에서는 지연됩니다. 따라서 이러한 원칙이 주요 관심사가 아닌 경우 더 쉬운 확장을 위해 NoSQL을 선택할 수 있습니다. 일관성 또는 기타 문제를 위해 관계형 데이터베이스에 의존해야 하는 경우 샤딩 및 기타 기술을 사용하여 확장할 수 있습니다.

팁 #7: 해당되는 경우 모놀리식 아키텍처보다 마이크로서비스를 선택하십시오.

모놀리식 아키텍처

모놀리식 소프트웨어는 클라이언트 측 및 서버 측 작업, 데이터베이스 등을 결합하는 단일 단위로 구축됩니다. 모든 것이 밀접하게 결합되어 있으며 모든 기능에 대한 단일 코드 기반을 가집니다. 애플리케이션의 나머지 부분에 영향을 주지 않고 한 부분만 업데이트할 수는 없습니다.

모놀리식 소프트웨어를 확장하는 것은 가능하지만 비용이 많이 들고 비효율적인 수직적 확장 접근 방식을 사용하여 전체적으로 확장해야 합니다. 특정 부분을 업그레이드하려는 경우 전체 애플리케이션을 다시 빌드하고 재배포해야 합니다. 따라서 솔루션이 복잡하지 않고 제한된 수의 사람들만 사용할 경우 모놀리식을 선택하십시오.

마이크로서비스 아키텍처

마이크로서비스는 모놀리식보다 더 유연합니다. 이 스타일로 설계된 애플리케이션은 함께 작동하지만 독립적으로 배포되는 많은 구성 요소로 구성됩니다. 모든 구성 요소는 특정 기능을 제공합니다. 하나의 애플리케이션을 구성하는 서비스는 서로 다른 기술 스택을 가질 수 있으며 서로 다른 데이터베이스에 액세스할 수 있습니다. 예를 들어 마이크로서비스로 구축된 전자상거래 앱에는 제품 검색용 서비스, 사용자 프로필용 서비스, 주문 처리용 서비스 등이 있습니다.

마이크로서비스 애플리케이션 구성 요소는 전체 소프트웨어에 부담을 주지 않고 독립적으로 확장할 수 있습니다. 따라서 확장 가능한 솔루션을 찾고 있다면 마이크로서비스가 가장 적합한 설계입니다. 높은 소프트웨어 확장성은 이 아키텍처에서 얻을 수 있는 많은 이점 중 하나에 불과합니다. 자세한 내용은 마이크로서비스의 이점에 대한 기사를 확인하십시오.

팁 #8: 성능을 모니터링하여 언제 확장할지 결정

배포 후에는 소프트웨어를 모니터링하여 확장으로 해결할 수 있는 성능 저하의 조기 징후를 포착할 수 있습니다. 이를 통해 문제가 확대되기 전에 대응할 수 있습니다. 예를 들어, 메모리가 부족하거나 메시지가 지정된 제한보다 더 오래 처리되기를 기다리는 경우 이는 소프트웨어가 최대 용량으로 실행되고 있음을 나타냅니다.

이러한 문제 및 기타 소프트웨어 확장성 관련 문제를 식별할 수 있으려면 코딩 단계에서 원격 측정 모니터링 시스템을 애플리케이션에 포함해야 합니다. 이 시스템을 사용하면 다음을 추적할 수 있습니다.

• 평균 응답 시간
• 지정된 시간에 처리된 요청 수인 처리량
• 동시 접속자 수
• 쿼리 응답 시간과 같은 데이터베이스 성능 지표
• CPU, 메모리 사용량, GPU와 같은 리소스 활용도
• 오류율
• 사용자당 비용

Splunk와 같은 기존 모니터링 솔루션 및 로그 집계 프레임워크를 활용할 수 있습니다. 소프트웨어가 클라우드에서 실행 중인 경우 클라우드 공급업체의 솔루션을 사용할 수 있습니다. 예를 들어 Amazon은 이러한 목적으로 AWS CloudWatch를 제공합니다.

ITRex 포트폴리오의 확장 가능한 소프트웨어 솔루션의 예

개인 코치가 있는 스마트 피트니스 미러

프로젝트 설명

클라이언트는 사용자의 운동 루틴을 도와줄 전신 벽 피트니스 거울을 만들고 싶어했습니다. 운동 중 사용자 양식을 모니터링하고 담당자를 계산하는 등의 작업을 수행할 수 있습니다. 이 시스템에는 트레이너가 비디오를 만들고 업로드하고 사용자가 운동을 기록하고 관리할 수 있는 소프트웨어가 포함되어야 했습니다.

소프트웨어의 확장성을 보장하기 위해 수행한 작업

• 우리는 마이크로서비스 아키텍처를 선택했습니다.
• 부하 분산을 위해 수평적 확장성을 구현했습니다. 기존 노드에 너무 많은 부하가 있을 때마다 새 노드가 추가되었습니다. 따라서 CPU 사용량이 용량의 90%를 초과하고 지정된 시간 동안 유지될 때마다 새 노드가 추가되어 부하를 완화합니다.
• 구조적인 이유로 관계형 데이터베이스(예: SQL 및 PostgreSQL)를 배포해야 했습니다. 관계형 데이터베이스는 확장하기가 더 어렵지만 여전히 몇 가지 옵션이 있습니다. 처음에는 사용자 기반이 아직 상대적으로 작았기 때문에 수직 확장을 선택했습니다. 청중이 더 커지면 마스터-슬레이브 접근 방식을 배포하여 데이터를 여러 데이터베이스에 분산시킬 계획이었습니다.
• 이 시스템에는 트레이너의 이름, 운동 제목 등과 같은 정적 정보가 많이 포함되어 있으므로 캐싱의 이점을 광범위하게 활용할 수 있습니다.
• 운동 앱과 서버 간의 비동기식 요청 처리를 위해 RestAPI 사용
• 다른 유형의 비동기식 처리를 위해 AWS Lambda와 같은 서버리스 아키텍처에 의존합니다. 한 가지 예는 비동기 비디오 처리입니다. 트레이너가 새 운동 비디오를 로드하고 이를 다른 운동으로 분할한 후 "저장"을 누르면 서버가 HTTP 라이브 스트리밍을 위해 이 비디오를 처리하기 시작하여 해상도가 다른 원본 비디오의 4개 버전을 구성합니다. 트레이너는 새로운 비디오를 동시에 업로드할 수 있습니다.
• 또 다른 예에서 시스템은 사용자 비디오에서 비동기식으로 스마트 트리밍을 수행하여 사용자가 비활성 상태인 부분을 제거합니다.

생체인식 기반 사이버 보안 시스템

프로젝트 설명

클라이언트는 기업이 생체 인식을 기반으로 직원, 계약자 및 기타 사용자를 인증하고 암호 및 PIN을 피할 수 있는 사이버 보안 플랫폼을 구축하기를 원했습니다. 이 플랫폼에는 사용자 신원을 원격으로 확인하는 라이브 비디오 도구도 포함됩니다.

이 소프트웨어의 확장성을 보장한 방법

• 우리는 분산형 마이크로서비스 아키텍처를 사용했습니다.
• 서로 다른 마이크로서비스 간에 로드를 분산하기 위해 3개의 로드 밸런서를 배포했습니다.
• 이 플랫폼의 일부는 설계상 자동 확장이 가능했습니다. 부하가 특정 임계값을 초과하면 마이크로 서비스의 새 인스턴스가 자동으로 생성됨
• PostgreSQL 4개와 MongoDB 2개 등 6개의 서로 다른 데이터베이스를 사용했습니다. PostgreSQL 데이터베이스는 필요할 때 수직으로 확장되었습니다. 아키텍처를 설계하는 동안 우리는 일부 데이터베이스를 자주 확장해야 한다는 사실을 깨달았고 수평 확장이 더 쉬운 MongoDB를 채택했습니다.
• 더 나은 사용자 경험을 위해 비동기식 처리를 배포했습니다. 예를 들어 비디오 후처리는 비동기식으로 수행되었습니다.
• 타사 서비스 제공업체의 안면 인식 알고리즘을 선택했습니다. 그래서 이미 확장 가능한 솔루션을 선택하고 API를 통해 플랫폼에 통합했습니다.

확장하는 동안 발생할 수 있는 문제

애플리케이션 개발 중에 소프트웨어 확장성을 계획하고 위의 팁을 통합하려는 경우 여전히 다음과 같은 문제에 직면할 수 있습니다.

• 누적된 기술적 부채 . 프로젝트 이해 관계자는 여전히 낮은 비용, 속도 등을 위해 확장성을 배제하려고 시도할 수 있습니다. 확장성은 기능적 요구 사항이 아니며 보다 유형적인 특성에 의해 가려질 수 있습니다. 결과적으로 응용 프로그램은 확장성과 호환되지 않는 기술적 기능을 축적하게 됩니다.
• 애자일 개발 방법론을 통한 확장 . 민첩한 방법론은 변화를 수용하는 것입니다. 그러나 클라이언트가 너무 많은 변경 사항을 너무 자주 구현하려는 경우 변화하는 요구 사항을 수용하기 위해 소프트웨어 확장성을 제쳐둘 수 있습니다.
• 확장성 테스트 . 실제 부하 테스트를 수행하기는 어렵습니다. 데이터베이스 크기를 10배로 늘리면 시스템이 어떻게 작동하는지 테스트하고 싶다고 가정해 보겠습니다. 원래 데이터 특성과 일치하는 많은 양의 현실적인 데이터를 생성한 다음 쓰기 및 읽기 모두에 대한 현실적인 워크로드를 생성해야 합니다.
• 타사 서비스의 확장성 . 타사 서비스 공급자가 확장성을 제한하지 않는지 확인하십시오. 기술 공급업체를 선택할 때 의도한 수준의 소프트웨어 확장성을 지원할 수 있는지 확인하고 솔루션을 올바르게 통합하십시오.
• 애플리케이션 사용법 이해 . 소프트웨어가 어떻게 작동하고 얼마나 많은 사람들이 소프트웨어를 사용할 것인지에 대한 확실한 시각이 필요하며, 이는 정확하게 예측하기가 거의 불가능합니다.
• 건축적 제한 . 때로는 아키텍처 선택에 제한이 있습니다. 예를 들어 관계형 데이터베이스를 사용해야 하고 수평 및 수직 확장을 처리해야 할 수 있습니다.
• 올바른 재능을 갖는 것 . 미래에 골칫거리가 되지 않는 확장 가능한 솔루션을 설계하려면 이전에 유사한 프로젝트를 수행했으며 코딩 및 인프라 관점에서 소프트웨어 확장성을 이해하는 숙련된 설계자가 필요합니다. 여기 ITRex Group에서 우리는 많은 프로젝트에 참여했으며 소프트웨어 개발 중에 항상 확장성을 염두에 둡니다.

요약하자면

확장할 필요가 없다고 절대적으로 확신하지 않는 한 개발 초기 단계에서 소프트웨어 확장성을 고려하고 필요한 예방 조치를 취하십시오. 아키텍처 선택이 제한되어 있고 항상 가장 확장 가능한 옵션을 구현할 수 없는 경우에도 여전히 장애물이 있는 위치를 알 수 있으며 대안을 고려할 시간이 있습니다.

다른 기능 요구 사항을 위해 확장성을 제외하면 역효과를 냅니다. 첫째, 회사는 성능 저하로 어려움을 겪을 것입니다. 요청을 처리하는 데 너무 오래 걸립니다. 사용자는 허용할 수 없는 지연을 경험하게 됩니다. 결국 회사는 초기 단계에서 지출할 수 있었던 금액의 두 배, 세 배를 지불하게 됩니다.

새로운 엔터프라이즈 소프트웨어 배포 또는 기존 시스템 업데이트를 고려하고 있지만 빠르게 확장되는 비즈니스 요구 사항을 따라가지 못할까 봐 걱정되십니까? 연락하세요! 귀하의 소프트웨어가 필요한 모든 기능을 갖추고 있을 뿐만 아니라 최소한의 투자와 중단 시간으로 확장할 수 있는지 확인합니다.

원래 2023년 7월 24일 https://itrexgroup.com 에 게시되었습니다 .