애플리케이션 설정: 최적의 서버 구성을 선택하는 방법은?

소개

기술과 인터넷은 우리의 일상, 학업, 직업 생활에서 중심적인 존재가 되었습니다. 그렇기 때문에 수많은 웹사이트와 애플리케이션이 동시에 존재하는 것은 놀라운 일이 아닙니다. 비즈니스를 운영하는 경우, 관련 웹 플랫폼을 보유하고 싶을 것입니다. 애플리케이션을 사용하면 타겟 고객에게 서비스를 쉽게 마케팅하고 제공할 수 있습니다.

이유가 무엇이든 간에, 귀하가 웹 애플리케이션을 제작할 때, 이를 어떻게 구축할지 결정해야 합니다. 선택할 때 사용할 수 있는 옵션은 많습니다. 바로 가장 적합한 서버 구성 말입니다. 선택한 서버 아키텍처에 따라 환경의 모든 것을 실행하고 관리하는 방법이 결정됩니다. 그렇기 때문에 신중하게 고려하여 결정을 내려야 합니다.

적합한 서버 구성을 선택하는 방법

그렇다면 귀하의 애플리케이션에 '적합한' 아키텍처가 무엇인지 어떻게 결정할 수 있을까요? 이를 위해서는 먼저 웹 애플리케이션의 요구 사항이 무엇인지 생각해야 합니다. 특정 사용 사례에 맞게 효율적으로 작동하려면 통합해야 하는 특정 기능이 있어야 합니다. 예를 들어, 확장이 용이한 애플리케이션을 목표로 할 수 있습니다. 또는 모바일 기기뿐만 아니라 브라우저에서도 애플리케이션이 원활하게 작동해야 할 수도 있습니다. 동시에 예산이 가장 큰 관심사일 수도 있습니다.

요구 사항이 무엇이든 간에, 귀하의 애플리케이션을 위한 맞춤형 솔루션을 만들 수 있다는 점을 알아두셔야 합니다. 이 튜토리얼에서는 많은 사람들이 웹 애플리케이션에 흔히 사용하는 다양한 유형의 서버에 대해 알아볼 것입니다. 다양한 사용 사례와 특정 구성이 언제 가장 잘 사용되는지에 대해 이야기하겠습니다. 귀하에게 적합한지 결정하는 데 도움이 되도록 각 서버 아키텍처의 장단점도 알려드리겠습니다.

1. 하나의 서버에 모든 것

이름에서 알 수 있듯이, 하나의 단일 서버에 전체 환경을 로드합니다. 이 환경에는 웹 서버, 애플리케이션 서버 및 데이터베이스 서버가 포함됩니다. 예를 들어, 이는 Linux, Apache, MySQL 및 PHP (LAMP) 스택 구성에서 작동합니다. 다음 튜토리얼을 통해 Ubuntu 서버에 LAMP 스택을 설치하는 방법과 CentOS에 LAMP 스택을 설치하는 방법 및 활용법을 배울 수 있습니다..

사용 시기:

이러한 방식은 시간이 부족할 때 가장 효과적입니다. 설정이 간단하고 빠릅니다. 그렇기 때문에 단순한 웹 애플리케이션에 적합합니다.

장점:

• 이해하고 구현하기가 간단하고 쉽습니다.
• 전체 설정을 완료하는 데 시간이 거의 걸리지 않습니다.

단점:

• 수평적 확장을 지원하지 않습니다.
• 구성 요소 격리 측면에서 제공하는 것이 거의 없습니다.
• 애플리케이션과 데이터베이스가 단일 서버에 있기 때문에 본질적으로 동일한 리소스를 두고 경쟁하게 됩니다.
• 결과적으로 성능 저하를 겪을 수 있습니다.

2. 데이터베이스 서버 분리

단일 서버를 사용할 때의 주요 문제는 제한된 리소스를 두고 경쟁하는 것입니다. 이 구성은 그 문제를 해결하는 것을 목표로 합니다. 여기서는 데이터베이스 관리 시스템(DBMS)을 애플리케이션 서버와 분리하여 유지합니다. 데이터베이스 서버는 사설 네트워크에 있으며 자체 리소스를 가집니다. 이를 통해 성능이 향상되고 보안이 강화됩니다.

사용 시기:

마찬가지로, 빠른 배포를 원한다면 이 구성은 비교적 간단하게 설정할 수 있습니다. 데이터베이스와 애플리케이션이 동일한 리소스를 두고 경쟁하는 것이 걱정된다면 이상적인 솔루션입니다.

장점:

• CPU, 메모리, I/O 등을 포함하여 애플리케이션과 데이터베이스 각각에 대해 분리된 전용 시스템 리소스를 제공합니다.
• 애플리케이션 또는 데이터베이스 계층 중 하나에서 확장 가능성이 더 높습니다.
• 필요에 따라 리소스를 추가하거나 제거할 수 있습니다.
• 공용 인터넷에서 데이터베이스를 제거하면 보안을 한층 더 강화할 수 있습니다.

단점:

• 단일 서버 구성보다 약간 더 복잡합니다.
• 두 서버 간의 대역폭이 낮거나 네트워크 연결 지연 시간이 길면 성능 문제가 발생할 수 있습니다.

3. 역방향 프록시 또는 로드 밸런서

여기서 로드 밸런서 가 등장합니다. 로드 밸런서는 일반적으로 성능과 안정성을 향상시키기 위해 서버 환경에서 사용됩니다. 이들은 '부하를 분산'함으로써, 즉 여러 서버에 작업 부하를 분산시킴으로써 이를 수행합니다.

사용 시기:

로드 밸런서는 수평 확장을 수행해야 할 때 매우 유용합니다. 수평 확장은 기본적으로 환경에 서버를 더 많이 추가하는 것을 의미합니다. 또한 애플리케이션 계층 역방향 프록시를 사용하여 하나의 도메인과 포트로 여러 애플리케이션을 동시에 서비스할 수도 있습니다. HAProxy, Nginx, 그리고 Varnish는 역방향 프록시 로드 밸런싱을 허용하는 소프트웨어의 예입니다.

장점:

• 대기 중인 서버 중 하나에 장애가 발생하면, 다른 서버가 작업 부하를 분산하여 그 기능을 보완합니다.
• 수평 확장을 수행하여 환경의 용량을 늘리거나 줄일 수 있습니다.
• 또한 클라이언트 연결을 제한하여 DDOS 공격에 대한 보호를 제공합니다.

단점:

• 시스템 리소스가 충분하지 않은 경우, 로드 밸런서가 애플리케이션의 성능을 제한할 수 있습니다.
• 적절한 성능을 보장하려면 올바른 구성이 필요합니다.
• 단일 서버 또는 개별 서버 구성보다 훨씬 더 복잡합니다.
• SSL 종료 및 스티키 세션(sticky sessions)이 필요한 애플리케이션과 같은 요소를 고려해야 합니다.
• 로드 밸런서 사용 시 가장 우려되는 점은 단일 장애점(single point of failure)이 된다는 것입니다. 즉, 로드 밸런서가 작동하지 않으면 전체 서비스가 중단됩니다.

4. HTTP 가속기 또는 캐싱 역방향 프록시

이것은 애플리케이션 사용자에게 콘텐츠를 전달하는 속도를 높이기 위해 사용할 수 있는 구성입니다. 이 시간을 단축하기 위해 다양한 기술을 채택합니다. 가장 중요한 것은 애플리케이션 서버의 응답을 캐싱하는 것입니다. 가속기는 사용자가 처음 요청할 때 콘텐츠를 메모리에 저장합니다. 따라서 향후 유사한 요청이 들어오면 애플리케이션 서버와 상호 작용하지 않고 콘텐츠를 신속하게 제공합니다. Nginx, Varnish 및 Squid 모두 HTTP 가속이 가능합니다..

사용 시기:

당연하게도, 이 구성은 사용자가 매우 자주 요청하는 파일 및 콘텐츠에 가장 적합합니다. 또한 콘텐츠가 많은 동적 웹 애플리케이션에도 매우 잘 작동합니다.

장점:

• 캐싱 및 압축은 애플리케이션 및 요청 처리 속도를 크게 향상시킵니다.
• CPU 부하를 줄이면 사이트 성능도 향상됩니다.
• 이를 역방향 프록시 로드 밸런서로 사용할 수도 있습니다.

단점:

• 최상의 성능을 이끌어내려면 튜닝을 잘 해야 합니다.
• 캐시 적중률(cache-hit rate)이 낮을 경우 성능이 저하될 수 있습니다.

5. 주-복제본(Primary-Replica) 데이터베이스 복제

주-복제본(Primary-Replica) 데이터베이스 복제 구성은 일반적으로 쓰기보다 읽기를 더 많이 수행하는 시스템에 매우 유용합니다. 예를 들어, 콘텐츠 관리 시스템(CMS)은 이러한 아키텍처를 매우 잘 활용할 수 있습니다. 복제를 위해서는 하나의 주(primary) 노드와 하나 이상의 복제(replication) 노드가 필요합니다. 이는 모든 노드에 읽기 작업을 분산시킵니다. 업데이트는 주 노드로만 전송됩니다.

사용 시기:

앞서 언급했듯이, 복제 기반 데이터베이스 구성은 시스템의 읽기 성능을 향상시키는 데 도움이 됩니다. CMS와 같은 애플리케이션에 사용할 수 있습니다.

장점:

• 복제본 전체에 읽기 작업을 분산시키므로 데이터베이스의 읽기 성능이 향상됩니다.
• 주 노드를 업데이트 전용으로만 사용하면 쓰기 성능도 향상시킬 수 있습니다.

단점:

• 데이터베이스에 액세스하려는 모든 애플리케이션은 업데이트 및 읽기 요청을 어느 노드로 보낼지 결정할 수 있어야 합니다.
• 주 복제본에 장애가 발생하면 업데이트가 중단됩니다. 업데이트를 계속하려면 문제를 해결해야 합니다.
• 잠재적인 주 노드 장애에 대응할 수 있는 장애 조치(failover) 메커니즘이 없습니다.

서버 구성 조합하여 사용하기

다행히도 원하는 결과를 얻기 위해 다양한 기술을 결합하는 것도 가능합니다. 즉, 단일 환경에서 캐싱 서버와 함께 애플리케이션 서버의 부하를 분산하고 데이터베이스를 복제할 수 있습니다. 이렇게 하면 두 서버의 기능을 모두 활용할 수 있습니다. 하지만 그렇다고 해서 설정이 더 복잡해지거나 번거로워지지는 않습니다.

예시:

예시를 통해 이러한 환경을 이해해 보겠습니다:

이러한 환경에서 로드 밸런서는 정적 요청을 캐싱 서버로 보냅니다.정적 콘텐츠에는 CSS, 이미지, Javascript 등이 포함됩니다. 대신 다른 모든 종류의 콘텐츠 요청은 애플리케이션 서버로 보냅니다.

사용자가 환경에 일부 정적 콘텐츠를 요청한다고 가정해 보겠습니다. 다음과 같은 일이 발생합니다:

• 로드 밸런서는 먼저 콘텐츠가 캐시 히트(cache-hit)인지 캐시 미스(cache-miss)인지 판단합니다. 캐시 히트 콘텐츠는 캐시에 존재하지만 캐시 미스 콘텐츠는 캐시에 없습니다. 이는 캐시 백엔드를 확인하여 수행됩니다.
• 캐시 히트인 경우, 로드 밸런서는 콘텐츠를 사용자에게 보냅니다.
• 캐시 미스인 경우, 캐시 서버는 요청을 애플리케이션의 백엔드로 전달합니다.
• 앱 백엔드는 데이터베이스에서 콘텐츠를 찾아 전송합니다.
• 캐시 백엔드는 로드 밸런서로부터 콘텐츠를 받습니다. 또한 이 콘텐츠를 로드 밸런서로 반환하기 전에 캐싱합니다.
• 그런 다음 로드 밸런서가 사용자에게 응답을 전달합니다.

반면, 사용자가 동적 콘텐츠를 요청하면 다음과 같은 일이 발생합니다:

• 사용자의 요청이 로드 밸런서로 들어옵니다.
• 이 요청은 앱 백엔드로 전달됩니다.
• 앱 백엔드는 요청된 콘텐츠를 찾아 로드 밸런서로 반환합니다.
• 사용자가 콘텐츠를 받습니다.

이러한 결합된 환경의 주요 이점 중 하나는 신뢰성이 더 높다는 것입니다. 그뿐만 아니라 성능도 더 우수합니다. 하지만 여전히 로드 밸런서와 기본 데이터베이스 서버라는 두 가지 단일 장애점(single points of failure)이 존재합니다.

결론

환경에서 각 서버 설정을 단독으로 사용할 수 있습니다. 반면에 몇 가지를 결합하여 개인화된 솔루션을 만들 수도 있습니다. '정답'은 없습니다. 모든 것은 아키텍처에서 얻고자 하는 기능에 달려 있습니다.

각 서버 설정이 어떻게 작동하는지에 대한 기초적인 지식을 갖추면 자신의 애플리케이션에 맞는 결정을 내리는 데 도움이 됩니다. 가장 좋은 방법은 작고 간단하게 시작하는 것입니다. 경험이 쌓이면서 설정의 복잡성을 계속 늘려갈 수 있습니다.

즐거운 컴퓨팅 되세요!