매일 한 걸음씩만

패스트캠퍼스 챌린지 27일차

이벤트 스토밍의 방식을 바탕으로한 자세한 모델링

1. Domain Event 정의(모든 상황을 일단 나열)

- Actor가 Action을 해서 발생한 결과는 어떤 것이 있는가?

- 각자 생각나는 Event 를 적고 더 이상 생각이 안 날 떄까지 붙임. 

- 서로 중복되는 것을 없애거나 합침. 

- 포스팃으로 정리

- 이벤트가 발생하는시간 순서대로 붙임. 동시수행되는 이벤트는 이벤트는 수직으로 붙임. 

- 비즈니스 용어로 무슨 일이 발생했는 지 적어야 함. 시스템 내에서(개발)발생하는 것을 찾는 것이 아님. (사용자 입장에서 이해 할 수 있는 언어로!)

예)

참고) 점선: 이벤트가 아예 분리되어 있는 것. (다른 actor가 하는 것)

2. 프로세스 그룹핑

그룹핑 예)

Step3. Commad 정의

- 사용자의 행위 == Command => Command는 일반적으로 무엇을 요청한다

- 각 Event 별로 그 Event 를 발생시키는 Command 가 무엇인지 생각하여 Event 왼쪽에 붙임. (Command1개에 1개 이상의 Event가 발생할 수도 있음)

예.

Step4. Trigger 정의

- Command를 수행하는 Actor정의. Actor를 Command의 왼쪽 하단에 겹쳐서 붙임. 

- Event발생과 관련된 외부 시스템이 있다면 Event우측 상단에 겹쳐서 붙임. 

예. 

Step5. Aggregate 정의

- Command수행을 위한 CRUD(가공)해야 하는 데이터 객체 정의(=Command를 수행해서 Event를 발생시키려면 어떤 데이터 및 정보가 필요한 지 각 Command 와 Event 사이의 위에 적음)

Step6. Bounded Context 정의

- 현재까지 처리한 메타 정보(Actor의 Action/Event/Command의 CRUD 및 DB...)에 바탕한 그룹핑

예.

Step7. Context MAP 작성

- 큰 카테고리 간의 서비스 간략화

인증

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 26일차

도메인 주도 설계 개요(DDD) 및 기존(전통적) 방법론 소개

기존 개발 프로세스

기획자

- 사업기획 

- 서비스기획

- 요구사항 정의

마케터 

- 사업기획

- 지표 관리

- 아이디어 제안(기획자에게 추가적인 아이디어 제안)

개발자

- 설계 및 구현(기획자와 마케터가 구상해 놓은 것을 실제로 구현) -  DB의 구조는 어떻게? 언어는 뭘로? 보안은 어떻게? 서버는 어떻게? 등을 정의. 

- 유지보수

디자이너

- 페이지 및 배너 디자인

=> PM이 이러한 인원의 트러블을 조율하고 일정에 차질이 없도록 관리하는 사람 - PM

=> 해당 인원들을 통해서 하기와 같은 업무 프로세스를 수행

기획/디자인/마케팅에서 전체적인 프로세스

1. 시장조사(IF 시장성이 있다면 서비스 기획)
2. 서비스 기획
3. 베타 서비스 개발
4. 마케팅(소규모) - User Feed Back바탕으로 기획 수정
5. 서비스 기획
6. 마케팅(소규모)...반복

개발자 입장의 프로세스

전체적인 요구사항 => 설계 => 구현 => 마케팅 => 수정된 요구사항 => 설계 => 구현 => 반복...

- 기획과 개발에서 각자의 애로 사항 발생 - 소프트웨어 개발과 도메인 모델(기획)과의 불일치 발생

- 결론적으로 도메인을 추상화하여 모델을 만들고 모델을 실체화하여 소프트웨어를 만들기까지 어려움이 발생

: 의사소통에서 많은 loss발생

참고) 도메인: 실제 서비스 / 모델은 서비스를 개발자가 구현을 하기 위해 간략화한 설계도

해결방안

DDD

1. 보편언어 사용

도메인에 대한 어휘를 이해관계자(기획자, 개발자, 분석가)들이 모두 이해할 수 있는 공통 언어로 정의. 

2. 모델 주도 설계

도메인과 모델의 간극을 최소화

분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지

=> 의사소통이 좀 더 잘 되도록 하자!

도메인의 복잡성, 즉 소프트웨어의 복잡성을 해결하기 위해서는 의사소통을 잘 되도록 해야 한다. 

DDD(전략적 설계)

• BROAD하게 비즈니스에 맞도록 맞게 설계하는 것 
• 서비스 안에서 일어 날 수 있는 모든 상황(Context)을 고려 - Event Storming(주문, 주문 취소, 배송 등등등)
• 이것들을 바탕으로 각 Context 그룹핑
• 왜 그Context 룹핑?: 하나하나 Context를 설계하기에는 너무 어려움. 어느 정도 추상화 하기 위해 영향으로 구분. 
• Bounded Context
• 컨텍스트 맵핑을 통해 Bounded Context간의 관계를 정의

=> 최종적으로 도메일 모델을 생성. 

=> 도메인 모델: 일종의 설계도로 서비스의 다양한 기능들을 간략화해서 추상화한 설계도. 

=> 여러가지 Context를 분리하고 Context mapping으로 연결하고 분리와 연결한 기능을 가지고 있음. 

예)

맞춤형 AI 문제 추천 앱

1. 아이가 먼저 진단 테스트(Diagnostic test)를 봐서
2. 레벨을 진단(Level(by part)). 즉, 아이의 수준을 진단 한 다음
3. 어떤 부분에서 취약점이 있는 지 판단하여
4. 판별된 Level을 바탕으로 Custom problem set, 즉 유사한 문제를 추천. 
5. 학생이 문제를 풀면 거기서 Wrong Prob. 를 통해 결과물을 바탕으로 
6. 다시 Level(by part)로 Level을 진단하고 Custom problem set을 생성
7. 최종적으로 Level을 통해 백분위 - Predicted Points - 를 계산하고 어떤 부분을 집중적으로 봐야 할 지 알기 위해 Custom Course를 추천

DDD(전술적 설계)

- 전략적 설계보다 전략 안에서 세세하게 모델링하는 것

- 개발방법론이 아닌 일종의 철학. 

지금까지 DDD의 철학에 대해서 알아 보았는데, 의사소통만 DDD가 쉽다 뿐이지 솔직히 개발자가 개처럼 일한다는 건 DDD나 뭐나 똑같은 것 같다. 그래서 강의의 짤 인증샷과 함께 오늘은 -끝-

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 24일차

프로젝트 개요(온라인 주문 어플리케이션)

어떤 기능을 보유하고 있는가

어떠한 것을 학습할 수 있는가

어떤 기능을 보유하고 있는가

• 구매자: 음식점을 선택 / 음식 메뉴를 선택 / 배송지를 입력 / 주문의 접수
• 판매자: 주문내역의 조회/ 예상 소요 시간의 입력
• 배송자: 배송완료 후 배송 완료를 입력
• 구매자: 주문 내역을 조회/ 주문의 취소와 확인

어떤 것을 학습할 수 있는가

• DDD(Domain Distribution Design): 웹개발의 단순화 앱을 어떻게 단순하게 개발할 수 있을 지 확인
• Django: Django를 통해 백앤드 개발
• HTML/JAVASCRIPT: 프론트앤드 개발
• EC2: EC2서버를 띄워서 전세계 사용자들이 볼 수 있도록 함. 
• RDS: 관계형 DB를 사용하기 위해 RDS사용
• ELB: 로드밸런싱 기능 사용, 즉 서버나 DB에 부하가 왔을 때 이것을 분산시켜 주기 위한 기능을 사용해 봄, 
• Route53: 도메인을 설정하기 위해 필요(예. 127.0.0.1 =>www.naver.com)
• Cloud Watch: 서버의 로그들을 보기 위한 AWS의 기능으로 보안을 위해서 사용함

- 이와 같이 기본적이고 고전적인 모놀로지 식으로 배포함. 

오늘도 개요이고 실습이 없어서 인증샷을 첨부 함. 

-끝-

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 23일차

 오늘은 야근을 하고 온 관계로 실습은 못할 것 같아서 바로 다음 챕터에서 뭘 하는 지 보기 위해 다음 챕터 개요를 보기로 했다. 그러면 진행을 해보자.

모놀로지식 아키텍쳐 vs 마이크로 서비스 아키텍쳐 - 차이

모놀로지식 아키텍쳐(서비스를 개발 할 떄 어떤 기능을 하나로 묶어서 관리하는 것)

End-to-End 서비스가 용이

=> 실제로 서비스가 구동되는 처음-끝까지의 모습을 한 번에 확인하기가 용이

=> 간단한 서비스를 빠르게 만들 수 있음. 

=> 단점:

1.  작은 수정사항이 발생해도 전체를 다 바꿔야 할 수 있음. 따라서 유지보수 어려움 
2.  서비스가 커지면 구동시간이 늘어날 뿐만 아니라 일부분의 오류가 전체에 영향을 미칠 수 있음.
3.  각 기능에 따라 다른 언어를 쓸 수 없음. => 한 통에다 다 관리를 하기 떄문임. 

서비 스를 개발 할 떄 그런 다양한 기능들을 잘 게 쪼개서 관리하는 것(마이크로 서비스 아키텍쳐) 

마이크로 서비스 아키텍쳐(서비스를 개발 할 때 거대한 - 여러가지 기능이나 로직이 있는 것 - 것을 잘 게 쪼갠 집합체로 보는 것)

- 유지보수가 용이 - 기능 A에서 에러가 나면 각각을 따로 관리하므로 A만 보면 됨. 

- 거대한 서비스도 빠르게 수정 가능하다. (모놀로지는 한 번에 관리하므로 코드를 다 뜯어 봐야 함)

- 각 기능에 따라 다른 언어를 선택 할 수 있음. ( Web: JAVA, 머신러닝: Python...)

<=> 단점: 기능이 분리되어 있고 상호작용하므로 모니터링이 힘듦. 

End-to-End 서비스 구동이 불편(테스트 불편): 모놀로지는 통으로 개발하므로 상대적으로 빠르게 개발 - 테스트 하는 것이 가능하지만 마이크로 서비스는 개발  - 테스트가 느림. 

DevOps는 처음에 모놀로지식으로 개발해서 최종적으로 마이크로 서비스로 운영하여 편리하게 운영 하는 것이 목표 - 물론 초기에는 시장성을 보기 위해 모놀로지식으로 개발하는 것이 좋음!

오늘은 실습이 없는 관계로 인증샷 첨부

- Ch2. 에서는 모놀로지식 아키텍쳐로 구현하는 것이 목표

- Ch.3에서는 마이크로 서비스로 구현하는 것이 목표

끝. 

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 22일차

AWS를 이용하여 NAT Gateway만들기

- Private subnet까지 접근 하였음. => 패치 다운로드, 외부 프로그램 다운로드 등 작업을 하기 위해서는

- NAT Gateway필요

- NAT Gateway 설치 

- NAT Gateway로 Private EC2에 Mysql설치

SQL 설치 

1) PUTTY로 EC2-public에 로그인

하려고 했는데 에러 

- 에러 해결

PUTTY fatal error라면서 접속이 안 됨. - auto login을 ec2-user로 해주거나 로그인 할 때 ec2-user로 로그인 해 주면 됨. 

sudo yum install mysql을 쳤으나

응답이 없음. => NAT 게이트웨이 생성필요

NAT Gateway 생성

1) VPC > 가상 프라이빗 클라우드 > NAT 게이트웨이 

NAT 게이트웨이 생성

=> NAT 게이트웨이는 프라이빗 서버가 우회적으로 인터넷을 하기 위한 (통신하기 위한) 수단이기 떄문에 Public subnet에 위치해야 함. 

2) 연결 설정

이름: 아무거나 입력

서브넷 public subnet선택

연결 유형: ? (일단 Public)

탄력적 ip를 할당해야 NAT 게이트웨이가 IP를 할당해 줌. 

게이트 웨이 생성

sudo yum install mysql을 쳐도 안 됨.

- sudo yum install mysql을 치는 것은 나는 외부로 나가서 통신 하고 싶다는 것임. 

- 그러나 private routing table에서 10.0.0.0/16인 ip는 모두 local에서만 도는 것으로 규칙을 만들어 놓았음. 

따라서 

0.0.0.0/0 인 것, 즉, 기존의 규칙 외의 모든 것을 NAT 게이트웨이로 보내는 규칙을 만들어야 함. 

설치하려고 했으나 나는 SSH 를 통해 Private subner에 아직 접속이 안 됨. 뭐가 문제인지 모르겠음ㅠ 어쨌든 NAT GATEWAY 생성과 정책 바꾸는 것 까지는 완료 하였다. 

끝

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 21일차

VPC Bastion HOST 만들기

Bastion HOST 외부 유저가 Private subnet에 접속하는 것 - public subnet을 우회해서 private subnet에 접속

Story

- Private EC2생성

- Public EC2생성(Bastion Host)

- Bastion Host를 통해 Private host에 접근 using putty

Public EC2 생성

1) EC2접근

2) EC2 생성(Linuc or Ubuntu - 프리티어)

상세 설정은 위와 같이 

customVPC에서 / PublicVPC를 생성하고 / 퍼블릭 IP자동할당에서 서브넷 사용설정(활성화)를 설정하면 된다. 

다른 건 건드릴 필요 없음. 

다음 클릭

스토리지 볼룸 유형 - 마그네틱 - 변경 / 다음 클릭 - 마그네틱 뭐지

네임태그 추가 - public-ec2입력 / 다음 클릭

• 보안 그룹 이름 변경
• 보안 규칙 추가, IPV4 규칙 추가, 
• 모든 포트 범위에 대해서 0.0.0.0/0 에 대해 접근을 허용하는 것으로 설정

- 검토 및 시작 클릭

다음 클릭

시작하기 클릭

새 키페어 생성(public-ec2-keypair) - 키페어 다운로드 - 인스턴스 시작

Private EC2생성

CustomVPC의 private subnet을 선택하고

private subnet이니 IP할당은 하지 않음 / 다음 클릭

볼륨 유형 - 마그네틱으로 변경 / 다음 클릭

name태그 추가 - private-ec2 / 다음 클릭

보안 정책은 모두 같은데 소스로 public-sg에서 온 것만 inbound로 받아 들이는 것으로 설정 / 검토 및 시작

private-ec2-keypair - 키페어 다운로드 - 인스턴스 시작

SSH를 통한 접근

1) PUTTY 다운로드

- pageant putty 검색

- putty.exe / pageant.exe / puttygen.exe 3개 다운로드

- pagent.exe를 연다. 키를 등록해야 하는데 .ppk만 등록이 된다. (우리가 AWS에서 다운 받은 것은 .pem 임.)  

- puttygen 이 pem -> ppk로 바꿔줌, 

2) Puttygen

-  load - allfiles - pem 선택 - save private key

3) pageant에 key등록

4) PUTTY 오픈

- Public EC2를 통해 Private EC2에 접근 할 것이므로 일단 Public EC2에 접근

Public EC2의 아이피 주소를 일단 집어 넣음

- connection - data - auto-login username: fastcampus-user

- connection - ssh - Auth - Authentication parameter - 체크 Allow agent Fowarding

Open

DOS창? 같이 로그인 됨, 

Private subnet에 접근

1) private EC2의 PRIVATE IP를 찾음

2) 접속한 PUTTY에 다음과 같이 침

SSH [PRIVATE SUBNET의 IPV4주소]

그러면 접속 되야 하는데??? 왜 안 되지????

ㅠㅠㅠ 질문해야 할듯 아니면 혼자 트러블 슈팅이나ㅠ어제부터 이상하네

덧) connect to host 10.0.1.111 port 22: Connection timed out 이라고 나오는 거 보니 연결 설정이 잘못 된듯. 보안 그룹을 잘못 만들었을 수도 있으나 오늘은 시간이 부족하여 나중에 다시 살펴 보는 것으로 하자!

끝!

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 20일차

1) VPC의 SUBNET내부에 EC2의 생성에 대한 이해

- PUBLIC SUBNET의 Inbound, Outbound규칙을 따를 것임. 

2) Inbound와 Outbound규칙의 수정에 따른 엑세스 거부와 허용의 살펴 봄. 

EC2생성과 보안 정책 연결

1) 인스턴스 시작 클릭

2) EC2생성

실습에서는 Linux를 생성한다. 저번에는 우분투를 생성하였는데 이번에는 Linux를 생성한다. 

그리고 사양으로는 프리티어에서 사용 가능한 t2.micro를 선택하고 다음을 클릭

3) 인스턴스 세부 정보(VPC, 서브넷 등) 입력

- 강사가 Subnet에서 별도로 ip자동할당 작업을 해줬는데 현재는 별도로 자동할당해주는 작업을 해주지 않아도 그냥 선택이 됨. 따라서 별도로 포스팅 하지 않음. 

네트워크 - customvpc

서브넷 - publicvpc

퍼블릭 IP 자동 할당 - 활성화

사용자 데이터에 다음과 같은 코드 입력

#!/bin/bash
yum install httpd -y 
service httpd start

그런데 위 코드가 무엇을 뜻하는 는 모름 <= (이해 필요)

현재는 강사가 이해 필용 없다고 하면서 설명하지 않았음. 

다음 클릭 

3) 다음 클릭

4) 네임 태그 생성

다음 클릭

5) 보안 그룹(Security Group) 세팅

최초에는 22번 포트밖에 허용되지 않아 있음. 따라서 이에 대한 세팅 필요. 

다음과 같이 80번 포트와 443번 포트에 대해 통신 가능하도록 설정하였다

(주. 80: http, 443: https)

그리고 검토 및 시작 클릭

개략적인 정보의 확인이 가능함. 

시작하기 클릭

6) 키-페어 다운로드

인스턴스 시작 클릭

7) 확인

인스턴스가 적절하게 만들어졌는지 확인

네트워킹 탭에서 서브넷이 내가 만든 CustomVPC와 연결되었느지 확인

네트워킹 탭에서 서브넷이 내가 만든 Publics subnet과 연결되었느지 확인

브라우저 창에 IpV4주소를 입력하여 실제로 잘 연결이 되었는지 확인

???????????

트러블 슈팅은 일단 나중에 해보고 포스팅을 계속해 보기 위해 강의를 봄. 이후는 실습없이 강의를 보는 것으로 대체함. 

분명히 80번 포트 Allow되어 있는데 강의와 달리 안 됨.

강의에서는 우선순위에서 Deny했을 경우에 접근이 안 되는 것을 보여줌. 

- 강사에게 질문을 하거나 구글링을 해보도록 하자. (근데 질문 하는게 가능한가?) 

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa

패스트캠퍼스 챌린지 19일차

AWS에서 NACL설정하기

• 보안에 대한 개념 설명
• AWS에서의 실습

AWS에서 instance에 대한 보안을 설정하는 방법은 크게 2가지가 있음

• NACL - statelss
• Security group - stateful

이것에 대한 차이는 다음과 같음. 

주) 오른쪽이 Server

테이블(강사는 패킷으로 쓴 것 같다.) 의 의미 - 클라이언트가 Request를 쏠 때는 80번 Port로 쏘고 받을 때는 Server가 Response로 Client의 1025 Port로 달라는 의미 

주)임시 포트의 범위는 1024~65535

• Server입장에서 생각했을 때 Response가 80번 포트로 들어 오는 것이므로 Inbound
• Server입장에서 생각했을 때 1025로 Response를 쏴줘야 하므로 Outboud

반대 방향의 흐름(Response)은 위와 같다. 즉, 전체적인 네트워크 구조는 위와 같다. 

Stateful(Security Group)

먼저 위 그림의 정책 Inbound: 80 / outbound: none의 의미는 다음과 같다. 

• 80으로 Client가 쏴주는 것은 허용, 나머지 포트는 불허용
• outbound(Server입장에서 쏘는 것)는 아예 어떠한 포트도 허용하지 않음. 

그러나 Stateful은 상태를 기억을 하고 있음 => 즉, 원래 80으로 inbond통신해서 request를 서버로 주는 것은 가능하지만 정책상 Response는 아무대도 가면 안 되지만, 패킷에서 1025PORT정보를 기억하고 있음. 따라서 1025로 갈 수 있음. (확인 필요)

- Stateful: Session을 통해 유용한 정보를 기억하고 있다.  

Stateless(NACL)

Stateful과 달리 룰에 따라서만 행동하는 정책으로 위에 따르면 패킷에 상관없이 Outbound를 내보내지 않는다. 

NACL 실습

1. AWS 로그인 > VPC > 보안 > 네트워크 ACL

- 기본 생성된 NACL이 있어서 햇갈릴 수 있지만 서브넷 연결란에서 내가 생성한 NACL을 확인할 수 있다. (이전 시간에 내 Custom subnet과 연결해 놨기 때문에)

- 내 NACL의 이름을 private-nacl로 바꾼 다음

2) 네트워크 ACL 생성 클릭

3) 정보 입력

- 이름 입력 후 NACL이 들어 갈 VPC 입력 - 생성

4) 서브넷을 연결하기 위해 먼저 public-nacl을 클릭하고 - 작업 - 서브넷 연결 편집 클릭

public subnet과 연결 후, 변경사항 저장

5) 확인

6) 인바운드 규칙 편집

7) public_nacl 인바운드 규칙 편집

8) 확인

규칙번호에 따라 Allow와 Deny가 있음. 규칙번호는 규칙의 우선순위임. 확인을 위해 아래와 같이 101번 규칙을 설정하고 확인

- 101번에서 거부하려고 했으나,

- 100번에서 이미 들어오라고 허용했기 떄문에

- 101번 규칙은 거부됨. 

(유형과 프로토콜에 대한 설명은 없었음. 추가적으로 공부해야 할듯)

9) public_nacl 아웃바운드 규칙 편집

- 임시 포트는 1024~65535이므로 나가는 포트는 전부 있어야 함!

-끝-

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

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online!

https://bit.ly/3FVdhDa