선수지식
네트워크 기본 지식
- 네트워크 프로토콜 : 네트워크 통신을 위한 통신 규칙
- 프로토콜의 역할은 데이터의 캡슐화와 캡슐 해제화를 으미
- 네트워크 통신에서 OSI 참조 계층을 넘을 때마다 데이터를 캡슐에 넣거나 꺼내는 것을 의al
- IP 주소 체계
- 전송계층(Layer 4)으로부터 받은 데이터(segment)에 IP 헤더를 붙여 패킷으로 만드는 역할
- IP header = 필드값(버전, 헤더길이, 프로토콜 등) + 출발지 IP 주소 + 도착지 IP 주소
- IP주소는 32비트로 된 식별번호
- 네트워크부 + 호스트부
--> 호스트부는 네트워크에 연결되어 있는 단말 나타냄
- 서브넷 마스크 : 1의 값 갖는 부분이 네트어크, 0 값은 호스트부
- 게이트웨이 : 인터넷 공간에서 각기 다른 호스트 사이를 연결해주는 기능
- 무선 공유기와 같음(공유기를 통해 인터넷이 접속하는 관문과 같은 것)
- 다른 말로 라우터
- 라우팅 테이블 : 라우터(Layer 3)가 라우팅 테이블을 이용해 패킷을 전송함
- 라우팅이란 라우터가 네트워크에서 패킷을 목적지까지 최적의 경로를 선택하는 과정
- 목적지 네트워크로 가기 위해 보내야하는 곳의 IP주소(next hop)
- 패킷이 목적지까지 가는 데 거치는 라우터의 개수를 홉 수(hop count)라고 함
- 정적라우팅 : 수동으로 라우팅 테이블 만드는 것
--> 하나하나 다 설정해야 함
--> 소규모 네트워크에서 주로 사용
- 동적라우팅 : 인접 라우터들끼리 정보를 교환하여 라우팅 테이블 자동으로 만드는 것
--> 대규모 네트워크 환경에서 주로 사용
- 리모트 로그인
- RDP : 원격 데스크탑 프로토콜
--> MS가 개발
--> 다른 PC에 그래픽 사용자 인터페이스 제공
--> GUI 제공
- SSH : Secure Sell
--> 원격지로 연결이 가능하도록 하는 네트워크 접속 도구
--> 리눅스는 RDP 지원 안됨
--> GUI 제공 안됨
--> 암호화 가능
데이터베이스 기본 (기본 SQL 명령어)
- DB
- DDL (데이터베이스 정의어)
- 예시
- DML (데이터베이스 조작어)
- DCL (데이터베이스 제어어) : 데이터 접근 권한 부여 및 제거
- 권한 종류 : CREATE, ALTER, DROP, INSERT, DELETE, SELECT 등
- TCL (트랜젝션 제어어) : 데이터 조작어 명령어 실행, 취소, 임시저장 (트랜젝션 : 분할할 수 없는 최소 단위)
스토리지 기초 (스토리지 접속 방법)
- DAS (Dirext Attached Storage) : 서버와 외장형 스토리지 사이를 전용 케이블을 통해 직접 접속하는 방법
- 전용라인 사용으로 성능 보장과 높은 안정성
- 단점 : 다른 서버에 접근 불가 => 파일공유 X, 확장성 및 유연성 낮음
- NAS (Network Attached Storage) : LAN을 통해 스토리지에 접속하는 것
- 개인이 많이 쓰는 Home Cloud의 개념이 NAS 방식
- 애플리케이션 서버의 데이터를 네트워크를 통해 저장함
- 네트워크가 연결된 곳에서는 언제 어디서라도 스토리지를 접속해서 사용할 수 있음
--> 애플리케이션 서버에 대한 저장장치로서의 역할
- 데이터 공유 가능이 가장 큰 장점
- 단점 : 네트워크 환경 불안정할 경우 트래픽 문제 발생, Latency Time 증가로 대규모 처리에서 성능문제 발생
- SAN (Storage Area Network) : 광채널을 기반으로 서버와 스토리지를 연결하는 네트워크
- DAS와 NAS의 개념이 혼용된 고속 네트워크
- 중앙 집중적 관리가 용이하며 높은 효율성과 매우 빠른 속도
- 단점 : 여러 서버들 사이에 파일 공유 안됨(독립적), NAS에 비해 많은 비용과 장비 투자 필요
- NAS vs SAN : 일반적으로 NAS는 클라이언트 대 호스트 연결에 가장 적합하여 SAN 연결은 고속 파일 공유와 호스트 대 스토리지 열결에 더 적합 / NAS 연결은 기존의 Infra를 사용하기 때문에 비용이 적게 들고 비교적 설치 용이하지만 속도가 SAN에 비해 몹시 느림
AWS 기초지
AWS(아마존 웹 서비스)란?
- 아마존에서 운영하는 클라우드 컴퓨팅 서비스
- 클라우드 컴퓨팅 서비스 : Internet을 통해서 내가 원하는 IT 리소스를 On-demand로 구현하고 종량 요금제로 지불
- 클라우드는 일회용품이라고 생각하며 쓰는 것이 가장 잘 쓰는 것
- On-Premise : 용량 산정 계획, 초기 대규모 비용 들어감
- 기존 온프레미스와 AWS를 함께 사용하는 Hybrid 방식으로 많이 사용함
클라우드 컴퓨팅의 장점
- 초기 대규모 투자비용 불필요 (종량 요금제)
- 유지 관리에 드는 비용 및 관리 노력이 줆 ( 온프레미스와 대비되는 점)
- 규모의 경제로 얻는 비용 절감 (점점 서비스 비용을 낮추겠다는 전략! 박리다매라고 할 수 있지)
- 고객의 입장에서도 비용을 세이브하며 서비스를 이용할 수 있는 것
- 전세계 원하는 곳에 (region)
- 빠르게 서비스 패포됨
- 유연한 용량 계획
AWS Infra ( Region, AZ)
- Region : 리전은 가까운 AZ들을 모아둔 것
- AZ : Availability Zone, 가용영역으로 DCs(데이터센터들)을 모아둔 것
- 현재 서울은 4개의 가용 영역으로 이루어져 있음
- 리전을 선택한다는 의미
- Latency(지연시간)을 고려해서 선택하는 것이 좋기 때문에 가까운 리전을 선택해 사용하는 것이 좋음
- 비용의 차이 (리전마자 비용이 조금씩 다름)
- 법적인 문제 (리전별로 법적으로 문제가 되는 경우가 있음)
- 가용서비스 (리전마다 가능한 서비스가 다를 수 있음)
AWS의 쉬운 접근 및 사용
- 관리 콘솔 : 웹 브라우저의 GUI로 AWS를 조작하는 화면
- 서비스별로 대시보드가 존재해 서비스를 설정하고 운영할 리전 선택, 계정 관리와 같은 요소들을 쉽게 관리 가능
- 매니지드 서비스 : AWS가 관리하는 서비스의 통칭
- 백업 및 업데이트가 자동으로 이루어져 관리자가 수동으로 할 필요가 없기 때문에 관리 부담이 줄어듦
- 일정한 안전상태 유지 가능
*이외에도 서비스 도입 사례와 AWS 비용에 대해 얘기했지만 넘어가도 될 부분 같음!
AWS를 이해하기 위한 클라우드 & 네트워크 구조
클라우드와 온프레미스
- 클라우드 : 언제 어디서 접속 가능한 환경
- 대표 사례 : AWS, Google Cloud Platform, Azure, CloudXper
- 온프레미스 <=> 임대 및 공용
가상화와 부산처리
- 가상화 구조 : 물리 서버 한 대에 가상 서버 여러 대를 생성하는 것
- 물리서버의 경우, 대수를 늘리려면 서버(PC) 자체가 여러 대 필요함
- 가상서버의 경우, 물리 서버 한 대에 가상 서버 여러 대를 생성할 수 있는 것
- 분산처리 : Load Balancer(로드 밸런서)로 서버 여러대에 분배하는 것
*SaaS, PaaS, IaaS는 별로 안중요하다고 하심 그냥 AWS는 EaaS임 (Everything as a Service) 앞에 세개 모두 통칭하는 것
서버와 클라이언트, 인스턴스
- 서버 : 어떠한 서비스를 제공하는 것
- 필요한 요소 : CPU, 메모리(메인 메모리), 메인보드, 스토리지, OS
- 대표적인 서버 : 웹 서버, 메일 서버, 데이터베이스 서버, 파일 서버, DNS, FTP, 프록시, 인증 등
- 클라이언트 : 서버에게 서비스를 요청하는 것
- 웹 서버와 클라이언트 (웹 브라우저)
--> 웹 브라우저 --접속--> 웹 서버 --요청전달--> 웹 브라우저
--> 웹 브라우저가 HTML 파일이나 이미지 파일을 웹 페이지로 구성
--> 웹 서버는 해당하는 HTMl 파일이나 이미지 파일 전달
- 인스턴스 : 실체라는 의미, 실제 가동되고 있는 가상화 컴퓨터
- 예를 들면, 서버라고 하면 실체인지 물리적인 서버 자체인 지 애매하지만 인스턴스라고 하면 서버로 가동되고 있는 가상 서버를 말한다
- 서버용 OS : 하드웨어와 OS 위에서 동작하는 소프트웨어 사이에서 중간 역할을 하는 것
- 유닉스가 리눅스와 윈도에 비해 좀 더 안정적 (벤더사들이 정해져 있기 때문 + 하드웨어도 같이 판매함)
--> 단점은 고가 (시스템 박스도 같이 사는 거니까)
- 리눅스 (minix, 미니 유닉스) : 유닉스의 단점 극복을 위해 만든 운영체제
--> 대체로 GNU 라이선스, 프리한 편 / 단점은 궁합이 안맞을 수 있음(상세 설정을 사용자가 직접 해야 함)
- 윈도우의 장점은 UI, 비용은 구성하기 나름
- 예산, 안정성, UI 중 원하는 것에 맞춰 선택하면 됨
IP와 DNS
- IP주소 : 사설IP 주소, 공인IP 주소가 있음
- 인터넷에서 사용되는 것은 공인 IP 주소 => 전 세계에서 어떤 것도 중복되는 일은 없음
- 사설 IP 주소 : 사내 LAN이나 가정 LAN 에서 사용되는 IP 주소
- DNS : URL에 포함된 이름에 해당하는 서버의 IP 주소를 알려주는 방식
- Domain Name Service : AWS에도 있는데 그거 이름이 Route 53
EC2 기본
AWS의 사용법과 계졍
- AWS 접근 도구
- 관리 콘솔 : 클릭해서 사용
- CLI : 명령어 입력해서 사용 / 장점은 자동화 가능, 단점은 첨에 어려울 수 있음
- SDK : 다양한 개발 언어 지원해서 애플리케이션 만들어서 접근 가능하도록 함
- root 사용자 : AWS 계정생성 email / 무한 권한
- AWS 콘솔 접근 : 다양한 관리 가능
- EC2 대시보드가 대표적인 에시
- 같은 EC2 서비스라도 리전별로 다른 것으로 간주함
서버 서비스 Amazon EC2
- Amazon Elastic Compute Cloud : 서버에 필요한 세트를 클라우드에서 빌릴 수 있다는 뜻
- 시스템박스/ 호스트 / 인스턴스/ 노드/ 서버 => 이런 개념의 서비스 제공
- 매니지드 서비스 아님!!
- 누구든지 바로 사용할 수 있고, 여러가지 기능을 선택해서 사용할 수 있음
- 바로 생성 가능, 바로 삭제 가능 => 불확실성이 많은 경우에 매우 유용함
인스턴스 주요 요소
- 인스턴스 : AWS 클라우드에 생성한 가상 서버, AMI로 같은 구성의 서버 생성 가능 => 생성한 서버를 가르킴
- AMI : Amazon Machine Image , 가상 이미지 OS를 베이스로 여러 (OS + @)
- 사용할 OS 선택 (AWS에서도 자체 배포판 제공함! Amazon Linux 2 같은 것)
- 추가로 소프트웨어 선택 가능
=> 소프트웨어 구성을 기록한 탬플릿이 됨 (루트 볼륨 탬플릿, C드라이브 같은 것)
- 같은 루트 내용(운영체제와 설치 패키지)를 계속 생산하기 위해
- Instance Type : 사양, 여기에 뭘 올려 쓸거냐에 따라 달라짐 (CPU 몇개, 메모리는 얼마 등)
- 종류 : t2.nano, t2.micro, t2. small, t2.medium, ..등 (크기에 따라 단가 다름)
- EBS (Elastic Block Storage) : 스토리지(SSD, HHD), EC2가 사용하는 저장공간
- VPC (Virtual Private Cloud) : 서버가 EC2를 생성할 때 네트워크 기반으로 서버를 배포해야 함 그 때 필요
- 네트워크를 구성하는 기본 프레임으로 반드시 있어야 함
*나중에 더 자세히 할 것임)
인스턴스 생성
- AWS 로그인
- EC2 인스턴스 생성
EC2를 쳐
인스턴스 만들어죠
쨘 만들어
만든 인스턴스의 세부내용
EC2
AMI 인스턴스 유형
- 인스턴스 유형 선택
예시> t2.mciro
- t2 = 인스턴스 유형 (대략적인 용도)
--> t : family, 2 : generation 번호 높을 수록 최근의 CPU 기술을 갖고 있는 칩 셋의 하드웨어
- micro = 인스턴스 크기(CPU나 탑재 메모리의 용량 등의 성능), scale
- 인스턴스 요금 옵션
- 온디맨드
- 예약 : 장기 약정 할인
--> 1y, 3y 선택 가능
- 스팟 : AWS 내부적으로 유휴 컴퓨팅 자원들에 대해 입찰해서 가장 싸게 EC2를 사용할 수 있는 요금제
--> 단점 : 혹시 입찰가가 올라가면 종료됨
--> 비용에 관한 이슈가 많고 죽어도 상관 없는 때 사용 (클러스터로 사용할 때 등)
User Data
- EC2를 생성할 때 딱 한 번 실행하는 스크립트
- 리눅스 기반의 명령어들이 들어감
- 나중에 저기에 자동으로 실행할 것들 적어서 실행하게 할 수 있음
인스턴스 수명 주기
- pending : 대기중
- running : 실행중
- 이때부터 과금 됨
- OS의 상태를 변경하는 것이 EC2 인스턴스의 수명주기라고 이야기 하는 것
Amazon EC2 연결접근(1)
- SSH : 키페어 기반으로 암호 전송하는 것
- 키 페어에 관한 설정 필요
- 기본 22번 port
- Session Manager
- 결과적으로는 SSH처럼 remote login 함
- 근데 얘는 웹 브라우저로 실행
- 콘솔 안에서 Connect
Amazon VPC
- 온프레미스 환경에서도 네트워크 환경이 필요함 (소프트웨어적이거나 하드웨어적으로)
- 네트워크 환경이 잘 구성 되어 있어야만 서버 서비스를 클라이언트가 요청해서 쓸 때 서비스를 제대로 제공해 줄 수 있음
- 이를 위한 기본 틀이 VPC(Virtual Private Cloud) : 사설네트워크
- 온프레미스 환경에서도 사설 네트워크 많이 만듦
- Inbound와 Outbound 차단하기 위해
- AWS에서는 강제임
- 네트워크 보안이 형성된 환경 안에서 EC2를 만들자는 의미가 담겨 있음
- 서브넷 : VPC를 쪼개서 접근에 대한 제어 (Public한 노드들만 넣고, Private한 노드들만 넣고)
- 서브넷을 지정하지 않으면 전부 Private 네트워크임
- 인터넷 게이트웨이가 Public한 네트워크로 통신할 수 있도록 함
- 그 밖의 서브넷들은 기본적으로 Private이므로 Inbound, Outbound 차단으로 보안 유지
- CIDR형식 (Classless Inter-Domain Routing)
- /숫자 (예시 : 171.31.0.0/16 => /16)
- 밑에서 더 자세히 설명할게유
- VPC는 리전에서 만들고 서브넷은 AZ에서 만듦
CIDR
- IPv4는 32bits
- 얘네는 기본적으로 Classfull : A/B/C
- 앞자리에 따라 class 소속이 다름
- class별로 구성할 수 있는 노드의 개수가 달라짐
- Classless : 클래스를 무시하고 원하는 Flexible한 네트워크를 만드는 것을 의미
- 이것이 CIDR
--> /숫자 : 32bits 중에 숫자만큼을 네트워크 범위로 표시하는 것
- 내가 만드는 VPC, 서브넷에 노드들을 몇 개 구성할 것인지에 따라 /bits 둘 수 있음
- 주소가 10.10.1.0/24이라면, 10.10.1의 부분은 네트워크 주소, 마지막 0,1,2,3,255는 예약되어져 있음
- 0은 네트워크주소 1은 라우터주소(게이트웨이 주소) 2는 네임 서버 주소
- 3은 향후를 위해 예약해 둔 것 255는 브로드캐스트
- 나머지 4~254까지 총 251개의 노드들이 실제적으로 구성할 수 있는 주소임
- /28일 경우 전체 16개의 노드 구성가능한데 여기도 5개의 예약된 것이 있으니까 11개만 구성할 수 있는 것
- 여기서 중요!!
서브넷을 구성하는 데 성실한 사람이라 계산을 함
여기에 열 개 정도의 노드 구성할 것 같아 그래서 계산해보니까 /28로 하게 되면 11개까지니까 충분해! 라고 하면서 서브넷을 배포할 때 /28로 줄 수 있겠지만 권장하지 않음
왜냐면 나중에 부족해질 때 IP를 할당할 수 없어짐
그럼 주소를 변경해야겠따!라고 생각할 수 있겠지만 안됨
한 번 생성한 서브넷은 그 이후에 CIDR 주소를 변경할 수 없음
그럼 이렇게 되면 어떻게 해야할까?
다른 서브넷을 새로 만들어야하는것이야
거기로 노드들을 옮겨..
어떻게 옮길까? AMI 복제 해가지고 만들어야 함 => 어렵지 않지만 번거롭다
넉넉하게 구성해라! -> 권장
얼마가 넉넉할까? AWS 권장은 /24이상!
라우팅 테이블
- 패킷을 전달하는 경로를 설정하는 이정표 역할
- 우리가 온프레미스 환경에서 라우팅 테이블의 기능은 패킷 전달 시 경로 설정하는 것 (aka 네비게이션)
- 디폴트 게이트웨이 : 외부로 연결하는 다리
- AWS 환경에서도 라우팅 테이블을 만들어서 경로 설정에 따라 패킷을 전달함
- AWS에 퍼블릭 네트워크 통신 하고 싶으면 인터넷 게이트웨이 생성해서 사용할 수 있는데 인터넷 게이트웨이를 사용할 수 있도록 경로 설정을 하는 라우팅 테이블을 만들어야 함
- AWS에서는 이 라우팅 테이블을 노출 시켜야하는 노드가 있는 서브넷에 연결해서 사용
- 서브넷에 연결하는 개념은 서브넷 안에 있는 EC2들은 연결되어있는 라우터에 다 적용이 되어짐
- 라우팅 테이블의 내용을 보고 인터넷게이트웨이를 거쳐서 밖으로 나가는 것 => 퍼블릭 서브넷
NAT 게이트웨이 (Network Address Translation Gateway)
- 나트 게이트웨이 내용 넣어줄 라우팅 테이블 만들어주면 연결되어있는 서브넷이 나트 거쳐서 밖으로 나갈 수 있게 해서 외부에서 패치나 업데이트 가능해짐
- 즉, Private 서버들에 있는 노드들이 NAT 거쳐서 업뎃 가능하게 함!
- 꼭 반드시 NAT 게이트웨이가 있어야 하는 것은 아님
- 그러나 온프레미스에서 업뎃을 위해 많이 쓰는 것처럼 AWS에서도 쓴다는 것
- 인터넷 게이트웨이의 존재 여부에 따라 Public 서브넷과 Private 서브넷이 결정되는 것
- 어떤 VPC안에 어떤 서브넷 안에 EC2를 생성해야지 해서 배포하는 것인데 EC2 노드를 배포할 때 어디에 배포 하는 것이 좋은 것일까?
- 굳이 불필요한 노출 필요 없으므로 되도록 Private 안에 두는 것이 좋음
Security Group과 NACL
- 보안그룹 : 인스턴스 레벨의 가상 방화벽
- EC2가 웹서비스를 제공할 때 80, 443 port 사용할 때 이걸 허락을 해야하는데 허락해 주는 것이 보안그룹임
- 아무리 잘 연결되어 있다해도 보안그룹에서 허락해주지 않으면 못 함 (가상 방화벽)
- 특정 주소 대역폭 쓸 수 있음
- 기본값 : 인바운드 모두 허락하지 않음, 아웃바운드 모두 허락
- NACL : subnet 단위의 가상 방화벽
- Rule number는 작을수록 매칭 우선 순위가 높음 마지막에 매칭이 안되면 * 표시됨
- 기본값 : 인바운드, 아웃바운드 모두 허락
Amazon EC2 연결접근(2)
- 서브넷에 있는 노드들은 연결되어있는 라우터들의 영향을 받아서 퍼블릭한 환경의 EC2들을 배포할수 있다고 했는데 그럴라면 EC2가 Public한 IP를 가져야 함
- Public IP 갖는 방법
- Dynamic : 자동 공인 IP 할당에 체크하면 Dynamic IP가 할당됨
--> 이것은 바뀔 수 있다는 것을 의미
--> 오늘은 100.100.100.100이었는데 내일은 200.200.200.200이 될 수 있다는 것
- Static : 바뀌지 않는 공인 IP 갖는 것
--> AWS 서비스 중 EIP를 사용하면 됨
--> 이것은 Elastic IP로 고정의 IP를 만들어 줌 오늘도 내일도 100.100.100.100이 되는 것
- 이제 여기에 SG에 허락해두면 노출이 완료되는 것
실습
VPC-Subnet-IGW-NATGW-RoutingTable 생성 및 연결
1. VPC 생성
- 하나씩 해보기 위해 VPC만으로 설정
- 이름 설정
- IPv4 CIDR 할당 : 10.0.0.0/16
2. 서브넷 생성
- 생성한 VPC에 연결
- Public Subnet 설정
- 이름, 가용영역, 서브넷 CIDR 설정
- Private Subnet 설정
- 마찬가지로 이름, 가용영역, 서브넷 CIDR 설정
- 두번째 Public Subnet 생성
- 가용영역을 다른 곳에 생성
- 두번째 Private Subnet 생성
3. Internet Gateway 생성
- My IGW라는 게이트웨이 생성
- MyVPC에 연결 => Attached
4. NAT Gateway 생성
- Public Subnet에 연결
- EIP 할당
5. Routing Table 생성
- Public Routing Table 생성
- MyVPC 할당
- 생성한 라우팅테이블 편집
- 10.0.0.0/16으로 대상 설정 및 인터넷게이트웨이 (아까 생성한 것) 대상 설정
- 두 개의 Public Subnet 연결
- Private Route Table 설정
- 0.0.0.0/0 설정 및 NAT 게이트웨이 설정
- 두 개의 Private Subnet 연결
6. 리소스 맵 확인
NATGW 삭제 후 EIP 삭제 (릴리스)
- NATGW 들어가서 MyNATGW 삭제
- 완전히 삭제된 후 EIP 가서 릴리스
EC2 배포 : WebServer 연결 확인
1. 네트워크 설정
- MyVPC 연결
- MyPubSubnet에 할당
- 퍼블릭 IP 자동 할당
- 보안 그룹 생성 > SGWeb
2. 보안그룹 규칙 설정
- HTTP와 HTTPS 두 개 설정, 둘 다 위치무관 설정
3. UserData 설정
4. 연결 확인
폰으로 확인함 ㅎ
- 잘 접속되는 것 확인 가능
EC2 AMI 생성 후 EC2 삭제
- EC2에서 이미지 생성 클릭
- AMI로 들어가 보면 생성되어있는 것 확인 가능
- EC2 인스턴스 종료
- 새 인스턴스 만들려고 들어가서 보니 AMI 잘 생성된 것 확인 가능
실습 부가 설명
AWS 네트워크 구성
- 권장하는 네트워크 구성
1. 기본 VPC 삭제
2. 주어진 리전에서 VPC,SUbnet(2개의 AZ에 퍼블릭 서브넷, 프라이비 섯브넷 하나씩 생성)
3. IGW 생성해서 VPC 연결 -> 라우팅 테이블 생성 -> 연결 (퍼블릿 서브넷에)
4. NAT gateway Public 서브넷에 만들고, 라우팅 테이블 생성해서 프라이빗 서브넷에 연결
5. NAT, EIP 삭제 (고정 공인 IP 갖고 있어야 외부에 Private 노드가 요청하는 업뎃이나 패치에 대해 갖다줘야하기 때문에 NAT gateway가 EIP를 갖고 있어야 함)
- AZ 중복 배포 해두는 이유 => 고가용성 : 중단시간의 최소화
- AZ 여러 곳에 EC2를 나눠두는 것을 권장함
- AZ 한 쪽이 문제가 생겨도 다른 곳에서 정상 작동할 수 있도록 하기 위해
VPC
- VPC 생성 > VPC등은 Wizard임 오늘은 VPC만 선택 (하나하나 다 해보기 위해)
- 리전 안에 VPC 만들기
- 라우팅 보면 10.0.0.0/16은 내가 직접 연결할 것이라는 의미
- 0.0.0.0 의 의미는 default의 의미를 갖고 있음
- NAT GW 에 할당한 EIP가 EIP 탭에 가 보면 생성된 것을 볼 수 있음
웹서버 인스턴스 생성 및 연결
- i-08bc6eea3c5455cae 리소스 아이디
- EC2 만들어진 결과물을 리소스라고 얘기하고 리소스를 구분하는 유니크한 ID
- 연결이 안될 때 뭐부터 확인해야할까?
- 보안그룹 확인하기
- 공인 IP 할당돼 있는 지
- 퍼블릭 서브넷에 있는지(연결돤 라우팅테이블에 IGW가 있는지)
*AMI : EC2 만든 것에 이미지 생성해서 만듬
ENI&EIP
- ENI(Elastic Network Interface) : VPC에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소
- EC2 연결 가능
- IP 주소, MAC 주소 부여 가능
- EIP 연결 가능
- 보안 그룹 부여 가능
--> 네트워크가 많아지면 네트워크별로 SG 설정
--> 서버의 안정적인 운영 측면에서는 바람직하지 않기 때문에 잘 안 씀
=> 애플리케이션이 보안관련된 것을 추가할 때 전용으로 네트워크 요구하는 경우 있음
=> 그 때 EC2에 추가적인 네트워크 환경을 만들어서 사용할 수 있도록 한 것
- EIP(Elastic IP) : 고정적인 IP
- EC2나 ENI 연결
EC2 마무리
SSH 설정
- 암호화 통신을 위한 설정
- 인스턴스 생성
- 키 페어 생성 (리눅스 기반 client: .pem, 윈도우즈기반 putty client: .ppk)
- 네트워크 설정 VPC -public network
- 퍼블릭 IP 활성화
- 보안그룹 생성 (ssh 허락 - 22번 포트)
- Git Bash 이용
SSH 실습
- EC2 생성
- TestServer로 설정
- 키페어 생성
- 네트워크 설정
- 여기서 Public Subnet에 해야하는데 실수로 Private에 해서 다시 만듦 ㅎㅎ
- 보안 그룹 생성 (22번 Port 허용)
- 만들어진 것 확인
2. 인스턴스 Git Bash에서 연결
- 순서대로 하면 됨
- 짜잔 Bash 연결 화면임
- 웹페이지로도 연결 가능
EBS (Elastic Block Store)
- EC2의 OS 레벨에서 접근해야 함
- 파일 시스템 안에 있는 폴더들 같은 스토리지 공간의 역할을 제공하는 것 (C드라이브, D드라이브)
- EC2에 종속적임 (EC2가 사용하는 디스크 역할)
- 우리 EC2 만들 때 보면 스토리지 얼마 만들거냐 할 때 그것도 EBS임
- EBS를 추가 생성해서 사용하겠다 하면 두 가지 유형이 있음 =>HDD, SDD
- 당연히 SSD가 더 좋음 (IOPS 기반 / IO per seconds : 성능 )
- 저렴하게 많은 양의 데이터 저장의 의미가 있으면 HDD (Mb/s)
- 우리 온프레미스 환경에서도 서버의 데이터를 백업하듯이 AWS 에서도 서버에 저장되어 있는 볼륨 데이터 (EBS 데이터)를 백업할 필요가 있는데 백업하는 방법이 스냅샷
- 스냅샷 : 나중에 복원할 때 특정 시점에의 것을 복원할 수 있도록 지원하는 것
- EBS 볼륨 유형 : https://aws.amazon.com/ko/ebs/volume-types/
- SSD에서 주로 사용하는 것은 gp2나 gp3 많이 씀
EBS 실습
- EBS 생성
- 먼저 기존 EC2에 연결되어있는 EBS 확인해 보면 기본으로 8GB 들어있는 것 볼 수 있음
- 이렇게 볼륨으로 들어가서
- 볼륨 설정 후 생성
- 이렇게 사용가능한 상태라고 뜨면서 아직 어딘가에 연결되지는 않은 상태
2. 볼륨 연결
- 만든 인스턴스에 연결하고 디바이스 이름 설정
- 이렇게 연결된 것 확인 가능
- 이렇게 확인이 가능함
3. EBS 삭제
- 먼저 EC2 중지
- 볼륨 분리 및 삭제
- EC2 종료!
추가적으로 종료 후 비용 들 수 있는 것 체크
- 추가적으로 연결한 EBS
- EIP
- Snapshot
- AMI (사용안 할 예정인)
IAM 기본
AWS IAM과 접근 권한
- AWS의 사용법과 계정
- root 사용자 : AWS 계정 생성 email / 무한 권한
- 내가 계정을 만든 관리자라고 해도 직접 root 권한 계정으로 접근하는 것은 권장하지 않음
- root 내 사용자 계정으로 접근하는 것 권장
- IAM : 인증 및 권한 제어
- User, Group, Policy
--> User들을 하나의 Group안에 포함시켜서 Policy를 Group에 부여할 수도 있는 것
--> 그럼 Group에 부여된 정책은 그룹 내 유저들 모두에게 적용됨
- MFA(Multi-Factor Authentication) : 암호외의 인증ㅊ
AWS IAM 정책
- IAM 정책
- json format
- Effect : 허용, 거부 (Allow, Deny)
- Action : 서비스 특정 작업
- Resource : 리소스 이름 (* 의미: 모든)
- Condition: 조건절
--> 내용이 모두 참일 경우, 수행 => 세밀한 작업수행 가능
- 정책 우선 순위
- 1순위 명시적 Deny (Effect: Deny)
- 2순위 명시적 Allow
- 암시적 Deny
- 명시적 Allow만 안하면 어차피 Deny인데 명시적 Deny를 해야할까?
- 생각지못하게 여러 정책이 하나의 유저에게 적용
--> Deny될거라고 생각했는데 어딘가 명시적 Allow 되어져 있음
--> 충돌 발생 => 미연에 방지하기 위함
- 어디서 정책 충돌나도 아예 안된다고 미리 대비!
Sample Json Formats
IAM 실습
*주의! 미리 만들어져 있는 유저와 정책은 지우지 않는다!!
- IAM User 생성
- 이름 입력
- 비밀번호 입력
- 그룹에 넣지 않기
- 생성
2. 새 유저로 로그인
- 로그인
- EC2 안되는 것 확인 가능
- S3 에러 확인 가능
3. S3 권한 허용
- 권한 추가
- 버킷 생성 확인 가능!
4. 생성했던 유저 지우기
S3 기본
S3 개요
- 객체기반(파일 단위 IO) 클라우드 스토리지 서비스
- 데이터 저장 및 관리
- 버킷: 파일을 담는 그릇
- 파일을 S3 bucket에 저장 가능
- 기능
- 여기에 여러 파일 업로드 및 다운로드 가능
- 웹 기반 스토리지와 유사
- 버킷을 생성하면, 버킷을 접근할 수 있는 url이 만들어짐 → url 기반으로 파일 접근 가능
- 사이즈 제한이 없음
- 접근 방법
- 허락이 되어져 있어야 하고
- 관리 콘솔 및 각종 도구 사용
S3 특징
- 복사본을 여기저기 흩뿌려 놓음 => 가용성이 높음
- 데이터의 높은 내구성
- 확장성 : 사이즈 제한 없음
- EC2와 마찬가지로 확장과 축소가 쉬움
- 가용성 및 내구성 : 99.99999999%의 내구성(1000년에 한 번 일어날까 말까한 데이터 손실을 의미)
- 내구성이란 데이터의 손실 최소화하는 것
- 내부적으로 보면 복사본을 여기저기 흩뿌려 두고 어디에서 문제가 생겨도 복사본을 통해 데이터에 접근할 수 있도록 해둔 것
- 얼마나 많은 개수의 복사본을 얼마나 많은 곳에 흩뿌려뒀는 지 확인하는 것이 내구성의 Factor
- 신뢰성 : 접근 관리 도구와 각종 규정 수준
- 다양한 관리 기능 : 스토리지 클래스 분석과 리전 간 복제
- 스마트한 기능 : S3 Select, 다른 서비스와 연동
- 버킷 생성 시, Region 선택
- region 내부에 스토리지
- 버킷 이름 unique해야함
- url 형식으로 접근하기 위해 world-wide함
--> 중복되면 안됨
- S3 데이터 보호 및 가용성
- 암호화 기능 지원
- S3 정적 웹사이트 호스팅 기능
- EC2를 만들지 않고 S3만 가지고도 웹서버의 역할 제공
- 권한이 있는 url을 기반으로 웹 서버 기능 제공
- 권한 - public, index, html 업로드
- 버전 관리 활성화 기능
- 기본: 비활성화
- “파일의 무결성” 보장 - 파일 손실 막음
- 실수로 객체 파일 삭제 → 원래대로 roll back
실습 - 퍼블릭 권한으로 객체 접근
(사실 좀 올드한 방법 요즘은 json format 정책 이용함)
- 버킷 생성
- 객체 삽입 확인
- 기능 확인 가능
- url 접근 거부된 것 확인 가능
- 현재는 ACL 활용 못하게 해 둠
- 퍼블릭 엑세스 차단을 비활성화 해 줘야 함
- 이후 ACL 활성화 가능해짐
- 퍼블릭 권한 주게 되면
- url로 객체 접근 가능!
버킷 정책과 사용자 정책
- AWS 서비스 접근 제어 방법
- 사용자 중심 기반 (IAM 정책, 모든 서비스에 대해) : IAM 정책
- 리소스 중심 기반 : 리소스 정책 (S3, Glacier-좀 더 싼 백업서비스 스토리지, SQS, KMS-키 관리 서비스,...)
--> 리소스 직접 찍고 들어가서 접근 제어 부여
- S3는 둘다 되는 거임 → IAM, 버킷 정책
S3 버전관리
- 버전관리 활성화 기능
- 기본저긍로 활성화가 안되어 있음
- 원하면 활성화 직접 해야함
- 버전관리라고 하는 것은 파일의 무결성을 보장하는 것
- 버전관리를 활성하하면 고객이 실수로 객체파일을 삭제한 경우 원래대로 돌릴 수 있음
- 그래서 버전관리 활성화가 되면 삭제된 것이 완전 삭제된 것이 아님
S3 웹사이트 호스팅
- 정적 웹사이트 호스팅
- 정적 데이터 : 이미지, 동영상
- 동적 데이터 : 검색할 때마다 다른 결과가 나오는 데이터
- 파일 서버로 사용가능
- 웹 서버로 사용 가능
실습 - 정적 웹사이트 호스팅 & 버전관리
- 콘솔 > S3 > 버킷생성
- 버킷이름 유일하게
- 버킷 생성 후 파일 업로드 => index.html
- 속성 > 정적 웹사이트 호스팅 활성화
- 이렇게 편집하면 됨
- 활성화된 것 확인 가능
- 웹페이지 로드해보니까 거절됨!
- S3 퍼블릭 권한 갖게 하기 위해 활성화 된것을
- 이렇게 체크 해제해서
- 비활성화하기
- 이후 버킷 정책 편집
- 정책 편집기를 활용한다
- 그럼 이렇게 json format 보여줌
- 이렇게 붙이면 됨
- 코드내용
- 짠 내용이 이제 보임
2. 버전관리 활성화
- 속성 > 버전관리
- 활성화
- 객체 삭제
- 404 NOT FOUND로 바뀐 것 볼 수 있음
- 객체 내 버전 표시 활성화하면 삭제마커가 보임
- 이거를 삭제하면
- 짠! 다시 보임
3. 마무리
- 객체 및 버킷 삭제!
S3 데이터 보호 및 가용성
- 암호화 저장 지원
- 암호화의 대상은 객체 (파일)
- 잠금기능
- 무결성과 관련 있음
- 삭제도 못하고 변조도 못 함
--> 아예 처음부터 lock 걸어두는 것
S3 비용
- S3 요금 = 저장용량 + 전송량 + Operation 비용
- 저장용량 : 데이터를 저장한 양에 따라 과금됨
- 전송량 : 데이터를 주고받은 전송량에 따라 과금됨
- 파일을 업로드할 때 저장하는데 이 때는 비용이 안들어감
- 다운로드의 경우, 같은 리전에서 하면 비용이 안들어감
- 다른 리전에서 다운로드 할 경우 비용 발생!! (Transfer 비용)
- Operation 비용 : 작업하는 개수에 비례해 비용 과금
스토리지 클래스 및 수명주기
- S3 수명주기 : S3는 클래스가 있는데 사용목적에 따라 선택 가능
- 클래스 : 기본값은 Standard 클래스
- S3를 비용효율적으로 쓸 수 있게 함
- S3 비용에 민감할 경우, 클래스에 따라 단가 다르므로 환경에 맞춰 효율적 클래스 선택 가능
- S3 기본 요금에 스토리지, 전송량, opration있었는데 Standard보다 IA(Infrequent Access)로 쓰는 것이 스토리지 비용은 더 저렴함
- 대신 opration 비용이 standard보다 더 비쌈
- 따라서 간헐적 Access의 경우 opration이 적게 일어나므로 standard보다 스토리지 비용 적은 것 사용이 효율적일 수 있음
- Glacier : 장기 백업 스토리지
- S3에 비해 비용이 굉장히 저렴하지만 복원 시간이 오래 걸림
- 옵션을 걸어 돈을 좀 더 내고 빠르게 복원 가능 반대로 덜 내고 느리게도 가능
- 클래스 변경 : 클래스 변경을 통해 비용효율적 S3 사용
- IT 클래스 (Intelligent-Tiering)
- 알아서 비용저렴하게 클래스를 옮겨주는 것
- 이걸 사용하면 추가적인 분석 비용이 들어감
S3 복제
- 복제의 의미 : 다른 리전의 버킷에 객체를 복사하는 것
- Region Fail에 대비하는 것
- 리전에 문제가 생겼을 때, 다른 리전의 데이터를 참조할 수 있도록 하는 것
- S3는 내구성 설계를 하기 때문에 리전 안에 여러 데이터 센터에 S3 객체 파일 복사본 여기저기에 둠
--> 고객 입장에서 장애를 느끼지 못하도록 서비스 설계
- 그러나 이 내구성 설계는 리전 안에서 일어나는 것 따라서 리전의 장애에 대한 대비 필요
--> 그 때 사용함 그러나 비용이 증가하기 때문에 디폴트 값이 아님
- 서비스 레벨(범위)의 의미 : S3리전레벨의 서비스, EC2와 EBS는 가용영역 레벨의 서비스
- 리전 레벨의 서비스는 리전까지만 선택하고 그 안의 가용영역을 선택하지 않음
--> 서비스 범위 안에서 내구성 설계를 한다는 의미
데이터분석 서비스와 연계
- S3 활용 : 데이터 저장소로 사용
- Redshift, Athena: 빅데이터 분석도구
- S3 Select : 데이터 파일 하나에 SQL문을 사용하여 집계 및 검색 가능한 기능
EC2(기타 서비스)
Tagging
- Tag : 여러 EC2를 만든 것 중에서 각각을 구분하기 위한 이름표같은 것
- 꼭 태그를 달지 않아도 내용을 보며 추측가능하지만 태그만보며 구분할 수 있도록 함
- 예시 : Name = Webserver1, Team = Prod1
--> 직관적으로 구분하기 좋음
- 태그 다는 것을 권장
- 장점
- 관리 편의 : Tag별 리소스 쿼리 가능 / Tag별 권한 제어 가능(Condition절 안에) / 리소스 그룹 지정
- 비용 관리 용이 : 태그별로 비용에 관한 모니터링 할 수 있는 설정 존재
- 태그 편집기 활용
ELB (Elastic Load Balancing)
- ELB 기능 : 클라이언트 요청 트래픽들을 여러 대상자들에게 자동 분산
- Healthy Check : 상태확인
- 뒷단에 있는 노드들에 관해 정상적으로 운영이 되고 있는 지 체크하는 것
- 문제가 있다고 생각되면 그 노드에 서비스 요청하지 않음
- 정상적으로 작동되고 있다고 생각되는 노드에만 서비스 요청함
- HTTPS 지원
- 애플리케이션 자동크기 조정 지원 : Auto Scaling Group이 하는 것이지만 ELB와 세트처럼 많이 사용
- 서버 뒷단에 있는 서버 노드들의 크기 조정 지원
ELB 종류
- ALB : Application Load Balancer
- L7의 애플리케이션 컨텐츠 기반 로드 분산
- HTTP, HTTPS 기반
- NLB : Network Load Balancer
- L4의 IP, Port 기반 로드 분산
- TCP, UDP 기반
- ELB 생성할 때 계획에서 어떤 기준으로 Load Balancing 해야하느냐에 따라 ALB와 NLB 생성 가능
Auto Scaling
- Auto Scaling의 필요 : 수요 요청에 따른 분석
- 기존 온프레미스에서는 수요 피크를 커버할 수 있는 정도로 준비해둬야 함
- 그럼 다른 날에는 리소스를 놀리고 있게 됨 => 낭비
- Auto Scaling 이용 시 필요에 따라 자동으로 크리 조절 가능
- EC2 Auto Scaling
- 로드 처리를 위해 EC2의 개수 자동 조정 : 수요에 맞게 서버의 개수 늘리고 줄여주는 것
- 향상된 가용성과 비용절감이 장점임
Auto Sacling 요소
- ASG (Auto Scaling Group) : min, max, desired
- min : 가용성
- max : 비용관리의 의미가 큼
- 시작탬플릿 (Launch Template) 설정 : 인스턴스 구성 정보 지정
- AMI, 인스턴스 유형, 보안그룹, 키페어 등
Auto Scaling 정책
- 어느 시점에 EC2를 늘리고 줄일 것인 지 정의함
- 수동
- 자동 : 예약된 일정, 초기값 유지, 동적 조정정책 ( 단순 조정정책, 단계 조정정책, 대상 추적 조정정책)
- 동적 조정정책은 CloudWatch와 함께 하는 것
- 예시 : CPU 80% 이상되면 2개 늘려, 60% 되면 1개 늘려, 40%되면 1개 줄여, 20% 2개 줄여
- 초기값 유지 : min/max/desired = 2/2/2 로 하는 것
--> 의미는 반드시 두개는 가용성 갖고 있어야 한다는 것
- 예측기반
AWS 사용을 위한 도구
IAM과 접근 권한
- 세 가지 방법
- console : username/password
- CLI/SDK : Access Key ID / Secret Access Key
CLI 실습
- IAM > User > 계정생성
- 권한설정 > 직접 정책 연결
- S3 Full Access 부여
- 생성 확인
- 권한 확인
- 원래 유저 > 보안 자격증명 > 액세스 키 만들기
- CLI 만들기
- 이후 실습을 위해 복사
- CLI 설치 : https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html
- Bash 열기
- aws 접근
- 목록 확인
- 다운로드 받기
- 다운로드 확인 가능
- AK와 SK의 유저가 해당 작업에 대한 허락이 있어야 할 수 있는 것임!!!!
- 코드 보기
AWS IAM 역할
- 정책 부여
- 관리형 : 반복부여 (AWS/고객)
--> user 삭제되어도 정책은 안사라짐
- 인라인 : 일회성 (user 삭제 시 정책도 사라짐)
- 역할(Role) : 임시 권한 부여
- User의 임시 권한 필요 시
- 서비스가 서비스를 액세스 할 때 : 서비스에 직접적으로 정책부여가 불가능하므로!
- 연동 자격 증명 : AWS는 교차계정 Access 지원하지 않음
--> 회사는 계정 여러 개 있을 수 있음
--> 어떤 계정의 유저가 다른 계정의 무언가를 건드려야 할 때 사용!
- 역할에 부여하는 정책
- 권한정책 : IAM
- 신뢰정책 : 누구한테 위임(허락)할 것인 지
권한 부여 권장 가이드
- root 사용 지양 : root의 Access Key 및 Secret Key 발급하지 않기
- 최소권한 부여
- 관리형 정책 사용
- 미사용 user, role, 정책은 정기적 검토를 통해 제거
- 권한 위임 : role 사용
- MFA 설정
- 정책 검증 : 잉여의 권한 주고 있는 것은 아닌 지 확인 필요
Amazon CloudWatch
- CloudWatch 기능 : AWS 서비스들을 모니터링할 수 있는 서비스
- 주요 기능
- 지표 : 각 서비스들이 지표와 연결되어 모니터링 되는 것
--> 그래프 형태로 확인 가능
- 경보(알람) : 임계치가 되면 알람을 주라는 설정 가능
--> 예시 : 80% 이상이 3번이상 지속되면 알람 설정
- Logs / Event
Amazon CloudTrail
- CloudTrail : AWS 모든 이벤트 로그 수집 서비스
- Who / When / What
- 예시 로그
AWS Billing and Cost Management
- 비용관리 도구
- 청구서 : 사용한 요금 청구서
- Cost Explorer : 시각적으로 보여줌
- Budgets : 예산 걸어두고 특정 퍼센티지에 도달하면 알람이 옴
- 비용활용 보고서 : 사용하는 리소스들에 대해 디테일한 비용의 내용 확인 도와주는 것
'SK 쉴더스 루키즈' 카테고리의 다른 글
| 클라우드기반 시스템 운영/구축 실무 (0) | 2024.08.10 |
|---|---|
| 클라우드 보안(2) (0) | 2024.08.10 |
| 애플리케이션 보안 (0) | 2024.08.10 |
| 네트워크 보안 (0) | 2024.08.09 |
| 시스템보안 (0) | 2024.08.09 |
