자동화
API 호출? = 규약
코딩을 잘 모른다? -> Amazon CodeWhisperer로 사용하면 된다.
한번 작업 후 고치면 템플릿을 통해 배포만 하면 된다.
cloud formation = template
여러명이 할 업무를 한 사람이 할 수도 있는 것....
AWS CDK :
AWS CDK는일반적인프로그래밍 언어를사용하여애플리케이션리소스를모델링및프로비저닝할수있는 오픈소스소프트웨어개발프레임워크입니다. AWS CDK를사용하면 CloudFormation 템플릿을간편하게생성및배포할수있습니다. AWS CDK는 모범사례에따라미리구성된구성요소그룹과인프라구성요소를 제공합니다. 하지만구성요소와해당설정은사용자지정할수있습니다.
(가게에서 카드등록을 하고 물건만 가지고 나와도 자동 결제되는 시스템)
컨테이너
(기본적으로 마이크로 서비스를 이해해야 함)
웹서버가 하나 없어지면 애플리케이션 서버도 변화가 있어야 겠지.
아주작은 변화에도 여러사람이 변화를 느껴야 함 (안티패턴)
-> 이런 것을 로드밸런서를 통해 해결을 함.
사용자가 토픽에 무언가를 요청하면 토픽에서 사용자 메소드를 코래야함.
메소드를 콜하면 부르긴 좋은데 사용자만 불러도 배포가 일어남.
어플리케잇ㄴ 일부만 변경하고 싶은데 자료가 deploy가 되는 것.
사용자가 실수하면 내 소스가 오류가 생길 수 있음
-> 이걸 분리시켜서 각각의 서비를 (유저는 유저 메시지는 메시지 토픽은 토픽으로만)
직접적인 연결관계가 없어서 좋은점?
각 각의 팀이 API를 통해서만 사용.
이렇게 사용하면 좋은데 이렇게 하기가 어렵다.
예를들어, 베어메탈서버라고 하면.
앱1, 앱2는 python 3.11을 사용하는데
앱3에서 python 3.14를 사용했다면 앱1,2는 앱 작동불가능.....
가상머신으로 각 각의 앱을 분리시키면 그런 일을 방지할 수 있다!!
-> 효율이 아주 극강으로 올라가는 장점이 생긴다. (매우 빠름)
컨테이너 사용하기 때문에 머리아픈 거?
서버에 컨테이너 띄우니까 라이브러리 각자 가지고 있고 오염도 안되어 좋으나.
컨테이너에 대한 모니터링도 필요하다.
: 컨테이너 하나 가지고 100명을 수용한다? 하지만 300명이 들어온다면 컨테이너 3개를 관리해야한다.
예를 들어, 이벤트가 있다면 컨테이너를 늘이고 줄이고 오케스트레이션을 해야한다.
컨테이너 오케스트레이션 도구
-> 쿠버네티스
코드 저장 : git
컨테이너 이미지 저장 : docker hub / Amazon ECR(Elastic Container Registry)
쿠버네티스 기능 : 1000개 정도
아마존 ECS 기능 : 100개 정도
둘 중 뭘 사용해야할까?
IT산업은 기본적으로 트렌디하다. 어느 영역에 쓸 것인지 생각하고 본인이 생각하고 선택하면 된다.
- 쿠버네티스의 경우, 3일 교육을 받아야 겨우 사용할 수 있을 정도로 조금 어렵다.
- ECS는 AWS 인프라 조금만 알면 바로 사용할 수 있다. (MLB 사이트도 ECS로 운영을 했다)
쿠버네티스는 기본적으로 컨트롤 플레인과 데이터플레인으로 구성됨.
컨트롤 플레인에서 데이터 플레인으로 데이터를 띄워야 하는데 각각의 파드가 가지고 있는 데이터베이스는 컨트롤 플레인에서 지워지면 같이 날아감.
보통 컨트롤 플레인 몇 개를 설치해서 사용해야 한다.
이 걸 해결하기 위해 나온 것이 바로 Amazon EKS임!
Fargate에 띄울지 / EC2에 띄울지 선택을 하면 됨
EC2는 내가 관리를 해야하니 파드를 띄우면 되겟네요?
EC2가 있는데 컨테이너가 9개가 있다고 생각해보자. 컨테이너 인스턴스를 모두 사용한다면 효율적으로 사용을 하는거지만 모두가 비워져있으면 아깝지.. 이런 애들은 fargate로 띄우는게 더 저렴하지.
(Fargate는 1.2배 정도 비용이 더 높지만 몇개만 띄울거라면 fargate가 낫지. fargate를 사용하면 인스턴스에 대한 관리 스트레스가 없다.)
네트워킹2
DynamoDB는 리전 수준의 리소스.
3개의 가용영역 사용 중이지만 우리 vPC에는없다.
그럼 내가 DynamoDB와 통신하려면 내가 퍼블릭 서브넷에 NAT를 달아야 하는 것이다.
보안상 안좋다.
outbound 비용이 나온다.
집에 에어컨을 단다고 생각해보자. 문을 열고 틀지는 않으니까.
문 닫고 구멍만 뚫고 에어컨을 사용하잖아? 이걸 VPC 엔드포인트라고 생각해.
고가용성!!
최근에 S3는 인터페이스 엔터페이스에도 제공해주고 있음.
둘 사이 통신을 하려면 VPC 피어링을 이용하면 private하게 연결이 가능함
리전/계정이 달라도 통신이가능함!
RFC1918 규약을 지켜서 하면 됨
가산 KINX 데이터센터
평촌 LGU+ 메가센터
상암 ICN10
다이렉트는 말 그대로 선임!
누가 끊으면 통신이 안되기 대문에 SLA를 지원하지 않는다. (수치를 얘기하지 않아서 내가 알아서 관리해야함)
*관리?
- 망을 이중화 해야함 (하나는 다이렉트 커넥트로 연결하고 다른 하나는 VPN으로 연결)
한번만 연결하면 모두와 연결이 된다는 장점!
프라이빗 IP 통신 가능~~
해외지사들은 이렇게 관리할 수 있는거지.
사용방법
1. 리전만들기
2. VPC 붙인다.
3. 서브넷에 붙어있는 라우팅테이블에 연결
라우팅테이블 분리하면 필요한 부분만 부분연결도 가능하다
서버리스
하드웨어에 주인인 나도 접근을 하지 못하니 당연히 외부인도 접근이 불가능하여 보안이 보장!
API는 기본적으로 URL이 생성됨
저장 X . 한번 뿌리면 끝
필요시 FIFO로 보낼 수 있다.
엣지서비스
'AWS' 카테고리의 다른 글
| Public Cloud Solution_AWS1 (0) | 2024.01.05 |
|---|---|
| 클라우드 기술 핵심 학습 목표 (0) | 2024.01.02 |
| AWS_실습4 Amazon VPC에서 고가용성 구성 (0) | 2023.12.28 |
| AWS_실습3 Amazon VPC 인프라에 데이터베이스 계층 생성 (0) | 2023.12.27 |
| 231227 AWS (0) | 2023.12.27 |
