인공지능 서비스를 지탱하는 기술(AIOps) : 인공지능 서비스를 실현하는 기술

인공지능을 실제 서비스화하는 데까지 수많은 고민과 노력이 필요합니다. 그리고 서비스화된 인공지능이 시대적으로 도태되지 않도록 지탱하는 방법론의 집약체를 바로 AIOps로 볼 수 있습니다.

글ㆍ사진 박찬성(프로그래머)

2022.06.07

작게

크게

책 쓰는 프로그래머 박찬성이 IT 트렌드를 알려줍니다.
어렵게만 느껴졌던 IT 이슈를 쉽게 풀어주는 본 칼럼은 매달 연재됩니다.

이 칼럼은 세 편으로 구성된 시리즈 중 세 번째로, “인공지능과 테이터의 관계”를 다룬 첫 번째 칼럼과 “인공지능 서비스 실현의 현실"을 다룬 두 번째 칼럼은 여기에서 확인해 보기 바랍니다. 이번 마지막 칼럼은 AIOps를 실현하는 데 쓰이는 실제 기술을 살펴봅니다.

인공지능 서비스를 실현하는 기술

AIOps를 실제로 실현하는 데 필요한 기술에는 어떤 것들이 있을까요? 기본적으로 하드웨어 인프라가 구성되어 있어야 합니다. 그리고 요구된 작업에 알맞은 자원을 할당할 수 있어야 합니다. 현대의 AIOps에서 이 기능은 다양한 종류별 컴퓨팅 자원들을 그룹으로 관리하고, 작업에 알맞은 유휴 자원을 할당하는 쿠버네티스Kubernetes에 의해 이루어집니다.

머신러닝 모델을 만들어 배포하는 일련의 과정은 서로 상관관계를 가지기 때문에, 지금의 작업이 나중의 작업에 영향을 미치게 됩니다. 가령 데이터를 입력받으면, 이어지는 작업에서는 해당 데이터를 검증하는 식입니다. 순수 쿠버네티스로는 이러한 상관관계선 상에 놓인 작업을 알맞게 처리할 수 없기 때문에, 각 의존성을 고려하여 프로그램을 작성해야만 합니다. 다행히 쿠브플로Kubeflow라는 프레임워크는 이를 일반화된 방식으로, 다양한 상황에 범용적으로 작업을 정의하고 처리할 수 있는 솔루션을 제공합니다. 이런 일련의 작업 처리 공정을 흔히 머신러닝 파이프라인pipeline이라고 합니다.

머신러닝 워크플로를 구성하는 일련의 작업이 처리되는 과정

이제 쿠브플로로 작업과 작업간 의존성을 정의해 작업 처리를 요청하면 됩니다. 한편 의존성은 쿠브플로에 의해 관리되지만, 작업을 처리하는 로직 자체는 개발자가 직접 개발해야만 합니다. 하지만 데이터 입력, 모델의 학습, 학습된 모델의 배포까지 산업 표준적인 방식이 존재하고, 이 방식은 다른 상황에서도 크게 바뀌지 않습니다. 따라서 이를 한 단계 추상화해 미리 구현한 라이브러리, 그리고 이를 토대로 좀 더 고차원적인 라이브러리를 구현할 수 있는 고수준 프레임워크도 있으면 개발을 가속화할 수 있습니다. 그리고 이 역할을 담당하는 것이 바로 텐서플로 익스텐디드TensorFlow Extended(TFX) 같은 기술입니다.

한편 경우에 따라 다량의 CPU 또는 GPU가 협업해 병렬로 처리해야만 하는 작업도 있지만, 기본 쿠브플로는 병렬처리를 지원하지 않습니다. 대신 병렬 처리에 특화된 별도의 인프라로 해당 작업을 위임할 수 있습니다. 이러한 구조는 구글 클라우드 플랫폼이 머신러닝 파이프라인의 처리, 대규모 데이터 처리, 대규모 모델 학습을 분리해둔 방식을 통해 엿볼 수 있습니다. 또한 파이프라인을 구성하는 각 작업은 그 결과물을 뱉어내는 데, AIOps 에서는 이런 결과물들이 나중에 재사용될 수 있는 형식으로 관리하는 것 또한 매우 중요합니다. 데이터의 가공과 모델의 학습에 들어가는 비용은 천문학적으로 높기 때문에, 입력이 동일한 경우 이미 이전에 얻은 결과물을 그대로 활용하여 비용을 절감하고, 일관성 있고 믿을 수 있는 결과물을 토대로 다양한 AI 를 쌓아올릴 수 있기 때문입니다.

이런 결과물을 보통 아티팩트Artifact라고 하며, 특히 데이터와 모델은 버전 관리 또한 함께 되어야 하는 기술적 어려움이 존재합니다. 모델의 버전 관리가 특히 중요한 이유는 모델의 행동을 사람이 예측하기가 어렵기 때문입니다. 만약 모델이 예상한 것과는 다른 방식으로 작동하여, 차별적인 행동을 보이는 경우, 이전 모델로 돌아가거나 극단적인 경우 AI가 없는 단순한 구현체로 잠시 회귀해야 할 필요도 있습니다.

배포된 머신러닝 모델에 사용자가 접근하는 기본 구조도

배포도 중요한 문제입니다. 모델의 규모에 따라서, 모델이 예측을 도출하는 데까지 드는 시간에 많은 차이가 있을 수 있습니다. CPU만으로 감당이 어렵다면 GPU까지도 고려해야만 하죠. 하지만 GPU 사용에는 많은 비용이 발생할 수밖에 없기 때문에, 한 서버 내 여러 모델들이 효율적으로 GPU 자원을 활용할 수 있는 스케줄링 방법도 고려되어야 합니다. 이러한 모델 추론에 걸리는 시간을 최소화하기 위해 인-메모리 키/객체 저장소인 레디스Redis 같은 기술을 사용자(클라이언트)와 모델 추론용 서버 중간에 두어 예전에 계산된 결과를 캐싱하는 방법도 쓰이곤 합니다.

모델이 갱신되어야 하는 두 가지 일반적인 경우

지금까지 알아본 내용은 주어진 데이터에 대해 모델을 학습시키고, 그 과정/실험에 엮인 다양한 작업의 결과물을 관리하고, 배포까지 이어지는 전형적인 머신러닝 파이프라인에 대한 것이었습니다. 하지만 이야기는 여기서 끝나지 않습니다. 이제 모델이 “언제” 학습되어야 하는지에 대한 시점을 기술적으로 녹여내는 과정이 남아있습니다. 모델은 “데이터에 유의미한 변화가 있을 때", 그리고 기존보다 더 뛰어난 최신State Of The Art(SOTA) 데이터 전처리 및 모델링 기법이 등장해서 코드가 교체되는 경우 다시 학습되어야만 합니다. 따라서 이러한 사건을 감지하는 이벤트 시스템을 통합시켜야 하며, 데이터의 변화를 감지하기 위한 기술, 통합된 신규 코드를 검증한 뒤 머신러닝 파이프라인을 일련의 작업을 처리하는 CI/CD 파이프라인과 같은 기법도 함께 고려되어야 합니다.

마치며

인공지능을 실제 서비스화하는 데까지 수많은 고민과 노력이 필요합니다. 그리고 서비스화된 인공지능이 시대적으로 도태되지 않도록 지탱하는 방법론의 집약체를 바로 AIOps로 볼 수 있습니다. AIOps의 각 구성요소를 실현하는 다양한 오픈소스 프로젝트 또는 서비스가 존재합니다. 다만 이들을 하나씩 모두 들여다보고 각 기술 간의 상호 작용, 의존성 관리 등을 생각하다 보면 실제 AIOps를 시작해 보기도 전에 나가떨어지는 경우가 부지기수입니다. 따라서 우선 각 구성 요소 서비스를 모두 한 군데서 제공하고, 내부 인프라를 대신 관리해 주는 클라우드(AWS, GCP, Azure) 서비스와 머신러닝 파이프라인을 손쉽게 작성할 수 있는 TFX와 같은 기술로 시작하기를 권장하고 싶습니다. 원하는 시나리오에 대응하는 AIOps를 클라우드 기반으로 구축한 다음, 이후 운영 과정에서 비용과 커스터마이징이 필요한 부분 등을 고려하여 하나씩 클라우드에서 자체 솔루션으로 교체해 나가는 방식이 바람직하다고 생각합니다.