N° 01 — 목록
'분류 전체보기' (197)
-
Software Architecture/Architectural StylesArchitectural Styles - 04. 클린 아키텍처
클린 아키텍처 — 의존성 규칙을 동심원으로 그리기2012년, Robert C. Martin은 자신의 블로그에 'Clean Architecture'라는 글을 올렸다. 거기 그린 그림은 동심원이었다 — 가운데 Entities, 그 바깥으로 Use Cases, Interface Adapters, Frameworks & Drivers가 겹겹이 둘러싼 모양. 이 그림은 5년 뒤 같은 이름의 책(, 2017)이 되고, 동시대에 Jeffrey Palermo가 제안한 'Onion Architecture'(2008)와 거의 같은 구조로 통합됐다. 동심원 그림은 인터넷에 널리 퍼졌지만, 정작 핵심은 그림이 아니다. 동심원은 발상을 시각화한 부수물이고, 본질은 '의존성 규칙(dependency rule)'이라는 한 문장에 ..
-
DevOps & SRE/Disaster Recovery엣지 컴퓨팅 환경에서 DR은 왜 더 어려운가 — DR 설계 여정 #2
지난 포스트에서는 CDC + Kafka 기반 데이터베이스 DR의 본질과, 활성/대기(active/standby) 교차 운영 방식을 다뤘다. 이번에는 그 위에 얹힌 더 까다로운 계층을 이야기하려 한다. 현장 단말이 클라우드와 통신하는 엣지 컴퓨팅 환경에서 재해복구(DR)는 어떻게 달라지는가.결론부터 말하면, 엣지가 끼어드는 순간 DR은 "데이터 복제" 문제에서 "현장 단말이 재연결되는가" 문제로 바뀐다. 데이터는 잘 복제해 두었어도 단말이 재연결되지 않으면 DR이 완료되지 않는다. 이 포스트에서는 그 간극을 어떻게 메웠는지, 그리고 왜 두 개의 DR 계층을 겹쳐 쌓는 설계에 도달했는지를 공유한다.비유로 시작하자: 지점과 본사상황을 일상에 빗대어 보자. 어떤 프랜차이즈가 본사와 여러 지점으로 이루어져 있다고..
-
Software Architecture/Architectural StylesArchitectural Styles - 03. 헥사고날 아키텍처
헥사고날 아키텍처 — 도메인을 프레임워크로부터 격리하기2005년, Alistair Cockburn은 자신의 웹사이트에 "Ports and Adapters"라는 패턴을 올렸다. 그가 풀고자 했던 문제는 단순했다 — "같은 비즈니스 로직이 GUI, CLI, 테스트, 다른 애플리케이션에서 다시 작성되는 일"을 피하는 것. 그가 그린 그림은 도메인을 중심에 두고 여섯 개의 변이 둘러싼 육각형이었다. 이름은 헥사고날(hexagonal)이 됐고, 그 육각형의 변이 '포트(port)'가 됐다. 20년이 지난 지금, 이 패턴은 DDD 진영에서 가장 널리 쓰이는 구조적 패턴이 됐다. 그런데 이름은 자주 쓰이면서 본질은 자주 오해받는다. 헥사고날의 핵심은 '육각형 모양'이 아니라 '의존성 방향'이다.비유로 감 잡기 — 가..
-
Software Architecture/Architectural StylesArchitectural Styles - 02. 계층형 아키텍처
계층형 아키텍처 — 가장 흔한 구조가 품은 함정Spring Boot 프로젝트를 하나 열어보자. controller, service, repository 패키지가 보인다. 어쩌면 자바 웹 애플리케이션의 90%가 이 구조로 돼 있다. 이름은 계층형 아키텍처(layered architecture). 너무 흔해서 '스타일'로 의식하지 못할 정도다. 하지만 이 흔함이 숨기는 함정이 있다 — 계층을 나눴다고 해서 결합이 낮아지는 건 아니다. 계층 사이의 규칙이 결합을 낮춘다.비유로 감 잡기 — 식당의 층별 배치3층짜리 식당을 상상하자. 1층은 홀(손님 응대, 메뉴 설명). 2층은 주방(요리). 3층은 창고(재료 보관). 손님이 1층에서 주문하면 주문서가 2층으로 올라가고, 2층 주방이 3층 창고에서 재료를 꺼내 요..
-
Software Architecture/Architectural StylesArchitectural Styles - 01. 모놀리스
모놀리스가 다시 출발점이 된 이유2015년 무렵 한 스타트업이 하루 처리 건수 10만을 넘기며 모놀리스를 마이크로서비스로 쪼갰다. "모놀리스는 스케일이 안 된다"는 조언을 따른 선택이었다. 6개월 뒤 그 팀이 직면한 것은 트래픽 처리의 성공이 아니라 배포 파이프라인 8배, 분산 트랜잭션 버그, 그리고 "어느 서비스에서 로그가 끊겼는지"를 찾느라 보내는 새벽이었다. 모놀리스 시절 한 번에 끝나던 배포가 여덟 개 서비스의 버전 정합성을 맞추는 일로 바뀌었다. 그들이 진짜 필요했던 건 "모놀리스를 버리는 것"이 아니라 "모놀리스 안의 모듈 경계를 명확히 하는 것"이었다.흥미로운 건 마이크로서비스를 대중화한 책 의 저자 Sam Newman이 2판(2021)에서 오히려 "모놀리스 먼저(monolith first)..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 10. audit runtime-security
정적 방어를 넘어 "지금 무슨 일이 일어나는가"를 잡는 법 — 감사와 런타임 보안한 클러스터에서 침해가 일어났다. 공격자는 권한을 올리고 비밀을 빼갔지만, 발견은 며칠 뒤였다. 아무도 실시간으로 "이상한 일이 돌아가고 있다"를 못 봤기 때문이다. 지금까지의 정적 방어 — RBAC·NetworkPolicy·Pod Security — 는 "들어오는 것"을 막는 데는 강하지만, 이미 들어와서 행동하는 것은 잡지 못한다. 이 빈을 메우는 두 축이 감사 로그(audit log)와 런타임 보안(Falco)이다. 전자는 "누가 무엇을 했나"를 사후에 기록하고, 후자는 "지금 커널에서 무슨 일이 일어나나"를 실시간으로 잡는다. 이 글은 03-k8s-security 영역의 마지막 주제로, 이 두 관측 축이 침해를 어떻게..