데이터베이스 마이그레이션은 참 번거로운 작업입니다. 상황에 따라서는 메인터넌스를 걸고 서비스를 잠시 중단해야 할 수도 있고 그걸 원하지 않는다면 dual-write 등의 수단을 통해 데이터베이스를 싱크업 하는 과정을 수행해야만 합니다.
마이그레이션이 이번 글의 주제는 아닙니다. 다만 마이그레이션이 필요하지만 메인터넌스 윈도우를 만들고 싶지 않아 데이터베이스를 매뉴얼하게 옮기는 것을 고민하다 문득 <데이터베이스의 모든 테이블 레코드 갯수를 한번에 뽑고 싶다>는 자체 요구사항이 생겨 확인한 내용을 정리해 봅니다.
데이터베이스의 모든 레코드 갯수 쿼리
데이터베이스에 있는 모든 테이블의 레코드 갯수를 카운트 하는 것은 아래의 쿼리를 통해 수행할 수 있습니다.
SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '##데이터베이스이름##';
모든 테이블 단위로 레코드 갯수 그룹화하는 쿼리
데이터베이스 내에 테이블이 많다면 각 테이블별로 레코드 갯수를 카운트 하고 싶을지도 모릅니다. INFORMATION_SCHEMA.TABLES 가 갖고 있는 몇 가지 컬럼을 활용해서 Group By 하면 쉽게 쿼리할 수 있습니다.
SELECT TABLE_NAME, TABLE_ROWS
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '##데이터베이스이름##';
개발자의 컴퓨터는 항상 좋은 퍼포먼스를 내는 장비여야 합니다. 개발 도구도 나날이 무거워지고 언어나 런타임시에 사용하는 가상환경도 많은 리소스를 요구하기 때문입니다. 다만 좋은 장비를 새로 지급받거나 구매해서 쓰게되면 손에 착착~ 감기게 맞추어둔 개발 환경을 동일하게 맞추는 스트레스가 발생하기 마련입니다.
제가 주력 개발도구로 사용하고 있는 것은 비주얼 스튜디오 코드 Visual Studio Code 입니다. 상용 개발도구가 아닌 부문에서는 이미 압도적인 사용 점유율을 보이고 있는데요, 워낙 이사람, 저사람, 이 글, 저 글을 통해 얻은 정보들로 환경을 셋업해둔 탓에 새로 받은 장비에 설치하기가 겁나더군요.
하지만, 우리의 사랑 마이크로소프트는 비주얼 스튜디오 코드의 개발 환경을 동일하게 맞추어주는 도구를 내장해 두었습니다. 이름하여 <Setting Sync> 기능입니다. 이 기능은 원격지에 비주얼 스튜디오 코드의 환경 정보를 저장하고, 동일한 계정으로 로그인하는 비주얼 스튜디오 코드들에 대하여 환경 정보를 동기화 하도록 합니다.
1단계 - 원본 컴퓨터에서의 작업
당연하겠지만 우리가 제일 먼저 해야 할일은 원본 컴퓨터 혹은 환경 셋업이 되어 있는 컴퓨터에서 개발 환경 정보를 <Setting Sync> 기능을 통해 원격지에 저장하는 것입니다. 비주얼 스튜디오 코드를 실행하고 아래의 단계를 따라하면 손쉽게 설정할 수 있습니다.
<Settings Sync> 기능 활성화하기
우선 <Settings Sync> 기능을 활성화 해보겠습니다. 비주얼 스튜디오 코드의 좌측 하단의 프로필 이미지를 누르면 <Turn on Settings Sync...> 메뉴가 있습니다. 선택해보겠습니다.
잘 동작하는 기능입니다만 아직 프리뷰 Preview 단계이기 때문에 간단한 동의 절차를 거쳐야 합니다. 문서를 읽어 보시거나 <Turn On> 버튼을 눌러 동기화 기능을 활성화 합니다.
<Turn On> 을 누르면 <Settings Sync> 커맨드 팝업이 뜹니다. 동기화할 항목을 선택할 수 있으며 저는 완전히 동일한 환경을 만들기 위해 모든 항목을 선택된 상태 그대로 두었습니다. 로그인 되어 있지 않기 때문에 <Sign in & Turn on>를 눌러 로그인을 하고 동기화 기능을 활성화 하겠습니다.
사용할 수 있는 로그인 방법은 두가지 입니다. 마이크로소프트 계정이나 깃헙 계정을 이용할 수 있습니다. 개발자라면 깃헙 계정을 대부분 가지고 계실테니 저도 깃헙 계정으로 해보겠습니다. 깃헙에서 종종 보셨을 권한 승인 절차를 거치면 연동이 완료됩니다.
깃헙에서 Continue 를 눌러 주시고...다시 비주얼 스튜디오로 돌아가도록 팝업 승인을 하거나 토큰 창의 URL 을 브라우저에 붙여넣고...비주얼 스튜디오 코드에서 Open 을 눌러줍니다.
승인 절차가 완료되면 비주얼 스튜디오 코드는 선택된 환경 설정에 대한 동기화 작업을 시작합니다. 동기화가 완료되면 비주얼 스튜디오 코드 우측 하단에 알림이 표시되며 <Show log> 링크를 눌러 상세한 동기화 내용을 확인할 수 있습니다.
열심히 동기화를 잘 했군요. 굿좁!
최초 한번은 이렇게 동기화가 되고 이후 동기화에 대한 설정을 하려면 Mac 기준으로 <shift>+<command>+<p>를 눌러 커맨드 팔레트를 열어 <Settings Sync> 기능을 열어야 합니다. 아래 화면에서 <Show Settings>를 눌러보겠습니다.
사이드바가 열리며 현재 동기화 된 설정의 내용을 확인할 수 있습니다. 이제 원래의 컴퓨터에서 해야 하는 작업은 마무리가 되었습니다. 항상 동기화가 되기 때문에 언제든 원래 컴퓨터에서 환경 설정을 바꾸면 원격지에 동기화되어 다른 컴퓨터에도 변경된 내용이 반영되게 됩니다.
2단계 - 새로운 컴퓨터에서의 작업
새로운 컴퓨터에서의 작업도 크게 다르지 않습니다. 비주얼 스튜디오 코드를 실행하고 깃헙 계정으로 로그인하여 동기화된 환경 설정을 가져오도록 해보겠습니다. 원본 컴퓨터에서 했던 작업과 마찬가지로 프로필 이미지를 눌러 <Turn on Settings Sync...> 메뉴를 실행합니다.
꼼꼼하고 친절한 마이크로소프트는 이번에도 기능이 프리뷰라는 것을 알려주고 정말로 켤 것인지를 한 번 더 확인하게 합니다. 우리는 과감하게 <Turn On>을 눌러 동기화 작업을 하겠습니다. 네, 모든 것이 완전히 동일하니 따로 설명하지 않고 스크린 샷으로 대치하겠습니다.
<Turn On> 을 누르고...<Sign in & Turn On> 을 누르고...원본 컴퓨터에서 쓴 것과 동일한 계정을 선택하고...여기까지 왔는데 승인 안하면 안되니 <Continue>를 누릅니다.스샷이 하나 빠졌는데... 여튼 확인하고 <Open>합니다.동기화가 빠르게 완료되었네요!
계정으로 로그인 하고 동기화가 완료되면 원본 컴퓨터에서와 마찬가지로 <shift>+<command>+<p>를 눌러 <Settings Sync> 기능을 열어봅니다. 재미있는 것은 커맨드 팔레트에서 사용했던 히스토리까지 넘어와 있는게 보입니다. 바로 설치한 비주얼 스튜디오 코드인데도 말이죠!
<Settings Sync> 내용을 보면 각 항목이 여러개 나와 있는 것이 보입니다. 같은 항목에 대하여 여러번 동기화가 된 경우 히스토리 성으로 그 내역이 동기화 되고 리스트화 되어 보이는 것으로 추정됩니다 -_-;; (네, 프리뷰입니다 여러분! 오류일수도 있지만 저는 마이크로소프트를 믿습니다!!)
왼쪽 하단의 <Synced Machines> 목록을 보면 원래의 컴퓨터와 새로운 컴퓨터가 목록에 보입니다. 알아보기 힘드니 눈에 익숙하도록 이름을 바꾸어 두었습니다.
이렇게 새로운 장비에 비주얼 스튜디오 코드를 설치하고 기존의 개발 환경을 그대로 옮겨와 봤습니다. 생각보다 쉬운 절차이고 앞으로도 유용하게 사용할 수 있을 것 같은 느낌입니다. 어렵게 한 땀, 한 땀 환경 설정을 옮기지 마시고 쉽게 동기화해서 셋업 시간을 아껴보시기 바랍니다! 보다 자세한 내용은 아래의 공식 문서를 참고하세요!
지난 포스팅에서 안드로이드 스튜디오를 업데이트하고 플러터 플러그인을 설치해보았습니다. 추가된 플러그인을 통해 샘플 프로젝트를 만들고 실행을 해보았지만 예상대로 문제가 발생했고, 안드로이드 가상 장치에서 시험을 해볼 수 없었습니다. 무슨 문제가 있었던 것일까요?
안드로이드 스튜디오에서 플러터 프로젝트를 생성하고 기본 샘플 앱을 가상 안드로이드 기기로 실행했을때 발생한 에러 화면입니다. 뭔가 SDK와 관련된 라이센스가 제대로 적용이 안된 것 같은 에러메세지입니다. 바로 터미널을 실행하여 플러터 닥터 flutter docter 명령을 통해 문제점을 확인해 보았습니다. 명령은 터미널에서 flutter docter 를 입력하여 수행합니다.
초록색 체크표시가 된 것들은 문제가 없는 부분들입니다. 느낌표로 출력된 내용을 보니 비주얼 스튜디오 코드를 위한 플러터 환경 구성 이후 변경된 것들이 좀 있어 보입니다. 가장먼저 Android toolchain 항목에 대한 명령을 통해 첫번째 문제를 해결해 보겠습니다.
flutter doctor --android-licenses
위의 플러터 닥터 명령은 동의해야 하는 약관, 라이센스에 대한 확인을 해주는 명령입니다. 실행후 나오는 내용을 살펴보고 (영어입니다 -_-;) 동의한다는 의미로 y 키를 몇 번 눌러주면 됩니다. 다시 닥터를 실행해서 처리가 잘 되었는지 보겠습니다.
오호라. 첫번째 Android toolchain 항목도 이제 초록색 체크로 바뀌었습니다. 플러터로 개발된 코드를 iOS 에서 실행할 수 있도록 하기 위해서는 Xcode 환경도 준비가 되어 있어야 합니다. 지난번에도 CocoaPods 설치하느라 고생했는데... 그래도 다시 한 번 해보았습니다.
# sudo gem install cocoapods
Password:
Fetching i18n-1.8.9.gem
Fetching tzinfo-1.2.9.gem
Fetching activesupport-5.2.4.5.gem
Fetching nap-1.1.0.gem
Fetching fuzzy_match-2.0.4.gem
Fetching concurrent-ruby-1.1.8.gem
...
...
Parsing documentation for gh_inspector-1.1.3
Installing ri documentation for gh_inspector-1.1.3
Parsing documentation for ruby-macho-1.4.0
Installing ri documentation for ruby-macho-1.4.0
Parsing documentation for cocoapods-1.10.1
Installing ri documentation for cocoapods-1.10.1
Done installing documentation for concurrent-ruby, i18n, thread_safe, tzinfo, activesupport, nap, fuzzy_match, httpclient, algoliasearch, ffi, ethon, typhoeus, netrc, public_suffix, addressable, cocoapods-core, claide, cocoapods-deintegrate, cocoapods-downloader, cocoapods-plugins, cocoapods-search, cocoapods-trunk, cocoapods-try, molinillo, atomos, CFPropertyList, colored2, nanaimo, xcodeproj, escape, fourflusher, gh_inspector, ruby-macho, cocoapods after 25 seconds
34 gems installed
자, 코코아포드 관련한 패키지들의 추가도 끝났으니 다시 flutter docter 를 실행해 봐야겠죠?
에러 메세지가 확~ 사라졌습니다. 이제 마지막으로 남은 것은 안드로이드 스튜디오에서 플러그인을 설치하는 일입니다. 에..? 플러그인? 분명히 설치했다고 생각했는데... 무슨 문제일까요? 일단 에러 메세지를 무시하고 코드를 안드로이드 에뮬레이터에서 실행해 보겠습니다. 희안하게도 문제 없이 실행이 됩니다.
어렵지 않죠? 네, 저는 어렵습니다 ㅎㅎ. 일단 동작이 잘 되는 것을 확인했으니, 본격적으로 뭔가를 만들어 봐야겠습니다!
grafana 를 쓰면서 각 차트에 alert 를 걸어두는 경우가 종종있습니다. alert 는 기본적으로 텍스트 메세지 템플릿을 사용하기 때문에 이미지가 포함되어 있지 않습니다. 그런데 쓰다보면 항상 알람을 받고 grafana 에 접속해서 차트를 확인하는 일이 빈번하게 발생합니다. false alert 때문에 이런 동작을 반복하다보면 alert 를 무시하다 사고로 이어지는 경우도 생기죠.
문득 든 생각이 <alert 메세지가 차트가 보이면 좋겠구먼> 이었고 공식 가이드에 기술된 내용에 따라 설정을 해보기로 했습니다. 대략 방식을 보면 헤드리스 브라우저를 띄우고 해당 차트에 진입해서 png 파일을 생성해주고 고유 URL 을 만들어 주는 방식처럼 보입니다. 자세한 건 실제로 돌려봐야 알 수 있겠죠?
rpm 으로 설치해서 그런것인지 OS 버전을 인식하지 않고 메세지를 내보내는 건지 모르겠습니다만, 플러그인 설치후 CentOS 6.x 기준으로 작성된 service 명령 안내가 나옵니다. 7.x 이후 버전을 쓰고 계시다면 아래와 같이 grafana 서버를 재기동 해주셔야 합니다.
$ sudo systemctl restart grafana-server
차트를 이미지 파일로 렌더링하기
플러그인 설치후 grafana 재기동까지 끝났다면 이제 렌더링이 잘 되는지 시험해 볼 차례입니다. 화면을 그냥 캡쳐하는 것과 무엇이 다르냐 하겠습니다만, 우리의 목적은 단순 캡쳐가 아니라 alert 메세지에 이미지를 포함시키는 것이 목표임을 잊지 마시기 바랍니다.
각 차트 상단의 toggle 버튼을 누르면 팝업 메뉴에서 `Share` 를 찾을 수 있습니다. 이 버튼을 누르면 나오는 `Share Panel` 에서 가장 아래에 있는 `Direct link rendered image` 버튼을 누르면 짠~ 하고 이미지가 나와야 합니다. 네, 꼭 나와야 합니다. ㅜㅜ
하지만 신은 저를 버리셨는지 차트가 나오지 않고 에러 페이지가 나왔습니다. 무엇이 문제인지 상세히 알려주지 않기 때문에 지금부터 grafana 와 렌더링 오류에 대한 원인을 찾기 위해 씨름을 좀 해야 합니다.
grafana 렌더링 관련 디버그 로그 설정
공식 가이드에서는 디버깅을 위해 grafana.ini 의 [log] 항목에서 이미지 렌더러를 필터로 걸어서 쓸 것을 권고 하고 있습니다. 하지만 꼭 그렇게 설정하지 않아도 에러 로그를 확인하는데는 문제가 없습니다. 하지만 필요하다면 아래의 내용대로 grafana.ini 를 수정하고 재기동 하면 되겠습니다. 참고로 grafana.ini 의 경로는 패키지 설치 기준으로 `/etc/grafana/grafana.ini` 입니다.
[log]
filters = rendering:debug
제 경우 굉장히 명확하게 에러가 나왔기 때문에 디버그로 설정할 필요는 없어 보였습니다. grafana 인스턴스와 이미지 렌더러 플러그인이 동일 머신에서 실행중이었기 때문에 localhost 콜을 했지만 https 로 호출된 것이 이유였습니다. 인증서 정보가 맞지 않아 ERR_CERT_COMMON_NAME_INVALID 에러가 발생한 것을 확인할 수 있습니다. 참고로 에러 로그의 경로는 `/var/log/grafana/grafana.log` 입니다.
SSL 인증서의 문제는 해결이 어렵지 않습니다. grafana-image-renderer 가 사용할 프로토콜은 grafana.ini 에서 지정할 수 있습니다. grafana.ini 파일을 열고 아래와 같이 설정하시기 바랍니다. 로컬 환경에 대한 설정이기 때문에 https 연결 과정의 에러를 무시해도 괜찮습니다.
재기동이 완료되면 앞서 진행했던 것처럼 차트에서 Share 메뉴를 선택하고 `Direct link rendered image` 를 선택합니다. 이번에는 문제 없이 이미지가 화면에 출력되었습니다. 이렇게 생성된 PNG 파일은 아래의 경로에서 확인할 수 있습니다.
$ sudo ls -al /var/lib/grafana/png
total 444
drwx------ 2 grafana grafana 134 Jan 21 10:53 .
drwxr-xr-x 5 grafana grafana 66 Jan 21 12:04 ..
-rw-r--r-- 1 grafana grafana 111403 Jan 21 10:46 96YKmq7MmGRTm8rArAMY.png
-rw-r--r-- 1 grafana grafana 109553 Jan 21 10:14 IQkelP0MQ70KVvFyEdeO.png
-rw-r--r-- 1 grafana grafana 111403 Jan 21 10:48 npMRvBsSuPxwDhRESL2n.png
-rw-r--r-- 1 grafana grafana 112893 Jan 21 10:53 xsCpyt0Idc39bKVjf9FL.png
이미지 렌더링에 대한 요청이 많은 것이 아니라 그랬을까요? 공식 문서에서 권장하는 16GB 의 메모리 공간에 택도 없이 부족한 경량 가상머신 장비였지만 렌더링 속도도 느리지 않았고 생성 과정에서 문제도 발생하지 안았습니다.
Slack Notification 의 설정? 결국 실패
결국 중요한 것은 이렇게 만든 이미지가 슬랙과 같은 서비스로 잘 연동되는지가 중요합니다. 문제는 이렇게 생성된 이미지들이 슬랙에서 보이려면 퍼블릭 인터넷 환경에서 접근이 가능해야 한다는 점이었습니다. 특히 회사 내부에서 사용하는 시스템의 중요한 지표라면 외부에서 아무나 액세스 할 수 있는 공간에 차트를 저장하는 것은 보안상 문제가 될 수 밖에 없습니다.
결론을 먼저 말씀드리긴 했습니다만, 이렇게 생성한 슬랙으로 전달되지 않았습니다. grafana notification 은 발송이 되지만 이미지 주소가 내부 도메인, 내부 주소를 사용하고 있기 때문에 슬랙이 읽어들여 채널에 렌더링 할 수가 없었습니다.
grafana 는 위와 같이 Notification 의 대상이 될 수 있는 type 을 제공하고 있습니다. 세번째 컬럼에서 <external only> 로 표기된 서비스들은 설명드린 것처럼 퍼블릭 인터넷 구간에서 접근이 가능한 스토리지를 사용해야만 합니다. S3 와 같은 것이 대표적이겠죠. 이 표기가 없는 Type 의 경우 local 스토리지를 사용할 수 있다고 이해하고 슬랙을 사용해보고자 했지만, 결과적으로는 잘 동작하지 않았습니다.
에필로그
grafana 에서 슬랙을 액세스 하는 방식은 Incoming Webhook 입니다. 이 방식에서는 파일의 업로드가 제공되지 않습니다. 메세지만 전송할 수 있는 것이지요. 내부 주소를 쓰게 되면 외부 환경에서 VPN 등의 연결이 필요한 상황이 또 발생하니 좋은 접근이 되기는 어렵습니다. 애초부터 문제 상황을 한번에 알기 위해서 이미지를 메세지에서 보여주려는 것이었는데 보안상 불가하다가 된 상황입니다.
외부 액세스가 문제 없는 이미지들이라면 (과연 존재할까요?) 공식 문서의 external_image_storage 섹션을 확인하여 S3 등을 타겟으로 설정해서 쓰시면 되겠습니다. 결과적으로 도움이 안되는 포스팅이 되버린 것 같아 속상합니다만...ㅎㅎ 사내용 이미지를 grafana notification + slack 으로 해결해 보신 경우가 있다면 댓글로 도움 말씀 부탁드리겠습니다!
