테스트용 데이터베이스를 만들고 지우다가 혹은 콘솔에서 클릭을 잘못해서 우발적으로 데이터베이스를 삭제하는 경우를 막고자 추가된 기능입니다. EC2 에서는 제공되고 있던 기능으로 RDS 는 실수로 지웠을경우 그 파장이 크기 때문에 이런 옵션의 추가는 사용자 입장에서 좋습니다.
이 기능은 모든 AWS 리전의 Amazon Aurora, RDS for MySQL, MariaDB, Oracle, PostgreSQL, SQL Server 에 대해 지원됩니다.
운영중인 DB에 삭제 보호를 활성화시 서비스 영향
삭제 보호 기능이 좋다고는 하지만 삭제 보호 기능을 위해 DB 서비스가 중단된다면 바로 적용하기는 곤란합니다. 그래서 확인 해보니 운영중인 DB에 삭제 보호 기능을 활성화 하더라도 DB 인스턴스의 상태가 바뀌지 않았습니다.
RDS 콘솔에서 DB 인스턴스 수정 페이지 아래쪽의 “삭제방지”를 활성화 하고 다음 버튼을 눌러 봅니다.(AWS 콘솔 번역은 삭제 방지라고 되있지만 저는 그냥 삭제 보호라고 하기로… AWS 블로그에도 삭제 보호라고 되있기도 하구요.)
그리고 즉시 적용을 하면 같이 예기치 않은 잠재적 다운타임이 있다고 나오는데요. 이 메시지는 그냥 항상 보여주는것으로 즉시 적용 해도 DB 인스턴스의 상태가 변하지 않고 적용됩니다.
활성화 된다음에 DB를 삭제하려고 하면 보호 옵션이 활성화 되있다는 메시지와 함께 삭제를 할 수 없습니다.
지금 바로 적용하기
거의 모든 서비스의 제일 중요한 부분은 DB라고 해도 과언이 아니라고 생각합니다. 지금 당장 운영중인 RDS 에 삭제 보호 방지를 활성화 하세요!
게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^
개발하다보면 개발서버 혹은 운영중인 DB 서버의 데이터를 이용해야 하는 경우가 있습니다. 이런 경우 PostgreSQL 에서는 pg_dump, pg_restore를 이용해 백업 및 복원을 진행합니다.
전체 DB를 백업하고 복원하는것은 어렵지 않지만 특정 테이블 하나만 적용하려고 보면 왜래키(Foreign key) 제약 조건으로 인해 복원이 실패하는 경우가 발생합니다. MySQL 의 경우는 외래키 제약 조건을 임시로 중단할수 있는 SQL이 있지만 PostgreSQL 에서는 여러가지 방법을 찾아 봤지만 모두 실패 했고 하나의 성공 방법을 찾았습니다.
monsters 라는 테이블을 운영 DB에서 받아와서 개발 DB에 반영 한다면 아래와 같은 절차로 진행합니다.
cascade 옵션은 다른 테이블에서 외래키로 참조하고 있는 제약 조건을 같이 삭제합니다. 실행하면 아래와 같이 외래키 제약 조건이 같이 삭제되었다는 메시지가 출력됩니다.
NOTICE: drop cascades to 4 other objects
DETAIL: drop cascades to constraint xxx on table regions_111
drop cascades to constraint yyy on table regions_222
drop cascades to constraint zzz on table regions_333
drop cascades to constraint qqq on table regions_444
DROP TABLE
현재 프로젝트 폴더 아래 .direnv/terraform/bin 폴더를 생성하고 1번에서 다운로드 받은 파일을 복사합니다.
.envrc파일에 다음 내용을 추가합니다.
load_prefix $(direnv_layout_dir)/terraform
direnv allow 명령어를 실행하여 환경변수를 새로 로딩합니다.
이제 which terraform 명령어를 실행하면 전역으로 설치된 Terraform 이 아닌 현재 폴더에 복사된 Terraform 버전의 실행파일을 바라보고 있음을 알수 있습니다.
두번째 방법 : brew switch 이용
이 방법은 Mac에서만 사용가능 합니다.
brew install terraform 명령어를 이용하면 항상 최신버전의 terraform이 설치됩니다.
현재 설치된 버전이 0.11.8 이고 구버전이 0.11.7 인경우 두 버전을 동시에 사용하는 방법입니다.
/usr/local/Cellar/terraform 폴더로 이동
새로 추가하려는 버전의 이름으로 폴더 생성(ex 현재 최신버전은 0.11.8 이고 설치하고 싶은 구버전은 0.11.7인 경우 0.11.7 이름으로 폴더 생성)
생성한 폴더 아래 bin 폴더를 생성하고 해당 버전의 Terraform 실행파일을 홈페이지에서 다운로드후 복사
이제 brew switch terraform 0.11.7 명령어를 실행하면 0.11.7 버전으로 변경되고 brew switch terraform 0.11.8 명령어를 실행하면 0.11.8 버전으로 변경됩니다.
정리
두가지 방법 각자의 장단점이 있는데요. 저는 현재 두번째 방법을 사용하고 있습니다.
첫번째 방법의 경우 .direnv 폴더 아래 Terraform 실행파일과 .envrc 파일 모두 버전관리에 포함시킨다면 다른 컴퓨터에서도 바로 사용할 수 있는 장점이 있습니다. 다만 프로젝트에서 이런방식으로 사용할것을 서로 약속해야하고 버전 업그레이드할때 마다 실행파일을 복사해야 합니다.
두번째 방법의 경우 일반적으로 많이 사용하는 brew 를 이용해서 편하지만 여러개의 Terraform 프로젝트가 있다면 그때마다 switch 를 수동으로 입력해야 하고 Mac 에서만 가능하다는것이 단점입니다.
각각 장단점이 있는데 각자 상황에 맞는 방법을 선택하면 되겠습니다.
게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^
빅쿼리를 사용하다 보면 불필요해진 컬럼이 있어서 삭제하고 싶은 경우가 있습니다. 컬럼을 삭제하지 않고 그냥 둬도 되겠지만 보기에 별로고 데이터 저장비용도 많이 들어갈테니 깔끔하게 삭제하는것이 좋습니다.
빅쿼리에서 테이블 컬럼을 삭제하는 2가지 방법이 있습니다.
1번 : SQL 쿼리를 이용해서 삭제하고자 하는 컬럼을 제외한 모든 데이터를 조회하고 결과를 기존 테이블에 덮어쓰기
2번 : 데이터를 Export 해서 클라우드 스토리지에 저장하고 데이터에서 컬럼을 삭제후 Load job 이용해서 기존 테이블에 덮어쓰기
기존 테이블에 덮어쓰기를 한다는 점에서는 어차피 둘다 동일한 방식입니다.
1번 방법은 데이터 조회에 따른 데이터 스캔 비용이 발생합니다. 2번 방법은 Export, Load job에 대해 비용은 없지만 스토리지 비용이 조금 발생합니다.
현재 저장된 데이터의 크기에 따라 적절한 방법을 선택하면 되겠습니다. 비용을 지불하더라도 편한 방법을 선택하고자 하면 1번을 데이터가 많아서 비용이 부담스럽다면 2번 방법을 선택하면 되겠습니다.
이 글에서는 1번 방법을 이용한 컬럼 삭제를 소개하겠습니다.
#standardSQL
SELECT
* EXCEPT(top_results)
FROM
테이블 이름
위의 쿼리를 입력후 ‘Show Options’ 를 클릭하고 ‘Destination Table’에 덮어쓰기할 테이블을 선택합니다.
‘Write Preference’는 ‘Overwrite table’을 선택합니다.
이렇게 선택한후 ‘Run Query’ 버튼을 클릭하면 작업이 시작되고 완료되면 기존 테이블에서 컬럼이 삭제됩니다. 이 작업은 데이터 크기에 따라 시간이 오래 걸릴수 있습니다.
생각보다 쉽죠? 하지만 결정적인 단점이 있습니다.
테이블을 생성할때 ‘Partitioning Type’을 지정해서 사용하는 경우 _PARTITIONTIME 필드가 모두 현재시점으로 변경되어 버립니다. 이렇게되면 데이터 스캔 비용 절약을 위해 _PARTITIONTIME를 사용하는 쿼리들에서 잘못된 결과가 나올수 있습니다. 테이블 데이터 크기가 큰경우 _PARTITIONTIME이 한날짜로 리셋되버리는것은 향후 쿼리 비용에 있어 많은 비용을 감당해야되는 상황이 발생할 수 있습니다.
기존 테이블을 계속 유지하고 새로운 테이블에서는 컬럼을 삭제한 상태로 새롭게 데이터를 쌓아가는것도 방법이 될수 있겠습니다.
Xcode를 이용해 개발을 하다보면 cocoapod를 이용해 외부 라이브러리를 사용하게 되는데요. Swift 언어가 계속해서 발전하다보니 새로운 버전에서 deprecated 되는것들이 많아져서 1년만 지나도 꽤 많은수의 경고문구를 보게 됩니다. 내 프로젝트의 경우 소스코드를 직접 수정하면 되지만 외부 라이브러리들은 해당 프로젝트의 상황에 따라서 경고되는 항목들을 고치지 못하는 경우가 많습니다.
이렇게 되면 어느순간부터 내 프로젝트의 빌드 경고창에는 외부 라이브러리들의 경고가 많아져서 내 프로젝트의 경고가 묻히고 수정해야 된다는 사실을 인지하지 못하게됩니다.
위의 경우 총 58개의 경고가 있는데 이중 56개는 외부 라이브러리들의 경고표시입니다. 내 프로젝트의 경고표시는 제일 아래쪽에 2개가 위치합니다. 또한 경고문구는 기본으로 펼쳐져 있어서 스크롤을 아래까지 해야 겨우 볼 수 있습니다. 프로젝트가 커져서 사용하는 외부 라이브러리가 많아지면 경고는 300개를 넘는경우도 있습니다.
다행히도 이 문제를 해결할 방법이 있습니다. cocoapod의 경우 Podfile에 아래 내용을 추가해서 Pod 프로젝트들에 대해 경고가 표시되지 않도록 설정 할 수 있습니다.
inhibit_all_warnings!
전체 Podfile 의 샘플을 보면 다음과 같은 식입니다.
platform :ios, '9.0'
target 'MyProject' do
use_frameworks!
inhibit_all_warnings!
pod 'Alamofire', '~> 4.5'
end
전체 Pod이 아닌 특정 Pod의 경고만 표시하지 않으려면 pod 선언할때 옵션으로 선언합니다.
pod 'Alamofire', '~> 4.5', :inhibit_warnings => true
Podfile 을 수정하고 pod install 을 다시 실행한후 Xcode 프로젝트에서 빌드를 다시하거나 클린빌드를 하면 기존에 보이던 Pod 프로젝트의 경고표시가 모두 사라진것을 볼 수 있습니다.
이 옵션은 pod init 으로 Podfile을 처음 생성할때 기본으로 들어가면 좋을것 같은데 기본 옵션은 아닙니다.
유튜브
달구지 코딩이라는 유튜브 채널을 만들어서 운영중입니다. 이 포스트 내용은 아래 유튜브 영상에서도 확인할 수 있습니다. 유튜브 구독 부탁드려요 ^^
.bot 도메인 등록을 대행하는 EnCirca 사이트의 설명을 보면 현재는 Landrush 2 기간으로 .bot 도메인 등록을 아무나 할 수 없고 봇을 운영중인지 확인후 등록할 수 있는 권한을 주는것으로 보입니다. 봇을 운영중인지 확인하는 것은 Amazon Lex, Microsoft Bot Framework, Dialogflow, Pandorabots, Gupshup, Botkit Studio 등 봇 관련 서비스들과의 연동을 통해서만 가능합니다.
아마도 2018년 5월 31일 이후에는 봇을 운영중인지 확인작업 없이 일반 도메인 처럼 등록되지 않을까 싶은데 확실한 정보는 아닙니다.
슬랙(Slack)을 자주 사용하다 보면 여러가지 연동을 하게 됩니다. 서버나 특정 상태에 따라 슬랙에 메시지를 보내는데요. 연동도 쉬워서 사용 할수록 더 많은 연동을 하게 됩니다.
이번에 소개하려는 slackboard는 슬랙에 메시지를 전송할때 아쉬운 부분을 해결해주는 기능을 가지고 있습니다. slackboard의 주요기능은 다음과 같습니다.
커맨드 라인에서 쉽게 메시지 전송
쉘 스크립트가 비정상적으로 종료됬을때 슬랙 메시지 전송
태그 이름만으로 미리 지정한 채널이름, 사용자 이름, 이모지 설정
QPS 제어 기능
이중 slackboard를 꼭 써야하는 이유중 하나는 마지막의 QPS 제어 기능입니다. 일반적으로 사용하는 슬랙의 Incoming webhooks의 경우 초당 1건의 메시지로 제한되어 있어서 1초에 메시지를 여러개 전송하면 일부 메시지가 유실될 수 있는데 slackboard의 QPS 제어 기능을 이용하면 메시지가 유실되지 않게 분산해서 전송합니다.
유튜브 영상으로도 촬영 했으니 참고하세요.
그외 장점 및 사용헤 대해서도 하나씩 알아 보기 전에 설치 방법을 알아 보겠습니다.
서버 설치
slackboard는 프록시 서버를 설치해야 하는데요. golang으로 작성되어 있어 사전에 go 언어를 빌드 할 수 있도록 준비해야합니다. go 언어가 설치 됬다면 아래 명령어로 slackboard 를 설치합니다.
아마존 웹서비스를 사용하다보면 사용중인 서비스를 모니터링 하기 위해 CloudWatch 를 한번씩은 사용하게 됩니다. 많은 지표들이 제공되지만 제공되는 지표에 몇가지 더하거나 조합하는 경우 이번에 소개하는 Metric Math 를 이용합니다.
RDS Total IOPS 수치 확인하기
RDS의 모니터링을 예로 들어보면 Read IOPS, Write IOPS라는 지표를 별도로 제공하는데 RDS의 IOPS 제한은 Read와 Write IOPS를 더한값으로 적용됩니다. 그래서 Total IOPS를 알고 있는것이 중요한데 CloudWatch 에서는 Total IOPS를 지표 정보로 제공하지 않습니다.
저 같은 경우 기존에는 Total IOPS를 모니터링 하기 위해 1분마다 Read IOPS와 Write IOPS를 조회하고 다시 Total IOPS라는 새로운 지표로 CloudWatch에 저장하는 작업을 하고 있었습니다. 하지만 Metric Math 기능을 이용하면 더이상 이렇게 할 필요가 없습니다.
CloudWatch 대시보드 혹은 Metrics 에서 RDS 를 선택하고 Read IOPS, Write IOPS를 각자 설정후 Graphed metrics 탭을 선택하고 테이블 상단의 Add a math express 버튼을 클릭합니다.
클릭하면 테이블 목록 상단에 e1 이라는 id를 가진 행이 추가되고 Details에는 SUM(METRICS()) 라고 입력됩니다. 이 수식의 의미는 현재 선택된 지표들을 모두 더한다는 의미입니다. 이 경우 Read IOPS + Write IOPS 인거죠. 수식을 이해하기 쉽게 m1 + m2로 변경해도 동일한 의미가 됩니다. 여기서 m1, m2는 각 행의 id 값입니다.
Total IOPS만 그래프에 표시하기 위해 체크 박스에서 e1 을 제외한 m1, m2는 체크를 해제하면 위와 같이 Total IOPS만 그래프에 표시되는것을 확인할 수 있습니다.
ElastiCache Hit Rate 계산 하기
ElastiCache 의 Hit Rate를 계산하는 것도 Metric Math를 이용하면 유용한 수치입니다. 캐시가 적당하게 잘 되고 있는지 볼 수 있는 유용한 지표가 Hit Rate인데 CloudWatch에서는 제공되지 않습니다.
이제 직접 Hit Rate를 계산해 보겠습니다.
Metrics 에서 모니터링을 원하는 ElastiCache 인스턴스의 Get Hits, Get Misses를 선택하고 앞서 했던 것처럼 Add a math express 버튼을 클릭합니다. 수식 입력란에 (m1 / (m1 + m2)) * 100를 입력하고 m1, m2의 그래프 체크박스를 해제하면 Hit Rate를 볼 수 있습니다.
정리
CloudWatch는 AWS 서비스를 이용하다 보면 한번쯤 접하게 되고 모니터링이나 알림 용도로 자주 사용하게 됩니다. 하지만 제공하지 않는 지표가 있거나 여러 지표를 조합하고자 하는 경우 불편한점이 있었는데 Metric Math 기능으로 인해 사용하기 편해졌습니다.
아쉽게도 현재는 수식이 적용된 지표에 대해서는 알림 기능을 제공하지 않습니다. 알림을 받고 싶다면 기존 방식처럼 별도의 CloudWatch 지표를 매분 마다 생성해야합니다.
이 내용은 제가 운영하는 유튜브 채널인 달구지코딩에서도 확인할 수 있습니다. 구독과 좋아요 부탁드립니다 ^^