안녕하세요? 이번 글부터는 간단한 클라우드 애플리케이션을 디자인하고 만들어 가는 과정을 내용으로 연재를 진행 하려고 합니다. 클라우드 애플리케이션 개발을 처음 접하시는 분들을 대상으로 하고 있으며, 블루믹스를 이용하여 개발, 배포 그리고 DevOps를 이용한 내용으로 아래와 같은 순서로 진행 할 예정입니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

클라우드 환경 이해

전반적으로 보면 클라우드 애플리케이션이라고 해서 기존의 웹 애플리케이션과 크게 다르지는 않습니다. 어떤 내용을 보여주고자 하는지 결정되면 그것을 웹을 통해 보여준다는 점은 동일합니다. 다만 그 애플리케이션이 실행되는 서버가 클라우드 환경으로 구성되어 있다는 점. 그리고, 클라우드 환경이기 때문에 일반적인 서버 환경의 차이점은 알고 애플리케이션을 개발하고 운영해야 한다는 차이가 있습니다.

클라우드 서버와 일반 서버 환경의 차이?

사실 클라우드 서버와 일반 서버의 환경 차이에 대해 설명하자면 좀 옛 이야기 일지도 모르지만 개인용 컴퓨터 PC부터 이야기를 시작해야 할 것 같습니다.

개인용 PC가 서버와 다른점은 말 그대로 개인용으로 사용되는 것이라 성능의 제한이나 OS의 차이가 있을 뿐 컴퓨터라는 점은 동일합니다. 특히, 대형 서비스를 구성하는 경우가 아니라면 웹서버, Database 환경도 구성할 수도 있으며, Linux와 같은 OS가 아니더라도 익숙한 OS인 Windows의 Server용을 사용할 수도 있습니다.

그럼 서버 환경과 PC와 뭐가 다른 걸까요?

가장 큰 차이점은 네트워크와 규모의 차이로 볼 수 있습니다. 보통 PC는 말 그대로 개인용입니다. 개인이 필요해서 사용하는 것으로 이 컴퓨터를 통해 서비스되는 내용은 그리 큰 네트워크를 필요로하는 경우가 많지 않습니다. 개인용이니까요. 만약 개인이 아닌 다수를 위한 환경을 구성하고자하면 먼저 해당 PC를 외부 인터넷에서 접속 할 수 있도록 네트워크 도메인 이름도 있어야 하고, 이렇게 제공하는 서비스가 정말 인기가 많아서 많은 사용자가 접속하거나 또는 대량의 네트워크 데이터를 쓰게 된다면 속도나 용량에 있어서 일반적인 개인 PC 환경은 적합하지 않습니다.

규모가 커지는 경우 IDC (인터넷 데이터 센터)에 전용 서버를 구매하고 이 서버에 배포하여 보다 안정적인 서비스를 제공 하는데, 이 전용 서버라는 것도 무제한으로 사용하는 것이 아니라 시간이 지나 구식이 되는 경우나 고장이 나거나 하는 이유로 기존 서버를 새로운 장비로 이전 및 교체하는 비용이 발생하게 됩니다. 이와 같은 물리 서버로 구성된 인프라(infrastructure)를 가상 서버로 구성된 형태로 전환된 것이 바로 클라우드 방식의 호스팅이 시작된 것으로 볼 수 있습니다.

클라우드 호스트 환경 자체는 물리적으로 서버로 구성되어 있지만, 제공하는 게스트 서버는 가상화 된 형태의 서버로 구성되어 있습니다. 네트워크를 통해 원격 접속해서 사용하는 것으로, PC에서 전용 서버로 이동한 것과 같이 물리 전용 서버에서 가상 전용 서버로 바뀐 셈이죠.

서비스 운영자의 입장에서 바라본 클라우드

서비스 운영자의 입장에서는 PC와 전용 서버의 차이는 규모의 차이로 인식합니다. 즉, PC와 같은 소규모 환경에서 서버와 같은 대형 환경으로 변한 것인데, 이 때 어느 정도 만큼의 서비스를 위해 필요한 리소스를 예측하는 것이 중요 합니다. 예를 들어 내가 만든 애플리케이션이 2~300명 정도 사용하는 경우라면 어지간한 서비스의 경우라도 적당하게 성능 좋은 하나의 서버로도 감당 할 수 있을 겁니다. 근데, 만약 사용자가 2~3천명 정도라면 어떨까요? 아니면 2~3만명이라면? 다수의 사용자들의 요청을 동시에 수용 하여 처리 할 수 있으려면 고성능 서버도 하나가 아닌 여러개의 서버가 준비되어야 합니다.

결국은 제공하는 서비스에 대한 수요 예측을 해야 하고, 그 예측 범위에 맞춰 서버를 구성해야 하는데, 만약 서버가 부족하게 된다면 서비스 장애가 발생하게 됩니다. 서비스 장애가 발생하는 시점에서 그렇다고 갑작스럽게 물리적인 서버를 추가 하는 것도 쉬운 선택은 아니구요. 그렇다고 미리 미리 넉넉하게 구성하면 나중에 유지 보수 및 비용 증가도 무시 할 수는 없습니다. 특히 트렌드에 민감한 서비스의 경우는 더욱 어렵겠지요.

클라우드 서버의 경우는 물리 서버와 달리 가상 서버를 이용환 클라우드 환경(Infrastructure)의 특성으로 인해 사용량 변동에 대해 훨씬 유연하게 대응 할 수 있는데, 이를 Scaling이라고 표현합니다. 예를 들어 네트워크나 CPU의 사용량이 특정 %이상으로 증가하고 그 시간을 어느정도 유지하는 경우 서버를 더 증설하여 이에 대응을 할 수 있도록 하는 것을 Scale Up 그와 반대로 사용량이 줄어드는 경우 서버를 감소 하도록 하는 것을 Scale Down이라고 부릅니다.

서비스 운영자는 클라우드를 안정된 서비스 공급 뿐만 아니라 가상 서버를 이용하는 것으로 물리 서버의 유지 보수 관리 비용 또한 줄일 수 있는 Infrastructure로 인식합니다.

개발자의 입장에서 바라본 클라우드

그렇다면 개발자의 입장에서는 어떨까요? 다양한 개발자가 있겠지만 여기서는 애플리케이션 개발자로 가정해 봅니다. 앱개발자 입장에서 보면 가상서버나 물리 서버와 같은 H/W적 변화는 그리 큰 관심이 없다고 볼 수 있습니다. 보통은 Middleware라 불리는 플랫폼 S/W가 있어, 기본적인 서버 환경에 대한 관리는 자동으로 처리해 주기 때문에 앱개발자의 고민은 애플리케이션과 그 서비스를 만드는 것이 됩니다.

문제는 이 서비스라는 것이 그리 단순한 것이 아니라는 점입니다. 특히, 수많은 업무(Business)와 그 업무가 서로 서로 연관된 형태(Business Logic & Flow)로 구성되어 있기에 이를 하나로 통합된 애플리케이션(Monolithic)으로 배포합니다. 그러나 그 만큼 덩치도 커지고, 이 애플리케이션이 실행되어야 할 서버도 대용량, 고성능으로 준비되어야 하게 되는데, 그런 경우 테스트 환경 구성도 쉽지 않을 뿐만 아니라 작은 부분에 대한 수정사항이나 오류가 발생하는 경우라 하더라도 전체 애플리케이션의 서비스에 영향을 미치게 되는 현상이 발생합니다. 결국, 개발자 입장에서는 개발에 집중할 수 있는 기회를 빼앗기게 되는 셈이 됩니다.

그렇기에, 이와 같이 하나로 통합된 애플리케이션이 아닌 독립된 서비스를 조합하여 구성되는 애플리케이션 아키텍쳐가 주목 받게 됩니다. 서비스가 독립적으로 구성된 경우 해당 서비스를 별도로 배포 할 수도 있으며, 이를 클라우드 서버의 Scaling 기능을 적용하면 서비스 사용량 증가에도 대응이 가능하게 됩니다. 단일 구성 애플리케이션 아키텍쳐보다 자원을 효율적으로 사용할 수 있게 되며 개발 도구를 통일하거나, 아키텍쳐의 큰 변경 없이 확장을 할 수 있는 장점도 가지게 됩니다. 이러한 아키텍쳐를 Microservice Architecture(마이크로 서비스 아키텍쳐)라고 부릅니다.

다만, 앞서 이야기 했던 클라우드 환경의 Scaling이라면 운영체제부터 Middleware에 애플리케이션까지 서비스에 비해 사용되는 리소스가 너무 커서 서비스로 할당되기에는 부적합하다고 볼 수 있습니다. 그렇기 때문에, Cloud Foundry PaaS(Platform As-a Service)나 Docker Container와 같이 적은 리소스로 애플리케이션이나 서비스를 개발에 더 집중 할 수 있는 클라우드 기술이 마이크로 서비스 아키텍쳐에 더욱 적합한 형태로 볼 수 있게 되었습니다.

정리하자면, 앱개발자의 입장에서는 서비스 개발에 보다 집중 할 수 있는 마이크로 서비스 아키텍쳐를 위한 환경이 클라우드로 볼 수 있겠습니다.

클라우드 애플리케이션을 위한 12요소

이제 클라우드 애플리케이션을 설계하기 위해서 알아두어야 할 내용으로 The 12-Factors App에 대해 알아 보겠습니다.

12가지 요소는 Adam Wiggins가 2011년 정리한 것으로 기본적으로는 클라우드 애플리케이션 개발 방법론입니다. 다만, 애플리케이션만 해당되는 내용은 아니고, 그런 애플리케이션이 실행되는 클라우드 플랫폼과 개발 및 운영 환경의 내용도 같이 정리되어 있으며, 앞으로 사용할 Bluemix 플랫폼도 이 12요소가 적용된 형태이므로 어떤 부분이 Bluemix와 관련된 내용인지 잠시 소개 드립니다.

  • Factor I: [코드 베이스] 리비젼을 이용하여 하나의 베이스 코드를 다양한 형태로 배포
  • Factor II: [의존성] 명시적인 선언 및 의존성 분리
  • Factor III: [설정] 설정 값을 환경 변수에 저장
  • Factor VI: [백엔드 서비스] Backend 서비스를 연결된 리소스로 취급
  • Factor V: [빌드, 릴리즈, 실행] 빌드와 실행 스테이지의 철저한 구분
  • Factor VI: [프로세스] 애플리케이션을 하나 이상의 stateless 프로세스로 실행
  • Factor VII: [포트 바인딩] 포트 바인딩(연결)을 이용하여 서비스 노출
  • Factor VIII: [동시성] 프로세스 모델을 이용한 확장(scale out)
  • Factor IX: [폐기가능성] 빠른 시작과 정상 종료로 안정성 극대화
  • Factor X: [개발/운영 일치] 개발, 스테이지 그리고 운영을 최대한 유사한 형태로 유지
  • Factor XI: [로그] 이벤트 스트림으로 로그를 처리
  • Factor XII: [관리 프로세스] 운영자 및 관리자 작업을 일회성 프로세스로 실행
  1. [코드 베이스] 애플리케이션이 Revision Control로 추적/관리되고 있는가?
    기본적으로 애플리케이션 소스 코드 관리를 위한 환경이 구성되어 있는 것을 가정합니다. Bluemix에서는 DevOps 환경을 지원하며, Code Repositry 및 Project Management 플랫폼으로 JazzHub를 사용했었으나, GitHub도 지원하고 있습니다.

  2. [의존성] 애플리케이션이 필요로하는 모듈이나 라이브러리가 선언되어 있는가?
    Runtime에 따라 다르겠지만 Node.js인 경우 package.json에 해당 애플리케이션이 사용하는 모듈과 version을 명시적으로 선언해 놓고 사용합니다.

  3. [설정] 애플리케이션을 위한 설정 정보를 별도로 가지고 있는가?
    애플리케이션의 코드와 별도의 설정 정보로 Bluemix의 경우는 시스템 환경 변수를 이용하여 설정 정보를 얻을 수 있습니다.

  4. [백엔드 서비스] 별도로 구성된 Backend 서비스를 사용하는가?
    Bluemix는 Service Catalog를 통해 상당히 많은 서비스를 SaaS (Software As-a Service)를 제공 합니다. Cloud Foundry 애플리케이션은 manifest.yml에 필요한 서비스를 지정 할 수 있습니다.

  5. [빌드, 릴리즈, 실행] 빌드, 릴리즈와 실행에 대한 스테이지가 구분되어 있는가?
    Bluemix의 DevOps의 Continous Delivery 환경을 이용하면 Build, Release 및 Deploy별 스테이지로 구분하며 각 스테이지에 필요한 단계를 추가 및 필요한 스크립트나 실행 할 수 있습니다.

  6. [프로세스] 메인 웹 프로세스와 연결되는 별도의 백그라운드 프로세스가 있는가?
    Stateless와 share-nothing인 형태의 프로세스를 강조하는 내용인데, 현재 Bluemix에서는 Procfile 파일에 web이라는 이름의 프로세스만 등록 할 수 있도록 되어 있습니다. 별도의 백그라운드 실행 프로세스가 필요한 경우라면 별도의 애플리케이션으로 생성해서 사용하도록 가이드 하고 있습니다.

  7. [포트 바인딩] 웹 프로세스와 특정 포트 번호를 연결 할 수 있는가?
    Bluemix의 Diego 애플리케이션인 경우는 VCAP_APP_PORT를, 최근 생성하는 Diego 인 경우는 PORT라는 환경 변수를 사용합니다. DEA 에서 Diego 로, Bluemix Cloud Foundry 업그레이드를 참고.

  8. [동시성] 동시성에 필요한 수준을 만족하기 위해 필요한 메모리와 인스턴스가 얼마나 되는가?
    Bluemix의 애플리케이션은 인스턴스를 증감하는 방법으로 Horizontal Scaling을 지원하며, 인스턴스당 할당되는 메모리를 조절하는 Vertical Scaling을 지원합니다. manifest.xml에 필요한 메모리와 인스턴스 갯수를 지정하는 방법으로 배포 하는 방법도 지원합니다.

  9. [폐기가능성] 애플리케이션의 프로세스들이 사용 후 disposable(사용후 버릴 수 있는) 상태인가?
    애플리케이션이 SIGTERM이나 시스템 오류로 인해 급작스럽게 중단되어도 문제가 없이 종료될 수 있는 상태를 말합니다. crash-only design for your app’s processes. 참고.
    Bluemix에서는 애플리케이션의 crash, scaling을 비롯한 다양한 시나리오에 대응하기 위한 애플리케이션 프로세스의 종료 및 재시작을 허용하고 있습니다.

  10. [개발/운영 일치] 개발과 운영에 대한 일치를 위해 어떻게 관리되고 있는가?
    개발환경과 운영환경이 최대한 동일하게 구성되어야 있어야 하는 점을 말합니다. Node.js의 경우는 최소한 npm 및 node 버젼 정보를 맞추도록 package.json에 engine 항목을 명시하도록 가이드고 하고 있으며, VCAP_SERVICES와 같이 애플리케이션 환경 변수를 로컬 개발 환경에서 확인 할 수 있도록 cfenv 명령을 이용할 수도 있습니다.

  11. [로그] 로그 메시지가 표준 출력을 통해 생성되고 있는가?
    애플리케이션이 사용하는 로그 메시지는 다양한 방법으로 생성되고 관리 될 수 있는데, 표춘 출력으로 메시지를 출력하고 이 메시지를 별도의 로그 관리 시스템과 연동하도록 하고 있습니다. Bluemix의 경우는 표준 출력(stdout), 표준 오류(stderr)에 대해 로그를 자동으로 수집하며 필요한 경우 Log drain을 지정하여 외부 로그 관리 시스템과 연동 할 수 있도록 구성되어 있습니다. 로그에 관련 내용은 Bluemix Node.js 앱 디버깅 해 보기 #1 – 로그 이용하기Bluemix 앱 외부 로그 시스템 연동하기를 참고 하시기 바랍니다.

  12. [관리 프로세스] 앱에 일회성 관리 프로세스가 있는가?
    관리 프로세스들은 DB 마이그레이션이나, shell에서 REPL(Read-Evaluate-Print Loop)이나 다른 script를 실행하거나 하는 용도로 사용 될 수 있습니다. Bluemix의 경우는 현재 adhoc admin 프로세스를 지원하지는 않고 있지만, 배포 프로세스에서 필요한 경우 admin 프로세스를 실행 할 수 있습니다. Node.js 앱의 경우는 package.json 파일에 install이나 postinstall 스크립드를 추가하여 간단하게나마 관리 프로세스를 실행 할 수 있습니다.

12가지 요소에 대해서 간략하게 알아보기는 했으나 좀 더 자세한 내용을 원하신다면 The 12-Factors App 홈페이지에서 확인 하실 수 있으니 참고 하시기 바랍니다.

다음 포스팅에서는 본격적으로 클라우드 애플리케이션을 만들어 보도록 하겠습니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

참고