AWS MySQL Aurora 최대 접속수 수정방법

Leave a reply

오랜만에 Aurora MySQL의 최대 접속수를 다시 지정했다. 개발용도의 데이터베이스는 사용량은 작지만 여러 프로젝트들이 connection pool 을 생성하니 기본 정의값보다 올려서 사용하는 경우가 종종있다. max_connections를 다시 지정한 파라미터 그룹으로 교체하면 된다. 이건 TIL이라 할 것도 없다.

하지만 글로 남기는건 10분이면 될 일을 1시간이나 헤맸기 때문.

클러스터 파라미터그룹과 인스턴스 파라미터 그룹 양쪽에 max_connections가 있다.
파라미터 수정 후 apply immediately로는 동작하지 않아서 reboot 후 적용되었다.

변경된 수치는 다음쿼리로 확인가능하다.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|               300 |
+-------------------+
1 row in set (0.00 sec)

Jenkins 역할기반 전략으로 프로젝트 권한지정하기

Leave a reply

Jenkins의 Security Rule 중 Role Based 플러그인을 사용한 사용자 권한 설정을 했다.

Manage Jenkins > Configure Global Security 의 Authorization 에서 Role-Based Strategy를 선택한다.
(Enable security 상태)

Manage Jenkins > Configure Global Security > Authorization

이후 Manage Jenkins > Manage and Assign Roles 화면에서 역할을 추가하고 사용자에 역할을 지정할 수 있다.

Manage Jenkins > Manage and Assign Roles 메뉴

Manage Roles	역할을 추가, 편집, 삭제한다. 전역(Global)과 프로젝트별 역할이 있다.
Assign Roles	Manage Roles에서 생성된 역할을 사용자에게 지정한다.

역할에는 Global Roles(전역역할)과 Project Roles(프로젝트 역할)가 있다.
사용자는 기본으로 전역역할 중 하나를 가지고 프로젝트 역할을 별도로 가지게된다.

Manage Roles 지정방법

관리자용 역할(권한이름 admin)과 프로젝트별 역할(권한이름 Developers)을 분리했다고 가정하면 다음과 같이 Global Roles를 설정한다. Developers역할이 최소한 Overall / Read 권한을 가져야 워크스페이스 화면에 접근할 수 있다.

프로젝트 역할은 프로젝트 이름을 패턴으로 매칭한다. 매칭은 정규식패턴이 프로젝트 이름의 전체에 대해 대응해야한다. 작업했던 Jenkins의 프로젝트들은 모두 숫자를 기본으로 가지고 있어서 숫자매칭을 통해 지정했다.

Assign Roles지정

Assign Roles화면에서 Manage Roles에서 추가된 권한들을 확인할 수 있다. (사용자 이름을 추가한 후 확인할 수 있다.) 사용자 이름에 따른 Global roles와 Item roles를 지정할 수 있게 된다.

GCP BigQuery Schema 구성 팁

Leave a reply

생성은 CSV를 통하면 편리하다.

BigQuery의 테이블스키마는 생성할때 UI가 꽤 불편한 편이다. 그래서 텍스트로 편집 옵션이 있기도 하지만 타이핑하기 좋지 않은 신택스를 가지고 있어서 CSV업로드로 자동생성하는 편이 개인적으로는 가장 편했다.

CSV 파일 업로드는 10MB까지만, 그 이상은 Cloud Storage 등에서 가져와야 한다.

CSV가 다룰 수 있는 데이터 타입에는 한계가 있다. 예를들어 날짜시간 등을 사용하고자 하면 메뉴얼의 Limitation부분을 잘 읽어보고 활용해야한다.

테이블 변경은 쿼리결과 저장 기능으로

BigQuery는 ALTER TABLE 문을 지원하지 않는다. 따라서 잘못만들면 테이블을 다시 만들어야 한다. 이때 테이블로 결과를 보내는 쿼리결과 저장기능을 활용할 수 있다. 다시말해 SELECT * FROM 식으로 조회한 결과를 테이블로 보내는데, 자기테이블을 덮어씌우는 방법을 사용한다. 이때 AS를 사용해 리네임을, CAST 함수를 사용해 컬럼의 타입을 변경할 수 있다.

물론 이에 따른 데이터 조회 / 쓰기 비용은 발생한다.

레코드는 피하자

except() 함수 등을 활용할 때 레코드는 통째로 처리되어서 불편할때가 있다. 예를들어 http 응답을 response.status, response.body 등으로 담았다고 치자. response.body 는 덩치가 크니까 가져오지 말고 response.status만 원하면 SELECT * except(response.body) 는 동작하지 않는다. 원하는 필드명을 하나씩 명시해야 한다. BigQuery에서 필드 = 돈이다.

참고:
https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-csv#appending_to_or_overwriting_a_table_with_csv_data
https://cloud.google.com/bigquery/docs/manually-changing-schemas?hl=ko

AWS NAT 인스턴스의 가성비 확인

Leave a reply

AWS의 Private Subnet에 있는 인스턴스가 외부와 통신하려면 NAT를 활용해야한다. 그렇다면 NAT인스턴스를 만들어 사용할지, NAT 게이트웨이(Gateway, 이하 GW)를 사용할지 결정해야 한다.

AWS VPC 와 서브넷

VPC의 NAT Gateway 가격은 서울리전에서 $0.059 이다. 1달이 월 720시간이라면 Multiple AZ를 고려해 2개를 설치하면 월 $84.96, 약 10만원의 추가부담이 생긴다.

NAT Instance로 구성한다면 EC2 1년 선결제 없는 경우의 예약 인스턴스 사용시 c5.large, m5.large, t3.large 정도의 가격이다.

NAT GW는 기본 5Gbps의 대역폭을 지원하고 45Gbps까지 확장가능하다. 또 관리 소요가 줄어들기 때문에 AWS에서는 GW를 활용할 것을 권고하고 있다. 하지만 이런 수치는 트래픽에 따라 달라질 것이라 우리 회사의 경우 가격 부담없이 사용할 수 있을지 확인해보고 싶었다. 특히 t3.nano를 적용했을 때의 성능이 활용할만한지 궁금했다. AWS홈페이지에 나와있듯 t3.nano의 네트워크 대역폭은 최대 5Gbps 이다.

참고:
AWS, NAT 인스턴스 및 NAT 게이트웨이 비교
AWS, Amazon EC2 인스턴스 유형

적용방법

먼저 Public 서브넷의 호스트를 Private으로 옮긴 후 t3.nano 로 만든 NAT인스턴스를 각 AZ의 Public Subnet에 설치했다. 인스턴스의 AMI는 AWS 매뉴얼(참고: AWS, NAT인스턴스)에 설명된 대로 AWS에서 제공하는 AMI를 사용했다.

NAT 인스턴스 전송속도

아래 수치들은 백엔드끼리 연결된 타사와의 트래픽이다(서비스 트래픽은 로드밸런서에 연결되어있다). 제휴사와의 트래픽 중 HTTPS 단일 호스트에 200 OK 로 제한한 결과다.
결론부터 말하자면 현재 우리 트래픽으로는 t3.nano NAT인스턴스 사용시에도 큰 차이가 나지 않았다. 특히 T3계열 네트워크 속도가 “최대5Gbps” 이고 경험상 때때로 네트워크가 지연되는 경우도 자주 봤지만(소위 튕기는 현상), 이번에는 편차면에서도 크게 차이가 없음을 확인할 수 있었다.

참고)

Group: Before / After – 적용 전후
Count : 요청 및 응답수 (50만건 전후)
AVG: 평균 (ms 단위)
Min: 최소값(ms 단위)
Max: 최대값(ms 단위)
STDDEV: 표준편차(ms 단위)

NAT 인스턴스 리소스 사용률

AWS의 T계열은 CPU사용률을 고려해야한다. 하지만 현재로써는 설치된 NAT인스턴스의 CPU사용률이 높지 않아 만약 더 저렴한 인스턴스 타입이 나온다면 전환하는 것도 가능할 것으로 보인다.

마지막으로 비용은 t3.nano, 표준 1년 선결제 예약인스턴스, GP 8GB EBS 를 사용해 인스턴스 대당 월 $3.5가량, 2대에 $7로 NAT GW의 $84.96에 비해 크게 비용을 아껴 구성할 수 있었다.

트래픽의 크기에 따라 다르겠으나 t3.nano 로 현재 트래픽에 대응되는 것을 확인했다. 비용면에서도 훨씬 저렴하기 때문에 소규모 스타트업이라면 적용해 보는 것을 추천한다.

AWS VPC 와 서브넷

Leave a reply

AWS 의 VPC는 리전 내에 위치하고 서브넷은 AZ내에 위치한다.

한 VPC에 AZ에 대해 여러 서브넷을 둬서 고가용성(HA)를 확보할 수 있다.

서브넷의 통신 방법은 VPC의 라우팅 규칙(Route Tables)을 따른다.

라우팅 규칙은 아이피 대역(CIDR)에 따라 타깃을 설정할 수 있고, 서브넷에 붙이는(associate) 방식으로 서브넷의 통신 방법을 설정할 수 있다. 서브넷과 라우팅 규칙은 1:n 관계이다. 각 서브넷은 한개의 라우팅 규칙을 붙일 수 있고 한 라우팅 규칙은 여러 서브넷에 적용될 수 있다.

이 라우팅 규칙을 통해 VPC Peering이나 Public Subnet, Private Subnet의 설정을 할 수 있게 된다.

인터넷 게이트웨이(IGW) / Public Subnet / Private Subnet

IGW는 VPC와 인터넷을 이어주는 가상 게이트웨이이다.

라우팅 규칙을 통해 IGW에 연결된 서브넷은 Public Subnet, 그렇지 않은 서브넷은 Private Subnet이라 한다.

Private Subnet 내의 인스턴스들은 Public IP를 갖지 않고 인터넷에 직접 노출되어있지 않다. Private Subnet에서 인터넷에 아이피가 노출되지 않으면서 인터넷에 접속하려면 NAT를 사용해야 한다.