안녕하세요. 얼마 전에 Lynq라는 Kubernetes operator를 소개드린 적이 있는데요,
그 이후로 계속 고민하다가 이게 단순히 하나의 도구가 아니라 새로운 운영 패러다임이 될 수 있지 않을까 하는 생각이 들었습니다.
그래서 이번에는 도구보다는 개념과 패러다임에 대해 얘기해보고 싶어서 글을 씁니다.
용어 정립: RecordOps / Infrastructure as Data
우선 서연님의 아이디어를 채택하여 이름부터 확정했습니다:
-
Infrastructure as Data (IaD): 패러다임 - 데이터로 인프라를 정의하는 방식
-
RecordOps: 운영 패턴 - 데이터베이스 레코드로 인프라를 운영하는 방법
Infrastructure as Code(IaC)가 "코드로 인프라를 정의"한다면,
Infrastructure as Data는 "데이터로 인프라를 정의"하는 겁니다.
Infrastructure as Data는 새로운 개념이 아니었습니다
나중에 찾아보니 Infrastructure as Data라는 개념이 2013년부터 있었더라고요.
Ansible을 만든 Michael DeHaan이 2013년 블로그 글에서 이렇게 말했습니다:
“Infrastructure is best modeled not as code, nor in a GUI, but as a text-based, middle-ground, data-driven policy.”
그리고 이걸 Infrastructure as Data라고 불렀죠. (출처: Dzero Labs, 2021)
현재는 주로 Crossplane이나 ACK처럼 Kubernetes Custom Resource로 클라우드 리소스를 관리하는 걸 Infrastructure as Data라고 부르는 것 같습니다.
제 접근은 이렇습니다.
저는 Kubernetes CR이 아니라 데이터베이스 레코드를 직접 인프라 스펙으로 쓰는 걸 시도했습니다.
(그저 다른 관점으로 접근한것일수도 있고, 더 발전시킨 형태일수 있지만 지금은 판단이 어렵네요)
왜냐면 멀티 테넌트 SaaS에서는:
-
고객 정보가 이미 DB에 있음
-
고객마다 똑같은 패턴의 인프라
-
하루에도 여러 번 프로비저닝/삭제
-
인프라 파라미터(도메인, 플랜, 리전)가 이미 DB 컬럼으로 있음
Kubernetes CR로 한 번 더 옮겨 적는 것도 중복처럼 느껴지더라고요. (저의 경우..)
RecordOps 예시
테이블:
CREATE TABLE tenants (
tenant_id VARCHAR(50) PRIMARY KEY,
domain VARCHAR(255) NOT NULL,
plan VARCHAR(20),
active BOOLEAN DEFAULT TRUE,
replicas INT DEFAULT 2
);
이 스키마가 곧 인프라 API입니다.
이후 템플릿을 하나 정의하면 됩니다. “활성화된 각 테넌트마다 namespace, deployment, service, ingress 만들어라” 와 같이요.
템플릿을 정의하고 나면 다음과 같이 할 수 있습니다:
-- 고객 추가
INSERT INTO tenants VALUES ('acme-corp', 'acme.example.com', 'enterprise', true, 5);
-- → 30초 후 인프라 뜸
-- 스케일 업
UPDATE tenants SET replicas = 10 WHERE tenant_id = 'acme-corp';
-- 블루-그린 배포
UPDATE deployments SET active_version = 'green';
-- 고객 삭제
DELETE FROM tenants WHERE tenant_id = 'acme-corp';
-- → 모든 리소스 자동 정리
기존 IaD와의 차이
Crossplane (기존 IaD):
애플리케이션 데이터(혹은 누군가의 구두 요청) => [수동 변환] => Kubernetes CR (YAML) => 인프라
RecordOps:
애플리케이션 데이터 => 직접 읽음 => 인프라
개발자에게 직접 요청하지 않아도 되도록 하면서, 중간 단계를 없앨수 있습니다.
장점
-
애플리케이션과 인프라가 하나의 DB 트랜잭션으로
-
운영이 평소 쓰던 SQL로 됨 (kubectl 필요 없음)
-
환경 복제 = DB 행 복제
-
DB 백업 = 인프라 백업
단점
-
DB 죽으면 새 인프라 못 만듦 (기존 인프라는 영향 없음)
-
스키마 마이그레이션이 인프라에 영향
-
SQL 인젝션 = 인프라 인젝션 (보안 중요)
언제 적합할까?
멀티 테넌트 SaaS, 반복 패턴, 빈번한 프로비저닝
클러스터 설정, AWS/GCP 리소스, 수동 승인 필요한 경우
개인적으로는 결국 엔터프라이즈 환경에서는 IaC + GitOps + RecordOps를 함께 쓰는 게 바람직한 자동화 환경이 될것으로 확신하고 있습니다.
마지막으로, 의견이 궁금합니다.
1. Infrastructure as Data의 또 다른 구현으로 봐도 될까요?
기존 IaD는 Kubernetes CR이나 Playbook을 씁니다. RecordOps는 DB 레코드를 씁니다.
이게 IaD의 변형일까요, 아니면 아예 다른 패턴일까요?
2. 비슷한 문제 겪어보신 분?
멀티 테넌트/고객별 인프라 관리하실 때 어떻게 하시나요? Git + CI/CD? Terraform? 어떤 어려움이 있으셨나요?
3. 이 접근의 문제점이 보이시나요?
Infrastructure as Data 자체가 2013년부터 있었는데, 왜 DB 레코드를 직접 쓰는 접근은 (제가 찾아본 한) 없었을까요?
Dzero Labs 글에서 "Infrastructure is static"이라고 했는데, DB 레코드처럼 dynamic한 데이터와 엮는 게 오히려 안티패턴일 수도 있을까요?
긴 글 읽어주셔서 감사합니다!
참고 자료:
