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

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

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 인터넷 통신 확인

2달에 걸쳐 읽게 된, 철학의 '교과서'

읽기전

이 책을 선택한 이유는 간단했다.

읽을만한 책을 찾아보던 도중 '철학 입문서' , '전 세계적으로 많이 번역된 책 Top 17' 같은 키워드에 끌려 주문하였다.

베스트셀러나 명저로 불리는 책들을 좋아하는데, 간접적으로 재미가 검증되기도 하였고

좀 더 많은 사람들이 이 책을 읽었을 확률이 높기 때문이다.

후기들을 리뷰하고, 책에 대해 토론하며 나와 다른 생각과 해석을 통해

책을 여러방면에서 즐길 수 있기에 최우선적으로 고려하는 항목이다.

철학 / 심리학에 관심도 있던 때라, 나에게 안성맞춤인 책이라고 생각되었다.

읽으면서

먼저, 왜 2점을 주었는지와 한줄평에 적었던 내용을 이야기하고자 한다.

책에서는 철학에 대해 2가지로 나누어 설명했다.

나는 후자의 철학을 통해 나의 가치관을 다듬고 싶었으나, 책의 내용은 전자였다.

고대 철학부터 현대에 이르기 까지, 영향을 받았던 시대적 배경등이나 흐름을 잘 설명해주어 이해가 빠르긴 하였다.

또한 소설의 형식을 취해 지루하지 않게 읽을수도 있었다.

하지만 최종적으로 내가 얻게되는건

영감이나 좀 더 깊은 차원의 생각들이 아닌, OO의 사상과 이론같은 정보들 뿐이었다.

교과서같은 책이라고 요약했지만, 바이블의 의미로 사용한 것이 아니었다.

윤리교과서의 등장하는 철학가들의 사상을 글로 풀어쓴 느낌이 들어 '교과서'라는 표현을 썼다.

물론 접근하는 방법에 따라, 어떻게 받아들이냐에 따라 유용하게 읽을 수 있을 것 같다.

하지만 나의 경우는 원하는 목적이 명확했고, 기대감이 컸던 탓인지 책의 흥미를 붙이기가 쉽지 않았다

게다가 700쪽에 달하는 방대한 분량에, 쉽게 손이가지 않은 것도 있다.

몇번이나 포기할까 했지만

후반부에 소설다운 반전이 있다는점과, 여태까지 읽은게 아쉬운 점, 블로그에 책 리뷰를 완성하고 싶어 놓지 못했다.

그러다보니 2~3달에 걸쳐 겨우 읽게되었다.

잡생각

책에 대한 느낀점은 위에 내용들이 전부이다.

다만 책의 내용과는 관계없이, 읽고나서 느꼈던 것에 대해 작성해보려 한다.

한 유튜버가 했던 말이 기억에 남는다

' 대충하고 견적봐서 미치세요 '

갑자기 뭔소리지 라고 생각할 수 있으나, 이 책을 읽어오며 겪었던것과 동일하다.

어떨지 예상이되고 끝이 상상되었지만

다 읽고나면 나랑 맞는책이 아닐까? 라는 긍정적인 상상과

중간에 그만두어 버리면, 끝을 보지못했다는 찝찝함과 아쉬움. 가능성을 저버린 느낌이 들어 멈출 수 없었다.

하지만 보는 도중에도 억지로 책장을 넘기는 느낌이었고

설사 마지막에 나와 맞다는것을 느껴도, 다행이다 정도였을 것이다.

결국 안맞았던 지금에서는 시간만 아까울뿐이다.

대충하고 견적보라는 말은, 무책임하게 들릴수도 있다.

하지만 선택과 집중이라는 말이 있듯, 세상에는 다양한 기회들이 있다.

책만 하더라도 읽지못한 책들이 평생에 걸칠만큼 남아있고, 인생도 마찬가지다.

억지로 결말을 보지말고

운이 따르는것. 나에게 맞는것. 시도자체가 즐거운 것들만 해도 기회는 충분하며 오히려 성공확률도 높다고 생각된다.

또한 잘 안되더라도 순간의 만족을 떠올리며 후회하지 않을 것 같다.

다양한 시도를 하지만, 아닌거 같다 싶으면 운이 없었다며 빠르게 털어내는 사람이 되고싶다.

이제는 한우물만 파서 노력으로 성공하는 시대가 아닌, 내가 잘 팔수있는 우물을 찾는거부터 시작이라고 생각한다.

지난장에서 인터넷 통신이 되는 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 등이 존재하는데

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

풍부한 표현력으로 그림을 읽는것 같은 책. 다소 아쉬운 마무리

읽기 전

1Q84를 통해 알게된 무라카미 하루키였고, 워낙 유명한 작품이라 기대가 되었다.

하지만 첫 장을 펴고난 뒤에는 조금 실망감을 감출 수 없었다.

작가의 말 마지막에 담겨있던 몇십년 전 날짜가, 이 소설에 대한 이미지를 바꾸어버렸다.

근 5년간 베스트셀러를 기대하고 집어들었는데, 토지같은 현대소설 초창기 작품을 받은 느낌이었다.

그래도 객관적으로 인정받고 있음은 불변한다는 기대 반과

당시 시대적 상황이나 감성이 지금에도 통할까? 라는 불안 반으로 읽기 시작하였다.

읽으면서

첫 문장을 읽자마자, 불안감은 날아갔다.

주인공이 비행기에 내려 독일 공항에 도착하는 단순한 장면이지만,

1인칭 시점에서 시선이나 느낀점들을 세세하게 표현해주어 글이 아닌 그림을 읽는 느낌이었다.

주인공이 바라보는 풍경이나 느낀점들을 상상하며 읽어지고, 술술 읽힌다는 표현이 맞는것 같다.

1970년대 독일 공항에 가본 경험은 없지만, 다양한 비유법으로 비슷한 경험들을 끌어모아 주인공과 같은 시선을 가지게 해주었다.

특히 처음에 읽으면서 느꼈던 것은 다양한 감각적 요소를 자극한다는 것이었다.

풍경을 묘사하다가 갑자기 옆에서 나는 다양한 냄새들을 느끼게해주고, 청각과 촉각적 요소들도 포함해 내가 주인공이 된 느낌이었다.

이러는데 책에 몰입되는 것은 당연했다.

몰입하여 읽을 수 있는 책을 싫어하는 사람은 드물겠지만, 나같은 경우는 특히 더 좋아한다.

독서량이 많지 않은 나로서는, 한번더 생각이 필요한 책보다 받아들여지는대로 이해하는 책들이 더 반가운법이다.

또 하나의 장점으로는 그림을 읽듯 빠르게 읽어나가기 때문에

정신없이 읽다보면 지나온 몇 백페이지의 두께에 성취감이 드는 것이다.

기억나는 장면 두 가지

먼저 여주인공 '미도리'가 주인공에게 얼마만큼 사랑하냐고 묻는 장면에 봄날의 곰처럼 좋다는 표현이 있다.

실제로 입밖에 내기에는 오그라드는 말이지만,

무슨 대답을 하던 감흥이 없을것 같은 질문에 센스있게 답을 했던 내용이라 기억에 남는다.

그리고 당시에 감정선을 잘 표현하는 문장인 것 같다.

주인공이 책을 즐겨보는 인물로 나오는데,

현상에 대해 다양하게 표현을 할 수 있는 독서가의 매력을 잘 표현했다고 생각된다.

다른 하나는 주인공이 '나오코'와 '미도리' 사이에서 갈등하는 부분이었다.

부부의 세계에서 '사랑이 죄는 아니잖아' 라는 장면이 순간 떠올랐지만, 처음부터 읽어온 사람이라면 그렇게 생각하지 않을 것이다.

감정선이 최고점에서 살짝 내려간 나오미에 대한 마음과,

점점 올라오던 미도리에 대한 마음이 만나는 지점이었는데 그동안에 감정선이 꽃이 피는 장면이라고 생각된다.

주인공의 갈등 또한 노골적으로 나타나고 있었고, 다음 장을 빨리 넘기고 싶은 마음이었다.

그래서 결말이 아쉬웠다.

물론 여운이 더 남는다는 점에서 열린결말에 대해 긍정적이나, 절정단계에서 개연성 없이 뚝 끊어버린 느낌이다.

독자들에게 충분한 시간과 표현을 들여서 해당 장면까지 끌고왔는데

이어져온 감정선은 오간데 없이, 날카로운 칼로 자른것 처럼 깔끔한 단면선이 아무것도 남지 않게 하였다.

책을 덮은뒤에 기억나는 것은, 어디인지 모를곳을 헤매는 주인공의 모습이다.

작가는 무언가를 상실하고, 갈피를 못잡으며 헤매고 있는 우리들을 보여주고 싶었던 것일까?

의도는 좋았으나 급작스레 끊어져버린 감정선이 아쉬움을 남긴다.

한편으로는 애처롭게 헤매고 있는 주인공의 상황을 더욱 부각시켜주는 장치로, 짜임새 있는 결말이라고 생각할 여지도 있는 것 같다.

총평

먼저, 풍부한 표현력이 나에게 가져다주는 생각들이 있었다.

근 몇년간 취직과 회사생활을 하면서 간략함이 강조되는 환경속에서 살아왔다.

보고서나 메일에는 두괄식으로 핵심을 강조하고, '그래서 결론이 뭔데?' 라는 말을 들을정도로 간단함이 중요시 된다.

물론 모든 업무에 있어 빠른 의사결정으로 행동하는것이 중요하지만, 업무외에도 그럴 필요가 있나 싶다.

요약하고 핵심을 찾는 능력은 늘고있지만, 조그만 것에서 많은 것을 발견하고 느낄수 있는 것들에 대해서는 반대로 잃어가고 있다.

현상에 대해 단순하고 간단하게 생각하고, 순간만을 기억한다면 모든것이 무미건조해지고, 세상이 흑백으로 바뀌는 느낌이다. 

다른사람에게 전달할 때도, 그때의 현상이나 감정을 100% 전달할 수 없다.

나 또한 숨겨져있는 즐거움들을 놓쳐가며 살게 될 것 같다.

풍부하게 생각하고 표현하려는 노력이 필요하다.

그리고 몇 십년전 감성과 시대적 배경이 지금에서도 통할까라는 의문에 대한 해소도 있다.

하지만 이 책이 오랫동안 읽어져온 이유는, 시대와 상관없이 삶을 살아가는 모든이에게 적용되기 때문이라고 생각한다.

삶과 죽음, 사랑에 대해 고민하고 겪어왔던 모두가 공감하고 생각할 거리가 있는 책이었다.

주인공을 통해 삶 속에서 방황하는 우리들을 위로하려는 것 같기도 하다.

책을 읽다가 죽음에 대해 생각거리를 던져준 문구를 소개하며 후기를 마친다.

죽음은 삶의 대극이 아니라 그 일부로 존재한다