[keyword] 7장 - 기반

[kth990303]

주제

7장 - 기반을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

20

---

@caffeine-library/readers-release-everything

[binchoo]

어디에도 aaS로 끝나는 단어가 보이지 않는다. 서비스형 인프라(IaaS)와 서비스형 플랫폼(PaaS)의 구분은 처음부터 결코 명확하지 않았다. 공급업체들이 전체 지형을 가로지르고 쪼개면서 이런 구분은 완전히 허물어졌다. (p. 208)

💬 지금의 클라우드 컴퓨팅 모델이 서비스 제공자와 이용자 사이의 책임 소재를 명확하게 구분하지 못하고 있다는 저자 의견이 제시되었습니다. IaaS, PaaS, SaaS를 머릿속에서 명확히 구분하고 계신가요? 특히 PaaS의 '플랫폼'이라는 말은 어느 계층에 가져다 붙여도 말이되는 거 같아 저자 의견에 수긍이 가네요. XaaS (anything as a service)가 상당히 많이 보이는 게 사실입니다. AWS Lambda 처럼 Function as a Service도 결국 PaaS라 할 수 있는데, 프로덕트를 강조하는 뉘앙스가 가미된 것 같죠?

호스트 네임과 도메인 네임

컴퓨터 FQDN(호스트네임)을 보고 자기 자신 IP 주소로 변환될 수 있다고 가정한다... 운영 서비스에서는 대부분 맞지 않다. (p. 210)

• 기기 호스트 네임은 hostname 명령어로 보거나 수정 가능. 기기에 부여된 닉네임처럼 생각. 로컬 네트워크 상에서 기기를 구분하는 용도로 이용.
• 도메인 네임은 DNS 질의를 통하여 IP 주소를 얻어서 기기를 식별하는 형태. 도메인 네임과 IP 주소는 다대다 관계.

멀티 호밍

데이터 센터 기기들은 다른 목적으로 멀티호밍된다. 관리와 모니터링을 다른 네트워크로 분리하면 보안이 강화된다... (p. 210)

• 서버 하나에 여러 NIC를 두어(여러 네트워크에 포함시켜) 고가용 구성을 고려할 때
  • 호스트네임은 내부 네트워크에서 기기 식별을 위해 하나면 충분
  • 높은 가용성을 위해서는 DNS 도메인 네임과 모든 IP가 매핑 될 필요
• 계층 내 책임 관점에서 NIC를 분리해 사용할 수 있다는 점이 흥미롭네요!
  • 물론 EC2 인스턴스도 서로 다른 두 VPC나 서브넷에 ENI를 두어 멀티 호밍 가능합니다.
  • SSH 서비스로 기기에게 접근할 수 있는 특정 네트워크를 두고, 운영 네트워크로는 이용할 수 없게 하기.

다수 NIC를 물고 있는 상황에서, 특정 인터페이스에 응용이 종속되려면 개발자가 다음과 같은 코드를 짜야 한다고 합니다. 저는 아무 고민 없이 0.0.0.0을 써 왔기에 모든 인터페이스를 대상으로 응용을 노출한 것이 됩니다 ... 머리가 깨졌습니다.

ln, err := net.Listen("tcp", ":8000") // 좋지 않음
ln, err := net.Listen("tcp", "spock.example.com:8080") // 좋음

여러분들도 목적별 NIC를 두어 서버를 운영해 보셨는지 궁금하네요.

[JasonYoo1995]

• 운영 고려 설계(design for production)는 운영 담당자를 위해 설계한다는 뜻이기도 하다

• 책임 측면에서의 5계층은 아래 그림과 같다

  

• 7장에서는 최하층인 물리적 기반에 대해 살펴볼 예정

7.1 데이터 센터와 클라우드의 네트워크

7.1.1 네트워크 인터페이스와 이름

• 호스트명의 2가지 정의
  • 첫번째 정의
    • 운영 시스템이 자기 자신을 구별하는 데에 사용
    • hostname 명령어를 통해 확인 가능
  • 두번째 정의
    • 다른 컴퓨터 대상 기기에 연결할 때 사용하는 호스트명
    • DNS를 통해 접근
  • 이 2가지 정의의 실제 값은 경우에 따라 서로 불일치 할 수 있음
• DNS 이름과 IP 주소는 다대다 관계
  • 하나의 IP 주소에 대하여 여러 DNS 이름을 할당할 수 있음
  • 분산 서비스에 대해서는 하나의 DNS 이름에 대하여 여러 IP 주소를 가짐

• NIC(network interface controller)는 IP 주소를 가지며 한 컴퓨터는 여러 NIC를 가질 수 있다 (=multihoming)

  
  • 스위치 1, 2는 일반 트래픽을 담당
  • 관리용 스위치는 운영 트래픽을 담당
  • 백업용 스위치는 백업 트래픽을 담당 (대용량 트래픽이며, 별도의 NIC로 분리됨으로써 성능 개선 가능)
  • bonding 또는 teaming
    • ex: 위 그림에서 nic0와 nic1가 하나의 IP 주소를 공유하는 것

7.1.2 다중 네트워크 프로그래밍

• 특정 NIC에서만 소켓을 열려면 호스트명을 지정해야 한다

ln, err := net.Listen("tcp", ":8080") // 모든 NIC 사용
ln, err := net.Listen("tcp", "spock.example.com:8080") // 특정 NIC 사용

7.2 물리 호스트, 가상 머신, 컨테이너

7.2.1 물리 호스트

• 예전
  • 고급 서버가 사용됨
• 요즘
  • 값싼 PC 여러 대에 분산하여 사용됨
    • 언제든 죽을 수 있음
    • 금전적인 비용이 적음
  • 예외로, 고급 서버가 사용되는 경우
    • 대규모 메모리가 필요한 경우
    • GPU 연산이 필요한 경우
• 개별 호스트는 가상 머신 이미지를 보관할 수 있는 정도의 작은 저장 공간만 가짐
  • 실제 사용할 저장 공간은 개별 호스트에 직접 달려있지 않고, 외부로 분리
  • 외부의 대용량 공간 : SAN, NAS

7.2.2 데이터 센터의 가상 머신

• 2000년 초부터 가상화 물결
• 가상 머신의 작동 구조
  • 물리 호스트 안에 여러 가상 머신이 배정됨
  • 호스트 운영체제 : 물리 호스트의 운영체제로 가상화 기능을 제공
  • 게스트 운영체제 : 가상 머신에서 작동
• 가상 머신의 본래 약속 (이상적인 이론)
  • 물리 머신을 이용하면 활용률(Utilization)이 낮으나 가상 머신을 이용하면 활용률과 관리 용이성이 높다
• 가상 머신의 현실 (단점)
  • 물리 호스트의 한정된 자원에 비해 가상 머신들이 과대 배정되어 가상 머신 입장에서 자원 부족 및 가상 머신 간 경합 발생으로 성능 저하 및 불안정 발생
    • ex) 물리 호스트의 코어는 16개이지만 물리 호스트 내 모든 가상 머신이 필요로 하는 코어는 32개일 수 있음
    • ex) CPU, 메모리, 네트워크 등 모든 자원에 대하여 과대 배정될 수 있음
  • 물리 호스트가 죽는 것에 대한 리스크가 배로 증대됨
  • 물리 머신도 시계에 대한 오차가 발생할 수 있으나 가상 머신은 시계에 대한 오차 발생 가능성이 더 큼 → NTP 서버 같은 외부 시계를 사용하여 해결 가능

7.2.3 데이터 센터의 컨테이너

• 컨테이너의 본래 약속 (이상적인 이론)
  • 프로세스의 격리와 가상 머신의 패키지화를 동시 제공
  • 운영 환경과 QA 환경 간 구분 불필요
• 컨테이너의 현실 (단점)
  • 수명이 짧고 재배정된다는 특징으로 인해 오래된 모니터링 시스템으로는 모니터링이 어려움
  • 컨테이너는 자체 저장 공간이 작아서 파일/데이터는 물론 캐시까지도 외부 저장소에 의존해야 함
  • 컨테이너는 자체 가상 인터페이스상의 포트를 호스트에 노출하지 않아 수동 포트 포워딩이 아니고서는 호스트와의 포트 연결 불가
    • 오버레이 네트워크 패턴을 통해 해결 가능 (가상 랜으로 포트 연결 가능)
  • 컨테이너를 어떤 머신 내에 배정할지에 대한 자동 배정 메커니즘 설계 필요
  • DB 접속 정보, 네트워크 정보 등이 컨테이너 이미지 내에 있으면 안 되고 외부에 저장되어 있다가, 컨테이너 초기화 후 주입되어야 함 (+보안화 필요)
  • 시동 시간이 긴 서버는 컨테이너화 되어선 안 됨 (총 시동 시간은 1초에 맞출 것)
  • 컨테이너 내 애플리케이션은 디버깅 및 로그 접근에 대한 난이도가 비교적 높음

7.2.4 클라우드 내 가상 머신

• 가상 머신 사용 시 발생 가능한 이슈
  • 가상 머신은 물리 머신에 비해 가용성이 낮음
    • 물리 호스트가 관리용 API를 통해, 가상 머신을 시작/종료 시킬 수 있음
    • 물리 호스트 내 가상 머신들 간에 자원 경합 발생 가능
    • 아무런 이유 없이 가상 머신이 중단될 수 있음
    • ex) AWS에서 오랫동안 작동 중인 가상 머신에 대하여 재실행해야 하며 그렇지 않을 경우 문제가 생길 거란 고지를 받을 수 있음
  • 가상 머신 재실행 시 (Elastic IP를 사용하지 않으면) 기기 ID와 IP 주소가 변경됨
  • 가상 머신은 (NIC 추가 설치하지 않는 한) 1개의 NIC만 가져 약 64,000개 정도의 연결만 수용 가능
    • 관리 및 모니터링 용 NIC도 별도 추가해야 할 수 있음

7.2.5 클라우드 내 컨테이너

• 서로 다른 리전에 위치한 컨테이너들을 서로 연결해야 할 수도 있음
• 나머지 내용들은 ‘데이터 센터 내 컨테이너’에서의 이슈과 비슷