Commonwealth Bank Australia, 지식 그래프로 네트워크 관측 가능성 확보

편집자 주: 이 프레젠테이션은 GraphSummit 2022에서 Stuart Horsman이 발표했어요.

이번 시리즈의 두 번째 프레젠테이션에서는 호주 Commonwealth Bank의 Stuart Horsman님을 소개할게요. CBA가 Knowledge Graph를 구축하면서 겪었던 성공과 어려움에 대한 이야기를 들려줄 거예요.

재밌게 봐주세요! 더 궁금한 점이 있다면 언제든지 daniel.ng@neo4j.com으로 이메일을 보내주세요.

2020년에 Matt Comyn[CBA(Commonwealth Bank Australia)의 CEO]은 CBA의 대부분의 디지털 자산을 온프레미스에서 클라우드로 이전하기로 결정했어요. 이때 IT 위험 안정성을 위한 고급 분석 작업을 통해 서비스 결제 중단을 예측하고자 했죠.

결제 시스템의 그래프 구조가 금방 눈에 띄었어요. 결제는 서로 굉장히 많이 얽혀있고, 이런 연결을 "일시적인 관계"라고 부르기로 했어요. 서비스 관리자는 서비스 A를 소유하고, 서비스 A가 서비스 B에 의존한다는 것을 알고, 서비스 B는 서비스 C에 의존하죠. 따라서 서비스 A는 서비스 C와 일시적인 관계를 가진다고 말할 수 있어요.

문제는 사람이 이 모든 일시적인 관계를 관리하기가 너무 어렵다는 점이었어요. 사실, 이 정보를 관계형 데이터베이스에 넣는 것조차 쉽지 않죠. 당시 데이터베이스는 이런 일시적인 관계를 제대로 유지하지 못하고, 서비스의 1-hop 관계만 살펴봤어요.

그래프 형태의 네트워크

네트워크를 그래프로 생각하기 시작했고, 데이터를 R의 igraph에 로드하는 것으로 시작했는데, 정말 운이 좋게도 곧 Neo4j를 알게 되었어요. Neo4j 오픈 소스 데이터베이스에 연결된 초기 R 드라이버를 직접 설치하기도 했죠. 여기서 데이터를 다시 R로 가져와서 그래프 알고리즘을 실행할 수 있었어요.

CBA의 클라우드 마이그레이션 위험을 어떻게 제거할 수 있을지 고민하기 시작했어요. 종속성이 없는 경우에는 가상 머신을 온프레미스에서 클라우드로 옮기는 게 정말 간단하죠. 하지만 더 복잡한 경우에는 이 서비스에 의존하는 다른 서비스와, 해당 서비스가 의존하는 서비스를 파악해야 해요. 이게 훨씬 더 어려워지기 때문에 모델링하기로 결정한 거죠.

처음에는 데이터 센터에 있는 수천 대 서버에 대한 데이터가 부족했어요. 이런 서버들이 어떤 애플리케이션 기능을 제공하는지, 또 이런 서비스들이 결제나 대출 같은 어떤 상위 수준에서 작동하는지 알 수 없었죠. 데이터를 저장하는 방식 때문에 1-hop 깊이의 서비스 종속성만 볼 수 있었고요.

문서 그래프: 올바른 데이터 찾기

Neo4j의 첫 번째 시도는 데이터가 불완전하다는 걸 알게 되면서 문서 그래프로 설명할 수 있었어요. 동시에 데이터를 수집하고 엔터티 해결을 수행할 수 있는 다른 IT 모니터링 및 관리 도구들이 있다는 것도 알고 있었죠. 예를 들어 Qualys 같은 도구는 취약점을 검색하고 호스트 이름, IP 주소, 정규화된 도메인 이름과 같은 유용한 메타데이터를 반환할 수도 있거든요. 이 프로젝트에서 저희는 Qualys가 찾아낸 취약점에는 관심이 없었고, 네트워크에서 사물이 어디에 있는지, 해당 IP 주소가 무엇인지, 얼마나 오랫동안 존재했는지에 관심이 있었어요.

Qualys 데이터를 다른 네트워크 정보와 결합하는 건 마치 큰 직소 퍼즐을 푸는 것과 같았어요. 이걸 함께 사용해서 엔터티를 해결하고 그래프를 만들 수 있었죠. 이러한 문서를 데이터베이스에 로드한 다음 네트워크에서 본 서버나 VM에서 "메타호스트" `Node`를 생성하고 `관계`를 만들기 시작했어요. 그런 다음 이 `Node`를 관계형 데이터베이스의 행에 다시 매핑하려고 했죠. 이렇게 하면 "원본 데이터베이스에 없는 것은 무엇일까요?" 또는 "데이터베이스에는 있지만 폐기된 상태이고 네트워크에는 아직 살아있는 것은 무엇일까요?"와 같은 질문을 쉽게 할 수 있게 돼요.

여기서 저희는 고아 자산 목록을 생성해서 서비스 관리자와 공유해서 실제로 특정 시스템을 소유한 사람이 누구인지 알아낼 수 있었어요. 물론 실제로 자기 소유라고 손을 드는 사람은 아무도 없었지만요.

아쉽게도 이 프로세스는 잘 확장되지 않았어요. 더 많은 시스템을 계속 온보딩함에 따라 이러한 시스템에 매핑해야 하는 레이블이 더 많아졌고, 이로 인해 선택적으로 일치하는 항목 수가 늘어났죠. 이러한 문제 때문에 다음과 같은 모델로 전환하게 되었답니다.

문서 그래프: 배운 교훈

원본 문서 그래프 유형에는 몇 가지 좋은 점이 있었어요.

• 확장하는 방법은 매우 쉬웠어요.
• 새로운 데이터 소스를 새로운 `Node` 레이블 유형에 매핑하는 것도 쉬웠죠.
• 이름이나 일련 번호와 같은 녹음 연결 의미는 저희가 연결하려고 시도한 모든 레코드에 대해 그대로 유지되었어요.
• 모든 `속성`이 `Node`에 있고 `Node`가 메타호스트에 대한 명확한 링크를 갖고 있기 때문에 데이터에 대해 추론하기가 쉬웠어요.
• 모든 데이터가 격리되어 있어서 `속성` 충돌이 발생하지 않았어요. 예를 들어, `속성`을 동일한 `Node`에 병합하는 문제에 대해 생각할 필요가 없었죠.

이러한 이점 외에도 사용자 `쿼리`에는 여전히 몇 가지 문제가 있었어요. `일치` 문은 저희가 원하는 것보다 약간 길었고, 각 `쿼리`마다 사용자가 소스 시스템의 컨텍스트와 존재 이유를 설명해야 했기 때문에 새로운 사용자를 교육하는 것이 어려웠답니다.

Knowledge Graph

결국엔 Knowledge Graph로 전환하게 되었어요. 위 이미지는 가장 최신의 단순화된 데이터 모델인데요. 이 모델에서 IT 서비스는 그저 컴퓨터의 논리적인 그룹일 뿐이에요. 이 모델의 Host에는 Interface가 있고, Host는 여러 Interface를 가질 수 있으며 여러 네트워크에 연결될 수 있죠. 해당 Interface에는 IP 주소가 있고요. 앞서 언급했듯이 Host는 관계형 데이터베이스에 있는 일부 엔터티와 이름을 공유할 수도 있어요. IP 주소는 일부 네트워크에 속하게 되고요.

Host 분류를 확장했는데, 원래는 데이터 센터의 일부 워크로드에 부여한 일반적인 레이블이었지만, 이제는 점점 더 많은 속성을 수집하고 분류하고 태그를 지정할 수 있게 되었어요.

네트워크 그래프

모델을 구축할 때 수직적인 관계는 만들었지만, 수평적인 관계는 없었어요. 그래서 어떤 IP 주소가 다른 IP 주소와 통신하는지, 어떤 Port에서, 언제 통신하는지 알고 싶었죠. 마침 병렬 프로젝트인 Iris가 전체 데이터 센터와 클라우드에서 흐름 데이터를 수집하고 해당 정보를 Kafka에 넣어 매일 처리하고 있었어요.

다음은 우리가 매일 받는 기록의 몇 줄인데요. 흐름이 시작된 시간, 소스 IP 및 대상 IP를 (마스킹 처리했어요). 우리는 수십억 개의 이러한 기록을 받아서 실제로 데이터를 다음과 같이 요약하고 싶었어요.

특정 정상 영업일에는 약 80억 개의 흐름을 수신해서 처리하는데요. Iris는 현재 약 2,400억 행의 데이터를 저장하고 있어요. Knowledge Graph를 위해서 우리는 수많은 플로우 데이터 행을 가져와서 그룹화하고 압축한 다음 Kafka를 통해 집계된 레코드만 Neo4j에 삽입해요. 이렇게 하면 네트워크의 흐름을 실시간으로 볼 수 있게 되죠.

두 IP 주소 간에 Relationship이 설정되면 Relationship 자체에 대한 동적인 메타데이터를 생성해요. Relationship에서 Port와 프로토콜은 고정되어 있지만, 더 많은 데이터가 전달됨에 따라 바이트와 개수가 증가하죠. Relationship이 생성되었을 때도 고정된 값이지만, 마지막으로 표시된 Relationship은 동적인 값이에요.

이 트래픽 데이터를 Neo4j에 전달하면서 시스템 규모를 고려해야 했어요. 시스템이 초당 200,000건의 트랜잭션을 실행하는 건 쉽지 않기 때문에 트래픽을 분리하기 위해 좀 더 스마트해져야 했죠. 우리가 생성하는 동적 메타데이터에는 "관리 트래픽"이나 컴퓨터가 존재하는 데 필요한 트래픽은 필요하지 않다고 결정했어요. 예를 들어 우리가 정말로 관심을 갖는 것은 애플리케이션 트래픽이나 443이나 포트 1521을 통해 들어오는 모든 것이죠. 우리는 이러한 트래픽 흐름을 별도로 처리하고 다양한 방식으로 주입해요.

우리 데이터 센터에서는 고정 IP가 다른 고정 IP와 통신하는 게 좋아요. 여기 기계는 항상 가동 중이기 때문에 IP를 절대 변경하지 않아요. 클라우드에서는 다르죠. 기계는 몇 시간 동안만 당신의 것이 될 수 있기 때문에 아무도 IP 주소에 관심이 없어요.
VM이 스핀다운되었다가 다시 작동하면 IP는 다르지만 워크로드는 동일해요. Knowledge Graph에서는 동일한 개체인 거죠. 이는 IP 할당과 관련된 일시적인 측면이 있음을 의미하며, 이제 이에 대해 생각하기 시작했어요. 어떤 호스트가 이 IP 주소를 가지고 있었을까요? 몇 시에? 어떤 라우팅 도메인에 있나요? AWS에는 실제로 보안 스캐너에서 검색한 CBA 외부의 다른 네트워크와 충돌하는 프라이빗 네트워크가 많이 있어요.
예를 들어, 재택근무를 하는 사람들이 있죠. 우리는 이러한 네트워크를 많이 가지고 있으며, 서브넷 트리 할당을 실행하면 인력이 실제로 네트워크의 잘못된 부분에 할당될 수 있다는 것을 알게 돼요. 우리는 지금 이 문제를 해결하려고 노력하고 있어요.

이 예는 얽힌 Node와 관련된 또 다른 문제에요. 파란색 Node는 IT 서비스예요. 왼쪽은 PaymentsJournal이고 오른쪽은 Oracle Platinum 그리드예요. 녹색 Node는 IP 주소이고 분홍색 Node는 머신 Node예요. 이 두 IT 서비스가 동일한 Node를 공유하고 있음을 알 수 있죠. 이것은 얽힘 문제예요. 실제로 해당 Node를 클라우드로 이동하려면 이 두 서비스를 처리해야 하며 시장에 출시되는 SLA는 서로 다를 수 있어요.

네트워크 흐름 정책: 시행에 대한 관찰

Commonwealth Bank Australia는 보안을 위해 전통적인 네트워크 분할을 실행했어요. 이는 기본적으로 다른 프로덕션 도메인 컴퓨터와 통신할 수 있도록 컬렉션에 있어야 하는 프로덕션 컴퓨터가 많이 있지만 우리는 해당 컴퓨터가 실제로 무엇을 하는지는 신경 쓰지 않는다는 의미에요. 우리는 그들이 실제로 어떤 네트워크에 연결되어 있는지에만 관심이 있죠. 정적 데이터 센터가 있고 네트워크가 변경되지 않으며 새 컴퓨터 설치가 잘 관리되는 경우에는 괜찮아요.
AWS와 같은 동적 환경으로 이동하면 누군가가 새로운 프로덕션 서비스를 시작하고 데이터 센터에 있는 무언가에 연결하기를 원할 수 있으며 우리는 해당 연결을 다르게 관리해야 해요. 이 워크로드에 더 많은 속성을 추가하여 이 프로덕션에 연결을 시도하는 워크로드를 결정하고 일시적인 시간 동안 허용되는지 여부는 살아 있을 수 있어요. 우리는 IP 주소나 방화벽 기반 규칙을 추상화하여 Neo4j에서 흐름 정책을 모델링하기 시작했어요.

이 예에는 IP 주소와 그 아래 흐름이 있는 4개의 호스트가 있는 PaymentsJournal이 있어요. 데이터베이스에서는 이들 각각을 워크로드로 태그 지정하고 정책을 규정할 수 있죠. 예를 들어 이 워크로드는 1521에서 수신될 수 있으며, 해당 기능은 호스트와 IP가 변경되더라도 해당 워크로드를 따릅니다. 이는 실제로 방화벽 정책을 호스트에서 워크플로 수준으로 이동합니다.

사이버 보안

사이버 보안은 우리 Knowledge Graph의 정말 흥미로운 사용 사례 중 하나에요. 왜냐하면 완벽한 네트워크 가시성을 확보하고 네트워크 형태에 대한 지표를 계산할 수 있거든요. 이 귀여운 비행선 모양은 네트워크의 핵심 부분을 스캔하는 네트워크 스캐너인데요, 사이버 보안 팀에 가서 이게 자기네 스캐너인지 확인해달라고 했더니, "생각보다 훨씬 더 많네요?"라는 답변이 돌아왔어요.

심지어 저희는 그들이 놓쳤을 수도 있는 네트워크 부분까지 알려줄 수 있었죠. 그랬더니 "당신은 누구고, 왜 이런 정보를 주는 거죠?"라면서 놀라더라고요. (농담은 여기까지!) Qualys 범위를 확장하기 위해 협력하고 있는데, Qualys를 사용해서 전체 네트워크와 스캐너가 하는 일을 확인하고 있기 때문이에요. 흥미로운 점은 내부 사이버 보안 "레드팀"이 연결돼서 내부에서 저희를 해킹하려는 모습도 볼 수 있다는 거죠. 그들이 네트워크의 일부를 스캔하기 시작할 때 실시간으로 관찰할 수 있어요.

지금까지의 여정

몇 년 동안 이 여정을 진행해 왔고, 아직 워크로드를 클라우드로 전환하는 과정에 있어요. 지금은 Knowledge Graph 생성을 배치 시스템으로 설정했는데, Neo4j가 부팅될 때 데이터를 로드하는 방식이죠. 데이터베이스가 수정되면 데이터베이스 상태를 추론하기가 정말 쉬워서 지금까지는 꽤 효과적이었어요. 데이터베이스가 읽기 전용 모드라면, `Node` 수, `Label` 수를 계산하고 데이터 원본 유형별로 `Node`를 계산할 수 있어요. 이런 측정항목을 계산하는 방법은 여러 가지가 있는데, 데이터베이스에 변경 사항이 생기면 메트릭에서 변경된 내용과 문제가 있는지 쉽게 확인할 수 있죠.

요즘은 AWS와 Azure 데이터를 많이 온보딩하고 있어서, API를 실행하고 모든 데이터를 추출하고 조작한 다음 데이터베이스에 로드하는 작업을 반복해야 해요. 클라우드의 시간적 특성 때문인데요, API를 실행하는 시점에서만 데이터를 볼 수 있다는 거죠. 저희가 진짜 원하는 건 이벤트 스트림이에요. 이벤트가 들어오면 실시간으로 이벤트를 변경하고, `Node` 주변의 `Relationship`도 변경하는 순수한 실시간 데이터베이스를 사용해서 라이브로 전환하려고 하고 있어요.

저희 데이터 모델은 많은 변화를 겪었고, 앞으로도 계속 변할 거예요. AWS 데이터 모델링을 통해 살펴봤듯이, 네트워크의 새로운 부분을 온보딩할 때 전송 게이트웨이와 비교해서 인터넷 게이트웨이를 모델링하는 방법에 대한 고민이 있었죠. 결국 공유 이름을 정하기 전에 AWS가 이름을 지정하는 방식과 회사 내부에서 이름을 지정하는 방식을 화이트보드에 적어야 했어요. (다행히 `Node`에 여러 `Label`을 지정할 수 있어서 Neo4j에서는 문제가 되지 않았죠.) 화이트보드에 있는 내용이 그래프의 데이터 모델이 되기 때문에 이 화이트보드 프로세스는 정말 중요해요.

CBA에서는 SQL을 아는 분석가들이 Cypher와의 크로스오버가 비교적 간단하다고 생각하는 점을 좋아해요. `SELECT` 문, `MATCH` 문, `WHERE` 절, 그리고 프로젝션을 이해하니까요. 하지만 모두가 Cypher를 배우는 건 아니죠. 즉, Graph Database를 최대한 활용하려면 이런 사용자들을 수용해야 해요.

저희는 Bloom이 유용하다는 걸 발견했어요. 사용자들이 복잡한 Cypher를 가져와서 코드를 작성하지 않고도 실제 UI에 포함시킬 수 있거든요. 실제로 마우스 오른쪽 버튼을 클릭해서 데이터를 업데이트하는 기능을 사용해서 그래프 자체에서 데이터를 업데이트하는 방식으로 Bloom을 사용하고 있어요. 저희는 정말 강력한 Knowledge Graph를 가지고 있고, 아직 Cypher를 배우지 않았더라도 CBA의 많은 사람들이 이걸 사용할 수 있도록 하고 싶어요.

더 자세히 알아볼 준비가 되셨나요? 주문형 웹 세미나를 확인하세요데이터 가치 극대화: Neo4j 그래프 데이터 플랫폼.

지금 웨비나 보기

• 고객 사용 사례
• 사이버보안
• GraphSummit 2022
• 프레젠테이션

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지