Red Hat OpenShfit를 활용한
컨 테 이 너 전 환 가 이 드
컨테이너 대전환의 시대!
쿠버네티스와 같이 빠르게 진화 발전하는 기술은 열 심히 공부한다고 해서 모두가 전문가가 되기 어렵습 니다. 교육을 열심히 받아도 실제 구축과 운영 경험 이 쌓이지 않으면 혁신의 템포를 쫓아가는 데 급급하 게 됩니다. 이는 실제 현장의 목소리에 잘 담겨 있습 니다.
더뉴스택(The New Stack)의 설문 조사 결과에 따르 면 엔터프라이즈 사용자의 75%가 구현과 운영의 복 잡성으로 쿠버네티스를 도입하지 않고 있다고 답했 습니다. 쿠버네티스를 잘 아는 이들은 많지만 이를 제 대로 구현하는 것은 여전히 어려운 일입니다. 일반적 으로 쿠버네티스 구축과 운영 관련해 고려해야 할 요 소들은 다음과 같습니다. 많은 엔지니어가 설치와 배 포 과정은 잘 압니다. 이는 각종 교육과 자료를 통해 학습할 수 있습니다. 하지만 경험의 영역에 속하는 강 화와 운영 단계는 시행착오를 피할 수 없습니다. 이 단계에서 많은 조직이 부담을 느낍니다.
모든 것을 배워서 할 수는 없다!
기술 내재화 과정에서 겪게 되는 시행착오를 최소화 하는 가운데 쿠버네티스 설치, 배포, 강화, 운영 모든 단계를 일관성 있게 밟아 나갈 방법은 없을까요? 이 런 시장의 요구에 대한 레드햇의 응답이 바로 Red Hat OpenShift입니다. Red Hat OpenShift는 도 커 표준을 기반으로 한 엔터프라이즈 쿠버네티스 플 랫폼으로 보안 측면에서 기업의 요구 수준을 충족하 는 신뢰 기반을 제공하는 가운데 자동화 기반의 운영 으로 기업이 개발에만 집중할 수 있는 길을 제시합니 다.
Red Hat OpenShift는 유연성도 뛰어납니다. 온프 레미스, 하이브리드, 공용 클라우드 어디에 배포하건 일관된 풀스택 플랫폼의 구조를 일관성 있게 유지할 수 있습니다. 그렇다면 OpenShift를 이용해 컨테이 너 환경으로 전환할 때 무엇을 따져봐야 하며, 어떤 절차로 프로젝트를 수행하는지 알아보겠습니다.
컨테이너 전환 시 고려 사항
현재 사용 중인 서버가 리눅스로 운영 중인가?
표준화 작업은 되어 있는가?
조직은 준비가 되어 있는가?
컨테이너 전환에 앞서 체크해야 할 것들을 하나하나 살펴보겠습니다. 먼저 OpenShift가 지원하는 컨테이너 이미지 는 리눅스 기반입니다. 유닉스나 윈도우 서버 환경은 리눅스로 먼저 전환을 해야 합니다. 다음으로 컨테이너 이미지 관 련 사내 표준 및 운영 프로세스 표준화 전략이 필요합니다. 마지막으로 DevOps 실행을 할 수 있는 조직 구성과 역량 을 갖추면 컨테이너 전환 효과를 극대화할 수 있습니다. 컨테이너 전환 절차는 크게 사전 요구 사항 정리, 사전 준비, 마이그레이션, 최적화 4단계로 구분합니다. 요구 사항을 정리하고 분석할 때 고려해야 할 것이 많습니다.
컨테이너 전환에 있어 가장 먼저 할 일은 전환 대상 선정입니다. 어떤 시스템을 옮길 것인지 정하고 해당 서버 운영 체제가 리눅스가 아닐 경우 마이그레이션 계획을 세웁니다. 전환 대상 선정 시 데이터베이스는 제외하는 것이 좋 습니다. 대부분 데이터베이스를 컨테이너 환경에 올리는 것을 추천하지 않습니다. 많은 자원을 요구하는 WAS를 사용할 경우 가벼운 오픈 소스 WAS 전환하는 것도 좋은 방법입니다. WAS의 경우 기존 것을 쓰건, 오픈 소스로 대 체하건 컨테이너 환경에서 쓸 수 있는 베이스 이미지가 있는지 확인해야 합니다. 만약 사용하고자 하는 상용 WAS 가 컨테이너 이미지를 제공하지 않을 경우 벤더에게 요청해야 합니다. 다음으로 네트워크 측면을 따져봅니다.
OpenShift 환경의 애플리케이션 구성 아키텍처는 Route를 외부 진입점으로 삼습니다. 컨테이너에 올린 서비스 는 개별적으로 내부 IP가 동적으로 할당됩니다.
컨테이너 전환 절차
Route
web.rockplace.co.kr Service
172.30.176.102
RCReplicationController DCDeploymentConfig Pod개별 내부 IP
몇 개의 Pod를 만들지…
어떻게 Pod를 배포 할지…
지정된 개수의 Pod가 잘 돌고 있는지…
Container는 Pod에 담겨...
Cluster IP (VIP)를 통한 Load Balancing 외부로부터의 진입점
(Domain과 내부 Service를 연결) Application
Image
Container
Container
Container
App code Runtime
System tools
System libraries
따라서 웹과 WAS 연동 아키텍처 구성시 IP 설정과 확장 방식을 고려해야 하고, API 서버 등 인터페이스 대상 시스템과 의 연계 방안도 생각해 두어야 합니다. 참고로 OpenShift 환경에서는 내부 연계 시 엔드포인트 URL을 서비스 이름이 나 환경변수를 이용하여 지정합니다. 기본 생성된 Route 이외에 외부에서 노드 내부로 들어오는 별도의 엔드포인트가 필요한 경우는 추가 Route 또는 외부 IP를 이용할 수 있습니다.
Route
Frontend + API
Service API Service
API Pod API Pod Frontend
Pod Frontend
Pod
api-service 시스템내부연계:
http://api-service:8080/api
API Route 시스템외부연계:
http://api.ocp.ing.co.kr/api
애플리케이션 측면에서 봐야 할 것도 많습니다. 가장 먼저 봐야 할 것은 컨테이너 전환 가능 여부입니다. 전환 가 능 여부는 기존 아키텍처에 배치한 로드밸런서, APM 등 주요 구성 요소를 OpenShift 기능이 지원하는지 확인하면 알 수 있습니다. 참고로 세션 클러스터링은 확장 시 부하가 증가하여 추천하지 않습니다. 세션 클러스터링 방식은 WAS마다 달라 사전에 벤더를 통해 확인해야 합니다. Multicast 등을 이용한 동적 클러스터링은 구성이 가능합니다.
Route Openshift
Service
WAS Pod WAS Pod Legacy
Web + Proxy
WAS WAS
컨테이너 전환 절차
이제 세부적으로 봐야 할 것들을 알아보겠습니다. 먼저 설정값과 소스입니다. 컨테이너 환경에 맞게 설정값이 있 는지 확인하고, 소스 내에 호스트 네임이나 IP 주소를 지정한 것이 있다면 수정을 해야 합니다. 다음으로 사용 중인 솔루션의 라이선스를 확인합니다. JNI, SSO 등의 별도 모듈이 있는 경우 WAS 이미지에서 실행 가능한지도 테스 트해야 합니다. 상용 라이브러리 이용 시에도 라이선스를 확인해야 합니다. C 언어로 작성한 so 파일 형태의 라이 브러리는 컨테이너 이미지에서 실행할 수 있는 바이너리로 바꾸어야 합니다. 이외에도 클러스터링이 고려되지 않 은 배치 형태의 애플리케이션은 Pod를 확장할 때 여러 번 반복해 실행될 수 있으니 다른 애플리케이션과 분리해 배포해야 합니다.
사전 준비의 핵심 ʻ이미지 표준화’
요구 사항을 정리하고 전환 전에 고려해야 할 사항을 살펴봤다면 다음은 본격적인 마이그레이션 준비를 해야 합니 다. 이 과정에서 가장 신경 써야 할 것은 이미지 표준화입니다. 표준화 대상은 생각보다 많습니다.
⁃ 컨테이너 이미지
⁃ 이미지 사용 가이드
⁃ 이미지 업데이트 기준 및 절차
⁃ 컨테이너 사용 리소스 제한 정책
⁃ 프로젝트 및 사용자 관리
⁃ 애플리케이션 생성 및 배포 관리
⁃ 장애 관리
⁃ 버전 관리
⁃ 관제 및 모니터링
⁃ 이미지 리포지토리 관리
마이그레이션 및 최적화
사전 준비를 성공적으로 마쳤다면 이제 남은 것은 마이그레이션과 최적화 작업입니다. 일반적인 엔터프라이즈 환 경의 경우 WAS 이미지 및 빌드 구성 후 애플리케이션 배포와 테스트로 마이그레이션 과정이 이어집니다.
컨테이너 전환 절차
Application Image
OS Libs JDK WAS Engine
Application Git
변경항목에 어떤 것이 있는지?
• Application
• server.xml
• lib 파일
• JNI 파일
• ?
락플레이스의 One Stop Service
락플레이스가 제공하는 마이그레이션 서비스 지원 범위 와 작업 내용은 다음과 같습니다. 락플레이스는 풍부한 마이그레이션 경험을 통해 쌓은 노하우로 최상의 서비스 를 제공합니다.
1. 전환 대상 애플리케이션 분석 2. 이미지 선정
3. WAS 마이그레이션(필요시) 4. 도커 테스트 환경 구축 5. 기본 기능 검증
6. 도커 이미지 OpenShift 컨테이너 플랫폼 이관 7. OpenShift 컨테이너 플랫폼 환경 빌드 구성 8. 템플릿 구성 및 애플리케이션 생성
9. 최종 검증 테스트
Photo by chuttersnap on Unsplash
Photo by frank mckenna on Unsplash
