DevOps의 핵심 요소인 Kubernetes 의 탄생(구글 블로그에서 발췌하여 번역)
"분명히 합시다. 여러분은 Borg 태스크 스케줄러를 사외 버전으로 만들고 싶다고 말하는 것이죠? Borg는 우리 회사는 경쟁력 우위를 위해서 무엇보다도 중요한 것 중 하나로 회사밖에서는 그 존재조차 알려지지 않은 것인데, 그것을 공개, 아니 그것도 오픈 소스로 하겠다는 것인가요?" Kubernetes는 2013년 여름 Urs Holzel의 방에서 이런 이야기 속에서 세상에 나오게 되었습니다. Urs는 기술 책임자이며 Google에서 가장 중요한 네트워크 혁신을 해낸 수석 아키텍트입니다. Craig McLuckie는 Urs에게 오픈 소스 컨테이너 관리 시스템 구축 아이디어를 설명했지만 쉽게 동의를 얻지 못했다고 생각했습니다. 왜 그렇게 생각했는지는 구글의 역사를 조금 거슬러 올라가야만 합니다.
Google은 Google 검색, Gmail, 그리고 YouTube 같은 강력한 온라인 서비스를 제공하기 위해 비밀리에 최상의 네트워크 인프라를 만들었습니다. 이 인프라들은 바닥부터 하나씩 만든 데다 프로젝트 초기에는 예산도 많지 않았기에, 서버의 성능을 최후의 하나까지 쪼이고 쪼여서 사용하기 위한 방법 중 하나로 컨테이너 기술을 시험했습니다. 구글은 클라우드 IaaS 플랫폼을 고객에게 공급하기 위해 대량의 CPU 연산자원을 확보했지만, 실제 실행 결과 VM의 비효율성 문제로 연산자원의 활용률이 기대치보다 낮았습니다. 구글은 이 문제를 해결하기 위한 방법으로 컨테이너 기술을 택했고, 이를 컴퓨팅의 미래로 여겼습니다.
컨테이너 기술은 쉽게 확장할 수 있으며 효율적으로 자원을 이용할 수 있게 해줍니다. 2014년 PyCon US에서 Docker가 발표된 이후, 구글은 그동안의 오랜 시행착오를 바탕으로 우수한 컨테이너 관리 시스템을 만들 수 있다고 생각했습니다. 그 후 Borg라는 클러스터 관리 시스템을 만들었으며, 프로젝트에는 Borg의 연관성에서 착안한 이름으로 Seven of Nine1이라는 이름을 붙였습니다. Borg는 수십만 개의 작업을 실행하며 컴퓨팅 효율성을 크게 향상했으며 데이터 센터의 능력을 최대한 활용할 수 있었습니다. 이후 구글은 동일한 인프라를 Google Cloud Platform으로 확장하여 누구나 자신의 요구에 맞게 사용할 수 있게 하였습니다.
Kubernetes 블로그를 통해 개발 초기부터 참여한 컨트리뷰터의 생각들과 개발 지향점을 잘 알 수 있습니다. 사용자가 오픈 소스를 사용하는 과정에서 어딘가 잘 동작하지 않을 때 개발자 커뮤니티에 전달하는 일련의 개발 피드백 루프가 빠르고, 훌륭한 개발자들이 함께 문제를 풀어갈 수 있다는 두 장점을 활용하고자 오픈 소스로 Kubernetes를 만들고자 한 것입니다. 이후 2017년 10월 Docker가 Kubernetes를 공식 지원하면서 Kubernetes는 DevOps 플랫폼으로 자리를 잡았습니다.
지난번 글 타래에서, DevOps를 서비스가 안정적으로 동작하면서 사용자로부터 받은 여러 피드백을 바탕으로 새로운 기능이나 기능 개선을 신속하게 서비스로 반영하기 위한 방법이나 문화로 정의했습니다. AIOps는 DevOps에 인공지능 서비스를 위한 데이터나 기계학습 모델에 대한 몇 가지 기능이 추가된 정의입니다. DevOps 개발자라고 말한다면 매우 넓은 개념과 함께 기술이 아닌 문화적인 부분까지 포함하므로, 여기서는 기술적인 부분 위주로 계속 이야기해보겠습니다.
저는 DevOps를 효과적으로 구현하여 가능한 한 짧은 개발 시간과 서비스 확장성을 달성하기 위해서는 클라우드나 SaaS 같은 클라우드 플랫폼 서비스(Managed Cloud Service)를 활용하는 것을 추천합니다. 거인(잘 만들어진 클라우드 플랫폼)의 어깨에 타서 고객이 원하는 서비스를 빠르게 공급하는 것이 DevOps를 잘하는 길이라고 개인적으로 믿고 있습니다. 이러한 요구 조건을 달성하려면 AWS, GCP, Azure에서 제공하는 각종 매니지드 서비스를 적절하게 조합해서 비즈니스에 맞는 서비스 아키텍처를 구상해서 실행하는 능력이 필수입니다. 다루는 연산 자원 규모가 크고, 비용 절감이 중요한 판단 사항이며, 클라우드 플랫폼 서비스를 사용하는데 제약 조건이 많은 경우라면 자체적으로 Kubernetes 플랫폼이나 Backend.AI 플랫폼을 활용하는 것도 좋은 선택입니다. DevOps/AIOps 서비스를 안정적으로 동작시키며 동시에 새로운 서비스를 사용자에게 빠르게 전달하려면 아키텍처 설계 단계에서부터 많은 자동화 도구나 서비스를 적절히 적용하여 관리 공수가 늘어나지 않도록 고려해야만 합니다.
Git 브랜치의 적절한 설계와 작업 단위 관리
협업을 통해 소프트웨어 개발을 진행할 때 소스 코드의 변화 기록을 살펴보고 여러 사람의 작업물을 잘 병합하는 것은 필수적인 과정입니다. 여러 버전마다 각각의 브랜치를 따서 관리를 할 경우 사용하는 다양한 소스 코드 형상 관리 도구 중 최근에 가장 많이 사용되는 형상 관리 도구는 git입니다. 브랜치를 어떤 단위로 나누고 어떤 방식으로 합칠 지에 대해서는 다양한 방법이 있습니다. 이런 방법들을 깃 브랜칭 모델(git branching model)이라 하며, 적절한 모델을 선택함으로써 브랜치 관리 작업을 자동화할 수 있습니다. 잘 알려진 깃 브랜칭 모델로는 git-flow, github-flow, gitlab-flow 등이 있습니다. 어떤 모델을 사용하든, 브랜치를 분기하거나 병합하였을 때 시스템이 자동 빌드와 검증 작업을 수행하도록 해야 하며, 이 경우 소스 수정 단위를 작은 단위로 만들어 놓지 않으면 소스 코드 충돌(conflict)이나 디그레이드(degrade) 가능성이 커져서 "리드 타임을 줄인다"는 DevOps의 목적을 달성하기 어렵게 됩니다. 새로운 기능을 추가하거나 기능을 개선할 때 코드가 비대해지는 느낌이 온다면 깃 피쳐 토글(feature toggles) 등을 사용해서 깃 브랜치의 생존 기간을 가능한 한 짧게 유지하는 것이 좋습니다.
인프라 코딩
클라우드의 웹 콘솔에서 인프라 구성을 수동으로 작성하거나 클라우드 서버 인스턴스에 직접 SSH로 로그인하여 라이브러리 등을 설치하는 방식은
- 다른 환경을 만들 때 다시 수동으로 동일한 작업을 해야만 한다.
- 현재의 인프라나 서버의 구성을 파악하는 것이 어렵다.
- 순서 관리가 되어 버린다.
- 라이브러리의 의존성에 따라 복잡도를 해결하는 일명 "배포 장인"이 필요해진다.
와 같은 문제들이 있습니다. 이러한 인프라 관리 과정에서 DevOps/AIOps의 목표인 "리드 타임을 단축한다"를 달성하기 위해서는 인프라의 구성을 기본적으로 모두 코드화해 관리할 필요가 있습니다.
인프라의 코딩 도구로는 Terraform, CloudFormation (AWS), Deployment Manager (GCP) 등을 많이 사용하고 있습니다. 최근에는 특히 Terraform의 인기가 높아서 '인프라로 코드를 관리한다 == Terraform을 사용한다'라고 생각해도 좋을 정도입니다. 하지만 tfstate 파일을 클라우드에서 관리하면 AWS는 S3 버킷을, GCP는 GCS 버킷을 미리 생성해야 하기에, tfstate 파일을 관리하기 위한 버킷 생성 및 삭제 작업마저도 자동화하려면 CloudFormation이나 Deployment Manager를 사용하게 되므로 이것들도 함께 알아 두는 것이 좋습니다.
컨테이너 기반 및 마이크로 서비스
컨테이너 기술은 소프트웨어 스택과 애플리케이션 실행 환경의 독립성을 보장하기 때문에 서비스 배포 환경에서 발생하는 의존성 문제를 해결하고 롤백, 오토스케일 같은 대규모 배포 작업에 확실한 이점이 있습니다. 이러한 장점 덕에 컨테이너 기반 배포 기술도 DevOps에서 매우 광범위하게 사용됩니다. 컨테이너 기반의 클라우드 서비스로는 AWS의 경우 ECS나 Beanstalk가 사용됩니다. 현재의 트렌드를 보았을 때 DevOps에서는 Kubernetes를 익혀두는 것이 DevOps 엔지니어에게는 필수라고 생각해도 좋을 것입니다. 그런데 AIOps는 코드 중심의 DevOps와 다르게 데이터가 중심이 되고 있습니다. 인공지능 학습에는 고집적·고밀도 성능 최적화를 위해 Kubernetes 사용 사례가 점차 줄어들고 있고, 인공지능 서비스 배포에는 DevOps처럼 배포의 편의성과 수평적 확장의 이점을 누리고자 Kubernetes를 많이 사용합니다.
빅 데이터 분산 처리
빅데이터의 분산 처리도 클라우드의 매니지드 서비스를 활용하면 보다 적은 비용으로 효율적으로 서비스를 만들고 운용할 수 있습니다. AWS라면 EMR, GCP라면 Cloud Dataproc 또는 Cloud Dataflow를 통해 빅데이터 분산 처리를 수행할 수 있습니다. 제 생각으로는 DevOps/AIOps의 목적인 "클러스터 관리를 가급적 하고 싶지 않다"라는 관점에서 본다면 GCP의 경우 Cloud Dataproc보다 Cloud Dataflow가 압도적으로 편합니다. Cloud Dataproc은 클러스터 구축 관리를 직접 수행해야 하지만 Cloud Dataflow 는 런타임에 자동으로 클러스터를 구축하고 확장하고 삭제할 수 있기 때문입니다. Dataflow는 Apache Beam의 관리 서비스입니다. AWS라면 EMR 이외의 옵션이 없습니다. AWS Batch도 병렬 분산 처리는 가능하지만 MapReduce 계통의 데이터 처리를 수행하지는 못합니다. EMR을 사용하는 경우 대부분 Spark를 사용하므로 Spark에 관한 지식이 필요합니다. 제 과거의 경험에 따른 개인적인 견해지만 Spark의 학습 비용이 Apache Beam 대비 높습니다.
Batch Process(일괄 처리) 및 작업 흐름(workflow) 제어
일괄 처리도 클라우드 매니지드 서비스의 조합으로 비교적 쉽게 사용할 수 있습니다. AWS에서는 Step Functions와 AWS Batch를 조합해서 사용할 수 있으며, GCP에서는 Cloud Composer를 일반적으로 사용합니다. Step Functions와 AWS Batch는 그리 어렵지 않지만, Cloud Composer (AirFlow)는 초기 학습 비용이 상당히 많이 듭니다. 특히 웹 UI는 최근 웹 트랜드와는 조금은 동떨어진 오래된 느낌입니다. GCP나 AWS에서 AirFlow는 Kubernetes 클러스터로 제공되고 있습니다.
CI/CD 파이프라인 구축
CI/CD 파이프라인 구축은 DevOps/AIOps 개발자의 가장 중요한 작업입니다. 시장에는 여러 가지 CI/CD 도구가 있는데, AWS는 CodeBuild나 CodePipeline, GCP는 Cloud Build라는 CI/CD용 서비스를 제공합니다. 최근 업데이트된 GitHub Actions은 캐시 기능이 크게 향상되었고, 브랜치 필터링에 따라 배치 프로세스를 실행할 수 있도록 개선되어 사용성이 좋아졌습니다.
DevOps에서 MLOps/AIOps로의 확장
데이터를 가공하거나 데이터를 바탕으로 기계 학습 모델을 학습하는 업무는 DevOps나 MLOps/AIOps 개발자들보다는 데이터 분석가 (Data Scientist)가 주로 진행을 하지만, 서로 간의 원활한 대화를 위해서 DevOps/MLOps/AIOps 개발자는 데이터 분석과 학습에 필요한 지식을 어느 정도 이해해야 합니다. 대화에 필요한 기본적인 지식으로는 Jupyter Notebook이나 Jupyter Lab 환경, 학습 모델을 디플로이(Deploy)하는 과정, API 서버 구성에 대한 지식입니다.
ML 워크플로우 제어
데이터 수집, 전처리, 학습 및 모델 배포와 같은 일련의 기계 학습 워크플로우를 제어하는 일은 MLOps/AIOps 개발자의 가장 중요한 작업입니다. ML 워크플로우 제어 분야엔 '이것이 표준이다' 라는 혹은 '보편적으로 이렇게 처리한다는' 등의 절대 반지는 없습니다. AWS라면 Step Functions를 사용합니다. AWS 공식 문서에 AirFlow를 사용한 ML 워크플로우 제어에 대한 글들이 있지만 SageMaker와 AirFlow를 조합하여 사용하기도 합니다. GCP는 Cloud Composer (AirFlow)를 이용하여 ML 워크플로우를 제어합니다. 또한 GKE에서 Kubeflow pipelines를 사용하여 ML 워크플로우를 제어하기도 합니다. 하지만 AirFlow가 DevOps 파이프라인으로 오래 사용되어 왔고, 범용 배포 파이프라인과의 연결에 유리한 점이 있어 실무에서는 AirFlow를 더 선호하는 경향이 있습니다.
AutoML
데이터에 대한 전처리, 학습 알고리즘이나 하이퍼 파라미터의 선정, 학습과 평가와 같은 일련의 작업, 혹은 그 일부를 자동으로 처리해 주는 서비스를 총칭해서 "AutoML"이라고 합니다. AWS의 Amazon Personalize가 AutoML 기반 서비스의 대표자라고 생각합니다. GCP의 경우 AutoML Vision이 유명하며, 작년 Vertex AI라는 새로운 AutoML 서비스를 소개하기도 했습니다. 기계 학습 엔지니어들과 데이터 과학자들에게 다양한 이야기를 들어보면, 지금까지 기계 학습 개발자(Data Scientist)에게 부탁하지 않으면 불가능했던 작업이 향후 AutoML에 의해 점점 자동화되고, 이에 따라 AI 모델을 개발하는 문턱이 낮아지는 "AI의 민주화"를 유도할 가능성이 매우 높아지고 있습니다. 이런 이유로 AutoML은 기계학습 서비스의 리드 타임을 줄이는 것이 목표인 MLOps/AIOps에서 가장 핵심으로 요구되는 기술임에는 분명합니다. 하지만 AutoML은 정말 엄청나게 많은 연산 자원을 사용하므로, 비용 관점에서 보면 우리가 실제로 이러한 이상을 빠르게 목격하는 것은 힘들 수도 있습니다.
맺음말
이 글 시리즈에서는 DevOps/MLOps/AIOps를 정의하였고, Kubernetes의 탄생 이야기와 함께 DevOps/AIOps에서 많이 사용되는 기술들을 소개했습니다. 이러한 기술들을 짧은 시간 내에 모두 마스터하는 것은 정말 어려운 일입니다. AWS, GCP 같은 클라우드 업체뿐만 아니라 거대한 오픈소스 생태계에서 다양한 문제를 해결하기 위한 수없이 많은 프로젝트들이 지금도 공개되고 있습니다.
개인적으로도 MLOps/AIOps 구축과 운영 문제를 어떻게 하면 효과적으로 풀 수 있을지 많이 고민합니다. 적어도 수작업은 최소화하고 자동화해야 하며, 그 과정에서 동시에 서비스 전체의 안정성과 리드 타임을 줄여야 하는데, 데이터가 중심이 되는 파이프라인을 좀 더 효과적으로 만들 수 있을지? 등의 고민이죠. 이미 많은 문제가 있고, 자고 나면 또 다른 문제들을 고객들로부터 받습니다. 래블업에서 저는 이러한 문제들을 클라우드 거인들의 어깨와 그들이 만들어 오픈한 오픈 소스 생태계 위에 서서 계속 해결해 가고 싶습니다.
1 스타트렉: 보이저의 (비공식)히로인입니다.