Container 기술을 적용한 Scalable Web Application 구축 사례

Container 기술 적용 케이스

Container 기술을 적용한 웹 애플리케이션 개발은 일반적인 Monolithic 환경과는 다르게 여러 사항들을 고려해야 합니다.

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

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

셋째, 애플리케이션이 Scalable한 구조로 개발되어야 합니다.
Scalein, Scale-out 발생과 Container 추가 생성/삭제 시, 혹은 workload 의 자동 할당 및 해제 시에도 서비스의 영향이 없어야 유연한 Scalein/out이 가능합니다. 때문에 stateless한 web/was서버와 stateful한 데이터 구성은 Persistent Volume에 구축하는 것이 바람직합니다.

웹 서버 제거 케이스

일반적으로 Container기반 웹 애플리케이션을 Kubernetes 환경에 구성할 때는 Ingress Controller라는 Inbound Http/Https Traffic을 통해 처리합니다. Container로써 Ingress Controller 자체도 Kubernetes worker node에서 서비스되는 Pod입니다. 대규모 처리 과정의 안정적인 진행을 위해서 Ingress Controller만 처리하는 Proxy Node를 이중화하여 LB를 통한 LoadBalancing이 바람직합니다. Ingress Controller는 웹 서버에서 수행되던 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도 다른 두 가지 Ingress Object를 구성하여 웹 서비스와 WAS 서비스에 대해 Routing 처리한 결과입니다. 이와 같이 Static Contents에 대한 사용량이 높은 경우, 서비스 처리의 상당 부분을 웹 서버에서 처리하게 됩니다. 상대적으로 WAS 서버의 경량화는 소프트웨어 라이선스에 대한 절감효과를 가져올 수 있습니다.

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

Persistent Data 구성 케이스

Container기반 웹 애플리케이션 시스템에서 Persistent Data에 대한 구성은 크게 세 가지로 나누어 볼 수 있습니다.

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

둘째, 텍스트, 이미지, 동영상과 같은 File Data가 있습니다.
클라우드 환경에서는 이러한 File Data를 Object Storage에 저장하는 것을 권장합니다.

셋째, Database Data가 있습니다.
Kubernetes 환경에서 Database와 같은 Stateful Resource는 StatefulSet을 사용합니다. Database는 Web/WAS와 달리 각각의 Pod별로 다른 역할/ 기능을 수행하며 Pod 재생성 시 상태 유지가 필요하기 때문입니다. Deployment는 정의된 replica에 대해 최소한(at least)의 개수를 보장하기 때문에 일시적으로 정의된 개수보다 많이 생성될 가능성에 대해 유의할 필요가 있습니다.

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

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