쿠버네티스 전문가 양성과정 6주차 5일(1/27)

최수환·2023년 1월 27일
0

Kubernetes

목록 보기
26/75
post-thumbnail

AWS 데이터베이스

데이터베이스

  • 여러 사람에 의해 공유되어 사용될 목적으로 통합하여 관리되는 데이터의 집합
  • 정보를 구조화하여 빠르고 효율적인 검색 및 갱신이 가능하도록 구성
  • DBMS를 통하여 관리됨
  • SQL을 통한 표준화된 접근 지원
  • DB의 트랜잭션은 ACID를 만족한다

RDBMS

  • 데이터베이스의 데이터 간 사전에 정의된 관계가 있는 데이터 항목의 모음
  • 열과 행으로 구성
  • 기본키와 외래키가 있다
  • 각 속성간 관계, 순서가 있는 데이터베이스 = 관계형 데이터베이스 <-> 비관계형 데이터베이스(NoSQL) ,구조화되지 않음

Amazon RDS : 아마존의 관계형 데이터베이스
Amazon DynamoDB : 아마존의 NoSQL 기반 비관계형 데이터베이스

RDS 실습

<VPC 생성>

  1. VPC생성
  2. 퍼블릭, 프라이빗 서브넷 생성
  3. igw생성 및 VPC연결
  4. 라우팅 테이블 생성 및 퍼블릭 서브넷에 명시적연결, 라우팅 편집으로 igw에 연결
  5. 탄력적 ip 할당
  6. 탄력적 ip를 이용한 nat게이트 퍼블릭 서브넷에 생성
  7. 기본 라우팅테이블에 라우팅 편집으로 모든 ip에 대해 nat게이트웨이 연결

<인스턴스 두개 생성>

  1. 퍼블릭 서브넷에 배치할 인스턴스 생성
  2. 보안 그룹 추가 및 ssh, MYSQL/Aurora 추가
  3. 프라이빗 서브넷에 배치할 RDS용 인스턴스 생성
  4. 이전에 만든 기존의 보안그룹 선택

<DB접속>

  1. SSH로 퍼블릭 인스턴스에 접속
  2. sudo -i
    루트권한으로 변경
  3. yum -y install mariadb
    mariadb 설치 (클라이언트 프로그램)
  4. vi key
    프라이빗 인스턴스 생성할때 사용한 pem키 내용 복사
  5. chmod 400 key
    key 권한 변경
  6. ssh로 프라이빗 인스턴스에 접속
  7. sudo -i 
    루트권한으로 변경
  8. yum -y install mariadb-sever
    mariadb 서버 설치 (서버 프로그램)
  9. systemctl start mariadb.service
    mariadb 데몬 실행
  10. systemctl enable mariadb.service
    mariadb 데몬 영구 실행
  11. mysql_secure_installation
    비밀번호 설정 및 원격접속 허용
  12. mysql -u root -p
    데이터베이스 접속
  13. use mysql
    mysql 사용
  14. select user,host from user;
    user, host 확인
  15. create user 'root'@'%';
    host가 없는 root 추가
  16. mysql -u root -p -h privateip 
    exit 후 인스턴스에서 DB에 접속되는지 확인

<RDS 생성>

  1. 표준생성 선택
  2. MariaDB 선택
  3. 프리티어 선택 (프리티어는 멀티AZ배포를 지원안한다)
  4. DB이름과 암호를 설정
  5. 이전에 만든 VPC설정, 기존 보안 그룹 설정, 가용영역을 설정한다

    -> 퍼블릭 액세스를 가능하게 하면 나의 VPC뿐 아니라 외부의 VPC에 속한 리소스도 RDS에 접근이 가능해진다
  6. 속도를 빠르게 하기위해 자동백업은 비활성화 해놓는다
  7. mysql -u admin -p -h test-db2.cdsm0tvbt6jn.ap-northeast-2.rds.amazonaws.com

    퍼블릭 또는 프라이빗 인스턴스에서 해당 RDS 엔드포인트를 입력하여 RDS에 접속이 가능하다
  8. use mysql
    mysql 사용
  9. create user dbuser@'%';
    새로운 user 추가
  10. select user,host from user;
    user,host 보기

AWS DNS


로컬에서 3단계를 거쳐 도메인에 해당하는 IP를 찾고, 없다면 DNS서버의 루트서버(".")로 넘어간다. 이때 재귀쿼리가 시작하고 루트서버는 1단계,2단계,3단계를 거치면서 IP를 찾아내는 순환쿼리를 실행한다. 최종적으로 도메인에 해당하는 IP를 결과로 반환한다.
📒 레코드가 A이면 IP를 결과로, NS이면 네임서버를 결과로 반환하는 것처럼 레코드에 따라 결과가 다르다
📒 www.naver.com. => 마지막 "."이 루트서버이다
📒 DNS과정은 도메인을 거꾸로 시작해서 찾는다
📒 회사에 자체 DNS서버가 있다면 루트DNS서버까지 가는 시간을 아낄 수 있고, 한번 쿼리를 통해 얻어진 결과를 자체 DNS서버에 일정 기간동안 캐시해놓는다면 다음 DNS요청은 쿼리를 하지않아도 캐시된 데이터를 그대로 반환하기 때문에 속도가 매우 빨라진다.

AWS Route 53

  • AWS를 통해 사용할 수 있는 클라우드 기반 DNS 서비스
  • Amazon EC2인스턴스, ELB, S3 등의 연결정보 제공
  • 외부 서비스 연결 정보 제공
  • 다양한 부가 옵션 제공
    • 로드 밸런싱
    • 연결 체크를 통한 페일오버 구성
    • 지연시간 기반 라우팅, 가중치 기반 라우팅, 지역 기반 라우팅 등 다양한 라우팅 기법을 구성

로드밸런싱

네트워크 트래픽을 하나 이상의 서버나 장비로 분산하기 위한 기술

Amazon ELB

  • AWS에서 사용하는 로드밸런서
  • Application Load Balancer, Network Load Balancer,
    Classic Load Balancer 가 있다.
  • 상태 확인 서비스 (헬스 체크)
    • ELB와 연결된 인스턴스의 연결상태를 체크
    • 헬스 체크 실패 시 트래픽 전달 차단
  • Sticky Session
    • 기본 동작 방식은 라운드 로빈 방식으로 세션 유지 보장 x
    • 세션 유지가 필요한 경우 Sticky Session 옵션을 사용하여 세션 유지
  • ACM에서 SSL/TLS 인증서를 발급받아 보안을 강화할 수 있다.
  • AWS 로드 밸런서 참고
  • AWS 홈페이지 참고

ELB(ALB) 실습

<인스턴스 3개 생성>

  1. 퍼블릭 서브넷으로 인스턴스 생성
  2. HTTP,SSH가 추가된 보안그룹 생성
  3. 사용자 데이터 스크립트 작성 후 인스턴스 개수 3개로 생성

    -> 사용자 데이터 스크립트를 통해 3개의 인스턴스에 일일이 설정할 필요없이 일괄적으로 해당 스크립트가 실행되게 한다

    -> 3개의 인스턴스에 스크립트가 실행되면서 각각의 public ip주소를 브라우저에 입력하면 index.html의 내용= hostname이 보여지는 것을 확인

<타깃그룹 생성>

  1. 로드밸런싱에서 타깃그룹 선택 및 설정,생성



    -> vpc만 선택해도 해당 vpc에 포함된 인스턴스가 선택목록에 나타난다
    -> 타깃그룹에 넣을 인스턴스 선택후 pending시킨다
    = 타깃그룹 생성

<로드밸런서 생성>

  1. 로드밸런서 클릭 후 ALB 선택

    -> 로드밸런서 이름 선택 및 ipv4주소 사용, 인터넷 사용

    -> 이전에 만든 vpc선택 및 가용영역 두개와 각각 퍼블릭, 프라이빗 서브넷 선택
    📒 프라이빗 서브넷은 igw가 연결된 라우팅테이블이 명시적 연결이 안되어있기 때문에 라우팅 테이블에서 명시적 연결로 프라이빗 서브넷을 추가한다

    -> 이전에 만든 보안그룹 추가

    -> 리스너그룹에 이전에 만든 타깃그룹 추가

    -> 로드밸런서 생성 및 DNS이름 확인

    -> DNS이름을 브라우저에 입력하고 새로고침을 계속 누르면 계속해서 화면이 바뀌는 것을 확인 = 로드밸런싱

    -> 인스턴스 하나를 종료하게 되면 로드밸런서가 헬스체크 후 트래픽을 중단시키게 되고 타깃그룹에 해당 인스턴스는 "unused"로 나타난다

<Sticky Session 설정>

  1. 타깃 그룹에서 속성에 들어가 편집을 누른다
  2. 아래와 같이 3초로 설정한다
  3. 실제로 브라우저에 dns주소를 입력하고 새로고침을 계속누르면 화면이 바뀌지않는것을 볼 수 있다 = 세션 고정
    그러나 3초동안 아무 입력도 하지않고 있다가 3초뒤에 새로고침하면 화면이 바뀌는 것을 볼 수 있다 = 다른 세션으로 고정

Auto Scailing

가용성

  • 시스템이나 서비스가 가동 및 실행되는 시간의 비율
  • 측정 단위로 '9'를 사용
  • 고가용성 시스템 : 중요 업무 시스템 및 서비스 다운 타임이 허용되지 않는 시스템

확장성

  • 성능 요구 증가 시 서비스나 응용프로그램이 향상될 수 있는 정도
  • 확장성이 높을 경우 유동적인 서비스 요구 증가에 유연하게 대응 가능
  • 스케일 방식
    • 스케일 업/다운 : 단일 시스템에 대한 하드웨어 사양 변경
    • 스케일 아웃/인 : 하드웨어 사양 변경 대신 시스템 수량 변경

Auto Scailing

  • 클라우드 환경의 장점을 극대화하는 기능
    • 서비스 구축 단계에서 예상 최대치의 인프라를 구축할 필요가 없음
    • 성능 요구 증가시 신속한 대응 가능
  • Auto Scailing Group
    • Auto Scailing을 할 인스턴스의 집합
  • 템플릿 (양식지,패키지)
    • 시작 구성 (구버전) = 버전관리 x
    • 시작 템플릿 (신버전) = 버전관리 지원
      💡 두개의 차이점은 이미 작성된 템플릿의 내용에 대한 수정 유무

Auto Scailing 실습

  • 시작구성으로 인스턴스 생성
  • 시작템플릿으로 인스턴스 생성
  • Auto Scailing에 로드밸런스 (CLB,NLB,ALB)

<시작구성 생성>

  1. 시작구성은 AMI를 ID로 선택해야하기 때문에 AMI카탈로그에 들어가 원하는 AMI ID를 복사한다.
  2. 복사한 ID 입력 후 이름과 유형 설정
  3. 쉘 스크립트 입력
  4. 기존보안그룹 http+ssh 선택
  5. 키페어 선택

<Auto Scailing Group 구성>

  1. 이전에 생성한 시작구성 입력
  2. 이전에 생성한 vpc 네트워크 설정
  3. 현재 용량, 최소/최대 용량 설정

    📒 대상 추적 크기 조정 정책을 선택시 모니터링할 지표가 뜨는데 cpu사용률을 선택하면 cpu사용률이 올라가면 인스턴스를 추가하고 cpu사용률이 내려가면 인스턴스를 축소한다
  4. Auto Scailing Group 생성 후 인스턴스 3개가 생성된 것을 확인
  5. 하나의 인스턴스를 임의적으로 종료하면 자동으로 새로운 인스턴스 하나가 시작되는 것을 확인
  6. Auto Scailing Group 설정에서 편집을 통해 현재 용량을 1만큼 줄이면 인스턴스 하나가 자동으로 종료되는 것을 확인
  7. Auto Scailing Group 삭제 시 모든 인스턴스 종료

📒 시작템플릿과 다르게 시작구성은 설정UI도 복잡하고 한번 설정하면 수정하기위해 다시 처음부터 만들어야하는 단점이 있다

<시작템플릿 생성>

  1. 시작템플릿 생성
  2. 인스턴스 생성 처럼 AMI, 키페어, 유형 등을 설정해준다. -> 네트워크를 빼먹었다
  3. 템플릿 수정(새 버전 생성) 클릭
  4. 빼먹은 네트워크 설정 후 새로운 버전2를 만든다
  5. 쉘 스크립트 부분을 빼먹어서 다시 템플릿 수정 클릭 후 스크립트 추가 후 새로운 버전3를 만든다.

    📗 새로운 버전 생성시 이전에 설정들이 제데로 보존되어 있는지 확인

<CLB를 이용한 AutoScailing>

  1. CLB선택 후 VPC선택
  2. CLB 생성
  3. Auto Scailing Group 생성
  4. 기타 설정
  5. 이전에 만든 CLB선택
  6. 생성 후 브라우저에 DNS이름 입력하면 로드밸런싱 되는 것을 확인

<ALB를 이용한 Auto scailing>

  1. 타깃그룹 생성 : 아직 인스턴스는 없음
  2. 타깃그룹으로 ALB 생성
  3. Auto Scailing Group생성
  4. 이전에 생성했던 ALB연결

  5. 브라우저에 ALB의 DNS이름 입력하면 로드밸런싱 되는것을 확인
  6. ssh로 인스턴스 하나에 접속
  7. sudo -i , systemctl stop httpd
    한개 인스턴스 웹 서버 종료
  8. 실제로 대시보드를 보면 타깃그룹에서 로드밸런서가 트래픽을 보낸것에 응답이 없는 것을 확인하고 해당 인스턴스가 바로 'unhealthy' 상태가 되는 것을 볼 수 있다. 이후 draining상태가 되면서 해당 인스턴스를 완전히 종료시키지 않고 설정 시간 300초 동안 기다린다. 이때 Auto Scailing Gruop에서는 'healthy상태' 3개를 유지해야하기 때문에 인스턴스 하나를 새로 가동한다. 로드밸런서가 총 4개의 인스턴스에 로드밸런싱하다가 draining시간 300초가 지났는데도 해당 인스턴스에 응답이 없으므로 맛이 갔다고 판단하여 완전히 종료시킨다.
    📒 unhealthy상태에서 바로 종료시키지 않고 draining상태로 설정시간만큼 기다리는 이유는 네트워크가 잠깐 끊겼던 걸수도 있고 아니면 다른 작업중이거나, 하고 있던 작업이 있을 수 있는 다양한 이유때문에 기다리는 것이다.
profile
성실하게 열심히!

0개의 댓글