스택 그리기 중단: AWS에서 Drupal을 그래프로 보기

발행: 1시간 전 (2026년 1월 18일 오전 08:01 GMT+9)

14 min read

Source: Dev.to

당신이 지금까지 그려온 모든 아키텍처 다이어그램은 그래프입니다.
상자는 노드이고, 화살표는 엣지입니다. 하지만 대부분의 팀은 이러한 다이어그램을 정적인 문서로만 여기고, 수학적으로 추론할 수 있는 작동 모델로 활용하지 않습니다.

Drupal과 AWS가 런타임에서 실제로 어떻게 동작하는지에 그래프 이론을 적용하기 시작하면, 지연 시간 예산, 장애 영향 범위, 리팩터링 우선순위와 같은 어려운 문제들이 이미 해결 방법을 알고 있는 그래프 문제로 변환됩니다.

당신의 플랫폼은 그래프이다

그래프는 단순히 노드(정점)와 그들을 연결하는 엣지(간선)들의 집합입니다. Drupal‑on‑AWS 플랫폼에서는 다음과 같이 구성됩니다:

Drupal 노드

콘텐츠 타입
구성 엔티티
컨테이너 내 서비스
이벤트 구독자
라우트
캐시

AWS 노드

VPC, 서브넷, 보안 그룹, NACL
ALB, ECS 작업, Lambda 함수
RDS 클러스터, ElastiCache, S3 버킷, SQS 큐
외부 SaaS (Auth0, Salesforce, …)

엣지

“API 호출”
“큐에 게시”
“보안 그룹에 의해 허용”
“리전으로 복제”
“대시보드에 피드”

이러한 프레임을 받아들인다면, “이 아키텍처가 깔끔한가?” 같은 모호한 질문을 더 이상 하지 않게 되고, “이 AWS 프리미티브에서 손상된 SLO까지의 가장 짧은 실패 경로는 무엇인가?” 와 같이 구체적인 질문을 하게 됩니다.

Source: …

Drupal을 의존성 그래프로

Drupal은 일반적으로 콘텐츠 타입, 뷰, 모듈 관점에서 설명됩니다. 실제로는 여러 겹치는 방향 그래프처럼 동작합니다.

구성 그래프

엔티티 타입, 번들, 필드, 필드 포매터, 뷰, 그리고 접근 규칙이 의존성 그래프를 형성합니다. 필드‑스토리지 정의를 변경하면 디스플레이, 뷰, REST 리소스, 통합을 통해 연쇄적으로 영향을 미칠 수 있습니다.

런타임 호출 그래프

Symfony 서비스 컨테이너, 이벤트 구독자, 미들웨어 스택이 호출 그래프를 정의합니다. 모든 HTTP 요청은 라우팅, 접근 검사, 엔티티 로딩, 렌더링, 캐싱 노드를 순차적으로 거치는 특정 경로를 따라 이 그래프를 탐색합니다.

권한 그래프

역할, 권한, 라우트‑접근 콜백이 또 다른 그래프를 형성합니다. “누가 무엇에 접근할 수 있는가” 를 방향성 엣지로 모델링하면, 낮은 권한 노드와 높은 권한 노드 사이에 예상치 못하게 짧은 경로가 존재하는 특권 상승 위험을 시각화할 수 있습니다.

단일 익명 페이지 뷰는 실제로 세 가지 하위 그래프를 동시에 탐색하는 과정입니다. 이 과정을 이해하는 것이 최적화의 첫 번째 단계입니다.

AWS를 인프라스트럭처 그래프로

AWS 아키텍처는 이미 그래프로 그려져 있습니다; 그래프 이론은 그 수학을 명시적으로 보여줄 뿐입니다.

네트워크‑토폴로지 그래프

VPC, 서브넷, 라우트 테이블, 보안 그룹 및 NACL은 도달 가능성 그래프를 형성합니다. 두 노드는 이 그래프를 통해 유효한 경로가 있을 때만 통신할 수 있습니다—경로가 없으면 패킷도 없습니다.

데이터‑플로우 그래프

S3, Kinesis, SQS, SNS, Lambda 및 분석 서비스는 데이터 변환의 방향성 비순환 그래프(DAG)를 구성합니다. 여러분의 ETL 파이프라인, 이벤트‑드리븐 워크플로우, 그리고 관측 스택은 모두 DAG이며, 이를 그렇게 그렸든 아니든 관계없습니다.

서비스‑종속성 그래프

ECS 서비스, Lambda 함수, RDS, ElastiCache 및 외부 API는 런타임 종속성 그래프를 형성합니다. 트레이스와 플로우 로그를 통해 오래된 문서에 의존하지 않고 프로덕션 트래픽으로부터 이 그래프를 추론할 수 있습니다.

Source: …

사고를 날카롭게 하는 네 가지 그래프 개념

경로와 지연
사용자가 체감하는 지연은 브라우저에서 데이터까지 그리고 다시 돌아오는 최단 경로상의 에지 가중치들의 가중합이다. CDN, WAF, ALB, PHP‑FPM, Redis, RDS—각 홉마다 가중치가 추가된다.
지연을 줄이는 방법은 경로에서 노드를 제거하는 것(예: 엣지 캐시에서 제공) 또는 에지 가중치를 낮추는 것(예: 커넥션 풀링, 읽기 복제본)이다. 모든 성능 최적화를 경로 단축 혹은 가중치 감소 작업으로 프레이밍하라.
최소 컷과 복원력
최소 컷은 그래프를 분리시키는 가장 작은 노드 혹은 에지 집합이다. 인프라 관점에서는 단일 장애 지점(SPOF)과 같다: 단일 RDS 라이터, 공유 Redis 클러스터, 모든 것이 의존하는 내부 인증 서비스 등.
고가용성 설계는 최소 컷을 크고 비용이 많이 들게 만드는 예술이다. Multi‑AZ RDS, 여러 ALB 뒤의 무상태 Drupal, 지역 장애 조치(failover) 등은 장애가 발생해야 하는 컷의 크기를 늘린다.
중심성 및 핫스팟
Betweenness centrality는 노드가 다른 노드들 사이의 최단 경로에 얼마나 자주 등장하는지를 측정한다. 중심성이 높은 노드는 병목점이다: 모든 요청이 통과하는 API 게이트웨이, 단일 모놀리식 “통합” 모듈, 여러 소비자를 공급하는 단일 SQS 큐 등.
관측성, 속도 제한(rate‑limiting), 용량 계획을 중심성이 높은 노드에 집중하라. 이들의 장애는 불균형적인 파급 효과를 가진다. 중심성을 없앨 수 없다면 최소한 이를 충분히 계측하라.
강하게 연결된 구성 요소 (SCC)
SCC는 방향성 에지를 통해 모든 노드가 서로 도달 가능한 최대 서브그래프이다. Drupal‑AWS 시스템에서는 순환 의존성 주위에 SCC가 자주 나타난다—예를 들어, 큐를 트리거하는 Lambda가 다시 동일한 Lambda를 호출하거나, Drupal 서비스가 서로 재귀적으로 호출되는 경우.
SCC를 식별하면 해로운 순환을 끊고, 장애 전파를 단순화하며, 명확한 소유 경계를 설계할 수 있다. 그래프 분석 라이브러리나 트레이싱 플랫폼 같은 도구를 사용하면 SCC를 자동으로 찾아낼 수 있다.

요약

모든 아키텍처 다이어그램을 생생한 그래프로 다루라. 노드와 에지, 그리고 이를 지배하는 수학적 특성을 매핑함으로써 올바른 질문을 제기하고, 숨겨진 위험을 포착하며, 체계적인 개선을 추진할 수 있는 정확한 언어를 얻게 된다.

구성 요소와 결합

**강하게 연결된 구성 요소 (SCC)**는 모든 노드가 서로 도달할 수 있는 노드의 부분 집합입니다. 실제로 SCC는 긴밀하게 결합된 하위 시스템을 나타냅니다: Drupal과 특정 내부 API, 큐, 그리고 서로 의존하는 Lambda 등.

SCC 내의 하나의 노드를 변경하면 다른 노드가 깨질 위험이 있습니다.
SCC를 리팩터링 전에 식별하고, 암시적인 런타임 의존성 대신 명시적이고 버전이 지정된 계약—API, 스키마, 이벤트—을 도입하여 이를 분리하세요.

그래프 사고를 일상에 적용하기

아키텍처 리뷰

주관적인 “이게 깔끔한가?” 대신 다음을 물어보세요:

핵심 사용자 여정에서 가장 긴 경로는 무엇인가요?
사용자와 SLO 사이의 최소 컷은 무엇인가요?
어떤 노드가 가장 높은 중심성을 가지고 있나요?

사고 분석

실패를 그래프 탐색으로 재구성하세요:

어떤 엣지가 끊어졌나요?
어떤 대체 경로가 존재했나요(또는 없었나요)?
어떤 노드의 중심성이 영향을 확대했나요?

현대화 로드맵

그래프 메트릭을 기준으로 리팩터 우선순위를 정하세요:

먼저 가장 높은 중심성을 가진 Drupal 모듈을 분해하세요.
단일 대규모 통합 엣지를 메시지 기반 서브그래프로 교체하세요.
가장 큰 SCC를 독립적인 배포 가능한 유닛으로 분리하세요.

어디서 시작할까

그래프 데이터베이스가 없어도 그래프 사고방식의 혜택을 누릴 수 있습니다. 다음 간단한 연습부터 시작해 보세요:

핵심 사용자 여정을 선택하세요 (예: 인증된 페이지 로드, 결제, 혹은 폼 제출).
이를 방향 그래프로 스케치하세요: 모든 서비스, 캐시, 데이터베이스, 외부 API가 노드이며, 모든 호출이나 의존성이 엣지(연결)입니다.
엣지에 레이턴시(p50, p99)와 가용성(과거 가동 시간)을 라벨링하세요.
최소 컷(minimum cut)과 가장 높은 중심성 노드를 식별하세요.
그 결과를 활용하여 다음 성능 또는 신뢰성 개선 작업의 우선순위를 정하세요.

Drupal‑on‑AWS 플랫폼을 그래프로 바라보면, 의사결정이 더 명확해집니다. 복잡성을 추측하는 것을 멈추고 실제 존재하는 구조 위에서 운영을 시작하게 됩니다.