안녕하세요, 스푼라디오 SRE 팀에서 DevOps 업무를 맡고 있는 백영진(Paul)입니다. 지난 5년 간, 저희 팀은 AWS의 Multi-Account Multi-Region 환경에서 서비스의 안정성과 확장성을 보장하기 위해 Ansible을 활용한 인프라 자동화 및 CI/CD 배포 시스템을 구축하였습니다. 또한 다양한 운영 체제(AmazonLinux, Ubuntu) 환경에서 Ansible Role을 검증하기 위해 Vagrant & VirtualBox를 사용하여 로컬 환경에서 테스트를 수행해왔습니다. 그러나 Mac M1 기기에서는 Vagrant & VirtualBox 실행에 문제가 있었습니다. 이 문제를 해결하기 위해 Molecule이라는 도구와 Docker 활용해서 Ansible Roles를 테스트 방법에 대해 설명을 하겠습니다.1.Molecule 란 무엇인가?Ansible Molecule은 다양한 시나리오를 기반으로 Ansible Role을 테스트할 수 있는 프레임워크로, 현재 Ansible/Red Hat에 의해 유지 관리되고 있습니다. Molecule은 Docker, Vagrant, EC2, Azure, OpenStack, Podman 등 다양한 드라이버를 제공하여 테스트 환경을 구성할 수 있게 해줍니다. 또한 Ansible Molecule는 지속적 통합(Continuous Integration)를 통해 Ansible Role에 변경이 생길 때마다 테스트 프로세스를 자동화하여 지속적인 테스트를 수행할 수 있습니다.2. Molecule 테스트 환경 구성하기Molecule 테스트를 위해 Docker 컨테이너 환경을 구성하였습니다. 또한, Docker-In-Docker (DinD) 기술을 활용하여, 다양한 운영 체제 환경에서 Ansible Role을 테스트할 수 있도록 환경을 구성 하였습니다. 아래의 Dockerfile을 참고해 주시기 바랍니다.# Python 3.10을 기본 이미지로 설정FROM python:3.10# 필수 패키지 업데이트 및 설치RUN apt-get update && \ apt-get install -y git sudo curl && \ apt-get clean && \ rm -rf /var/lib/apt/lists/*# Docker 설치(DinD)RUN curl -fsSL https://get.docker.com -o get-docker.sh && \ sh get-docker.sh && \ rm get-docker.sh# Ansible 및 Molecule 설치RUN pip install --no-cache-dir ansible molecule docker pytest testinfraRUN python3.10 -m pip install -U "molecule-plugins[docker]"Molecule 실행하기 위해서는 Python 3.10 버전 이상이 필요합니다. Docker-In-Docker를 위해서 Docker 설치 하였고, Molecule 드라이버를 Docker 로 설정하기 위해서 플러그인을 설치 및 검증을 위해 pytest, testinfra 패키지를 설치 하였습니다. Molecule 컨테이너 실행하기 위해서 Docker Compose로 구성하였고, Yaml 파일은 아래와 같습니다.version: '3'services: moleclue: container_name: moleclue build: context: . dockerfile: ./Dockerfile volumes: - "./:/workspace" - "/var/run/docker.sock:/var/run/docker.sock" # (DinD) tty: true로컬 PC에서 Docker Desktop을 이미 설치했다고 가정하고 진행하겠습니다. GitHub에서 데모 프로젝트를 클론 합니다. 데모 프로젝트에는 테스트를 위한 간단한 Ansible Role과 Molecule 환경을 구성 및 실행하기 위한 파일로 구성되어 있습니다.# github clonevagrant@molecule:~$ git clone https://github.com/baiyongzhen/molecule-demoCloning into 'molecule-demo'...remote: Enumerating objects: 30, done.remote: Counting objects: 100% (30/30), done.remote: Compressing objects: 100% (23/23), done.remote: Total 30 (delta 0), reused 27 (delta 0), pack-reused 0Unpacking objects: 100% (30/30), 7.58 KiB | 369.00 KiB/s, done.vagrant@molecule:~$ lsmolecule-demovagrant@molecule:~$ cd molecule-demo/# Molecule 환경 실행vagrant@molecule:~/molecule-demo$ docker-compose up -d[+] Building 4.7s (3/8) => [internal] load .dockerignore 0.2s => => transferring context: 2B# docker ps 명령어를 통해서 컨테이너 실행 상태 확인vagrant@molecule:~/molecule-demo$ docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES60180282c58d molecule-demo-moleclue "python3" 26 seconds ago Up 25 seconds moleclue# docker exec 명령어를 통해서 컨테이너 접속vagrant@molecule:~/molecule-demo$ docker exec -it 60180282c58d /bin/bash# workspace 폴더로 이동root@60180282c58d:/# cd workspace/root@60180282c58d:/workspace# lsDockerfile Vagrantfile bitbucket-runner docker-te

배포 자동화는 소프트웨어 개발 프로세스에서 중요한 역할을 합니다.이는 개발자가 코드를 변경하고 테스트한 후 프로덕션 환경에 배포하는 과정을 자동화하여 시간을 절약하고 오류 가능성을 줄이는 데 도움이 됩니다.• None 수동 배포 프로세스는 시간 소모적이고 반복적이며 오류 발생 가능성이 높습니다. 배포 자동화는 이러한 프로세스를 자동화하여 개발자가 더 중요한 업무에 집중할 수 있도록 시간을 확보해줍니다. 또한, 배포 프로세스의 일관성을 유지하여 오류 가능성을 줄이고 배포 시간을 단축할 수 있습니다.• None 배포 자동화는 배포 프로세스를 표준화하고 일관성을 유지하여 배포 품질을 향상시킵니다. 자동화된 테스트를 통해 배포 전에 코드의 버그를 발견하고 해결할 수 있습니다. 이는 시스템 안정성을 높이고 사용자 경험을 개선하는 데 도움이 됩니다.• None 배포 자동화는 배포 프로세스를 간소화하여 배포 빈도를 높일 수 있도록 합니다. 이는 새로운 기능 및 업데이트를 사용자에게 더 빠르게 제공할 수 있도록 합니다. 또한, 문제 발생 시 신속하게 핫픽스를 배포하여 시스템 가동 시간을 늘릴 수 있습니다.• None 배포 자동화는 배포 프로세스를 표준화하고 일관성을 유지하여 보안 취약점을 줄일 수 있도록 합니다. 자동화된 보안 테스트를 통해 배포 전에 시스템의 보안 취약점을 발견하고 해결할 수 있습니다. 배포 자동화는 소프트웨어 개발 프로세스의 효율성, 품질, 빈도, 비용 및 보안을 향상시키는 데 중요한 역할을 하는 기술입니다. 다양한 배포 자동화 도구가 사용 가능하며, 기업의 규모와 요구 사항에 맞는 도구를 선택하는 것이 중요합니다.AWX를 이용한 배포 자동화 툴 개발은 다음과 같은 장점을 제공합니다.• None 간편한 설치 및 사용: AWX는 오픈 소스 플랫폼이며 설치 및 사용이 간편합니다.• None 다양한 기능: AWX는 다양한 배포 관련 기능을 제공합니다.• None 확장성: AWX는 확장 가능하며 다양한 환경에 적용할 수 있습니다.• None 커뮤니티 지원: AWX는 활발한 커뮤니티를 가지고 있으며 지원을 받을 수 있습니다.• None AWX를 이용한 배포 자동화 툴 개발은 소프트웨어 배포 프로세스를 개선하고 다양한 이점을 얻을 수 있는 효과적인 방법입니다.AWX는 Ansible 기반의 오픈 소스 IT 자동화 플랫폼으로, 웹 기반 인터페이스를 통해 Ansible Playbook을 관리, 실행, 배포, 모니터링 등을 수행할 수 있도록 강력한 기능을 제공합니다.• None 모니터링 및 보고: 작업 실행 결과 및 시스템 상태 모니터링 및 보고서 생성AWX는 다음과 같은 분야에 활용될 수 있습니다.AWX는 다양한 규모의 조직에서 IT 자동화를 효과적으로 수행할 수 있도록 지원하는 강력하고 유연한 플랫폼입니다.AWX Operator는 Kubernetes 상에서 Ansible AWX를 관리하기 위한 도구입니다.AWX는 Ansible의 웹 기반 그래픽 사용자 인터페이스로, 작업 흐름을 자동화하고 관리할 수 있는 플랫폼입니다.AWX Operator는 Ku

안녕하세요. HBase 팀 김영주, 김동의입니다. HBase 팀에서는 LY의 많은 서비스를 지원하기 위해 수천 대 규모의 HBase를 운영하고 있습니다. HBase는 Hadoop 기반 칼럼형 분산 데이터베이스로 확장이 용이해 대용량 데이터를 다룰 때 많이 사용하는데요. 회사가 성장하면서 많은 서비스에서 HBase를 사용하고자 하는 니즈가 생겼고, 이를 지원하기 위해 저희 팀에서 전문적으로 HBase를 운영하고 있습니다.HBase 도입 초기에는 Cloudera사의 Cloudera's Distribution for Hadoop(이하 CDH)을 솔루션으로 사용했습니다. CDH가 Hadoop 관련 운영 도구 중 주류였고 커뮤니티를 중심으로 많은 자료를 이용할 수 있었기 때문입니다.하지만 현재 이 솔루션을 탈피하기 위한 작업을 진행하고 있습니다. 몇 가지 이유가 있는데요. 첫 번째 이유는 라이선스 비용입니다. 초기에는 라이선스 비용이 크지 않았지만 서비스가 늘어나고 노드 수가 많아지면서 라이선스 비용이 점점 증가해 무시할 수 없는 수준이 되었습니다. 두 번째 이유는, 상용 배포판의 매니저와 에이전트가 프로세스를 관리하기 때문에 사내 프라이빗 클라우드 플랫폼인 Verda에서 제공하기가 어려울 것이라고 판단했기 때문입니다. 세 번째 이유는 상용 배포판을 계속 사용하면 Cloudera사의 기술 지원에 의존할 수밖에 없어서 팀의 기술력 향상 측면에서 부정적이라고 판단했기 때문입니다.이와 같은 이유로 HBase 팀에서는 CDH로 운영하고 있는 HBase 클러스터를 모두 오픈소스 HBase(이하 Apache HBase)로 이관하기로 결정하고, 내부적으로 HitBase라고 이름을 지었습니다. 또한 이관하기 위해서, Cloudera사의 클러스터 관리 도구인 Cloudera Manager(이하 CM)을 대체할 수 있는 HitBase Handler(이하 HBH)라는 관리용 도구를 만들기로 결정한 뒤 개발에 돌입해 2023년에 HBH v1 버전을 릴리스했습니다.개발 완료 후 실제 운영 중인 서비스를 순차적으로 HitBase로 이관했고, 현재 약 50%의 HBase가 HitBase로 운영되고 있습니다. 이번 글에서는 저희가 2023년 한 해 동안 HBH를 어떻게 개발했는지 공유하려고 합니다.팀 내에서 개발에 투자할 수 있는 시간과 인력을 고려했을 때 처음부터 CM에 포함된 모든 기능을 HBH에서 지원하도록 만드는 것은 어려울 것이라고 판단했습니다. 요구 사항을 분석하며 논의한 결과, 우선 필요한 기능부터 넣은 뒤 CM에서 제공하는 기본 기능을 구현했고, 그 외 그동안 운영하면서 필요하다고 판단했던 리전 복구 및 백업과 실시간 인스펙터 기능을 추가했습니다. 아래는 HBH와 CM의 기능을 비교한 표입니다.HBH 개발 과정은 다음과 같습니다. 각 과정을 하나씩 살펴보겠습니다.Apache HBase로 전환하기 위해서는 무엇보다도 문제없이 작동하는 HBase 바이너리 파일이 필요합니다. 이때 Hadoop 호환성 이슈를 피하려면 안정적이고 검증된 버전을 사용할 필요가 있는데요.

안녕하세요 카카오페이 SRE팀 RE파트 데이빗입니다. RE파트의 주 업무는 “for the 배포, of the 배포, by the 배포”입니다. 즉 배포가 주 업무이고 배포 프로세스 개선 및 배포 효율화를 하고 있습니다. 배포 업무를 하다 보면 안전(safe)과 속도(rapid)의 두 마리 토끼를 잡기 위해 고민을 하고 개선을 하게 되는데요. 이 글을 통해 저희 팀에서 안전과 속도 개선을 어떻게 했고, 어떤 문제들을 겪었는지 공유하여 비슷한 환경에서 겪고 계실 이슈에 도움이 되었으면 좋겠습니다.카카오페이에서는 개발자, 배포자를 분리하여 운영(production) 배포를 하고 있습니다.배포 방식은 온프레미스 환경에서 크게 2가지 타입으로, 전통적인 배포 방식과 컨테이너 기반의 방식으로 구성되어 있습니다.컨테이너 기반의 배포 방식은 컨테이너 환경에 맞게 구현한 파이프라인으로 배포를 통제, 관리하게 되었습니다. 반면 물리 환경은 조직별로 구성한 Jenkins의 배포 Job으로 진행하고 있었고, 레거시 시스템이더라도 시스템이 유지될 때까지는 배포 업무에 있어서 리스크가 있는 부분(아래)은 개선할 필요가 있었습니다.• 배포 시 필요한 매개변수 입력에 휴먼 에러 발생• Problem 레거시 시스템인 물리 배포 방식의 Jenkins 배포 Job은 “빌드 -> 배포”로 구성되어 있습니다. 이런 구조는 빌드가 필요 없는 롤백을 진행할 때도 빌드 후 배포를 진행합니다. Solution 빌드와 배포 사이에 이미지 리포지터리를 두어 빌드 시 리포지터리에 이미 빌드한 결과물이 있는지 확인 후 있다면 바로 배포를 진행하게 하면 될 것 같습니다.• Problem 빌드, 배포에 필요한 매개변수를 Jenkins 배포 Job 실행 시 입력하여 배포를 합니다. 서두에 말씀드린 것과 같이 배포 담당자가 직접 배포를 하고 있는데요. 아무래도 사람이 하는 일이고, 동시에 많은 모듈들을 신경 쓰다 보니 어쩔 수 없이 브랜치명 오기입 혹은 오타 등 휴먼 에러가 발생하기도 합니다. Solution Jenkins에서 입력하는 부분을 자동화하면 휴먼 에러를 줄일 수 있기 때문에 업무 효율화에도 도움이 될 것 같습니다.• Problem 레거시 시스템인 물리 배포 방식의 Jenkins 배포 Job의 구성은 config 파일로 구성되어 있습니다. Job 수만큼 config 파일이 존재하는데요. 많은 Job의 로직 수정이 필요할 경우 모든 config를 수정해야 합니다. Solution 일괄 적용 및 수정, 삭제를 위해선 자동화 시스템이 필요한데요. 공통 파이프라인을 만들어 모든 배포 Job이 일관된 루틴으로 진행할 수 있도록 하고, 프로젝트 관리를 Jenkins의 config 방식에서 코드 베이스로 변경하여 파이프라인에서 프로젝트별 코드에 따른 추가 루틴을 진행하도록 하면 될 것 같습니다.• Problem Jenkins 배포 Job의 구성은 빌드, 배포가 하나로 구성되어 있어서 실제 빌드, 배포에 소요된 시간은 확인할 수 없습니다. 또한 배포 이력은 Jenkins의 job history로만