ELB (Elastic Load Balancing)

워크로드를 다수의 컴퓨팅 리소스로 분산한다.

서비스 영향을 주지않고 컴퓨팅 리소스를 추가/제거할 수 있다.

로드 벨런서는 등록된 대상의 상태를 모니터링하고 정상 대상으로만 트래픽이 라우팅 되도록 한다.

ELB도 서버를 이용해 구현한 것이므로 멀티AZ 환경에서는 내부적으로 AZ마다 ELB가 구성되므로 AZ별 부하를 고려해서 구성한다.

ELB에는 ALB, NLB, CLB 3가지 종류가 있다.

 

 

ALB (Application Load Balancer)

HTTP, HTTPS 로드밸런싱에 최적화 되어 있음

웹소켓, 사용자 인증도 지원 함

L7전용이라 TCP등의 로드밸런싱 불가능

host based routing과 path based routing을 지원하며(=content based routing) 여러개의 URL과 path를 가질 수 있음

 

NLB (Network Load Balancer)

성능면에서 최고

TCP, UDP등의 L4의 로드밸런싱 가능

 

CLB (Classic Load Balancer)

TCP, SSL, HTTP, HTTPS 등 L4~L7의 로드밸런싱이 가능

웹서버 health check시 /index.html경로를 참조 하기 때문에 이 파일이 없으면 health check가 실패 하므로 이런 경우 TCP로 80번 포트를 모니터링해서 우회할 수 있다.

CLB는 URL하나만 가질 수 있음

 

 

기능 ALB NLB CLB
프로토콜 HTTP, HTTPS TCP, UDP, TLS TCP, SSL/TLS, HTTP, HTTPS
플랫폼 VPC VPC EC2-Classic, VPC
상태 확인
CloudWatch 지표
로깅
영역 장애 조치
Connection Draining(등록 취소 지원)  
같은 인스턴스의 여러 포트로 로드 밸런싱  
IP 주소를 대상으로 사용 (TCP, TLS)   
로드 밸런서 삭제 탐지  
구성 가능한 유휴 연결 시간 초과  
교차 영역 로드 밸런싱
고정 세션
정적 IP    
탄력적 IP 주소    
소스 IP 주소 유지    
리소스 기반 IAM 권한
태그 기반 IAM 권한  
느린 시작    
WebSocket  
PrivateLink 지원   (TCP, TLS)   
소스 IP 주소 CIDR 기반 라우팅    
계층 7
경로 기반 라우팅    
호스트 기반 라우팅    
네이티브 HTTP/2    
리디렉션    
고정 응답    
Lambda 함수를 대상으로 사용    
HTTP 헤더 기반 라우팅    
HTTP 방법 기반 라우팅    
쿼리 문자열 파라미터 기반 라우팅     
보안
SSL 오프로드
SNI(서버 이름 표시)  
백엔드 서버 암호화
사용자 인증    
사용자 지정 보안 정책    

 

 

 

== 참고

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/what-is-load-balancing.html

https://aws.amazon.com/ko/elasticloadbalancing/features/

 

 

AND

Region

AWS 서비스가 위치한 장소 or 서비스 지역

예: 한국(ap-northeast-2), 런던(eu-west-2), 홍콩(ap-east-1)

 

AZ(Availability Zone)

region 내에서 물리적으로 분리된 AZ가 구성 됨. IDC라고 생각하면 됨.

일반적으로 하나의 region에 3개의 AZ가 존재 함.

예: 한국 남부 IDC, 한국 중부 IDC와 같은 형태라고 생각하면 됨.

 

VPC(Virtual Private Cloud)

사용자가 구성한 독립된 가상 네트워크

하나의 region에 속하며 모든 AZ에 걸쳐서 구성된다.

VPC의 IP주소 범위를 CIDR로 지정해야 한다. 여러 IP주소 범위를 지정 가능.

IP주소 범위를 지정할 때 공인IP 대역을 지정하는 경우 인터넷 연결을 할 때 해당 공인IP는 VPC 내부로 라우팅 되어 버리니 사설IP 대역 사용을 권장한다.

VPC에서 한번 지정한 IP대역 수정은 불가능하고 새로운 IP대역 추가는 가능하다.

 

[VPC 생성시 옵션]

* DNS Resolution : DNS 호스트네임을 IP로 해석할 때 AWS에서 제공하는 DNS 서버를 사용. (기본 : Enabled)

* DNS Hostname : VPC 내부에서 생성되는 인스턴스에 퍼블릭 DNS 호스트네임을 할당해주는 기능. (기본 : Disabled)

 

Subnet

VPC의 IP주소 범위 내에서 Subnet을 생성하고 특정 1개 AZ를 지정하여 구성

서브넷 트래픽이 인터넷 게이트웨이로 라우팅 되는 경우 퍼블릭 서브넷, 아닌 경우 프라이빗 서브넷이라고 한다.

퍼블릭 서브넷의 인스턴스가 인터넷과 통신할 수 있게 하려면 퍼블릭IP or EIP를 가져야 한다.

VPC가 논리적이라면 서브넷은 물리적인 구성으로 EC2를 생성한다고 했을 때 특정 서브넷이 지정된다.

멀티 AZ로 구성하는 경우 AZ별로 서브넷을 생성한 후 각각 할당한다

 

네트워크 ACL / SG(Security Group)

NACL : 서브넷 인바운드/아웃바운드 트래픽 제어. stateless

SG : (EC2) 인스턴스 인바운드/아웃바운드 트래픽 제어. stateful

네트워크 ACL을 통과해도 SG에서 통신이 막힐 수 있다.

ACL 규칙의 번호는 우선순위를 나타내며, *는 어떤 규칙에도 해당하지 않는 경우 사용된다.

ACL 기본 규칙은 모든 통신 허용, SG 기본 규칙은 VPC 내부 리소스간 통신 모두 허용

 

Route Table

VPC의 IP주소 범위는 기본으로 라우트 테이블에 기록된다.

 

Internet Gateway

VPC는 기본적으로 격리된 네트워크 환경이다.

라우트 테이블에 VPC의 특정 서브넷이 인터넷 게이트웨이를 향하도록 규칙을 추가하면 해당 서브넷이 인터넷과 통신할 수 있다. 

이때 인터넷을 사용하려는 리소스는 공인IP를 가져야 한다.

 

 

 

== 참고

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html

https://www.44bits.io/ko/post/understanding_aws_vpc

 

 

 

 

AND

 

AWS Shield Standard

주요 보호 대상 : L3, L4 계층. CF, Route53 서비스

추가 비용 없이 가장 흔한 공격 유형에 대해 자동 대응. (SYN/UDP Flood, Reflection Attack 등)

L7 공격 대응을 위해서는 AWS WAF 활용 필요.

 

 

AWS Shield Advanced

주요 보호 대상 : L3, L4, L7 계층. EC2, ELB, CF, Route53, Global Accelerator 서비스. (각 리소스 유형별로 1,000개까지 보호 지정 가능)

비용 : 월 사용료 약 $3,000 , 데이터 Transfer out 비용

예를들어 EIP로 DDoS 공격이 감지되는 경우 해당 EIP는 네트워크 경계로 이동하여 EC2의 대역폭인 10Gbps가 아닌 수TB 트래픽을 처리할 수 있게 된다. (네트워크 경계라는 개념은 뭔지 잘 모르겠다 =_=)

DDoS공격으로 인한 AWS 비용 급증으로부터 보호하는 기능을 제공한다.

UDP 반사 공격, SYN flood, DNS 쿼리 flood, HTTP flood/캐시 버스팅 공격 등의 DDoS 공격에 대한 보호를 제공한다.

WAF는 추가 비용 없이 Shield Advanced 서비스와 함께 제공된다. L7 계층을 어플리케이션 패턴 공격은 WAF를 통해 보호합니다.

 

기능 활성화 후 보호가 필요한 리소스를 지정하면 된다. (세부 옵션 같은건 없음)

1. EIP, Global Accelerator, Route53를 지정하면 위험 감지 정확도가 향상되어 임계값 이하에서 위험이 감지되어 방어한다.

2. CF, ELB를 지정하면 트래픽 볼륨이 통계적으로 변화가 감지될 때 알림이 발생한다.

 

 

WAF

비용 : $5/웹ACL , $1/rule , $0.6/100만request

임계치가 넘는 요청을 보내는 IP 자동 차단. 기본값 5분간 2,000회 요청.

정책을 정하고 해당하는 요청은 특정 Action을 취하도록 할 수 있음. 복합적인 정책을 굉장히 디테일하게 지정 가능.

일반적인 사용 대상

  1. 취약점 공격 : SQL Injection, XSS(Cross Site Scripting)
  2. 악의적인 요청 : Web Crawler, Scrapers, Direct linkes, 스캐너/probes
  3. L7 DDoS : HTTP/HTTPS floods

 

 

 

== 참고

https://docs.aws.amazon.com/ko_kr/waf/latest/developerguide/shield-chapter.html

 

DDoS 공격의 유형
1. UDP(User Datagram Protocol) 반사 공격
공격자는 요청의 소스를 스푸핑하고 UDP를 사용하여 서버에서 대규모 응답을 끌어낼 수 있습니다. 공격을 받는 스푸핑된 IP 주소에 추가 네트워크 트래픽이 유도되면 대상 서버의 속도가 느려질 수 있으며 합법적인 사용자가 필요한 리소스에 액세스하지 못할 수 있습니다.

2. SYN flood
SYN flood 공격의 목적은 연결을 절반 정도 열린 상태로 유지하여 시스템에서 사용 가능한 리소스가 고갈되도록 하는 것입니다. 사용자가 웹 서버와 같은 TCP 서비스에 연결하면 클라이언트는 SYN 패킷을 전송합니다. 서버는 승인을 반환하고 클라이언트는 자체 승인을 반환하여 3방향 핸드셰이크를 완료합니다. SYN flood에서 세 번째 승인은 반환되지 않고 서버는 응답을 대기하는 상태로 유지됩니다. 이로 인해 다른 사용자가 서버에 연결하지 못할 수 있습니다.

3. DNS 쿼리 flood
DNS 쿼리 flood 공격에서 공격자는 여러 DNS 쿼리를 사용하여 DNS 서버의 리소스를 고갈시킵니다. AWS Shield Advanced​은 Route 53 DNS 서버에 대한 DNS 쿼리 flood 공격을 방지하는 데 도움이 됩니다.

4. HTTP flood/캐시 버스팅(계층 7) 공격
GET 및 POST flood를 포함한 HTTP flood 공격에서 공격자는 웹 애플리케이션의 실제 사용자로부터 나온 것처럼 보이는 여러 HTTP 요청을 전송합니다. 캐시 버스팅 공격은 HTTP 요청 쿼리 문자열에서 변형을 사용하여 에지 로케이션 캐시 콘텐츠 사용을 가로막고 콘텐츠가 오리진 웹 서버에서 제공되도록 강제하여 오리진 웹 서버에 손상을 일으킬 수 있는 추가 부담을 발생시키는 일종의 HTTP flood입니다.

 

 

AND

K8S(Kubernetes)

시스템 2020. 6. 26. 19:31

 

K8S

Docker같은 컨테이너들을 편리하게 운영할 수 있게 해주는 오케스트레이션 도구

관리자가 이 컨테이너 서비스는 웹이야 라고 정의하면 K8S가 적당한 서버를 골라 배포하고 부하 상황을 모니터링 하면서 컨테이너를 scale out/up/in 할 수 있다. CPU, Memory 외에 현재 접속자 수 같은 값을 이용해 Auto Scaling도 된다.

다양한 방식의 배포를 제공해서 canary, Rollingupdate 등 우리가 생각할 수 있는 대부분의 방법들이 이미 준비되어 있다.

Google에서 발표한 IDC에서 사용하는 기술이지만 Google 포함 모든 클라우드 벤더들이 K8S를 지원한다.

 

배포한 서비스들은 논리적으로 Namespace나 Label 단위로 관리가 가능. 예를들어 label이 Frontend인 컨테이너를 버전1->버전2로 업그레이드 하게 명령할 수 있다.

 

Desired State라는 방식으로 컨테이너를 관리한다.

예를들어 "web app 1개를 유지해" 라고 요청하면 컨테이너가 없으면 적절한 pod에 web app 컨테이너를 1개 띄우고, 이미 컨테이너가 떠 있다면 더이상 생성하지 않는다. 모니터링을 하다 web app 컨테이너가 사라지면 다시 1개를 띄운다.

이런 방식으로 관리자는 직접 컨테이너를 생성하고 제거하는 등의 명령을 내리지 않아도 된다.

 

Ingress 기능을 제공하는데 Proxy 같은 녀석이다. 특정 웹서비스를 제공하는 컨테이너의 IP가 변경 되더라도 어떤 IP 를 찾아가면 되는지 알려준다.

여러개의 Ingress를 설정할 수 있어 보통 관리자용과 일반 유저용을 분리해서 관리한다.

 

 

 

Pod

K8S 배포 최소단위 : 컨테이너, 스토리지, 네트워크.

Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고 서로 localhost로 접근 가능.

컨테이너를 하나만 사용하더라도 Pod으로 감싸서 관리한다.

 

Deferation, Multi Cluster

클라우드와 IDC를 묶어서 관리할 수 있다.

구글에서 발표한 Anthos를 이용하면 여러 클라우드의 여러 클러스터를 한곳에서 관리할 수 있다.

 

CRD (Custom Resource Definitaion)

K8S가 제공하지 않는 기능이 있는 경우 plug-in같은 느낌으로 추가 리소스를 설치해서 사용할 수 있는 기능이다.

 

Cloud Code

구글에서 제공하는 K8S용 개발환경. IntelliJ, VS Code에서 사용 가능하다.

https://cloud.google.com/code

 

 

 

== 참고

CNCF CNCF Cloud Native Interactive Landscape : https://landscape.cncf.io/

https://medium.com/@tkdgy0801/amazon-eks-%EB%A1%9C-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-kubernetes-intro-83fd3ef2f10e

https://subicura.com/2019/05/19/kubernetes-basic-1.html

 

 

 

AND

SVN, Github, Gitlab

시스템 2020. 6. 26. 02:04

 

SVN vs Git

SVN 버전 중앙관리 방식

서버의 소스를 내려받아(update) 작업하고 결과물을 서버로 commit.

서버가 죽으면 그동안 update, commit을 못함.

서버에 commit한 소스는 다른 사람들이 모두 update할 수 있으니 특정 문제가 있는 소스를 commit하는 경우 문제가 발생할 수 있음

동일한 파일을 여러 사람이 작업하는 경우 충돌 발생

 

Git 버전 분산 관리 방식

로컬 저장소에 나만의 이력관리를 하면서 개발이 어느정도 마무리 된 파일을 서버에 반영 함

진행하는 작업이 많은 경우 작업별로 commit 대상을 구분해서 관리할 수 있는 스테이지 영역 기능이 있음

중앙서버가 죽어도 각자의 로컬저장소를 이용해 작업 가능하며, 로컬저장소를 이용해 중앙서버의 복구도 가능하다.

 

 

 

Github vs Gitlab

Github

무료계정으로 Github 저장공간을 사용하는 경우 모든 코드를 공개해야 한다

싫으면 유료계정 사용하면 됨. 개인 $7/Month, 팀은 유저당 $9/Month

 

Gitlab

설치형 Github

클라우드형 Gitlab도 있음

무료임

 

 

== 참고

git from SVN : https://www.slideshare.net/justinyoo/git-from-svn

https://ojava.tistory.com/158

 

 

AND


php7.1 -> 7.0 다운그레이드

sudo apt-get remove php7.1-fpm

sudo apt-get remove php7.1-mysql

sudo apt-get autoremove libvpx1 php7.1-cli php7.1-json php7.1-opcache php7.1-readline

sudo apt-update


sudo apt-get install php7.0-fpm

sudo apt-get install php7.0-mysql


nginx 설정에 반영. 
/etc/nginx/sites-enabled/default 

여기서 php 경로를 7.0으로 변경

fastcgi_pass unix:/var/run/php7.0-fpm.sock;

sudo service nginx reload


sudo apt-get autoremove php-xml

sudo apt-get install php7.0-xml


sudo apt-get autoremove php-gd

sudo apt-get install php7.0-gd


AND

Linux에서 cp로 폴더 복사시 대상 폴더가 있으면 omitting directory 가 나오면서 건너뛰어 버린다

이때는 -r 옵션을 함께 주면 된다

cp -r 원본 대상


mv명령으로는 되지 않는다.

cp로 복사 후 기존 폴더를 지워버려 mv처럼 동작시켜야 한다.



AND

xe 설치하기

시스템 2018. 8. 10. 21:13

== 환경정보

OS : ubuntu 14.04.5 LTS x64

nginx 1.12.1

php 7.1.10 fpm

PHP 7.1.10-1+ubuntu14.04.1+deb.sury.org+1 (cli) (built: Sep 29 2017 17:33:22) ( NTS )

Copyright (c) 1997-2017 The PHP Group

Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

    with Zend OPcache v7.1.10-1+ubuntu14.04.1+deb.sury.org+1, Copyright (c) 1999-2017, by Zend Technologies


mysql 5.7

mysql  Ver 14.14 Distrib 5.7.20, for Linux (x86_64) using  EditLine wrapper


xe : 1.8.46



127.0.0.1/xe 접속시 xml_parser 오류 발생

2017/10/28 23:21:18 [error] 2422#2422: *9 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function xml_parser_create() in /var/www/html/xe/classes/xml/XmlParser.class.php:128

// 다음과 같이 php-xml 설치하면 알아서 Php7.1관련모듈을 함께 설치해 줌
sudo apt-get install php-xml 

이후 127.0.0.1/xe 접속시 설치 페이지는 정상적으로 뜨지만 설치 조건 확인에서 다음과 같은 경고가 발생

퍼미션 :  불가능

[필수] XE의 설치 경로 또는 ./files 디렉토리의 퍼미션이 707이어야 합니다.

GD 라이브러리 :  불가능

이미지변환 기능을 사용하기 위해 GD라이브러리가 설치되어 있어야 합니다. 

// php-gd 라이브러리 설치

sudo apt-get install php-gd

// xe 폴더에 가서 다음과 같이 files 폴더 생성 및 권한 설정

mkdir files

chmod 707 ./files


XE 설치 가능함을 확인


xe에서 사용할 계정 생성

grant all privileges on DB명.* to ID입력@localhost identified by '암호입력' with grant option;


다음과 같은 오류 발생

'' template file does not exists 

layout이 없어서 발생하는 문제. 

기존의 xe 사이트 데이터를 mysqldump로 받아와서 복원했는데 xe는 신규 버전으로 설치해서 기존에 사용하던 layout이 없는가보다

모바일 웹으로 접속해서 Layout을 default로 변경 후 문제가 해결 됨.


AND

apt 패키지 찾기

시스템 2018. 8. 10. 21:12

apt에서 검색어의 패키지가 있는지 확인

sudo apt-cache search 검색어


apt에서 패키지 설치

sudo apt-get install 패키지명



AND

sudo apt-get install lrzsz


이후에 탐색기에서 xshell로 drag & drop 을 하면 파일을 복사해 넣을 수 있다.



AND