T101-Study-4Week

가시다님과 스터디를 한지도 5번째 이번엔 테라폼이다.

오늘 블로그를 쓰게된건 중간과제를 설명하기 위해서다.

바로 본론으로 들어간다. 내 GIT 이다

https://github.com/Cloud-Linuxer/T101/tree/main/4week

variable "availability_zone" {
        description = "Seoul region availability zone"
        type = list
        default = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d"]
}

variable "subnet_numbers" {
  type    = list
  default = [10, 20, 30, 40]
}
variable "az_count" {
  type    = list
  default = ["A", "B", "C", "D"]
}

나의 Variables는 이런식으로 구성되어있다. 모든 타입을 List로 선언하여 사용한다. 5주차에 할 테라폼 의 반복문을 사용하기 위한 형태다. 가장 중요한 부분은 subnet_numbers 부분이다. 10, 20, 30, 40 이 핵심이다.

resource "aws_subnet" "pub-common" {
        count = "${length(var.availability_zone)}"
        vpc_id = "${aws_vpc.default.id}"
        cidr_block = [
                for num in var.subnet_numbers:
                cidrsubnet(aws_vpc.default.cidr_block, 8, num)
                ][count.index]
        availability_zone = "${element(var.availability_zone, count.index)}"
        tags = {
                Name = "Linuxer-Dev-Pub-Common-${element(var.az_count, count.index)}"
        }
}

이 코드만 봐서는 이게 무엇을 뜻하는지 한눈에 보기 어렵다. 그럼 하나씩 설명하겠다. 하시코프에서는 cidrsubnet 이라는 Function 을 지원한다. 이 함수를 통해서 나는 /16비트의 서브넷을 24비트로 자를거다.

간단히 보여주자면 이렇다

terraform console
> cidrsubnet("10.0.0.0/16",8,10)
"10.0.10.0/24"
> cidrsubnet("10.0.0.0/16",8,20)
"10.0.20.0/24"
> cidrsubnet("10.0.0.0/16",8,30)
"10.0.30.0/24"
> cidrsubnet("10.0.0.0/16",8,40)
"10.0.40.0/24"

for로 list 에 담긴 subnet_numbers를 가져다가 CIDR 을 반환한다. 위처럼 24비트의 4개 서브넷이다.
위와같이 24비트로 나뉜 4개의 서브넷을 테라폼은 생성한다.
위의 리소스선언 한줄로 Subnet 4개를 생성하는 것이다.

서울 리전의 4개 AZ를 모두 사용하고, A zone은 10대역대 B Zone은 20대역대 C Zone은 30대역 D Zone은 40 대역인것이다.

이렇게 사용하면 장점이 있다. 한개의 존이 문제가 생긴것을 파악하기 쉽고, 아이피 대역대 만으로 서비스의 역할을 파악할수 있는 장점이 있는 것이다.

처음엔 리스트로 서브넷 선언도 모두 입력해서 하나의 리소스 선언으로 모든 서브넷을 생성하려했지만 그렇게 사용할 경우 리스트가 변경되면 모든 서브넷이 영향을 받는 이슈가 있어서 각 서브넷별 리소스 선언을 하는 방향으로 수정했다.

AWS-FinOps-S3-incomplete-multipart-uploads-MPU

S3는 청크 단위로 파일을 잘라서 업로드 할수있는 기능을 제공한다.

이 기능의 정식명칭은 multipart upload 이다.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html

MPU라고 줄여서 부른다.

MPU는 업로드 속도를 빠르게 해줄수있는 아주 좋은 기능이지만, 업로드에 실패할 경우 완성되지 않은 청크단위의 파일들이 S3스토리지에 저장되게 된다. 업로드가 정상적으로 이루어진 경우 청크단위로 나뉜 파일을 하나의 파일로 합쳐서 객체로 보이게 되지만, 그렇지 않은 파일은 우리의 눈에 보이지 않지만 S3의 스토리지에 비용만 발생시키며, 하등 쓸모없는 상태로 저장만 되어있는다. 이런 경우를 "incomplete multipart uploads" 라 부른다.

불완전 멀티파트 업로드/완료되지 않은 멀티파트 업로드 는 Lifecycle 를 통해 삭제 할수있다. 간단한 정책을 만들어서 보여주고자 한다.

설정은 S3 버킷 에서 관리로 가면 수명주기 규칙으로 설정할수 있다.

이설정은 모든 버킷에서 통용적으로 사용할수 있는 규칙이므로 버킷을 생성할때 무조건 넣어도 좋다.

위와같이 "만료된 객체 삭제 마커 또는 완료되지 않은 멀티파트 업로드 삭제" 체크후 "불완전 멀티파트 업로드 삭제" 를 체크하면 된다. 일수는 1일이 최소값이다.

정상적으로 삭제가 동작하면 이런식으로 S3 dashboard에서 불완전한 멀티파트업로드 바이트 차트가 0B로 변경되는것을 확인할수 있다.

불완전 MPU는 대표적으로 이런경우 생성된다.

MPU 업로드 실패.
Athena 쿼리 실패
Redshift UNLOAD 실패등

AWS 서비스에서 S3로 저장하는 액션을 취하다 실패하는경우가 있다면 대부분 "불완전 MPU"가 생성될것이다.

AWS S3 대시보드를 확인하여 "불완전한 MPU" 를 확인하고 삭제해보자.

바닥에 흘리고 다니던 눈먼 동전 줍기가 될것이다.

읽어주셔서 감사하다!
앞으로도 FinOps 시리즈로 찾아 뵙겠다.

AWS-IAM-Identity-Center

가시다 님과 함께하는 CASS 스터디를 시작했다.

첫시간은 OU / IAM과 함께하는 즐거운 시간.
MSP에서 OU는 열심히 익힌터라 좀 자신이 있었다. 그래서 나는 IAM Center를 써봤다.

검증할것은 이것이다. 지금까지는 각 계정에 역할을 생성하고, STS를 통해서 계정에 접근했다면 IAM Center에선 통합계정을 생성하여 OU에 연결된 루트계정들에 접근할수 있도록한다.

먼저 OU에 계정을 연결한다.

3개의 계정이 연결된것을 확인할수있다.

linxuer 계정이 Root OU를 관리한다.

linuxer 계정에서 IAM Identity Center서비스 로 이동한다. 그리고 사용자를 생성한다.

사용자를 생성할때 권한세트를 참조한다. 나는 AdministratorAccess 권한을 미리 생성해서 넣어줬다.

IAM Identity Center 에서는 이계정으로 OU의 하위 모든 계정을 관리한다 이과정에서 IAM Role Change가 필요하지 않다. 테스트하면서 정말 놀랐다.

계정을 생성하면 아래와 같은 메일주소가 온다.

내 포탈이라는 페이지로 이동하면 계정의 패스워드와 MFA를 설정할수 있는 페이지로 이동한다. MFA 잊지말고 설정하자

이포탈의 역할은 딱하나다.

로그인-MFA-다른계정의 콘솔접근-억세스키생성
편리하지만 위험하다. 단순 1회발급되고 휘발성을 가지던 억세스키가 페이지 안에선 변경되지 않고 여러차례 확인이 가능하다

보안에 특별히 유의가 필요하다!!!!!!!!

이서비스는 다음과 같은 메뉴만 제공한다. 미리 OU에서 SCP로 Linuxer2 계정의 S3를 제한해 놨다. linuxer2 계정에서 S3로 이동해 볼거다.

IAM Identity Center 계정도 정상적으로 제어된다. 그럼 Trail 에는 어떻게 표시될까?

signin.amazonaws.com 을통해 로그인한 계정을 추적할수 있다.

앞으로 OU를 사용하는 사용자는 IAM Identity Center를 이용해 다량의 작업을 편하게 할수 있음을 알았고 불편하게 역할 전환을 하게되는 경우가 없이 IAM Identity Center Console을 사용할수 있음 을 알수있었다.

새로운 보안의 공백이 될 수 있음을 염두에 두도록 하자.

읽어 주셔서 감사하다!

AWS FinOps - Intro

이번엔 FinOps에 대한 이야기를 할거다.

먼저 본론으로 들어가기 전에 FinOps에 대한 정의부터 이야기할까 한다.

우리가 흔히 알고있는 DevOps는 Development 과 operations 의 합성어 이다.
FinOps는 이 DevOps 에 Finance를 더한것이다. ( Finance + Development + Operations )
IT infra 상에서 발생하는 비용을 제어하고 투자하는 방식을 말하는것이다.

'투자' 라고 말하면 의아 할수도 있는데 클라우드 상의 자원은 무한하지만 사용자에게 할당된 비용은 유한하다.
그렇기에 제한된 비용내에서 적절한곳에 맞는 리소스를 투입하는것이 FinOps 에서 투자인것이다.

FinOps의 목적은 절약이 아니다.
FinOps는 제한적인 예산에서 낭비되는 비용을 줄여 리소스가 필요한곳에 투입하는것이 FinOps 목적인 것이다.
절약에서 '만' 끝난다면 지속적으로 줄여야하는 비용의 압박에 씨달릴 것이다.

또한 비용관리는 반드시 필요하나, 이 비용관리가 비즈니스의 편의성을 해치고, 확장성과 탄력성에 영향을 준다면 당신을 FinOps를 잘못이해 하고있는것이다.

예를 들어 RI를 구매 후 워크로드가 변화에도 불구하고 RI때문에 유연한 리소스를 사용하지 못한다면 잘못된 방식의 비용관리를 하고 있는 것이다. RI 때문에 서버추가에 대한 고민이나 원하는 유형의 인스턴스를 사용하지 못한다는 것은 클라우드를 사용하는 방식도 아니며, 이런경우 차라리 On-Premises로 의 회귀가 더 저렴할것이며 사용패턴도 맞을것이다.

차후 포스팅 할 내용에서는 먼저 가장 간단히 보고 절약할 부분부터 새로운 아키텍처가 필요한 부분까지 작성할 것이다.

FinOps의 세계가 얼마나 짜릿하고 즐거운 분야인지 같이 느껴보면 좋겠다.

함께 돈을 버는 엔지니어의 세계로 가보자.


Kubernetes-Mysql-Operator

Mysql Operator 스터디를 진행중에 느꼈다.
Mysql Operator는 현재 나의 판단보다 Operator의 로직이 훨신 빠르고 정확하게 동작할거라는 생각이 들었다.

다른말로는 믿고 써도 될수준에 가깝다 느껴졌다. 물론 RDS 못잃어

https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-introduction.html

그래서 나는 실습은 그냥..helm으로 다들 하는것 같아서 Operator가 생성하는 Mysql Cluster 의 아키텍처를 파해쳐 볼까한다.

DNS - SRV Record

https://www.haproxy.com/documentation/hapee/latest/management/service-discovery/dns-service-discovery/discovery-with-srv-records/

SRV 레코드는 자주 사용 되는 레코드는 아니지만, GSLB혹은 가중치를 이용한 라우팅, 페일오버 등에 사용된다.

수진님의 포스팅 링크

https://dev.mysql.com/doc/refman/8.0/en/connecting-using-dns-srv.html

정리하자면 Mysql Routor 에서 클러스터의 노드별로 srv레코드를 부여하고,

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-dns-srv.html

mysql 8.0.19버전에서 Connector 에서 또한 srv 레코드를 이용할수 있게되어서 Mysql 클러스터는 획기적으로 발전한것이다. 이전에는 mysql 의 HA를 구성하려면 FaceMaker 부터 시작해서 손이 갈부분이 만만치 않게 많았다.

오라클로 인수된 Mysql의 약진이 정말 기대이상이다.

X Protocol

https://dev.mysql.com/doc/internals/en/x-protocol.html

X Protocol 은 5.7.12 버전부터 플러그인으로 사용할수 있었다.

https://dev.mysql.com/doc/internals/en/x-protocol.html

X protocol 은 Life Cycle, Notifocation 등의 기능을 담당하는데, 이 프로토콜로 서버의 정상유무를 라우터나 오퍼레이터와 통신하여 처리한다.

https://dev.mysql.com/doc/internals/en/x-protocol-lifecycle-lifecycle.html

Backup

Backup는 다이렉트로 S3백업이 가능하다는 점이 인상적인데, 정말 바라던 기능이라 충격적일 정도이다.

https://github.com/bitpoke/mysql-operator/blob/master/docs/backups.md

다른 Operator 와 비교해보고 싶다면 아래 블로그를 참고하길 바란다.

https://portworx.com/blog/choosing-a-kubernetes-operator-for-mysql/

마치며

SRV레코드를 이용하여 Endpoint를 특정하고, X protocol을 이용하여 헬스체크를 하고, 문제가 생기면, 오퍼레이터가 파드를 다시 생성하는 등의 과정이 이루어 진다. 말로는 정말 간단하다. 하지만 이 아키텍처가 쿠버네티스의 탄력성과 신속성과 합쳐짐으로 강력한 시너지를 발생하는것으로 보인다.

사용자의 고민이 많이 없이 사용할수있는 레벨의 솔루션으로 진화한듯싶다.

그간 많은 엔지니어 들이 사랑하던 Mysql 의 진화가 반갑기만하면서..오라클의 품에 있는 My가 두렵다.

그래서 MariaDB Operator를 찾아보았다.

https://mariadb.com/kb/en/kubernetes-operators-for-mariadb/

그런데 MariaDB Operator는 이전에 Galera Operator라 불리던 작품인듯한다.

다음에 한번 테스트를 해봐야 겠다....근데 사용자가 정말 없는듯하다.

오퍼레이터 스터디로 인하여 컨테이너 디비에 대해서 새로운 관점이 생기는 것을 느낀다.