[구름 k8s] TIL 2-2-1

Peppie·2022년 9월 13일
0

1. 컴퓨팅 서비스 - EC2

private subnet 상의 EC2 instance 관리 방법

private subnet에 위치한 AWS resource (EC2, RDS 등)

  • 직접적인 인터넷 접속이 불가능
  • 외부로부터 직접 접근을 허용하지 않기 위해 구성하는 네트워크
  • 인터넷에 접속하여 사용하기 위해서는 NAT 게이트웨이 서비스 활용

NAT 게이트웨이 서비스

인터넷과 연결을 수행하는 서비스, 인터넷과 단방향 통신만 수행 (인터넷 게이트웨이는 양방향 통신 수행)

  • 통상 private subnet에 위치한 AWS 리소스 (EC2, RDS 등)가 인터넷에 연결하여 사용할 때 활용
  • 일반 client가 private subnet에 있는 AWS 리소스 접근 블가능 -> 단방향 통신
  • NAT 게이트웨이 서비스 인스턴스는 반드시 public subnet에 위치해야 한다. (위 이미지 참고)
  • NAT 게이트웨이 서비스는 EIP를 사용함

Bastion server를 이용하여 private subnet에 있는 AWS resource 접근 및 제어

  • Bastion Server : private server에 위치한 EC2 instance를 제어하는 목적으로 사용하는 EC2 instance, 역할에 따라 부여된 명칭

  • private subnet에 EC2 instance 생성

    • subnet : private subnet에 위치
    • 퍼블릭 IP 할당 : 비활성화
  • NAT 게이트웨이 생성

    • EIP 생성
      EC2 메뉴 -> 탄력적 IP -> 탄력적 IP주소 할당

    • NAT 게이트웨이 인스턴스 생성
      VPC 메뉴 -> NAT 게이트웨이 -> NAT 게이트웨이 생성
      • 이름 / 서브넷 (반드시 public subnet에 위치) / 연결유형 : 퍼블릭 / 탄력적 IP 할당

    • private subnet의 라우팅 테이블에 NAT 게이트웨이에 대한 라우팅 추가
      VPC 메뉴 -> 서브넷 -> 라우팅 테이블 -> private subnet 라우팅 테이블 선택 -> 라우팅 -> 라우팅 편집 -> 라우팅 추가 -> NAT 게이트웨이 라우팅 추가

private subnet에 위치한 EC2 instance는 NAT 게이트웨이를 통해 인터넷 접속 가능 상태,
but 외부에서 인터넷을 통해 private subnet에 위치한 EC2 instance에 직접 접속은 불가능
-> NAT 게이트웨이는 단방향 통신만 가능

public subnet에 위치한 bastion server를 통해 private subnet에 위치한 EC2 instance 제어

  • bastion server를 이용하여 private subnet의 EC2 instance에 접속하기 위해서는 private subnet의 EC2 instance에 대한 keypair 파일이 bastion server에 위치해야 함
  • bastion server에 priavte subnet의 EC2 instance용 keypair 파일 저장 방법
    • FTP 또는 git을 이용하여 keypair 파일 공유
    • VS Code 원격 접속을 통해 keypair 파일 업로드
  • 관리자 -> bastion server 접속 -> 필요시 keypair 파일을 bastion server에 저장 -> bastion server에서 private subnet의 EC2 instance 접속 -> 필요한 작업 수행

네트워크 보안

네트워크 통신

  • 패킷(packet) 단위 통신
  • 패킷에는 수신측 IP 주소, 수신측 포트 번호, 송신측 IP 주소, 송신측 포트 번호 정보 포함

AWS 네트워크 보안

인스턴스 보안

보안 그룹 (Security Group)

  • EC2 instance 단위로 설정
  • inbound / outbound 규칙으로 구성
  • 허용 규칙만 생성 가능
  • 기본적으로 모든 보안 그룹의 outbound 규칙은 모든 트래픽 허용, inbound 규칙은 모두 거부 설정
  • 각 EC2 instance는 서로 다른 보안 그룹 할당 가능
  • 설정된 EC2 instance는 연결된 보안 그룹의 모든 룰 적용 받음
  • 상태를 저장하는 성격(stateful) 가짐
    • inbound를 통과하는 패킷은 outbound 규칙 적용 X
    • 상태를 저장하여 한번 outbound를 통과하는 패킷은 inbound 규칙 적용 X

네트워크 보안

네트워크 ACL (NACL)

  • inbound / outbound 규칙으로 나뉨
  • NACL은 여러 subnet에 적용 가능 but subnet은 한개의 NACL만 연결 가능
  • 허용(Allow) 규칙뿐만 아니라 거부(Deny) 규칙 생성 가능
  • 규칙 번호는 숫자가 매겨져 가장 작은 숫자값을 지니는 규칙이 우선적으로 적용
  • 규칙 번호순으로 적용 (낮은 번호에서 높은 번호 순으로 적용)
    • 같은 유형에 대하여 규칙을 구성한 경우 낮은 번호의 규칙이 적용되면 높은 규칙 번호의 동일 규칙에 대해서는 적용 X
    • 규칙 번호는 연속된 번호보다는 일정 간격의 번호를 설정해야 차후 필요시 규칙 추가 용이
  • NACL 규칙 목록은 inbound, outbound 최대 20개까지 지정 가능
  • NACL은 상태를 저장하지 않는 성격(stateless) 가짐
    • 상태 저장 X -> 한번 inbound를 통과하는 패킷은 outbound 규칙 적용, outbound를 통과하는 패킷은 inbound 규칙 적용 받음
  • VPC 메뉴 -> 네트워크 ACL -> 네트워크 ACL 생성

    이름 / VPC 설정

  • 네트워크 ACL 선택

    subnet 연결

    • subnet 연결 편집 -> subnet 선택

    inbound / outbound 규칙 추가

    • 규칙 번호 / 유형 / 프로토콜 / 포트 범위 / 소스 / 허용 or 거부 설정
  • 보안그룹과 네트워크 ACL (NACL)을 조합하여 필요한 보안관리 수행 가능
  • 통상은 보안그룹을 통해 관리

번외) 용어 정리

stateful

상태를 저장

stateless

상태를 저장하지 않음

2. 스토리지 서비스 - EBS

스토리지 서비스

데이터나 객체를 저장하기 위한 목적으로 사용하는 AWS 서비스

종류

EBS (Elastic Block Storage)

블록 형태 데이터 저장 스토리지 서비스

  • 일반적인 데이터 저장
  • 외장 HDD/SSD 성격
  • EC2 instance와 연결하여 사용 (단독사용 X)
  • 하나의 가용영역에서만 사용 (바뀌면 접근 불가)

EFS (Elastic File Storage)

파일 형태 데이터 저장 스토리지 서비스

  • 네트워크를 이용한 파일 저장 및 공유
  • NAS 성격
  • 데이터 공유
  • 통상은 EC2 instance와 연결하여 사용 -> 이때 사용하는게 NFS (Network File System)

S3 (Simple Storage Service)

객체 형태 데이터 저장 스토리지 서비스

  • 객체 (object) 단위로 저장
    • 객체 : 유/무형의 모든 형식의 사물
  • serverless 방식 : 별도의 EC2 instance와 연결하지 않더라도 사용 가능
  • AWS의 다른 서비스와 데이터 공유를 목적으로 할 때 많이 사용

EBS (Elastic Block Storage)

EC2 인스턴스 스토리지 볼륨

  • EC2 instance의 기본 저장 공간으로 사용하는 EBS
  • EC2 루트 볼륨 의미
  • 항상 EC2와 연동하여 사용
  • EC2 instance 삭제시 인스턴스 스토어 볼륨도 같이 삭제되므로 중요 정보 보관 필요
  • 참고

EBS (Elastic Block Storage)

  • AWS 기본 블록 스토리지
  • application의 기본 스토리지로 사용하거나 시스템 스토리지로 사용하는데 적합
  • 필요시 EC2 instance에 마운트하여 사용
  • 한번 크기가 정해지면 중간에 크기 변경 불가능
  • 같은 가용영역의 EBS만 공유 가능
  • 하나의 EC2 instance만 EBS 볼륨과 연결해서 사용 가능
  • 사용 목적 : 데이터 보관, 스냅샷 저장
  • 참고

EBS 공유 실습

2개의 EC2 instance 간에 EBS 볼륨을 이용한 데이터 공유

EBS 생성

EC2 메뉴 -> 볼륨 -> 볼륨 생성

  • 볼륨 유형 선택
  • 크기 결정
  • 가용 영역 선택
  • 태그명 지정

EC2 instance와 연결

  • EC2 instance와 EBS 볼륨 연결
    • EC2 메뉴 -> 볼륨 -> 작업 메뉴 -> 볼륨 연결

      인스턴스 선택
      디바이스 이름 확인 : OS에서 마운트할 때 연결할 디바이스 이름

  • 연결된 볼륨에 대하여 EC2 instance의 OS에서 mount 작업
    • lsblk : 연결된 디바이스 정보 확인
    • df -h : 디바이스 연결 상태 확인
    • sudo mkfs -t ext4 /dev/xvdf : 연결할 EBS 볼륨에 대한 file system 생성
    • sudo mount /dev/xvdf /mnt : /dev/xvdf에 연결된 EBS 볼륨과 /mnt 디렉토리 마운트
    • sudo umount /mnt : 마운트 해제
  • 기존 EC2 instance와의 연결 해제 및 새로운 EC2 instance와 연결하여 마운트해서 사용

EBS 사용이 적합한 경우

  • 데이터에 빠르게 액세스하고 장기적으로 지속해야 하는 경우
  • 세분화된 업데이트가 필요하고 형식이 지정되지 않은 블록 수준의 원시 스토리지에 액세스 해야하는 파일시스템, 데이터베이스 또는 application의 기본 스토리지로 사용하기에 적합
  • 임의 읽기 및 쓰기에 의존하는 데이터베이스 스타일의 application / 장기간의 읽기 및 쓰기를 수행하는 처리량 집약적 application 모두 적합

3. 네트워크 서비스 - ELB

scale out

  • 동시 접속 client 수에 따른 서버 분산 처리 -> 서버 부하 분산
  • EC2 instance를 복제하여 여러 개의 EC2 instance를 생성하는 동작
  • client 동시 접속 증가에 따라 server 처리 능력을 높이기 위하여 같은 동작을 하는 server를 여러개 생성하여 client 동시 접속에 대한 처리 효율을 높이는 방법

AWS Scale out을 위한 서비스

ELB (Elastic Load Balancing)

동시접속 client를 여러 서버로 분산해서 처리할 수 있도록 관리하는 서비스, 서버 분배

Auto Scaling

서버 처리량에 따라 서버를 자동 증설 및 감소시키는 서비스

ELB

Elastic Load Balancing (참고)

  • 트래픽 분산
  • 자동 확장 (auto scaling)
  • EC2 instance 상태를 자동 감지하여 오류가 있는 시스템은 제외
  • 사용자 세션을 특정 instance에 고정 가능
  • SSL 암호화 지원
  • SSL의 경유지로 ELB를 사용하는 경우에 SSL 처리에 따른 부하를 ELB가 수용
  • IPv4 / IPv6 지원
  • Amazon CloudWatch를 통한 모니터링
  • 사용한 시간과 통과한 트래픽에 따라 종량제 과금

OSI 7 계층 네트워크 프로토콜에서 L4 (Transport) 계층과 L&(Applicaion) 계층에 대한 서버 부하 분산 기능 제공 (참고1) (참고2)

L4 (Transport) 계층 : TCP, UDP에 대한 처리 계층 - Network Load Balancer
L7 (Application) 계층 : HTTP, HTTPS 등에 대한 처리 계층 - Application Load Balancer

4. 컴퓨팅 서비스 - Auto Scaling

Auto Scaling

참고1 참고2

  • scale out 적용시 사용하는 기능
  • 다중 서버 운영시 서버의 일정한 부하 임계치를 넘었을 때 자동으로 서버 증가 or
    부하 임계치가 해소되었을 때 다시 원래의 서버수로 자동 변화를 수행하는 서비스

5. TIF

지난 며칠간 내 골머리를 많이 썩히던 EC2 - VSCode 연동 문제가 드디어 해결됐다! 인터넷에 검색했을 때 나오던 내용대로 하니까 갑자기 됐는데, 솔직히 지난주 수업 내용대로 한 접속방법과 큰 차이가 안나서 저번엔 안됐던 정확한 원인은 여전히 잘 모르겠다. 그냥 이것도 컴퓨터가 변덕을 부렸다고 생각하면 마음 편할지도.

오늘 배운 내용은 전반적으로 네트워크 느낌이 강했다. 왜 네트워크 엔지니어들이 클라우드 엔지니어 쪽으로 많이들 넘어가는지 알 것 같았다.

0개의 댓글