클라우드 애플리케이션을 위한 9가지 룰

퍼옴요~

 

* 이 포스팅은 아래 원문을 번역한 포스팅입니다.
원문: https://www.ibm.com/developerworks/websphere/techjournal/1404_brown/1404_brown.html

by Kyle Brown, Mike Capern

애플리케이션을 클라우드 레디 애플리케이션으로 만들기 위한 방법

애플리케이션을 클라우드에서 실행할 수 있도록 하는 것이 일반화되고 있습니다. 이러한 작업의 난이도는 애플리케이션이 어떻게 개발되었느냐에 따라 크게 달라집니다. 대표적인 차이 중 하나가 “클라우드 레디(cloud-ready)” 애플리케이션과 “클라우드 중심(cloud-centric)” 또는 “클라우드 전용(born on the cloud)” 애플리케이션의 차이입니다.

예를 들어, 애플리케이션을 퍼블릭 클라우드나 프라이빗 클라우드에 효과적으로 배치할 수 있다면 이는 클라우드 레디 애플리케이션입니다. 즉, 애플리케이션이 실행되고 있는 PaaS(platform-as-a-service) 계층에서 제공하는 기능을 십분 활용할 수 있도록 애플리케이션이 디자인되어야 합니다. 또한 PaaS 계층의 전제 조건과 상충하는 디자인 상의 제약 때문에 애플리케이션에 문제가 생겨서는 안 됩니다.

이런 이유로 기존 애플리케이션을 전혀 새로운 애플리케이션, 즉, 클라우드 전용 애플리케이션으로 대체하는 데 주력하는 개발자가 많습니다. 이 클라우드 전용 애플리케이션은 대개 기존 애플리케이션과 다른 툴과 런타임을 사용하여 개발됩니다. 예를 들어 애플리케이션이 클라우드를 위해 완전히 재개발되는 경우에는 관계형 데이터베이스가 Cloudant 또는 MongoDB와 같은 NoSQL 데이터베이스로 바뀔 수도 있습니다.

그러나 굳이 기존 툴과 런타임을 포기할 필요는 없습니다. 일반적으로 애플리케이션 디자인에서 몇 가지 간단한 규칙을 준수한다면 기존 애플리케이션을 완전히 다시 개발하지 않고도 클라우드 레디 애플리케이션으로 만들 수 있습니다. 기존 애플리케이션 중에서 탄력적인 클라우드 환경으로 마이그레이션할 대상을 선정할 때에도 이 규칙을 평가 기준으로 활용할 수도 있습니다.

클라우드 레디 애플리케이션으로 만들기 위한 9가지 규칙은 다음과 같습니다.

1. 특정 토폴로지로 애플리케이션을 코딩하지 않는다

여러 클라우드 플랫폼 서비스의 주요 이점 중 하나는 애플리케이션에서 즉각적으로 확장성을 변경할 수 있다는 것입니다. 이는 IBM® PureApplication® System의 가상 애플리케이션과 같이 탄력적인 확장을 통해 혹은 애플리케이션의 인스턴스 수를 조정하는 방법(예: Heroku에서 dyno 추가, Cloud Foundry에서 Warden 컨테이너 추가)으로 실현할 수 있습니다. 변경 가능한 토폴로지는 언젠가 바뀌기 마련이라는 것을 기억하십시오. 이것은 커다란 변화입니다. 기존 환경에서는 애플리케이션이 특정 배치 토폴로지를 전제로 할 수 있습니다(예: 2노드 IBM 호스트 이름 및 호스트 IP 주소). 이러한 전제 중 어느 것도 클라우드 애플리케이션에서는 유효하지 않습니다. 호스트 이름, IP 주소, 사용 중인 애플리케이션 노드의 수는 언제든 바뀔 수 있습니다. 토폴로지에서 “싱글톤(singleton)”의 위치에 대한 전제가 특히 문제될 수 있습니다. 어떤 노드를 다른 모든 노드에서 접속하려 하는데 그 노드가 없거나 심지어 2개라면 애플리케이션은 어떻게 될까요?

대안

이 첫 번째 규칙은 애플리케이션이 탄력적 확장의 영향을 받지 않게 하는 것입니다. 최대한 일반적이고 상태를 저장하지 않는(stateless) 애플리케이션으로 만드십시오. 싱글톤을 사용해야 하는 경우 투표(voting) 프로토콜을 활성화하여 이 싱글톤이 사라졌을 때 나머지 노드가 싱글톤을 새로 생성할 수 있게 하십시오. 또한 싱글톤의 상태에 대한 영구 백업을 데이터베이스와 같은 공유 리포지토리에 보관하십시오.

2. 로컬 파일 시스템이 영구적이라고 가정하지 않는다

노드는 언제라도 이동하거나 사라지거나 복제될 수 있으므로 파일 시스템에 기록된 파일의 지속성에 대해 어떠한 가정도 해서는 안됩니다. 애플리케이션에서 사용하는 로컬 파일 시스템은 자주 액세스하는 정보의 캐시로 간주하십시오. 노드가 중단되었다가 다른 VM의 다른 위치에서 재시작할 경우, 그 캐시는 사라지고 토폴로지의 다른 노드에서 다른 응답 시간으로 시작됩니다.

대안

로컬 파일 시스템을 임시 정보의 저장소로 사용하지 말고 임시 정보를 SQL 또는 NoSQL 데이터베이스와 같은 원격 저장소에 보관하십시오. 파일 시스템에서 정적 정보를 읽는 것은 괜찮습니다. 예를 들어 각 노드가 동일한 또는 동급의 디렉토리 구조에서 동일한 파일을 갖고 있는 경우 애플리케이션에서 구성이나 속성 파일을 읽을 수 있습니다. 파일 시스템에 고유한 파일을 기록하면 문제가 생깁니다.

3. 애플리케이션에서 세션 상태를 저장하지 않는다

어떤 유형이든 세션 상태 저장(statefulness)은 로컬 파일 시스템에 상태를 저장할 뿐 아니라 로컬 메모리에 영구적인 상태를 저장한다는 측면에서 애플리케이션의 확장성을 제한합니다. 애플리케이션이 노드가 제거될 때 원활하게 정상화하고, 새 노드가 추가될 때 즉시 작업을 재분배하지 못한다면, 이 애플리케이션은 클라우드 환경에서 제 기능을 하기 어렵습니다.

많은 애플리케이션에서 가장 제거하기 어려운 상태가 세션 상태입니다. 그러한 시도 자체가 헛수고로 끝날 때가 많습니다. 최신 웹 애플리케이션에서는 예를 들어, HTML5 기능을 사용하는 방식으로 클라이언트 브라우저에 일부 상태를 저장할 수도 있습니다. 그러나 대개는 중앙의 서버에 상태를 저장하여 그 상태의 영향을 최소화하는 것이 더 효과적입니다. 제 조언대로 진행하시려면 다음을 주의해야 합니다. Java 애플리케이션에서는 HTTPSession 상태가 메모리에 저장되는 경우가 많은데, 언제라도 전체 애플리케이션 서버가 추가되거나 제거되면 문제가 될 수 있습니다. Ruby on Rails도 session[] 해시로 비슷한 메커니즘을 사용하기 때문에 동일한 문제가 발생합니다.

대안

세션을 완전히 제거할 수 없다면 애플리케이션 서버 외부의 고가용성 저장소로 보내는 게 최선책입니다. 즉, IBM WebSphere Extreme Scale, Redis, Memcached와 같은 분산형 캐싱 저장소나 외부 데이터베이스(기존 SQL 데이터베이스 또는 NoSQL 데이터베이스)에 저장하는 것입니다.

4. 파일 시스템에 로깅하지 않는다

로컬 파일 시스템에 로그를 기록할 경우, 애플리케이션이 실행 중인 컨테이너나 VM 전체가 중단될 만큼 심각한 충돌이 일어나면 어떻게 될까요? 또는 PaaS 계층에서 애플리케이션을 스케일다운하기로 결정하고 VM 또는 컨테이너를 완전히 제거한다면 어떻게 될까요? 두 가지 경우 모두 디버깅에 중요한 정보, 특히 사용자가 최초의 증상을 발견하기 훨씬 전에 시작했던 문제를 디버깅하는 데 유용한 정보를 잃게 됩니다.

대안

이런 문제가 있기 때문에 Heroku, Cloud Foundry, PureApplication System과 같은 여러 PaaS 계층은 원격 리디렉션이 가능한 로그 애그리게이터를 추가합니다. 또는 Scribe, Apache Flume과 같은 오픈소스 애그리게이터, Splunk와 같은 상용 제품을 사용할 수도 있습니다. 어떤 경우에도 가변적인 클라우드 환경에서는 로그가 생성된 노드보다 수명이 긴 서비스에서 로그를 사용할 수 있게 해야 합니다. 로깅을 수행할 때 로그의 목적을 고려하십시오. 대부분의 로그 프레임워크는 로깅할 정보의 양을 사용자 정의할 수 있는 로그 레벨이 저마다 다릅니다. 로그 정보가 네트워크 전반에 전달될 예정이라면 그 로그 레벨을 줄여 관리 가능한 수준의 볼륨을 생성하는 방법으로 트래픽의 오버헤드를 최소화하는 조치가 필요할 수도 있습니다.

5. 특정 인프라 종속성을 가정하지 않는다

이 일반적인 원칙은 여러 가지 의미로 구체화됩니다. 이를테면, 애플리케이션에서 호출하는 서비스가 특정 호스트 이름 또는 IP 주소에 있다고 가정해서는 안됩니다. 최근 몇 년 사이 서비스 지향 아키텍처가 널리 보급되었지만, 애플리케이션이 호출하는 서비스 엔드포인트의 세부 사항을 내장하고 있는 경우가 여전히 많습니다. 이처럼 호출된 피어 또는 서비스가 클라우드 환경 내에서 재배치되거나 재생성되고 새로운 호스트 이름과 IP 주소로 이동하면, 호출하는 애플리케이션의 코드에 오류가 발생합니다.

대안

환경별 종속성을 속성 파일의 모음으로 추상화하면 더 나아지겠지만 그래도 완벽하지는 않지요. 파일을 이름으로 사용할 경우 속성 파일을 끊임없이 업데이트하고 변경하는 문제가 있습니다. 애플리케이션은 클라우드 환경에서 더 우수한 레질리언스가 필요하므로 클러스터링에 독립적이어야 합니다. 외부 서비스 레지스트리를 참조하여 서비스 엔드포인트를 확인하거나 라우팅 기능 전체를 가상 이름과 함께 서비스 버스나 로드 밸런서에 맡기는 것이 더 효과적입니다

6. 애플리케이션 내에서 인프라 API를 사용하지 않는다

이는 광범위한 적용과 관련된 규칙인데, “인프라 API”란 소프트웨어 스택을 구성하는 각종 계층을 가리킬 수 있기 때문입니다. 이를테면 WorkManager API와 같은 개념이 등장한지 오래 되었지만 아직도 각자의 스레드를 생성하고 각자의 스레드 풀을 관리하는 Java 개발자가 많습니다. 로우 레벨 인프라 API를 사용하지 않으면 애플리케이션 모니터링 측면에서 중요한 이점이 있습니다. 기존 모니터링 툴은 관리 대상 스레드 풀에 대해 파악하지만, 직접 개발할 경우 클라우드 모니터링 툴은 스레드 병목 지점을 찾아내는 데 도움이 되지 못합니다.

구성 레벨에서 ISV가 각자의 애플리케이션을 최대한 완비된 형태로 만들려 하는 경우가 많습니다. 애플리케이션의 TCP 연결 시간 초과에 낮은 값이 필요하다는 것을 알고 있으면 애플리케이션 또는 그 런처 스크립트에서 이 네트워크 옵션을 확인하거나 설정할 수 있습니다. 이제는 애플리케이션에서 이러한 요구 사항을 애플리케이션에 적합한 클라우드 환경을 준비하는 스크립팅에 맡기는 게 더 나은 방법입니다. 즉, 애플리케이션 코드에 쓰이는 API의 범위를 제한하십시오. 또한 인프라 서비스에 대한 책임을 공급업체에 이전함으로써 애플리케이션에 영향을 주지 않으면서 인프라의 계층, 더 정확히는 운영 체제 이미지가 업데이트되게 할 수 있습니다.
관리 영역에서는 개발자가 JMX API를 통해 IBM WebSphere Application Server 인프라를 쿼리하고 다루는 애플리케이션 코드를 작성하곤 했습니다. 이는 정밀하게 인프라를 제어할 수 있다는 점에서는 유익합니다. 그러나 클라우드 마이그레이션의 일환으로 WebSphere Liberty프로파일과 같은 경량의 애플리케이션 서버로 이전한다면 어떨까요? 여기서는 전혀 다른 MBean 모음이 있고 그 기능도 다릅니다. 이에 대한 코드도 변경해야 합니다. OpenStack과 같은 클라우드 API에서는 더 이례적인 옵션을 시험해볼 기회가 있습니다. 이를테면 OpenStack Nova API를 다루면서 직접 자동 확장을 구현할 수 있습니다.

대안

이는 해결해야 할 잠재적 문제 중 가장 까다로운 문제일 것입니다. 애플리케이션이 실행되는 인프라에 대해 뭔가를 가정하기 시작하면 그 인프라를 변경하는 게 점점 더 어려워집니다. 애플리케이션 코드에서 인프라 서비스 또는 API를 왜 호출하는지 생각해보십시오. PaaS 계층으로 넘길 수 있을까요? 앞서 언급했던 JMX 상황에서는 코드가 애플리케이션 성능에 대한 대시보드를 제공하기 위해 JMX API를 쿼리했는데, 이는 ITCAM과 같은 벤더 솔루션이 더 우수한 편의성과 이동성을 발휘하면서 해결할 수 있습니다. 그렇다면 이렇게 질문해야 합니다. 대신 사용할 만한 기존 오픈소스 또는 상용 제품이 있는가? 애플리케이션은 그 애플리케이션이 실행 중인 인프라의 운용이 아니라 본래 해결하고자 했던 비즈니스 문제에 집중해야 합니다. PaaS 솔루션은 PaaS 계층에 두고 애플리케이션 코드와는 거리를 두십시오

7. 잘 알려지지 않은 프로토콜을 사용하지 않는다

흥미로운 프로토콜과 이를 기반으로 구현되는 흥미로운 패키지가 다양하게 선보이고 있습니다. 문제는 레질리언스를 위해 특별한 구성과 튜닝을 적용하는 경우가 많다는 것입니다. 그리고 클라우드에서는 로드 상태에서 노드를 추가하거나 제거하려면 레질리언스가 절실히 필요합니다. 플랫폼에서 레질리언스를 제공할 수 있는데 데이터베이스 연결 모델에 구현할 이유가 있을까요? HTTP, SSL, 표준 데이터베이스, 큐잉, 웹 서비스 연결을 기반으로 한 애플리케이션은 구성과 관련된 기능을 플랫폼에 맡기므로 장기적으로 더 우수한 레질리언스를 갖추게 됩니다.

대안

애플리케이션에서 오래된 프로토콜 또는 비표준 프로토콜을 사용하고 있다면 이를 “반전의 기회”로 삼아 현대화와 표준화에 나설 때입니다. 예를 들어 IIOP를 사용하던 EJB는 밀레니엄이 시작할 때는 근사한 기술이었지만, 이제는 세상이 바뀌었습니다. REST와 같은 표준(또는 더 오래된 SOAP 및 WS-* 표준)을 따르는 HTTP 기반 인프라로 바꾸면 더 수월하게 새로운 환경으로 시스템을 이동할 수 있습니다. 또한 API 관리를 통해 새로운 비즈니스 기회도 얻을 수 있습니다. 마지막으로, IBM MQ 또는 MQTT와 같은 비동기식 프로토콜은 여전히 건재하며 다양한 애플리케이션 프로그래밍 스타일에서 매우 효과적일 수 있습니다. HTTP를 안정적인 메시징 시스템과 같이 HTTP답지 않은 것으로 바꾸려 하기 보다는 미니멀리즘 방식으로 해당 작업에 적합한 툴을 사용하십시오.

8. OS에 특화된 기능에 의존하지 않는다

표준 기반 서비스 및 API를 사용하는 애플리케이션이 특정 운영 체제 기능에 의존하는 애플리케이션보다 수월하게 클라우드 환경으로 이동할 수 있다는 것은 놀라운 일이 아닙니다. 상위 레벨의 OS 중립적인 버전이 있는데도 OS에 특화된 기능을 사용하려는 경우가 많습니다. 간단한 예로, 수행할 작업의 스케줄링을 생각해보십시오. WebSphere Application Server와 같은 여러 애플리케이션 서버는 API에 직접 스케줄링 서비스를 구현합니다. Quartz와 같은 오픈소스 옵션도 즉시 사용 가능합니다. 그러나 아직도 cron과 같은 OS 레벨 스케줄러에서 Java 프로그램을 호출하는 개발자가 많습니다. 애플리케이션이 Linux 또는 다른 UNIX 버전에서 실행 중일 때는 제대로 작동합니다. 그러나 Microsoft® Windows®로 이전할 경우에는 그렇지 않습니다. 그 반대의 경우도 마찬가지입니다. 즉, 애플리케이션에서 Windows Event Service를 사용할 수 있다고 단정하여 향후 Linux 클라우드에서 실행될 가능성을 배제할 필요가 있을까요?

대안

경우에 따라서는 어떤 운영 체제를 다른 운영 체제처럼 “보이게” 만드는 호환성 라이브러리를 사용하여 이 문제를 해결할 수 있습니다. Cygwin은 Windows 환경에서 Linux 툴 모음을 제공하는 대표적인 호환성 라이브러리입니다. Mono는 그 반대로 Linux에서 .NET 기능을 제공하는 호환성 라이브러리의 좋은 예입니다. 그러나 OS에 특화된 종속은 최대한 피하십시오. 그리고 미들웨어 인프라 또는 서비스 제공업체의 서비스를 활용하십시오.

9. 수동으로 애플리케이션을 설치하지 않는다

클라우드 환경은 기존 환경보다 더 빈번하게 생성되고 삭제되는 편입니다. 애플리케이션을 자주, 필요에 따라 설치하게 됩니다. 따라서 설치 프로세스는 스크립트화되고 확실하게 안정적이어야 하며, 구성 데이터는 스크립트로부터 외부화해야 합니다. 다음 두 가지를 명심하십시오. 첫째, 라이센스 계약에 동의하는 사용자가 반드시 있을 것으로 가정하지 마십시오. 둘째, 여러 가지 구성 옵션 중에서 하나를 선택하는 사용자가 반드시 있을 것으로 가정하지 마십시오.

대안

적어도 애플리케이션 설치를 운영 체제 레벨의 스크립트 모음으로 만드십시오. 미들웨어 플랫폼에 스크립팅 메커니즘이 내장되었다면(예: WebSphere Application Server에서 사용 가능한 Jython 스크립트) 그 기능을 활용하십시오. 애플리케이션 설치를 작은 규모로 유지하고 이동성을 보장하면 Chef, Puppet 또는 PureApplication System의 패턴 등 다양한 자동화 기술에 더 수월하게 적응할 수 있습니다.

또한 애플리케이션 설치에 요구되는 종속성을 최소화하는 것이 바람직합니다. 예를 들면 최소 구성은 무엇입니까? 실제로 애플리케이션을 설치하기 위해 데이터베이스가 사용 가능한 상태가 되어야 합니까? 또는 애플리케이션이 데이터베이스 없이 시작하고 문제를 보고한 다음 데이터베이스가 사용 가능해지면 기능을 늘리는 것이 더 나은 방법입니까?

결론

이와 같이 간단한 규칙을 통해 클라우드에 맞는 애플리케이션으로 만들기 위한 조건을 판단할 수 있습니다. “클라우드 전용” 애플리케이션을 개발하는 경우에는 이 규칙을 염두에 두고 애플리케이션에 직접 반영하십시오. 처음으로 애플리케이션을 클라우드 환경으로 이전할 준비를 하고 있다면 시간을 갖고 이 규칙에 대해 숙고한 다음 중요한 조정을 하는 것이 마이그레이션 여정의 중대한 첫걸음이 됩니다.