본문 바로가기

PRODUCT/Middleware

4편: 글로 보는 웨비나 1편 - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려 사항

4: 글로 보는 웨비나 1: OpenShift 구축 사례와 컨테이너로 환경 전환 고려 사항

 

컨테이너 도입을 위해 사전에 고려해야 것들은? 가상 머신에서 운영하던 워크로드를 그냥 옮기는 되는 것으로 많이들 생각합니다. 하지만 엔터프라이즈 워크로드를 컨테이너로 마이그레이션 하려면 표준화를 시작으로 여러 요소를 사전에 꼼꼼히 체크해야 합니다. 아무도 알려주지 않았던 컨테이너 전환을 위한 준비와 고려 사항을 시원하게 모두에게 공개한 락플레이스 웨비나의 주요 하이라이트를 소개합니다. 자세한 내용은 웨비나를 참조 바랍니다.

 

단점이 없는 기술이 있다? 없다?

 

컨테이너는 가상 머신과 비교해 리소스를 적게 사용하고, 애플리케이션 배포 속도는 높아집니다. 이는 하드웨어 측면에서 가상화를 하는 가상 머신과 달리 다수의 컨테이너를 운영체제 커널에서 직접 구동하므로 시작이 빠르고 메모리를 적게 사용할 수밖에 없습니다. 여기에 이식성(Portability)까지 좋습니다. 그렇다면 단점은? 한때 컨테이너가 보안에 취약하다는 이야기들이 보안 업체들의 단골 소재가 적이 있었습니다. 하지만 컨테이너 관련 보안 강화를 위한 도구가 많이 나와 이는 현재 이슈가 아닙니다. 결론을 내리자면 컨테이너는 장점은 매우 많지만 단점을 딱히 끄집어내기 어려운 기술입니다.

 

컨테이너와 도커는 이음동의어?

 

흔히 컨테이너 하면 도커(Docker) 떠올립니다. 둘은 소리는 다르나 뜻이 같은 단어인 이음동의어(異音同義語) 관계일까요? 아닙니다. 도커는 컨테이너 런타임의 일종입니다. 2013 공개된 도커는 Go 언어로 개발을 진행한 오픈 소스 프로젝트였습니다. 그러던 것이 도커 재단이 엔터프라이즈를 출시하면서 오픈 소스로 사용할 없게 되었습니다.

 

레드햇은 오픈 소스를 최우선 전략으로 삼습니다. 그래서 레드햇의 OpenShift 컨테이너 플랫폼은 OCI 선정한 컨테이너 기술의 표준인 cri-o 쿠버네티스 오픈 소스 기술을 사용합니다. OpenShift 컨테이너 플랫폼이 채용한 cri-o 도커와 완벽하게 호환되는데, 장애 위험성은 낮습니다. 데몬 기반 엔진인 도커와 달리 cri-o 기반의 컨테이너 엔진인 podman 데몬이 없어 안정적으로 사용할 있습니다.

 

 

또한, 레드햇은 Openshift Origin이란 이름이었고, 지금은 okd 부르는 오픈 소스 버전의 OpenShift 지원하고 있습니다. 그리고 개인과 기업 고객을 위해 4개로 나뉜 Openshift 플랜도 제공합니다.

 

 

그렇다면  Openshift 위치와 역할은 무엇일까요? 컨테이너 기반 플랫폼을 제공하는 PaaS 보면 됩니다. 아마존, 구글, 마이크로소프트 공용 클라우드에 설치해 있고 필요에 따라 온프레미스 환경에서 베어 메탈, 가상 머신, 레드햇 오픈 스택 플랫폼 환경에도 구현할 있습니다. 공용, 하이브리드, 온프레미스 모두에서 사용할 있는 PaaS입니다.

 

Openshift okd 엔터프라이즈의 선택은?

 

Openshift okd 다른 같은 플랫폼입니다. 모두 오픈 소스라는 점은 같습니다. 하지만 관리 주체를 놓고 보면 둘은 확연히 다릅니다. Openshift 엔터프라이즈 눈높이에 맞춰 손을 제품으로 최적화, 버그 픽스, 보안 패치 등을 레드햇이 맡아서 합니다. 그리고 레드햇을 통해 기술 지원을 안정적으로 받을 있습니다. okd 기술 뿌리는 같지만, 버그 수정과 보안 패치 등을 전적으로 오픈 소스 커뮤니티에 의지해야 합니다. 이런 이유로 okd 1 4 정리 릴리즈를 기다려야  합니다. 전에 공개된 취약점이 있어도, 마땅히 손쓸 도리가 없습니다. 이런 이유로 기업에서는 신뢰성, 안정성, 보안성 보장이 가능한 Openshift 주로 도입합니다. okd 기술 내재화를 시도하는 곳도 있지만, 전문 인력 구하는 것부터 어려움이 크다 보니 초반부터 시행착오를 많이 겪는 경우가 많습니다.

 

Openshift 플랫폼은 다음과 같은 요소로 구성됩니다. 플랫폼 구축 개발자와 운영자 모두 변화를 곧바로 체감할 있습니다. 이를 줄로 요약하면각자 자신의 책임과 역할에 집중할 있다 것입니다.

 

 

개발자는 CI/CD 바탕으로 빌드와 배포 자동화의 이점을 누릴 있습니다. 깃허브 같은 소스 리포지토리에서 코드를 가져와 사전에 표준화한 베이스 이미지에 올려 만든 컨테이너 이미지를 배포하면 그만입니다. 이후 이미지 롤백도 자유로워 배포 장애 발생에 대한 부담도 한결 합니다. 또한, 노드 증설 같은 인프라 영역의 작업도 운영자 도움 없이 직접 있습니다. 중장기적으로는 개발팀 측면에서 마이크로서비스 아키텍처(이하 MSA) 전환을 가속할 있습니다. 운영자 역시 자원 준비 요청에 일일이 대응할 필요 없이 프로덕션 환경에 있는 컨테이너 운영 인프라에 대한 모니터링 중요한 일에 시간을 투입할 있습니다.

 

 

사례를 통해 검증된 Openshift 효과

 

국내에도 Openshift 관련 사례가 다양한 업종에서 발굴되고 있습니다. 관련해 금융권 사례를 예로 들어 보겠습니다. 생명보험 분야의 기업은 도커와 쿠버네티스를 직접 설치해 개발 일부 테스트 용도로 사용하였습니다. 기술 내재화를 시도하는 과정에서 기업은 패치, 업그레이드, 기술 지원 부재가 갖는 위험을 체감하였습니다. 각종 장애 대응을 위해 로깅과 모니터링 체계 마련 역시 오픈 소스 도구 어떤 조합이 최적인지 일일이 살펴보기 어려웠습니다. 또한, 쿠버네티스 환경을 프로덕션까지 적용할 경우 금융권 망분리 요건을 만족해야 하는 이것도 구체적인 방안이 필요했습니다. 여러 방법을 검토한 끝에 기업은 Openshift 플랫폼을 선택하였습니다.

 

Openshift 플랫폼 도입 효과는 시스템 구축 바로 나타났습니다. 기존과 비교해 하드웨어와 소프트웨어 구성 시간이 크게 줄었고, 비용 절감 폭도 컸습니다. 자원 활용의 경우 가상 머신 기반 환경과 비교할 CPU 1/100, 디스크는 1/10 수준으로 낮아졌습니다. 그리고 운영체제 수를 줄여 관리 편의성이 높아졌습니다. 

 

컨테이너 환경 전환 고려 사항

 

락플레이스는 Openshift 도입 관련 국내 주요 기업 고객의 프로젝트 현장을 2015년부터 지켜온 증인입니다. 관련해 여러 프로젝트에 참여하면서 컨테이너 전환 반드시 고려해야 하는 사항이 무엇인지 명확히 파악하였습니다. 락플레이스의 노하우이자 아무도 알려주지 않는 컨테이너 전환 체크리스트를 소개합니다.

 

가장 먼저 생각해야 것은 작게 시작해 크게 가는 길을 찾는 것입니다. 위험을 줄이기 위해 장애에 민감한 업무를 시범 삼아 옮겨 보고 내부 역량을 충분히 확보한 중요 업무까지 마이그레이션 범위를 넓히는 것이 좋습니다.

 

기술적 측면에서 고려해야 것은 크게 현재 환경 평가, 컨테이너 관련 표준화 작업, 내부 조직의 준비 상태입니다. 현재 환경의 경우 애플리케이션 실해 환경에서 운영체제를 살피는 것입니다. Openshift 지원하는 이미지는 리눅스 기반입니다. 따라서 윈도우, 유닉스 환경에서 운영하던 시스템이라면 먼저 리눅스로 전환을 준비해야 합니다. 마이그레이션이 어려우면 컨테이너로 옮길 것과 가상 머신 또는 베어 메탈에서 운영할 것을 명확히 구분해야 합니다.

 

운영체제 환경 점검을 마친 다음 일은 컨테이너 이미지 표준화 작업입니다. 이는 가장 중요한 사전 준비라 있습니다. 이미지 표준화 없이 프로젝트를 시작하는 것은 무모한 도전이 가능성이 매우 큽니다. 이미지 표준화를 하지 않으면 어떤 일이 생길까요? 베이스 이미지를 개발자마다 따로 가져가면 당연히 복잡성이 높아져 관리가 됩니다. 업데이트 기분과 절차 역시 각각 달라 컨테이너 플랫폼 환경 전반이 갖는 운영과 보안 취약성이 커질 있습니다.

 

표준화 작업의 핵심은 이미지 표준화입니다. 작업은 단순히 베이스 이미지를 만들면 되는 것이 아닙니다. 베이스 이미지 외에도 고려해야 것이 많은데 이를 정리하면 다음과 같습니다.

 

l  컨테이너 이미지 표준화

l  이미지 사용을 위한 가이드라인 마련

l  이미지 업데이트 기준 및 절차 정립

l  컨테이너 사용 리소스 제한 정책 수립

l  프로젝트/사용자 관리 방안

l  애플리케이션 생성 및 배포 관리

l  장애 관리

l  버전 관리

l  관제/모니터링 관리

l  이미지 리포지토리 관리

 

위와 같은 기준을 마련했다면 요구 사항 분석을 토대로 다음과 같은 절차를 통해 컨테이너 환경으로 전환을 추진할 있습니다.

 

 

한편 컨테이너 전환 WAS 관련 구성 고민도 많이 합니다.  Openshift 장점 하나는 동적 확장이 자유롭다는 것입니다. 레거시 WEB/WAS 연동 구조는 동적 확장을 고려한 것이 아닙니다. 따라서 컨테이너 환경에 맞게 구성을 해야 합니다. 관련해 Openshift 환경에서 적용 가능한 구조는 다음과 같으니 참조 바랍니다.

 

 

 

Openshift 서비스 구현 방안

 

이재 Openshift 기본 활용 방법을 간단히 알아보겠습니다. 먼저 Openshift 기본 베이스 이미지에 WAS 애플리케이션을 추가해 이미지를 만듭니다. 그리고 여기에 소스 코드가 위치한 Git 서버 주소를 입력해 애플리케이션 자동 빌드와 배포를 수행합니다.

 

 

이렇게 배포한 애플리케이션 실행을 위한 아키텍처는 다음과 같습니다. 라우트는 외부에서 컨테이너 이미지에 접근할 중계 역할을 합니다. 서비스는 파드 단에서 로드밸런싱 기능을 담당합니다. 컨테이너는 파드에 담기고, 각각 내부 IP 부여됩니다. RC ReplicationController 약자로 지정된 개수의 파드가 돌고 있는지 체크합니다. 그리고 DC DeploymentConfig 약자로 파드를 만들지, 어떻게 배포할지를 담당합니다.

 

 

Openshift 환경에서 애플리케이션 소스 코드를 컨테이너 이미지에 포함하기 위해 사용하는 도구는 S2I 빌드, 도커 빌드, 파이프라인 빌드가 있습니다.

 

 

베이스 이미지를 이용해 빌드한 다음 노드로 배포 문제가 생기면 정상 작동하던 시점의 컨테이너로 롤백을 있습니다.  Openshift 배포 히스토리를 모두 가지고 있습니다. 운영자는  문제가 생기면 배포 내역을 참조해 문제가 없던 시점에 생성한 이미지로 롤백을 있습니다.

 

 

자원 확장의 경우 오토스케일링 설정을 통해 포드의 개수를 자동으로 늘리거나, 줄일 있습니다. 이때 기준이 되는 설정 정보는 CPU 사용률입니다.

 

한편 Openshift 기본 이미지 템플릿을 제공합니다. 별도 구독을 통해 이용할 있는 xPaaS 미들웨어 이미지와 다양한 써드파티 ISV에서 제공하는 이미지를 이용할 있습니다.

 

 

이상으로 ‘OpenShift 구축 사례와 컨테이너로 환경 전환시 고려 사항웨비나의 주요 내용을 요약해 보았습니다. 실제 서비스 마이그레이션 사례에 대한 자세한 설명과 락플레이스가 진행한 국내 주요 기업의 OpenShift 사례와 이들 기어이 전환 고려했던 점이 무엇인지에 대한 상세 내용은 웨비나를 참조 바랍니다.

 

웨비나 바로가기

https://www.youtube.com/watch?v=i3yKrHLHYJI

 

 

2020/03/04 - 1편: 컨테이너, 쿠버네티스, DevOps 유행 따라잡기!

2020/03/18 - 2편: 엔터프라이즈 쿠버네티스로 가는 모든 길은 OpenShift로 통한다!

2020/04/01 - 3편: OpenShift 구축 성공 사례: A생명보험사

2020/04/16 - 4편: 글로 보는 웨비나 1편 - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려 사항

2020/04/29 - 5편 : 글로 보는 웨비나 2편 - Microsoft Azure 클라우드에서 Red Hat OpenShift 시작하기

2020/05/13 - 6편 : 글로 보는 웨비나 3편- ARO(Azure Red Hat OpenShift) 운영 시나리오 및 Demo

 

위의 내용은 격주 수요일 마다 업데이트 될 예정입니다. 

해당 칼럼을 빠르게 받아보길 원하신다면? 

락플레이스 뉴스레터 신청하기 (클릭)