인생무엇

< 강의 커리큘럼 >

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

< 강의 커리큘럼 >

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

CLI, API, SDK 에 대해서는 많이 들어보셨을거라 생각합니다. 

그러나 구분을 잘 못하는 경우가 많습니다. 

검색을 통해서라도 그 차이를 정확히 알고 있어야합니다. 

오늘 들었던 강의에서는 CLI에 대한 내용이 나왔는데, 

CLI는 흔히 생각하는 커맨드창, 터미널창에 명령어를 입력하는 그런 방식?을 말합니다. 

네트워크 컨피그를 설정할때, 리눅스를 다룰 때, 각종 3rd파티를 다룰 때도 사용합니다. 

CLI를 지원해야 여러장비와의 호환이 쉽게 이루어 질 수 있으며.. CLI를 지원안하는 경우는.. 있는지 모르겠습니다. 

AWS CLI를 설치하는 방법 (macOS)

brew install awscli

AWS CLI를 설치하는 방법 (Ubuntu)

sudo apt update
sudo apt install unzip build-essential curl
curl "http://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip 
sudo ./aws/install

AWS를 다루는 방법은 Ansible, Terraform 등을 활용하는 경우도 있고 하지만.. 근본적으로는 

1) AWS Management Console , 2) AWS CLI , 3) AWS API로 볼 수 있습니다. 

추후 강의에도 나오겠지만 

1) AWS Management Console을 사용할 때 가장 필수로 해야하는 보안사항이 MFA설정이고, 

2) AWS CLI 나 AWS API를 사용할 때에는 액세스키라는 것을 활용합니다. 

이 액세스키는 사용자의 권한과 동일한 권한을 가지고 있어, 정말 잘 관리해야합니다. 

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_access-keys.html

AWS 액세스키에 대해서 조금 이야길 하자면

액세스키는 액세스키 ID와 보안액세스키 2가지 부분으로 구성되어 있습니다.

위에서 말씀드렸다시피 액세스키는 IAM 사용자의 권한을 그대로 가지고 있기 때문에 액세스키가 노출되면 큰 보안사고로 이루어 질 수있습니다. 

특히 Admin 권한이나 Full Access권한을 가지고 있는 IAM사용자의 액세스키가 노출될 경우에 해커에 의해 타 사용자의 권한 상승 및 AWS 리소스의 수정,삭제,생성이 일어날 수 있어 금전적인 피해가 발생 할 수 있습니다. 

액세스키는 주기적으로 변경해주는 것을 권장하며 IAM사용자 별 최대 2개까지 만들 수 있습니다. 왜냐면 Access key변경을 할 경우 필요합니다.. 

액세스키 관리에 대해 좋은 아이디어가 있으신 분들은.. 알려주시면 감사하겠습니다. 

여기에 추가적으로 액세스키 발급이야기를 하니까 IAM사용자의 유형에 대해서도 조금 이야길 하자면..

AWS의 사용자, 계정 이런 이야기를 할 때 약간.. 사람들 마다 조금 다릅니다. 

그래서 저는 나름의 정의를 내린것이 

- AWS 계정은 콘솔을 기준으로 나누는 것. 

  콘솔로그인 할 경우 "계정ID 또는 계정별칭"을 적으라고 하는데, 이 기준을 이야기하고, 

- AWS 사용자는 root와 IAM을 정확히 구분한다. 

  root사용자는 말그대로 root사용자를 의미합니다. 정말 최상위의 모든 ALL 권한을 가진 root사용자.

  그 이외 IAM사용자. IAM에 사용자 등록을 하는 경우. 

그러나 여기서 IAM 사용자도 2가지 분류로 나눌 수 있습니다. 

1). 콘솔접속 IAM 사용자 

    > 콘솔에 접속할 수 있는 패스워드를 설정합니다. Access Key는 발급되지 않고, 추후에 생성할 수 있습니다. 

2). 프로그램용 IAM 사용자 

   > 콘솔 접속할 수 있는 패스워드가 설정되지 않고 Access Key가 생성이됩니다. 

용도에 따라 IAM사용자를 구별해서 생성해줘야합니다. 

강의에서는 콘솔에 접속하는 IAM 사용자의 Access Key를 사용해서 CLI작업도 진행했지만, 

콘솔 접속하는 IAM 사용자는 Access Key를 따로 만들지 않는것을 추천드리기도 합니다. 

콘솔에 정말 극히 드문 몇몇 사용자만 접속하고, 다 AWS CLI나 API를 통해 AWS를 컨트롤하는 회사도 있는것 같습니다.

AWS CLI를 사용할 때 스위칭 하는것도 실제로 많이 활용하고 있습니다. 

https://novemberde.github.io/post/2018/06/20/AWS-config-switching/

MFA 설정 및 비용관련 이슈 처리는 내일 작성하고, 이제 진짜 AWS 실습으로 넘어가보도록 하겠습니다.

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

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

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

오늘은 AWS에서 가장 기본적인 EC2에 접속하는 것을 배웠습니다. 

AWS 프리티어계정을 만들어서 해당 강의 내용대로 그대로 따라하게 될 경우 손쉽게 EC2에 접속하는 게 가능합니다.

그러나 테스트 계정이라든지, 기존에 누군가가 기본설정을 삭제했거나 등등.. 여러이유로 강의에서 본 것 처럼 쉽게 넘어가지 않습니다. 

추후에 VPC에 대한 개념을 다루는것 같지만, EC2에 접속하려면 Public 서브넷에 위치해야 가능합니다. 

오늘은.. 아키텍처를 그릴 준비가 안된 상태로 글을  쓰다보니까 아키텍처 그림이 이쁘지가 않지만.. 추후에는 준비를 조금 하도록 하겠습니다. 

AWS에서 기본적으로 Default VPC가 생성되어 IGW가 다 연결되어 있는걸로 알고있습니다..(아마도..?)

그래서 Default VPC를 사용할 경우에는 바로 쉽게 SSH키 (키페어)를 생성하고 그 키페어를 이용해서 생성한 EC2에 접속할 수 있도록 되어 있습니다. 

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

< TMI > 
과거에는 Default VPC를 삭제할 경우에는 AWS에 따로 요청을 해서 Default VPC를 생성해야 했지만, 지금은 많이 업그레이드 되서 Default VPC를 사용자가 만들 수 있습니다. 일반적인 VPC만드는게 아닌 우측상단에 기본VPC생성하는 그런 메뉴가 있습니다.
Default로 생성되는 VPC나 SG 등을 관리해야할 필요가 있습니다. (Defualt는 사용하지 않도록 권고드리고있습니다.)

만약에, EC2를 만들다가 VPC를 선택하는 부분에서 넘어가지 않는 경우가 발생 할 수 있습니다. 

그럴경우 Public Subnet을 만들어줘야합니다. 

VPC를 만들고, IGW를 생성하고 라우팅테이블을 설정해주는 작업이 필요합니다. 

네트워크 구조를 모르고 그냥 아무런 VPC를 연결해서 EC2를 생성하면, 접속이 안됩니다. 

사용자는 외부인터넷을 통해 EC2에 접근하기 때문입니다. 

AWS에서 SSM이라는 기능도 있어 사용하면 좋을 것 같습니다. (보안적인 측면에서)

https://musma.github.io/2019/11/29/about-aws-ssm.html

영상은 짧게 Key를 등록하고, 설치한 WSL 또는 mac 터미널을 이용해서 

ssh -i ./[pemkey] ubuntu@[ip]

형태로 로그인을 했지만 

일반적으로 putty나 xshell을 많이 사용하실 거라 생각합니다. 

저는 putty를 사용하는데, putty를 사용할 경우 다운로드 받은 pem키를 ppk키로 변환해주는 작업이 필요합니다. 

https://sujinisacat.tistory.com/17

또는 구글에 'putty ec2 연결'과 같은 키워드로 검색을 하면 많은 글들을 확인할 수 있습니다. 

AWS의 운영계정이나 테스트계정에서 AWS 키페어부분을 보면 관리가 안되는 경우가 많습니다. 

EC2를 생성하는 경우에 키페어가 없으면 만들 수 있는데, 그때 필요에 의해 만들고나서 삭제를 안한다거나, 무분별하게 테스트를 위해 만들어서 EC2를 사용하고 난 이후에 키페어에서 삭제를 안해서 쌓이는 경우가 많습니다. 

불필요한 키페어는 삭제하고, 키페어가 유출되지 않게 유의해야합니다. 

해당 영상에서도 키페어는 비대칭키라는 설명을 하는데, 비대칭키와 대칭키에 대한 내용은 간단하게라도 알고 있어야합니다.

이 또한 검색해보면 좋은 자료가 많기 때문에 간략히

비대칭 키 : 개인키 + 공개키로 이루어져 있어 키 교환의 문제가 해결됨. 속도는 느림
대칭 키   : 키교환의 문제가 있음. 1개의 키로 암복호화를 다 할 수 있음. 속도가 빠름

IAM 사용자의 Access Key나 키페어의 키는 반드시 안전하게 보관이 되야합니다. 

키 보관에대한 방법은 많지만, 효율적으로 키관리를 어떻게 해야하는지는 어려운 것 같습니다. 

SG의 경우 0.0.0.0/0과 같이 모든 IP에서 오픈하는 것이 아닌 반드시 IP 및 Port에 대한 할당이 필요하며, Wellknowport를 사용하지 않도록 하는것이 좋습니다.

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/working-with-security-groups.html

Security group 또한 무분별하게 Default name으로 생성되어 관리가 안되는 경우가 많습니다. 주기적인 관리가 이루어지면 좋습니다. 

나중에 관련해서 강의가 나올지 모르겠지만 

EC2와 같이 S3, RDS 등등 AWS의 서비스는 태그를 붙일 수 있습니다. 

Tag를 활용하면, 자산관리를 쉽게 할 수 있을 뿐아니라 검색에도 효율적입니다. 

아래 AWS의 리소스태그지정 모범사례도 있으니까 참고하시면 좋을 것 같습니다.

https://docs.aws.amazon.com/ko_kr/general/latest/gr/aws_tagging.html

각 회사별 태그 규칙이 존재할 것입니다. 

해당 자산은 어디에 포함이 되는지 기록도 할 것이고 (예를 들어 ISMS-P 점검 대상 자산 등), 테스트용인지 운영용인지, 어디 부서에서 활용하고 있는지, 특수목적이 있는지, 관리자는 누구인지, 등등 

태그는 리소스 한개에 최대 50개까지 설정을 할 수 있습니다. 태그를 잘 사용하는 것도 자산관리에 도움이 될 것이라 봅니다. 

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

https://bit.ly/3FVdhDa

< 강의 커리큘럼 >

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

▶ PC 기본 셋팅

어제는 DevOps의 기본개념과 DevOps 엔지니어에 대해서 가볍게 알아보는 시간과 강사님의 소개를 듣는 시간을 가졌다면 오늘은 챌린지 2일차로 본격적인 강의에 들어가기 앞서 기본 환경구성을 하는 시간을 가졌습니다. 

강의준비가 탄탄하다고 느꼇던 부분이 mac과 윈도우에 대한 설명이 나눠져 있어서 좋았습니다. 

저는 mac도 사용하고 윈도우도 사용하고있는데, 개발관련 업무를 할 때는 mac을 쓰고, 문서작업을 할 경우에는 윈도우를 쓰고 있습니다. 

두가지 OS를 사용하고 있으면.. 키보드 자판이 햇갈린다는 단점이 있습니다. 

mac을 사용하기전 윈도우 PC만 사용할때 WSL(Windows Subsystem for Linux)라는 것을 몰라서.. 필요한 경우에는 Ubuntu VM을 띄워놓고 리눅스 위에서 작업하기도 했었습니다.

WSL 깔아두고 zsh설치하고 화려하게 꾸며두고 사용을 했었는데, 강의에서도 관련해서 자세히 잘 설명해줘서 좋았습니다. 또 version에 대해서는 잘 몰랐는데 관련해서도 설명이 되어있어 사용하는 다른 윈도우 PC의 WSL 버전도 업그레이드 해두었습니다. 

전체적으로 기본개념설명이 잘 되있고, 차근차근 따라할 수 있게 되어 있어 만족스럽습니다. 

▶ AWS 계정 준비

그리고 중요한 AWS 계정생성 하기를 진행했습니다. 

클라우드는 사용한만큼 비용을 지불하기 때문에 수많은 업체에서도 클라우드 비용을 줄이기위한 노력을하고, 비용관리하는 솔루션도 출시되어 있습니다. 

해당 실습을 진행하면서 프리티어의 Product만 사용할 수 없지만, 앞서 비용에 대한 부분도 이야기 해주셨고, 실제로 얼마쯤 나올것이다 라는 예상치를 알려주는 점이 좋았습니다. 

AWS 등 다른 CSP도 사용해봤기 때문에 해당내용들은 크게 어려움이 없었고, 

클라우드 비용에 관해서 처음에 저도 얼마가 나올지 가늠하기 힘들었기 때문에 학생들이나 취준생분들은 쉽게 접근하지 못하는 것 같습니다. 

AWS 계정을 다 지웠는데도 요금이 과금되는 문제가 예전에 있었는데, 다른분들도 그런 적이 종종 있는것 같더라구요. 오늘은 비용관련 이슈해결 강의까지 듣진 않았고, 내일 관련해서 포스팅 해보도록 하겠습니다. 

https://aws.amazon.com/ko/pricing/

가장 민감한 비용관련해서도 정리를 잘 해주었습니다. 

- On-demand  : 쓴만큼 비용지불 (일반적으로 이 방식으로 사용)

- 예약 구매 : 현업에서 RI 라고 이야기 하기도합니다.
                 약정을 걸고 비용을 미리 내고 사용, 얼마나 사용할지를 판단하기가 까다로움.. 

- 절감 계획 :  예약구매와 비슷하지만 인스턴스 타입변경시 별도 작업없이 RI보다 유연한 할인을 받을수 있다고 합니다. 
                  https://www.bespinglobal.com/aws-discount-model-saving-plan/ 

- 경매 (Spot) : 변수가 너무 많음.. 그래서 사용하기 어렵지만 가장 싸게 이용할 수 도 있음

또한 프리티어를 사용시에 대한 유의사항으로 

- 모든 서비스를 프리티어로 제공하진 않는다.

- 프리티어 서비스이더라도 사용한도가 있다.

- 12개월 무료

- 리소스 사용량 모니터링은 필수.

- 결제페이지에서 틈틈히 확인.

- EC2의 경우 EBS의 경우는 독자적인 서비스이기 때문에 1달에 30G 제공되고.. EIP 제거 등의 세세한 확인이 필요

다른 CSP도 마찬가지겠지만,

클라우드에서 비용이 요청량, 엄청 세분화된 서비스들에 대한 과금체계, 트래픽량.. 등등등 세부적으로 따지다 보니 사실상 초보자들이 파악하고 계산하기 너무 어려울것 같다. 

사실 조금 숙련된 사람도 이런걸 다 알아서 비용을 유추하기란 너무 어려울 것 같다... 

틈틈히 생성한 리소스를 확인하고, 불필요한것은 삭제하고, 정지시키는 것이 생활화 되어있어야 하는 것 같다. 

https://aws.amazon.com/ko/blogs/korea/10-things-you-can-do-today-to-reduce-aws-costs/

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

https://bit.ly/3FVdhDa

직장인들은 다양한 교육기관에서 배움의 기회 조차 주어지지 않는 경우가 많았는데

이번에 패스트캠퍼스에서 이런 최신 트렌드에 맞춘 AWS인프라 구축과 DevOps 관련해서 갓생살기 100%환급 챌린지라는 좋은 이벤트가 있어서 참여하게 됐습니다. 

100%환급을 받기위해 11월1일부터 30일까지 하루도 빠짐없이 포스팅을 진행 해야하는데.. 한번 열심히 해보겠습니다. 

한 번에 끝내는 AWS 인프라 구축과 DevOps 운영 초격차 패키지 Online.

라는 강의를 수강하고 있습니다. 

강의 커리큘럼은 

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

위와 같은 커리큘럼으로 진행됩니다. 

실제로 현업에서 일하시는 분들이 강의를 해주시는 거라서 아직 몇강 안들었는데, 굉장히 도움이 많이 되겠다는 생각이 들었습니다. 

또 타 강의들을 보다보면 옛날에 찍어둔 영상을 계속 재활용하는 경우가 있는데, 이 강의는 그러지 않은거 같더라구요. 

최근에 디지털트렌스포메이션(Digital Transformation, DT)라는 용어를 많이 들어봤을거 같습니다. 또한 클라우드라는 용어를 한번쯤은 다들 들어보셨을 거라고 생각합니다. 

특히 백신예약시스템을 클라우드 환경으로 구축해서 전국민의 불편을 해소한 것 처럼, 기술의 변화는 정말 빠르게 일어나고 있습니다.

IT를 직업으로 가지고 계신분들은 많이 느끼고 계실겁니다. 기존의 레거시 방식이 아닌 AWS, Azure, GCP 뿐아니라 국내에서는 NCP, TOAST, KT클라우드 등 다양한 CSP 업체들이 있습니다. 

또한 이를 지원하는 MSP업체들도 많이 있습니다. 

메가존, 베스핀글로벌이 국내에서는 1,2위 하는 업체이고, 생각보다 작은 업체들도 많드라구요. 

클라우드 환경으로 변화하면서 예전에는 없었던 DevOps라는 직종이 생긴거 같습니다. 

이 글을 읽으시는 분들이라면, 

DevOps란 무엇인가? 정의, 필요성...  등등 일반적인 부분들은 너무 글이 많기 때문에 

쿨하게 PASS합니다. 

최근 많은 회사들의 채용을 보면 DevOps 엔지니어를 채용한다는 공고가 많습니다. 

DevOps 엔지니어라는 것은 무엇인가? 를 생각해봤을때 뭔가 Role이 애매하다고 생각을 했었는데, 해당 강의에서 정리를 잘 해줬습니다. 

DevOps 엔지니어의 역할

- 네트워크

- 개발 및 배포 플랫폼

- 오케스트레이션 플랫폼

- 관측 플랫폼

- 클라우드 플랫폼

- 보안 플랫폼

- 데이터 플랫폼

- 서비스 운영

DevOps Team의 업무 도메인

- 구축 (Provisoning)

- 설정 (Configuration)

- 운영 (Operation)

- 사용 (Usage)

- 교육 (Training)

- 문서화 (Documentation)

DevOps Team의 핵심지표

- 장애복구 시간 MTTR (Mean Time To Recovery)

- 변경으로 인한 결함률 (Change Failure Rate)

- 배포 빈도 (Deployment Frequency)

- 변경 적용 소요 시간 (Lead Time for Changes)

해당 내용들이 정말 중요하다고 생각하고, 추후에는 DevOps 엔지니어도 다양한 Role로 쪼개지겠다는 생각을 합니다. 

지금의 DevOps엔지니어의 역할은 너무 방대하다고 봅니다. 

DevOps 엔지니어는 
자주 빠르게 쉽게 안전하게 배포하면서 언제든 다시 배포할 수 있게 만드는 것이 핵심 역량이라고 생각했습니다.

DevOps 엔지니어는 개발자인가? 엔지니어인가? > 개발자에 가깝다고 생각합니다.

DevOps엔지니어이신 분하고 이야기도 해보았는데, 백앤드개발자를 하셨어서 인프라와 코드의 이해가 굉장히 좋으셨습니다. 

요즘의 IT는 새로운것을 빨리 받아들이고 적용하고 활용을 잘하는게 중요하다.. 라는 생각이 많이 듭니다. 

그리고 영어도 잘해야하고.. 글도 잘 써서 남겨놔야대니까.

블로그 포스팅을 열심히 해보도록 하겠습니다. 

DevOps 로드맵 (https://github.com/kamranahmedse/developer-roadmap)

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

https://bit.ly/3FVdhDa