[클라우드 인프라와 API의 구조] 12. Immutable Infrastructure

1. 과거의 인프라 구축 방법 (온프레미스)

기존 인프라 환경의 생명주기는 업무 서비스나 프로세스 본연의 비즈니스 생명 주기를 따르는 것이 아니라 하드웨어나 소프트웨어의 생명 주기에 좌우된다는 문제가 존재.

 

2. Immutable Infrastructure의 개념

클라우드로 만들어진 인프라 환경에서는 가상 서버를 생성하거나 추가 및 삭제를 API를 통해 제어 가능.

이뮤터블 인프라스터럭처(immutable infrastructure) → Disposable Components (일회용 컴포넌트)

• 인프라 환경을 자동으로 구축하되, 시스템을 변경해야 할 때는 이미 구축된 환경을 수정하는 대신, 구축된 환경을 파괴하고 수정된 환경으로 다시 구축.
• 멱등성의 특징을 가짐
• 불변성을 유지하기 위해 인프라 환경을 코드로 생성하고 유지보수도 코드로 수정한 다음, 인프라를 새로 만들어 내는 방법으로 코드는 변경하더라도, 인프라 자체는 바꾸지 않는다는 의미.

 

⇒ 필요할 때 바로 서비스를 릴리즈하거나, 변화에 맞추어 서비스를 확장할 수 있으며, 사업을 철수해야 할 때는 불필요한 자산을 남기지 않고 처분할 수 있는 시스템 환경의 장점.

 

2-1. Immutable Infrastructure의 Life Cycle

생명주기는 비즈니스의 요구사항에 따름

 

3. Immutable Infrastructure와 Code를 기반한 Infrastructure

인프라 환경의 구성 정보를 코드 형태로 정의한 후, 시스템 구축을 자동화하여 언제든 인프라 환경을 재구성 ⇒ Infrastructure as Code

• 쉐프, 퍼펫, 앤서블, 테라폼 등
• Infrastructure as code를 실현하기 위해서는 클라우드 API가 반드시 필요.

 

4. Blue-Green Deployment

Immutable Infrastructure에서는 기존의 인프라 환경에 변경이 필요한 경우 기존의 인프라를 수정하면서 계속 사용하는 방식이 아니라, 기존 환경을 파괴하고 수정된 환경으로 새로 만드는 접근 방식을 사용.

시스템 Down Time을 최소화하기 위한 인프라 환경 교체 방법

1. 인플레이스 업그레이드 (in-place upgrade)
   • 이미 동작하는 실행 환경에 새로운 애플리케이션 모듈을 배포하는 방법
   • 인플레이스 업그레이드를 하면 사용자 요청을 일시적으로 받지 못하는 단점 존재. (일시적인 다운타임 존재)
   • 릴리즈가 완료되기 전까지 애플리케이션이 정상 동작하는지 알 수 없는 문제.
   • 성능이나 리소스 이슈는 사용자가 장애 상황을 경험한 이후에나 확인되는 잠재 위험이 존재.
2. Blue-Green Deployment

• 변경할 애플리케이션과 실행 환경을 포함하여 인프라를 새롭게 구성한 다음, 실제 동작까지 테스트를 완료하고 이상이 없으면, 현재 사용 중인 시스템의 URL로 교체하는 방법.
• 운영 장비를 두 대 이상 만들어두고 사용자가 점진적으로 업그레이드된 장비로 옮겨갈 수 있도록 함.
• 새로 준비한 환경에서 충분한 테스트를 거친 다음, 이상이 없다고 판단되면 비로소 기존 환경을 파괴.
• 만약 새로 교체한 환경에서 문제가 확인되었다면 기존 환경으로 롤백이 가능.

 

5. Immutable Infrastructure와 애플리케이션 아키텍처

Immutable Infrastructure의 전제 조건 ⇒ Shared Nothing 상태

• 변경 전의 인프라 환경과 변경 후의 인프라 환경 사이에 공유되는 것이 없음.

일반적인 3티어 아키텍처 (Web Server(프레젠테이션 계층) - Application Server - DB 서버)에서 프레젠테이션 계층과 애플리케이션 서버 계층은 보통 애플리케이션 서버에 위치하며 비즈니스 요구 사항에 따라 빈번하게 바뀔 가능성이 높으며, 외부로부터 악의적인 공격이 발생한느 부분이기도 해 보안 취약점에 대한 패치가 자주 발생할 수 있음.

⇒ Immutable Infrastructure의 적용이 가장 필요한 곳.

 

5-1. 세션관리

보통 프레젠테이션 계층과 애플리케이션 계층은 하나의 요청에 대해 하나의 응답을 하고 통신이 종료되는 Stateless 방식으로 동작.

한 사용자가 여러 요청을 보내는 것을 처리하기 위해 내부적으로 세션 정보를 관리함.

세션 정보를 애플리케이션 서버에 저장하는데, 이런 경우 Blue-Green 배포로 서버를 교체하면 세션 정보가 없어서 접속자가 다시 로그인을 해야 한다거나 오동작을 겪기도 함.

⇒ 프레젠테이션 계층과 애플리케이션 계층을 Immutable Infrastructure로 구현하려면 세션 정보를 애플리케이션 서버의 내장 메모리에 두어서는 안 되고 외부의 저장소에 보관하는 것을 검토해야 한다.

 

데이터베이스 계층

데이터베이스 정보만큼은 이뮤터블 하게 새로 구축하는 것보다 변경 전의 인프라 환경과 변경 후의 인프라 환경에서 공유하게 놔두는 것이 현실적임.

• 하나의 데이터베이스에서 다른 데이터베이스로 정보를 복사하는 데는 상당한 시간이 소요되기 때문
• 데이터베이스 서버는 애플리케이션을 배포하지 않는 것이 일반적이고, 외부에서 접속이 가능한 네트워크를 사용하지 않기 때문에, 보안 취약점에 대한 패치의 빈도도 상대적으로 적음.
•  

결론

프레젠테이션 계층과 애플리케이션 계층에는 Immutable Infrastructure을 적용하되, 데이터 계층은 영속적인 인프라 기반으로 구분하는 것이 효과적인 유지보수를 위한 전략.

(물론 데이터베이스 계층도 영속성이 보장되어야 하지 않아도 되는 경우, 오브젝트 스토리지나 Key-Value 스토어 형태의 데이터베이스를 활용하면 하드웨어나 소프트웨어의 생명 주기에 종속되지 않는 유연한 데이터 계층을 만들 수 있음.)

 

6. 마이크로서비스

기존의 모놀리스 서비스의 단점

애플리케이션 모듈을 교체할 때는 새로 구축한 환경에서도 모든 기능이 문제없이 동작하는지 하나하나 확인해봐야 함. ⇒ 애플리케이션 기능이 많으면 많을수록 모듈 교체 시 테스트하는 시간이 길어지고, 변경한 부분과 상관없이 모든 기능을 테스트해보기가 현실적으로 어려움.

⇒ 마이크로서비스

• 독립해서 배포할 수 있는 서비스 단위로 설계된 애플리케이션.

 

7. Immutable Infrastructure & 컨테이너 가상화 기술

하이퍼바이저형 가상화 기술

• 하나의 하이퍼바이저, 혹은 호스트 OS위에 여러 개의 가상 서버를 만들고, 그 안에 Guest OS가 탑재되는 형태로 가상화 환경이 만들어짐.

컨테이너형 가상화 기술

• 하나의 호스트 OS위에 독립된 가상 서버에 해당하는 컨테이너를 여러 개 만드는 형태로 가상화 환경이 만들어짐.
• 하이퍼바이형 가상화 기술과 다르게, OS를 기동 하거나 OS를 설정하는 작업을 할 필요가 없어서 애플리케이션 실행 환경을 기동까지의 시간이 상당히 줄어듬.
• 또한 애플리케이션 실행 환경을 이미지로 패키지화해 두면 필요한 라이브러리 모듈을 업그레이드하거나 애플리케이션만 배포하면 되기 때문에 애플리케이션의 기동 시간을 더 단축시킬 수 있음.

 

8. 도커와 컨테이너 클러스터 관리 프레임워크

8-1. 도커의 구현 기술

도커는 리눅스에서 사용하는 여러 기술들을 응용해서 컨테이너 가상화를 구현하고 있음.

 

Namespaces

• 사용자가 이용하는 공간을 분리하고 글로벌 리소스를 사용자 자신만 가지고 있는 것처럼 격리시켜주는 기능.

 

Cgroups

• CPU의 사용량, CPU 코어 개수, Memory, 사용 가능한 디바이스 등 그룹화된 프로세스의 리소스를 제어.

 

Storage

• 착탈 가능한 스토리지 드라이버 기능.

 

Networking

• 네트워크 디바이스를 짝지어 컨테이너와 호스트 사이의 통신을 가능하게 만드는 veth
• 가상 브릿지를 만들어 컨테이너 간의 통신을 가능하게 만드는 bridge
• 컨테이너 간의 통신 가능 여부를 제어하는 iptables
• 등으로 컨테이너 안의 프로세스 동작을 제어

 

Security

• 컨테이너에서의 프로세스 권한을 관리하는 Capability
• 컨테이너 프로세스 동작을 컨테이너 내부에만 제한하는 SELinux
• 프로세스가 실행하는 시스템 호출을 제한하는 seccomp와 같은 컨테이너 내부 프로세스들을 제어.

 

이와 같이 도커는 리눅스의 호스트 머신상에서 동작하는 프로세스를 커널 기술을 사용해서 격리하고 있음.

하이퍼바이저형의 가상화 기술처럼 호스트 머신과 프로세스 사이에 특별한 소프트웨어 레이어를 두지 않았고, 각 컨테이너는 OS를 별도로 설치할 필요도 없으며, 심지어 호스트 OS의 프로세스로 기동 되기 때문에, 속도가 빠름.

또한 OS상의 프로세스를 격리만 시키는 것이 아니라, 프로세스를 포함한 컨테이너를 하나의 이미지로 만들어 또 다른 OS의 도커 환경에 이식하는 것도 가능.

⇒ 도커를 사용한 컨테이너형 가상화 기술은 인프라 환경에서 하드웨어 계층을 밑바닥부터 완전히 격리할 수 있음.

 

8-2. 도커의 생명주기

Docker Repository는 도커 이미지를 보존하는 곳으로, 반드시 같은 호스트 머신에 있지 않아도 됨 ⇒ 여러 대의 호스트 머신에 클러스터를 구성한 뒤, 그 클러스터에서 컨테이너를 자유롭게 이동시킬 수 있는 프레임워크 존재 ⇒ 쿠버네티스, 도커 스웜.

⇒ 도커 클러스터와 도커 컨테이너의 높은 이식성을 응용하면 여러 노드의 리소스들을 보다 효율적으로 활용할 수 있음.

 

8-3. 컨테이너 클러스터 기능

AWS ECS의 경우

• 클러스터 관리
  • 특정 AWS 리전의 여러 EC2 인스턴스들을 도커 클러스터로 관리.
• 테스크 관리
  • 클러스터 상의 여러 컨테이너들을 사용해서 하나의 목적을 수행하는 테스크들을 관리
• 스케줄러
  • 어느 인스턴스로 컨테이너를 배포할지 결정하는 기능.
  • 미리 정의된 테스크를 실행할 컨테이너를 일정량 유지하는 서비스 스케줄러, 지정된 개수의 테스크를 여유가 있는 인스턴스에 순차적으로 배분하는 테스크 스케줄러, 사용자가 정의할 수 있는 커스텀 스케줄러 등이 존재
• ECS 컨테이너 레지스트리
  • 도커 컨테이너 이미지를 저장, 관리, 배포하는 레지스트리 기능