양식
• 스타일은 다음과 같이 공식화됩니다
• 인터페이스가 잘 정의된 (교체 가능한) 구성 요소
• 구성 요소가 서로 연결되는 방식
• 구성 요소 간에 교환되는 데이터
• 이러한 구성 요소와 커넥터가 시스템에 공동으로 구성되는 방법
• 커넥터
• 구성 요소 간의 의사소통, 조정 또는 협력을 매개하는 메커니즘입니다.
• 예: (원격) 프로시저 호출, 메시징 또는 스트리밍 기능
레이어드 아키텍처
• 계층화된 다양한 조직
애플리케이션 계층화
• 삼층관
• 애플리케이션 인터페이스 계층에는 사용자 또는 외부 애플리케이션과의 인터페이스를 위한 유닛이 포함되어 있습니다
• 프로세싱 계층은 애플리케이션의 기능을 포함합니다. 즉, 특정 데이터 없이 말이죠
• 데이터 계층에는 클라이언트가 애플리케이션 구성 요소를 통해 조작하려는 데이터가 들어 있습니다
• 이 계층화는 기존의 데이터베이스 기술과 함께 제공되는 응용프로그램을 사용하는 많은 분산 정보 시스템에서 볼 수 있습니다.
객체기반 스타일
• 컴포넌트는 프로시저 호출을 통해 서로 연결된 객체입니다. 객체는
서로 다른 기계에 배치됩니다. 따라서 네트워크를 통해 호출을 실행할 수 있습니다.
• 캡슐화(encapsulation): 객체는 내부 구현을 드러내지 않고 데이터를 캡슐화하고 해당 데이터에 대한 방법을 제공한다고 합니다.
미들웨어 조직
레거시를 사용하여 미들웨어 구축
• 레거시 구성 요소가 제공하는 인터페이스는 모든 애플리케이션에 적합하지 않을 가능성이 높습니다.
• 래퍼 또는 어댑터는 클라이언트 어플리케이션이 수용할 수 있는 인터페이스를 제공합니다. 그것의 기능은
구성 요소에서 사용할 수 있는 것으로 변경되었습니다.
• 적응형 미들웨어 개발
• 미들웨어는 대부분의 애플리케이션에 적합한 솔루션을 포함하고 있습니다.
• 특정 응용프로그램에 대한 동작을 조정할 수 있습니다.
중앙 집중식 시스템 아키텍처
• 기본 클라이언트-서버 모델
• 서비스(서버)를 제공하는 프로세스가 있습니다
• 서비스(클라이언트)를 사용하는 프로세스가 있습니다
• 클라이언트와 서버가 서로 다른 컴퓨터에 있을 수 있음
• 고객은 서비스 사용과 관련하여 요청/응답 모델을 따릅니다
다층 중앙 집중형 시스템 아키텍처
• 몇몇 전통적인 조직들은
• 단상: 덤 터미널/메인프레임 구성
• 2계층: 클라이언트/단일 서버 구성
• 3단: 개별 기계의 각 레이어
대체조직
• 수직 분포(vertical distribution): 분산된 애플리케이션을 3개의 논리 계층으로 나누고, 각 계층의 구성 요소를 서로 다른 서버(머신)에서 실행하는 것에서 비롯됩니다.
• 수평 분포: 클라이언트 또는 서버는 물리적으로 논리적으로 동등한 부분으로 분할될 수 있지만, 각 부분은 전체 데이터 세트에서 각자의 몫으로 작동합니다.
• P2P 아키텍처: 프로세스는 모두 동일합니다. 수행해야 하는 기능은 모든 프로세스로 표현됩니다. 각 프로세스는 클라이언트와 서버의 역할을 동시에 수행합니다(즉, 서번트의 역할).
비정형 P2P
• 각 노트는 이웃의 임시 목록을 유지합니다. 결과적인 오버레이는 랜덤 그래프와 유사합니다. 에지 < 𝑢, 𝑣 > 는 특정 확률의 ℙ < 𝑢, 𝑣 > 만 존재합니다.
• 검색중
• Flooding: 발행 노드 𝑢는 𝑑 요청을 모든 이웃에게 전달합니다. 수신 노드가 이전에 본 적이 있을 때 요청이 무시됩니다. 그렇지 않으면 𝑣는 로컬에서 𝑑(재귀적)를 검색합니다. Time-to-live(최대 홉 수)에 의해 제한될 수 있습니다.
• 랜덤 워크(Random walk): 노드 𝑢 발행은 임의로 선택된 이웃에게 𝑑 요청을 전달합니다. 𝑣에 𝑑이 없는 경우 임의로 선택된 이웃 중 하나에게 요청을 전달합니다.
슈퍼 피어 네트워크
• 순수 P2P 네트워크에서 대칭을 깨는 것이 현명할 때도 있습니다:
• 비정형 P2P 시스템에서 검색할 때 인덱스 서버가 있으면 성능이 향상됩니다.
• 데이터를 저장할 위치를 결정하는 것은 종종 브로커를 통해 보다 효율적으로 수행될 수 있습니다.
에지 서버 아키텍처
• 서버가 네트워크 가장자리에 배치된 인터넷 상에 배치된 시스템
기업 네트워크와 실제 인터넷 사이의 경계.
에지 서버 아키텍처
• Edge 인프라스트럭처를 보유한 이유
• 레이턴시 및 대역폭: 증강/가상현실 애플리케이션과 같은 특정 실시간 애플리케이션에서 특히 중요합니다. 많은 사람들이 클라우드에 대한 레이턴시 및 대역폭을 과소평가합니다
• 신뢰성: 클라우드에 대한 연결은 신뢰성이 있다고 가정하는 경우가 많은데, 이는 잘못된 가정인 경우가 많습니다. 매우 높은 연결 보증이 다음과 같은 중대한 상황이 발생할 수 있습니다
• 보안 및 개인 정보 보호: 암묵적인 가정은 자산이 근처에 있을 때 자산을 더 잘 보호할 수 있다는 것입니다. 관행에 따르면 이러한 가정은 일반적으로 잘못된 것입니다. 그러나 클라우드에서 데이터 작업을 안전하게 처리하는 것이 조직 내에서보다 더 까다로울 수 있습니다.
클라우드보다 에지에서 리소스를 관리하는 것이 더 까다로울 수 있음
• 자원 할당: 서비스 수행에 필요한 자원의 가용성을 보장해야 합니다
• 서비스 제공 : 서비스 제공 시기와 장소를 결정해야 합니다. 모바일 어플리케이션과 특히 관련이 있습니다
• 에지 선택: 서비스를 제공해야 할 때 어떤 에지 인프라를 사용해야 하는지 결정해야 합니다. 가장 가까운 것이 최선이 아닐 수 있습니다
스레드 소개
• NAT은 물리적 프로세서 위에 소프트웨어로 가상 프로세서를 구축합니다:
• 프로세서: 일련의 명령을 자동으로 실행할 수 있는 기능과 함께 일련의 명령을 제공합니다.
• 프로세스: 하나 이상의 스레드가 실행될 수 있는 소프트웨어 프로세서. 스레드를 실행한다는 것은 해당 스레드의 컨텍스트에서 일련의 명령어를 실행하는 것을 의미합니다.
• 스레드(Thread): 일련의 명령어를 실행할 수 있는 최소한의 소프트웨어 프로세서입니다.
스레드 컨텍스트를 저장한다는 것은 현재 실행을 중지하고 나중에 실행을 계속하는 데 필요한 모든 데이터를 저장한다는 것을 의미합니다.
Thread
콘텍스트 전환
• 콘텍스트
• 프로세서 컨텍스트: 일련의 명령(스택 포인터, 어드레싱 레지스터, 프로그램 카운터)의 실행에 사용되는 프로세서의 레지스터에 저장된 값의 최소 모음입니다.
• 스레드 컨텍스트: 일련의 명령(즉, 프로세서 컨텍스트, 상태)의 실행에 사용되는 레지스터 및 메모리에 저장된 값의 최소 모음입니다.
• 프로세스 컨텍스트: 레지스터 및 메모리에 저장된 값의 최소 모음으로, 스레드의 실행에 사용됩니다(즉, 스레드 컨텍스트이지만 현재는 MMU 레지스터 값 이상).
• 관측치
• 스레드는 동일한 주소 공간을 공유합니다. 스레드 컨텍스트 전환은 운영 체제와 완전히 독립적으로 수행할 수 있습니다.
• 프로세스 전환은 일반적으로 OS를 루프에 포함시키는 것, 즉 커널에 트래핑하는 것을 수반하기 때문에 (어느 정도) 비용이 더 듭니다.
• 스레드를 생성하고 폐기하는 것이 프로세스에 사용하는 것보다 훨씬 저렴합니다.
스레드를 사용하는 이유
• 불필요한 차단 방지
• 단일 스레드 프로세스는 I/O를 수행할 때 차단됩니다. 다중 스레드 프로세스에서는 운영 체제가 CPU를 해당 프로세스의 다른 스레드로 전환할 수 있습니다.
• 병렬성 활용
• 다중 스레드 프로세스의 스레드는 다중 프로세서 또는 다중 코어 프로세서에서 병렬로 실행되도록 예약할 수 있습니다.
• 프로세스 전환 방지
• 대규모 애플리케이션을 프로세스 모음이 아닌 여러 스레드를 통해 구성합니다.
프로세스 전환 방지
• 값비싼 컨텍스트 전환 방지
• 트레이드오프
• 스레드는 동일한 주소 공간을 사용하므로 오류가 발생하기 쉽습니다
• 서로의 메모리를 사용하는 스레드를 보호하기 위해 OS/HW에서 지원하지 않음
• 스레드 컨텍스트 전환이 프로세스 컨텍스트 전환보다 빠를 수 있음
클라이언트 측에서 스레드 사용
• 다중 스레드 웹 클라이언트: 네트워크 지연 시간 숨기기
• 웹 브라우저는 들어오는 HTML 페이지를 검색하고 더 많은 파일을 가져올 필요가 있음을 발견합니다.
• 각 파일은 별도의 스레드에 의해 가져와지며, 각각은 (차단) HTTP 요청을 수행합니다.
• 파일이 들어오면 브라우저에 파일이 표시됩니다.
• 다른 컴퓨터(RPC)에 대한 다중 요청 응답 호출
• 클라이언트는 한 번에 여러 개의 호출을 수행하고, 각각은 다른 스레드에 의해 수행됩니다.
• 그런 다음 모든 결과가 반환될 때까지 기다립니다.
• 다른 서버로 호출하는 경우 선형 속도가 빨라질 수 있습니다.
서버측에서 스레드 사용
• 성능향상
• 스레드를 시작하는 것이 새 프로세스를 시작하는 것보다 저렴합니다.
• 단일 스레드 서버를 사용하는 것은 멀티프로세서 시스템으로의 단순한 스케일업을 금지합니다.
• 클라이언트의 경우와 마찬가지로, 이전 요청이 응답되는 동안 다음 요청에 응답하여 네트워크 지연 시간을 숨깁니다.
• 더 나은 구조
• 대부분의 서버는 I/O 수요가 높습니다. 단순하고 잘 이해된 차단 호출을 사용하면 전체 구조가 단순해집니다.
• 다중 스레드 프로그램은 제어 흐름이 단순화되어 크기가 작고 이해하기 쉬운 경향이 있습니다.
클라이언트측 소프트웨어
• 일반적으로 유통 투명도에 맞게 조정됨
• 액세스 투명성: RPC를 위한 클라이언트측 스터브
• 위치/ 마이그레이션 투명성: 클라이언트 측 소프트웨어가 실제 위치를 추적할 수 있도록 합니다
• 복제 투명성: 클라이언트 스텁에서 처리하는 여러 호출
• 장애 투명성: 종종 클라이언트에만 배치될 수 있습니다(서버 및 통신 장애를 감추려고 합니다).
서버 : 일반조직
• 기본모델
• 클라이언트들의 집합을 대신하여 특정 서비스를 구현하는 프로세스로서, 클라이언트로부터의 착신 요청을 대기하고, 그 후에 그 요청이 처리되도록 하고, 그 후에 다음 착신 요청을 대기하도록 하는 것을 특징으로 하는 방법.
• 동시 서버
• 반복 서버: 서버는 다음 요청에 참여하기 전에 요청을 처리합니다.
• 동시 서버: 디스패처(dispatcher)를 사용하여 수신 요청을 픽업한 다음 별도의 스레드/프로세스로 전달합니다.
• 동시 서버는 일반적으로 여러 요청을 쉽게 처리할 수 있으며, 특히 디스크나 다른 서버에 대한 차단 작업이 있는 경우에도 이를 처리할 수 있습니다.
대역외 통신
• 서비스 요청을 수락(또는 수락 중)한 후 서버를 중단할 수 있습니까?
• 해결책 1: 긴급한 데이터를 위해 별도의 포트 사용
• 서버에 긴급 메시지를 위한 별도의 스레드/프로세스가 있습니다
• 긴급 메시지가 → 관련 요청이 보류됨
• 참고: OS 지원 우선 순위 기반 스케줄링이 필요합니다
• 해결책 2: 수송층의 설비 사용
• 예: TCP는 동일한 연결에서 긴급 메시지를 허용합니다
• OS 시그널링 기법을 사용하여 긴급 메시지를 탐지할 수 있습니다
서버 및 상태
• 상태 비저장 서버
• 요청을 처리한 후 클라이언트의 상태에 대한 정확한 정보를 보관하지 마십시오:
• 파일 열기 여부를 기록하지 않음(액세스 후 다시 닫기만 하면 됨)
• 클라이언트의 캐시를 무효화하겠다고 약속하지 않음
• 고객을 추적하지 않음
• 결과
• 클라이언트와 서버가 완전히 독립적임
• 클라이언트 또는 서버 충돌로 인한 상태 불일치 감소
• 예를 들어, 서버가 클라이언트 동작을 예측할 수 없어 성능이 저하될 수 있음(파일 블록 미리 가져오기)
서버가 인터넷에 퍼질 때
• 서버가 인터넷으로 확산되면 관리상의 문제가 발생할 수 있습니다. 이러한 문제는 단일 클라우드 제공업체의 데이터 센터를 이용함으로써 해결할 수 있습니다.
• 발송요청(현지가 중요한 경우)
• 일반적인 접근 방식: DNS 사용
• 클라이언트는 DNS를 통해 특정 서비스를 검색합니다. 클라이언트의 IP 주소는 요청의 일부입니다
• DNS 서버는 요청된 서비스의 복제본 서버를 추적하고 대부분의 로컬 서버의 주소를 반환합니다
• 클라이언트 투명도
• 클라이언트가 배포를 알 수 없도록 하려면 DNS 확인자가 클라이언트의 역할을 대신하도록 합니다. 문제는 확인자가 실제 클라이언트에서 로컬과 거리가 멀 수 있다는 것입니다.
분산 서버: 세부 정보 처리
• Mobile IPv6를 사용하는 클라이언트는 모든 피어에 대해 투명하게 연결을 설정할 수 있습니다
• 클라이언트 C가 IPv6 홈 주소 HA에 대한 연결을 설정합니다
• HA는 등록된 Care-of-Address CA에 연결을 넘겨주는 (네트워크 수준) 홈 에이전트에 의해 유지 관리됩니다
• 그런 다음 C는 패킷을 주소 CA로 직접 포워딩함으로써(즉, 홈 에이전트를 통한 핸드오프 없이) 경로 최적화를 적용할 수 있습니다.
• 공동 분산 시스템
• 오리진 서버는 홈 주소를 유지하지만, 공동 작업 피어의 주소로 연결을 해제합니다.
오리진 서버와 피어가 하나의 서버로 나타납니다.
코드 마이그레이션
코드를 마이그레이션해야 하는 이유
• 하중분배
• 데이터 센터의 서버에 충분한 부하가 걸리는지 확인합니다(예: 에너지 낭비를 방지합니다).
• 계산이 데이터가 있는 곳에 근접하도록 함으로써 통신을 최소화합니다.
• 유연성: 필요할 때 클라이언트로 코드 이동
기동성이 강하고 약함
• 객체 구성요소
• 코드 세그먼트: 실제 코드를 포함합니다
• 데이터 세그먼트: 상태 포함
• 실행 상태: 개체의 코드를 실행하는 스레드의 컨텍스트를 포함합니다
• 취약한 이동성: 코드 및 데이터 세그먼트만 이동(및 재부팅 실행)
• 특히 코드가 휴대용인 경우 비교적 간단함
• 코드 발송(푸시)과 코드 페칭(풀) 구분
• 강력한 이동성: 실행 상태를 비롯한 구성 요소 이동
• 마이그레이션: 한 컴퓨터에서 다른 컴퓨터로 전체 개체 이동
• 클로닝: 클론을 시작하여 동일한 실행 상태로 설정
이기종 시스템에서의 마이그레이션
• 주요문제
• 대상 컴퓨터가 마이그레이션된 코드를 실행하기에 적합하지 않을 수 있습니다
• 프로세스/스레드/프로세서 컨텍스트의 정의는 로컬 하드웨어, 운영 체제 및 런타임 시스템에 크게 의존합니다
• 유일한 솔루션: 서로 다른 플랫폼에 추상적인 시스템 구현
• 통역 언어, 자체 VM을 효과적으로 보유
• 가상 머신 모니터
가상 시스템 마이그레이션
• 이미지 마이그레이션: 세 가지 대안
• 메모리 페이지를 새 시스템으로 푸시하고 마이그레이션 프로세스 중에 나중에 수정된 페이지를 다시 보냅니다.
• 현재 가상 시스템을 중지합니다. 메모리를 마이그레이션하고 새 가상 시스템을 시작합니다.
• 필요에 따라 새 가상 시스템이 새 페이지를 가져오도록 합니다. 프로세스는 새 가상 시스템에서 즉시 시작되고 메모리 페이지는 요구에 따라 복사됩니다.
가상 시스템 마이그레이션 성능
• 완전한 마이그레이션은 실제로 수십 초가 걸릴 수 있습니다. 또한 마이그레이션 중에는 몇 초 동안 서비스를 완전히 사용할 수 없다는 사실을 인식해야 합니다.
• VM 마이그레이션 중 응답 시간에 대한 측정값