Making Programming Simpler: AWS 2 Tier Arthitecture 설계 (Recklessly HandsOn)

Recklessly Handson for design 2 Tier infra architecture on AWS Cloud.

AWS 클라우드 경험을 남기기 위해 무작정 핸즈온(Recklessly Handson)을 해보려 한다.

먼저 진행할 아이템을 생각나는대로 기술 하고, 스케치 하고 IaC 코드를 짜고 빌드를 해볼 예정 이다.

1. 구성도 스케치

2. 태깅 전략

3. 네트워크 및 보완

1. 구성도 스케치 작업

구성도 스케치를 위해 PPT로 간략하게 스케치 한다. (aws symbol icon 으로 검색하면 템플릿이 나올듯)

Convention 규칙

AWS 에서 제공하는 Symbol Icon 은 리소스의 타입과 Guideline 역시 존재 한다.

표기법이 어렵지 않고 Guideline 을 준수하는 것 만으로 여러 사람들이 쉽게 이해 할 수 있으니 규칙을 따르도록 하자.

"AWS 아키텍처 아이콘" 사이트를 보니 "visual-paradigm" 을 통해 더욱 간단하게 아키텍처를 그릴수 있는 것 아닌가? AWS 최신 아이콘도 이미 적용 되어 있으니 이것으로 시도하는것도 나쁘진 않다.

그리고자 하는 2 Tier 아키텍처 backend API 와 DB(postgresql) 을 배치하는 단순한 시나리오이다.

주요 특징으로

api 인스턴스는 2개가 서로다른 AZ 존에 배치되어 하나가 죽더라도 정상 서비스 되도록 구성 한다.
외부 접근을 막기위해 private subnet 에 API와 DB 서버를 배치 하였다.
보안 그룹을 통해 API와 DB 서버에 대해 필요한 서비스 포트만 열어 두어서 보안을 강화 하였다.
API 인스턴스의 탄력적인 확장이 가능 하도록 타겟 그룹을 설정 하였다.
애플리케이션 로드 밸런서를 두어 외부의 트래픽 유입량에 탄력적으로 대응 하도록 하였고, Gateway API 와 같이 URI 패턴에 대응하는 서비스 라우이팅이 가능 하다.
public subnet 은 인터넷 게이트웨이를 통한 인터넷 액세스를 지원 한다.
private subnet의 인스턴스는 NAT 게이트웨이를 통해 인터넷을 액세스 할 수 있도록 지원 한다.

2. 태깅 전략

AWS와 같은 클라우드 벤더가 제공하는 서비스와 구성 할 수 있는 리소스는 너무나 많아서 효율적인 관리 전략이 필요 하다.

가만히 생각하면 아래와 같은 중요한 컨디션이 있다.

리소스마다 Key, Value 형태의 태그 정보를 입력함으로써 위의 주요 고려 사항을 해결 가능 하다.

아래 링크를 참고 하자.

그리고 아래는 리소스 태깅 샘플 이다.

3. 네트워크 및 보완

네트워크를 구성 할 때 애플리케이션 인스턴스는 private subnet 에 배치 하도록 한다.

각각의 애플리케이션을 위한 보안 그룹을 설정 하자. (보안 그룹은 기본이 50개 한정 이다).

외부 사용자로부터 인터넷 접근을 처리하는 ELB는 인증서(TLS)를 발급 및 적용 한다.

jumphost 와 같은 터널링을 통한 외부 접속을 위한 베스천을 두지 않는다.

Access Key 와 같은 Credentials 정보는 외부 유출이 안되도록 각별히 조심 한다.

IAM 정책을 위해 사용자 및 역할을 구분 하고 제한된 policy 를 구성 한다.

의도적으로 무작정 핸즈온을 시도 했는데 시간이 상당히 많이 걸렸다.

simple 하고 싶은데 심플 하지 않게 되었다.

Making Programming Simpler