머가필요해

ChatGPT가 정말 범지구적인 인기를 얻고있다.

최근에 그 성장세가 주춤해졌다고 뉴스에서 떠들지만, 그래도 여전히 대단한 인기이다.

인기를 얻으면 뭐가 따라올까!?

당연히 Anti가 따라온다.

그리고, 일종의 sacarsm(빈정댐, 비꼼)도 등장한다.

뭔가 깔끔하게 잘 만들어진 인터페이스가 먼저 눈에 들어온다.

그리고, 귀찮게 로그인하지 않아도 사용할 수 있다.

오른쪽 위의 X를 누르자.

"ChatGPT를 따라했네!?"라며 그냥 넘어가지 말고

그 안의 내용물을 좀 살펴보면... 저절로 웃음이 나올 것이다.

AI apocalypse ?????? ㅋㅋㅋ

한글 질문에 한글 대답도 할 줄 안다.

근데, 말투가 상당히 건방지지 않은가 ?! ㅋㅋㅋ

저런 X가지 없는 말만 하는 것은 아니다.

가끔 말을 듣기도 하고, 실제로 코드를 생성해주기도 한다.

다만, 그다지 긴 대답을 하지는 못해서 큰 기대를 하면 안된다.

BratGPT는 BratAI에서 만들었다고 한다.

그런데, 별 내용은 없다.

애초에 뭘 얻고자 이런 사이트를 운영하고자 하는 것인지는 모르겠지만,

AI 윤리를 생각해보면.... 음... 뭔가 생각해볼 꺼리가 있을 것 같다.

ChatGPT를 생각해보면 많은 이슈거리들이 뉴스를 장식하고 있다.

차별적인 발언을 해도 문제고, 가치 판단을 해도 문제고 ... 도덕적으로 완전무결.... 거의 순결해야 한다고 강요하고 있다.

과연 이것이 맞는 것일까?!

뭐 그냥 그렇다고.... ^^

전자제품을 구매하고 언박싱을 하면 매번 튀어나오는 매뉴얼...

하지만, 우리는 보통 그 매뉴얼을 거들떠 보지도 않는다. 어!? 나만 그런가!? ^^

리눅스 서버를 구성하고 종종 확인하는 리소스...

솔직히... 그 의미가 어떤 것인지 경험으로만 파악했지, 정확한 의미는 잘 모른다. 어?! 나만 그런가?! ^^

[ Environment ]

- VM : VirtualBox v7.0.6 r155176

- OS : Ubuntu 20.04 LTS

[ top ]

내 서버가 왠지 힘들어하는 것 같으면 가장 먼저 확인하는 것이 'top' 명령어이다.

여기에서 주로 보는 것은 다음의 'load average' 영역일 것이다.

'load average'는 시스템의 부하정도를 알려주는 지표인데,

실행중인 프로세스 또는 Disk I/O 등을 위해 대기하고 있는 프로세스의 정도를 알려주는 정보로써

CPU core 1개당 1 이상의 값을 갖는다면 대기해야하는 task가 있다는 의미로 이해하면 된다.

그런데, 왜 3개의 값이 보일까?!

1분 / 5분 / 15분 순서로 값을 보여주는데, 이를 통해 부하가 심해지고 있는지 해소되고 있는지 경향을 볼 수 있다.

개인 PC라면 가성비로 사용해야하기에 1에 맞춰서 Spec을 확보해도 괜찮겠지만

서비스를 위한 서버라면 아무리 돈이 없어도 평균 0.5 이하로 맞춰야 그나마 성능 저하 없이 사용할 수 있다.

일단 여기까지만 알아도 충분하지 않을까!? ^^

[ core ]

우리가 요즘 사용하는 CPU는 거의 multi-core일 것이다.

어!? 그런데, 생각해보니 Kubernetes에서 POD의 core를 소숫점으로도 줄 수 있는데... 일단 지금은 무시!!! ^^

실습을 하고 있는 환경은 일단 VirtualBox에서 2 core를 할당했다.

정말 잘 되어있는지 확인해보자.

스크린샷을 다 찍기에는 너무 길어져서 잘랐는데.... 그냥 심플하게 확인하려면 다음과 같이 하면 된다.

2 core가 잘 할당되어 있는 것을 볼 수 있다.

다른 명령어로도 확인할 수 있다.

[ full-load CPU ]

CPU 관련한 부하가 한계치까지 가면 어떻게 되는지 시뮬레이션을 해보자.

Terminal 탭을 2개를 열고 진행을 해보자.

응?! 그런데, 2 core 인데...

CPU 100%라고 하면, load 값이 2가 되어야 할 것 같은데 ... 1 값으로 수렴하고 있는 것 처럼 보인다.

그 이유는!

지금 실행되고 있는 python은 core 1개에서 실행되고 있기 때문이다!

그러면... python을 하나 더 실행해보자.

그리고나서 top을 다시 한 번 확인해보면,

2 core이기 때문에, 각각 100% 실행이 되고 있으니... 2 값으로 나온다.

어!? 그러면 하나 더 실행하면!?

밑에 보이는 리스트 형식의 내역을 보면 CPU는 총 200%를 3으로 나눠서 사용하고 있는 것이 보일 것이다.

'load average' 값은 3값으로 수렴하고 있다.

[ uptime]

'top' 명령어 말고 다른 명령어도 알아보자.

지속적으로 값을 보여주는 것이 아니라 1회성으로 뿌려주고 끝난다.

[ /proc/loadavg ]

또 다른 방법으로도 확인해볼 수 있다.

[ w ]

top 명령어와 uptime 명령어의 중간쯤에 위치하고 있는 것 같은 'w' 명령어도 있다.

그런데, 'load average'를 발생시키는 요인이 CPU 사용만 있을까!?

답은.... 당연히... 아니다 !!!

[ full-load Disk I/O ]

디스크에 읽고 쓰는 것도 부하를 야기한다.

CPU 사용량은 9%를 찍고 있지만 'load average'를 보면 1에 수렴하고 있다.

CPU 100%를 찍으면 어떻게 될까?

'load average'를 보면 2에 수렴하고 있지만 CPU 사용량을 보면 차이가 있다.

그렇다.

'load average'는 단순하게 Running 중인 프로세스 뿐만 아니라 Disk I/O로 인해 대기타는 것도 같이 바라보고 있다.

그러면, 이렇게 부하가 잡히고 있을 때 분석은 어떻게 하면 될까!?

일단은 뭐, top으로 확인 가능한 아래 리스트 목록으로 추적이 가능하다.

하지만, CPU 부하가 문제인지 Disk I/O 대기가 문제인지 어떻게 알 수 있을까?

[ vmstat ]

어떤 상태인지 'vmstat' 명령어를 사용해보자.

'vmstat' 명령어는 일단 Virtual Memory Statistics의 약자로써 현재 CPU 및 Memory 사용량을 알 수 있다.

지금 여기에서 살펴볼 것은 앞 부분에 있는 "r"과 "b" 부분이다.

"r"은 현재 실행하려고 하거나 실행 중인 프로세스의 개수를 알려주는 것이고

"b"는 uninterruptible sleep 상태의 프로세스 개수, 즉 I/O 대기를 하고 있는 프로세스의 개수를 알려준다.

중간에 io.py의 실행을 종료하면 어떻게 나오는지를 살펴보자.

중간에 보면 "b" 부분이 0으로 바뀌는 것을 확인할 수 있다.

우리 서버가 지금 힘들어하지는 않는지

머리(CPU)가 아픈지 손(I/O)이 바쁜지 파악해서 해결해주도록 하자.

받아보는 메일링 리스트를 통해 알게된 재미있는 Framework가 있어서 한 번 다뤄보려 한다.

나온지 꽤 된 것임에도 잘 몰랐는데,

'노마드 코더'의 극찬 영상으로 인해 호기심을 확 끌었다.

이 framework의 분류를 정확히 뭐라해야할지 애매한데, 구글링을 통해 확인한 여러 별칭은 다음과 같다.

  - CMS

  - App Framework

  - App Backend

  - Backend Framework

  - Admin Panel

  - Library

음... 아직 명확한 naming은 안되어있는 분류인 것이다.

하지만, 뭘 말하고자 하는 것인지는 왠지 알 수 있을 것만 같은 느낌적인 느낌!?

일단, 이번에 다뤄보고자 하는 것은 "Keystone JS"라는 아이이다.

재빨리 설치하고 웹을 띄워보자!!!

[ Environment ]

일단 개발 환경은 다음과 같다.

- 운영 체제: Ubuntu 20.04 LTS

[ Node ]

이 아이도 Node.JS 기반이고 npm을 이용하기 때문에 node부터 설치를 해야 한다.

버전 호환성으로 인한 어려움이 종종 발생하기 때문에

우리는 node의 다양한 버전을 다룰 수 있는 방법이 필요하다!

그래서, 나의 선택은 nvm !!!

아래 링크를 통해 nvm, node, npm 설치를 하자 !!!

- https://www.whatwant.com/entry/npm

- shell 재접속 후

[ Keystone JS ]

npm을 이용해서 keystone-app을 생성할 수 있다.

나의 app 이름을 지어주면 기본적인 boilerplate를 생성해준다.

'npm run dev'를 하면 웹앱을 띄워준다.

크롬으로 접속하면 된다.

첫 사용자를 생성해야 한다.

귀찮지만 8자 이상의 패스워드를 넣어줘야 한다.

예쁜 화면을 볼 수 있다.

User List를 확인해보면 다음과 같은 화면을 볼 수 있다.

상세 정보도 확인할 수 있다.

Posts 화면을 살펴보자.

Create Post 버튼을 누르면 멋진 화면이 나온다.

입력 인터페이스가 정말 산뜻하다. (직접 구현하려면 엄청 귀찮았을....)

[ GraphQL ]

API를 확인하기 위해서는 주소가 다르다.

멋지지 않은가?!

하지만, 주의 사항은 있다.

관련된 공부를 하지 않고서는 이 편리함을 누릴 수 없다.

귀차니즘의 해결이지, No Study & Easy Use는 아니다 !!!

최근에 "git sparse-checkout" 명령어를 살펴보면서 git version을 좀 따져보았었다.

  - https://www.whatwant.com/entry/sparse-checkout-size

"떡 본 김에 제사지낸다"고,

이번 기회에 Git 최신 버전을 사용하기 위한 방법을 살펴보도록 하겠다.

[ Environment ]

릴리즈된지 좀 오래되긴 했지만,

실무에서 주력으로 사용되는 Ubuntu 20.04 버전을 기준으로 하겠다.

(설마 우리 회사에서만? ^^)

[ Default ]

Ubuntu 20.04 설치 후에 "git" 설치는 손쉽게 가능하다.

버전까지 바로 확인해보자.

[ Check ]

그러면, 지금 현재 git 최신 버전은 어떻게 될까?

공식 홈페이지에서 확인되는 최신 버전은 "v2.41.0"이다.

최신 버전을 사용하는 것이 중요할까!?

"Release Notes"를 한 번 살펴봐보자.

밑으로 스크롤을 내려보면 지난 버전의 Release Note도 확인 가능한데,

뭔가 새로운 명령어나 기존 명령어의 변경 및 개선 사항들이 많이 보인다.

즉, 새로운 버전이 필요한 상황이 발생할 수 있는 여지가 많다!

[ Install ① Using Apt ]

Git PPA를 추가해서 apt를 이용해 Git 최신 버전을 설치해보자.

이걸로 끝이다.

이렇게 하면 너무 쉽기에 추천할만한 방법이지만...

간혹 내부망 등의 이슈로 PPA 추가가 어려운 경우가 있으니 다른 방법도 알아보자.

[ Install ② Source Build ]

좀 번거로울 수도 있지만, 소스코드를 내려 받아서 직접 빌드를 해보자.

일단 apt로 설치한 git 패키지를 삭제하자.

빌드에 필요한 것들을 미리 설치해두자.

소스코드를 내려받을 곳을 확인해보자.

오른쪽 하단의 tags를 클릭해보자.

소스코드 내려받고, 압축을 해제하자.

이제 빌드 진행하면 된다. 어렵지 않다.

기본 환경 설정은 필수 !!

자동완성 기능을 사용하고 싶다면 추가 설정을 진행하자.

bash를 사용하는 경우에는 다음과 같이 하면 된다.

zsh을 사용하는 경우에는 다음과 같이 하자.

뒷 부분에 다음 라인을 추가하면 된다.

shell 관련된 사항은 shell에 재진입해야 적용된다.

그게 싫다면 source 하던지...^^

빌드해서 설치까지 진행하는 과정이 어렵게 느껴질 수도 있지만

직접 버전 선택하고, 환경도 직접 꾸미는 것이 확실한 방법이긴 하다. 화이팅 !!

구글링을 하다가 우연히 발견한 멋진 제목 하나!

"Git 특정 디렉터리만 clone 하기"

여러 팀이 하나의 Repository를 사용하는 "Mono-Repo" 방식으로 소스코드를 관리할 때

너무 커져버린 용량으로 인한 어려움이 있을 경우에

이런 제목의 글이 눈에 들어오기 시작한다. ^^

3개의 팀이 다음 그림과 같이 mono-repo로 개발한다고 해보자.

3개팀에서 각자 개발하는 내용이 하나의 저장소에 모이기 때문에 2가지 이슈가 있다.

1. clone 받을 때 용량이 쓸데없이(?) 커서 오래걸린다.

2. 개발할 때 쓸데없는(?) 다른 팀 내용들까지 같이 보인다.

[ background ]

일단 보통의 방법으로 clone을 해보자.

200MB 규모의 Repository이다.

tree 방식으로 디렉토리/파일을 보기 위해 tree 유틸리티 설치 후 사용해봤다.

50MB 크기의 파일 4개로 구성된 Repository다. (테스트를 위해 만든 저장소 ^^)

[ sparse-checkout ]

0. environment

- 이하 실습을 진행하는 환경은 다음과 같다.

  . OS : Ubuntu 20.04 LTS

  . Git : v2.25.1

1. git

- "sparse-checkout" 명령어는 Git v2.25.0 부터 추가되었다.

- 천만 다행으로 Ubuntu 20.04에서 제공되는 Git 패키지의 버전이 가까스로 0.00.1을 넘겼다 ^^

- 과거 Git v1.17.0 부터 "sparse checkout"을 제공했었다! (사이에 "-"가 있고 없고의 차이)

  . 그 때의 명령어 사용법과 차이가 있는데, 많은 웹 포스팅에서 이를 섞어서 설명하고 있다.

2. 어렵게 clone 받기

- 블로그를 돌아다니다 보면 조금 어렵게(?) 아니 번거롭게(?) clone 받는 방법을 소개하고 있다.

으응?!

- Work Directory의 내용만 보면 내가 원하는대로 client/ 디렉토리만 존재한다.

- 하지만, clone 받는 용량이 줄어든 것은 아니다.

- sparse-checkout 명령어는 work directory를 다루기 위한 명령어이지 전송받는 데이터 용량을 줄여주는 것은 아니다.

- 그렇다면, 위와 같이 어렵게(?) clone을 받을 필요가 없다.

3. 편하게 sparse-checkout 적용하기

- 일반적인 방법으로 clone을 받고 sparse-checkout을 이용해서 정리하는 것이 훨씬 편하다.

- 훨씬 간단하지 않은가?! ^^

4. 결론

- "sparse-checkout"은 전송 용량을 줄이기 위한 것이 아니고,

- 내가 개발하는 내용(파일)만 보면서 개발하기 위한 용도로 사용하는 것이다.

[ --filter=blob:none ]

0. background

- 웹서핑을 하다보니, clone을 순식간에 할 수 있다는 옵션을 소개하곤 했다.

1. clone

- "--filter=blob:none" 옵션을 사용하면 필요한 만큼만 blob를 내려받는다.

- 보통의 방식으로 clone 받는 것과 비교해보자.

- 어!? 용량이 차이가 난다! 이건 써볼만한 방법이다!!!

2. with sparse-checkout and 'no-checkout'

- clone 받을 때 "--no-checkout" 옵션을 넣으면 working directory에 checkout을 하지 않는다

- 이렇게 clone을 받은 후 해당 디렉토리를 들어가면 필요한 일부 blob를 내려받느라 시간이 조금 소요된다.

- 용량이 또 줄었다! ^^

3. 결론

- clone 받을 때 "--filter=blob:none --no-checkout" 옵션을 추가해서 최소한으로 다운받고,

- 'sparse-checkout' 명령어를 섞어주면 내려받는 전체 용량을 확실히 줄여줄 수 있다.

git sparse-checkout 명령어에 대한 자세한 내용은 다음 링크를 참조하기 바란다.

- https://git-scm.com/docs/git-sparse-checkout/2.41.0

이전에 "dd"를 이용해서 대용량 더미 파일 생성하는 것을 살펴봤었다.

https://www.whatwant.com/entry/대용량-더미-파일-만들기-Ubutnu-1404-64bit

이번에는 좀 다른 명령어를 이용해 보고자 한다.

0. Environment

  - OS: Ubuntu 20.04.6 LTS

1. fallocate

  - 소문자 L 옵션을 사용해서 원하는 용량, 파일 이름을 명시하면 된다.

2. truncate

  - 소문자 S 옵션을 사용하는 것을 제외하고 fallocate 명령어와 동일하다.

3. dd (random)

  - 그냥 0으로 채워버리는 dummy file을 만들면 git 전송 속도 등을 측정할 때 압축이 되어버려 애매해진다.

  - 압축이 제대로 안되도록 하려면 random 값으로 채워지는 dummy file을 만드는 것이 유리하다.

  - 자세히 보면 파일 크기가 좀 차이가 있는 것도 확인해볼 수 있다.

여러 옵션이나 차이점 등이 궁금하긴 하지만,

굳이 시간을 쏟아 파고들 것 까지는 아닌 것 같아 여기서 멈추련다 ~ ^___^

옛날에 한 번 만들었다가 방치 끝에 삭제를 당해버린 서버의 부활 프로젝트 !!! ^^

"오라클 클라우드"를 처음 들어보신 분도 계실 수 있는데,

나름 어느 정도의 시장은 갖고 있는 ... 우리나라 리전도 갖고 있는 클라우드 플랫폼이다.

https://www.oracle.com/kr/cloud/

다른 클라우드들과 마찬가지로

계정 등록을 할 때 신용카드 정보가 필요하다. (1달라인가? 결제하고 곧바로 취소된다)

가입을 까막득한 옛날에 했다보니 기억이 가물거려서.... ^^

가입 후 화면을 보면 다음과 같다.

밑에 내려보면 "리소스 실행" 부분에 "VM 인스턴스 생성" 카드가 보인다.

이것을 선택하면 된다.

기본 이미지가 Orable Linux인데... 다른 배포판을 고를 수도 있다.

눈치빠른 분은 이미 파악하셨겠지만, 고를 수 있다고 해서 모두 무료가 아니다.

회색 뱃지가 붙어있는 것을 잘 확인해야 한다.

나는 익숙한 우분투로 골라봤다.

 SSH 키 생성해서 내려받는 방법도 있지만,

내가 사용하는 작업용 우분투에 이미 있는 Public-Key를 등록하는 방식으로 진행해봤다.

갖고 있는 Public-Key 복사해서 넣어줬다.

이렇게 하면 내 작업용 우분투에서 바로 오라클 서버로 접속할 수 있게 된다.

열심히 생성중이다.

확인해야 할 것은 "공용 IP 주소" 와 "사용자 이름"이다.

그냥 "ssh ubuntu@ip" 방식으로 접속하면 된다.

Disk 용량은 위에서 보듯이 50GB가 주어진 것을 알 수 있고,

메모리 용량은 다음과 같이 확인해볼 수 있다.

무료임에도 1GB를 주는 것은 대단한거다.

하지만, 뭣 좀 해보려면 좀 부족한 것도 사실이니.... swap을 잡아줘보자.

위 명령어들을 따라해보면 2GB 사이즈의 swap 메모리를 만들어줄 수 있다.

하지만, 재부팅하게 되면 사라지니... 재부팅해도 유지될 수 있도록 추가 작업을 해주자.

아래 한 줄 추가해주면 된다. (탭으로 구분하는 것 잊지 말고!)

추가로... 우리는 대한민국 사람이니, 타임존을 맞춰주자.

굳이 왜 이렇게까지 하냐면.... ^^

예전에 이렇게 만들어놓고 잊어먹어서.... 접속을 하지 않다가.... 결국은 삭제를 당했기에....

파이썬 환경을 만들어보자.

아래 소스코드를 저장해놓자.

위 코드를 실행하면 다음과 같이 메일이 온다.

하루에 한 번씩 보내도록 하자 ^^

만날 헷갈리는 crontab ... 예쁜 사이트의 도움을 받자.

https://crontab.guru/

crontab 등록을 해보자.

이제, 매일 새벽 4시에 메일을 보내준다 ^^

IaC라는 말은 인프라스트럭처(Infrastructure)를 코드(Code)로 관리를 하겠다라는 것이다.

Infrastructure as Code

이것을 가능하게 만들어주는 도구 중에서

최근 가장 유명한 도구가 바로 해시코프(HashiCorp)에서 만든 테라폼(Terraform)이다.

바로 이 도구에 대해서 친절히 알려주는 책이 바로 이 책이다.

5월말에 출간된 따끈따끈한 책이다.

이 책의 구성은 개인 사용자를 위한 내용부터 단일팀, 다수팀을 넘어 조직 단위에서 필요한 내용까지 담고 있다.

다만, 이 책은 초보자들을 위한 책은 아니다.

본업이 Infrastructure와 관련된 분들을 위한 책이다.

이 부분이 조금 아쉬운 부분일 수도 있겠지만,

이 분야를 조금이라도 아시는 분들은 어쩔 수 없다는 것에 동의하실 것이라고 생각한다.

사실 Infrastructure 라는 용어에 대한 명확한 정의조차 어려움이 있긴한데,

단순히 서버(Server)라는 hardware라고 생각할 수도 있지만

지금 실제 필드에서 infrastructure라는 용어는 대단히 광의적으로 쓰이고 있다.

이 분야에서 업무를 하기 위해 알아야할 것들은 정말 많다.

CPU, Memory 등의 실제 hardware에 대한 지식도 알아야 하고

Windows Server나 Linux 등의 운영체제에 대해서도 알아야 하고

서버에 설치되는 MySQL, PostgreSQL,Oracle 등과 같은 데이터베이스도 알아야 하고

NginX나 Apache, Tomcat과 같은 WAS에 대한 지식 뿐만 아니라

그 외 다양한 HW에 대한 지식 + SW에 대한 지식들을 모두 알아야 한다.

최근에는 심지어 AWS, Azure, GCP, OCI 등 Cloud에 대한 지식은 물론이고

Container, Kubernetes 등에 대한 지식까지 모두 알아야만 한다.

또한 보안 관련된 지식 뿐만 아니라 네트워크에 대한 지식까지도 필요하다.

위에서 언급한 모든 것들을 전부 잘 알아야 하는 것은 아니지만

최소한 무엇인지 알고는 있어야 테라폼에 대해서 공부할만할 것이다.

그러면, 테라폼 외에 다른 IaC 도구들은 없는 것일까!?

비교표를 보면 알겠지만... 뭐 결국은 Terraform 짱!!!

설치 과정이 단순하기에... 사실 경로 설정만 신경쓰면 된다.

책은 전반적으로 많은 노력을 기울인 잘 만들어졌다라는 것이 느껴진다.

다만, 아쉬운 점은 ... 위 이미지와 같이 ... 컬러가 아니다보니, 몇 몇 그림은 아쉬움이 남는다.

서버 관리 및 DevOps 등을 담당하는 분들이라면,

서버 및 클라우드 등을 code로 관리하고픈 분들이라면 필독서로 옆에 비치해놓아야 할 책이라고 생각한다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."