Cloud Native App Design Patterns

Overview

communication patterns

• 동기

  • RPC

• 비동기

  • Message Queue
  • Pub-Sub

• 요청-응답 패턴

  • blocking call
  • 즉각 데이터를 요청하고 받아야 하는 경우 사용
  • 초창기에 많이 사용
  • 의존성이 발생하므로 좋지 않음

• RPC

  • 서비스의 기능을 함수로 제공
  • 보통 IDL 사용해서 proxy 생성하여 사용
  • client와 server에 모두 stub이 있고 stub은 RPC runtime으로 통신
  • RESTful이 곽강받으면서 RPC는 도태
  • gRPC 같이 CNA에 적합한 것을 사용
    • HTTP2 통신 사용 - 기존의 부하기 그대로 사용 가능 및 프로토콜 버퍼를 통해 효율적 직렬화
  • 내부 서비스 간 통신에 적합

• 비동기 메시징 패턴

  • single receiver
    • P2P 비동기 메시징
    • procuder가 message broker에 메시지를 enqueue
    • message broker가 consumer에게 message를 전달
  • AMQP가 널리 사용
    • RabbitMQ
    • ActiveMQ
    • Artemis
  • E2E 메시지 전달 보장 필요 시 사용
  • multi receiver
    • Pub-sub임
    • client는 topic을 구독
    • '가격 변동' 토픽 메시지
    • Apache Kafka, ActiveMQ, RabbitMQ
    • Durable topic은 메시지 전송을 보장

• 비동기 요청-응답

  • 송/수신 별 각각 message broker를 사용해서 통신

서비스 정의 패턴

service definition

service registry에 service definition이 위치
service가 registry에 등록
client가 registry에서 찾음
메타 데이터 store로 구현됨
RESTful interface를 제공하여 검색 가능하도록 지원 피룡

동기 메시지 패턴 구현 기술

RESTful

• 서비스와 객체는 고유 URI로 resource에 접근
• REST는 보통 HTTP 사용
• URI는 각 자원 구분할 수 있는 고유 십결자로 사용됨
• GET/POST/DELETE/PUT/HEAD와 같은 표준 HTTP method로 액션을 수행

Graph QL

요청-응답 패턴 중 하나
요청이 query 형태
내부적으로 HTTP 사용
표준 Graph QL 요청은 HTTP POST request

WebSocket

요청-응답 패턴
Web에서 TCP를 도입 (세션 유지하여 양방향 통신)
HTTP 상에서의 handshaking

gRPC

서비스간 통신을 지역 함수 호출처럼
ser/des 즉, marshalling, unmarshalling 필요
HTTP2 기반
여러 언어 지원(Java, Go 등)

비동기 메시징 패턴 구현 기술

AMQP

빠르고 신뢰성 있음
message ack 제공

• Queue에 메시지 전송 시 확인 보냄
• broker가 consumer에 전달 ㅏ시에도 확인 보냄 가능
• Apache Kafka
  • open source broker
  • message나 event를 분산 commit log로 유지
    • message durability
  • 고가용성, 분산 이벤트 지원
  • event 전달 보장
  • replay 가능(미 삭제)

testing

• 비동기 이므로 phase 별로 검증
  • producer에서 broker의 전송 검증
  • broker에서 consumer로의 전송 검증

보안 기술

• TLS (Transport Layer Security)
  • RESTful, gRPC, GraphQL 모두 TLS 적용 가능
• 인증
  • OAuth 2.0
  • JWT (JSON Web Token)

모니터링 / 관측 기술

OpenTelemetry
app의 metrics를 Prometheus로 수집/추적/로깅 하여 Grafana로 visualization

연결성 / 조합 패턴

• 연결성
  • 통신 매체 제공
  • 접속, 보안 등
• 조합
  • 여러 서비스 통합
  • SOA는 ESB로 통합
  • Cloud Native는 중앙 집중화된 조합 계층 없음
  • 서비스 조합은 모두 서비스 개발 과정에서 수행

동기 메시지 기술

• RESTful
  • 기능을 자원 지향 모델로 표현
  • 웹, 모바일 등 다양한 client 대응
  • JSON, XML, CSV 등 지원
  • human readable text based
• GraphQL
  • 데이터 획득 방식 지정 필요 경우
  • 잘 정의된 스케마 필요 경우
• gRPC
  • 저지연, 고성능
  • 타입 안정성 필요
  • 스트리밍 처리. <--- ?
• Web Socket
  • 고유 데이터 포맷으로 양방향 통신
  • TCP 기반으로 세션 유지

service registry / discovery

registry
서비스 정보(definition)과 metadata를 저장하는 store
store API 와 discovery API 제공
반드시 필요
API를 외부 제공 시 API 개발 portal이라는 별도 API registry 사용

저장 정보
service URL
service interface definition(OpenAPI spec, gRPC definition)
service-level agreements (SLA)
개발 시 앱이 서비스 규약 및 정보에 맞게 개발
사전에 정의된 수준의 서비스 협약

Load balancer가 registry에서 서비스를 검색 하기도 함
서비스 배포 시 registry인 Consul에 등록
service는 주기적으로 허트비트를 보내 registry가 유효한지 파악하게 함

Kubenetes에서 pod 검색 시 DNS 이름을 사용
http://bar:... <- bar 서비스

탄력적 연결성

연결성 장애시 복구

방식
timeout
retry
deadline
deadline 시 연결 끊음 ? ??
circuit breaker
실패 횟수 임계치 초과 시 해당 서비스의 호출 막음
일종의 fallback 처리

side car

큰 앱의 보조 앱
동일 레벨의 우측에 요소를 배치

용도
컨테이너의 기능 확장/향상
주 앱에 수정 없이 기능 확장
별도의 독립적인 프로세스/컨테이너 (plugin과 유사하나 가장 큰 차이)
IPC로 결합됨
독립적인 생명주기를 지님

sidecar proxy
ex. 타 서비스의 DB에 저장 기능을 sidecar로 구현

sidecar bridge
proxy는 delegate 역할이나 bridge는 여러 통신 로직을 제공

service mesh

여러 서비스를 망처럼 연결
여러 서비스간 traffic routing, 보안, 서비스 검색/관측 등

service 조합 패턴

service orchestration pattern

여러 service와 system을 통합하고 호출

ex. 서비스 A가 서비스 B, C를 사용하고 이들의 응답을 조합해서 사용자에게 전달
동기/비동기
서비스 체인
gRPC 등을 이용한 직접 연결

Service Choreography pattern

로직이 여러 서비스에 퍼진 경우, 이들을 비동기 통신으로 구현
즉, Message broker를 통한 연결
pub-sub, 비동기 메시징 등으로 구현

Saga pattern

일련의 사건 패턴
서비스간 상호작용을 transaction 으로 제어
한 동작의 실패가 다른 동작의 취소(rollback)이 필요한 경우

transaction을 여러 하위 transaction 및 compensating transaction으로 구성
하나라도 실패 시 원상 복구

데이터 관리 패턴

CNA에서의 데이터 관리도 분산 방식
각 MS가 자신만의 store를 지니고 interface로 접근
동기화가 어려움

Event Driven patterns

비동기 통신은 CNA의 근간
Event Driven Architecture로 느슨한 결합

stream processing patterns

EDA는 한번에 하나의 event 처리
스트림은 시간 상 서로 밀접한 관계
앱이 현재 상태를 계속 저장 관리

API 관리 및 사용 패턴

관리형 서비스 / API로 서비스들의 기능 제공 제어
보통 API gateway를 둠

DB 정규화

DB 정규화

원자성 (속성)
모든 속성은 기본키에 종속 > 무결성 향상
이행 종속성 제거 > 한 속성이 다른 속성 결정을 막고자 테이블을 추가하여 분리

key-value store

Redis
cache

column store

각 row에 여러 column 저장
row key, column key에 value

Casandra

Document store

JSON, XML 등의 반정형 데이터 저장
MongoDB

Graph store

node 연결

Neo4j

Object store

time-series data store

멀티 모델 지원

Amazon DynamoDB
    key-value와 document 지원

NoSQL 특징

분산 동작이 기본

CAP 이론
    Consistency, Availability, Partition tolerance

    일관성: 특정 노드의 수정을 다른 노드에 전파
    가용성: 일부 노드 문제에도 시스템은 정상
    분할 내성: 분할 후에도 연결 유지

NoSQL은 CAP 만족 불가
    상황에 따라 선택
    최신 데이터 중요 시 가용성 확보 필요

central data management

모든 데이터를 단일 DB에 저장

장점
    DB table의 일관성, 정규화 가능

단점
    앱간 데이터 의존성 발생

decentralized data management

각 서비스가 별도의 데이터 store 사용

pros
    서로 다른 목적에 맞는 데이터 스토어 타입 선택
    각 서비스는 타 서버스의 데이터에 의존성 없음

cons
    별도 데이터 store 사용에 따른 비용 발생

hybrid data management

서비스가 cache를 지니고 data store와 sync

data composition patterns

data service pattern

데이터 서비스 = 데이터를 서비스 형태로 제공

서비스가 데이터 사용을 추상화


service —> data service <—> database

보안 정책 적용 가능
다양한 조합으로 데이터를 제공
접근 제어
여러 테이블에 대한 join, 저장 등
    이를 처리하고 캐싱해서 성능 향상
캐싱 가능

composition data service pattern

여러 서비스에서 데이터를 읽고 조합

composite
data        <———> data service
service           data service
                  database

서비스 orchestration pattern과 유사
여러 데이터 서비스와 자신의 데이터 스토어에서 조합

ex. 
여러 업체의 데이터 서비스에서 제공받아 가공하여 제공

client side mashup pattern

client가 데이터 서비스에서 데이터를 자져와 조합

ex. web browser가 page의 일부를 가져와 화면에 표시
    부분 부분 화면에 표시하여 경험을 향상

    저지연으로 보여줌

data scaling patterns

data sharding pattern

data store를 shard로 나눠 저장

horizontal data sharding
    샤드들이 같은 스키마 사용
    샤딩 키에 따라 서로 다른 레코드를 저장

vertical data sharing
    shard들은 다른 스키마 사용
    자주 사용하는 유저 이름 등을 하나의 샤드에
    자주 사용하지 않는 주소 등은 다른 샤드에

functional data sharding
    기능별로 데이터 분리
    상품 세부 데이터, 상ㅍ무 리뷰 데이터

    vertical과 functional은 한계가 있음
    결국 horizontal 즉, 키를 통한 분리를 써야 함

수평적 샤딩

lookup
    분산 캐시에 샤드 키와 실제 데이터 위치 저장
    별도의 매핑 태이블을 둠

range
    날짜나 시간 등으로 나눔

hash
    데이터 필드를 샤드 키로 사용
    range와 달리 균등 분포됨

샤드키와 관련된 필드 값은 불변 이어야 함

샤딩 목적

scale-out

조회 시간 단축
    특정 브랜드로 샤드 키를 만들어 조회 시간을 단축

분산 (지역적 분산)
    데이터를 지역으로 나누고 가까운 데이터를 지역별로 모음

고려사항
데이터 양이 비슷해야 함

샤드는 가급적 작게

여러 샤드 복사 유지
    장애 대응, 성능 대응

CQRS

command and query responsibility segregation pattern

데이터 변경과 질의를 분리

    속도향상
    확장성 향상
    보안성 확장

쓰기와 조회를 별도의 서비스로 분리
저장소 역시 분리
    쓰기와 읽기를 서로 다른 노드에서 수행해서 성능 향상
    각각 독립적으로 스케일링

저장은 RDB, 질의는 document store 등으로 구성 가능

고려
    명령과 질의 간 일관성이 필요한 경우 사용하면 안됨
    약한 일관성에서만 사용

        일관성 유지하고자 할 시 lock 획득 경합 발생 > 지연

단점
    복잡
    중복 / 실패 처리 필요

    이벤트 소싱 패턴(결과가 아닌 이벤트들을 기록) 관리 필요

        CQRS는 상태 저장 방식을 강제하지 않음

Performance Optimization Patterns

데이터는 주요 병목 중 하나

성능향상

• 색인

  • 검색 성능 향상
  • 과도한 색인 사용은 RW 성능 저하
    • 모든 W 작업에 대해 모든 색인이 변경
    • DB는 여러 번의 write 수행
    • read 경우 모든 색인을 memory에 들고 있을 수 없음

• 비정규화

  • join 연산을 제거하여 읽기 성능을 비약적으로 향상
  • 쓰기 작업은 정규화 하여 저장하여 높은 일관성을 유지
  • 읽기 작업은 비정규화 하여 저장된 것을 통해 효율적으로 처리
  • CQRS 패턴과 함께 사용

ex. CQRS에서 비정규화 예
전자상거래 주문 시스템에서 정규화된 저장

즉 데이터의 저장은 RDB에 하여 정규화된 상태로 저장을 하지만,
중복도 없고 최소 속성으로 쪼개고, 필드들은 모두 주키에 연관되어 있고 ...하나,
검색 속도 향상을 위해 join 해야 하는 모든 항목들의 데이터를 중복하여 하나의 덩어리로 저장하고, 이는 반정형 형태의 JSON이나 YAML에 저장하고 키 값으로 관련된 정보를 한번에 조회

orders, order_item, products, users 등 많은 테이블이 존재
이를 조회할 시 다음과 같이 여러 table에서 join 필요

SELECT 
    o.order_id,
    o.order_date,
    u.username,
    u.email,
    p.product_name,
    oi.quantity,
    oi.price
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_id = 12345;

비정규화된 읽기

{
  "order_id": 12345,
  "order_date": "2024-02-21T10:30:00",
  "status": "shipped",
  "user": {
    "user_id": 789,
    "username": "john_doe",
    "email": "john@example.com"
  },
  "items": [
    {
      "product_id": 101,
      "product_name": "MacBook Pro",
      "category": "Electronics",
      "quantity": 1,
      "price": 2500.00
    },
    {
      "product_id": 102,
      "product_name": "Magic Mouse",
      "category": "Accessories",
      "quantity": 2,
      "price": 79.00
    }
  ],
  "total_amount": 2658.00
}

Materialized view pattern

데이터 처리 위치 근처에 구체화된 뷰를 저장

정규화 테이블들을 JOIN 해서 materialized view를 비정규화된 결과를 저장하는게 materialized view
DB에 검색 결과를 저장하는 table을 두고 이를 검색

materialzied view는 JOIN 결과를 미리 계산해서 저장하는 것 (캐싱)

CREATE MATERIALIZED VIEW order_summary AS SELECT * ... <- summary를 생성

주기적으로 정규화 테이블들을 JOIN 해서 materialized view를 비정규화된 결과를 저장

고려

• 동기화 데이터 복제 시 경합 발생하므로 비동기 방식으로 데이터를 복사해야 함
• 의존 서비스의 데이터 스토어 내 불필요한 데이터들을 필터링 하여 사용

Data Locality Pattern

데이터 처리 로직을 데이터와 최대한 가깝게 둠
서비스와 데이터를 같은 위치(같은 노드)에 배포

필요 이유

• 데이터 읽기 지연 시간 감소
  • join 등 연산 수행 경우 모든 데이터를 local로 가져와서 작업 수행하므로,
• 조합 서비스 패턴
  • 여러 store의 join 연산 하여 성능 향상
• Network BW 감소
  • 여러 데이터 소스에서 aggregation 이나 filtering 시 유용

고려

• 타 서비스로 전달하는 데이터를 줄일때 사용 의미가 있음(그대로 전달한다면 굳이 데이터 옆에 있을 필요는 없음 bypass 이므로)

Caching pattern

RDB 등에서 query 한 결과를 redis에 key-value인 반정형 데이터로 저장

적재 방식

• cache-aside (lazy loading)
  • 조회 시 cache에서 찾고, cache miss 시 DB에서 조회 후 cache에 저장
• write-through
  • 저장 시 DB와 cache에 모두 저장
  • write-behind
    • 캐시에 우선 저장하고 DB 저장은 queue에 쌓고 background에서 worker가 queue의 작업을 처리

CQRS와 유사해보이나,
CQRS는 영구저장인 반면, cache는 임시저장(ex. 1시간 후 삭제)
즉, 삭제가 있기 때문에 적재 방식의 다양함이 존재

Static Content Hosting Pattern (CDN)

정적 content를 client 주변에 배포하여 낮은 지연 시간 확보
Image file, HTML page, JavaScript, CSS, 등은 모두 정적 데이터으므로 CDN 활용

Reliability pattern

Transaction pattern

여러 transaction을 하나의 작업처럼 만들어 완료/비완료로 처리
SAGA와 유사하나 Transaction pattern은 전통적 ACID transaction 임
즉, 단일 DB 내에서(lock 불필요)의 여러 table에 대한 처리 작업을 원자적으로 보장하는 것
SAGA는 여러 서비스간 트랜잭션

여러 DB나 서비스의 데이터를 조율
이를 하나의 transaction 처럼 만듦
금융 어플에 필수적 패턴
ACID 속성을 따름

• Atomic
• Consist: 전/후 유효 상태
• Isolation: 영향 X
• Durable: system failure 경우에도 종료된 Transaction은 처리 완료 보장

Security: Vault key pattern

신뢰할 수 있는 token(vault key)로 data store에 접근

client -> identity provider : trusted token을 요청
client -> Data Store : token을 가지고 데이터 요청

데이터 store에서 인증/권한 처리를 분리하고 한 곳에 집중

데이터 관리 패턴 구현 기술

RDBMS

• MySQL, Oracle, MSSQL, Postgres, H2

  • ACID 지원
  • SQL 지원
  • 비관계형 데이터에 맞지 않음

• Cassandra

  • column store
  • 정지 없이 계속 동작
  • 고성능, 선형적 확장성
    • 패타 단위 데이터 처리 가능, 동시 초당 수 천개 작업 처리 가능
  • 리전간 데이터 복제 지원

• HBase

  • NoSQL column store
  • HDFS에서 map-reduce 작업 처리
  • 선형적 확장성
  • 장애시 문제 (데이터 위치가 오직 한 곳)

• MongoDB

  • Document store
    • JSON 등의 document 저장 가능
  • document collection은 RDB의 record에 비슷
  • query 지원
    • aggregation, filtering, sorting 등 지원
  • 색인이 있어야 성능 유지 가능
  • 고가용성
    • 하나의 RW primary, 여러 secondary replica (primary가 죽을 시 secondary에서 candidate 하여 primary election)

• Redis

  • in-memory key-value store
  • cache에 주로 사용
    • 문자열 키, 문자열, 목록, 집합, 정렬된 집, 해시, 비트 배열 등 저장
  • transaction 지원
    • 키에 대한 유효 시간 지정 가능
  • LRU 방식의 key-value 삭제
  • 자동 복구
  • 넘치는 데이터는 disk에 저장
    • Redis DB backup 형태로 저장
  • cloud hosting 많음
  • 고가용성
    • CQRS 처럼 단일 마스터, 여러 복제 노드를 통한 고가용성 지원
      • mater가 write/update
      • replica는 read
      • master와 replicas간 동기화 (설정에 따름)
  • 샤딩 패턴
  • 복잡한 질의 처리 어려움

• Dynamo DB

  • key-value, document
  • 저지연
  • 고확장성
  • join, 외래 키 기능 없음 - 관계형 DB에 비해 질의 기능 제약
  • 비정규화된 중복 데이터를 통한 성능 향상

• HDFS

  • 분산 file system

  • 고 데이터 탄력성

  • 저장 데이터는변경 불가

  • Amazon S3

    • object store
    • big-data 분석 등에 사용
    • 표준 SQL 구문 지원
    • S3 select로 전체 object가 아닌 일부만 read 가능
    • 고가용성

• Azure Cosmos DB

  • 완전 관리형 NoSQL
  • key-value, document, column, graph 지원
  • 지저연
  • 접근제어, 암호화 등 지원

...

고려사항

• 암호화
  • 민감 데이터 암호화
  • 파일 시스템 암호화
• 격리
  • 민감 데이터와 다른 데이터의 격리
  • 추가 보안 정책 적용
  • 모니터링, 감사
• 불필요 민감 데이터 저장 X
  • 민감 정보를 고유 식별자로 대체

Observability / Monitoring

지표

• application matrics
  • data store 가동 시간, 상태
  • 질의 처리 시간
    • 최적화 되지 않은 질의 (복잡한 조인, 색인 X)
    • 데이터 증가
    • 리소스 부족 (CPU, memory, disk space)
  • 질의 실행 응답 - 정상 여부 확인
  • 이상 질의 감사
• system matrics
  • CPU, memory, disk space, network, disk I/O
• data store log
• primary와 replica 간 통신 시 처리 시간 및 throughput
  • 네트워크 상 문제 파악 가능
  • 상태가 안좋은 node 대체

DevOps

data store 선택

RDB, NoSQL, file system
vendor

배포 패턴

고가용성, 확장성 수준 설정
clound type
node 개수
clonud vendor (public, on-premise)
복제 방식
백업 방식
보호
모니터링
비용

보호 정책

민감 데이터에 대한 보호
암호화, 접근 제어, 로그 감사

관측성 설정 및 모니터링

정상 동작 관찰
샤드 재배치 등 확장 방법 적용
지속적 전달(CI)
data store schema 초기화 뒤 앱이 커지면서 하위 호환성을 유지하는건 어려운 일
script 등을 통해 지속 전달을 자동화