DEV Community

NeNoVen
NeNoVen

Posted on

CAP 이론

C: 일관성

  • 어떤 노드에서 접근을해도 동시에 동일한 내용을 제공

A: 가용성

  • 사용자의 요청에 항상 응답하는 것.

P: 분할 허용성 (네트워크)

  • 네트워크 파티션이 있어도 시스템이 계속 작동하는 능력

분할 허용시…

일관성과 가용성을 적절한 가중치 배분이 중요

case 1. 은행의 경우

atm 2대로 가정을 하면,

하이브리드 구성

  • 잔액조회만 가능, 소규모 출금만 가능

case2. 구글독스 CAP 전략

구글독스의 충돌전략은 가용성과 분할 허용성을 우선시합니다. 즉, 사용자가 문서를 항상 사용할 수 있고, 시스템이 분할되어 있어도 작동하도록 설계되었습니다.

구글독스의 충돌전략은 다음과 같이 CAP에 구성되어 있습니다.

  • 일관성: 구글독스는 버전 관리 시스템을 사용하여 문서의 이전 버전을 저장합니다. 충돌이 발생하면 사용자는 이전 버전에서 선택할 수 있습니다. 따라서 구글독스는 일관성을 일부 희생합니다.
  • 가용성: 구글독스는 문서를 여러 서버에 분산하여 저장합니다. 따라서 시스템이 분할되어 있어도 문서에 액세스할 수 있습니다.
  • 분할 허용성: 구글독스는 문서에 대한 변경 사항을 추적하여 충돌을 감지합니다. 충돌이 감지되면 사용자에게 경고하고 해결 방법을 제안합니다. 따라서 구글독스는 분할 허용성을 달성합니다.

구글독스의 충돌전략은 사용자 친화적이고 효과적이지만, 일부 상황에서는 일관성이 약화될 수 있습니다. 예를 들어, 두 사용자가 동시에 동일한 단어를 수정한 경우, 충돌이 발생하여 사용자가 이전 버전으로 돌아가야 할 수 있습니다.

case 1. 은행의 경우

atm 2대로 가정을 하면,

하이브리드 구성

  • 잔액조회만 가능, 소규모 출금만 가능

case2. 구글독스 CAP 전략

구글독스의 충돌전략은 가용성과 분할 허용성을 우선시합니다. 즉, 사용자가 문서를 항상 사용할 수 있고, 시스템이 분할되어 있어도 작동하도록 설계되었습니다.

구글독스의 충돌전략은 다음과 같이 CAP에 구성되어 있습니다.

  • 일관성: 구글독스는 버전 관리 시스템을 사용하여 문서의 이전 버전을 저장합니다. 충돌이 발생하면 사용자는 이전 버전에서 선택할 수 있습니다. 따라서 구글독스는 일관성을 일부 희생합니다.
  • 가용성: 구글독스는 문서를 여러 서버에 분산하여 저장합니다. 따라서 시스템이 분할되어 있어도 문서에 액세스할 수 있습니다.
  • 분할 허용성: 구글독스는 문서에 대한 변경 사항을 추적하여 충돌을 감지합니다. 충돌이 감지되면 사용자에게 경고하고 해결 방법을 제안합니다. 따라서 구글독스는 분할 허용성을 달성합니다.

구글독스의 충돌전략은 사용자 친화적이고 효과적이지만, 일부 상황에서는 일관성이 약화될 수 있습니다. 예를 들어, 두 사용자가 동시에 동일한 단어를 수정한 경우, 충돌이 발생하여 사용자가 이전 버전으로 돌아가야 할 수 있습니다.

Image description

case3. 다양한 케이스

CAP 전략은 분산 시스템에서 중요한 고려 사항입니다. 다양한 케이스에 따라 다음과 같은 다양한 CAP 전략을 사용할 수 있습니다.

  • 일관성을 우선시하는 경우:
    • 원자성(Atomicity): 모든 작업이 성공하거나 실패하도록 합니다.
    • 멱등성(Idempotence): 작업을 여러 번 실행해도 동일한 결과를 얻도록 합니다.
    • 지연된 일관성(Eventual consistency): 시간이 지남에 따라 데이터가 일관되도록 합니다.
  • 가용성을 우선시하는 경우:
    • 캐싱(Caching): 데이터를 임시로 저장하여 성능을 향상시킵니다.
    • 복제(Replication): 데이터를 여러 서버에 복제하여 가용성을 향상시킵니다.
    • 투명성(Transparency): 사용자에게 시스템이 분산되어 있다는 사실을 숨깁니다.
  • 분할 허용성을 우선시하는 경우:
    • 파티셔닝(Partitioning): 데이터를 여러 서버에 분산하여 분할을 허용합니다.
    • 동기화(Synchronization): 분할된 서버 간에 데이터를 동기화합니다.
    • 재시도(Retry): 실패한 작업을 다시 시도합니다.

다음은 CAP 전략을 적용한 몇 가지 구체적인 예입니다.

  • 온라인 쇼핑몰: 주문 처리 시스템은 가용성을 우선시합니다. 시스템이 분할되어 있어도 사용자는 주문을 할 수 있어야 합니다. 따라서 시스템은 주문 데이터를 여러 서버에 복제하고, 사용자가 주문할 때마다 가장 가까운 서버에 요청을 보냅니다.
  • 금융 서비스: 결제 시스템은 일관성을 우선시합니다. 모든 거래는 동일한 결과를 가져야 합니다. 따라서 시스템은 트랜잭션을 원자적으로 실행하고, 트랜잭션이 실패하면 모든 변경 사항을 되돌립니다.
  • 게임: 게임 서버는 분할 허용성을 우선시합니다. 게임 서버가 분할되어 있어도 플레이어는 게임을 계속할 수 있어야 합니다. 따라서 시스템은 게임 상태를 여러 서버에 복제하고, 플레이어가 게임을 할 때마다 가장 가까운 서버에 연결합니다.

CAP 전략은 분산 시스템을 설계 및 구현할 때 중요한 고려 사항입니다. 시스템의 요구 사항을 평가하고 적절한 CAP 전략을 선택해야 합니다.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more

Top comments (0)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Discover a treasure trove of wisdom within this insightful piece, highly respected in the nurturing DEV Community enviroment. Developers, whether novice or expert, are encouraged to participate and add to our shared knowledge basin.

A simple "thank you" can illuminate someone's day. Express your appreciation in the comments section!

On DEV, sharing ideas smoothens our journey and strengthens our community ties. Learn something useful? Offering a quick thanks to the author is deeply appreciated.

Okay