인생무엇

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

앞선 Django(1/2) 초기에 말씀드린 것과 같이.

모놀로식 아키텍처를 한번 배포해보고자합니다.

앞서 기본적으로 알아야되는게 Django를 이용하고 인프라는 당연히 AWS를 사용하려고 합니다. 

그런데 Django에 대해서 들어만 봤지. 실제로 써보지 않았기 때문에 강의에서 설명해주는 듯 합니다. 

https://docs.djangoproject.com/ko/3.2/intro/tutorial01/

관리자 생성하기

python manage.py createsuperuser

> 장고에서는 어드민관리해주는 게 따로 있습니다. 

> 127.0.0.1/8000/admin 을통해서 접속이 가능합니다.

> urls.py 에서 urlpatterns에 path 설정이 어떻게 되있나 확인하면 됩니다. . 모든지 URL 정보가 여기에 담겨있습니다.

> 기본적이 구성이 잘 되어있습니다. 

> 관리자 페이지를 왜 필요한가? >> 모든걸 계속 코드로 관리할 수 없기 때문에. 

> 관리자 페이지에서 정말 손쉽게 데이터를 관리할 수 있게 잘 되어 있습니다. 

> admins.py에서 register로 사이트를 등록하게되면 쉽게쉽게 적용해서 활용할 수 있습니다. 

> 데이터베이스를 직접 코드로 관리하지 않아도 관리자 페이지에서 쉽게 관리가능합니다. 

뷰 추가하기 

강의에서도 주어진 코드를 활용했습니다.

> html에 대한 약간의 지식과 JSON, 기본 문법 등을 조금이라도 알아야 이해가 될 것 같네요.

> 처음 들으시는 분들은 변수가 넘어가고 배열이 나오고, 반복문, 조건이 나오고 이런 부분을 어려워할 거 같습니다.

> 뷰라는 건 말 그대로 보여지는 페이지에 대한 구성을 합니다. 

> 우리가 쓰는 웹페이지에서 F12를 눌렀을때 보이는 그런 코드들을 만든다고 보시면 됩니다. 

> Django로 프론트부터 백앤드까지 다 할 수 있다는걸 느낄 수 있습니다. 

> 진자언어? 를 사용하기 위해서는 {% 명령어 입력 %} 형태로 이루어 져있습니다. 
   저 명령어에는 for if  등을 넣어주면됩니다. 

> 데이터베이스에 없는 값이 입력될 경우에 404에러가 뜰 수 있도록 설정되야합니다.

> 템플릿을 등록해서 사용할 수도있습니다. 

하드코딩된 URL 제거하기

> 일반적으로 경로 등을 코드상에 하드코딩하는것은 좋지 않습니다

> 하드코딩 한줄에 연봉 300만원 삭감해야합니다. 

> 진자언어(?) 형식으로 변경합니다. {% url '이름' question.id %} 이런형식으로. 

form

> form 문을 이용해서 라디오버튼이 생긴다든지. 뭐 .. 이런 형태로 변경이 가능합니다. 

전반적으로 이해는 다 가고, 장고로 모든 페이지를 만들고 디비를 컨트롤 할 수 있는것 까지.. 알게되었습니다.

내용을 다 줄줄 쓸 수 없고, 실제로 따라해보는게 좋을 것 같네요.

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

모놀로식 아키텍처를 한번 배포해보고자합니다.

앞서 기본적으로 알아야되는게 Django를 이용하고 인프라는 당연히 AWS를 사용하려고 합니다. 

그런데 Django에 대해서 들어만 봤지. 실제로 써보지 않았기 때문에 강의에서 설명해주는 듯 합니다. 

https://docs.djangoproject.com/ko/3.2/intro/tutorial01/

해당강의는 위 링크를 따라하면서 진행했습니다.

Django 설치하기.

모든 개발에 있어서 환경설정이 필수인것을.. 본인은 다 깔려있다고 하고 그냥 넘기네요.. 

후.. 

https://docs.djangoproject.com/en/2.0/topics/install/#installing-official-release

저의 경우는 

코드들을 모아두는 폴더가 따로 있습니다.

python --version

>> 3.7.5 

설치가 되어 있었고. 

cd /폴더경로

mkdir fastcamp-1

cd fastcamp-1

생성한 이후 

pip install Django 

를 통해서 Django를 설치했습니다. 

python -m django --version

>> 3.2.9

프로젝트 생성하기

django-admin startproject mysite

명령어를 통해서 Project를 생성합니다. 프로젝트명은 mysite 부분을 변경하면 가능합니다. 

좌측 사진과 같이 프로젝트가 생성되면서 기본 파일들이 생성됩니다. 

그렇기 때문에  해당명령어를 통해서 프로젝트를 생성합니다. 

1. manage.py : 서버를 운영하는 파일 서버 런, 스탑 .. 같이 진짜 메인. 중요한업무 시행

2. settings.py : 장고의 다양한 셋팅을 확인할 수 있고, 변경할 수 있음
                    디비를 변경할때 DATABASES = 부분을 변경할 필요가 있음. 

3. urls.py : URL 관련 행위를 모두 다함. 

서버 시작하기 

python manage.py runserver

명령어를 통해서 실행 할 수 있습니다. 

성공해서 127.0.0.1:8000 접속을하면 로그들도 쭉 뜨는 걸 확인 할 수 있습니다. 

설문조사 앱 만들기

python manage.py startapp polls

명령어를 실행하면 아래 사진과 같이 새로운 polls라는 폴더가 생성되면서 기본 코드들이 들어갑니다. 자동으로

models.py 라는 파일은 

> 데이터베이스라고 생각하면 됩니다. 데이터에 접근하기 위한 그런 클래스 형태를 통해서 디비를 변경 CRUD를 진행합니다. 

views.py 파일은

> 사용자가 버튼을 클릭했을 때 나오는...백에서돌아가는 알고리즘,로직들을 관리하는 그런 파일.. 

urls.py와 views.py 파일을 통해 

url의 값에 따라 어떤 페이지를 보여줄지를 정할 수 있게 됩니다. (urlpatterns path에서 설정)

데이터베이스 설치

python manage.py migrate

>> 설명이 딱히 없네요.. 

모델 만들기

models.py : CRUD를 할 수 있는 클래스를 정의한다. 

데이터베이스의 개념이 필요하며, 클래스 내부의 변수선언이 스키마 설정이면서 Foreignkey 설정 등을 합니다. 

장고에서 마이크레이션하는게 엄청 편한것 같습니다. 

models.py의 형식에 맞춰서 금방 되는 형식이네요. 

설명을 쓰기가.. 어렵네요.. 

위에 페이지가 있으니까 그대로 따라해보면 좋을 것 같습니다. 

manage.py 파일이 main이다보니까 모든 실행시에 해당파일을 기준으로 migrate 할지 어떤 동작을 할지 입력하네요.

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

모놀리식 아키텍처 VS 마이크로서비스 아키텍처

Monolithic을 한국어로하면 "획일적인, 하나의, 단일체의" 이라고 해석이되고

Micro를 한국어로 하면 "소형의, 아주 작은것, 극소의"로 해석이됩니다. 

이런 아키텍처 설계?는 과거에서 부터 두 종류가 있었던것 같습니다. 

그러나 빨리빨리를 좋아하는 한국인의 특성상 과거에는 모놀리식 아키텍처를 그려서 서비스를 제공했다고 하면, 요즘에는 마이크로서비스 아키텍처라는게 더 많이 화두가 되고 있습니다. 

최근 개발자 채용 JD를 보면 많이 느낄 수 있습니다. 

마이크로서비스 아키텍처 설계가능자, 클라우드에서 서비스 개발을 해본사람, 쿠버네티스 할 수 있는 사람.. 등

앞선 맨 첫 강의에서도 DevOps 팀의 핵심지표로 배포빈도(Deployment Frequency)를 중요시하는게 

이 마이크로서비스 아키텍처가 최근의 트렌드인 것을 볼 수 있습니다. 

맞는지 모르겠지만

마이크로서비스 아키텍처는 각각의 작은 기능들을 구분(?), 독립적으로 서비스를 띄워두고, 각각의 통신은 API를 통해서 하는것 같습니다. 

그래서 API 설계가 중요하고.. AWS도 마찬가지로 모든 기능을 콘솔에서 하는게 아니고 API로 가능한 걸로. 알고있습니다.

이런 관련 글들을 어디서 본적이 있는데.. 어떤글인지는 모르겠습니다.

아무튼 API가 엄청 중요하다. 라는게 결론..

강의에서는 이런 내용들이 나오진 않았지만 강의랑 강의자료에 있는 내용들은 일반적으로 알 수 있는 내용들이였습니다. 

프로젝트 구성원들 역할

해당 내용들은.. 강의자료가 따로 없고, 강의 내용만 있네요.

프로젝트를 일반적으로 진행 할 때, 구성원들을 보면

- 기획자 

- 마케터

- 개발자

- 디자이너

- PM 

구성원들은 조금 씩 다를 수 있지만, 일반적으로 위의 구성원들로 프로젝트가 진행 됩니다. 

각각의 역할이 있기 때문에 프로젝트를 설계할때, 또는 진행이 될 때 트러블이 많이 생깁니다. 

각자의 도메인 지식이 다르고, 서비스가 복잡해지면 복잡해 질 수록 기획과 개발의 불일치가 발생하고, 

각자의 언어가 달라 소통도 어려워지는 문제가 있습니다. 

그에 대한 해결방법으로, 보편적인 언어(모두 이해하는 말로하자, 전문용어 쓰지말고)를 쓰고,

모델 주도 설계를 하자는 것입니다. 

모델 주도 설계가 뭔가 딱 아직 와닿진 않지만, 이내용이 밑에서 설명할 DDD에 대한 내용과 같습니다. 

프로젝트 설계 방법론

DDD (Domain Driven Design) : 도메인 주도 설계에 대한 내용이였습니다. 

도메인이라는것이 IT를 하면서 많이 들어봤지만, 뭔가 참 범위가 엄청 큰 부분 같습니다. 

- 전략적 설계

일어날 수 있는 모든 경우를 생각해서 공유하고, 이것을 그룹핑합니다.

그리고 이 그룹핑간의 관계를 정의하여 도메인 모델을 생성합니다. 

-전술적 설계

그룹핑 한 내용을 더 상세히 모델링하고 Aggregate Pattern을 많이 생각한다고 하는데.. 뭔소린지 잘 모르겠습니다.

https://huisam.tistory.com/entry/DDD

https://ppiyo5.tistory.com/21

https://brunch.co.kr/@springboot/605

위 블로그들에서 내용들이 자세히 잘 나와있습니다. 

도메인 주도 설계라는 것을 들어 봤으니, 해당 강의에서 정말 상세히 다 이해하기보다. 대강 이야기 듣고, 관심 있는 부분은 조금 더 찾아 봐야할 것 같습니다. 

강의에서는 굉장히 짧게 이야기했지만 엄청 복잡합니다. 

결론적으로는 각 프로젝트인원들의 도메인이 다르고. 그걸 이용해서 경우의 수를 다 나열하여 그룹핑 하여 그 관계를 정의하고,  모델링하여 그 것을 바탕으로 구현하자!

로 이해했습니다. 

강의는 이제 모놀리식 아키텍처를 기반으로 빠르게 한번 배포도해보고, 추후에는 마이크로서비스 기반으로 배포해보고 CICD까지 가는 것 같습니다. 

강의구성은 참 좋은 것 같네요.

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

Bastion 실습 

>> 해당 그림을 바탕으로 실제로 테스트를 해봤습니다. 

이 테스트를 하면서 처음에는 Bastion에서 Private EC2에 접속을 못했습니다. 

그래서 원인을 찾아보니. 처음에 위 그림에서 빨간색 표시가 있는 NACL에서의 설정 문제가 있었습니다. 

Private subnet NACL은 인/아웃바운드 ANY OPEN으로 해두었고, 

Public subnet NACL은 아웃바운드 ANY OPEN, 인바운드는 22번만 OPEN 해두었습니다. 

그런데, NACL은 stateless 형식인 것과 TCP는 3way handshake를 한다는 것을 이해하면서 

Public subnet NACL에 대해 인바운드 22 OPEN 해둔것이 문제였다는 것을 파악했고, 

모든 NACL에 대해 인/아웃바운드 ANY로 open하니까 정상적으로 연결이 가능했습니다. 

syn을 보낼때는 22port로 정상적으로 들어왔지만 

synack이 갈때는 syn에서 들어온 source port가 22번이 아닌 random이기 때문에 22번만 열었을 경우에는 통신이 정상적으로 되지 않았습니다. 

결론적으로 말하자면, 

Bastion을 통해 Private EC2에 접속할 때 SG와 NACL의 설정을 모두 고려해야한다.

그럼 NACL은 언제 쓰냐?

차단해야하는 대역대가 있을 경우 일반적으로 사용한다고합니다. 

AWS에서도 NACL은 차단대역대가 있을 경우에 사용한다고.. 말했던거 같네요. 유투브 영상에서

또한 NACL은 설정할 수 있는 규칙이 20개입니다... 

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

VPC도 그렇고, IGW, 라우팅테이블 등 다 무한대로 생성할 수 있는게 아닙니다. 

모든 자원에 limit값이 정해져 있으니까 문서를 보고 알아두는 것도 좋을 것 같습니다. 

또 이 작업을 하면서 들었던 궁금점이 

Router가 하나인데 라우팅테이블이 2개가 있는게 맞는건가?

일반적으로 Subnet 당 라우팅테이블을 하나씩 넣어준다고 합니다. 

NAT Gateway

아키텍처좀 그려주고 설명해주면.. 좋겠지만.. 그러지 않습니다. 

NAT GW를 사용하면 private안에 있는 EC2에서 인터넷을 사용할 수 있습니다. 

예를들어 yum install mysql 같이.. 다운로드가 가능합니다. 

NAT Gateway는 Public Subnet 상에 위치해 있어야하며,

Private Route Table에 0.0.0.0/0 일경우 NAT GW로 라우팅 될 수 있도록 설정이 필요합니다. 

VPC EndPoint

VPC 엔드포인트를 사용할경우 EC2인스턴스에 'IAM사용' 설정을 통해 필요한 권한의 ROLE을 부여해줘야합니다. 

s3에 접근할 수 있는 권한을 가진 role을 부여하는 것 처럼.. ec2 인스턴스를 생성할 때 붙여줍니다. 

그리고 VPC EndPoint를 생성해주고,

VPC EndPoint는 2가지 종류가 있습니다. GW, Instance방식 으로 구분을 지을 수 있으며 강의에서는 GW방식으로 했습니다.

VPC EndPoint는 꼭 Public에 있지 않아도 되고, Private subnet에 있도록 설정했고, 

설정 후에는 Private Routetable에 자동으로 라우팅테이블이 생성되는걸 확인할 수 있습니다. (시간이 조금 걸림..)

>> S3와 관련된 트래픽이 오면 해당 대상으로 보내라.. 이런건데 자동으로 생성됩니다. 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

NACL vs SG

NACL 과 SG에 대해서는 앞선 7일차 포스팅에서도 써놨었습니다. 

이번 강의에서는 조금 더 자세히 설명을 해주었습니다. 

NACL은 Stateless 방식이면서 VPC의 방화벽 역할을 합니다. 
우선순위를 정해서 인바운드, 아웃바운드를 설정할 수 있습니다. 
(일반적으로 우선순위 정할 때 100단위로 한다고 어디선가.. 들었습니다.
왜나면 그래야 나중에 중간에 다른 규칙이 필요할때 쉽게 넣을 수 있어서.. 라고 합니다.)

SG는 Stateful 방식이면서 인스턴스의 방화벽 역할을 합니다.
EC2와 같이 SG를 설정할 수 있는 인스턴스들이 있습니다. 말단의 인스턴스들의 방화벽 역할을 한다고 생각하면 편합니다. 이 SG는 우선순위를 정하는 건 없이 인바운드, 아웃바운드 규칙을 설정 할 수 있습니다. 

Stateless 방식과 Stateful 방식을 설명해주었습니다. 

아웃바운드가 ALL Deny라고 가정하면, 

NACL 의 경우 Stateless 방식으로 외부에서 request가 와도 response를 해 주지 않습니다.

SG의 경우 Stateful 방식으로 외부에서 request가 오면 그 상태를 기억하고 있기 때문에 ALL Deny 정책을 가지고 있어도 response를 해줍니다.

그리고 NACL은 앞서 이야기한데로 우선순위가 있습니다.

100 HTTP 80port Allow 설정을 해두고, 

101 HTTP 80port Deny 설정을 했을 경우에는

>>>> 100 HTTP 80 Allow가 우선순위가 높기 때문에 101 HTTP 80 Deny가 있어도 Allow 됩니다. 

자동할당 IP설정

강의도중에 자동할당 IP설정하는 부분이 있습니다. 

public subnet의 경우에는 퍼블릭 IP자동할당이 되어있을경우 인스턴스 생성시 기본설정으로 되어 있어서 편리하다? 라는 장점이 있지만.. 

보안상으로는 추천하지는 않습니다. 퍼블릭 공개되는 인스턴스가 있을 경우에는 물론 따로 관리가 필요하며, 외부침입의 표적이 될 수 있습니다. 

그리고.

httpd 설치를 통해 SG, NACL설정에 대해서 실습을 해주셨지만.. 사용자 데이터부분에 bash 명령어 사용하는부분이 어려운게 아닌데.. 그냥 따라하라고 하는 부분이 뭔가 아쉽네요.. 

사용자 기본이 ec2-user인데.. 에러난거에 대한 설명을 안해주는것도 좀 아쉽네요.

Bastion에 대해서

강의에서는 앞서서 Bastion에 대해서 설명했기 때문에 그냥 단순히 설정하는 것을 보여줬습니다. 

Priavate Subnet의 SG를 설정할 때 Public Subnet의 SG를 설정할 수 있습니다. (IP를 꼭 안넣고, SG를 넣어도 됩니다.)

SG를 설정할 때 CIDR, IP 또는 보안그룹을 입력해서 설정할 수 있습니다.

그런데 이 강의에서.. 조금 아쉬운점이 있다면. 

아키텍처를 그려놓고 설명을 해주면 좋았겠다... 라는 생각 

강의에서 설명은 위 사진에서 빨간색 화살표 (-->) 처럼 접근이 된다고 설명을 했지만 .. 

제가 생각하기에는 녹색 화살표(-->) 처럼 흐르는게 맞는게 아닌가... 

그런데 강의자료에서도 해당 아키텍쳐가 그려져있지 않네요. 위 아키텍처가 맞다면 그냥 SG만 설정해줄게 아니고 NACL도 설정해주는게 맞는거 같은데.. 갑자기 햇갈립니다. 

내일 한번 테스트를 진행 해 볼 예정입니다. 포스팅 시간이 늦었기 때문에.. 

NACL을 따로 설정안해줘도 되는건가..? 해줘야되는거같은데..

내일은 NAT GW와 VPC Endpoint에 대해서도 다 이해할 수 있을지 모르겠지만 한번 해보도록 하겠습니다. 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

AWS VPC (Virtual Private Cloud)

VPC는 가상네트워크라고 되어있는데, 그냥.. 클라우드에서 네트워크를 구성하는 AWS서비스라고 이해하면 편할 것 같습니다. 

앞선 포스팅에서도 VPC에 대해 언급한적이 있지만 계정생성시 defalut VPC가 자동으로 생성되고, default VPC를 사용하지 않는것을 권고드린다고 이야기 했었습니다. 

VPC 서비스 내에서도 

세부 기능들이 많습니다. 

이번강의에서 알아볼 아키텍처는 다음과 같았습니다.

앞서 배웠던 CIDR과 서브넷의 개념을 정확히 알고 있어야했고,

리전과 AZ에 대한 것도 알고 있어야합니다. 

1개의 리전에는 다수의 AZ가 존재하며, 1개의 AZ안에 다수의 VPC(subnet)가 설정될 수 있습니다.

Internet gatewat (IGW)

일반적으로 줄여서 IGW라고 이야길 합니다. 

IGW가 붙어있으면 Public subnet, IGW가 붙어있지 않다면 Private Subnet이라고 합니다. 

인터넷과 통신을 할 수 있고, 라우팅테이블에서 설정을 해줘야합니다.

NACL vs SG

Network ACL을 줄여서 NACL이라고 이야기를 합니다. 

이 NACL과 SG의 비교에 대한 내용은 검색해보면 많이 나옵니다. 

강의에서는 조금.. 이해하기 힘들었을것 같은데, 검색을 통해서 자세히 알 수 있습니다. 

간략히 이야기하면 

NACL은 Stateless 방식이면서 VPC의 방화벽 역할을 합니다. 

우선순위를 정해서 인바운드, 아웃바운드를 설정할 수 있습니다. 

(일반적으로 우선순위 정할 때 100단위로 한다고 어디선가.. 들었습니다.

왜나면 그래야 나중에 중간에 다른 규칙이 필요할때 쉽게 넣을 수 있어서.. 라고 합니다.)

SG는 Stateful 방식이면서 인스턴스의 방화벽 역할을 합니다.

EC2와 같이 SG를 설정할 수 있는 인스턴스들이 있습니다. 말단의 인스턴스들의 방화벽 역할을 한다고 생각하면 편합니다. 이 SG는 우선순위를 정하는 건 없이 인바운드, 아웃바운드 규칙을 설정 할 수 있습니다. 

그런데, NACL도 설정하고 SG도 설정 해야하는 이유가 뭘까요..?

음.. 아직 딱 뭔가 정확한 답은 못내린 상태입니다. 

NAT (Network Address Translation) Instance / gateway

이 강의에서 한 내용으로는 100%이해하긴 힘들것 같습니다.. 

일단 Private subnet에서 외부의 Internet과 통신하기 위한 방법으로 사용한다. 정도로 이해하고, 추후 강의를 좀 봐야할 것 같습니다. 

물론.. 인터넷 검색하면 내용은 다 나옵니다.. 

Bastion Host

이렇게 정말 많은 분들이 사용하고 있는걸로 알고 있습니다. 

저도 실제로 이렇게 사용하고 있습니다. 

Bastion host를 사용하는것도 여러 장점이 있지만, 생각해보면 Bastion을 두게되면.

Bation이 큰 보안의 Hole이 됩니다. 

과연 Bastion을 사용해야하는지.. 생각해봐야하고, SSM도 고려를 해볼 필요가 있습니다. 

VPC Endpoint 

AWS의 여러 서비스하고 VPC하고 연결시켜주는 역할을합니다. 

Interface endpoint와 Gateway endpoint로 구별할 수 있습니다. 

그런데 이런 VPC endpoint는 IGW나 NAT GW를 거치지 않고 Private subnet에서 다른 서비스랑 연결할 수 있으니까..

보안상으로는 취약한 요소이긴합니다만 필요한 기능이기도하죠.. 

관리가 적절히 필요하다고 봅니다. 

VPC를 만들면 

자동으로 함께 생성되지 않는것

서브넷

인터넷게이트웨이

엔드포인트

NAT게이트웨이

자동으로 함께 생성되는것

라우팅테이블

NACL

보안그룹

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

2번째 챕터?인 AWS기반 소규모&중규모 아키텍트설계를 시작했습니다. 

클라우드를 왜 쓰는가? 

클라우드를 왜 쓰는지는 많이 알고있을거라 생각합니다. 요즘 클라우드를 학원에서도 취준생 대상으로 교육도 많이하고 그러는데 탄력성, 민첩성이라는 용어를 많이 쓰는것 같더라구요. 

틀린말은 아닙니다. 접근성도 좋고 다 좋지만 또 큰 장점이 자동화를 할 수 있다는게 저는 큰 장점이라고 생각합니다.

서드파티를 사용하면.. 부분자동화는 가능하겠지만 완전 자동화는 힘들겠죠. 

그치만 강의에서도 나왔듯이 클라우드라는게 정말 알면알수록 너무 어렵고, 알아야 되는게 많습니다. 그리고 CSP 종류만해도 AWS, Azure, GCP, NCP, Oracle, Nhn, 알리바바.. 등등 정말 많습니다. 이걸 다 알기에도 사실 무리가 있고요.

점차 클라우드로 모든 환경이 이동할 거고, SaaS 솔루션이 대세가 될 것이라는 전망이 많습니다. 

Public클라우드에서 제공되는 서비스로 쉽게 데이터분석과 다양한 서비스들을 사용할 수 있게 될것이고, 그로인해 더 빨리 좋은 서비스가 나올것이고, 기술의 변화가 더 빠를거라고 봅니다. 

클라우드의 성공사례? 를 이야기할 때 넷플릭스와 테슬라 이야기를 많이하는데,

테슬라가.. 갑자기 너무 많이 올랏죠.. 

AWS 주요서비스는 

크게 4가지 구분을 했습니다.  

1). 컴퓨팅 서비스

2). 네트워킹

3). 스토리지/데이터베이스

4). 데이터 분석 & AI

AWS의 서비스는 계속 늘어나고있고 있지만.. 다 알기는 어려운것 같습니다. 

그리고 CSP별로 기능/성능이 조금씩 다르고 가격도 다르기 때문에 

규모가 있는 회사의 경우 멀티클라우드나 하이브리드 클라우드형식으로 많이 활용하고 있습니다. 

네트워크 기본

CIDR이야기도 하면서 IP주소에 대해서 기초적인 이야기를 했습니다. 

네트워크를 처음하는데 서브넷의 개념이 잘 안잡히시는 분들이 많은걸로 알고있습니다.

그 원리를 이해하지 못하고, 서브넷계산기만 활용하시는 분들이 종종 있어보입니다만, 서브넷의 개념을 정확히 이해하고 있어야합니다. 

http://korean-daeddo.blogspot.com/2015/12/ip.html

https://limkydev.tistory.com/168

강의에서 나온자료 이외에도 구글에 조금 검색하면 관련된 내용들이 많이 나옵니다. 

여러사람들하고 이야기해본 결과, 차분히 앉아서 숫자를 하나하나 비교해보고 써보고 하면 쉽게 이해하는데... 

뭔가 그 010110101010101010101010 이런걸 하나하나 비교하고 확인해보는 걸 안하는 것 같습니다.. 

네트워크를 할 때의 가장 기본이되고, 가장 기본이 되는 VPC에서도 반드시 필요한 개념입니다. 

아키텍처를 그릴때도 마찬가지고요.. 

예전에는.. 원을 그려놓고 배웠었는데.. 요즘은 어떤식으로 교육받는지 모르겠네요.

다음포스팅에는 진짜 VPC가 나올것 같습니다. 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

01. DevOps의기본 개념 
02. AWS기반 소규모&중규모 아키텍트설계
03. AWS기반 대규모아키텍트 설계
04. 코드를통한 인프라관리(IaC)
05. 도커와 쿠버네티스를 이용한서비스 운영
06. CI/CD(지속적 통합/지속적 제공) 구현하기
07. 모니터링서비스 구축및운영
08. AWS기반보안
부록. Kuberneteson AWS EKS

01. DevOps의 기본개념의 마지막.. 포스팅입니다. 

MFA랑 AWS 비용이슈에 대한 강의였습니다. 

MFA란? 매우 중요합니다. 

다단계 인증이라고도 하는, Multi Factor Authentication을 MFA라고 말합니다. 

흔히 은행거래할 때 OTP카드를 사용하는 그런것 하고 동일하다고 보면됩니다. 

AWS를 이용할 경우 IAM사용자와 root사용자 모두에게 MFA 정책적용은 반드시 필수입니다. 

특히 root사용자에게는 하드웨어 MFA를 적용할 것을 권장하고 있습니다. 

root 사용자는 하드웨어 MFA를 꼭 설정하라고 권고하고 있습니다. 

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_mfa_enable_physical.html

root 사용자는 계정발급 초기에 IAM사용자를 생성할 경우에만 로그인하고, 그 이후에는 root사용자를 활용할 일이.. 어떤게 있을지 모르겠습니다. 

AWS best practice에서도 위처럼 이야기 하는걸로 알고있습니다. 

일반적으로 MFA 하드웨어 장비는 1개에 1계정을 설정하여 잠글 수 있습니다. 

AWS root 계정 잠금용으로 하드웨어 MFA는.. 찾아본적이 있는데, 국내에 말고 해외의 어떤 제품 1개가 되는걸로 봤었습니다... 현재는 잘 모르겠지만.

아무튼 AWS에 사용할 수 있는 하드웨어MFA장치가 흔하게 있는건 아닌것 같았습니다. 만약 제품을 구매하실 생각이시면 꼭 그런 부분을 확인해서 구매하셔야할 겁니다. 

IAM사용자의 경우 일반적으로 가상 MFA 디바이스라고 불리는.. 흔히 사용하는 PC나 핸드폰에 어플을 깔아서 사용합니다.

저도 그렇게 사용하고 있고, 강의에서는 4개의 앱을 소개해줬는데, 

저는 Authy를 사용하고 있습니다. 가장 .. 일반적으로 많이 사용하지 않을까? 라는 생각을 합니다 .

Azure Authenticator도 사용하시는 분들도 계시고... google꺼는 잘 못본거 같네요

IAM의 모든 사용자, root사용자에게 MFA는 필수입니다. 

MFA만 설정되어 있어도 외부의 침입을 막을 수 있습니다. 

MFA가 설정되지 않은 취약함 IAM 사용자가 탈취당했다는 이야기는 들어봤어도, MFA까지 뚫고서 탈취당했다는 이야기는 들어본적이 없습니다. 

정말 MFA가 별거 아니라고 생각할 수 있지만 매우 중요한 부분이기 떄문에 반드시 반드시 설정해야합니다. 

물론 로그인할 때 조금 불편함이 있지만. 반드시 해야하는 부분입니다. 

IAM 정책으로 MFA사용자는 아무런 권한을 가질수 없도록 정책화 하여 부여할 수 도 있습니다. 이러한 보안정책을 잘 수립하고 지켜야합니다. 

보통, MFA설정과 Trusted IP설정도 하고, 미사용리전에 대해서도 제한을 걸어놓습니다.

기본적인 보안정책. 꼭 하셨으면 좋겠습니다. 

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_mfa.html

사용알림 설정도 꼭 해야합니다. 

일반 학생과 취준생들이 AWS를 쉽게 사용하지 못하는 이유 중 가장 큰 부분이 비용때문입니다. 

저도 프리티어를 예전부터 조금 써왔는데,, 이런 설정이 있는지도 모르고 썻다고 비용이 많이 나온적도 있고.. 그렇습니다. 

프리티어 사용량 알림설정이 어렵지 않기 때문에 반드시 해야하며, 

클라우드를 사용하는 회사에서도 동일하게 비용절감이 중요합니다. 

결제 경보나 비용알림의 경우는 꼭 하는걸 추천합니다. 

이런 비용관리해주는 솔루션들도 있습니다.  

그런데.. 사용안해봐서 얼마나 좋은지는 잘 모르겠습니다. 

베스핀글로벌의 OpsNow라는 솔루션도 있고, 메가존의 스페이스원 이라는 솔루션도 있습니다.

그리고 이상비용이 탐지되면 AWS에서도 메일을 통해서 알림을 주기도 합니다. 

AWS계산기를 잘 활용해야하고.. 개인은 비용절감을 위해..

리소스 정리해주는 aws-nuke는 사용해본적이 없는데, 한번 알아봐야겠습니다. 

https://github.com/rebuy-de/aws-nuke

내일부터는 이제 진짜 AWS의 서비스를 배워보면서 포스팅하겠습니다. 

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.

https://bit.ly/3FVdhDa