의존성 지식 그래프

답사를 떠나며 — 세 풍경에 흐르는 하나의 문법

답사는 언제나 눈앞의 풍경 셋을 견주는 데서 시작된다. 다음 세 장면에 무슨 공통점이 있는지 잠시 걸음을 멈추고 생각해 보라.

세 풍경의 공통 주제는 의존성 모델링이다. 발상은 지극히 직관적이다 — 개별 직접 의존 하나하나를 노드 사이의 관계로 그리면, 그것들이 얽히며 추이적(transitive) 의존의 네트워크로 자라난다. 이 의존의 네트워크가 곧 그래프이니, 수많은 의존성 문제가 그래프 패턴 매칭과 그래프 알고리즘으로 풀리는 것은 실로 자연스러운 귀결이라 하겠다.

표에서 그래프로 — 아는 만큼 보이고, 그린 만큼 드러난다

표 11-1은 의존성의 흔한 표현이다. 각 행은 어떤 요소가 다른 요소에 직접 의존함을 적는다. 요소는 네트워크의 라우터일 수도, 공급망의 부품일 수도, 프로젝트의 태스크일 수도 있으나, 그것을 처리하는 방식은 어느 사용 사례에서나 동일하다.

지식 그래프로 옮기면(그림 11-1) 표의 각 행은 방향 있는 관계가 되고, 의존은 명시적이 된다. 같은 질문 — A와 F 사이에 숨은 의존이 있는가 — 이 이제 하찮은 일이 된다. 사람이라면 몇 초면 A와 F 사이에 의존이 없음을 정확히 짚어낼 것이요, 그래프 데이터베이스는 같은 일을 훨씬 빠르게, 훨씬 큰 규모로 해낸다. DEPENDS_ON* 패턴 하나가 임의 깊이의 순회를 명한다. 이 견고함에 더해 패턴 기반 질의는 눈에 띄게 직관적이고 간결하니, 소프트웨어 개발의 맥락에서는 곧 유지보수 비용의 절감을 뜻한다. 가히 개종이라 할 만한 전환인 것이다.

의존의 결 — 세기(强度)와 세월(時效)

의존이 늘 단순한 것은 아니다. 표 11-1처럼 있고 없음만 따지면 족할 때도 있으나, 더 복잡한 문제는 더 많은 데이터를 청한다 — 의존이 얼마나 결정적인지, 얼마나 비싼지, 여러 의존이 어떻게 합쳐지는지. 데이터 모델링의 관점에서 속성 그래프 모델은 관계 타입과 그 안의 속성을 결합해 한정된(qualified) 의존을 표현하는 자연스러운 길을 내어 준다.

그림 11-2의 풍경을 보라. 기업 소유 그래프에서는 한 회사가 다른 회사의 일부를 가진다는 사실만이 아니라 소유의 백분율을 알아야 하고, 용량 활용 그래프에서는 상위 서비스가 하위 서비스 용량의 몇 할을 쓰는지 알아야 한다. OWNS의 part 속성과 CONSUMES의 capacity 속성이 바로 그것을 새긴다. 속성은 절댓값이든 백분율이든 대개 수치이며(하다못해 열거 목록의 값이라도), 여러 값이 합성 가능(composable)해야 한다는 것이 요체다 — 뒤에서 볼 복합 임팩트 전파의 계산과 모델 정합성 검증이 모두 여기에 기대기 때문이다.

의존의 또 다른 결은 시간적 유효성이다. 의존이 언제 유효한지를 새겨 두면, 임의의 일시가 주어졌을 때 그 의존이 활성인지 아닌지 판정할 수 있어야 한다. 그림 11-3이 이 경우인데, 방법은 세기를 새길 때와 똑같다 — 관계 속성에 유효 기간의 시작과 끝을 적는 것이다. 이렇게 역사화된(historized) 의존성 그래프의 질의에는 타임스탬프 매개변수 t가 따라붙어, 시각 t에 활성이던(또는 활성일) 의존만을 탐색하도록 질의를 맥락화한다. 미래를 미리 적어 두지 말라는 법도 없다 — 자원을 미리 예약하는 스케줄링 애플리케이션을 떠올려 보면 될 일이다.

다중 의존의 두 문법 — 가산(加算)과 중복(重複)

그림 11-2와 11-3에서는 의존하는 엔터티가 모두 단 하나의 나가는 관계로 단 하나의 상대에 기댔다. 그러나 세상일이 어디 그러한가. 투자자는 한 자산 유형에의 노출을 줄이려 투자를 여기저기 벌려 놓고, 공급망은 회복력을 위해 운송 경로를 여럿 낸다(그림 11-4). 다중 의존은 오히려 상례인 것이다. 문제는 그 해석이다 — 논리가 더해지는(additive) 것인가, 아니면 하나만 살아 있으면 되는(at least one) 것인가. 이것이 다중 의존의 두 기본 문법, 가산적/집계형과 중복적/보호형이다.

가산적 의존 — 무게만큼 나눠 지는 짐

가산적 의존은 동시에 활성인 것으로 해석되어, 의존이 상대들 위에 분산된다. 요소 A는 요소 B에, B가 A에 기여하는 만큼의 가중치로 의존한다. 그림 11-4 왼편의 포트폴리오가 좋은 본보기다 — 한 자산이 전체의 30%를 차지한다면 포트폴리오는 그 자산에 딱 그만큼 의존하는 것이요, 그 투자에 무슨 일이 생기면(좋은 일이든 궂은 일이든) 포트폴리오에 미치는 영향은 0.3으로 가중된다. 부정적 임팩트라면(의존성 분석의 주된 관심사가 대개 이쪽이다) 전파되는 피해가 그 몫으로 제한된다. 여러 물리 링크의 용량을 본딩한 논리 통신 링크, 여러 물리 드라이브가 받치는 가상 저장 드라이브도 같은 논리를 따른다 — 하나가 무너지면 상위 요소의 용량은 그 기여분만큼 깎이는 것이다. 물론 기여 손실이 쌓이다 보면 상위 요소의 공급이 통째로 무너지는 티핑 포인트가 있을 수도 있다.

중복적 의존 — 예비를 거느린 보호

중복적 의존은 내결함성을 준다. 중복 집합의 상대들 중 어느 한 시점에 활성인 것은 하나뿐이고 나머지는 필요할 때까지 예비로 대기한다. 상대 중 하나라도 살아 있는 한 의존하는 쪽은 영향을 받지 않는다. 그 결과 어떤 실패는 보호 노드(중복 상대를 여럿 거느린 노드)에 흡수되어 더는 전파되지 않는다. 연중무휴로 돌아야 하는 핵심 서버를 다른 서버가 받치는 고가용성 아키텍처가 그러하고, 방송·통신망이 두 지점 사이에 대체 경로를 여럿 두는 것이 그러하다. 공급망도 마찬가지다 — 그림 11-4 오른편에서 싱가포르와 펠릭스토를 잇는 선호 경로는 수에즈 운하를 지나지만, 시베리아 횡단 철도를 타는 대안도 마련되어 있다. 에너지망과 프로젝트 계획 또한 중복 의존의 무대이니, 이런 지식 그래프의 쓸모는 실로 광대하다 하겠다.

임계값의 일반화 — 쿼럼이라는 문지방

더 복잡한 시스템에는 부모가 작동하기 위한 최소 상대 수가 있을 수 있다. 그 문지방을 넘어서면 보장은 무너진다. 원리는 그대로되, 임팩트 계산식이 임의의 임계값을 반영하도록 일반화될 뿐이다.

완전한 기능을 위해 서버 과반의 가용을 요구하는 데이터베이스 클러스터 — 내결함성 갱신을 위한 쿼럼 — 가 좋은 예다. 그림 11-7에서 GraphDB 노드는 서버 1·2·3에 3중으로 의존하고, 서버들은 저마다 하부 가상 머신에 의존한다. 임계값은 GraphDB 노드의 속성에 담겨 프라이머리 셋 중 둘이 살아 있어야 가용임을 새긴다. 그 위로는 두 recommender API가 GraphDB에 직접 의존하여, 하부 의존이 추이적으로 충족될 때 — 즉 데이터베이스와 그 인프라가 가용할 때 — 최종 사용자에게 기능을 제공한다. 여기서 설명한 두 해석은 기초 두 갈래일 뿐, 실제 시스템의 의존성 그래프에서는 둘이 한 그래프 안에 공존하는 것이 예사다.

임팩트 전파를 Cypher로 — 파문(波紋)을 계산하다

이제 두 해석의 다중 의존이 뒤섞인 완전한 의존성 그래프를 분석할 차례다. 데이터셋은 파일 하나 — 매 레코드가 두 요소 사이의 직접 의존과 그 유형('AGG' 가산, 'RED' 중복), 절대 한정치를 적는다(Example 11-4: element / depends_on / mode / abs — "A","B","AGG","80"과 같은 행들). 모든 의존은 ()-[:DEPENDS_ON]->()로 모델링하고, 관계의 mode와 abs 속성이 각각 유형과 가중치를 새긴다.

일반적 임팩트 분석 질의는 이미 알려진 피해 노드의 목록을 입력으로 받아, 의존성 그래프에 근거한 유도 임팩트로 확장된 목록을 산출한다. 가장 기초적인 것은 잠재 피해 노드 집합의 계산 — 순수하게 위상적인 분석으로, 초기 피해 목록에 대해 직·간접 의존(방향 경로)이 존재하는 모든 노드를 돌려준다. 이 임팩트 범위 분석은 상세 분석을 적용할 부분집합을 먼저 추리는 첫걸음으로 흔히 쓰인다 — 중복·가산 의존을 감안하면 그중 전부가 끝내 피해를 입는 것도, 온전히 입는 것도 아니기 때문이다.

그림 11-5와 11-6은 이 계산의 정경을 그린다 — 관측·탐지된 임팩트는 진술(statement)로 그래프에 들어와 돋보기 아이콘으로 표시되고(하드 드라이브가 죽었다, 자산 X의 가치가 50% 떨어졌다, 링크 X에 신호 손실이 있다), 유도된 임팩트는 산술의 근거와 함께 계산기 아이콘으로, 전파 경로는 배경 음영으로 드러난다. 진술에서 유도로, 유도에서 다시 유도로 — 파문이 번지듯 임팩트가 계보를 타고 흐르는 것이다.

그래프의 감정(鑑定) — 네 가지 정합성 검증

좋은 유물은 감정을 견딘다. 의존성 그래프 모델의 중요한 미덕 하나는 정합성 검증이 쉽다는 것이다. 잘 빚어진 의존성 그래프가 지켜야 할 조건은 시나리오마다 다르지만, 그 위에 특수 조건을 쌓아 올릴 토대가 될 만큼 일반적인 검증이 넷 있다.

검증 1 — 순환이 없을 것

엄밀히 말해 의존성 그래프는 방향 비순환 그래프(DAG)다. 순환이 있다는 것은 어떤 구성 요소가 돌고 돌아 결국 저 자신에 의존한다는 뜻이니, 계산의 관점에서 곤란함은 물론이요 지식 그래프나 도메인 자체의 버그를 반영하는 것이다. 다행한 소식은 그래프가 구조를 명시적으로 만든다는 것 — 순환이든 무슨 모양이든, 그 모양을 질의 패턴으로 그리기만 하면 탐지가 된다. 순환이란 같은 노드에서 시작해 같은 노드에서 끝나는 경로이므로, 패턴도 꼭 그렇게 쓴다.

검증 2 — 가산 의존의 합이 기대 총량과 맞을 것

모델이 이상한 상황을 그리지 않도록 하는 검증이다. 주주 지분을 합치면 정확히 100%가 되어야 하고, 20Gbps 회선 다섯을 본딩한 광전송 링크는 100Gbps로 보고되어야 마땅하다. 논리는 단순하다 — 가산 집합의 성분 가중치가 상대값이면 합이 1(100%)이어야 하고(Example 11-13), 절대값이면 모델에 노드별 총량이 속성으로 있을 터이니 그 total과 견주면 된다(Example 11-14).

검증 3 — 소비가 생산을 넘지 않을 것

의존이 수시로 붙고 떨어지는 고도로 동적인 시나리오에서는 현재 총량을 속성으로 유지하는 일이 비싸질 수 있고, 관계의 증감과 용량 갱신이 별개 트랜잭션으로 이루어지면 불일치의 씨앗이 되기도 한다. 용량을 담을 속성이 없다면, 임의 시점의 정합성을 확인할 길은 들어오는 의존과 나가는 의존의 균형을 재는 것뿐이다. Example 11-15가 바로 그 저울이다.

그림 11-8의 그래프에 적용한 결과가 위의 표(Example 11-16)다. percentage_used가 100%를 넘지 않으면 그 요소의 들고 나는 의존은 정합하다. 정합성 판정에 그치지 않고, 이 보고서는 자원 활용을 최적화할 비즈니스 수준의 지침까지 겸하니 일석이조라 하겠다.

검증 4 — 중복 구성이 임계값 정의와 어긋나지 않을 것

임계값이 정의된 중복 의존 시나리오에서 중복 집합의 성원 수는 최소한 임계값과 같아야 한다 — 그러지 않으면 그 의존은 영영 충족될 수 없다. 그림 11-7의 클러스터에서 PrimaryServer가 하나뿐이라면 임계값 2는 정의상 채울 수 없고, GraphDB 노드는 피해를 입으며 그 피해는 의존망을 타고 번질 것이다.

단일 장애점과 근본 원인 — 계보를 거슬러 병소(病巢)를 찾다

앞서 본 전파 규칙들은 알고리즘적으로 결합되어 하나 또는 여러 실패 노드의 상세 임팩트 평가를 산출한다. 이는 종종 이벤트가 그래프로 스트리밍되는 동안 계산되어 실시간 이벤트 보강에 쓰이며, 복잡한 시스템 위 대량 이벤트의 필터링과 우선순위화에 유용하다. IT 인프라에 무슨 일이 생겼을 때, 보호가 되어 있어 낮은 우선순위인지, 핵심 서비스를 때리고 있어 높은 우선순위인지 — 무엇을 먼저 보고 무엇을 무시할 것인가. 의존성 지식 그래프는 계획을 위한 단일 장애점 탐지와 사후 개선을 위한 근본 원인 분석 같은 문제를 풀도록 돕는다.

단일 장애점(SPOF) — 겉치레 내결함성의 정체

단일 장애점이란 시스템 전체가 기대는 단 하나의 요소로, 그것이 무너지면 시스템이 무너진다. 원리는 의존성 그래프의 부분들로 일반화된다. 그림 11-7을 다시 보라 — Primary2와 Primary3 두 노드가 같은 CloudVM 노드(VM2)에 직접 의존하고 있으니, GraphDB(recommender DB)는 실은 VM2에 강하게 의존하는 셈이다. 실생활에서 흔한 실수가 바로 이것이다. 내결함성 소프트웨어의 인스턴스 여럿을 같은 하드웨어 위에 배치하면 하드웨어 장애 한 번에 대형 사고를 맞는다. 가상 머신만의 얘기가 아니다 — 네트워크, 냉각, 전력, 심지어 데이터센터 전체까지 모든 인프라가 해당된다. 말하자면 기저의 SPOF 의존 때문에 내결함성이 겉치레에 그치는 것이다. 시스템을 설계할 때, 투자를 집행할 때 이런 정경은 곧잘 눈에 띄지 않고 지나가지만(실제로 자주 그런다), 지식 그래프를 쓰면 지나칠 수가 없다.

위상적으로 SPOF는 그래프의 또 하나의 패턴에 불과하다. 그러니 Cypher 패턴으로 그려서 의존성 그래프 안의 모든 사례를 표면화하면 된다 — 주어진 요소에서 출발한 여러 가변 길이 의존 사슬(경로)이 어느 한 요소 spof로 수렴하는 모양이다.

근본 원인 분석 — 전파의 역문제

근본 원인 분석은 임팩트 전파의 역문제다. 피해의 모음이 주어졌을 때, 그것들이 모두 단 하나의 요소에 의존하는지를 캐고, 그렇다면 그 공통 조상이 관측된 피해들의 근본 원인이라는 결론에 이른다. 이 분석이 도드라지는 무대가 서비스 어슈어런스 시스템이다 — 복잡한 시스템(통신망, 공급망, IT 인프라…)을 감시하며 구성 요소들로부터 알람·이벤트·지표를 끊임없이 받는데, 어떤 오작동은 요소 고유의 것이지만 어떤 것은 의존하는 요소의 실패가 번져 온 것이다. 감시 시스템은 알람의 홍수를 고신호/저잡음으로 줄여 개입을 정확히 이끌어야 하니, 유도된 알람들을 근본 원인으로 묶어 근본 원인만 제시하는 것이 한 방법이다 — 이른바 알람 상관(alarm correlation), 이벤트 상관이며, 알람의 직·간접 의존을 캐는 일임을 이제는 직감할 것이다.

첫걸음은 후보의 식별이다. 피해 노드의 모음(증상)이 주어지면, 그래프의 의존을 탐사해 증상 집합의 부분 집합을 설명할 수 있는 리프 노드 — 남에게 의존하지 않아 근본 원인일 수 있는 노드들 — 를 찾는다. 이 탐사는 서로소 집단들을 즉시 드러낸다 — 동시에 일어났으되 서로 무관한 결함들이 따로따로 묶이는 것이다.

판독은 이러하다. I·J·K의 정밀도는 매우 비슷하다 — 셋 다 탐지된 증상의 상당 부분을 일으켰을 수 있다는 뜻이다. 그러나 J가 근본 원인이었다면 J에 간접 의존하는 노드가 훨씬 많으니 증상 목록에 실패 노드가 훨씬 많이 올라왔어야 한다. 그것들이 입력에 없다는 사실이 J의 혐의를 던다. K도 마찬가지다. 오직 I만이 정밀도와 재현율의 균형 잡힌 조합을 갖추었고, 그것이 F-점수에 새겨진 것이다. 물론 이 접근은 관측된 증상의 품질에 기댄다 — 목록이 온전할수록 결과가 정확하다. 현실에서 환경의 현재 상태를 빠짐없이 아는 일은 드물기에, 이런 분석의 결과는 단 하나의 답이 아니라 가장 유력한 후보들의 목록이 되기 마련이다. 그러나 그 결과를 시간이나 여타 도메인 특화 휴리스틱과 결합하면 올바른 진단의 확률은 얼마든지 높일 수 있다.

답사를 마치며 — Vanguard의 400만 행, 그리고 계보의 교훈

의존성을 포착하고 활용하는 것은 흔하고도 중요한 능력이다. 의존성을 표현하고 처리하는 자연스러운 길은 의존성 중심 지식 그래프를 쓰는 것이니, 그 표현력과 직관성과 효율 때문이다. 이 장의 아이디어들은 임팩트 분석과 근본 원인 분석 같은 복잡한 문제를 풀 의존성 중심 지식 그래프 구축의 기본 원리를 보여 주었고, 예제들은 이 그래프의 폭넓은 적용 가능성을 일러 주었다 — 여기서부터는 이 기법들을 자신의 필요에 맞게 적용하고 확장하면 되는 것이다. 답사의 끝에서 새삼 확인하는 진실은 하나다. 계보는 그려야 보이고, 보여야 지킬 수 있다.