아무거나 시도해보는 개발일지

여태까지 구성된 아키텍쳐를 다시 살펴보자.

1) 유저가 WEB 서버 (Public IP)로 리퀘스트를 요청하면

2) 인터넷 게이트웨이가 이를 받아, 네트워크 주소 변환을 하여 VPC 내의 라우터로 전달한다.

- ex) 유저가 3.14.14.14 (Public IP)로 요청하면

      인터넷 게이트웨이가 이를 받아 10.0.0.82 (VPC 內 private IP)로 변환하여 라우터 전달

3) 라우터는 라우팅 테이블을 참조하여, VPC 안에서 목적지를 찾는다.

4) 10.0.0.82는 Public 서브넷 대역으로, 해당 망에서 목적지와 연결한다.

5) Nginx가 (10.0.0.82:80) 수신하고, Reverse Proxy 설정에 따라 10.0.0.190:82로 리퀘스트를 전달한다.

6) 라우터는 테이블을 참조하여, Python API Server로 연결한다.

7) 리퀘스트에는 IP:Port 말고 뒤에 /api/1234 라는 리퀘스트 Path 및 파라미터가 있었다.

   /api 로 수신하는 파이썬 서버가 이를 받아들인다.

   내부 로직에 따라 DB에 접속해서, Key 값이 1234인 데이터를 뽑아온다.

8) Name 값으로 kim을 받아 그대로 회신한다.

ㅁ WEB - WAS 연결 테스트

위의 Pyhton 코드는 Private Subnet에서 올라가있어, 직접 테스트가 불가능하다.

Public Subnet에 떠있는 Web서버를 통해 서비스 테스트를 해보자.

- WEB서버 Nginx port forwarding 설정

/etc/nginx/conf.d/default.conf 

server {
 listen 80; // 80포트로 리슨하고
 
 location /api/ { //api 리퀘스트 요청이 온다면
 proxy_pass http://10.0.0.190:82; // private WAS서버로 포워딩
 }
}

nginx 재시작

sudo service nginx restart 

ㅁ 연결테스트

- Nginx로 80 RestApi 호출 - 404 Error

- Nginx에는 Access Log 확인됌

Python에는 로그가 발견되지 않아

Nginx의 포트 포워딩 기능에 문제가 있다고 예상됌

에러로그에는 따로 남지않아, 포워딩 기능 재확인 필요.

- Default 링크 제거

스택 오버플로우를 참조하여 , /etc/nginx/site-enabled 의 default 링크 삭제.

포트포워딩 기능 정상 확인.

ㅁ WAS - DB 연결테스트

- Python <-> Postgresql 연동 라이브러리 설치  ( psycopg2 )

sudo pip3 install psycopg2

- 에러 발생

Error: pg_config executable not found.
=> Postgresql 관련 라이브러리가 설치되어 있지 않아서 그렇다고함.

libpq라는 Postgresql 프로그래밍 인터페이스 라이브러리 설치

sudo apt-get install libpq-dev

- Python 코드 수정

기존 Restapi 코드에서, 데이터를 Postgresql에 붙어서 가져오도록 수정

import psycopg2

user_db = psycopg2.connect (
  host='10.0.0.198',
  dbname='USER',
  user='test',
  password='a123456789',
  port=5432
)

@api.route('/api/users/<int:id>')
class HelloWorld(Resource):
 def get(self,id):
    cursor = user_db.cursor()
    sql = " select * from user_info where id= " + str(id)
    cursor.execute(sql)
    data=cursor.fetchall()
    return {"id": data[0][0],
              "name": data[0][1]}

- Key 값으로 1234 주었을 때

- Key 값으로 123 주었을 때

※ 비용 관리

원하는 아키텍쳐를 구성해보았으니, 할당받은 자원에 대해 정리도 중요하다

콘솔에서 현재까지 청구 금액을 살펴보자

현재까지 6$ 가량 나왔고, 대부분이 NAT Gateway라는것을 알 수 있다.

서버 구성이 완료되어, Private WAS / DB 에서는 외부 인터넷 연결이 필요없다.

학습도 완료하였으니 추가적인 과금을 방지하기 위해 NAT 게이트웨이를 삭제하도록 하자.

이미지를 통해 EC2를 생성하고, 서비스를 제공하기 위해 추가적인 설정이 필요하다.

이 경우에 EC2 인스턴스 OS에 직접 붙어야하는데 크게 3가지의 방법이 있다.

- AWS Console Manager에서 다이렉트로 연결
- Key를 사용한 SSH 통신
- AWS Session Manager 설정

ㅁ 콘솔 매니저를 통한 다이렉트 접근

인스턴스 클릭 후, 직접 연결을 통해 붙을 수 있다.

외부에서 접근할 수 있는 Public IP 및 OS User 정보가 필요하다.

※ Linux : ec2-user / Ubuntu - ubuntu

※ Private Subnet에 존재하는 EC2는 Public IP가 존재하지 않기때문에, AWS 콘솔 매니저에서 붙을 수 없다.

ㅁ Key를 통한 EC2 인스턴스 접근

AWS 콘솔을 통한 접근은 편리하지만

Public IP가 없는 Private IP 접근이 어렵고, 로컬 PC기반에서 파일 전송 등의 작업이 안된다.

그래서 Key 인증기반으로 원격접속을 수행하려한다.

공개 - 개인 키 인증방식으로 개인키만 가지고있으면 어디서든 접근이 가능하다.

※ 그래서 키 관리에 더욱 주의해야한다.

AWS Key Pair 인증방식이란?

1. Public Subnet 에 있는 WEB 서버에 Key로 접속하기

2. WEB 서버를 Bastion Host (경유 호스트)로 두어, Public Subnet을 통한 Prviate Subnet 접근

- Public Subnet 에 있는 WEB 서버에 Key로 접속하기

- 먼저, WEB서버 연결을 위한 Key를 발급받는다

- 인스턴스 생성 시, 해당 Key를 매칭해준다.

- PuttyGen을 통해, Public Key를 Private로 변환

- Putty 접속시 해당 Key를 SSH-Auth-authentication에 등록

ㅁ SSM (Systems Manager)를 통한 Session Manager로 접근

인스턴스가 재시작될때마다 Public IP를 새로 받기에, 매번 방화벽을 뚫어주기는 힘들다.
그렇다고 EIP를 받아쓰기엔, 비용적인 부담이 있어 Session 매니저를 사용해보려한다.

[ 장점 ]
1. 키 페어가 따로 필요없다.
2. Bastion Host (경유서버)가 따로 필요 없다.
3. IAM 롤을 통해, 일부 사용자에게만 접속권한 부여가능
4. 443으로 나가는 포트만 뚫려있으면, 특별한 설정이 필요없고 바로 붙을 수 있다.

[ 단계 ]
1. SSM agent 설치 
2. 해당 인스턴스의 443 Outbound 추가. ( SSM이 443 통신임 )
   - 기본적으로 Outbound에 대해선 막혀있지 않을것임
3. IAM에 session manager 역할 생성 ( AmazonEC2RoleforSSM )
4. 인스턴스에 해당 역할 매핑

- WEB ( Public Subnet )





- WAS ( Private Subnet )


인바운드 정책없이 연결 및 Outbound 인터넷 통신 확인

지난장에서 인터넷 통신이 되는 Public 인스턴스를 만들었다.

해당 인스턴스에 Nginx를 설치하여 WEB 서버로 사용하고,

WAS와 DB를 구성하여 연결해보자.

1) WEB EC2 구성

ㅁ nginx 설치 및 구동

sudo apt install nginx
sudo service nginx start

2) WAS용 인스턴스 추가

해당 인스턴스는 실제 로직과 데이터가 담겨있기때문에, Private Subnet에 생성해야한다.

ㅁ 인스턴스 생성

Public과 동일하지만 Subnet 부분과 보안설정은 변경한다

- Subnet : Private

- 보안그룹 : SSH 및 서비스 통신은 WEB서버를 통해서만 받도록 설정

ㅁ NAT 게이트웨이 생성

Private Subnet에 있는 WAS나 DB의 경우

외부에서 접근은 불가능하더라도, 인터넷 사용이 필요한 경우가 있다. ( apt-get , curl 등 )

해당 경우에는 NAT 게이트웨이를 두어, Public subnet 망을 통해서 나갈수 있게 설정해준다.

- 연결유형을 Public으로 두어, 인터넷에 연결 ( Inbound는 차단 )

- EIP (탄력적 IP)를 부여해, 해당 IP로 외부에 통신함.

ㅁ Private 전용 라우팅 테이블 생성 및 연결

Public Subnet의 라우팅 테이블은

10.0.0.0/24 (VPC 내 통신)은 local로 설정되어있어, VPC 내부에서 찾는다.

Private Subnet은 VPC 내부 통신외에, 나가는 요청만 NAT 게이트웨이를 통하므로

라우팅 테이블을 따로 만들어서 할당해야한다.

- local 통신은 동일하게 두고, 인터넷 통신은 public subnet에 있는 NAT 게이트웨이로 통신한다.

ㅁ WAS 인스턴스 환경 구성

- 파이썬 및 Flask 설치

※ Flask : Rest api 구성을 위한 Micro web framework

sudo apt-get update
sudo apt install python3
sudo apt-get install python3-pip
sudo pip3 install Flask

-python 파일 작성 후 구동 테스트

rest.py

- 에러 발생

restx 모듈을 못찾았다. 

해당 모듈 설치 후 재실행

sudo pip3 install flask_restx

- 구동완료

3) DB용 인스턴스 구성

ㅁ PostgreSQL 설치

sudo apt-get update
sudo apt install postgresql 

ㅁ DB 접근제어 허용

PostgreSQL는 기본적으로 접근허용이 막혀있다.

Listen Address에 *를 넣어 접근가능하게 변경해주자 ( 재시작 필요 )

sudo vi /etc/postgresql/12/main/postgresql.conf

sudo vi /etc/postgresql/12/main/pg_hba.conf

ㅁ 데이터 베이스 생성

- DBMS 접속

sudo su postgres
psql
CREATE DATABASE "USER"; // USER 데이터베이스 생성

- USER 생성 및 권한부여

CREATE USER test WITH PASSWORD 'a123456789';
ALTER USER test WITH SUPERUSER;
ALTER USER test WITH LOGIN;

- 해당 유저로 접속 및 Sample 데이터 생성

psql -U test -d USER // test유저로 USER 데이터베이스 접근
CREATE table user_info( id int NOT NULL, name char(20) DEFAULT NULL, PRIMARY KEY (id) );
INSERT INTO user_info VALUES(1234,'kim');
INSERT INTO user_info VALUES(123,'Lee');
commit;

※ psql: error: FATAL:  Peer authentication failed for user "test" 에러 발생

더보기

검색해보니 local 통신 방식에서 perr를 md5로 바꿔주라고 함

 

sudo vi /etc/postgresql/12/main/pg_hba.conf

 

검색해보니 local 통신 방식에서 perr를 md5로 바꿔주라고 함

 

sudo vi /etc/postgresql/12/main/pg_hba.conf

 

앞선 장에서 클라우드 망 구성 및 EC2 인스턴스를 생성해보았다.

하지만 해당 인스턴스를 세팅하기위해 접속시도하면, 접속이 되지 않고 네트워크 세팅을 확인하라는 경고가 나온다.

외부 환경에서 VPC로 접근할때 연결해줄 인터넷 게이트웨이가 없어서 그런 것 같다.

ㅁ 인터넷 게이트웨이

인터넷과 VPC를 연결해주는 게이트웨이

크게 2가지 목적으로 사용된다.

1. VPC 라우팅 테이블에 목적지 추가
2. 퍼블릭 IPv4 주소를 할당된 인스턴스로 NAT(네트워크 주소변환) 수행

1) VPC 라우팅 테이블에 목적지 추가

- VPC 안에 존재한 라우팅 테이블에, 인터넷과 연결할수 있게 경로를 설정해준다.

2) 퍼블릭 IPv4 주소를 할당된 인스턴스로 NAT(네트워크 주소변환) 수행

- 인스턴스 정보를 살펴보면 아래와 같다.

외부에서 접근가능한 IP는 3.38.94.10 이지만, VPC를 구성할때 10.0.0.0/24 네트워크로 구성했다.

퍼블릭 서브넷은 10.0.0.0/25로 할당했으므로, 인스턴스의 호스트IP 범위는 10.0.0.0 ~ 10.0.0.127 이다.

3.38.94.10와 매핑되는 VPC 안의 인스턴스주소는, 프라이빗 IPv4주소인 10.0.0.82 이다.

그래서 3.38.94.10으로 접근한 트래픽에 대해, 10.0.0.82로 접근할수 있도록 해주어야한다.

이때 인터넷 게이트웨이가 NAT(네트워크 주소 변환)을 수행한다.

ㅁ 라우팅 테이블

다른 네트워크끼리 통신할때는 라우터를 통해야한다.

라우팅 테이블에는 목적지에 대한 노선이 담겨있으며, 라우터는 이를 참조해 통신한다.

기본적으로 VPC 內 통신에 대해, 라우팅 테이블이 적용되어있다.

VPC ( 10.0.0.0/24 )에 대한 통신은, 로컬 라우팅을 통해 VPC 내에서 목적지를 찾는다.

그렇다면, 인터넷 통신은 어떻게 연결할까?

인터넷에 대한 통신을 ( 0.0.0.0 ) , 위에 만들어놓은 인터넷 게이트웨이에 연결해주자.

이후 해당 라우팅 테이블에 Public Subnet을 연결해주면

인터넷 - 인터넷게이트웨이 - 퍼블릭 서브넷 통신이 가능해진다.

인터넷에서 Public Subnet에 생성된 인스턴스로 연결까지 마쳤으니, 한번 접속해보자

콘솔을 통해 임시 연결하였으며, 기존의 발급받은 Key를 통해 원격접속도 가능하다.

이번장에서는 간단한 시스템 구현을 통해

AWS에서 제공하는 서비스와 흐름에 대해 알아보려한다.

0) 비용정책 설정

AWS 요금에 대해 조금만 검색하다보면 요금폭탄으로 인한 고민글들이 많다.

계정생성후 제공되는 프리티어 사용 예정이라 큰 요금이 지출되지는 않겠지만

DDOS 공격이나, 미사용 인스턴스로 인한 지속적 트래픽, Key 유출로 인한 사례 등 위험에 노출되어있다.

따라서 가장먼저 비용정책 설정을 통해 사전감지 및 제한을 걸어두려한다.

ㅁ Billing Console에서 예산 설정

- 월 / 30$ : 학습용 시스템으로, 일 트랜잭션이 100회를 넘지않을 것이다.

- 알림 설정 : 25$에 알림 임계치를 걸어, 사전에 인지

                 추후 대량 트래픽 시스템이나, 부하테스트시에는 예산 및 알림설정 변경 예정

※ 악의적인 트래픽에 의한, 요금폭탄을 방지하기 위해 아래의 사항을 명심하자

ㅁ Key 발급 주의

 - 상당수가 Key 유출로 인해, 요금폭탄을 맞는다.

   Git에 소스를 올릴때 자기도 모르게 함께 올리거나 문의글, 블로그 작성중에 노출되기도 한다.

 - 이를 방지하기 위해, Key 사용시에는 IAM을 통하여

   Root , 사용자 키를 나눠서 사용해야하고 Key 관리에 신경써야할 것이다.

ㅁ AWS 콘솔 계정관리

1) 설계

EC2 생성에 앞서, 어떤 아키텍쳐로 구성할지 그려보자

- 리젼 : 해외에서 접속하는 트래픽도 없고, 학습용으로 만드는 시스템. 서울로 지정

- VPC 및 서브넷 : 가상의 클라우드망을 만든 후

                       유저가 접근할 수 있는 Public 서브넷에 웹서버를 두고 인터넷 게이트웨이를 연결한다.

                       WEB으로 온 리퀘스트는 Private 서브넷으로 전달하기 위해

                       Route Table 을 연결하고, WEB에서만 요청을 받기위해 보안그룹 설정을 해둔다.

2) VPC 생성

EC2 및 서브넷들이 포함될 가상의 클라우드 망을 만들어보자.

IP 대역대는 기본으로 추천해주는 10.0.0.0/24를 설정했으며

/24의 의미는 앞의 24비트, 즉 10.0.0 까지는 네트워크 주소로 나머지 비트는 호스트 주소로 사용한다는 뜻이다.

ex) 10.0.0.0 = 10.0.0 네트워크의 첫번째 호스트 주소

결국 10.0.0.0 ~ 10.0.0.255 범위의 호스트 총 256개를 사용한다는 의미이다.

3) 서브넷 생성

클라우드 망을 만들었으니, 유저에게 공개될 Public 서브넷과 Private 서브넷으로 나눈다. 

서브넷(Subnet)은 말 그대로 분할된 작은 네트워크를 의미하며

기존의 네트워크에서 좀더 적절한 단위로 조절한 것이다.

우리는 10.0.0.0 ~ 10.0.0.255 를 사용할 수 있으므로 절반으로 서브넷을 나눌 것 이다.

절반이므로 기존 /24에서 1비트를 더 사용한 /25가 될 것이다.

/25인 이유

Public 서브넷에는 Public IP가 할당될수 있도록, 자동 IP 할당설정을 체크해준다.

위의 VPC에 할당된 서브넷 2개를 만들었다. 현재까지는 아래와 같다.

4) EC2 생성

이제 실제로 서비스가 구동될 EC2 인스턴스를 만들어보자.

우리는 3개의 인스턴스가 필요하다. 1) Nginx , 2) Python [Rest-Api] , 3) PostgreSQL 

ㅁ 이미지 선택

인스턴스를 시작할때 기본으로 사용될 운영체제, 어플리케이션 등이 포함된 이미지를 선택해야한다.

도커 이미지처럼 남들이 만들어놓은 것을 사용하면 편하겠지만, 비용이 발생한다. 직접 만들자..

Ubuntu 20.04 LTS 버전을 사용하였다.

ㅁ 인스턴스 유형 선택

사용할 수 있는 CPU, 메모리, 스토리지 및 네트워킹 용량에 따라 다양한 유형으로 나뉜다.

사용 목적에 따라 그룹이 나뉘며 ( t2, c2, p2, r2 )

세대가 높을수록 최적화가 더 잘되어있다고 한다.

나는 프리티어여서 선택의 여지없이, t2.micro로 선택하였다.

ㅁ 인스턴스 세부정보 구성

해당 인스턴스의 정보를 설정한다.

여러 항목이 있지만 아래 내용만 확인하고 넘어갔다.

- 인스턴스 개수 1 ( Auto Scaling 은 다음장에서 진행 )

- 네트워크 ( 위의 VPC )

- 서브넷 ( 유저가 접속하는 Nignx 용도이므로, Public Subnet으로 할당 )

ㅁ 스토리지 추가

기본적으로 루트 디렉토리가 포함되어있어, 특별한 추가는 하지않았다.

스토리지에는 다양한 종류가 있는데

- EBS ( Block Storage ) : 블록단위의 스토리지. 

- 인스턴스 스토어 : 물리적 디스크로부터 임시로 스토리지를 할당받음.

                         인스턴스 종료시에 해당 스토리지가 회수되므로 데이터를 보존할 수 없다.

- EFS ( File Storage ) : EC2용 파일 스토리지. On-Promise 환경에서 Mount 된 NAS 디스크와 같다고 보면된다.

                             클라우드 환경답게, 사용한 만큼만 용량이 유지된다.

- S3 ( Simple Storage Service ) : 객체 저장 스토리지. 다양한 종류에 객체를 저장할 수 있고, 웹에서도 접근이 가능하다.

                                           Buckets + Key + version 조합으로 접근한다.

ㅁ 태그 - Pass

ㅁ 보안그룹

방화벽 규칙을 어떻게 적용할지에 대한 내용이다.  기본적으로 모든 Inbound 방화벽은 막혀있으며, Out bound는 열려있다.

콘솔에서 OS로 원격접속할 SSH포트 (22) 및 유저가 웹을 통해 접근할수 있도록 HTTP포트 (80)을 열어주었다.

ㅁ 검토

모든 단계를 마치니, AWS에서 경고메세지를 주었다.

해당 인스턴스에 모든 호스트에서 접근가능하다는 내용이었다.

WEB서버는 인터넷망에 오픈이므로 냅두고, 인스턴스 원격접속만 내 IP로 지정해주었다.

ㅁ 키 생성

SSH 설정을 하였더니, 키를 생성하라는 문구가 나왔다.

기존의 Public-Private 키페어 방식이며

키 관리에 자신이 없어 비밀번호로 로그인 할 예정이다.

=> AMI 즉 이미지의 비밀번호를 알아야한다.. 그냥 키쓰자

     생성된 키를 Putty Key Generator를 통해 불러오고, private key로 다시 저장한다.

      해당 키를 사용하여 보안접속을 한다

AWS 시스템을 구축하기에 앞서, 3가지 서비스에 대한 개념을 이해해야한다.

- Network (VPC)
- 클라우트 컴퓨팅 (EC2)
- 엑세스 관리 (IAM)

ㅁ VPC

클라우드의 가상 네트워크 환경.

IP , 라우팅, 게이트웨이 및 보안설정 등을 담당하며, 리전 내에 위치한다.

※ 리전 : 서비스를 제공하는 데이터센터들이 모여있는 위치

리전 내에 위치하나, 가용영역 (AZ) 기준으로 구분하여 여러개의 VPC를 가질 수 있다.

※ 가용영역 : 리전내에 물리적으로 격리되어 있는 데이터센터

ㅁ EC2

AWS에서 제공하는 독립된 클라우드 컴퓨터 서비스.

아마존 머신 이미지 (AMI) 기반으로 인스턴스를 쉽게 생성할 수 있으며,

CPU, 메모리, 스토리지, 네트워크 등의 리소스 사용 목적에 따라 최적화된 인스턴스를 제공한다.

인스턴스 스토어위에서 올라가기 때문에, 종료시 데이터가 사라진다.

저장이 필요한 파일은 EBS에 두고, S3 버킷에 정적 컨텐츠나 로그를 두는 것이 일반적이다.

ㅁ IAM

리소스를 제어할 수 있는 엑세스 권한을 중앙에서 관리하는 서비스

AWS 시스템을 이해하기 위해, 아래와 같은 시나리오로 공부하려한다.

시나리오 1. WEB - WAS - DB 3티어 시스템 구성해보기

기존에 도커를 공부하며 구성해두었던, API 서버 아키텍쳐를 그대로 사용하려한다.

( WEB - 리퀘스트를 WAS 서버로  포트포워딩 / WAS - API 서버 / DB - 업무 데이터 저장 )

예상되는 작업 순서는 아래와 같고, 4/5/6 단계는 시나리오 2에서 진행하려 한다.

1. 리전을 선택하고
2. VPC 생성
3. 퍼블릭 / 프라이빗 서브넷 결정
  + 퍼블릭 : 주로 웹서버로 인터넷에 연결 필요
  + 프라이빗 : 백단 소스, DB 등. 보안그룹 설정필요
4. ELB를 통해 로드밸런싱
5. Auto Scaling 설정 ( Scale up / Sacle out ) 
  + Scale Up은 지원 안하는가?
6. Route 53을 통해 도메인 서비스 제공가능.
7. 비용처리 정책
8. 로깅 정책 -> S3로 저장
9. 백업 정책 -> EBS ( 부팅 및 데이터 볼륨 ) , 스냅샷은 S3에 저장

※ WEB은 Public Subnet, WAS/DB 는 Private Subnet에 두고

   사용자 및 각 인스턴스 간 커넥션을 어떻게 연결할 것인지 생각해보며 진행할 것

시나리오 2. 고가용성 설정 및 부하 테스트, 로그 확인

시나리오 1에서 구성한 시스템에 고가용성 및 서비스를 위한 설정들을 추가할 예정이다.

- ELB : 트래픽 분산
- Auto Scaling : 시스템 부하 시, 서버를 추가하여 서비스 안정화
- Route 53 : DNS 등록

설정 추가 후, 부하테스트를 통해 작동여부를 확인하고 AWS Cloud Watch 를 사용해보고자 한다.

시나리오 3. Iac ( Infrastructure As Code ) 적용

Iac : 코드를 통해 인프라 환경 구성 및 관리 자동화를 수행

      환경 구성 간편화 및 개발/운영간 환경의 일관성이 유지된다.

대표적인 툴로는 AWS CloudFormation, Terraform, Ansible 등이 존재하는데

한번씩 사용해보고 차이점을 서술할 예정이다.