클라우드 환경에서 컨테이너(Container) 기술을 적용한, 확장 가능한 웹 애플리케이션(Scalable Web Application) 구축 사례

컨테이너(Container) 기술을 적용할 때 고려할 사항

확장 가능한 웹 애플리케이션을 구축할 때, 컨테이너 기술을 적용한 웹 애플리케이션 개발은 일반적인 Monolithic 환경과는 다르게 여러 사항들을 고려해야 합니다.

첫째, 컨테이너 이미지 Build 환경 구축 필요

컨테이너기반의 웹 애플리케이션 시스템은 소스 코드를 수정할 때마다 이미지 Build를 통해 컨테이너가 배포됩니다. 대부분이 DevOps를 위한 CI/CD 환경에서 이미지 레지스트리(Image Registry) 및 컨테이너 이미지 Build/배포까지 포함된 Pipeline을 구성하기 때문입니다.

둘째, Linux Environment 및 컨테이너 지원 SW 사용

대부분의 컨테이너 환경은 Linux 기반입니다. 예외적으로 Windows 컨테이너 구성이 가능할 수 있지만, 보통의 경우 Windows 기반 시스템을 컨테이너로 바꾸려면 우선적으로 Linux Environment로의 전환이 선행됩니다. 여기에는 컨테이너를 지원하는 SW로의 전환까지가 포함됩니다. 그러나 컨테이너 지원 기능이 없는 SW사용이 불가피한 경우, VM 환경이 더 적합할 수 있습니다.

셋째, Scalable한 구조로 개발된 애플리케이션

Scale-in, Scale-out 발생과 컨테이너 추가 생성/삭제 시, 혹은Workload의 자동 할당 및 해제 시에도 서비스의 영향이 없어야 유연한 Scale in/out이 가능합니다. 때문에 Stateless한 Web/Was서버와 Stateful한 데이터 구성은 Persistent Volume에 구축하는 것이 바람직합니다.

웹 서버 제거 케이스

일반적으로 컨테이너기반 웹 애플리케이션을 쿠버네티스 환경에 구성할 때는 인그레스 컨트롤러(Ingress Controller)라는 Inbound Http/Https Traffic을 통해 처리합니다.

컨테이너로써 인그레스 컨트롤러 자체도 쿠버네티스 worker node에서 서비스되는 Pod입니다. 대규모 처리 과정의 안정적인 진행을 위해서 인그레스 컨트롤러 만 처리하는 Proxy Node를 이중화하여 LB를 통한 로드 밸런싱(Load Balancing)이 바람직합니다. 인그레스 컨트롤러는 웹 서버에서 수행되던 Proxy 역할을 처리하게 됩니다. 즉, 웹 서버 없이 직접 WAS 서버를 호출하는 구조가 가능하다는 의미입니다. 이는 일반적으로 웹 애플리케이션에 많이 적용되는 구성입니다. 이는 웹 서버가 HA(고가용성)를 위해 여러 대로 구성되어 있을 경우 자원 및 웹 서버 비용 절약의 효과를 기대할 수 있습니다.

실제 적용한 성능 테스트에서 TPS가 유사하여 웹 애플리케이션 구성에 많이 적용되고 있습니다. 이때 처리되던 Static Contents를 WAS 서버로 옮기는 것도 고려할 수 있습니다. 또한, WAS 서버 용량 산정 시 해당 서버로 Static Contents를 옮기는 것도 추가로 고려해야 합니다.

웹 서버 유지 케이스

웹 애플리케이션은 커뮤니케이션 시스템으로써 게시물, 댓글, 이슈 토론방 등의 기능을 제공합니다. 그러나 동영상, 스트리밍, 대용량 파일, 다운로드 등 서버가 처리해야 하는 정적 콘텐츠의 크기가 크고 변경이 잦은 경우에는 웹 서버 유지를 고려해야 합니다. A사의 경우, 웹 서버의 Static Contents와 WAS 서버의 Dynamic Contents 모두를 호출하기 위해 위해 인그레스 오브젝트(Ingress Object)를 각각 생성하도록 구성하였습니다. 이와 같은 구조의 시스템은 4,000~5,000 TPS 성능의 규모를 처리합니다. 즉, Path가 구분되어 있고 Session Cookie Name도 다른 두 가지 인그레스 오브젝트를 구성하여 웹 서비스와 WAS 서비스에 대해 라우팅(Routing) 처리한 결과입니다. 이와 같이 Static Contents에 대한 사용량이 높은 경우, 서비스 처리의 상당 부분을 웹 서버에서 처리하게 됩니다. 상대적으로 WAS 서버의 경량화는 소프트웨어 라이선스에 대한 절감효과를 가져올 수 있습니다.

더불어, 쿠버네티스 환경에서 웹 서버를 구성할 때 인그레스 컨트롤러(Ingress Controller)를 통하는 구성 외에도 NodePort를 Open하여 웹 서버로의 다이렉트한 접근 방법을 고려해 볼 수 있습니다. 그러나 NodePort 구성 시에는 30000번 대 Port를 80, 8080 등의 포트로 Port Forwarding까지 고려해야 합니다.

퍼시스턴트 데이터(Persistent Data) 구성 케이스

컨테이너기반 웹 애플리케이션 시스템에서 퍼시스턴트 데이터 에 대한 구성은 크게 세 가지로 나누어 볼 수 있습니다.

첫째, 로그 파일 존재

로그 파일은 RWX용 Persistent Volume으로 구성하여 Scale-in/out되는 여러 컨테이너(Container Deployment)에서 접근이 가능하도록 설계할 수 있습니다. 이때, 로그 파일의 경로가 동일하면 여러 컨테이너에 대한 로그가 하나의 파일에 통합되기 때문에 WAS 컨테이너 Base 이미지의 로그 파일 설정에는 Pod name으로 구분된 경로를 설정하는 것이 바람직합니다. 더불어 오브젝트 스토리지(Object Storage)에 로그 파일이 저장될 수 있지만, 파일을 그곳에 저장하게 하는 별도의 구성이 필요합니다. 다른 선택으로는 Splunk와 같은 솔루션에 로그를 통합 저장하도록 구성하고 WAS 컨테이너 단에서 별도의 로그 파일을 관리하지 않는 방법도 있습니다.

둘째, 텍스트, 이미지, 동영상과 같은 파일 데이터(File Data) 존재

클라우드 환경에서는 이러한 파일 데이터를 오브젝트 스토리지에 저장하는 것을 권장합니다.

셋째, 데이터베이스 데이터(Database Data)가 존재

쿠버네티스 환경에서 데이터베이스와 같은 Stateful Resource는 StatefulSet을 사용합니다. 데이터베이스는 Web/WAS와 달리 각각의 Pod별로 다른 역할/ 기능을 수행하며 Pod 재생성 시 상태 유지가 필요하기 때문입니다. Deployment는 정의된 복제본(Replica)에 대해 최소한(at least)의 개수를 보장하기 때문에 일시적으로 정의된 개수보다 많이 생성될 가능성에 대해 유의할 필요가 있습니다.

Auto Healing 기능을 제공하는 쿠버네티스는 단일 Standalone 데이터베이스라 할지라도 상당한 가용성을 확보할 수 있습니다. 그렇기 때문에 가용성이 확보된다면 컨테이너 데이터베이스는 Standalone으로 구성하는 것이 간단하면서도 효과적입니다. 물론, Operator 활용으로 HA Cluster 구성의 컨테이너 Database를 Scale in/out 할 수 있지만, 이는 어디까지나 데이터베이스 유지/ 관리의 편의성 측면으로 활용하는 것이 좋습니다. 이는 아직까지 컨테이너 기반의 데이터베이스에 대해 Auto Scale in/out이 failover 했을 때 데이터의 무결성, 일관성 등의 몇 가지 제약을 가지고 있기 때문입니다.

여러 가지 고려 사항에도 불구하고, 쿠버네티스이라는 강력한 도구의 활용은 컨테이너 기술을 적용한 MSA기반 웹 애플리케이션 개발의 대세로 떠오르고 있습니다. Tomcat, Nginx와 Web, WAS Server Software 등을 컨테이너로 사용할 수 있는 삼성 클라우드 플랫폼(Samsung Cloud Platform)의 쿠버네티스 Apps은 다수의 현장 운영 경험을 기반으로 최적화된 개발 환경을 제공합니다. 손쉽게 다수의 컨테이너 관리가 가능한 쿠버네티스 서비스, 지금 삼성SDS에서 만나실 수 있습니다.