Apollo: 여러 환경의 소프트웨어 배포와 운영

Apollo는 여러 위치와 인프라에서 실행되는 소프트웨어를 배포하고 관리하는 플랫폼입니다. 클라우드, 온프레미스와 네트워크가 분리된 환경의 소프트웨어를 업그레이드하고, 상태를 관측하며, 허용된 조건에 따라 구성을 변경합니다.

Foundry와 AIP가 데이터와 업무 기능을 제공하는 계층이라면, Apollo는 소프트웨어가 실제로 배치된 환경의 변경을 관리합니다. Foundry 안에서 데이터셋이나 온톨로지 리소스를 제품으로 설치하는 작업과 Apollo가 소프트웨어 서비스의 버전을 바꾸는 작업은 관리 대상이 다릅니다.

배포 대상이 많아질 때의 문제

소프트웨어를 한 데이터센터에서만 운영할 때에도 배포와 복구 절차가 필요합니다. 여러 데이터센터로 확장하면 환경별 구성과 의존 관계 때문에 업그레이드를 조정하기가 더 어려워집니다. 변경을 한 번에 검토하기 어려운 환경에서는 배포 주기가 길어지기도 합니다.

SaaS와 CI/CD는 소프트웨어 변경을 자주 제공하는 방식을 확대했습니다. 조직은 공개 클라우드, 사설 클라우드, 혼합 환경을 함께 사용하고, 데이터가 저장되거나 처리되는 위치에 관한 요구사항도 충족해야 합니다. GDPR 같은 데이터 보호 규정, 주권 클라우드와 FedRAMP 같은 인가 체계가 환경 선택과 운영 조건에 영향을 줄 수 있습니다.

환경이 분산될수록 새 기능과 보안 수정 사항을 적시에 제공하려면 환경별 제약을 확인하고, 변경 가능 시점과 승인 책임을 조정해야 합니다. 개발팀이 매번 모든 환경의 세부 구성을 직접 알아야 하는 방식은 환경이 늘거나 바뀔 때 관리 부담이 커집니다.

Apollo는 이러한 배포 조건을 설정으로 관리하고, 실제 상태를 관측하면서 변경을 조정합니다. 개발팀은 배포할 소프트웨어와 필요한 제약을 제공하고, 운영팀은 자신의 환경에서 허용할 조건을 정합니다.

환경별 조건을 반영한 자율 배포

자율 배포(autonomous deployment)는 구성된 제약과 승인 정책에 따라 소프트웨어 변경을 조정하는 방식입니다. 사람이 모든 환경의 업그레이드를 매번 수동으로 수행하는 대신, Apollo가 실행 가능한 변경을 판단하고 배포 환경에 전달합니다.

제품 개발자는 서비스 간 의존 관계나 지원하는 데이터베이스 스키마 버전 등의 조건을 정할 수 있습니다. 환경 운영자는 언제 변경할 수 있는지 같은 환경별 조건을 정합니다. Apollo는 변경할 때 이 조건들을 함께 평가합니다.

연결된 환경과 연결이 끊기는 환경, 망분리 환경을 함께 운영하는 경우에도 관리 설정과 실제 상태를 구분하여 다룹니다. 각 환경이 얼마나 지속적으로 연결될 수 있는지에 따라 상태 보고와 변경 전달 방식이 달라질 수 있습니다.

릴리스 채널을 구독하는 배포 방식

환경마다 정확한 버전을 개발팀이 직접 지정하여 밀어 넣는 방식에서는 개발팀이 각 환경의 안정성 요구와 제약을 모두 알아야 합니다. Apollo에서는 제품팀이 릴리스 채널 간 승격 기준을 정하고, 환경 운영자가 필요한 채널을 구독하는 방식으로 책임을 나눌 수 있습니다.

가상의 조직이 RELEASE, CANARY, STABLE이라는 채널을 사용한다고 가정하겠습니다. 제품팀은 새 릴리스가 어떤 조건을 통과하면 다음 채널로 이동할지 정합니다. 운영자는 기능을 빨리 받을 환경과 안정성을 우선하는 환경에 서로 다른 채널을 선택할 수 있습니다. 이 채널 이름들은 예시이며 Apollo의 기본 채널 목록과 동일하다고 가정하지 않습니다.

릴리스가 다음 채널로 승격되고 환경이 그 채널을 구독하고 있더라도, 실제 환경 변경에는 적용되는 제약 조건이 함께 평가됩니다.

변경 승인과 추적

Apollo는 조직의 SAML 신원 제공자와 연결하고, 기존 그룹을 활용하여 승인 과정과 승인자를 구성할 수 있습니다. 변경 요청을 추적하면 누가 어떤 변경을 요청하고 승인했는지 조사할 수 있습니다.

이 기능은 보안과 인가 요구가 높은 환경에서 변경을 관리하는 데 사용됩니다. FedRAMP, IL5, IL6 같은 기준이 적용되는 운영에서는 승인, 접근과 추적 요구사항을 실제 환경의 정책에 맞춰 구성해야 합니다. 소프트웨어를 배포할 수 있다는 사실만으로 조직의 모든 인증 또는 규제 요구사항이 자동으로 충족되는 것은 아닙니다.

개발팀과 운영팀의 역할

이 구분을 통해 개발자는 여러 인프라의 세부 실행 절차를 각각 다시 구현하는 부담을 줄일 수 있습니다. 운영자는 개발자에게 환경의 직접 접근을 항상 제공하지 않고도 자신의 관리 조건을 적용할 수 있습니다.

관측 도구와 연결하기

소프트웨어 운영에서는 오류를 발견한 뒤 적절한 담당자에게 알리고, 원인을 조사하여 수정할 수 있어야 합니다. Apollo는 소프트웨어와 함께 관측 구성을 제공하고 기존 관측 도구와 연결하는 방식을 지원합니다.

Datadog이나 Prometheus 같은 도구와 호환되는 모니터를 소프트웨어에 묶어 제공할 수 있습니다. 배포와 관측을 함께 관리하면 특정 릴리스의 상태와 운영에서 확인한 문제를 연결하기 쉬워집니다.

구체적인 구성 요소와 데이터의 이동은 Apollo 구성, 실제 변경이 결정되고 실행되는 과정은 Apollo의 변경 처리에서 설명합니다.