2-2. 인프라, 플랫폼, 데브옵스 환경

이번 차시에서는 아우터 아키텍처를 구성하는 인프라 영역, 플랫폼 영역, DevOps 환경에 대해 말씀드리려고 합니다. MSA에서 인프라 영역은 클라우드 환경을 의미합니다. 클라우드 환경에서 제공되는 서비스는 레이어별로 여러 가지가 있는데요. 여기서는 인프라로서의 서비스, 즉 IaaS, 플랫폼으로서의 서비스, 즉 Paas로 나눠집니다. 예전에 힘들게 구축했던 인프라를 AWS, 구글, 마이크로소프트, IBM 등 세계적인 플랫폼 사업자들이 자동화된 기능으로 제공합니다. 저희 SK에서도 클라우드Z라는 서비스를 제공하고 있는데요. 예를 들면 시스템의 자원 구성, 할당, 관리, 모니터링 등 일련의 작업들을 몇 번 만의 버튼 클릭만으로 자동화, 시각화해서 제공하고 있습니다. 여기서 아키텍트 해야 할 일을 하나씩 살펴보면 제일 하단에 인프라 영역에서 클라우드 사업자가 제공하는 IaaS를 선택할지, 기존 베어 메탈 장비나 가상 머신인 VM을 선택할지 결정해야 합니다. 그다음 위에 플랫폼 영역에서는 마찬가지로 클라우드 사업자가 제공하는 Paas를 선택할지 또는 직접 오픈 소스로 프라이빗한 Paas를 구축할지 결정해야 합니다. 각각의 관계가 어떤 것을 선택할지라도 유연하게 결합할 수 있는데요. 이것은 각 제품들이 상호 독립적이나 호환되도록 모두 유연한 구조로 만들기 때문에 가능한 일입니다. 요즘의 추세는 이렇게 유연성이 소프트웨어의 필수 요소가 되고 있습니다. 플랫폼 영역에서는 가상 머신과 컨테이너를 기반으로 한 Paas 제품을 놓고 선택에 대한 고민을 많이 하게 되는데요. 그 차이점을 살펴보면 가상화는 하이퍼바이저라는 소프트웨어를 이용해서 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술입니다. 반면에 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성합니다. 즉, 게스트OS가 있느냐 없느냐가 가장 큰 차이인데요. 가상화는 게스트 운영체제 설치와 관련 라이브러리 설치 같은 오버헤드가 발생하게 됩니다. 따라서 마이크로서비스 같은 작은 서비스를 패키지하고 배포하기에 컨테이너가 더 적절합니다. 가장 대표적인 컨테이너 기술로는 필요한 라이브러리나 실행 파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커 컨테이너가 가장 유명하고 많이 쓰이고 있습니다. 만약 컨테이너 기술을 선택했다면 이런 컨테이너를 관리하기 위한 기술 또한 필요합니다. 이런 기술을 컨테이너 오케스트레이션이라고 하는데요. 구글이 자신들의 도커 컨테이너 관리 기술을 오픈한 쿠버네이트가 가장 인기입니다. 왜 인기냐면 쉽게 쿠버네이트로 프라이빗한 Paas 환경을 구축할 수 있기 때문입니다. 다음은 쿠버네티스의 운영 메인 화면입니다. 쿠버네티스와 AWS 같은 플랫폼 사업자가 제공하는 대부분의 Paas UI가 매우 비슷한데요. 컨테이너에 애플리케이션을 올리고 다음과 같이 실시간으로 성능으로 모니터링할 수 있고 특정한 조건이 되면 예를 들면 CPU 사용량이 70% 찬다든지, 아니면 메모리 사용량이 어느 정도 차는 경우에 인스턴스 수를 증가시키는 스케일 아웃 설정을 할 수 있습니다. 다음은 마이크로서비스를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 DevOps 환경입니다. DevOps는 사실 첫 주차에서 말씀드린 것처럼 개발과 운영이 분리되지 않은 개발과 동시에 운영을 할 수 있는 조직, 그 문화를 말하기도 하는데요. 여기서는 그런 개발과 운영이 동시에 진행 가능하도록 빠르고 높은 품질로 소프트웨어를 개발할 수 있게 지원해 주는 빌드, 테스트, 배포, 자동화 환경을 말하고 있습니다. 예전처럼 수동으로 빌드, 배포하는 과정을 생각해 보겠습니다. 처음에 개발자가 개발 환경에서 컴파일하고 수동으로 테스트하고 오류를 수정하고 운영 환경 전에 스테이지 환경에서 다시 수동으로 테스트하고 다시 오류를 수정하고. 그다음에 배포 승인을 받고 배포 담당자에 의해 운영 환경에 배포하는 식으로 정말 많은 시간이 흐르게 됩니다. 또한 마지막에 배포를 처리하는 이런 빌드, 배포 담당자는 음지에서 활동한다고나 할까요? 보통 밤새워 진행하는 경우가 많이 있었습니다. 당연히 이런 환경에서는 속도가 날 수가 없습니다. 그래서 이런 활동을 자동화할 필요가 있는 것입니다. 그림을 보면 우선 하단에 배포의 타깃이 되는 인프라와 플랫폼이 있습니다. 보통 클라우드 환경에서 배포를 하게 되면 Paas가 될 수 있겠습니다. 그림에서는 개발자가 형상 관리 도구에 소스 코드를 컴파일하면 빌드, 배포 작업이 되는 것으로 표현되고 있는데요. 하나하나 과정을 살펴보도록 하겠습니다. 자동화된 빌드, 배포 작업을 보통 CICD라고 하는데요. 여기서 CI는 Continuous Integration, 지속적 통합이라고 합니다. 원래 이 활동은 애자일 방법론 중 켄트 벡이 만든 XP의 주요 프랙티스로 시작했습니다. 즉, 오랜 시간 걸리는 빌드를 매일 자동화하여 수행한다면 개발 생산성이나 코디의 품질이 높아질 거라는 건데요. 개발자들이 퇴근 시에 매일 자신이 작성한 소스 코드와 그것을 테스트한 테스트 코드를 형상 관리해 체크인 합니다. 그럼 빌드 도구에서 매일 밤 형상 관리 서버의 코드를 가져와서 통합한 다음에 자동으로 빌드하고 테스트를 수행하게 됩니다. 그리고 그 결과를 레포트 문서로 남기고 빌드 된 소스를 실행 환경에 자동으로 배포해 놓습니다. 그렇게 하면 다음날에 테스터가 실행 환경에서 테스트를 바로 수행할 수 있는 것입니다. 또는 빌드 및 단위 테스트 결과를 개발자가 확인하고 만약 문제가 있다면 바로 소스 코드를 수정할 수 있는 것입니다. 여기서 자동으로 통합하고 테스트하고 레포트로 남기는 활동을 CI라고 하고 실행 환경에 자동으로 배포하는 것을 CD라고 합니다. CD에 대해서 좀 더 살펴보면 CD, 즉 지속적 배포는 Continuous Delivery와 Continuous Deployment의 앞 두 글자를 의미하는데요. 두 가지 의미를 모두 포함하고 있습니다. 그 차이점을 살펴보면 지속적 딜리버리, 지속적 배포는 빌드된 소스 코드의 실행 파일을 실행 환경 반영 전까지 배포하는 방식입니다. 실행 환경 반영을 위해서는 승인 및 배포 담당자의 허가를 받아야 배포할 수 있으며 배포도 수동으로 처리합니다. 조금은 엄격한 배포 절차를 가지는 것이죠. 또 Continuous Deployment는 소스 저장소에 빌드 된 소스 코드의 실행 파일을 실행 환경까지 자동으로 배포하는 방식입니다. 그럼 이런 CICD 과정을 어떻게 구성하는지 살펴볼까요? 보통 파이프라인이라고 합니다. 파이프라인은 통합 및 배포까지 일련의 프로세스를 하나로 연계하여 자동화하고 시각화된 프로세스를 구축하는 것을 말합니다. 이러한 파이프라인도 어떠한 단계를 거칠지, 어떠한 도구로 구성할지를 설계해야 합니다. 여기 보면 전형적인 파이프라인 흐름도가 있는데요. 빌드, 유닛 테스트, 정적 분석, 배포의 과정을 거치고 있습니다. 여기에 배포 전에 UI 테스트, 통합 테스트, 배포 승인 프로세스 등을 넣어서 추가 설계할 수도 있습니다. 그리고 이것을 위해 어떠한 도구들을 활용할지 결정하고 그 연계 정의를 해야 됩니다. 그런 과정이 빌드 배포 파이프라인 설계라고 합니다. 이번 차시에서는 아우터 아키텍처를 구성하는 인프라 영역, 플랫폼 영역, DevOps 환경에 대해 살펴보았습니다. 다음 차시에서는 아우터 아키텍처의 애플리케이션 영역을 구성하는 기반 서비스에 대해 하나하나 자세히 살펴보도록 하겠습니다. 감사합니다.