분산 시스템 디자인 패턴

분산 시스템 역시 모법 사례와 원칙에 따라 설게됐다면 정상적으로 동작할 것이다.

 

• 사이드카 패턴
  포드에 있는 다른 컨테이너를 메인 애플리케이션 컨테이너에 함께 배치하는 것이다.
  애플리케이션 컨테이너는 사이드카 컨테이너가 추가된 것을 인지하지 못한 채 자신의 역활을 수행한다.
  중장 집중식 로깅 에이전트가 좋은 예다.
  메인 컨테이너는 표준 출력에 로그를 기록한다. 하지만 사이드카 컨테이너는 모든 로그를 중앙 집중식
  로깅 서비스로 전송하고 전체로 시스템과 로그를 집계한다.
  메인 애플리케이션에 중앙 집중식 로그의 기록을 위해 사이드카 컨테이너를 함께 사용하면 큰 장점이 있다.
  대표적인 장점은 중앙 집중식 로그 수집 환경으로 발생하는 애플리케이션의 부담을 해소하는 것이다.
  중앙 집중식 로깅 정책을 갱신하거나 완전히 새로운 공급자로 전환할 경우
  사이트카 컨테이너만 업데이트하고 배포하면 된다. 애플리케이션 컨테이너에는 변경이 없으므로
  실수로 애플리 케이션이 중단되는 일도 없을 것이다.
• 앰버서더 패턴
  원격 서비스가 마치 로컬인 것처럼 운영되도록 일부 정책을 시행하는것이다.
  쓰기 작업용 마스터 하나와 읽기 작업용 복제본 다수로 구성된 레디스 클러스터가 앰버서더 패턴의 좋은 예이다.
  로컬 앰버서더 컨테이너는 프록시 역활을 하며, 로컬호스트의 메인 애플리케이션 컨테이너에 레디스를 노출한다.
  애플리케이션 컨테이너는 localhost:6379에 있는 레디스에 간단히 연결되지만 실제로 동일한 포드에서 동작 중인 앰버서더에 연결된다. 앰버서더는 요청을 필터링하고, 실제 레디스 마스터에게 쓰기 요청을 보낻고, 읽기 복제본 중 하나로 읽기 요청을 전송한다. 사이드카 패턴과 같이 메인 애플리케이션은 어떤 일이 일어나고 있는지 알지 못한다.
  이것은 실제 로컬 레디스 환경에서 테스트할 경우 많은 도움이 된다. 또한 레디스 클러스 구성의 변경이 있는 경우
  앰버서더만 수정하면 되며, 메인 애플리케이션은 아무런 영향을 받지 않는다.
• 어댑터 패턴
  메인 애플리케이션 컨테이너의 출력을 표준화하는 것이다. 점진적으로 배포되는 서비스를 가정해보자.
  이전 버전과 일치하지 않는 형식의 출력이 발생하고 그 출력을 사용하는 다른 서비스나 애플리케이션은 아직 업그레이드되지 않은 경우를 가정하자. 이 경우 어댑터 컨테이너는 새로운 애플리케이션 컨테이와 함께 동일한 포드에 배포될 수 있으며 해당 출력을 사용하는 다른 서비스나 애플리케이션이 업그레이드 될 때까지 이전 버전에 맞게 출력ㄷ을 변경할 수 있다. 어댑터 컨테이너는 메인 애플리케이션 컨테이너와 파일시스템을 공유하기 때문에 로컬 파일시스템의 감시가 가능하며, 새로운 애플리케이션이 무언가 쓰기 작업을 할 때마다 이를 즉시 변경한다.
• 다중 노드 패턴
  모든 단일 노드 패턴은 포드를 통해 쿠버네티스가 직접 지원한다. 반면 리더 선출, 작업 큐, 분산 수집 같은 다중 노드 패턴은 쿠버네티스의 직접적인 지원 없이 표준 인터페이스를 사용해 포드를 구성한 쿠버네티스에서 실행 가능한 접근 방식이다.