흰색기린

NLB

Network Load Balancer

L4(Layer 4)는 OSI 7 계층 모델에서 전송 계층(Transport Layer)을 의미

TCP: 안전한 택배 서비스

• 연결 지향: 물건(데이터)을 보내기 전에 보내는 사람과 받는 사람이 확실히 준비되었는지 확인합니다.
  • 예: 택배 회사가 물건을 받을 주소와 받는 사람의 정보를 확인.
• 신뢰성 보장: 물건이 안전하게 도착하지 않으면, 다시 보내줍니다.
  • 예: 택배가 분실되면 택배 회사가 재발송.
• 순서 보장: 여러 상자를 보냈을 때 도착 순서를 바르게 맞춥니다.
  • 예: 1번 상자, 2번 상자, 3번 상자가 차례로 도착.
• 속도보다 안정성 우선: 다소 시간이 걸리더라도 정확한 전달을 보장합니다.
  • 예: 귀중품을 배송할 때.

UDP: 간단한 편지

• 비연결 지향: 받는 사람과 미리 확인하지 않고 바로 보냅니다.
  • 예: 편지를 우체통에 넣고 바로 보내는 것.
• 신뢰성 낮음: 편지가 가끔 분실될 수 있지만, 이를 확인하거나 다시 보내지 않습니다.
  • 예: 엽서를 보냈는데 받는 사람이 못 받았을 수 있음.
• 순서 보장 없음: 여러 장의 편지를 보냈을 때 도착 순서는 신경 쓰지 않습니다.
  • 예: 편지 3장을 보냈는데 2번이 먼저 오고 1번이 나중에 도착.
• 속도 우선: 빠르게 보내는 것이 중요합니다.
  • 예: 생일 파티 초대장처럼 빨리 도착하면 좋지만, 없어도 큰 문제는 없는 경우.

HTTP (택배로 보내는 일반 편지)

• HTTP는 TCP 위에서 작동하는 프로토콜로, 웹 브라우저와 서버가 대화하는 규칙입니다.
  • 예: "내가 www.example.com에서 이 페이지를 보고 싶어!"라는 요청을 보내고, 그에 대한 웹 페이지 데이터를 받음.
• 보안이 없음:
  • 요청과 응답 내용이 암호화되지 않아서, 누군가 중간에서 볼 수 있습니다.
  • 예: 일반 편지를 보낼 때, 누군가 봉투를 열어 내용을 읽을 수 있음.
• HTTP는 빠르고 간단하지만, 민감한 정보에는 적합하지 않습니다.

HTTPS (택배로 보내는 금고 편지)

• HTTPS는 HTTP + SSL/TLS 보안이 결합된 프로토콜입니다.
  • 모든 데이터가 암호화되어 중간에 누가 훔쳐봐도 내용을 알 수 없습니다.
  • 예: 중요한 문서를 금고에 넣고, 택배로 안전하게 전달.
• 브라우저와 서버 간의 데이터 전송이 보안 연결을 통해 이루어집니다.
  • 예: 온라인 쇼핑, 은행 사이트, 로그인 등.
• HTTPS는 오늘날 대부분의 웹사이트에서 사용되며, 주소창에 자물쇠 아이콘🔒으로 표시됩니다.

• TCP: 데이터를 안전하게 전달하는 택배 서비스.
• UDP: 신뢰성 낮은 일반 편지
• HTTP: 웹에서 데이터를 요청하고 주고받는 규칙, 보안은 없음.
• HTTPS: HTTP에 보안을 더한 프로토콜, 민감한 데이터를 안전하게 주고받음.

ALB (Application Load Balancer)

• **L7(애플리케이션 계층)**에서 작동.
• 웹사이트 관리자처럼, 요청 내용을 보고 알맞은 곳으로 보냄.
  • 예: "로그인 페이지 요청이면 서버 A로 보내고, 이미지 요청이면 서버 B로 보내자!"
• 주로 HTTP/HTTPS 트래픽을 처리.
• 사용 사례:
  • 웹사이트, API, 마이크로서비스.

NLB (Network Load Balancer)

• **L4(네트워크 계층)**에서 작동.
• 빠른 우체부처럼, 요청 내용을 보지 않고 지정된 서버로 바로 전달.
  • 예: "이 요청은 서버 C로 보내야 해!" (IP/포트 기반).
• TCP/UDP 트래픽을 처리.
• 사용 사례:
  • 실시간 게임, 채팅 서비스, IoT 데이터 전송.

핵심 차이:

• ALB는 똑똑하게 요청 내용을 분석하고,
• NLB는 단순하고 빠르게 요청을 전달합니다.

인바운드 규칙과 아웃바운드 규칙이란?

인바운드 규칙과 아웃바운드 규칙은 네트워크 보안 설정에서 사용되며, 클라우드 인프라(예: AWS 보안 그룹)나 방화벽에서 특정 트래픽의 허용 여부를 제어합니다.

1. 인바운드 규칙 (Inbound Rules)

• 정의:
  • 네트워크 외부에서 내부로 들어오는 트래픽을 허용하거나 차단하는 규칙입니다.
  • 예를 들어, 클라이언트가 서버에 접속하려는 트래픽이 인바운드 트래픽에 해당합니다.
• 사용 사례:
  1. 웹 서버(예: HTTP 요청):
     • 외부 사용자가 **포트 80(HTTP)**을 통해 웹사이트에 접속.
     • 인바운드 규칙: 포트 80을 허용.
  2. 데이터베이스 접근 제한:
     • 애플리케이션 서버만 **데이터베이스 포트(예: 3306)**에 접근 가능.
     • 인바운드 규칙: 포트 3306을 애플리케이션 서버의 IP만 허용.
• 예시:
  • 허용 규칙: "모든 IP(0.0.0.0/0)에서 포트 80으로의 트래픽 허용".
  • 차단 규칙: "외부에서 포트 22로의 SSH 접속 금지".

2. 아웃바운드 규칙 (Outbound Rules)

• 정의:
  • 네트워크 내부에서 외부로 나가는 트래픽을 허용하거나 차단하는 규칙입니다.
  • 예를 들어, 서버가 다른 서버에 요청하거나 인터넷에 데이터를 보내는 트래픽이 아웃바운드 트래픽에 해당합니다.
• 사용 사례:
  1. 애플리케이션 서버가 외부 API에 요청:
     • API 서버의 포트 443(HTTPS)으로 나가는 트래픽 허용.
     • 아웃바운드 규칙: 포트 443을 특정 IP로 허용.
  2. 데이터 유출 방지:
     • 특정 내부 서버가 인터넷에 직접 접속하지 못하도록 차단.
     • 아웃바운드 규칙: 모든 포트와 IP로의 트래픽 차단.
• 예시:
  • 허용 규칙: "서버에서 포트 443으로의 모든 아웃바운드 트래픽 허용".
  • 차단 규칙: "내부 데이터베이스에서 외부 네트워크로 나가는 트래픽 금지".

사례 예시

사례 1: 웹 애플리케이션 서버

• 목표: 외부 사용자가 웹사이트에 접속하고, 서버가 외부 API를 호출 가능하게 설정.
• 설정:
  • 인바운드 규칙:
    • 포트 80(HTTP) 및 443(HTTPS) 허용 (모든 IP).
  • 아웃바운드 규칙:
    • 포트 443(HTTPS)을 통한 외부 API 호출 허용.

사례 2: 데이터베이스 서버

• 목표: 외부에서의 접속 차단, 애플리케이션 서버만 접근 허용.
• 설정:
  • 인바운드 규칙:
    • 포트 3306(MySQL) 허용 (애플리케이션 서버의 IP만).
  • 아웃바운드 규칙:
    • 외부 인터넷으로 나가는 모든 트래픽 차단.

요약

• 인바운드 규칙: 외부 → 내부 트래픽을 관리 (클라이언트 요청 처리).
• 아웃바운드 규칙: 내부 → 외부 트래픽을 관리 (외부와 통신 제어).

• ALB (Application Load Balancer)
  👉 웹 애플리케이션을 운영할 때 사용.
  • HTTP/HTTPS 트래픽(7계층) 처리를 잘함.
  • URL별로 트래픽 분배 가능.
  • 예: "로그인 페이지 트래픽은 서버 A로, 상품 페이지 트래픽은 서버 B로 보내라!"

• NLB (Network Load Balancer)
  👉 빠른 트래픽 처리가 필요할 때 사용.
  • TCP/UDP(4계층) 트래픽에 적합.
  • 매우 높은 성능과 낮은 지연 시간 제공.
  • 예: "수천 개의 게임 클라이언트 트래픽을 서버로 보내라!"

• GWLB (Gateway Load Balancer)
  👉 보안 트래픽 관리가 필요할 때 사용.
  • 방화벽 같은 네트워크 보안 장치와 연계.
  • 모든 트래픽을 한 번 거쳐서 검증 가능.
  • 예: "트래픽을 방화벽으로 보내서 악성 트래픽 걸러내라!"

선택 기준:

1. 웹 애플리케이션 운영 → ALB
2. 낮은 지연, 높은 성능 필요 → NLB
3. 보안 장치와 통합 필요 → GWLB

Sticky Session (스티키 세션)

스티키 세션은 사용자의 요청을 항상 같은 서버로 보내는 방식을 말합니다. 로드 밸런서를 사용하는 환경에서 클라이언트와 서버 간의 상태를 유지해야 할 때 사용됩니다.

왜 사용하나요?

1. 상태 유지를 위해
   일부 웹 애플리케이션은 서버 간 세션 상태를 공유하지 못하는 경우가 있습니다.
   예: 로그인 상태, 장바구니 정보, 폼 입력 상태 등.
   • 스티키 세션은 사용자가 항상 같은 서버로 연결되도록 보장해, 이러한 데이터를 유지합니다.
2. 단순화된 애플리케이션 설계
   스티키 세션을 사용하면 별도로 서버 간 세션 동기화를 구현할 필요가 없어 애플리케이션 설계가 단순해집니다.

어디에 사용하나요?

1. 로그인 기반 애플리케이션
   로그인 상태가 서버에 저장되는 경우, 사용자가 항상 같은 서버에 연결되어야 인증 상태를 유지할 수 있습니다.
2. 전자상거래
   장바구니 정보가 특정 서버의 세션에 저장될 때, 사용자가 쇼핑하는 동안 동일한 서버에 연결해야 합니다.
3. 폼 제출 및 작업 흐름 관리
   사용자가 특정 작업을 처리하는 도중 서버가 바뀌면 데이터 유실이나 작업 흐름 중단 문제가 발생할 수 있습니다.

스티키 세션의 작동 방식

• 세션 쿠키 기반:
  로드 밸런서가 클라이언트에게 특정 서버를 식별할 수 있는 쿠키를 발급하고, 해당 쿠키를 기반으로 요청을 같은 서버로 라우팅합니다.
  예: AWS의 Application Load Balancer(ALB)에서는 AWSALB 쿠키 사용.
• 소스 IP 기반:
  클라이언트의 IP 주소를 기반으로 항상 같은 서버에 연결되도록 설정. (주로 NLB에서 사용)

장점

1. 상태 유지 보장
   서버 간 세션 동기화 없이 사용자의 상태를 유지.
2. 애플리케이션 코드 단순화
   상태를 관리하기 위한 추가적인 개발이 불필요.

단점

1. 확장성 제한
   특정 서버에 트래픽이 몰릴 수 있어 부하 분산 효과 감소.
2. 서버 장애 시 문제
   특정 서버가 다운되면 사용자가 세션 정보를 잃을 위험.
3. 멀티 서버 환경에 비효율적
   클라우드 환경에서 서버 간 세션 공유가 가능한 구조에서는 스티키 세션이 필요하지 않을 수도 있음.

대안

1. 세션 공유
   Redis, Memcached와 같은 중앙 세션 저장소를 사용해 모든 서버가 세션 상태를 공유.
2. JWT(JSON Web Token)
   상태를 서버에 저장하지 않고, 클라이언트 측에서 유지하여 서버 간 상태 동기화 문제를 해결.

결론

스티키 세션은 애플리케이션이 서버 간 세션을 공유하지 못하는 경우 간단한 해결책이 될 수 있지만, 확장성과 장애 대응을 고려해야 하는 환경에서는 다른 방법(예: 세션 공유, JWT)을 고려하는 것이 좋습니다.

크로스존 로드 밸런싱 (Cross-Zone Load Balancing)

크로스존 로드 밸런싱은 **로드 밸런서가 요청을 가용 영역(AZ, Availability Zone)**에 관계없이 모든 대상(target)으로 고르게 분배하는 기능을 의미합니다.

작동 방식

기본적으로 AWS의 로드 밸런서는 가용 영역(AZ)별로 균등하게 트래픽을 분배합니다.

• 크로스존 로드 밸런싱 비활성화
  가용 영역 간에 분배는 균등하게 이루어지지만, 각 가용 영역의 대상 수에 따라 불균형이 발생할 수 있음.
  예:
  • AZ1에 2개의 서버, AZ2에 5개의 서버 → AZ1의 각 서버에 더 많은 트래픽이 집중.
• 크로스존 로드 밸런싱 활성화
  로드 밸런서가 가용 영역에 상관없이 모든 대상에게 트래픽을 고르게 분배.
  예:
  • AZ1에 2개의 서버, AZ2에 5개의 서버 → 총 7개의 서버에 트래픽을 균등하게 분배.

어디에 사용되나요?

1. 애플리케이션 로드 밸런서(ALB)
   기본적으로 크로스존 로드 밸런싱이 활성화되어 있음.
2. 네트워크 로드 밸런서(NLB)
   선택적으로 활성화 가능.
3. 클래식 로드 밸런서(CLB)
   선택적으로 활성화 가능.

장점

1. 균등한 부하 분산
   가용 영역의 대상 수가 다르더라도 모든 서버에 트래픽이 균등하게 분배됩니다.
2. 효율적인 리소스 사용
   특정 가용 영역에서 대상 수가 적어도 전체 리소스를 최적으로 활용 가능.
3. 트래픽 불균형 문제 해결
   대상 그룹 내 리소스가 고르게 트래픽을 처리하므로 과부하 방지.

단점

1. 네트워크 비용 증가
   크로스존 로드 밸런싱을 활성화하면 가용 영역 간 트래픽 전송 비용이 발생할 수 있음.
2. 특정 사용 사례와의 비효율성
   만약 가용 영역 간의 데이터 전송을 피해야 하거나, 대상 간 완벽한 격리를 요구하는 경우 크로스존 로드 밸런싱은 적합하지 않을 수 있음.

SSL과 TLS의 차이

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 둘 다 인터넷에서 데이터의 보안을 보장하는 암호화 프로토콜입니다. 하지만, SSL은 더 이상 안전하지 않아서 대부분의 시스템에서 TLS로 대체되었습니다. TLS는 SSL을 개선한 버전입니다. 기본적으로 SSL과 TLS는 비슷한 목적을 가지고 있지만, 차이점도 존재합니다.

1. SSL (Secure Sockets Layer)

• SSL은 인터넷을 통한 데이터 전송의 보안을 제공하는 프로토콜로, 웹 브라우저와 서버 간의 암호화된 연결을 설정하기 위해 사용되었습니다.
• 버전: SSL 1.0은 발표되지 않았고, SSL 2.0(1995)과 SSL 3.0(1996)이 주요 버전이었습니다.
• 문제점: SSL 2.0과 SSL 3.0은 여러 가지 보안 취약점이 발견되어 더 이상 사용되지 않습니다.

2. TLS (Transport Layer Security)

• TLS는 SSL을 대체하는 암호화 프로토콜로, SSL의 보안 취약점을 해결하고 성능과 보안을 향상시킨 버전입니다.
• 버전: TLS 1.0 (1999), TLS 1.1 (2006), TLS 1.2 (2008), TLS 1.3 (2018) 등이 있으며, 최신 버전은 TLS 1.3입니다.
  • TLS 1.3: 성능과 보안을 강화하여 암호화 방식과 핸드쉐이크 절차를 단순화함.
• 보안 강화: TLS는 암호화 수준을 높이고, 더 안전한 알고리즘을 채택하여 공격에 강합니다.

주요 차이점

항목SSLTLS

실제 사용

• 현재 사용되는 프로토콜: 대부분의 현대 웹 서버와 클라이언트는 TLS를 사용하며, SSL은 더 이상 안전하지 않아 대부분 사용하지 않습니다.
• "SSL"이라는 용어의 남아 있는 사용: TLS가 SSL의 후속 프로토콜이지만, 여전히 많은 사람들은 SSL이라는 용어를 사용하여 TLS를 의미하는 경우가 많습니다. 예를 들어, "SSL 인증서"라고 말하지만 실제로는 TLS 인증서를 사용하는 것입니다.

결론

• SSL은 더 이상 안전하지 않으며, 최신 보안 프로토콜인 TLS로 대체되었습니다.
• TLS는 보안 수준이 향상되어, 현재는 인터넷 상에서 데이터를 안전하게 암호화하여 전송하는 표준 프로토콜로 사용되고 있습니다.
• TLS 1.2와 TLS 1.3을 사용하는 것이 현재의 추천된 방식입니다.

드레이닝 (Draining)

**드레이닝 (Draining)**은 주로 네트워크와 서버 관련 용어로 사용되며, 서비스나 리소스를 순차적으로 종료하는 과정을 의미합니다. 이는 서버나 로드 밸런서의 대상 서버에서 트래픽을 더 이상 받지 않도록 처리하는 작업입니다.

1. 로드 밸런서에서의 드레이닝

드레이닝의 역할

로드 밸런서에서 드레이닝은 대상 서버가 요청을 받지 않도록 설정하는 과정으로, 서비스 중단 없이 서버를 점진적으로 종료하기 위해 사용됩니다. 이는 서버 유지보수나 종료 시 중요한 트래픽 손실을 방지합니다.

작동 원리

• 트래픽 차단: 드레이닝을 시작하면 로드 밸런서는 해당 서버로의 새로운 트래픽을 더 이상 보내지 않음.
• 기존 연결 처리: 기존에 연결된 클라이언트 요청은 처리하되, 새로운 요청은 다른 서버로 보내는 방식으로 운영됩니다.
• 목적: 서비스 중단 없이 서버나 리소스를 종료하거나 교체할 수 있도록 합니다.

2. AWS에서의 드레이닝

AWS에서는 **Elastic Load Balancer (ELB)**와 Auto Scaling 그룹에서 드레이닝을 설정할 수 있습니다.

ALB/NLB에서의 드레이닝

1. 정의: 로드 밸런서가 대상 서버로 트래픽을 더 이상 보내지 않도록 하는 과정.
2. 실행 방법: 대상 서버에서 "등록 해제" 또는 "디레게이트(Draining)" 상태로 설정하면 로드 밸런서는 해당 서버로의 새로운 트래픽을 보내지 않음. 기존의 연결은 종료되지 않고 계속 처리됩니다.
3. 유지보수: 서버가 유지보수 상태로 전환되거나 Auto Scaling 그룹에서 서버를 교체할 때 드레이닝을 사용하여 안정적인 종료가 가능합니다.

Auto Scaling 그룹에서의 드레이닝

• 배치 교체: Auto Scaling 그룹에서 인스턴스 종료 시 새로 배치된 인스턴스로 트래픽을 전환하면서, 이전 인스턴스는 드레이닝 상태로 전환되어 현재 진행 중인 트래픽 요청을 끝내고 종료됩니다.

3. 애플리케이션에서의 드레이닝

애플리케이션에서는 유저 세션이나 작업 처리를 종료할 때 드레이닝을 사용하여, 사용자가 작업을 중단하기 전에 트래픽을 안전하게 종료하고 새 요청을 받지 않도록 처리할 수 있습니다.

4. 드레이닝을 사용하는 이유

• 서비스 중단 최소화: 서버나 서비스를 종료할 때, 드레이닝을 사용하여 기존에 진행 중인 연결을 마무리할 수 있어, 서비스 중단 없이 순차적인 종료가 가능합니다.
• 트래픽 손실 방지: 새로운 요청을 받지 않게 하여 불필요한 트래픽 손실을 방지하고, 리소스를 안전하게 종료합니다.
• 시스템 안정성: 불필요한 서버 종료로 인한 시스템 장애를 방지합니다.

결론

드레이닝은 서버나 리소스를 안전하고 점진적으로 종료하기 위한 중요한 과정으로, 로드 밸런서나 서버의 유지보수 및 교체 시에 사용됩니다. 서비스 중단 없이 연결을 종료하고 트래픽을 다른 서버로 원활하게 전환하는 데 도움을 줍니다.

**키 페어(Key Pair)**를 설정하는 이유는 AWS EC2 인스턴스에 안전하게 접근할 수 있도록 하기 위함입니다. 쉽게 말해서, 보안과 접근 제어를 위해 사용됩니다.

키 페어란 무엇인가?

AWS에서 키 페어는 **공개 키(Public Key)**와 비공개 키(Private Key) 한 쌍으로 이루어져 있습니다. 이 키 쌍은 EC2 인스턴스에 SSH로 접속하거나, 암호화된 연결을 통해 로그인할 때 사용됩니다.

• 공개 키(Public Key): 이 키는 서버에 저장됩니다. 공개적으로 공유할 수 있습니다.
• 비공개 키(Private Key): 이 키는 자신만 가지고 있어야 하며, 서버에 접근할 때 사용합니다. 비공개 키를 누구에게도 공유해서는 안 됩니다.

키 페어의 주요 역할

1. 안전한 인증

• 키 페어를 설정하면 암호를 사용하지 않고, 공개 키와 비공개 키를 통해 안전하게 인증합니다.
• 비공개 키는 자신만 가지고 있어야 하므로, 그 키를 가진 사람만 EC2 인스턴스에 접근할 수 있습니다.

2. 암호화된 연결

• 키 페어를 이용한 SSH 연결은 암호화된 연결입니다. 즉, 비공개 키를 사용하여 인증 후 서버와의 통신이 암호화되어, 데이터가 중간에 가로채지지 않도록 보호됩니다.
• 이는 **중간자 공격(MITM)**을 방지하는 중요한 보안 수단입니다.

3. 무차별 대입 공격 방지

• 암호 기반의 로그인은 **무차별 대입 공격(brute force attack)**에 취약할 수 있습니다. 예를 들어, 공격자가 여러 비밀번호를 시도하여 로그인할 수 있습니다.
• 키 페어 방식에서는 비공개 키를 가지고 있어야 하므로, 단순히 비밀번호를 추측해서 로그인하는 방식은 불가능합니다. 키가 없으면 아예 접속 자체가 불가능합니다.

왜 키 페어를 설정하나요?

1. 보안 강화
   • 비밀번호를 사용하는 대신, 키 페어를 이용한 인증은 더 안전합니다. 비밀번호는 사람이 쉽게 추측할 수 있는 반면, 키 페어는 복잡한 암호화 방식을 사용하므로 안전합니다.
2. 접근 제어
   • 키 페어를 소유한 사람만 EC2 인스턴스에 접근할 수 있습니다. 즉, 비공개 키를 가진 사람만 로그인할 수 있기 때문에, 불법적인 접근을 막을 수 있습니다.
3. 암호화된 통신
   • 비공개 키와 공개 키는 암호화된 연결을 설정하는 데 사용됩니다. 이로 인해 네트워크에서 데이터를 주고받을 때 중간에서 탈취되는 일이 없도록 보장합니다.

실제 예시

1. 키 페어 생성 및 다운로드
   • AWS EC2 인스턴스를 생성할 때, 키 페어를 생성합니다. 이때 비공개 키를 다운로드합니다.
   • 이 키는 EC2 인스턴스에 SSH로 연결할 때 사용됩니다.
2. EC2 인스턴스에 접근
   • 예를 들어, ssh -i "your-key.pem" ec2-user@your-ec2-public-ip 명령어를 통해 EC2 인스턴스에 접근할 때, your-key.pem 파일(비공개 키)이 인증에 사용됩니다.
   • 만약 비공개 키가 없다면, 접근이 불가능합니다.

결론

키 페어는 보안적인 이유로 사용되며, EC2 인스턴스에 안전하게 접근할 수 있도록 하는 중요한 방법입니다. 비공개 키를 가진 사람만 해당 인스턴스에 접근할 수 있으며, 이 과정에서 암호화된 연결을 통해 데이터를 보호할 수 있습니다.

가상화 (Virtualization)

컴퓨터 자원을 물리적인 형태와는 독립적으로 사용할 수 있도록 만드는 기술
하나의 컴퓨터를 여러 대처럼 나눠서 쓰는 것

1. 하나의 컴퓨터에서 windows 와 linux를 동시에 실행하는 것처럼 가상 컴퓨터를 나눌 수 있음.
2. 자원을 효율적으로 활용 / 물리적인 서버 한 대에 가상 컴퓨터 여러 대를 올려서 서버 자원을 효율적으로 활용 가능
3. [ 하이퍼바이저 ] 이 소프트웨어가 물리적 자원을 가상화해서 여러 운영체제가 동시에 사용할 수 있게 해줌.

물리적인 컴퓨터 = 아파트 건물
가상 컴퓨터 = 아파트 안에 있는 각 세대

적고 생각해보니 그럼 클라우드랑 다른 점?
클라우드는 서비스(결과), 가상화는 기술(수단)

클라우드는 가상화 기술을 활용해서 제공하는 서비스
인터넷을 통해 컴퓨터 자원을 빌려씀.

AWS의 꽃 EC2는 무엇일까?

Amazon Elastic Compute Cloud 여서 EC2였다..

C가 두개여서 EC2로 불리는 것 또 처음알게된 사실

EC2는 크기 조정이 가능한 컴퓨팅을 클라우드에서 제공하는 웹 서비스임, 고로 해보면 좀 더 쉽게 클라우드 컴퓨팅 작업을 할 수 있음.

Amazon EC2의 간단한 웹 서비스 인터페이스를 통해 간편하게 필요한 용량을 얻을 수 있다.

언제사용하는지?

우리가 사용하는 게임서버 또는 웹서버 , 애플리케이션 서버를 구축할 때 EC2를 사용함.

비트코인 채굴도 가능한데 그럼 비트코인 채굴로 쓰는것도 가능하지 않을까?

AWS에서 서비스 제공안하고 비트코인 채굴하면 더 사업성에 좋지 않을까?

 - 비트코인 채굴로만 사용하면 경제성이 떨어질 수 있음

(채굴난이도 시간 지나면 증가하며 장비 업글해야함 그러면 AWS 회사 손해볼 수 있음 또한 당연하게도 비트코인 채굴하는 것보다 수익이 안좋으면 회사 손실이 큼)

 - 클라우드 서비스가 꾸준한 수익이고 안정성이 더 좋음 , 정부 규제로 AWS같은 대형 기업이 채굴 사업에 집중하면 규제 리스트에 영향도 크고 안좋을 수 있음.

단기적으로는 매력이 있어보이나 , 장기적으로는 서비스 제공이 더 좋다.

온디맨드 : 수요에 반응하여 가격이 초 단위로 결정됨

인스턴스 : 가상 서버 CPU,메모리,그래픽카드 연산 하드 웨어 담당

EBS : 가상 하드디스크 

AMI : 실행정보담고 있는 이미지

보안 그룹 : 가상 방화벽

DFS(깊이 우선 탐색) 최대한 깊이 내려간 후, 더 이상 갈곳 없으면 뒤로 돌아오는 방식
"깊이" 현재 노드에서 연결된 노드를 재귀적으로 따라가는 것 , 미로에서 한길로 가다가 막히면 뒤로 돌아와서 다른 길이 있다면 그 길로 가는 것

BFS(너비 우선 탐색) 가까운 노드부터 차례로 탐색하는 방식.
DFS는 스택과 비슷 , BFS는 Queue(FIFO) 방식

DFS
1. 1번에서 2,3,4로 갈 수 있음 2번 으로 이동
2. 2번에서 1,4 이동할 수 있는데 1은 왔던길이니 4로 이동
3. 4번에서는 3으로 갈 수 있음.
4. 3번에서는 이미 방문했으므로 종료
고로 1->2->4->3

BFS
1. graph 리스트에 각 정점의 연결 정보를 저장
2. 시작 정점 1
3. 1에 연결된 정점 : 2,3 -> 오름차순으로 2 먼저 탐색함
4. 2에 연결된 정점 : 4,5 -> 오름차순으로 4 탐색
5. 3에 연결된 정점 : 6

나머지 이미 탐색되어있음 1,2,3,4,5,6

bfs는 Queue 인터페이스와 LinkedList를 분리해서 사용 다양한 구현체( LinkedList, PriorityQueue, ArrayDeque 등)을 활용할 수 있음.

Queue<Integer> queue = new LinkedList<>();
queue.offer(1);
queue.offer(2);
queue.poll(); // 정상 동작: Queue 인터페이스의 메서드

LinkedList<Integer> list = new LinkedList<>();
list.addFirst(1); // LinkedList 고유의 메서드 사용 가능
list.add(2);
list.removeFirst(); // Queue의 FIFO 원칙과 맞지 않음

큐의 원칙에 위배되지 않게 , 인터페이스를 통해 동작을 방지할 수 있음 
LinkedList<Integer> list = new LinkedList<>();
LinkedList를 인터페이스로 했을경우 종속적이므로 지양

BFS에서 할일을 생각
1. 값 넣어주기
2. 방문 값 true로 바꿔주기
3. queue가 안비었으면 꺼낸 후 출력
4. 현재 노드와 연결된 모드 노드를 확인하고 , 방문하지 않은 노드 방문처리하고 다시 큐에 추가시킴

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;
import java.util.ArrayList;
import java.util.StringTokenizer;
import java.util.List;
import java.util.Collections;
import java.util.LinkedList;
import java.util.Queue;

class Main{
    static int N; // 정점의 개수
    static int M; // 간선의 개수
    static int V; // 정점 시작 번호
    static List<List<Integer>> adjList; // 근접 노드
    static boolean[] visited; // 방문

    public static void main(String[] args) throws IOException{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine()," ");
        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());
        V = Integer.parseInt(st.nextToken());

        adjList = new ArrayList<>(N+1);
        for(int i=0; i<=N; i++){
            adjList.add(new ArrayList<>());
        }

        for(int i=0; i<M; i++){ // 간선 입력 받아서 넣기
            st = new StringTokenizer(br.readLine()," ");
            int u = Integer.parseInt(st.nextToken());
            int v = Integer.parseInt(st.nextToken());
            adjList.get(u).add(v);
            adjList.get(v).add(u);
        }

        // 각 리스트들 작은 값 먼저 나와야 함
        for(int i=1; i<=N; i++){
            Collections.sort(adjList.get(i));
        }

        visited = new boolean[N+1]; // 방문체크
        dfs(V);
        System.out.println("");// 줄바꿈
        visited = new boolean[N+1]; // 방문체크
        bfs(V);
    }

    // dfs private으로
    public static void dfs(int n){
        visited[n] = true; // 방문했으니
        System.out.print(n + " ");
        for(int neighbor : adjList.get(n)){ // 방문한 노드 연결된 숫자 체크
            if(!visited[neighbor]){
                dfs(neighbor); // 방문 안했으면 다시 넣어서 방문
            }
        }
    }

    // bfs private으로
    public static void bfs(int n){
        Queue<Integer> q = new LinkedList<>();
        q.add(n);
        visited[n] = true; // 방문했으니 true

        while(!q.isEmpty()){ // q가 비어있지 않을때 까지
            int current = q.poll(); // 현재 꺼 꺼냄
            System.out.print(current + " ");
            for(int next : adjList.get(current)){
                if(!visited[next]){
                    visited[next] = true;
                    q.add(next); // next 방문 안했으면 다시 넣음
                }
            }
        }
    }
}

쓰는 이유?

1. 페이지 전환을 쉽게 만들 수 있게 도와줌

2. 페이지 새로고침 않고도 화면 이동

BrowserRouter

 - 애플리케이션 감싸는 최상위 컴포넌트

 - html 히스토리 사용해서 URL 관리함

설치방법

npm install react-router-dom

import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.jsx'
import './index.css'
import { BrwoserRouter } from "react-router-dom"; // react-router-dom 적용 시 추가

ReactDOM.createRoot(document.getElementById('root')).render(
    <BrwoserRouter> // 추가
        <App />
    </BrwoserRouter> // 추가
);

리액트앱에 모든 앱들이 BrowserRouter안에 있

게 된다.

import { Routes , Route } from "react-router-dom";

function App() {
  return <Routes />;
}

Routers 안에 여러 Router를 정의하여 URL 경로별로 렌더링할 컴포넌트 지정 가능

import NotFound from "./pages/NotFound";

function App() {
  return <Routes>
    <Route path="/" element={<1 />} />
    <Route path="/2" element={<2 />} />
    <Route path="/3" element={<3 />} />
    <Route path="*" element={<NotFound />}/>
  </Routes>;
}

Route path에 "*"를 설정하면 3개 안탈경우 해당 페이지 타게 설정된 것

Link컴포넌트 이용해서 다른 방법으로도 표현할 수 있음

import { Routes , Route , Link } from "react-router-dom";

<Link to={"/"}>Home</Link>
<Link to={"/1"}>1</Link>
<Link to={"/2"}>2</Link>
<Link to={"/*"}>NotFound</Link>

마찬가지로 링크 컴포넌트 이용해서 이동할 수 있다.

a태그를 이용하면 번들패키지로 전부 렌더링 되어 있는 MPA 방식으로 동작할 수 있음 SPA 원칙이 깨질 수 있다.

SPA vs MPA

 - SPA 단일 페이지 동작 , 클라이언트 측에서 페이지 전환함 (전부 가져오고 그 다음 누르면 그 부분만 보여주는 것)

 - MPA는 페이지가 독립적이여서 깜빡깜빡거림 자연스럽지가 않고 원할때 그 부분만 새로 로드하는 방식

도커 학습을 하고 , 집에와서 노트북을 키니 부팅시에 무한로딩하는 현상에 걸렸음

BIOS 모드에 진입 후에 부팅 순서를 변경하면 된다고 나왔음

그래서 부팅 순서를 LEGACY로 바꿧는데 그래도 정상동작하지 않았음

1. BIOS/UEFI 설정 확인

1. 컴퓨터를 재부팅하면서 Del, F2, F10, 또는 Esc 키를 눌러 BIOS/UEFI 설정에 진입합니다.
2. Boot Order (부팅 순서) 메뉴를 확인하세요.
   • OS가 설치된 드라이브가 첫 번째로 설정되어 있는지 확인합니다.
   • 드라이브가 없거나 순서가 잘못되었다면 수정하고 저장한 후 재부팅하세요.
3. Secure Boot:
   • Secure Boot 설정이 켜져 있으면 꺼보세요.
   • 이를 위해 Legacy Boot 옵션을 활성화할 수도 있습니다.
    

부팅모드는 2가지가 있었음 나의 경우

UEFI 모드가 좀 더

최신인데 이 설정일떄 안됐었음

Secure Boot 모드로 진입하려고 하는데 계속하

다보니깐 이번엔 F2로 진입 못하고 

검은화면에 "_" 표시만 있고 다른 동작하지않음.

검색해보니 물리적인 컴퓨터 내부문제가 생긴거라고함.

이경우 BIOS모드에 진입하지않음.

BIOS모드에 진입하지 않아서 다른 윈도우 컴퓨터를 이용해서 부팅디스크를 만드고 USB를 꽂았으나 F2로 부팅모드를 들어가지 못하여 이것또한 무용지물

컴퓨터 안에는 중요한 파일이랑 백업이 있는데 ㅜㅜ (물론 하드디스크에서 다른 컴퓨터로 옮기면 가능하긴 함)

노트북마다 모드진입이 다르긴 해서 다른것들도 다 해봤는데 이젠 BIOS 들어가지지도 않고 화면도 안나옴.

여기저기 글도 올리고, 서비스센터를 가려고 했으나 오기가 생겨서 유투브로 해외영상까지 다 찾아봐서 해결하력 노력했음

https://www.youtube.com/watch?v=gKIve6xnLU0

보통의 경우 위의 유투브 영상을 시청하면 똑같이 하면 해결되는데 나의 경우 그렇지 않았음.

Chatgpt의 확인결과 cmos배터리를 뺏다 꽂으면 bios 초기화돼서 다시 될 수 있다고함.

그래서 레노버 y540하판 분해 시작..

구글,네이버,유투브,레노버 공식 홈페이지를 찾아본 후 따라하였음.

순서는 이와 같음.

1. 하판 나사를 전부풀음

2. 기타피크로 (공식 영상에서도 기타피크를 이용해서 분해) 뒤 하판에 꽂은 후 (딱) 소리 날떄까지 한바퀴 돌려준 후 분해

3. 수직으로 천천히 뚜둑뚜둑(오래돼서 그런것 같음 본인 5년이상 사용했음)해서 분해

4. cmos배터리선을 뽑아야하는데 cmos배터리 선은 배터리 안에있었음

 - 처음에는 이 배터리를 교환하려고 다이소에서 가서 직접 CR2032 리튬 버튼전지,전기테이프를 사왔음(여기저기 문의한 결과 도움을 주신분이 해당 배터리를 교체해야할 경우도 있다고 하셔서)

 - 처음에 테이프 제거하려고했으나 + , - (빨간색,검은색) 연결이 되어있어서 이건 완제품으로 사야될 것 같았음 따로 판매하고 있는게 있음 

일단은 교체는 보류하기로했음

5. 쿨링팬에 먼지가 너무 많아서 물기 안묻은 칫솔로 전부 청소해줬음

6. 분해한다음 30분있다가 재결합하고 재부팅하니깐 성공

서비스센터 가려고했는데 4시간만에 해결했으니 시급 25,000원 너무 좋다!

평소에 중요한 자료들을 백업 잘해둬야겠음

1. 리액트 앱 생성

npx create-react-app ./
# 현재 폴더에 리액트 앱 생성

2. 도커 파일 생성

.dockerignore파일

package-lock.json
node_modules

docker-compose-dev.yml

services:
  web:
    build:
      context:  .
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      -/app/node_modules
      - .:/app
  tests:
    stdin_open: true
    build:
      context: .
      dockerfile: Dockerfile.dev
    volumes:
      - /app/node_modules
      - .:/app
    command: ["npm", "run", "test"]

docker-compose.yml

version: "3"
services:
  web:
    build: 
      context: .
      dockerfile: Dockerfile
    ports:
      - "80:80"

Dockerfile

FROM node:16-alpine as builder
WORKDIR '/app'
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM nginx
CMD --from=builder /app/build /usr/share/nginx/html

Dockerfile.dev

FROM node:16-alpine

WORKDIR '/app'

COPY package.json .
RUN npm install

COPY . .

CMD ["npm", "run", "start"]

3. 아마존 가입 후 IAM에서 역할 먼저 생성 

 - AWSElasticBeanStalk에서 멀티컨테이너,웹티어,워커티어 설정

AWS Elastic Beanstalk은 애플리케이션 배포 및 관리 간소화 해줌 PaaS임( 사용자가 인프라 관리 X)

복잡한 인프라 설정없이 빠르게 클라우드로 애플리케이션 배포 가능

서버 프로비저닝 , 로드 밸런싱 , 자동 스케일링

서버 프로비저닝 : 마치 컴퓨터 사서 운영체제 필요한거 설치 작업을 AWS가 해준다.

로드 밸런싱 : 들어오는 트래픽 여러 서버로 고르게 분배하여 서버 과부하 방지

자동 스케일링 : 트래픽 변화에 따라 서버의 개수를 자동으로 늘리거나 줄이는 기능

4. 검색에 elasticbeanstalk으로 간다.

환경 생성해준다.

5. IAM 가서 사용자도 생성

보안 자격증명에서 

엑세스 키 만들어야 함

만들면 액세스키랑 비밀 액세스 키 생성된다.

필요하기 때문에 개인 보관

6. S3 이동

클라우드 스토리지 서비스 , 데이터 인터넷에 안전하게 저장하고 관리 , 디지털 저장소

자동으로 생성된 버킷에 들어간다.

객체소유권에서 객체 라이터 , ACL 활성화됨 선택 잘되어있는지 확인

객체라이터 : 각 계정이 자신이 업로드한 데이터의 소유권과 관리를 계속 유지해야될 때

ACL 활성화 : 객체 소유자가 버킷 소유자와 다른 경우가 많아, 버킷 정책만으로 권한 관리가 어려운 경우

7. 리액트 빌드 테스트 성공하면 방금 만든 elasticbeanstalk에서 바로 배포(저장소 필요 깃헙생성)

8. 원격 저장소와 react app 연결 후 소스코드 올려줌

9. 올라간거 확인하고 Travis CI 대신 Github action 이용할 것

프로젝트에 .github 폴더와 workflows 폴더 그리고 deploy.yml 파일 작성한다.

10. deploy.yml에 필요한 계정 비밀 액세스 키 등은 깃허브 settings에서 Secrets and variables에서 설정가능하다.

깃 액션에서 자동으로 배포해주는 모습을 보여준다. 현재는 에러나서 해결 해야함.

도커 비밀번호가 틀려서 제대로 동작하지 못했음.

성공해서 도메인 들어갔는데 도커랑 연결이 되었다는 화면만 뜰분 내가 배포한 리액트 기본 이미지는 나오지 않았음

원인 분석해보니 Elastic Beanstalk의 애플리케이션 이름과 환경이 설정이 되지 않았음

• **actions/checkout**은 GitHub 리포지토리에서 코드 작업을 할 때 필수적인 기본 액션입니다.
• **einaregilsson/beanstalk-deploy**는 AWS Elastic Beanstalk에 애플리케이션을 배포하는 데 사용되는 액션입니다.

따라서, actions/checkout은 코드 다운로드에 사용되고, einaregilsson/beanstalk-deploy는 배포를 위한 액션입니다.

uses 에서도 actions를 배포를 위한 액션으로 바꿔줘야한다.

v20,v18 버전으로 바꿔봤으나 둘 다 빌드 실패했음 어느게 문제일까?

로그탭에서 로그 전체를 받아서 분석해본결과 docker-compose.yml파일에 version삭제하라해서 삭제했는데도 안됨..

FROM이 from으로 되어있다고 했는데 그건 문제가 아니였고

ngnix로 정적 파일 디렉토링해서 옮겨야되는데 CMD로 적어서 오류난거였음 COPY로 수정한다.