생각보다 OPA에 대해서 들어본 사람이 없는 것 같다. 

특히 국내에서는 확산이 많이 안된거 같지만, 해외 벤더사들은 많이 사용하고있다... 

클라우드, 쿠버네티스, MSA, 메타버스, 블록체인 등등 IT기술이 정말 엄청많이 바뀌고 있다는게 엄청 많이 느껴지고, 이제 레거시만 고집한다면 점점 도태될거란 생각이 많이든다. 

OPA를 찾아보면 소개글이나 동작방식 등에 대해서는 정말 많이 나와있지만, 

실제로 OPA코드를 짜다보면 내가 원하는 정보는 많이 없는 것 같다.. 커뮤니티에서 고수들의 대화에 낄 정도는 아니고.. 그냥 소소하게 코드를 짜보고 있다. 

설명이 너무 장황하게 길고 그러면 이해하기 힘드니까 간략하게 OPA가 뭐냐고 물어본다면 일반적으로 general-purpose policy engine이라고 하면서 범용 정책 엔진이라고 이야기를 한다. 

그런데 범용 정책엔진이 무엇이냐고 물어보면, CNCF의 졸업프로젝트 이야기부터 써둔 글들이 많다. 

근데.. 거의 https://www.openpolicyagent.org/docs/latest/ 공식사이트에 있는 글을 그대로 쓴게 많아서 처음 배우는 사람한테는 진입장벽이 높겠다? 라는 생각이든다. 

간략하게 말하면 다양한 클라우드 네이티브 영역 전반에 걸쳐서 정책, 인증을 코드로 관리를 하여 보안, 운영, 자동화를 할 수 있다.

사실 내용을 줄여서 정리를 할려고해도, 줄이기 어렵고, 쉽게 쓰기는 어려운것 같다. 

쉽게 얘기하자면, AWS의 보안정책과 GCP의 보안정책을 OPA로 한방에 관리를 할 수 있다. 

더 나아가서, 쿠버네티스,  CICD, Servicemesh 등을 보안정책을 모두 다 OPA로 관리할 수 있다. 

그게 어떻게 가능하냐면 

OPA는 Policy enforcement와 policy decision-making을 decoupling 하기 때문이다. 

이게 뭔소리냐면

Policy decision-making(정책 의사결정)은 조건을 만족하냐? > 이런 개념이고

Policy enforcement(정책 시행)은 말그대로 시행하는 개념이다. 

이걸 분리한다는것은

관리자 권한이 있는 사람만 사용자 리스트를 볼 수 있습니다. 

여기에서 관리자 권한이 있는 사람인지 판단은 OPA로 하고, 

사용자리스트를 보는건 구현해둔 코드, 서비스가 실행을 하는 개념이다. 

관리자권한이 있는 사람인지아닌지 판단은 True / False로 하듯. OPA는 단순히 True / False로 판단만 한다. 

 

OPA를 사용하면 퍼포먼스차이가 많이 나냐? 라고 하면 많이 난다고 말할 수 있지만, 

구체적인 수치를 가져오라고하면.. 그건 딱히 비교를 해 보지도 않았고, 그정도까지 서비스 개발은 안해봤다... 

OPA의 Input에는 3가지 종류가 있다. 

1. Query Input : OPA가 결정해야하는 질의 (관리자 권한이 있음?)

2. Policy : 정의된 decision Making 실행 (사용자 리스트 봐라!)

3. Data : Decision Making을 위해 필요시 참조할 데이터 (관리자 권한 부여된 리스트)

https://www.openpolicyagent.org/docs/latest/philosophy/


나름.. 쉽게 정리한다고 했지만 이해가 잘 안되는 부분이 많을것 같단 생각은 든다. 

원래 이런 기술?들을 직접 해보면서 깨닫고 다시 한번 보는게 더 좋을 것 같다. 

OPA 엔진을 띄워놓고 Data/Policy를 적용하는 방법도 5가지가있다. 

그런데 너무 어려우니 일단 차근차근 hellow world 찍어보고, 어느정도 이해가 되면 조금 더 이론을 보면 쉽게 이해할 것 같다. 

반응형

 


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


 

오토스케일링 : 자동으로 크기가 늘었다 줄었다 하는 그런 기능이 가능합니다. 

이건 뭐.. 클라우드의 장점 이야기할 때 항상하는 이야기인걸로 압니다. 

 

트래픽이 많을 경우에는 EC2가 늘어나고, 트래픽이 적을때는 EC2가 줄어들고, 

상황에 따라서 조절이 가능해야합니다. >> 클라우드의 장점 스케일업 스케일 다운

 

예를 들어 CPU 사용량이 50%가 넘으면 스케일업 하겠다. 이런식으로 기준에 정해서 설정하면됩니다. 

CPU든 GPU든


오토스케일링 설정 프로세스

1. 서버 셋팅

2. 이미지 생성

3. 시작 템플릿 생성
   > 이미지와 조금 다른데, 이미지는 서버의 환경을 그대로 캡쳐를 해놓은거고, 소스코드, 프로그램, 파일 등.. 똑같이. 
      시작 템플릿은 T2 마이크로할건지 키페어는 뭘로 할거고 보안그룹 등 다양한 환경,,,, AWS에서 관장하는 그런 환경        을 그대로 정하는게 시작템플릿!

4. 대상 그룹 생성

  > 디폴드 값 설정 ALB안에 들어갈 인스턴스수 정하는것.. 

5. ALB 생성

6. Auto Scaling 그룹 생성 

 

 

 

 

 

 

 

 


 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

반응형

 

 


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


 

 

앞서서 개발한 Django로 만든 어플리케이션을 배포하려면 어떻게 해야하는지 알아봤었습니다.

 

1. 개발한 소스코드를 git에 잘 정리해서 올려둔다.

2. EC2를 올리고 EC2에 접속해서 git clone한다.

3. git clone한 소스코드를 실행한다. 

 

다음과 같은 절차를 걸쳐서 진행했었습니다. 그런데 EC2의 수량이 100대라면? 

100대의 EC2에 들어가서 다 그렇게 하는게 맞는것인가?

 

아닙니다. 

 

그럴경우 git clone한 EC2이미지를 만들어서, 그 이미지를 바탕으로 100대를 만들면 각각의 EC2에 git clone을 할 필요는 없습니다.

그러나 소스코드를 실행하기 위해서는 어쩔 수 없이 다 EC2에 접속해야하는 이슈가 있습니다. 

 

그러면 어떻게 해결해야되냐? 소스코드가 올라가면 알아서 실행되게끔해야된다. 

그래서 Nginx, Gunicorn, Supervisor를 활용한다. 

 


Nginx란 무엇인가?

- 차세대(?) 웹서버

- 아파치를 안쓰고 요즘은 다 이걸 쓰죠.. 아파치는 너~무오래됨.. 

- 적은자원으로 더 빠르게 쓸 수 있다는 장점이 있다고하네요

 

EC2를 올리고, 거기에 nginx등 필요한걸 설치 해보겠습니다. 

 

sudo apt update

sudo apt-get install python3-pip

sudo pip3 install gunicorn

sudo apt-get install supervisor

sudo apt-get install nginx

sudo pip3 install django

django-admin startproject django_nginx

cd django_nginx

vi django_nginx/settings.py

>> ALLOWED_HOSTS = ["*"]으로 바꿔준다. 

 

python3 mange.py runserver 0.0.0.0:8000 >>돌아가는지 확인 

 

cd /etc/supervisor/conf.d

sudo touch django.conf

sudo vi django.conf

>> 이파일안에 다음 내용을 넣음

[program:gunicorn]

directory=/home/ubuntu/django_nginx

command=/usr/local/bin/gunicorn --workers 3 --bind:/home/ubuntu/django_nginx/app.sock django_nginx.wsgi:application

autostart=true

autorestart=true

stderr_logfile=/logs/gunicorn.err.log

stdout_logfile=/logs/gunicorn.out.log

해당내용 입력

 

sudo mkdir /logs

sudo supervisorctl reread

sudo supervisorctl update

cd /etc/nginx/

cd sites-available

sudo touch django.conf

sudo vi django.conf

>> 아래 내용입력

server{

 listen 80;

 server_name *.compute.amazonaws.com;

 location / {

   include proxy_params;

   proxy_pass http://unix:/home/ubuntu/django_nginx/app.sock;

   }

 }

 해당내용 입력

 

sudo ln django.conf /etc/nginx/sites-enabled/

sudo service nginx restart

 

 

장고파일을 먼저 해야 nginx가 정상적으로 설정 동작됩니다. 

EC2에 정상적으로 다 설치되면 

welcome NGINX 페이지가 떠야합니다. 

 

 


 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

반응형


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


 

AWS CloudFront

Cloudfront = cache + CDN 

 

cache는 잘 알다시피 데이터나 값을 미리 복사해놓는 임시 장소를 말합니다. 캐시에 접근하면 원래 데이터에 접근하는 시간보다 훨씬 빠르고, 다시 계산하는 시간을 절약할 수 있습니다. 

강의에서는 서버를 Origin 이라고 표현했고, 캐시서버를 distribution이라고 표현했는데, 

cloudfront를 직접 다룰 때 이 용어를 정확히 이해하고 있어야합니다. 

 

CDN은 Content Delivery Network의 약자입니다. 전세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 그런 콘텐츠 전송기술을 의미합니다. 
전세계에 흩어져있는 Edge Location을 활용하여 가능합니다. 

 

CDN을 처음에 쓸 경우에는 느릴 수 있지만 그 데이터들이 캐시서버에 저장하고 있어 그 이후로는 빠르게 서비스를 할 수 있습니다. 

origin을 거치지 않고 distribution을 활용하기 때문입니다. 

 

CDN의 활용사례를 이야기할 때 항상 나오는게 넷플릭스입니다. 자체 CDN을 구축하고 있다고합니다. 

 

 

위 사진과같은 형태의 아키텍처를 구성할 수 있습니다. 

 

추가로 설명을 조금 덧붙이면 

CloudFront의 origin 설정을 S3와 ELB 둘 중 하나로도 설정할 수 있습니다. 

 

 

Cloudfornt를 설정할때 미국등 영어권만할지 전세계로 할지에 따라서 비용의 차이가 있습니다.

물론 비쌀 수록 서비스의 질이 좋아지겠지만, 어디 나라 쪽을 지원하느냐를 고려해서 설정해야합니다. 


본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

 

반응형


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


http와 https 

익히 이 두차이는 알겠지만 

http는 클라이언트와 서버가 통신할 때 정보를 암호화하지 않고 전송하여 보안에 취약

https는 암호화하여 전송함으로 안전하지만 인증서 발급 및 암복호화의 과정이 있어야해서 조금 느림

 

 

ACM 

AWS에서 인증서 프로비저닝, 관리, 배포를 해주는 서비스입니다. Certificate Manager라고도 합니다. 

ACM에서 인증서를 요청해서 받을수가 있습니다. Route53에서 받은 도메인을 입력해서 진행하면 됩니다. 

 

fast-devops.comwww.fast-devops.com  등.. 필요한 도메인을 모두 입력해줍니다. 

와일드카드라는 것도 들어보셨을 텐데

 

와일드카드는 * 형태(모두포함)로 관련된 모든 도메인에 적용할때 와일드카드 인증서라고 합니다. 

 

그리고 인증서 검증을할 때 DNS와 이메일 검증 2가지 방법이있습니다. 

DNS로 검증하는 것을 권고드립니다. 

 

DNS로 검증을 할경우 Route53에서 생성한 도메인 레코드에 버튼클릭하나로 자동으로 인증관련된 CNAME레코드가 입력이되고 그러면 정상적으로 인증서 발급이 되는걸 확인 할 수 있습니다. 

 

 

ELB에 발급한 인증서 적용

인증서가 발급되었다고 바로 적용되진 않습니다.

적용할 ELB에 접속하여 리스너에 HTTPS 443을 추가하고, 발급받은 인증서를 추가해야만 적용이 됩니다. 

 

그러면 인터넷주소에 접속하였을 때 보안연결사용이 정상적으로 뜨게 됩니다.

 

 

 

 


 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

반응형

 


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


 

 

이번강의는 잘 모르는 경우가 많을 것 같은 그런 내용입니다. 

 

도메인을 산다 등록한다라고 얘기를 많이하는데, 어떤식으로 이루어지는지 모르는 경우가 많습니다. 

 

위 사진에서 잘 표현이 되어있고, 

 

등록 대행자는 freenom도 있고, 국내에서는 가비아에서 많이 진행합니다. 

그리고 .com 인지 .ai인지에 따라 등록소가 다 다릅니다. 

 

클라이언트는 원하는 도메인이 등록이 되었으면, 

ICANN에 등록된 Root name server에 fast-devops.com을 찾게되고, 

Roout name server에서는 com에 해당되는 등록소에서 정보를 보내주도록 하는 그런 절차라고 합니다. 


AWS의 route53은 등록대행의 역할을 진행합니다. 

AWS의 ELB와 연결해서 서비스를 제공할때 쓰이면 좋다고 하네요. 

 

route53에서 도메인을 구매 가능하고, .com  .io  .org 등에 따라서 가격이 다 다릅니다. 

.com의 경우 1년에 12달러이네요.. 

 

등록을 하는 경우 바로 뿅 생성되는것이 아니라 

AWS에서도 등록하는데 최대 3일정도가 걸린다고 합니다. 

도메인이 정상 등록되면 정상등록되었다고 메일을 보내주고, 등록실패할 경우에도 왜 등록이 실패했는지 메일로 준다고 하네요.

 

도메인이 정상적으로 구매완료 되었다면 Route53의 호스팅 영역에 표시가됩니다. 

레코드에 NS, SOA(CNAME) 설정들이 기본적으로 되어있는걸 확인할 수 있는데 ,

AWS Route53을 이용하여 구매할 경우 AWS에서 자동으로 설정을 해줘서 바로 사용이 가능합니다. 

 

그러나 freenom이나 가비아를 통해서 도메일을 구매하였을 경우에는 이런 NS, SOA(CNAME)를 직접등록해야 합니다. 

 

 

Route53에서 레코드 생성을 통해 원하는 IP또는 별칭을 연결할 수 있습니다. (ELB나 EC2 등)

레코드 생성에 따라 앞에 www.를 붙여도 되고.. 그렇게 활용을 할 수 있습니다. 

 

 

Route53으로 도메인을 구입해서 그것을 ELB와 연결하는 것 까지 알아봤는데, 

실제 실습을 통해서 해보니까 이해도 잘되고 좋았습니다.

CNAME이나 이런부분은 조금 더 자세히 알아볼 필요는 있네요. 

 

다음은 인증서에 대해서 알아보겠습니다. 


 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

반응형


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


ELB에 대해서 알아보는 시간을 전시간에 가졌습니다.

실제로 실습을 통해서 ELB에 설정해보는 시간을 가졌습니다. 

 

 

 

실습은 ALB를 생성해서 연결하는 형태로 진행이 되었습니다. 

여기서도.. 굉장히 그냥 default VPC를 사용하고 서비넷설정하는 것도 그냥 대충하고 넘어갔는데.. 

이런부분에서 조금 더 신경을 써주면 좋지 않았을까? 라는 생각이듭니다. 

 

실제로 한 서비스를 만든다고 생각하고 접근을 해야하는데, 굉장히 먼가 대충대충이네요.. 

헬스체크하는 포인트도 있는데, unhealthy로 떳는데 해결도 안하고 그냥 넘어가네요.. 

기본적인 아키텍처 그림을 바탕으로 이런식으로 설정하고 이런식으로 VPC가 구성되어있고, 

그래서 ALB는 위치가 어디고, 대상그룹은 어디인지가 보이지 않습니다. 

 

처음하는 사람이 따라오기에는 이건 뭔소리인가.. 할 것 같네요. 

 

앞서 한 내용들이 계속 사용되는게 아니고 다 분리되어 있는 느낌입니다. 

 

앞선 개발코드에서는 8000번을 쓰는데, 갑자기 ELB설정할때는 81번으로 바꾸고.. 그에 대한 설명도 많이 부족하네요

VPC나 헬스체크도 참.. 이번강의는 아쉬운부분이 많습니다. 

 

GWLB도 새로 출시되었는데, 그냥 새로 나왔나보내요 하고하는 부분도 그렇고.. 

 

이미지 생성할때 애러가날 수 있는부분 설명하는것도.. 음.. 

 

앞선 LB설명도 뭔가 많이 부족했고. .참.. 그릏습니다. 

 


ALB Rule

URL path에 맞게 각각 다른 Target group으로 갈 수 있도록 설정할 수 있습니다. 

 

Sticky Session 

특정 EC2에 접속한다고 가정했을 때, 그 해당 EC2에 세션값이 정해져있지만

LB를 통해 Target group안에서 EC2가 변경되었을 경우? 사전에 맺어둔 session이 의미가 없어져 버리는 문제 발생

그럼 해결 방법은? 세션에 대한 정보를 EC2에 두는것이 아니라 LB에 두자. 

그래서 LB에서 세션을 확인해서 해당 EC2에 연결되도록 하는 개념

 

 

이번영상은.. 전체적으로 아쉬움이 많은 영상들이였네요

 


본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

 

반응형


< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS


 

EC2 배포까지 다 해보았으니.. 

이제 ELB에 대해서 알아보는 시간입니다. 

로드벨런싱은 익히 들어 잘 알거라고 생각합니다. 

 

L4 로드밸런싱 = AWS CLB (classic 로드밸런싱)

L7 로드밸런싱 = AWS ALB (application 로드밸런싱)

 

L4로드밸런서 CLB는 데이터를 보지 않고, IP와 포트만 보고 분산해줌. 간단한 서비스 

L7로드밸런서는 데이터를 보고 해더도 봐야되고 그런다음에 판단을 해야함. 

 

뭐.. 대충 이런 이야기하고 끝이 났습니다. 

추가적인 설명을 좀 덧붙이자면

 

 

ELB는 NLB, ALB, CLB로 구분됩니다. 

CLB는 22년 8월에 서비스 종료하는 걸로 알고 있습니다. 

 

 

선택! AWS 서비스, 아리송한 AWS 서비스 대신 결정해드립니다. - 안준환 차장, NDS :: AWS Summit Seo…

스폰서 발표 세션 | 선택! AWS 서비스, 아리송한 AWS 서비스 대신 결정해드립니다. 안준환 차장, NDS AWS는 매년 수많은 신규 서비스와 기능들을 출시합니다. 이 중에는 여러분들로 하여금 선택하는

www.slideshare.net

 

 

서버 부하 분산 쉽게 이해하기

부하 분산(Load Balancing)이란 말 그대로 처리해야 할 업무 혹은 요청 등을 나누어 처리하는 것을 의미합니다. 회사에서 팀장이 외부로부터 받아 처리해야 할 업무를 팀원에게 나누어 주는 행위 또

aws-hyoh.tistory.com

 

 

Elastic Load Balancing 기능 - Amazon Web Services

 

aws.amazon.com

 

ALB (Application Load Balancer)

> OSI 7계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서로 HTTP, HTTPS의 특성을 다룸.

부하분산 뿐 아니라 HTTP 헤더, Host 헤더, 요청 메서드 등의 정보를 이용해 부하분산을 합니다. 

> 요청을 받으면 우선순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹에서 대상을 선택합니다.  (규칙을 정할 수 있습니다.)

> HTTP를 활용한 라우팅(부하분산)

> 로드밸런싱 방법 선택가능 (Round Robin , Least Outstanding Requests)

> SSL 인증서 사용가능

> 포록시서버 역할 가능

> AWS Web Application Forewall(WAF) 연동 가능 

 

 

NLB (network Load Balaner)

> OSI 4계층에 해당하는 Transport Layer의 특성을 이용하는 로드밸런서로 TCP, UDP를 사용 요청으로 부하분산을 합니다. (송신자와 수신자 간의 논리적인 연결 담당) 

> ALB보다 빠르고 시스템 리소스 소모가 적습니다. 지연시간이 훨씬 낮음

> TCP/UDP기반 라우팅

> 고정 IP를 갖는다.

> ALB와 달리 보안 그룹을 가짖지 않습니다. 

> SSL인증서 사용 가능

> Request만 처리하고 Response는 EC2가 직접 전달하여 NLB의 트래픽 처리 부담이 적음

 

 

CLB

> 4/7계층에 모두 해당되는 로드밸런서로 EC2-Classic 네트워크 내에 구축되어있을 경우 사용

> CLB가 가장 오래된 서비스이고, 그 이후 ALB가 출시되었고, 가장 최근에 시작한 서비스가 NLB입니다. 

> CLB에서 ALB, NLB의 모든 서비스를 지원하려다가 ALB, NLB로 레이어에 맞춘 특화된 LB가 나온거 같습니다. 

 


본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

 

https://bit.ly/3FVdhDa

 

수강료 100% 환급 챌린지 | 패스트캠퍼스

딱 5일간 진행되는 환급챌린지로 수강료 100% 환급받으세요! 더 늦기전에 자기계발 막차 탑승!

fastcampus.co.kr

 

반응형

+ Recent posts