DevOps 전제조건: 반드시 이해해야 할 “지루한” 기본 원칙

Source: Dev.to

DevOps Day 0

• 네트워크는 기본적으로 신뢰할 수 없습니다
  패킷은 손실, 지연, 중복, 순서 뒤바뀜이 발생할 수 있습니다.
  신뢰성은 네트워크가 보장하는 것이 아니라 프로토콜이 추가하는 것입니다.

  이 한 가지 생각이 다음을 설명합니다:

  • 재시도
  • 타임아웃
  • 느려짐
  • “무작위” 오류

• IP 주소는 머신을 식별합니다

  • 네트워크에 연결된 모든 장치는 고유한 IP가 필요합니다.
  • IP = 머신이 누구인지.
  • 프라이빗 IP는 내부에서 사용됩니다.
  • 퍼블릭 IP는 인터넷에서 사용됩니다.
  • 라우터는 NAT를 사용해 여러 프라이빗 IP를 하나의 퍼블릭 IP에 매핑합니다.
  • 두 머신이 같은 IP를 공유하면 → 통신이 끊깁니다.

• 포트는 서비스를 식별합니다

  • 하나의 머신에서 여러 서비스를 실행할 수 있습니다.
  • 각 서비스는 포트에서 수신 대기합니다.
  • 한 포트당 동시에 하나의 서비스만 가능합니다.

  서비스를 주소 지정한다는 것은:

  IP + Port

  예시:

  192.168.1.10:443

• 통신을 위해 필요한 세 가지
  한 머신이 다른 머신과 대화하려면:

  1. 올바른 IP (머신)
  2. 올바른 Port (서비스)
  3. 열린 네트워크 경로 (라우팅 + 방화벽)

  이 중 하나라도 실패하면 → 통신이 이루어지지 않습니다.

TCP vs UDP (두 가지 신뢰성 전략)

UDP

• 빠름
• 전달 보장 없음
• 재시도 없음
• 순서 보장 없음
• 오버헤드 낮음

사용 상황: 속도가 정확도보다 중요하고, 재시도가 저렴할 때.
예시: DNS, 비디오 스트리밍, 메트릭스.

TCP

• 신뢰성 있음
• 전달 보장
• 데이터 순서 보장
• 손실된 패킷 재전송
• 오버헤드 때문에 느림

사용 상황: 정확도가 중요할 때.
예시: HTTP/HTTPS, 데이터베이스, API, SSH.

실제 시스템에서의 실패 모습

UDP 실패

• 데이터 누락
• 불안정한 동작
• 빠른 실패

TCP 실패

• 지연 증가
• 요청이 걸림
• 조용한 느려짐

UDP는 빠르게 실패하고, TCP는 느리게 실패합니다.

DNS는 기본적으로 UDP를 사용합니다

DNS가 UDP를 선택하는 이유:

• 요청이 작음
• 연결 설정 비용이 큼
• 재시도가 대기보다 저렴함

필요에 따라 DNS는 TCP로 전환할 수 있습니다 (큰 응답, DNSSEC 등).

세 가지 가능한 연결 결과 (핵심)

IP:PORT에 연결할 때:

• ✅ 성공

  • 서비스가 실행 중
  • 네트워크 경로가 열려 있음

• ❌ Connection refused

  • 머신은 도달 가능
  • 해당 포트에 서비스가 없음 → 애플리케이션/포트 문제

• ⏳ Connection timeout

  • 서비스에 도달 불가
  • 패킷이 차단되었거나 손실됨 → 네트워크/방화벽 문제

리스닝 범위가 중요합니다

서비스는 다음 중 하나에 리스닝할 수 있습니다:

• localhost → 같은 머신에서만 접근 가능
• 0.0.0.0 → 어디서든 접근 가능

이 때문에 흔히 “내 컴퓨터에서는 동작한다”는 문제가 발생합니다.

Core Day 0 Mental Model (꼭 기억하세요)

• IP = 누구
• Port = 무엇
• Protocol = 어떻게
• Firewall = 여부
• DNS = 편의성

이 네 가지를 논리적으로 생각할 수 있다면 대부분의 장애를 디버깅할 수 있습니다.