개인히스토리저장소

[AWS Architecture] #6. ELB 설정

작성일자 : 2018년 10월 14일

목표 구성

현재 구성

ELB(Elastic Load Balancer )란?

Elastic Load Balancing는 여러 가용 영역에서 Amazon EC2 인스턴스, 컨테이너 및 IP 주소 같은 여러 대상에 수신 애플리케이션 또는 네트워크 트래픽을 분산합니다. 애플리케이션에 대한 트래픽이 시간에 따라 변화하므로 Elastic Load Balancing이 로드 밸런서를 자동으로 확장하며 대다수의 워크로드를 자동으로 확장할 수 있습니다. 이러한 작업을 ELB에서 해줄 수 있으며, L4 Switch에서의 LB 역할을 수행합니다.

현재 구성

1. ELB 설정

ELB 생성

- EC2 > 로드 밸런싱 > 로드밸런서 > 로드 밸런서 생성

- CLB로 진행

-내부 로드 밸런서 생성 옵션으로 내/외부 구분

-내부 로드 밸런서의 경우 8080 Port로 들어와서 연결 인스턴스(WAS)에게 8080 Port로 전달

-외부 로드 밸런서의 경우 80 Port로 들어와서 연결 인스턴스(Web Server)에게 80 Port로 전달

-트래픽을 분산할 서버의 서브넷 설정(내부:Private Subnet, 외부:Public Subnet)

-Apache로 가는 외부용은 Default 설정을 따르며 Tomcat로 가는 내부용은 Ping 포트:8080, Ping 경로 /index.jsp로 설정

- 외부 : WebServer #1, 2

- 내부 : WAS #1, 2

확인

- 외부, 내부용 ELB 생성 완료

ELB 생성 후 현재 구성

구성 확인 

시나리오 1 :

인터넷 망(본인 PC) 에서 외부 로드밸런서 접근하여 트래픽 분산 확인

시나리오 2:

내부 망(VPC 내 접근용 서버) 에서 내부 로드밸런서로 접근하여 트래픽 분산 확인

2. Web Server 설정

mod_proxy 모듈 사용하도록 설정 : 

http://osc131.tistory.com/79

VirtualHost 설정 

Web Server VirtualHost 구성 후 현재 구성

구성확인

시나리오 1 :

인터넷 망(본인 PC)에서 외부 로드밸런서로 접근하여 외부로드밸런서 > 웹서버 > 내부로드밸런서 > WAS 의 경로로 로드밸런싱 및 요청/응답 확인

참조

https://jackiechen.org/2018/01/10/aws-elb-clb-vs-alb-vs-nlb/

http://osc131.tistory.com/80 - [AWS Architecture] #1. 소개 

http://osc131.tistory.com/81 - [AWS Architecture] #2. VPC 생성하기

http://osc131.tistory.com/82 - [AWS Architecture] #3. Subnet 설정

http://osc131.tistory.com/83 - [AWS Architecture] #4. EC2 설정

http://osc131.tistory.com/84 - [AWS Architecture] #5. RDS 설정

http://osc131.tistory.com/85 - [AWS Architecture] #6. ELB 설정

[AWS Architecture] #5. RDS 설정

작성일자 : 2018년 10월 13일

목표 구성

현재 구성

RDS(Relational Database Service)란?

AWS에서 제공하는 DB 서비스. 서버에 DB를 올려놓은 것과 동일하게 DB 사용이 가능하며 추가로 모니터링, 백업, HA 설정이 가능합니다. MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server 그리고 AWS의 Aurora DB 제품 군을 사용할 수 있습니다.

1. DB 서브넷 그룹 생성

RDS > 서브넷 그룹 > DB 서브넷 그룹 생성

이름 및 해당 DB 서브넷이 속할 VPC 선택

연결할 서브넷 설정 ( 연결 할 Subnet은 DB에 직접 접속 할 Private Subnet 망 )

확인

2. RDS 생성

RDS > 인스턴스 > 데이터베이스 생성

사용할 엔진 선택

목적에 맞는 옵션 선택

DB 세부 정보 지정

- 버전 및 인스턴스 사양 설정

- 이중화를 위한 다중 AZ 배포 설정

네이밍 설정

- 해당 페이지에서 설정한 이름 및 암호가 RDS에 접근 할 아이디, 패스워드가 된다

고급 설정 구성

-사용할 VPC, 앞에서 생성한 DB Subnet 설정

-설정한 Private Subent에서만 접근 가능하도록 퍼블릭 엑세스 허용 X

-가용영역 설정

PostgreSQL 기본 포트 : 5432

보안그룹 설정

RDS에 적용 할 보안그룹 설정

- 접근을 허용할 Private Subnet #1,2와, 접속 용 Public 서버 IP의 5432(PostgreSQL 서비스 포트) Inbound를 설정

확인

-Master(active) DB 가용영역 : a

-서브넷 : Private Subnet과 연결

-다중AZ 옵션 허용

-Slave(standby) DB 가용영역 : c 

DB Tool을 사용하여 접속 확인

현재 구성

- RDS 서브넷 그룹에 Private Subnet #1, 2가 연결 되어있고, 보안그룹 설정에 의해 Private Subnet #1, 2 망 내에서와 접근용 서버만 서비스 이용이 가능 

http://osc131.tistory.com/80 - [AWS Architecture] #1. 소개 

http://osc131.tistory.com/81 - [AWS Architecture] #2. VPC 생성하기

http://osc131.tistory.com/82 - [AWS Architecture] #3. Subnet 설정

http://osc131.tistory.com/83 - [AWS Architecture] #4. EC2 설정

http://osc131.tistory.com/84 - [AWS Architecture] #5. RDS 설정

http://osc131.tistory.com/85 - [AWS Architecture] #6. ELB 설정

[AWS Architecture] EC2 설정

작성일자 : 2018년 10월 12일

목표 구성

현재 구성

EC2란 ??

Elastic Compute Cloud(이하 EC2)는 Amazon Web Services(이하 AWS) 클라우드에서 확장식 컴퓨팅을 제공합니다. EC2에서 E의 Elastic은 고무처럼 탄력이 있다는 것을 의미 합니다. Amazon EC2를 사용하면 하드웨어와 초기 구축에 들어가는 선 투자를 할 필요 없이 빠르게 애플리이션을 개발하고 배포할 수 있습니다. 즉 실제 물리 서버 인프라를 구축하지 않고도 클라우드 상에 구축하여 서버로서 활용할 수 있다는 것을 의미합니다.

1. EC2 설정

각 Subnet에 EC2를 생성

생성할 때 아래 옵션의 설정이 필요

생성 결과

+++

WAS가 올라가는 EC2(서버)는 일반 인터넷망에서 접근이 불가능하기 때문에 Public Subnet에 Private Subnet 접근용 서버를 하나 추가해서 사용

2. Web, WAS 설치 및 설정

위에서 생성한 EC2들을 목적에 맞게 설정

Web Server(Apache) 설치 : 

http://osc131.tistory.com/56

WAS(Tomcat) 설치 : 

http://osc131.tistory.com/57

+++

현재 WAS용 서버는 Private Subnet에 위치해있기 때문에 인터넷 통신 불가(NAT 설정 필요)

때문에 Tomcat 파일을 인터넷 연결 서버에서 다운로드 후 접근용 서버를 통해 전송

현재 구성

http://osc131.tistory.com/80 - [AWS Architecture] #1. 소개 

http://osc131.tistory.com/81 - [AWS Architecture] #2. VPC 생성하기

http://osc131.tistory.com/82 - [AWS Architecture] #3. Subnet 설정

http://osc131.tistory.com/83 - [AWS Architecture] #4. EC2 설정

http://osc131.tistory.com/84 - [AWS Architecture] #5. RDS 설정

http://osc131.tistory.com/85 - [AWS Architecture] #6. ELB 설정

[AWS Architecture] Subnet 설정

작성일자 : 2018년 10월 11일

목표 구성

현재 구성

AWS VPC 서비스 내 Subnet 설정

사용할 가용 영역 및 IP 주소 영역 설정(VPC에 포함되도록)

Private용 서브넷 라우팅 테이블엔 NAT Gateway 설정 (본 과정에서는 설정은 하나 미사용)

Public용 서브넷 라우팅 테이블엔 Internet Gateway 설정

확인

현재 구성

현재 구성에서 Public Subnet 내에서는 별다른 설정 없이도 IGW를 통해 인터넷에 접근이 가능하나, Private Subnet 내에서는 인터넷 망 접근을 위해선 NAT Gateway 설정이 필요하다. 

http://osc131.tistory.com/80 - [AWS Architecture] #1. 소개 

http://osc131.tistory.com/81 - [AWS Architecture] #2. VPC 생성하기

http://osc131.tistory.com/82 - [AWS Architecture] #3. Subnet 설정

http://osc131.tistory.com/83 - [AWS Architecture] #4. EC2 설정

http://osc131.tistory.com/84 - [AWS Architecture] #5. RDS 설정

http://osc131.tistory.com/85 - [AWS Architecture] #6. ELB 설정

[AWS Architecture] VPC 생성하기

작성일자 : 2018년 10월 10일

목표 구성

VPC란?

Virtual Private Cloud(VPC)는 사용자의 AWS 계정 전용 가상 네트워크입니다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있습니다. 즉 일종의 AWS용 개인 네트워크 망입니다.

VPC 생성하기

AWS VPC 서비스 접근

위 구조에서의 VPC는 Public/Private Subnet을 둘다 사용

필요 정보 입력

CIDR를 활용해 VPC 주소를 설정하고 해당 VPC에 속하도록 Public/Private 주소를 설정 

외부(인터넷)으로, 외부(인터넷)에서 접근하기 위한 NAT 게이트웨이 설정

VPC 확인

현재 구성

[AWS Architecture] 소개

1. 개요

위 구성은 AWS에서 제공하는 Web Application Hosting Architecture입니다. 하나의 Web Application은 이론상으로 하나의 Server가 있으면 서비스가 가능합니다. 그러나 대부분의 인프라는 위와 같이 복잡한 구조로 설계가 되어있습니다. 그 이유는 실제 운영을 위해서는 보안, 고가용성, 과부하 등을 위해 여러 SW 및 Device가 추가되기 때문입니다. Web Application 인프라 설계의 궁극적인 목표는 지속적으로 안정적인 서비스를 보장하기 위함입니다.

2. 목표

AWS에서 제공하는 서비스를 활용하여 Web Application 서비스용 Architecture를 구성

3. 목표 구성도

Web-WAS-DB의 3 Tier 구조

Private/Public Subnet을 통한 내/외부망 분리 - 외부망은 IGW를 통해 인터넷 접근이 가능

두 개의 AZ에 구성하여 HA(고가용성) 보장

ELB를 통한 트래픽 분산

4. Flow

1) User가 Internet을 통해 Web 접근 시도

2) HTTP Request가 IGW를 통해 External ELB로 전달

3) External ELB에서 각 Web Server #1,2로 로드밸런싱

4) 각 Web Server에서 Request를 Internal ELB로 전달

5) Internal ELB에서 Request를 WAS로 전달

6) 각 WAS에서 DB 접근하여 Read/Write 작업 후 역순으로 User에게 Response

7) 평소에는 Master DB로만 서비스를 제공하며 장애 등과 같은 특별한 이유로 정상 서비스 불가 시 다른 AZ에 존재하는 Slave DB에서 서비스 제공

http://osc131.tistory.com/80 - [AWS Architecture] #1. 소개 

http://osc131.tistory.com/81 - [AWS Architecture] #2. VPC 생성하기

http://osc131.tistory.com/82 - [AWS Architecture] #3. Subnet 설정

http://osc131.tistory.com/83 - [AWS Architecture] #4. EC2 설정

http://osc131.tistory.com/84 - [AWS Architecture] #5. RDS 설정

http://osc131.tistory.com/85 - [AWS Architecture] #6. ELB 설정

[Linux] Apache, Tomcat 연동 (mod_proxy 사용)

작성일자 : 2018년 09월 13일

환경 : AWS Linux AMI 2018, Apache 2.2, Tomcat 7

1. Apache proxy 모듈 사용 설정

1.1 컴파일 시 필요 모듈(proxy) 포함

1.2 확인

# 컴파일 시 포함하는 방법 외에 동적으로 적재도 가능( 해당 경로에 mod_proxy.so 파일 필요 )

2. 연동 설정

3. 확인

# Apache IP로 접근했을 때 IP/proxy/ 이하 URL은 2. 설정에 의해 Tomcat 서버로 전달

Apache_IP/ 접근 시 Apache index 페이지 확인

Apache_IP/proxy/ 접근 시 Tomcat index 페이지 확인

접근 로그 확인

Apache 로그

 Tomcat 로그

일반 접근 시 Apache 서버로만 접근하며, /proxy 접근 시 Apache 서버로 접근 후 Apache 서버에서 Tomcat으로 전달

[Linux] 계정 별 JDK 설정

작성일자 : 2018년 08월 23일

환경 : CentOS 6.6 / JDK 1.8.0_181 / JDK 1.7.0_80

시나리오 : Root 계정을 제외한 사용자 계정 별 다른 버전의 JDK 설정

           jdk17 : jdk1.7 사용 계정

           jdk18 : jdk1.8 사용 계정

# JDK 1.7 버전은 EOS 이후 다운로드 시 로그인이 필요

# JDK 1.8 : wget을 이용하여 다운

# JDK 1.7 : 설치파일 직접 다운로드

1. 설치 파일 준비

2. 압축 해제

* 경로 확인 주의

3. jdk17 계정 설정

4. jdk18 계정 설정

5. 확인

[Linux] telnet 사용

작성일자 : 2018년 09월 14일

환경 : CentOS 6.6 Minimum

1. 관련 패키지 설치

# Minimum시 기본 설치 X

2. 설정

# disable = no 확인

3. 서비스 시작

> service xinetd restart

# telnet은 xinetd에 의해서 서비스가 관리

[Linux] Node.js 설치

작성날짜 : 2018년 08월 07일

환경 : Node.js 8.11.3, CentOS 6.6

# Source Code로 설치 시 g++ 버전 4.9.4 이상 권고

# NVM : Node의 버전을 관리

# NPM : 패키지 관리

1. NVM 설치

2. 권한 설정

3. 스크립트 실행

4. 환경변수 반영

5. Node 설치

6. 확인

참조

https://d2fault.github.io/2018/04/30/20180430-install-and-upgrade-nodejs-or-npm/