날마다 새로워

[개념]

🔐 랜섬웨어 개요

1. 정의

랜섬웨어는 악성코드(멀웨어, Malware)의 한 종류로, 감염된 시스템의 파일을 암호화하거나 접근을 차단한 뒤, 이를 해제하기 위해 금전(주로 암호화폐)을 요구하는 공격 형태입니다.
‘Ransom(몸값)’과 ‘Software(소프트웨어)’의 합성어입니다.

2. 주요 특징

• 파일 암호화
  문서, 사진, 데이터베이스 등 주요 파일을 강력한 암호화 알고리즘(AES, RSA 등)으로 암호화하여 사용자가 접근하지 못하게 함.
• 금전 요구
  암호 해제(복호화) 키를 제공하는 대가로 비트코인 또는 모네로 같은 추적이 어려운 암호화폐를 요구.
• 사회공학 기법 활용
  이메일 피싱, 악성 링크, 가짜 프로그램 업데이트 등을 통해 사용자를 속여 감염.
• 이중 갈취(Double Extortion)
  최근에는 단순 암호화뿐 아니라 내부 데이터를 외부로 유출한 뒤, 이를 유포하겠다고 협박하는 방식도 활용.

3. 감염 경로

• 피싱 이메일 첨부파일 (MS Office 매크로, 악성 PDF 등)
• 악성 웹사이트/광고(Drive-by Download)
  사용자가 클릭하지 않아도 브라우저 취약점을 이용해 설치.
• 원격 데스크톱(RDP) 취약점 공격
• 공급망 공격 (악성 코드가 포함된 소프트웨어 업데이트)
• USB 및 외장 저장장치를 통한 전파

4. 주요 종류

• Crypto Ransomware
  파일을 암호화하는 형태 (예: CryptoLocker, WannaCry, REvil)
• Locker Ransomware
  OS 전체를 잠그고 로그인을 못하게 하는 형태
• Ransomware-as-a-Service(RaaS)
  다크웹에서 서비스 형태로 판매·배포하는 모델

5. 피해 영향

• 데이터 영구 손실 위험
• 업무 중단 및 서비스 마비
• 금전적 피해 + 평판 손실
• 법적 책임 (개인정보 유출 시 GDPR, 개인정보보호법 위반 등)

6. 랜섬웨어 예방 방법

1. 데이터 백업
   • 주기적으로 중요한 데이터를 백업하고,
     오프라인 저장 장치 또는 백업 전용 네트워크를 사용
   • 백업이 온라인 상태로 연결돼 있으면 함께 암호화될 수 있으니 주의
2. 운영체제 및 소프트웨어 최신화
   • Windows, Linux, macOS 등 OS 보안 패치 최신 유지
   • Office, 브라우저, 플러그인 등 애플리케이션도 최신 버전 유지
3. 이메일 보안 강화
   • 의심스러운 첨부파일/링크 클릭 금지
   • 매크로(Office Macro) 자동 실행 방지
4. 권한 최소화 원칙(Principle of Least Privilege) 적용
   • 불필요한 관리자 권한 제공 금지
   • RDP(원격데스크톱) 접근 제한 및 VPN 등 안전한 접속 수단 사용
5. 보안 솔루션 사용
   • 엔드포인트 보안(EPP/EDR) 제품
   • 네트워크 침입탐지/방지(IDS/IPS) 시스템
6. 사용자 보안 교육
   • 피싱 메일 식별 방법
   • 의심스러운 파일/링크 신고 프로세스
7. 다단계 인증(MFA) 적용
   • 계정 탈취를 통한 내부 침투 방지

7. 대응 방법 (감염 시)

• 즉시 네트워크 분리 → 감염 확산 차단
• 백업 데이터로 복구 (감염 전 상태로)
• 몸값 지불은 지양
  • 지불하더라도 복호화 키를 받지 못하거나, 또다시 공격받을 위험
• 수사 기관 신고
  • 국내: 경찰청 사이버범죄수사대, 한국인터넷진흥원(KISA) 등

📌 결론
랜섬웨어는 단순히 보안 솔루션 하나로 막기 어렵고,
백업 + 보안 패치 + 사용자 교육이 3대 핵심 예방책입니다.
기업 환경에서는 EDR, 네트워크 세분화, 다단계 인증, 사고 대응 프로세스까지 포함한 종합 전략이 필요합니다.

랜섬웨어 (Ransomware) 💰

랜섬웨어는 시스템을 잠그거나 파일을 암호화하여 접근을 막은 뒤, 이를 풀어주는 대가로 금전을 요구하는 악성 소프트웨어입니다. 랜섬웨어는 파일을 인질(Ransom)로 잡는다고 해서 붙여진 이름으로, 최근에는 기업을 대상으로 한 공격이 증가하고 있습니다.

• 주요 감염 경로:
  • 이메일 첨부 파일: 악성 매크로가 포함된 문서 파일을 열거나, 악성 URL 링크를 클릭할 때.
  • 취약점 공격: 패치되지 않은 서버, 소프트웨어, 네트워크 장비의 보안 취약점을 이용해 침투.
  • 무단 원격 접속: 비밀번호가 취약한 원격 데스크톱 프로토콜(RDP) 포트를 통해 무단 침입.

랜섬웨어 복구 방안 🛡️

랜섬웨어에 감염되었을 때 가장 중요한 것은 돈을 지불하지 않고 데이터를 복구하는 것입니다. 돈을 지불해도 복구를 보장할 수 없으며, 추가 공격의 빌미를 제공할 수 있기 때문입니다.

1. 네트워크 격리: 감염된 서버를 즉시 네트워크에서 분리하여 추가 확산을 막아야 합니다.
2. 백업 활용: 가장 효과적인 복구 방안입니다. 랜섬웨어는 원본 파일을 암호화하므로, 감염 전의 시점으로 백업된 데이터를 복원하여 시스템을 정상화합니다.
3. 랜섬웨어 복구 툴: 일부 랜섬웨어는 암호화 방식이 알려져 있어, 보안 업체가 제공하는 복호화 툴로 파일을 복원할 수 있습니다.
4. 시스템 재설치: 감염된 OS는 재사용하지 않고 완전히 포맷한 후, 클린 설치해야 합니다.

서버 내에서 맞이할 수 있는 상황 예시 🚨

회사 서버 관리자인 당신은 평소처럼 서버 상태를 확인하던 중, 다음과 같은 이상 징후를 발견했습니다.

1. 파일 확장자 변경: 서버의 중요한 데이터가 저장된 폴더 내 모든 파일의 확장자가 . 뒤에 알 수 없는 문자열(예: .encrypted, .locky)로 변경되어 있습니다.
2. 랜섬 노트 발견: 각 폴더 내에 README_TO_DECRYPT.txt 또는 HOW_TO_RECOVER_FILES.html과 같은 파일이 생성되어 있습니다. 이 파일에는 비트코인을 요구하는 메시지와 복호화 방법이 담겨 있습니다.
3. CPU/디스크 사용량 급증: 특정 시점에 시스템의 CPU와 디스크 I/O 사용량이 비정상적으로 치솟았다가 다시 안정화되는 패턴이 관찰됩니다. 이는 랜섬웨어가 파일을 암호화하는 과정에서 발생하는 전형적인 현상입니다.
4. 관리자 계정 접속 기록: 시스템 로그에서 평소 사용하지 않던 해외 IP 대역에서 RDP를 통해 관리자 계정으로 접속을 시도하거나 성공한 기록을 발견했습니다.

대처 방안:

1. 즉시 격리: 서버의 네트워크 케이블을 분리하거나, 방화벽 규칙을 추가하여 외부 통신을 차단합니다.
2. 상황 파악: 감염된 서버와 범위를 확인하고, 어떤 종류의 랜섬웨어인지 파악합니다.
3. 복구 절차 실행: 최근에 생성한 백업본을 이용하여 시스템을 복원합니다.
4. 근본 원인 해결: 침투 경로(예: 취약한 RDP 비밀번호, 미패치된 OS)를 찾아 해결하고, 시스템의 보안 설정을 강화합니다.

BPFDoor 🚪

BPFDoor는 지속적인 감시와 원격 액세스를 위해 설계된, 탐지하기 어려운 백도어 악성코드입니다. 이 악성코드의 가장 큰 특징은 **네트워크 필터링 기술(BPF)**을 사용하여 특정 조건의 패킷만 선별적으로 수신하며, 일반적인 네트워크 트래픽에 섞여 있어 방화벽이나 보안 솔루션을 우회하기 쉽다는 점입니다.

• BPF(Berkeley Packet Filter)란?: 리눅스 커널의 패킷 필터링 기술입니다. BPF는 특정 조건을 만족하는 패킷만 캡처하여 처리할 수 있게 해주며, tcpdump 같은 도구에서 사용됩니다. BPFDoor는 이 기능을 악용하여, 특정 소스 IP, 포트, 패킷 시그니처 등을 가진 '마법의 패킷'이 도착했을 때만 활성화됩니다.
• 작동 방식: BPFDoor는 보통 서버에 설치된 후, 평소에는 아무런 활동 없이 대기 상태를 유지합니다. 공격자가 미리 정해놓은 '트리거' 패킷을 보내면, BPFDoor는 이를 감지하고 원격 명령 실행, 데이터 유출 등의 악성 행위를 수행합니다. 트리거 패킷은 일반적인 HTTP, DNS 트래픽처럼 보일 수 있어 탐지가 어렵습니다.

최근 서버 내에서 맞이할 수 있는 상황 예시

회사 서버의 보안 담당자인 A씨는 최근 다음과 같은 상황을 겪었습니다.

1. 이상한 네트워크 트래픽: 서버 모니터링 시스템에서 평소에는 보이지 않던 알 수 없는 IP 대역에서 DNS 쿼리 트래픽이 간헐적으로 유입되는 것을 발견했습니다. 쿼리 내용 자체는 정상적인 도메인처럼 보였지만, 빈도가 비정상적이었습니다.
2. 로그 파일의 불일치: 로그를 분석하던 중, 외부 IP로부터 whoami나 ls -al 같은 셸(Shell) 명령어가 실행된 흔적을 발견했습니다. 하지만 시스템 접속 기록(SSH)이나 웹 로그에는 해당 IP의 정상적인 접근 기록이 전혀 없었습니다.
3. 시스템의 미묘한 성능 저하: 특정 시간에 CPU와 네트워크 사용량이 소폭 증가하는 현상이 반복되었지만, 어떤 프로세스 때문인지 명확하게 파악되지 않았습니다.

BPFDoor 감염의 가능성:

이러한 상황은 전형적인 BPFDoor 공격의 징후일 수 있습니다.

• DNS 쿼리 트래픽: 공격자가 BPFDoor를 활성화하기 위한 트리거 패킷으로 DNS 트래픽을 사용했을 가능성이 높습니다. DNS 트래픽은 방화벽을 쉽게 통과하기 때문에 악용하기 쉽습니다.
• 접근 기록 없는 셸 실행: BPFDoor가 성공적으로 '마법의 패킷'을 수신하여 활성화되면, 접근 기록을 남기지 않고 원격에서 직접 명령어를 실행할 수 있습니다.
• 미묘한 성능 저하: 백도어는 평소에는 비활성 상태로 대기하며 시스템 자원을 거의 사용하지 않지만, 활성화될 때만 일시적으로 자원을 소모합니다. 이는 일반적인 악성코드처럼 지속적으로 CPU를 소모하는 것과 다른 패턴입니다.

대응 방안: A씨는 다음과 같은 조치를 통해 문제를 해결해야 합니다.

1. 네트워크 트래픽 분석: tcpdump를 사용하여 의심스러운 DNS 트래픽을 더 정밀하게 캡처하고 분석합니다.
2. 시스템 파일 검사: 시스템 파일의 무결성을 검사하고, 의심스러운 파일이나 프로세스가 없는지 확인합니다.
3. BPF 필터링 검사: bpftool과 같은 리눅스 명령어를 사용하여 의심스러운 BPF 프로그램이 커널에 로드되어 있는지 확인합니다.

문제

어느 날 한 Linux 서버에서 다음과 같은 징후가 발견되었습니다.

• /tmp 디렉토리의 용량이 갑자기 빠르게 차오르기 시작함
• ps aux | grep java 명령어를 사용하면 기존에 없던 여러 개의 Java 프로세스가 생성되어 있음
• 시스템에 nohup 을 이용한 작업이 없었음에도 불구하고, /tmp/nohup.out 파일이 점점 커짐
• root 사용자의 crontab에는 이상이 없음

질문 1

위와 같은 상황에서 /tmp/nohup.out 파일이 계속 커지는 원인을 분석하고, 시스템 관리자의 조치 방법을 기술하세요.

질문 2

이러한 일이 다시 발생하지 않도록 /tmp 디렉토리의 악의적인 자동 실행을 막는 보안 설정 2가지를 설명하세요.

[개념]

장애상황은 무조건 조치 부터 진행!

리눅스 포트 트래픽 증가 장애 상황

리눅스 서버에서 특정 포트의 트래픽이 급증하는 상황은 여러 가지 원인으로 인해 발생할 수 있습니다. 이는 서버의 성능 저하, 네트워크 지연, 심지어는 서비스 중단으로 이어질 수 있는 심각한 장애 상황입니다.

장애 시나리오: 웹 서버 포트(80번) 트래픽 증가

웹 서버를 운영 중인 리눅스 서버에서 80번 포트의 트래픽이 평소보다 10배 이상 증가했습니다. 시스템 관리자는 top 명령어로 CPU 사용량은 정상적인데, 네트워크 I/O만 급증하는 것을 확인했습니다.

원인 및 대처 방법

이러한 상황은 크게 두 가지 원인으로 볼 수 있으며, 원인에 따라 대처 방법이 달라집니다.

1. 합법적인 트래픽 증가 (플래시 크라우드)

대량의 사용자 유입이나 언론 보도, 이벤트 등으로 인해 갑자기 접속자가 폭증하는 상황입니다.

• 진단:
  • netstat -an | grep :80 | wc -l 명령어로 연결된 세션 수를 확인합니다. 평소보다 세션 수가 급증했다면, 정상적인 트래픽 증가일 가능성이 높습니다.
  • tcpdump -i eth0 port 80 -n -c 100 명령어로 패킷을 캡처하여 트래픽의 소스와 유형을 확인합니다.
• 대처 방법:
  1. 애플리케이션 스케일 아웃: 웹 서버(예: Apache, Nginx)의 워커 프로세스 수를 늘려 동시에 처리할 수 있는 요청 수를 증가시킵니다.
  2. 부하 분산: L4/L7 스위치나 클라우드 로드 밸런서를 사용하여 여러 서버로 트래픽을 분산합니다.
  3. 캐싱: 정적 콘텐츠나 자주 접근하는 동적 콘텐츠를 CDN(Content Delivery Network) 또는 Redis와 같은 캐시 서버에 저장하여 웹 서버의 부하를 줄입니다.

2. 비정상적인 트래픽 증가 (DDOS 공격 또는 포트 스캐닝)

악의적인 공격자가 서버의 특정 포트를 대상으로 대량의 트래픽을 보내는 상황입니다.

• 진단:
  • tcpdump -i eth0 port 80 -n 'tcp[tcpflags] & (tcp-syn) != 0 and (tcp[tcpflags] & tcp-ack) = 0' 명령어를 실행하여 SYN 패킷이 비정상적으로 많이 들어오는지 확인합니다.
  • netstat -an | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10 명령어로 가장 많은 연결을 시도하는 IP 주소를 식별합니다. 특정 IP나 소수 IP 대역에서 연결이 집중된다면, 공격일 가능성이 높습니다.
• 대처 방법:
  1. 방화벽(iptables) 차단: 비정상적인 트래픽을 보내는 IP 주소나 IP 대역을 방화벽에서 즉시 차단합니다.
  2. L4/L7 스위치 또는 WAF 사용: DDoS Protection 기능이 있는 L4 스위치나 웹 애플리케이션 방화벽(WAF)을 사용하여 비정상적인 트래픽을 필터링합니다.
  3. 네트워크 대역폭 증설: 일시적인 대처 방법으로 네트워크 대역폭을 늘려 트래픽을 수용할 수 있는 용량을 확장합니다.

[개념]

가상화 환경에서 캐시 미스(cache miss)는 필요한 데이터가 캐시에 없을 때 발생하며, 경합(contention)은 여러 프로세스나 스레드가 동일한 자원(예: 캐시 라인)에 접근하려 할 때 발생합니다. 가상화 환경에서는 이러한 현상들이 성능 저하의 주요 원인이 될 수 있습니다. 캐시 미스 (Cache Miss):

• 정의:
  가상 머신(VM)이나 컨테이너 등 가상화 환경에서, CPU가 데이터를 접근하려 할 때 해당 데이터가 캐시에 없어서 메인 메모리나 스토리지에서 데이터를 가져와야 하는 상황을 의미합니다.
• 원인:
  • 새로운 데이터 요청: 가상 머신이 처음으로 데이터를 요청하거나, 기존 캐시에 없는 데이터를 요청할 때 발생합니다.
  • 캐시 공간 부족: 캐시 크기가 제한적이어서 자주 사용되지 않는 데이터가 캐시에서 제거될 때 발생합니다.
  • 데이터 지역성 부족: 데이터 접근 패턴이 예측 가능하지 않아 캐시 효율성이 떨어질 때 발생합니다.
• 영향:캐시 미스가 발생하면 메모리 접근 지연으로 인해 전체적인 시스템 성능이 저하됩니다. 특히, 가상화 환경에서는 여러 VM들이 공유 자원을 사용하므로 캐시 미스가 빈번하게 발생할 수 있습니다. 

경합 (Contention):

• 정의:
  가상화 환경에서 여러 VM이나 스레드가 동시에 동일한 캐시 라인이나 공유 자원에 접근하려고 할 때 발생합니다.
• 원인:
  • 다중 사용자 환경: 여러 사용자가 동시에 가상 머신에 접속하여 작업을 수행할 때, 각 사용자의 작업이 공유 자원에 영향을 줄 수 있습니다.
  • 높은 부하: 시스템에 부하가 높을 때, CPU, 메모리, 디스크 등 공유 자원에 대한 접근 경쟁이 심화됩니다.
  • 비효율적인 캐시 정책: 캐시 관리 정책이 효율적이지 않으면, 여러 VM들이 같은 데이터를 캐싱하여 경합을 유발할 수 있습니다.
• 영향:경합이 심해지면, 캐시 라인의 갱신 지연, 데이터 손실, 시스템 충돌 등의 문제가 발생할 수 있습니다. 특히, 가상화 환경에서는 여러 VM 간의 경합으로 인해 성능 저하나 불안정성이 발생할 수 있습니다.

가상화 환경에서의 캐시 미스 및 경합 관리:

• 캐시 라인 크기 최적화:
  캐시 라인 크기를 적절하게 조정하여 캐시 효율성을 높입니다.
• 캐시 알고리즘 개선:
  캐시 적중률을 높이는 캐시 알고리즘(예: LRU, FIFO 등)을 사용합니다.
• 가상 머신 간 자원 분배:
  각 가상 머신에 적절한 CPU, 메모리, 스토리지 자원을 할당하여 경합을 줄입니다.
• 캐시 일관성 유지:
  여러 VM에서 공유하는 데이터의 일관성을 유지하기 위한 프로토콜을 사용합니다.
• 가상화 기술 활용:하이퍼바이저, 컨테이너 기술 등을 활용하여 자원 관리를 효율적으로 수행합니다. 

가상화 환경에서 캐시 미스와 경합을 효과적으로 관리하는 것은 시스템 성능을 최적화하고 안정성을 확보하는 데 매우 중요합니다.

캐시 미스 (Cache Miss)

캐시 미스는 CPU가 필요한 데이터나 명령어를 **캐시(Cache)**에서 찾지 못하고, 더 느린 저장소(예: 주 메모리)에서 데이터를 가져와야 할 때 발생하는 현상입니다.

• 작동 방식: CPU는 데이터를 처리할 때 먼저 속도가 빠른 캐시 메모리에 해당 데이터가 있는지 확인합니다. 캐시 히트(Cache Hit)는 데이터가 캐시에 있어 즉시 처리하는 경우이고, 캐시 미스는 데이터가 없어 주 메모리에서 가져와야 하는 경우입니다.
• 가상화 환경의 영향: 가상화 환경에서는 여러 가상 머신(VM)이 하나의 물리적 CPU 캐시를 공유합니다. 이로 인해 한 VM이 사용하던 캐시 공간을 다른 VM이 덮어쓰면서 캐시 미스율이 높아질 수 있습니다. 캐시 미스가 많아지면 CPU의 처리 속도가 느려져 전체 시스템 성능이 저하됩니다.

자원 경합 (Resource Contention)

자원 경합은 여러 VM이 **제한된 물리적 자원(CPU, 메모리, 스토리지 I/O)**을 동시에 사용하려고 할 때 발생하는 현상입니다.

• 작동 방식: 하이퍼바이저는 물리적 서버의 자원을 여러 VM에게 할당하고 스케줄링합니다. 하지만 VM들의 자원 요구량이 물리적 자원 한계를 초과하면 경합이 발생합니다.
• 가상화 환경의 영향:
  • CPU 경합: 여러 VM이 동시에 CPU를 과도하게 사용하려 할 때 발생합니다. 하이퍼바이저는 CPU 시간을 VM들에게 나눠주지만, 이 과정에서 VM은 자신의 CPU 작업을 완료하기 위해 대기해야 합니다.
  • 메모리 경합: VM이 필요한 메모리보다 물리적 메모리가 부족할 때 발생합니다. 이 경우 하이퍼바이저는 메모리 오버커밋(Overcommit)을 통해 물리적 메모리를 VM들 간에 공유하며, 이는 시스템 스와핑(Swapping)을 유발하여 성능 저하를 일으킵니다.
  • 스토리지 I/O 경합: 여러 VM이 동시에 디스크에 데이터를 읽거나 쓰려고 할 때 발생합니다. 디스크의 I/O 처리량에는 한계가 있어, 요청이 대기열에 쌓이면서 지연이 발생합니다.

가상화에서 캐시 미스와 경합의 관계

가상화 환경에서 캐시 미스는 자원 경합의 한 형태로 볼 수 있습니다. 여러 VM이 CPU 자원을 공유하는 과정에서 CPU 캐시를 효율적으로 사용하지 못해 캐시 미스가 증가하고, 이는 결국 CPU 자원 경합을 심화시켜 시스템 성능 저하로 이어집니다.

서버 가상화는 하나의 물리적 서버를 여러 개의 가상 서버로 나누어 사용하는 기술입니다. 이 기술은 크게 하이퍼바이저 기반 가상화, 컨테이너 기반 가상화, 운영체제 수준 가상화로 나눌 수 있습니다.

1. 하이퍼바이저 기반 가상화 (Hypervisor-based Virtualization)

가상화 기술의 가장 전통적인 방식입니다. 하이퍼바이저라는 소프트웨어가 물리적 서버와 가상 머신(VM) 사이의 중개자 역할을 합니다.

• 종류:
  • Type 1 (베어메탈): 하이퍼바이저가 운영체제 없이 하드웨어에 직접 설치됩니다. VMware ESXi, Microsoft Hyper-V, Citrix XenServer 등이 있습니다. 성능이 가장 우수하여 엔터프라이즈 환경에서 주로 사용됩니다.
  • Type 2 (호스트형): 하이퍼바이저가 기존 운영체제(Windows, Linux 등) 위에 애플리케이션처럼 설치됩니다. VMware Workstation, VirtualBox 등이 있습니다. 사용하기 쉽지만, 하이퍼바이저가 호스트 OS의 영향을 받으므로 성능은 Type 1보다 떨어집니다.
• 특징:
  • 완전한 격리: 각 가상 머신은 자체 OS와 리소스를 가지므로, 서로 완벽하게 격리됩니다.
  • 높은 유연성: 다양한 OS(Windows, Linux 등)를 하나의 물리적 서버에서 동시에 실행할 수 있습니다.
  • 자원 소모: 각 VM이 자체 OS를 포함하므로, 컨테이너에 비해 메모리, 디스크 등 자원 소모가 큽니다.

2. 컨테이너 기반 가상화 (Container-based Virtualization)

호스트 OS 위에 컨테이너 엔진을 설치하고, 이 엔진이 여러 개의 컨테이너를 관리하는 방식입니다.

• 종류: Docker, LXC, Podman 등이 대표적입니다.
• 특징:
  • OS 공유: 모든 컨테이너가 호스트 OS의 커널을 공유합니다. 이로 인해 VM보다 가볍고 빠르게 시작할 수 있습니다.
  • 낮은 오버헤드: VM처럼 OS를 따로 설치할 필요가 없어, 자원 소모가 매우 적습니다.
  • 높은 이식성: 컨테이너 이미지를 한 환경에서 다른 환경으로 쉽게 이동할 수 있어 개발 및 배포에 매우 효율적입니다.
  • 제한된 격리: VM만큼 완벽한 격리는 불가능하며, 컨테이너 내에서 커널 수준의 보안 취약점이 발생하면 호스트 OS에 영향을 미칠 수 있습니다.

3. 운영체제 수준 가상화 (OS-level Virtualization)

컨테이너와 유사하지만, 특정 OS에 종속되어 동작하는 방식입니다.

• 종류: OpenVZ, Solaris Zones, BSD Jails 등이 있습니다.
• 특징:
  • 단일 OS: 동일한 운영체제만 가상화할 수 있습니다. 예를 들어, 리눅스 서버에서는 리눅스만, 솔라리스 서버에서는 솔라리스만 가상화할 수 있습니다.
  • 낮은 오버헤드: 컨테이너처럼 OS 커널을 공유하므로, 자원 효율이 뛰어납니다.
  • 용도: 특정 OS 환경 내에서 격리된 환경을 제공하는 데 사용됩니다.

비교 요약

데이터베이스(DB) 이중화는 하나의 DB를 여러 개로 복제하여 장애에 대비하고 서비스의 안정성과 가용성을 높이는 기술입니다. 주로 액티브-스탠바이와 액티브-액티브 방식으로 나뉩니다.

DB 이중화의 필요성

DB는 시스템의 핵심이므로, DB에 장애가 발생하면 전체 서비스가 중단될 수 있습니다. DB 이중화는 다음과 같은 목적을 위해 필요합니다.

• 고가용성(High Availability): 주 DB에 문제가 생겨도 다른 DB가 즉시 서비스를 대신하여 중단 없는 서비스를 제공합니다.
• 재해 복구(Disaster Recovery): 지리적으로 떨어진 다른 곳에 DB를 복제하여 자연재해나 대규모 장애에 대비합니다.
• 부하 분산: 여러 DB에 요청을 분산시켜 시스템의 성능을 향상시킵니다.

1. 액티브-스탠바이 (Active-Standby)

이 방식은 하나의 DB만 활성화(Active)되고, 다른 DB는 대기(Standby) 상태로 있다가 주 DB에 장애가 발생하면 활성화되는 방식입니다.

• 동작 방식: 주(Primary) DB에서 발생한 모든 변경 사항이 실시간으로 대기(Standby) DB로 복제됩니다.
• 장점:
  • 데이터 일관성 유지: 한쪽만 쓰기 작업을 하므로 데이터 충돌이 발생하지 않아 일관성을 유지하기 쉽습니다.
  • 구현 용이성: 액티브-액티브에 비해 구조가 단순하여 구현과 관리가 비교적 쉽습니다.
• 단점:
  • 자원 낭비: 스탠바이 DB는 평소에 아무 역할도 하지 않으므로 컴퓨팅 자원이 낭비됩니다.
  • 서비스 중단: 장애 발생 시 스탠바이 DB로 전환하는 짧은 시간 동안 서비스가 중단될 수 있습니다.
• 예시: A 지점의 DB 서버가 주 DB 역할을 하고, B 지점의 DB 서버가 대기 상태로 A의 데이터를 실시간으로 복제합니다. A 서버에 장애가 발생하면, B 서버가 즉시 액티브로 전환하여 서비스를 이어갑니다.

2. 액티브-액티브 (Active-Active)

이 방식은 두 개 이상의 DB가 동시에 활성화되어 요청을 처리하는 방식입니다.

• 동작 방식: 모든 DB가 읽기/쓰기 작업을 동시에 수행하며, 각 DB에서 발생한 변경 사항을 서로에게 실시간으로 복제합니다.
• 장점:
  • 자원 활용 극대화: 모든 DB가 동시에 사용되므로 자원 낭비가 없습니다.
  • 높은 성능: 부하를 여러 DB에 분산시켜 성능을 향상시킵니다.
  • 무중단 서비스: 한쪽에 장애가 발생해도 다른 DB가 이미 활성화되어 있어 서비스 중단이 발생하지 않습니다.
• 단점:
  • 데이터 충돌: 여러 DB에서 동시에 쓰기 작업을 할 때 데이터 충돌(예: 동일한 데이터에 동시에 쓰기)이 발생할 수 있어, 이를 해결하기 위한 복잡한 로직이 필요합니다.
  • 복잡한 관리: 시스템 구성 및 데이터 동기화 관리가 매우 복잡하고 어렵습니다.
• 예시: 서울과 부산의 두 DB 서버가 모두 활성화되어 사용자 요청을 분산 처리합니다. 서울 서버에 장애가 발생해도, 부산 서버가 이미 요청을 처리하고 있었으므로 서비스는 중단되지 않습니다.

선택 기준

• 액티브-스탠바이는 데이터 일관성이 가장 중요하고, 짧은 시간의 다운타임을 허용할 수 있는 시스템에 적합합니다 (예: 금융 시스템, 내부 업무 시스템).
• 액티브-액티브는 높은 성능과 무중단 서비스가 최우선인 시스템에 적합합니다 (예: 대규모 온라인 서비스, 게임 서버).

• 주제: 세션 클러스터링 포함한 이중화 구조

[개념]

1. 브라우저 쿠키 & 세션 개념

2. HTTP 헤더의 JSESSIONID와 WAS의 Session Object 매핑

1. 브라우저 요청 흐름
   • 최초 요청 시 서버(WAS)가 HttpSession 객체 생성 → 세션 ID 부여 (JSESSIONID) → Set-Cookie로 브라우저에 전달.
2. 이후 요청 시
   • 브라우저가 Cookie: JSESSIONID=<id>를 HTTP 헤더에 포함.
   • WAS의 세션 관리 모듈이 해당 ID로 세션 저장소에서 Session Object 조회.
3. 결론
   • JSESSIONID는 단순 식별자.
   • 실제 상태 데이터는 서버 세션 저장소(WAS 메모리나 외부 저장소)에 있음.

3. WAS Clustering 시 공유되는 것

• 공유 대상: 세션 데이터(= WAS Session Object)예) WebLogic : JSESSIONID=wXGc7vOVb-lcKb5z5eHiYbB0-PsWuBqvpoS2dWYdujaxo4dcLS31!-1381829421!1969680044;
         → SESSION_ID  !  PRIMARY_JVMID_HASH  !  SECONDARY_JVM_HASH
• 공유하지 않는 것: 각 WAS의 로컬 자원(메모리 변수, 파일 핸들, 스레드 등)
• 공유 방식
  1. In-memory replication: 각 WAS 간 메모리에 세션 복제.
  2. Database / External store: 세션을 외부 저장소(RDB, Redis 등)에 저장.
  3. Mixed: 로컬+외부 캐시 혼합.

4. Session object serializable
세션 클러스터링을 사용하면 다음과 같은 일이 발생

1. 클라이언트 요청 → WAS 인스턴스 A에서 HttpSession 객체 생성.
2. 세션 클러스터링 모듈이 인스턴스 B, C… 로 해당 세션 데이터를 복제.
3. 복제 과정에서 세션 객체 내부의 모든 값이 네트워크로 전송되어야 함.
4. 네트워크 전송이나 외부 저장소 저장을 위해선 바이트 스트림 형태로 변환이 필요 → 직렬화(Serialization).

Serializable 역할
 - Java 직렬화는 객체를 바이트 배열로 변환하는 표준 방식.
 -  HttpSession 내부 속성(attribute)에 저장된 객체가 Serializable을 구현하지 않으면, WAS가 세션 복제 시 직렬화 실패 → NotSerializableException 발생.
 - 이 때문에 세션에 담는 모든 객체는 직렬화 가능해야 함.

5. Sticky vs Non-sticky Session

6. Scale-out 상황에서 Session Clustering 방식 비교

• 주제: 세션 클러스터링 포함한 이중화 구조

[개념]

1. 브라우저 쿠키 & 세션 개념

2. HTTP 헤더의 JSESSIONID와 WAS의 Session Object 매핑

1. 브라우저 요청 흐름
   • 최초 요청 시 서버(WAS)가 HttpSession 객체 생성 → 세션 ID 부여 (JSESSIONID) → Set-Cookie로 브라우저에 전달.
2. 이후 요청 시
   • 브라우저가 Cookie: JSESSIONID=<id>를 HTTP 헤더에 포함.
   • WAS의 세션 관리 모듈이 해당 ID로 세션 저장소에서 Session Object 조회.
3. 결론
   • JSESSIONID는 단순 식별자.
   • 실제 상태 데이터는 서버 세션 저장소(WAS 메모리나 외부 저장소)에 있음.

3. WAS Clustering 시 공유되는 것

• 공유 대상: 세션 데이터(= WAS Session Object)예) WebLogic : JSESSIONID=wXGc7vOVb-lcKb5z5eHiYbB0-PsWuBqvpoS2dWYdujaxo4dcLS31!-1381829421!1969680044;
         → SESSION_ID  !  PRIMARY_JVMID_HASH  !  SECONDARY_JVM_HASH
• 공유하지 않는 것: 각 WAS의 로컬 자원(메모리 변수, 파일 핸들, 스레드 등)
• 공유 방식
  1. In-memory replication: 각 WAS 간 메모리에 세션 복제.
  2. Database / External store: 세션을 외부 저장소(RDB, Redis 등)에 저장.
  3. Mixed: 로컬+외부 캐시 혼합.

4. Session object serializable
세션 클러스터링을 사용하면 다음과 같은 일이 발생

1. 클라이언트 요청 → WAS 인스턴스 A에서 HttpSession 객체 생성.
2. 세션 클러스터링 모듈이 인스턴스 B, C… 로 해당 세션 데이터를 복제.
3. 복제 과정에서 세션 객체 내부의 모든 값이 네트워크로 전송되어야 함.
4. 네트워크 전송이나 외부 저장소 저장을 위해선 바이트 스트림 형태로 변환이 필요 → 직렬화(Serialization).

Serializable 역할
 - Java 직렬화는 객체를 바이트 배열로 변환하는 표준 방식.
 -  HttpSession 내부 속성(attribute)에 저장된 객체가 Serializable을 구현하지 않으면, WAS가 세션 복제 시 직렬화 실패 → NotSerializableException 발생.
 - 이 때문에 세션에 담는 모든 객체는 직렬화 가능해야 함.

5. Sticky vs Non-sticky Session

6. Scale-out 상황에서 Session Clustering 방식 비교

문제 1

운영 중인 Tomcat 클러스터에서 Sticky Session을 사용하고 있다.
롤링 배포 과정에서 WAS01 jvmRoute 값을 node1 → node01로 변경한 후 일부 사용자가 계속 로그아웃되는 문제가 발생했다.
이 상황의 원인으로 가장 적절한 것은 무엇인가?

A. JSESSIONID의 Route ID가 변경되어 기존 세션이 더 이상 매핑되지 않는다.
B. 직렬화되지 않은 객체가 세션에 들어가 복제가 실패했다.
C. Tomcat이 HTTPS 요청을 처리하지 못한다.
D. 세션 타임아웃 값이 갑자기 0으로 설정되었다.
E. 브라우저 쿠키가 Secure 속성을 잃어버렸다.

문제 2

WebSphere 클러스터 환경에서 세션 클러스터링을 활성화했지만, 장애 발생 시 다른 노드에서 세션이 복구되지 않는다.
로그를 확인해보니 세션 복제 과정에서 NonSerializableException 에러가 발생한다.
가능성이 가장 높은 원인은 무엇인가?

A. 세션 객체 복제시 commit이 불가하다.
B. 로드밸런서가 Sticky Session으로 설정되어 있다.
C. 세션 객체가 너무 커서 네트워크로 전송되지 못한다.
D. HTTP Keep-Alive 설정이 꺼져 있다.
E. 브라우저에서 JSESSIONID 쿠키를 전송하지 않는다.

문제 3

WildFly 클러스터 환경에서 세션을 Redis에 저장하는 방식으로 변경했다.
이후 세션 동기화 문제는 사라졌지만, 서비스 부하가 커질수록 Redis CPU 사용률이 급격히 올라가고 응답 지연이 발생한다.
운영 측면에서 가장 적절한 대응 방안은 무엇인가?

A. 세션에 저장하는 데이터 크기를 줄이고, 필요 없는 속성은 제거한다.
B. 세션 직렬화를 JSON이 아닌 바이너리 포맷으로 변경한다.
C. Redis를 In-memory replication 방식으로 바꾼다.
D. 세션 타임아웃을 늘려 세션 유지 시간을 길게 한다.
E. 로드밸런서를 Non-sticky로 변경한다.

• 온프레미스 환경(사설 네트워크, 서브넷 마스크)

온프레미스는 기업이 자체 데이터 센터에 서버, 스토리지, 네트워크 장비를 직접 소유하고 관리하는 IT 인프라 환경을 말합니다. 이는 클라우드 서비스와 대조되는 개념으로, 모든 자원이 기업의 물리적 시설 내에 존재합니다.

온프레미스 환경의 특징

• 물리적 소유: 기업이 서버, 네트워크 장비, 소프트웨어 라이선스 등을 직접 구매하여 소유합니다.
• 완전한 통제: 인프라의 모든 측면(하드웨어, 네트워크, 보안)을 기업이 직접 제어할 수 있습니다.
• 초기 비용: 인프라 구축에 많은 초기 자본이 필요하지만, 장기적으로는 운영 비용이 더 저렴할 수 있습니다.
• 보안: 보안을 자체적으로 관리하므로, 민감한 데이터를 외부 클라우드에 두기 어려운 금융, 공공 기관 등에 주로 사용됩니다.

사설 네트워크 (Private Network)

사설 네트워크는 외부 인터넷으로부터 분리된 내부 네트워크입니다. 공인 IP 주소가 아닌, 사설 IP 주소 대역을 사용하여 내부 기기들이 서로 통신합니다.

• 사설 IP 대역:
  • A 클래스: 10.0.0.0 ~ 10.255.255.255
  • B 클래스: 172.16.0.0 ~ 172.31.255.255
  • C 클래스: 192.168.0.0 ~ 192.168.255.255
• NAT (Network Address Translation): 사설 네트워크에 있는 기기가 외부 인터넷과 통신하려면 NAT 기술을 통해 사설 IP 주소를 공인 IP 주소로 변환해야 합니다.

서브넷 마스크 (Subnet Mask)

서브넷 마스크는 IP 주소를 네트워크 부분과 호스트 부분으로 나누는 역할을 합니다. 이를 통해 하나의 큰 네트워크를 여러 개의 작은 서브넷으로 분할하여 IP 주소를 효율적으로 관리하고 네트워크 트래픽을 줄일 수 있습니다.

• 작동 방식: 서브넷 마스크는 32비트 이진수로 표현되며, 1로 채워진 부분이 네트워크 주소를, 0으로 채워진 부분이 호스트 주소를 나타냅니다.
• 예시: 192.168.1.100이라는 IP 주소와 255.255.255.0이라는 서브넷 마스크가 있을 때,
  • IP 주소: 11000000.10101000.00000001.01100100
  • 서브넷 마스크: 11111111.11111111.11111111.00000000
  • 네트워크 주소: 192.168.1.0 (IP와 서브넷 마스크를 비트별로 AND 연산)
  • 호스트 주소: 0.0.0.100

IP 주소 11000000.10101000.00000001.01100100는 32비트 이진수로, 8비트씩 네 부분으로 나뉩니다. 각 8비트 덩어리(옥텟)를 십진수로 변환하면 익숙한 IP 주소 형식이 됩니다.

각 옥텟은 2진법으로 표현된 숫자이므로, 이를 10진법으로 변환하는 과정을 거칩니다.

옥텟별 변환 과정

IP 주소는 총 4개의 옥텟으로 구성됩니다. 각 옥텟을 따로 계산합니다.

1. 첫 번째 옥텟: 11000000
   • 1 * 27 + 1 * 26 + 0 * 25 + 0 * 24 + 0 * 23 + 0 * 22 + 0 * 21 + 0 * 20
   • = 128 + 64 + 0 + 0 + 0 + 0 + 0 + 0 = 192
2. 두 번째 옥텟: 10101000
   • 1 * 27 + 0 * 26 + 1 * 25 + 0 * 24 + 1 * 23 + 0 * 22 + 0 * 21 + 0 * 20
   • = 128 + 0 + 32 + 0 + 8 + 0 + 0 + 0 = 168
3. 세 번째 옥텟: 00000001
   • 0 * 27 + 0 * 26 + 0 * 25 + 0 * 24 + 0 * 23 + 0 * 22 + 0 * 21 + 1 * 20
   • = 0 + 0 + 0 + 0 + 0 + 0 + 0 + 1 = 1
4. 네 번째 옥텟: 01100100
   • 0 * 27 + 1 * 26 + 1 * 25 + 0 * 24 + 0 * 23 + 1 * 22 + 0 * 21 + 0 * 20
   • = 0 + 64 + 32 + 0 + 0 + 4 + 0 + 0 = 100

이렇게 각 옥텟을 십진수로 변환하여 합치면 192.168.1.100이 됩니다.

IP 주소 클래스에서 첫 비트들이 고정된 값으로 시작하는 이유는 네트워크 클래스를 식별하기 위함입니다. IP 주소는 32비트 이진수로 이루어져 있는데, 이 중 첫 몇 비트를 미리 정해놓음으로써 주소의 크기를 구분하는 규칙을 만든 거죠.

A, B, C 클래스 비트 구조 💻

• A 클래스: 첫 번째 비트가 항상 **0**으로 고정되어 있습니다.
  • 예시: 01111111.11111111.11111111.11111111
  • 0으로 시작하는 IP는 A 클래스라는 것을 약속한 것입니다. 덕분에 첫 옥텟(8비트)은 0부터 127까지의 값을 가질 수 있습니다.
• B 클래스: 첫 두 비트가 항상 **10**으로 고정되어 있습니다.
  • 예시: 10111111.11111111.11111111.11111111
  • 10으로 시작하는 IP는 B 클래스라는 것을 약속한 것입니다. 첫 옥텟은 128부터 191까지의 값을 가집니다.
• C 클래스: 첫 세 비트가 항상 **110**으로 고정되어 있습니다.
  • 예시: 11011111.11111111.11111111.11111111
  • 110으로 시작하는 IP는 C 클래스라는 것을 약속한 것입니다. 첫 옥텟은 192부터 223까지의 값을 가집니다.

이러한 규칙은 IP 주소 체계 초기에 만들어진 것으로, 네트워크 크기에 따라 주소를 효율적으로 분배하기 위한 방법이었습니다. 마치 전화번호의 지역번호처럼, 앞자리가 02면 서울, 051이면 부산인 것처럼, IP 주소도 앞 비트 몇 개로 클래스를 구분하는 것입니다.

문제 1: 기본 서브넷팅 계산 (C-클래스)

회사에 할당된 IP 대역은 203.0.113.0/24입니다. 이 네트워크를 다음과 같이 4개의 서브넷으로 나누고자 합니다.

• 영업팀: 최대 30개의 호스트
• 개발팀: 최대 40개의 호스트
• 서버팜: 최대 5개의 호스트
• 예비용: 최대 15개의 호스트

요청된 호스트 수를 수용하기 위한 각 서브넷의 **서브넷 마스크(CIDR)**와 할당 가능한 IP 주소 범위를 계산하시오.

정답 및 해설:

203.0.113.0/24는 C-클래스 네트워크로, 256개의 IP 주소(203.0.113.0 ~ 203.0.113.255)를 가지고 있습니다. 네트워크를 서브넷으로 나누려면 서브넷 마스크를 변경해야 합니다. 필요한 호스트 수를 기준으로 계산합니다.

1. 개발팀 (최대 40 호스트):
   • 2^n - 2 >= 40을 만족하는 가장 작은 n은 6입니다. (2^6 - 2 = 62)
   • 따라서 호스트 비트는 6개가 필요합니다.
   • 서브넷 마스크는 32 - 6 = 26이므로, 255.255.255.192 (/26)입니다.
   • IP 범위: 203.0.113.0 ~ 203.0.113.63 (사용 가능한 IP: 62개)
2. 영업팀 (최대 30 호스트):
   • 2^n - 2 >= 30을 만족하는 가장 작은 n은 5입니다. (2^5 - 2 = 30)
   • 호스트 비트는 5개가 필요합니다.
   • 서브넷 마스크는 32 - 5 = 27이므로, 255.255.255.224 (/27)입니다.
   • IP 범위: 203.0.113.64 ~ 203.0.113.95 (사용 가능한 IP: 30개)
3. 예비용 (최대 15 호스트):
   • 2^n - 2 >= 15를 만족하는 가장 작은 n은 4입니다. (2^4 - 2 = 14)
   • 하지만 15개를 수용하려면 최소 30개 IP를 제공해야 하므로, n=5가 되어야 합니다.
   • 호스트 비트는 5개가 필요합니다.
   • 서브넷 마스크는 32 - 5 = 27이므로, 255.255.255.224 (/27)입니다.
   • IP 범위: 203.0.113.96 ~ 203.0.113.127 (사용 가능한 IP: 30개)
4. 서버팜 (최대 5 호스트):
   • 2^n - 2 >= 5를 만족하는 가장 작은 n은 3입니다. (2^3 - 2 = 6)
   • 호스트 비트는 3개가 필요합니다.
   • 서브넷 마스크는 32 - 3 = 29이므로, 255.255.255.248 (/29)입니다.
   • IP 범위: 203.0.113.128 ~ 203.0.113.135 (사용 가능한 IP: 6개)

문제 2: 추가 IP 주소 요구 사항 (VLSM)

기존 203.0.113.0/24 네트워크를 사용 중인 회사가 있습니다. 현재 다음과 같이 서브넷이 분리되어 있습니다.

• 네트워크 A: 203.0.113.0/25 (126개 사용 가능)
• 네트워크 B: 203.0.113.128/26 (62개 사용 가능)
• 네트워크 C: 203.0.113.192/27 (30개 사용 가능)
• 네트워크 D: 203.0.113.224/28 (14개 사용 가능)
• 네트워크 E: 203.0.113.240/29 (6개 사용 가능)

이 회사는 새로운 지점을 열고, 40개의 IP 주소를 필요로 합니다. 기존 서브넷을 변경하지 않고 새로운 지점에 할당할 수 있는 새로운 서브넷 주소와 서브넷 마스크를 계산하시오.

정답 및 해설:

1. 사용 중인 IP 대역 확인:
   • 네트워크 A: 203.0.113.0 ~ 203.0.113.127
   • 네트워크 B: 203.0.113.128 ~ 203.0.113.191
   • 네트워크 C: 203.0.113.192 ~ 203.0.113.223
   • 네트워크 D: 203.0.113.224 ~ 203.0.113.239
   • 네트워크 E: 203.0.113.240 ~ 203.0.113.247
2. 남은 IP 대역 계산:
   • 203.0.113.0/24의 총 IP 주소는 256개(0 ~ 255)입니다.
   • 현재 사용 중인 마지막 IP 주소는 203.0.113.247입니다.
   • 따라서 사용 가능한 IP 대역은 203.0.113.248부터 203.0.113.255까지입니다.
   • 남은 IP 수는 255 - 248 + 1 = 8개입니다.
3. 새로운 지점 IP 요구사항 충족 여부 확인:
   • 새로운 지점에는 40개의 IP 주소가 필요합니다.
   • 2^n - 2 >= 40을 만족하는 n은 6이므로, 최소 64개의 IP를 가진 /26 서브넷이 필요합니다.
   • 하지만 현재 남은 IP는 8개밖에 없으므로, 기존 네트워크에서는 필요한 40개의 IP 주소를 할당할 수 없습니다.
4. 결론: 기존 서브넷을 변경하지 않고서는 새로운 지점에 할당할 수 있는 추가 IP 대역이 없습니다. 이 문제를 해결하려면 기존 서브넷을 재구성하거나, 203.0.113.0/24와 다른 새로운 IP 대역을 할당받아야 합니다.

문제 1: B-클래스 네트워크 서브넷팅

회사에 할당된 IP 대역은 172.16.0.0/16입니다. 이 네트워크를 500개의 IP 주소를 가진 서브넷 10개로 나누고자 합니다.

각 서브넷의 **서브넷 마스크(CIDR)**와 할당 가능한 IP 주소 범위를 계산하시오.

정답 및 해설:

172.16.0.0/16는 B-클래스 네트워크로, 총 2^(32-16) = 2^16 = 65,536개의 IP 주소를 가지고 있습니다. 500개의 IP 주소를 가진 서브넷을 생성하려면, 서브넷당 502개(500 + 2)의 주소를 수용해야 합니다.

1. 호스트 비트 수 계산:
   • 2^n - 2 >= 500을 만족하는 가장 작은 n은 9입니다. (2^9 - 2 = 510)
   • 따라서, 각 서브넷은 9개의 호스트 비트를 가집니다.
2. 서브넷 마스크(CIDR) 계산:
   • 네트워크 비트 수는 32 - 9 = 23입니다.
   • 따라서 서브넷 마스크는 /23입니다.
   • 십진수로 변환하면 255.255.254.0이 됩니다.
3. 10개 서브넷의 IP 주소 범위 계산:
   • /23 서브넷은 2^(32-23) = 2^9 = 512개의 IP 주소를 가집니다.
   • 서브넷의 블록 크기는 3번째 옥텟에서 256 - 254 = 2가 됩니다.
   • 1번 서브넷: 172.16.0.0/23 (172.16.0.0 ~ 172.16.1.255, 사용 가능한 IP: 510개)
   • 2번 서브넷: 172.16.2.0/23 (172.16.2.0 ~ 172.16.3.255, 사용 가능한 IP: 510개)
   • ...
   • 10번 서브넷: 172.16.18.0/23 (172.16.18.0 ~ 172.16.19.255, 사용 가능한 IP: 510개)
   • 각 서브넷의 시작 주소는 2씩 증가합니다.

문제 2: IP 주소 고갈 시 추가 서브넷 계산 (VLSM)

기존 172.16.0.0/16 네트워크를 다음과 같이 서브넷팅하여 사용하고 있습니다.

• 네트워크 A: 172.16.0.0/20 (4094개 사용 가능)
• 네트워크 B: 172.16.16.0/20 (4094개 사용 가능)

이 회사에 3,000개의 IP 주소가 필요한 새로운 지점이 추가되었습니다. 기존 네트워크를 변경하지 않고 새로운 지점에 할당할 수 있는 새로운 서브넷 주소와 서브넷 마스크를 계산하시오.

정답 및 해설:

1. 사용 중인 IP 대역 확인:
   • 네트워크 A: 172.16.0.0 ~ 172.16.15.255
   • 네트워크 B: 172.16.16.0 ~ 172.16.31.255
   • 두 네트워크는 172.16.0.0부터 172.16.31.255까지 사용하고 있습니다.
2. 새로운 지점 IP 요구사항 충족:
   • 3,000개의 IP 주소를 수용하려면 2^n - 2 >= 3000을 만족하는 n이 필요합니다.
   • 2^11 - 2 = 2046
   • 2^12 - 2 = 4094
   • 따라서 n=12가 되어야 합니다.
   • 서브넷 마스크는 32 - 12 = 20이므로, /20입니다.
   • /20 서브넷은 2^(32-20) = 2^12 = 4096개의 IP 주소를 가집니다.
3. 남은 IP 대역 계산:
   • 기존 네트워크는 172.16.0.0/16 대역 중 172.16.31.255까지 사용하고 있습니다.
   • 남은 사용 가능 IP 대역은 172.16.32.0부터 시작합니다.
   • 필요한 서브넷은 /20이므로, 172.16.32.0/20 대역이 새로운 지점에 할당될 수 있습니다.
4. 결론:
   • 새로운 서브넷 주소: 172.16.32.0
   • 새로운 서브넷 마스크: /20 또는 255.255.240.0
   • 할당 가능한 IP 범위: 172.16.32.0 ~ 172.16.47.255 (4094개 사용 가능)

OSI 7 계층

OSI 7 계층(Open Systems Interconnection 7 Layers)은 네트워크 통신 과정을 7단계의 논리적 계층으로 나눈 모델입니다. 각 계층은 독립적인 기능을 수행하며, 아래 계층의 기능에 의존하고 위 계층에 서비스를 제공합니다.

문제: OSI 7계층과 네트워크 장비

다음 그림과 시나리오를 참고하여, A, B, C, D 장비에 대한 설명으로 가장 옳지 않은 것을 고르시오.

[그림 설명]

• A: 사용자의 PC가 연결된 가장 최전방의 네트워크 장비.
• B: VLAN을 지원하며, 여러 서브넷 간의 통신을 제어하는 장비.
• C: 인터넷에 접속하기 위해 사설 IP를 공인 IP로 변환하는 장비.
• D: 전송 계층의 신뢰성 있는 연결을 담당하고, 포트 번호를 사용하여 서비스를 식별하는 프로토콜.

[시나리오] 사내 네트워크에서 PC(192.168.10.10)가 외부 웹 서버(203.0.113.10)에 접속하려고 합니다. PC에서 웹 브라우저(Port 55000)를 통해 HTTP(Port 80) 요청을 보냅니다. 이 요청은 장비 A를 거쳐 장비 B에 도달합니다. 장비 B는 이 요청을 장비 C로 전달하며, 장비 C는 요청 패킷의 소스 IP 주소를 변환하여 외부로 보냅니다. 웹 서버로부터의 응답은 다시 장비 C, B, A를 거쳐 PC의 웹 브라우저로 전달됩니다. 이 과정에서 프로토콜 D가 신뢰성 있는 데이터 전송을 보장합니다.

1. 장비 A는 OSI 2계층에서 동작하는 스위치로, PC와 동일한 네트워크(VLAN) 내에서 MAC 주소를 기반으로 프레임을 전달한다.
2. 장비 B는 2계층과 3계층 기능을 모두 갖춘 Layer 3 스위치이며, 서로 다른 서브넷(VLAN) 간의 패킷 라우팅을 담당한다.
3. 장비 C는 NAT(Network Address Translation) 기능을 수행하며, OSI 3계층에서 IP 주소 변환을 통해 사설 네트워크와 공인 네트워크 간의 통신을 가능하게 한다.
4. 프로토콜 D는 OSI 4계층에서 작동하는 TCP(Transmission Control Protocol)이며, 3-way handshake를 통해 신뢰성 있는 데이터 전송을 보장한다.
5. 위 시나리오에서 PC가 보낸 요청은 OSI 7계층에서 HTTP를 사용하며, 이 HTTP 요청은 최종적으로 OSI 2계층의 헤더와 트레일러가 붙은 프레임 형태로 장비 A에 전달된다.

정답 및 해설

정답: 1. 장비 A는 OSI 2계층에서 동작하는 스위치로, PC와 동일한 네트워크(VLAN) 내에서 MAC 주소를 기반으로 프레임을 전달한다.

해설:

1. 정답 (옳지 않음): 장비 A는 사용자의 PC가 연결된 가장 최전방의 네트워크 장비입니다. 일반적으로 이는 **스위치(Switch)**의 역할입니다. 하지만 VLAN은 서로 다른 네트워크를 논리적으로 분리하는 기술이므로, VLAN을 구성하는 장비는 Layer 2 스위치가 아니라 Layer 3 스위치가 됩니다. 또한, 스위치는 포트 기반으로 작동하며, MAC 주소를 기반으로 통신합니다. 따라서, **"동일한 네트워크(VLAN) 내에서"**라는 표현은 적절하지만, **장비 A가 VLAN을 지원한다**는 단서가 없으므로 옳지 않습니다. 문제에서 장비 B는 VLAN을 지원하고 있다고 명시했으므로, 장비 A는 단순한 2계층 스위치일 가능성이 높습니다.
2. 옳음: 장비 B는 여러 서브넷(VLAN) 간 통신을 제어하므로, OSI 3계층 기능을 가진 라우터 또는 Layer 3 스위치입니다.
3. 옳음: 장비 C는 사설 IP를 공인 IP로 변환하는 NAT 기능을 수행하며, 이는 OSI 3계층(네트워크 계층)의 역할입니다.
4. 옳음: 프로토콜 D는 신뢰성 있는 데이터 전송과 포트 번호를 사용하는 OSI 4계층의 TCP입니다.
5. 옳음: 데이터는 OSI 7계층에서 1계층으로 내려가면서 각 계층의 헤더가 추가됩니다. HTTP는 7계층 프로토콜이며, 2계층에서는 프레임 헤더와 트레일러가 붙습니다.

Debezium은 오픈 소스 분산 플랫폼으로, 데이터베이스 변경 사항을 실시간으로 캡처하여 이벤트 스트림으로 변환하는 CDC(Change Data Capture) 기능을 제공합니다. 주로 Apache Kafka Connect 기반으로 사용되며, 다양한 데이터베이스의 변경 이벤트를 캡처하여 다른 시스템으로 전송할 수 있도록 합니다. 

주요 특징:

• Change Data Capture (CDC):데이터베이스에서 발생하는 INSERT, UPDATE, DELETE와 같은 변경 사항을 실시간으로 캡처합니다. 
• 오픈 소스 및 분산:오픈 소스 프로젝트로, 여러 노드에서 분산되어 실행될 수 있어 안정성과 확장성이 뛰어납니다. 
• Kafka Connect 기반:Apache Kafka Connect 프레임워크를 기반으로 구축되어 카프카를 통해 데이터를 처리하고 전송합니다. 
• 다양한 데이터베이스 지원:MongoDB, MySQL, PostgreSQL, SQL Server 등 다양한 데이터베이스를 지원합니다. 
• 로그 기반 CDC:데이터베이스의 변경 로그를 기반으로 변경 사항을 캡처합니다. 
• 유연한 데이터 동기화:CDC 기술을 활용하여 데이터 변경 사항만 동기화하므로, 전체 데이터 동기화 방식보다 비용과 속도 측면에서 효율적입니다. 
• 미러링, 캐싱, 분석 등 다양한 활용:캡처된 변경 이벤트를 사용하여 데이터베이스 미러링, 캐싱, 분석 등 다양한 용도로 활용할 수 있습니다. 

Debezium의 작동 방식 (간단히):

1. Debezium 커넥터가 데이터베이스의 변경 로그를 읽습니다.
2. 변경 사항을 캡처하여 이벤트 형태로 변환합니다.
3. 변환된 이벤트를 Kafka 토픽에 발행합니다.
4. 다른 시스템에서 Kafka 토픽을 구독하여 변경 이벤트를 처리합니다. 

예시:
예를 들어, Debezium을 사용하여 MySQL 데이터베이스의 변경 사항을 캡처하여 Elasticsearch에 인덱싱할 수 있습니다. MySQL에서 데이터가 변경되면 Debezium이 이를 감지하고 Kafka를 통해 Elasticsearch 커넥터로 전달하여 Elasticsearch 인덱스를 업데이트합니다. 

[개념]

생성 / 데이터 스토어

1. VMware

개념: 하나의 물리 서버에서 여러 개의 가상 컴퓨터(가상 머신)를 실행할 수 있게 해주는 가상화 소프트웨어 플랫폼

• VMware Workstation
  - 가상화 Type 2(호스트 기반 하이퍼바이저)
  - 개인용 가상화 도구
  - 종류: Workstation(Windows/Linux), Fusion(Mac용)
  - 로컬 PC에서 다양한 OS 테스트나 개발 환경 구축에 사용
• VMware vSphere
  - 가상화 Type 1(베어메탈 하이퍼바이저) 
  - 엔터프라이즈용 가상화 도구
  - 구성요소: ESXi, vCenter Server, vSphere Client

2. ESXi

- 베어메 하이퍼바이저로 일반적인 운영체제 없이 직접 하드웨어 위에서 동작

- 자체 커널인 VMkernel을 사용하여 가상머신을 관리하고 하드웨어 자원을 할당

🧩 VMkernel과 VM 간의 관계

** ESXi 구조

3. 데이터 스토어

- 데이터 스토어는 가상머신의 VMDK 파일, 설정파일(.vmx), ISO 이미지 등을 저장하는 공간

- 새로운 VM 생성 시 해당 VM의 모든 구성 파일이 지정된 데이터 스토어에 저장됨.

- 여러 ESXi 호스트가 하나의 데이터 스토어를 마운트하여 VM의 이동, 백업, 복제등 관리가 가능

- VM 마이그레이션의 핵심 기능

🧾 VMFS 

[문제]

1. VMware 환경에서 ESXi 하이퍼바이저가 가상머신을 내부적으로 어떻게 관리하는지 설명한 내용 중 가장 적절한 것은 무엇인가?

A) ESXi는 VM을 각각 독립된 물리서버처럼 인식하며, VM 하나 당 별도의 커널을 실행한다.

B) ESXi는 VM을 각각 하나의 실행 프로세스(VMX 프로세스)로 관리하며, 이를 통해 CPU와 메모리 자원을 할당한다.

C) ESXi는 VM을 호스트 운영체제 위의 애플리케이션으로 실행하여 게스트 OS와 호스트 OS가 동일한 커널을 공유 한다.

D) ESXi는 VM을 단순한 파일 모음으로 취급하며, VM 실행 시 별도의 프로세스 생성 없이 직접 하드웨어에 접근한다. 

2. 데이터스토어와 VM 마이그레이션(vMotion) 관계에 대한 올바른 설명을 고르시오.

A) 데이터스토어는 VM이 실행 중일 때 해당 VM의 VMDK 파일을 직접 CPU에 할당한다.
B) 하나의 데이터스토어를 여러 ESXi 호스트가 마운트할 경우, VM의 실시간 이동과 백업이 가능하다.
C) 데이터스토어 없이도 모든 ESXi 간에 무중단 vMotion이 항상 보장된다.
D) 데이터스토어는 VM마다 독립적으로 할당되며 ESXi 호스트 간 파일 공유는 불가능하다.

3. ESXi 환경에서 VMkernel, VMM, VMX 간의 관계를 가장 적절하게 설명한 것은?

A) VMkernel이 VMX를 통해 직접 하드웨어에 접근하며, VMM은 VMkernel 내 프로세스이다.
B) VMX는 VM에 CPU/메모리를 할당하고 하드웨어 접근은 VMM이 전담한다.
C) VMkernel이 하드웨어 자원 관리, VMM이 각 VM마다 생성되어 가상화 기능 담당, VMX는 VM 실행관련 프로세스이다.
D) VMkernel이 VMX와 VMM을 병렬로 관리하며, VM마다 VMM과 VMX 프로세스 하나씩 생성된다.

• Redis 기반 세션 클러스터링 및 복제 고가용성

[개념]

Redis는 REmote DIctionary Server의 약자로 공식적으로 NoSQL Database로 분류되어 있는 오픈소 데이터베이스이다.
In-Memory Key-Value Store, 즉 메모리에 Key-Value 값을 저장하여 빠른 성능을 보장하며, 다양한 언어 클라이언트 및 자료구조를 지원하므로 다양한 상황에서 사용될 수 있다.
많은 서비스에서 캐시, 세션 저장을 위해 많이 사용하며, 실시간 순위나 메시지 브로커, 비동기 작업 큐로도 사용하기도 한다.
명령어가 짧고 직관적이며, redis-cli를 통해 터미널에서 실행하거나 Python, C#, .NET, Java 등 Redis에서 제공하는 여러 언어의 클라이언트 라이브러리로 연결하여 사용할 수 있다.

[Redis가 제공하는 자료구조 별 사용 예시]

Redis에서는 고가용성(HA, High Availavility)을 유지하기 위해 Replication(복제)을, 확장성을 위해 Cluster 구조를 제공한다.
기본적으로 Master/Slave (또는 Leader/Follower) 구조로 Replication을 제공하며, 하나의 쓰기Write 가능한 Master(Leader)와 읽기전용Read 또는 백업을 기본으로 하는 Slave(Follower)를 두고 고가용성을 유지한다.
Master->Slave로 단방향 복제가 발생하며, 이 때 복제는 비동기(Async) 방식으로 동작하여 아주 약간 데이터 지연이 발생할 가능성이 있다.

Replication 구조에서는 Redis Sentinel을 함께 구성하여 고가용성을 유지할 수 있다.
Redis Sentinel은 Master 인스턴스를 모니터링 하며 Master에서 이슈가 발생할 경우 자동으로 Slave를 Master로 승격하여 서비스를 유지시킨다. [참고] High availability with Redis Sentinel 

[Redis Replication 구조]

Redis Cluster는 Replication의 구조를 그대로 가져가며 그 자체를 수평적으로 분산시켜 거대한 시스템으로 구성한 것이다.
N개의 Master가 있고, Master는 1개 이상의 Slave를 보유한다.

Cluster에는 Sharding/Replication/Failover 3가지 개념이 존재하고, 전체 0~16485 Slots이 Master에 자동으로 나눠지며(Sharding),
Replication 구조에서 자동으로 Master의 장애를 감지, Slave를 승격(Failover)시킬수 있게 된다.
Key는 "CRC16(key) % 16384" 연산으로 Slot 번호를 계산하여 해당 Slot을 관리하는 Master에 저장된다.

Client는 직접 Master에 통신하여 Key를 저장하거나 읽어오며, Key를 읽을때 값을 가지고 있지 않은 Master로 요청하게 될 경우
MOVED 응답을 통해 어디에 해당 Key가 저장되어 있는지 전달받게 된다. Redis Cluster에서는 다중 키 연산이 불가능 하므로,
함께 연산이 필요한 Key들은 HashTag를 통해 동일한 마스터에 저장될 수 있도록 구성되어야 한다.

Redis는 데이터베이스, 캐시, 메시지 브로커로 사용되는 인메모리(in-memory) 데이터 저장소입니다. 디스크에 데이터를 저장하는 전통적인 데이터베이스와 달리, 모든 데이터를 **메모리(RAM)**에 저장하는 것이 가장 큰 특징이에요.

왜 Redis를 쓸까? 🏃‍♂️

Redis의 가장 큰 장점은 엄청나게 빠른 속도입니다. 모든 데이터를 메모리에서 읽고 쓰기 때문에, 디스크 I/O가 필요한 데이터베이스보다 훨씬 빠릅니다. 웹 서비스에서 Redis는 주로 다음과 같은 용도로 사용됩니다.

1. 캐시(Cache): 자주 조회되는 데이터를 Redis에 저장해두고, 요청이 들어올 때마다 데이터베이스를 거치지 않고 Redis에서 바로 응답을 줍니다. 이렇게 하면 데이터베이스 부하를 줄이고 응답 시간을 단축할 수 있습니다.
2. 세션 저장소: 로그인한 사용자의 세션 정보를 Redis에 저장하여, 여러 웹 서버 간에 세션 데이터를 공유하고 관리하는 데 사용됩니다.
3. 랭킹 시스템: 실시간으로 순위가 변하는 게임 랭킹이나 인기 검색어 순위 등을 Redis의 Sorted Set 자료구조를 이용해 빠르게 처리할 수 있습니다.
4. 메시지 큐: Pub/Sub 기능을 사용하여 실시간 채팅이나 알림 등 메시지 브로커 역할도 수행합니다.

Redis의 독특한 특징 🛠️

Redis는 단순히 키-값(key-value) 쌍만 저장하는 것이 아니라, 다양한 자료구조를 지원한다는 점이 독특합니다. 덕분에 Redis는 매우 유연하게 활용될 수 있어요.

• String: 가장 기본적인 문자열 저장 방식.
• List: 여러 개의 문자열을 순서대로 저장하는 목록.
• Set: 중복되지 않는 값들의 집합.
• Sorted Set: 점수(score)를 기준으로 정렬되는 집합. (랭킹 시스템에 유용)
• Hash: 필드와 값의 쌍으로 이루어진 객체. (사용자 프로필 정보 등에 유용)

Redis와 MySQL 비교 (쉬운 비유)

Redis와 MySQL 같은 전통적인 데이터베이스의 차이는 **'책상 위의 서류철'**과 **'서류 창고'**의 차이와 비슷합니다.

• MySQL (서류 창고): 모든 서류(데이터)가 서류 창고(디스크)에 정리되어 있습니다. 서류를 찾으려면 창고로 가서 서류를 꺼내와야 하므로 시간이 좀 걸립니다. 하지만 서류가 많아도 모두 보관할 수 있습니다.
• Redis (책상 위의 서류철): 자주 사용하는 중요한 서류(데이터)만 책상 위(메모리)에 꺼내놓습니다. 필요할 때 바로바로 찾아볼 수 있어 매우 빠릅니다. 하지만 책상 공간(메모리 용량)이 제한적이라 모든 서류를 다 올려놓을 수는 없습니다.

결론적으로, Redis는 빠른 속도가 필요하거나 다양한 자료구조를 활용해야 할 때 사용하는 보조 저장소라고 이해하면 됩니다.

[문제]

1) Redis Sentinel의 주요 역할로 옳은 것은?

1. 데이터 백업 자동화
2. 마스터 장애 발생 시 슬레이브를 마스터로 자동 승격
3. 클러스터 내 데이터 샤딩
4. 키별 만료 시간 설정
5. Lua 스크립트 실행

2) Redis 클러스터에서 특정 키에 대해 클라이언트가 "MOVED" 응답을 받았을 때 올바른 처리 방법은?

1. 요청을 동일한 노드로 재시도한다
2. 요청을 중단한다
3. 안내 메시지만 출력하고 아무 조치도 하지 않는다
4. 전달 받은 새로운 슬롯(slot)을 관리하는 마스터 노드로 요청을 다시 보낸다
5. 클러스터를 리스타트한다

3) Redis를 대규모 서비스에 적용할 때는 단일 노드의 한계 극복 및 무중단 서비스를 위해 클러스터(cluster) 구성이 필요합니다.
    Redis Cluster 환경에서는 전체 데이터를 복수의 노드에 분산 저장하고, 마스터-레플리카 구조를 통해 장애 시 데이터를 보존합니다.
    클러스터의 샤딩(sharding), 슬롯(slot) 관리 및 failover 처리와 관련하여 다음 설명 중 올바른 것을 고르시오.

1. 동일한 키는 클러스터 내 여러 Master 노드에 자동 복제되어 저장된다.
2. 클러스터는 각 키를 해시 함수로 계산한 슬롯 번호에 따라 Master에 분산 저장한다.
3. 클러스터 환경에서 마스터 노드가 장애를 일으켜도 자동 failover는 지원하지 않는다.
4. Redis Cluster에서는 데이터 일관성을 위해 모든 노드에 데이터를 동기적으로 저장한다.
5. 클러스터 구성 시 마스터는 반드시 각자 하나의 레플리카만 둘 수 있다.

4) 글로벌 SNS 서비스에서 수억 명의 사용자의 피드, 알림 등 다양한 데이터를 빠르고 안정적으로 처리하기 위해 Redis Cluster 환경을 운영한다고 가정합니다.
    각 지역 데이터센터에는 여러 개의 Redis 노드가 있으며, 클러스터 구성을 통해 데이터 분산과 고가용성을 달성하고 있습니다.
    이런 실무 환경에 대한 다음 설명 중 옳은 것은?

1. 특정 유저의 피드 데이터는 클러스터 내 모든 노드에 복제되어 저장된다.
2. 각 노드는 0~16383번 슬롯 중 일부를 담당하며, 키 해시값에 따라 자동 분산 저장된다.
3. 마스터 노드 장애 시 수동 개입 없이는 어떤 Replica도 마스터로 승격되지 않는다.
4. 수평 확장이 불가능하므로 클러스터 노드 수를 늘릴 수 없다.
5. 복잡한 트랜잭션 처리를 위해 다중 키 연산이 자유롭게 허용된다.

5) 글로벌 SNS 업체에서는 수억 명의 사용자 데이터를 빠르게 저장하고 조회하는 동시에, 장애 발생 시 데이터 손실 및 서비스 중단 위험을 최소화하기 위해 Redis Cluster를 엔진으로 채택했습니다.
    Cluster는 여러 노드에 데이터를 분산 저장(샤딩)하고, 각 노드별로 복제본(Replica)을 유지해 신속한 장애 복구를 도모합니다.
    또한, Redis의 클러스터 모드에서는 애플리케이션이 각 키의 분산 위치를 알아야 하며, 데이터의 일관성과 가용성, 확장성이 복합적으로 고려됩니다.
    이런 상황에서 Redis Cluster의 동작 및 특징에 대한 올바른 설명을 고르세요.

1. 모든 키-값 데이터는 클러스터 내 여러 마스터 노드에 동시 복제되어 저장되기 때문에 데이터 손실 가능성이 없다.
2. 클러스터 내 각 키는 해시 슬롯(Hash Slot) 방식으로 분할되어 특정 마스터 노드에만 저장된다.
3. 마스터 노드 장애 발생 시, 별도의 설정 없이도 자동 복구나 Failover 처리가 이뤄지지 않는다.
4. 다중 키(Multi-key) 연산은 클러스터 내 여러 슬롯(노드)에 걸쳐 자유롭게 수행할 수 있다.
5. 노드 추가나 삭제 등 확장 및 축소가 불가능하여 클러스터 크기는 고정된다.

A) 한 서비스가 Redis master 1대와 replica 2대(replica1, replica2)로 운영 중입니다. 어느 날 master와 replica1 사이 네트워크가 15분 동안 단절됩니다.
    그동안 replica1은 master의 변경사항을 수신하지 못해 데이터가 일치하지 않게 됩니다.
    네트워크 복구 후 replica1은 master와 전체 동기화를 시도하지만, maxmemory 설정이 작아 전체 복제 데이터를 모두 저장하지 못합니다.
    이 상황에서 발생하거나 관련 있는 현상/설명으로 옳지 않은 것을 고르세요.

1. replica1은 동기화에 실패할 경우, 여전히 오래된 데이터를 클라이언트에게 제공할 수 있다.
2. replica2는 네트워크 이상이 없었으므로 master와 동일한 최신 데이터를 계속 서비스한다.
3. master와 replica1 간의 복제가 네트워크/메모리 문제로 반복적으로 실패하면, replica1이 데이터 일관성을 잃을 수 있다.
4. 전체 복제 과정에서 maxmemory eviction 정책에 따라 replica1의 기존 데이터도 삭제될 수 있다.
5. replica1은 동기화 실패 시 자동으로 master 역할로 승격되어 쓰기 요청을 받아들이게 된다.

B) 여러 대의 노드로 이루어진 Redis Cluster 환경에서, 각 노드는 slot을 분산해 저장하고 있습니다. 상태는 다음과 같습니다.

• cluster 전체 노드: 6대(3 master, 3 replica)
• 특정 master 노드(M1)가 하드웨어 장애로 다운됨. 이 마스터의 replica(R1)가 살아남아 있다는 신호를 다른 노드들에게 전송하고 있습니다.
• cluster의 min-replicas-to-write 옵션은 1로 설정되어 있습니다.

    이 상황에서 발생할 수 있는 결과나 현상으로 옳지 않은 것을 고르세요.

1. 클러스터에서는 자동으로 남은 replica(R1)가 마스터로 승격(failover)되어 해당 슬롯 데이터를 계속 서비스한다.
2. cluster-replicas 옵션이 1 이상이므로, 최소 하나의 replica가 남아 있으면 클러스터는 쓰기·읽기가 모두 가능하다.
3. 특정 master(M1)가 사라져도, 나머지 master들이 담당하는 slot에는 아무런 영향이 없다.
4. 클러스터 내부적으로 단일 key에 대한 operations는 해당 slot을 가진 노드만 장애가 아니라면 정상적으로 동작한다.
5. failover 이후 새로 마스터가 된 R1이 장애 발생 직전의 완벽한 최신 데이터를 반드시 보장한다.

• replication 개념
• kafka 기반 대용량 MSA 실시간 스트리밍
• 파티션, 컨슈머

참고링크 : kafka overview > 1) data producer & consumer test

[개념]

아파치 카프카는 실시간으로 레코드의 스트림을 게시, 구독, 저장, 처리할 수 있는 분산 데이터 스트리밍 플랫폼입니다.

다양한 소스에서 데이터 스트림을 처리하고 여러 컨슈머에게 전달하기 위해 설계되었습니다.
간단히 말해서, 카프카는 단순히 A지점에서 B지점으로 데이터를 이동시키는 것뿐 아니라 A지점에서 Z지점과 필요한 모든 곳으로 동시에 대규모 데이터를 이동시킬수 있습니다.
아파치 카프카는 전통적인 엔터프라이즈 메시징 시스템의 대안이며, 이제는 다양한 엔터프라이즈 요구 사항에 적용 가능한 오픈 소스 데이터 스트리밍 솔루션으로 사용 되고 있습니다.

스트리밍 데이터
스트리밍 데이터는 실시간 정보의 지속적인 흐름이자 이벤트 기반 아키텍처(event driven architecture) 소프트웨어 모델의 기반입니다.
현대적인 애플리케이션은 스트리밍 데이터를 사용하여 데이터를 처리, 저장, 분석합니다.
스트리밍 데이터는 데이터 세트에 발생한 변경 사항이나 이벤트의 실행 로그(대개 매우 빠른 속도로 변경됨)라고 볼 수도 있습니다.
빠르게 이동하는 대규모 데이터 세트로서 스트리밍 데이터의 소스일 수 있는 경우는 금융 거래, 사물 인터넷(IoT) 센서 데이터, 물류 운영, 소매 주문 또는 병원 환자 모니터링 등 다양합니다.
차세대 메시징처럼 데이터 스트리밍은 이벤트에 대한 실시간 응답이 필요한 상황에 적합하다고 할 수 있습니다.

Kafka를 통한 비동기식 통합
마이크로서비스(Microservices)는 개발 환경을 바꾸어 놓았습니다.

공유 데이터베이스 계층과 같은 종속성을 줄여 개발자들이 더욱 민첩하게 작업을 수행하도록 해줍니다.

그러나 개발자가 구축 중인 분산형 애플리케이션이 데이터를 공유 하려면 특정한 유형의 통합 환경이 필요합니다.

널리 사용되는 통합 옵션으로 동기식 방법이 있는데, 이는 서로 다른 사용자 간 데이터를 공유하는 데 애플리케이션 프로그래밍 인터페이스(API)를 활용합니다.

또 다른 통합 옵션으로는 중간 데이터 스토어에 데이터를 복제하는 비동기식 방법이 있습니다.
Apache Kafka는 바로 이런 맥락에 등장하는 솔루션으로, 다른 개발팀의 데이터를 스트리밍하여 데이터 스토어를 채우면 해당 데이터를 여러 팀과 이들의 애플리케이션 간에 공유할 수 있게 됩니다.

아파치 카프카 구성 요소

 - Producer : 데이터를 Kafka 클러스터에 보내는 역할을 합니다. 애플리케이션에서 이벤트나 메시지를 생성하고 이를 특정 주제(Topics)로 전송합니다.

 - Broker : Kafka 클러스터 내의 서버를 의미합니다. 이들은 Producer로부터 데이터를 받고, 이를 저장한 후 Consumer에게 제공합니다. 각 Broker는 클러스터의 일부로 기능하며, 데이터 분산 및 복제를 통해 높은 가용성을 유지합니다.
 - Topic : 메시지를 구분하는 논리적인 채널입니다. 데이터를 카프카 클러스터에 저장할 때, 각 메시지는 특정 주제에 연관되어 있어야 합니다.
 - Partition : 각 Topic은 여러 개의 Partition으로 나눌 수 있으며, 이로 인해 데이터의 병렬 처리가 가능해집니다. Partition은 메시지 순서를 보장하고, 각 Partition은 하나의 Broker에 저장됩니다.
 - Consumer : 카프카 클러스터에서 데이터를 읽는 애플리케이션입니다. Consumer는 Topic을 구독하여 메시지를 읽고 처리합니다.
 -  Consumer Group : 여러 개의 Consumer가 함께 작동하여 특정 Topic의 메시지를 분산 처리할 수 있게 합니다. 각 Partition은 한 Consumer에만 할당되어 메시지 처리를 중복하지 않도록 합니다.
- Zookeeper: 카프카 클러스터의 메타데이터와 상태를 관리하는 데 사용됩니다. Broker의 동작 및 클러스터 상태를 관리하며, Failover 및 구성을 조정합니다.

리더와 팔로워
Replication은 토픽 단위로 동작하는 것이 아닌 파티션 단위로 동작한다는 것을 꼭 기억해야한다. 각 파티션의 복제본들은 서로 다른 브로커에 위치한다. 파티션의 원본을 리더, 복제본을 팔로워라고 부르며 각 파티션 마다 존재한다. 필자는 Kafka replication 개념을 처음 공부할 때, 3개의 파티션이 있을 때 (0, 1, 2) 0번 파티션의 팔로워가 1, 2번 파티션이라고 헷갈리곤 했는데, 0, 1, 2는 서로 독립적이며 모두 각자의 팔로워를 가진다는 것을 꼭 기억하자.

만약 N개의 노드, N개의 replication이 있다고 가정하면, N-1까지의 브로커 장애에도 tolerant 하다. 이를 가능케 하는 것이 리더와 팔로워이다. 

Kafka에서는 동일한 복제본들을 리더와 팔로워로 구분함으로서, 서로 다른 역할을 분담시킨다. 
복제본 중 하나가 리더로 선출되며, 모든 읽기와 쓰기는 리더를 통해서만 가능하다. 다시말해, 프로듀서와 컨슈머는 파티션 리더로 부터만 읽기와 쓰기를 요청하는 것이다.

Kafka의 replication(복제)은 데이터의 신뢰성과 고가용성을 높이기 위해 토픽의 각 파티션 데이터를 여러 브로커에 복제하는 역할을 합니다 1.

Kafka 복제의 주요 역할

• 데이터 내구성: 파티션의 데이터를 다수의 브로커에 복제하여 하나의 브로커가 장애가 발생해도 다른 브로커에 동일한 데이터를 유지함으로써 데이터 유실을 방지합니다.
• 고가용성 구현: 파티션의 리더 브로커가 다운되면, 복제본을 가진 다른 브로커가 새로운 리더가 되어 서비스가 중단 없이 계속 운영될 수 있습니다.
• 복제본 관리: 각 파티션은 'replication factor' 설정에 따라 여러 복제본을 유지하며, 리더와 팔로워로 역할이 나뉩니다. 리더는 클라이언트 요청을 담당하고, 팔로워는 리더의 데이터를 실시간 복제합니다.
• 관점 정리
  • 장애 복구: 리더 브로커가 장애로 인해 사용할 수 없게 되면, ISR(In-Sync Replica, 동기화된 복제본) 내에서 다음 리더가 자동으로 선출됩니다.
  • 확장성: 복제본 수를 조절함으로써 필요한 수준에 따라 장애 허용 범위나 분산 저장 전략을 유연하게 운영할 수 있습니다.

정리

Kafka의 replication은 데이터 유실을 막고, 장애 발생 시 빠른 복구를 지원해 서비스 연속성을 확보하는 핵심 기능입니다.

Replication

카프카 아키텍쳐의 핵심.

클러스터에서 서버가 장애가 생겼을 때, 카프카의 가용성을 보장하는 가장 좋은 방법이 복제이기 때문이다.

​

그렇다면 Replication은 무엇일까? Replication은 파티션의 복제를 뜻한다.

Replication이 1이라면 파티션은 1개만 존재한다는 것이고, 2라면 파티션은 원본 한개와 복제본 1개로 총 2개가 존재한다.

Replication이 3이라면 원본1+복제본2로 총 3개가 존재한다.

​

다만 브로커 개수에 따라 Replication 개수도 제한이 된다. 브로커 개수가 3개이면 Replication은 4가 될 수 없다.

원본1개의 파티션을 Leader Partition, 나머지 2개의 파티션은 Follower Partition이라 부른다.

이 Leader, Follower Partition을 합쳐서 ISR(In Sync Replica)이라 부른다.

​

그렇다면 왜 Replication을 사용할까? Replication은 파티션의 고가용성을 위해 사용한다.

만약 브로커가 3개인 카프카에서 Replication이 1이고 Partition이 1인 topic이 존재한다고 가정해 보자. 갑자기 브로커가 어떠하 이유로 사용불가하게 된다면 해당 파티션은 복구가 불가능하다. 하지만 Replication이 2라면 브로커 1개가 죽더라도 복제본, 즉 Follower Partition이 존재하므로 복제본으로 복구가 가능하다. 나머지 1개가 남은 Follower Partition이 Leader Partition 역할을 승계하게 되는 것이다.

​

Replication이 고가용성을 위해 중요한 역할을 한다면 Replication이 많을수록 좋은게 아니냐는 생각을 할 수 있다. 하지만 Replication이 많아지면 많아질수록 브로커의 리소스 사용량도 늘어나게 된다. 따라서 카프카에 들어오는 데이터량과 Retention Date(저장시간)을 잘 생각해서 Replication 개수를 정하는 것이 좋다. 예를 들어, 3개 이상의 브로커를 사용한다면 Replication의 개수는 3으로 설정하는 것이 좋다.

카프카에는 다양한 데이터가 들어갈 수 있는데, 그 데이터가 들어가는 공간을 토픽이라 한다.

카프카에서는 토픽을 여러 개 생성할 수 있다. 토픽은 데이터베이스의 테이블이나 파일시스템의 폴더와 유사한 성질을 가지는데, 이 토픽에 프로듀서가 데이터를 넣게 되고, Consumer는 데이터를 가져가게 된다.

토픽은 이름을 가질 수 있는데, 목적에 따라 무슨 데이터를 담는지(click_log, send_sms, location_log) 명확하게 명시하면 추후 유지보수 시 편리하게 관리할 수 있다.

​

하나의 토픽은 여러 개의 파티션으로 구성될 수 있으며, 첫번째 파티션 번호는 0번부터 시작한다.

하나의 파티션은 큐와 같이 내부에 데이터가 파티션 끝에서부터 쌓이게 된다.

이후 Consumer가 붙으면 데이터를 가장 오래된 순서대로 가져가게 된다. 더 이상 데이터가 들어오지 않으면 Consumer는 또 다른 데이터가 들어올 때까지 기다린다.

​

이때 중요한 점은, Consumer가 record를 가져가도 데이터는 삭제되지 않는다. 파티션에 그대로 남는 것이다. 그렇다면 파티션에 남은 데이터는 누가 가져갈까? 만약 새로운 Consumer가 붙는다면 다시 0번부터 가져가서 사용할 수 있다. 다만 Consumer 그룹이 달라야 하고, auto.offset.reset=earliest라는 추가 설정이 필요하다. 이렇게 설정하면 동일 데이터에 대해 두번 처리할 수 있는데, 이는 카프카를 사용하는 아주 중요한 이유이기도 하다.

예를 들어 한 파티션 내 동일 데이터들에 대해 한 Consumer는 Elastic Search에 저장하기도 하고, 백업을 위해 Hadoop에 저장할 수 도 있다.

​

이제 한 토픽 내 파티션이 2개 이상인 경우에 대해 알아보자.

예를 들어 데이터 7이 토픽에 들어가야 하는데, 사실 Producer가 데이터를 보낼 때 키를 지정할 수 있다.

​

1) 키가 null이고, 기본 파티셔너 사용할 경우

-> round robin으로 할당

​

2) 키가 있고, 기본 파티셔너 사용할 경우

-> 키의 해시(hash)값을 구하고, 특정 파티션에 할당

​

파티션 설정 시 조심해야 할 점은, 파티션은 늘릴 순 있지만 줄일수는 없다는 점이다.

그렇다면 파티션을 늘릴 때는 언제일까? 바로 Consumer의 개수를 늘려서 데이터 처리를 분산시킬 수 있을때이다.

그렇다면 파티션의 데이터는 언제 삭제될까? 옵션에 따라 달라진다. record가 저장되는 최대 시간과 크기를 지정할 수 있다.

log.retention.ms : 최대 record 보존 시간 log.retention.byte : 최대 record 보존 크기(byte)

​

참고링크(브로커와 컨슈머 갯수 설계 관련) : 

https://jisooo.tistory.com/entry/%EC%B9%B4%ED%94%84%EC%B9%B4-%ED%95%B5%EC%8B%AC-%EA%B0%80%EC%9D%B4%EB%93%9C-4%EC%9E%A5-%EC%B9%B4%ED%94%84%EC%B9%B4-%EC%BB%A8%EC%8A%88%EB%A8%B8-%EC%B9%B4%ED%94%84%EC%B9%B4%EC%97%90%EC%84%9C-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%9D%BD%EA%B8%B0

출처 : https://hoing.io/archives/4907

출처 : https://m.blog.naver.com/jyk2367/223091449545

출처 : https://surgach.tistory.com/117#:~:text=%EC%B9%B4%ED%94%84%EC%B9%B4%20%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%20%EC%A4%91%20%ED%95%98%EB%82%98%EC%9D%98%20%EB%B8%8C%EB%A1%9C%EC%BB%A4%EA%B0%80%20%EC%BB%A8%ED%8A%B8%EB%A1%A4%EB%9F%AC%20%EC%97%AD%ED%95%A0%EC%9D%84,%EB%A6%AC%EB%8D%94%EA%B0%80%20%EC%84%A0%EC%B6%9C%20%EB%90%A0%20%EC%8B%9C%2C%20%ED%95%B4%EB%8B%B9%20%EC%A0%95%EB%B3%B4%EB%A5%BC%20%EC%A3%BC

출처 : https://m.blog.naver.com/jyk2367/223091422468?recommendTrackingCode=2

카프카는 대용량의 데이터를 실시간으로 처리하고 분산하는 분산 스트리밍 플랫폼이에요. 특히 여러 애플리케이션이나 시스템 간에 데이터를 이벤트(event) 형태로 주고받을 때 사용돼요.

카프카의 핵심 개념

카프카는 데이터를 저장하고 주고받는 데 필요한 3가지 핵심 개념을 가지고 있어요.

1. 프로듀서 (Producer) ✍️
   • 데이터를 만드는 주체예요.
   • 예를 들어, 웹사이트에서 사용자가 '구매하기' 버튼을 누르면, 이 행위가 '주문 이벤트'가 되어 카프카로 전송돼요.
   • 프로듀서는 이 이벤트를 카프카의 특정 토픽에 보내는 역할을 해요.
2. 컨슈머 (Consumer) 👂
   • 카프카에 저장된 데이터를 가져와서 사용하는 주체예요.
   • 예를 들어, '주문 이벤트'를 필요로 하는 '재고 관리 시스템', '배송 시스템', '결제 시스템' 등이 모두 컨슈머가 될 수 있어요.
   • 컨슈머는 자신이 구독한 토픽의 데이터를 가져와서 처리해요.
3. 토픽 (Topic) 📁
   • 데이터가 저장되는 공간이에요.
   • 프로듀서가 데이터를 보낼 때, "이건 '주문'에 관한 데이터야"라고 지정해주는 데이터 분류 체계예요.
   • 컨슈머는 자신이 관심 있는 토픽만 구독해서 데이터를 가져가요.

카프카의 작동 방식

카프카의 데이터 흐름은 메시지를 보내는 사람(프로듀서)과 받는 사람(컨슈머)이 직접 연결되지 않는다는 특징이 있어요.

1. 프로듀서가 데이터를 토픽에 보냄: 프로듀서는 데이터를 직접 컨슈머에게 보내는 것이 아니라, 카프카 클러스터에 있는 특정 토픽에 데이터를 보관해요.
2. 데이터 저장: 카프카는 프로듀서가 보낸 데이터를 순서대로 로그(log) 형태로 저장해요. 이 데이터는 컨슈머가 가져간 후에도 일정 기간 보관돼요.
3. 컨슈머가 데이터를 가져감: 컨슈머는 자신이 필요한 토픽에서 데이터를 꺼내 읽어가요. 여러 컨슈머가 동시에 같은 토픽의 데이터를 읽을 수도 있어요.

카프카의 장점

• 대용량 데이터 처리: 초당 수백만 건의 이벤트를 처리할 수 있는 높은 처리량을 자랑해요.
• 높은 확장성: 서버(브로커)를 수평적으로 늘리면 시스템 용량을 쉽게 확장할 수 있어요.
• 데이터 보존: 데이터를 일정 기간 보관하기 때문에, 컨슈머가 데이터를 놓치더라도 나중에 다시 읽을 수 있어요.

쉬운 비유로 이해하기

카프카는 택배 물류 시스템과 비슷하다고 생각하면 쉬워요.

• 프로듀서는 택배 기사예요. 상품(데이터)을 들고 와서 특정 분류(토픽)에 넣어두죠.
• 토픽은 물류 창고의 분류된 구역이에요. "여기는 옷", "여기는 신발"처럼요.
• 컨슈머는 택배를 받는 고객이에요. "나는 옷만 받아갈 거야"라고 하면 옷 구역에 있는 물건만 가져가요.

이 시스템에서 택배 기사(프로듀서)와 고객(컨슈머)은 직접 만나지 않아요. 물류 창고(카프카)라는 중간 지점을 통해 효율적으로 데이터를 주고받는 거죠.

[개념]

MSA환경에서 가시성 방안(솔루션, data 수집 등), 비동기 트랜잭션 가시성 방안

Grafana/Prometheus

동기, 비동기에 대한내용

MSA(Microservices Architecture) 환경에서 '통합 가시성(Observability)'은 여러 마이크로서비스의 상태를 종합적으로 파악하고 문제를 진단하는 데 필수적입니다. 이를 위해 **지표(Metrics), 로그(Logs), 분산 추적(Distributed Tracing)**의 세 가지 핵심 데이터를 수집하고 분석하는 것이 중요합니다.

1. 가시성 방안 (솔루션, 데이터 수집)

MSA 환경에서는 수많은 서비스가 서로 통신하기 때문에, 각 서비스의 상태를 개별적으로 모니터링하는 것만으로는 전체 시스템의 문제를 파악하기 어렵습니다. 따라서 다음과 같은 데이터와 솔루션을 활용하여 통합 가시성을 확보해야 합니다.

• 지표 (Metrics): 시스템의 상태를 수치로 나타내는 데이터(예: CPU 사용량, 메모리 사용량, 요청 수, 응답 시간)입니다.
  • 수집: 각 마이크로서비스에 Prometheus 클라이언트 라이브러리를 통합하여 지표를 노출합니다.
  • 솔루션: Prometheus가 각 서비스 엔드포인트에서 지표를 주기적으로 수집(Pull 방식)합니다. 수집된 데이터는 시계열 데이터베이스에 저장됩니다. Grafana는 이 Prometheus 데이터를 시각화하여 대시보드를 구축하는 데 사용됩니다.
• 로그 (Logs): 애플리케이션에서 발생하는 이벤트, 오류, 경고 등을 기록한 텍스트 데이터입니다.
  • 수집: 각 서비스의 로그를 stdout으로 출력하고, Fluentd, Logstash 같은 로그 수집기를 사용하여 중앙 집중형 로깅 시스템으로 전송합니다.
  • 솔루션: **ELK 스택(Elasticsearch, Logstash, Kibana)**이나 Loki와 같은 솔루션을 사용하여 로그를 수집, 저장, 검색합니다.
• 분산 추적 (Distributed Tracing): 하나의 요청이 여러 마이크로서비스를 거치면서 어떻게 처리되었는지 전체 흐름을 추적하는 데이터입니다.
  • 수집: OpenTelemetry, OpenTracing 같은 표준을 사용하여 각 서비스 호출에 대해 고유한 Trace ID와 Span ID를 생성하고 전달합니다.
  • 솔루션: Jaeger나 Zipkin 같은 솔루션을 사용하여 분산 추적 데이터를 시각화하고, 요청의 병목 구간을 파악할 수 있습니다.

2. Grafana & Prometheus

Prometheus는 MSA 환경에서 지표를 수집하고 저장하는 데 특화된 시계열 데이터베이스 및 모니터링 시스템입니다. 서버 상태, 애플리케이션 지표 등을 주기적으로 수집하며, 유연한 쿼리 언어(PromQL)를 제공합니다.

Grafana는 Prometheus를 포함한 다양한 데이터 소스의 지표를 시각화하는 대시보드 도구입니다. Prometheus에서 수집한 지표를 그래프, 차트, 테이블 등으로 만들어 직관적인 모니터링 환경을 제공합니다.

라이선스 제공자: Google

3. 동기, 비동기 트랜잭션 가시성 방안

MSA 환경에서는 서비스 간 통신 방식에 따라 트랜잭션의 가시성 확보 방식이 달라집니다.

동기 트랜잭션 (Synchronous Transaction)

• 통신 방식: 한 서비스가 다른 서비스의 응답을 기다리는 직렬(Serial) 통신 방식입니다. (예: HTTP REST API)
• 가시성 방안: **분산 추적(Distributed Tracing)**이 가장 효과적입니다. 요청의 시작부터 끝까지 모든 서비스 호출을 Trace ID로 연결하여 시각화함으로써, 어떤 서비스에서 지연이 발생했는지 쉽게 파악할 수 있습니다.

비동기 트랜잭션 (Asynchronous Transaction)

• 통신 방식: 메시지 큐(Message Queue)나 이벤트 스트림을 통해 통신하므로, 응답을 기다리지 않고 다음 작업을 진행합니다.
• 가시성 방안: 동기식 방식처럼 하나의 요청 흐름을 추적하기 어렵습니다. 따라서 다음과 같은 복합적인 접근이 필요합니다.
  • 메시지 ID 추적: 메시지 헤더에 고유한 Message ID를 포함시켜, 메시지 큐에 들어갈 때와 나올 때의 로그를 남겨 흐름을 추적합니다.
  • 상관관계 ID (Correlation ID): 요청의 시작부터 마지막까지 동일한 ID를 모든 메시지에 포함시켜, 서로 다른 서비스의 로그를 이 ID를 기준으로 연결하여 분석합니다.
  • 중앙 집중형 로깅: 모든 서비스의 로그를 한 곳에 모아 Correlation ID나 Message ID로 검색하여 비동기 트랜잭션의 전체 과정을 재구성합니다.