Basic-Docker

오랜만의 블로깅이다.

오랜만에 글을 쓰는것은 Docker 다.

간단히 도커 설치부터 이야기를 해보겠다. 나는 Redhat 계열의 리눅스를 좋아하므로 Centos7 로 진행하려 한다.

yum 으로 도커를 설치할건데, 몇가지를 선택해야 한다.

도커를 제공하는 레포는 여러가지가 있는데, 나는 Centos 의 Extra repo를 좋아한다. 다른레포를 사용하지 않고 그냥 바로 설치 할수 있기 때문이다.

https://docs.docker.com/engine/install/centos/

다음 URL을 참고하자.

물론 최신버전과는 거리가 좀 많다. Extra repo 는 1.13버전을 제공하며, 현재 Docker-ce repo에서 제공하는 버전은 1.20다.

Docker를 사용하기 위해선 6개의 패키지가 필요하다.

[root@linuxer ~ ]# yum install -y docker

(1/6): container-selinux-2.119.2-1.911c772.el7_8.noarch.rpm                     
|  40 kB  00:00:00     
(2/6): container-storage-setup-0.11.0-2.git5eaf76c.el7.noarch.rpm               
|  35 kB  00:00:00     
(3/6): containers-common-0.1.40-11.el7_8.x86_64.rpm                             
|  43 kB  00:00:00     
(4/6): docker-client-1.13.1-162.git64e9980.el7.centos.x86_64.rpm                
| 3.9 MB  00:00:00     
(5/6): docker-common-1.13.1-162.git64e9980.el7.centos.x86_64.rpm                
|  99 kB  00:00:00     
(6/6): docker-1.13.1-162.git64e9980.el7.centos.x86_64.rpm                       
|  18 MB  00:00:00 

docker 만 설치해도 의존성으로 도커를 사용하기위한 패키지를 설치해준다.
아이러니 하게 yum remove docker 로 삭제하면 docker는 그냥혼자 지워진다. 설치할땐 패거리로 오고 갈땐 혼자간다. 구버전이라 패키지 네이밍도 좀 올드 하다.

docker-ce repo 에서 지원하는 패키지를 확인해보면 이렇다.

[root@linuxer ~ ]# yum install -y docker-ce

(1/6): container-selinux-2.119.2-1.911c772.el7_8.noarch.rpm                      
|  40 kB  00:00:00     
(2/6): docker-ce-20.10.7-3.el7.x86_64.rpm                                       
|  27 MB  00:00:00     
(3/6): containerd.io-1.4.6-3.1.el7.x86_64.rpm                                  
|  34 MB  00:00:00     
(4/6): docker-ce-rootless-extras-20.10.7-3.el7.x86_64.rpm                      
| 9.2 MB  00:00:00     
(5/6): docker-scan-plugin-0.8.0-3.el7.x86_64.rpm                                
| 4.2 MB  00:00:00     
(6/6): docker-ce-cli-20.10.7-3.el7.x86_64.rpm                                   
|  33 MB  00:00:02     

패키지의 역할을 각각 설명하자면, docker 의 데몬을 실행하기 위한 패키지 그리고 우리가 흔히 쓰는 docker 명령어를 포함한 docker-cli, 그리고 containerd는 컨테이너를 실행하고 노드에서 이미지를 관리하는데 필요한 기능을 제공하는 OCI다. OCI는 Open Container initiative 라고 하는데 업계 표준이라 생각하면 간단하다.

패키지의 이름과 역할 분류가 조금씩 변한거다.

그럼 이제 좀 원론적인 이야기를 한번 해야겠다.

도커는 격리된 프로세스다. 도커를 실행중인 리눅스 시스템에서 아주 쉽게 알수있다.

docker run -d -p 8080:80 ngnix 명령어로 도커를 실행했다.

그리고 도커를 실행중인 호스트에서 ps 명령어를 쳤다.

[root@linuxer ~ ]# ps afxuwww

/usr/bin/containerd-shim-runc-v2 -namespace moby -id 
\_ nginx: master process nginx -g daemon off;
\_ nginx: worker process
\_ nginx: worker process

ps afxuwww 명령어에서 보기쉽게 트리만 떼온 상태다. containerd-shim-runc 데몬이 nginx를 실행중인것을 알 수 있다. 이것만으로도 컨테이너는 프로세스다. 라는것을 알수있다.

이렇기에 컨테이너는 불 안정함을 띄고 있고, 취약한 부분이 있다.

이제 도커 파일을 이야기해보려한다.

근래엔 도커파일의 사용법을 다들 잘아는 터라 Docs 로 대체한다.

https://docs.docker.com/engine/reference/builder/

근래에 내가 만든 도커파일은 이렇다.

FROM centos:7
LABEL maintainer "linuxer<linuxer@linuxer.name>"
LABEL "purpose"="practice"
ENV PATH /opt/remi/php80/root/usr/sbin:$PATH
RUN yum -y update
RUN yum -y install epel-release
RUN yum -y install https://rpms.remirepo.net/enterprise/remi-release-7.rpm
RUN yum -y install nginx php80-php-fpm
RUN mkdir /var/run/php
RUN mkdir /root/bin
ADD www.conf /etc/opt/remi/php80/php-fpm.d/
ADD php.ini /etc/opt/remi/php80/
ADD nginx.conf /etc/nginx/
ADD index.php /usr/share/nginx/html/
ADD start.sh /root/bin/
RUN chmod 755 /root/bin/start.sh
WORKDIR /usr/share/nginx/html/
EXPOSE 80
CMD ["/bin/bash", "-c", "/root/bin/start.sh"]

ngnix와 php80 버전을 합친 Dockerfile이다.

ADD한 파일들은 직접 파라미터를 수정한터라 스킵하고 start.sh에 대해서 이야기하려한다. 일반적으로 컨테이너는 포그라운드에서 동작한다. 백그라운드에서 동착한다면 작업을 마친 프로세스는 스스로 종료된다. 여기에서 문제가 발생한다. 도커는 CMD로 시작되는 프로세스는 아무리 많이 입력 되어도 마지막 줄만 실행된다. 그렇기에 두개의 프로세스를 한번에 실행할수 없었다. 이게바로..포그라운드의 문제점이었다.

이문제점을 회피하기위해서 수십가지의 테스트를 하였다.

CMD ["php-fpm", "-f", "&", "nginx", "-g", "daemon", "off"]

이런짓까지.. 하지만 실패했고 결국 스크립트를 작성하여 실행하도록 하고 fg %1 과같은 명령어를 썼다.

[root@linuxer ~ ]# cat start.sh

#!/bin/bash
set -m
/opt/remi/php80/root/usr/sbin/php-fpm --nodaemonize \
--fpm-config /etc/opt/remi/php80/php-fpm.conf & \
/usr/sbin/nginx
fg %1

다른사람들에게 팁을 얻으려고 했으나, 안티 패턴인지 딱히 다들 말이없었다. 컨테이너이므로 쪼개 라는 대답을 얻었다. 나도 알고있는 부분인지라 사실 쪼갤까 했지만 일단 스크립트를 써서 완성을 했다.

이렇게 완성한 컨테이너 를 실행해 보면

[root@linuxer ~ ]# ps afxuwww
/usr/bin/containerd-shim-runc-v2 -namespace moby -id 4
      \_ php-fpm: master process (/etc/opt/remi/php80/php-fpm.conf)
      |   \_ php-fpm: pool www
      |   \_ php-fpm: pool www
      |   \_ php-fpm: pool www
      |   \_ php-fpm: pool www
      |   \_ php-fpm: pool www
      \_ nginx: master process /usr/sbin/nginx
          \_ nginx: worker process
          \_ nginx: worker process

두개의 부모프로세스를 가진 컨테이너를 확인할수 있다.

사실 이건 테스트 하느라 만든 방법이고 실제로는 nginx 를 lb로 이용하여 php-fpm 으로 라우팅 하는 구조를 만들꺼다. 그전에 손풀기로 만들어본 이미지 이나, 나름 재미있어서 포스팅까지 진행했다.

좋은밤되시라!

Linux-one-line-Challenge

리눅서들은 이상한 것에 집착하곤 한다.

한줄 명령어가 그 중 하나이다.

보통 그렇다. 이런 아무렇지 않은 질문으로 시작한다.

질문은 곧 챌린지가 되고 도전이 시작된다.

적당히 조언했던것이..

다른 분의 참전으로 새로운 측면을 맞이한다.

ls -lt 는 시간순 정렬이다.

대충이라고 하셨지만 골자는 이렇다. ls -ptl 은 파일의 최신순서대로 정렬해서 보여준다. 거기에 / 디렉토리를 빼고 토탈을 빼는 방식이다.

물론 이런것들이 한방에 되진 않는다.

여러 가지 조언을했지만 사실 말처럼 쉽게 되지 않는다. 그저 제한사항 들을 확인하는 것이다.

위에 내가 쓴 명령어는 안됬다.

하얀색 프로필을쓰시는 분은 초굇수다.

이제 거의 정답이 나왔다. 여기서 디렉토리만 제외하면 정답이다.

맞다 나눠서 하는것도 정답이다. 하지만, 챌린지는 그렇게 쉽지 않다. 한줄로 해야한다.

find . -type d -exec bash -c 'echo "next dir: ${1}" ; ls -lt "$1" |
    grep ^- |
    head -n 5' bash {} \;

정답이다. 그러나 더깔끔하게 하고싶었다 나는...ㅠㅠ

find /root -type d -exec sh -c "ls -lpt {} | egrep -v '^d|합계' | head -n 1" \;

나는 grep -v 로 ^d 옵션을 줘서 첫글자가 d 그러니까 디렉토리 속성일경우 제외하여 결과를 만들었다.

sh -c "find /root -type d -exec bash -c \"ls -lpt {} | egrep -v '/|total' | head -n 1 \" \;" | awk '{print $9}'

리눅스는 각자의 방법이 있다.

그런 방법들이 너무 사랑스럽다.

오랜만에 즐거운 one line Challenge 였다.

좋은하루되시라!

AWS-CLF-Practitioner

https://www.aws.training/LearningLibrary

AWS 의 기초학습은 먼저 AWS training ang certification 에서 진행한다.

Amazon 계정이 필요하며 로그인후

클라우드 실무자

한국어로 정렬한다.

그럼 초보자를 위한 학습리스트가 보인다. 모두듣자.

그다음은 내 블로그에서 여러번 소개된 인도아저씨 블로그를 참고하자.

Jayendra 님은 나를 AWS로 이끌어주는데 아주 많은 일조를 하신분이다.
항상 감사하는중. 언제 한번 계획을 세워 감사인사를 할 계획.

SAA 포스팅을 추가로 넣은이유는 경계가 애매하기 때문이다.

그래서 같이보는것도 좋다.

공부할때 참고하길 바라며 궁금하거나 알고싶은건 언제나 댓글이나,

https://open.kakao.com/o/gMCqYXxb

오픈카톡으로 들어와서 질문하여도 좋다!

건승하시라!

Linux-bashtop

bashtop&bpytop 이 핫해서 centos 7 에서 설치했습니다.

bashtop 은 bash 4.4 이상 bpytop는 python3이상입니다.
오늘 저는 bashtop를 사용해볼까 합니다.

먼저 bash 5.0을 설치 하려 합니다.

 cd /usr/local/src/
 wget http://ftp.gnu.org/gnu/bash/bash-5.0.tar.gz
 tar zxvf bash-5.0.tar.gz
 cd bash-5.0/
 ./configure && make && make install
 mv /bin/bash /bin/bash.bak
 ln -s /usr/local/bin/bash /bin/bash
 
[root@linuxer src]# bash -version
GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)

그래서 bash 를 다운받고 컴파일 해줬습니다. 기존 bash 는 4.2 버전이라 bash.bak 으로 변경해 문제가 생기면 언제든 사용할수 있도록 만들었습니다.

yum install git
git clone https://github.com/aristocratos/bashtop.git
cd bashtop/
make install

이제 완성됬습니다.

Bashtop 의 컴파일 까지 끝났으므로 실행만 하면 됩니다.

./bashtop

레트로 게임같은 비주얼에서 매우 만족스럽습니다.

한번써보시는걸 추천해 드립니다.

감사합니다.

AWS Certified Solutions Architect – Associate SAA-C02

AWS Certified Solutions Architect – Associate SAA-C02 준비방법

자격증 개요확인

https://aws.amazon.com/ko/certification/certified-solutions-architect-associate/

안내서

https://d1.awsstatic.com/ko_KR/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

샘플문항

https://d1.awsstatic.com/ko_KR/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Sample-Questions.pdf

기본교육 - amazon id 필요

https://www.aws.training/Dashboard/?cta=tctopbanner

인도아저씨 - 서비스가 간략하게 정리되어있음 - 기출문제 존재

참고사이트

https://aws-hyoh.tistory.com

비공식 AWS 공인 솔루션스 아키텍트 - 어소시에이트 SAA-C02 (2020년 3월 출시) 수험 가이드 (bit.ly/saaguide)

https://github.com/serithemage/AWSCertifiedSolutionsArchitectUnofficialStudyGuide

시작하는 엔지니어를 위해-2

시작하는 엔지니어를 위해-1 적은지 두달이 지났습니다.
다음편을 써야겠다 여러번 마음을 먹었지만 쉽지 않았습니다.

이전 주제는 엔지니어의 방향성에 대해서 이야기를 했습니다. 시스템 엔지니어와 클라우드 엔지니어의 차이 그리고 근본적인 핵심을 다루어야 한다는 이야기 까지요.

엔지니어로서 어떻게 하면 클라우드가 쉬워질까? 그리고 클라우드가 대세인 요즘 어떤 방향성을 가져야 할까? 를 적어보려 합니다.

먼저 클라우드는 마케팅 적 용어라 생각 합니다.

클라우드라 정의하고 이야기하지만 본질적으로는 컴퓨팅리소스를 임대하는 범주에서 벗어날수 없습니다. 물론 여기에는 많은 생략이 들어가 있기는 합니다. 하지만 클라우드가 대량의 컴퓨팅파워를 재 가공해서 판매하는 개념은 달라지지 않습니다.

이전에는 서버를 사용하려했다면 서버를 구매하고 서버를 랙에 입고하여 OS를 설치하고 IP를 할당받아 부여해서 사용하는 방식을 사용했습니다. 시작하려면 고정적인 금액이 발생했던 거죠. 그런데 클라우드에서는 구매 입고 설치 이런 과정들이 생략되게 됩니다.

편해 졌는데 이상하게 접근 장벽이 높습니다. 클라우드를 공부 하려는 동료 엔지니어들 만봐도 어려워합니다.

왜 일까요?

제 생각은 포장이 너무 잘되어 있기 때문입니다.

근본적으로 그냥 가상화 위에 네트워크를 제공한다. 이렇게 접근하면 아주 쉬운데 우리는 VPC / EIP / EC2 이런 용어들에 별 세계의 새로운 기술인것처럼 포장되어 있는 바람에 접근이 어렵다 생각됩니다.

물론 퍼블릭 클라우드를 구현하기위해선 진짜로 어렵고 많은 기술들이 사용 되었습니다. 그러나 사용자가 무조건 알아야지만 쓸수있는것은 아니라는 것입니다. 애초에 퍼블릭 클라우드의 제공 목적도 쉽고 간편하게 사용 이니까요.

그래서 말하고 싶은바는 포장지를 볼게 아니라 무엇을 제공하냐? 입니다.

VPC는 Virtual Private Cloud 으로 사설망을 제공합니다. EC2는 가상 머신입니다. 서버라고도 하죠. EIP는 공인 IP 입니다.

이정도 연관하여 이야기하면, 느낌이 딱 올 겁니다. 어려운건 아니었구나.

그럼 어려운건 무엇일까요?

잘 사용하는 것, 입니다.

VPC는 망분리 디자인을 얼마만큼 해야하는지 퍼블릭과 프라이빗의 차이는 뭔지, 어떻게 하면 더 보안적인 측면을 강화할수 있는지. 이떤 패턴이 가격이 싼지 등을 궁리하고, 더 편하고 빠르고 무결 한 방법을 고민하는것이 어려운것이죠.

그렇다면 이제 구분에 대해서 이야기 하겠습니다.
이 구분은 클라우드를 이야기할때 빼놓을 수 없는 이야기입니다.

IaaS / SaaS / PaaS 가 그것입니다. 이 구분은 관리 영역이 누구에게 있는지로 구분을 합니다. 그럼 여기서 다시 포장의 개념을 가져와 봅시다. 클라우드 벤더가 어디까지 포장해서 판매하는지, 그 포장의 개념이 여기 여러가지의 구분입니다.

IDC - Network - Server - virtualzation - OS - DB - App - Data

그럼 IDC에서 부터 관리해야 하면 뭘까요? Hosting 입니다.

그럼 부터 OS는요? IaaS 입니다.

App 부터는 PaaS 입니다.

Data 부터는 SaaS 입니다.

이제 예를 들어 보겠습니다.

인스턴스에 CentOS를 사용한다면 IaaS 입니다.

PaaS는? EB, EKS ECS 등이 PaaS입니다.

SaaS는? AWS에서 자랑하는 대부분의 서비스는 SaaS입니다 RDS가 그렇습니다.

이 구분을 어느정도 해내는 단계에 오면 이제 클라우드 서비스가 어느정도 익숙해진것입니다. 제공자와 나의 경계범위를 확인할수 있는 것 이니까요.

이 구분법은 간단하게 클라우드 벤더에서 제공하는 단계에따라 비용의 상승을 불러일으킵니다. 책임과 관리의 범위를 클라우드 벤더가 가져가는 만큼 비용의 상승이 발생하는 것입니다.

클라우드에 선 기회와 시간에 대해서 이야기합니다.

비즈니스에 집중하세요.

이 말입니다. 비즈니스에 집중하는 것은 인프라나, 플랫폼이나, 서비스의 관리를 벤더 에서 해주니 그 기회 비용을 비즈니스에 사용 하라는 말이죠.

저는 엔지니어의 길이 이곳에 있다 생각합니다.

IaaS,PaaS,SaaS를 기회와 비용을 적절하게 섞어서 사용하는것 말이죠. 무조건 관리형 서비스를 쓰는게 능사가 아니라, 관리포인트가 적은 서비스라면 직접구축해서 쓰는것또한 필요하다는 이야기 입니다.

정리하겠습니다.

좋은 엔지니어라면 칼을 가리지 않아야 합니다.. -키보드는 가립니다-

무조건 써야하는것은 없습니다. 필요한 부분에 적재적소로 사용해야 합니다. 한가지만 고집하는것은 결국 시대에 도태 될수있습니다. 그렇기에 온 프레미스도, 클라우드도 IaaS도 SaaS도 적절하게 사용하는것. 이것이 엔지니어로 가져야할 필수 마인드라 생각합니다.

언제든지 쓸수있도록 준비하세요. 그 준비가 더 나은 기회를 잡을수 있도록 도울것입니다.

긴글 읽어주셔서 감사합니다.

grep-return-NULL

if 돌려야할거 같았는데.. 아니었다.

[root@linuxer log]# grep "11111" /var/log/messages 2>&- || echo "NULL"
Dec 21 02:51:18 linuxer dhclient[3934]: XMT: Solicit on eth0, interval 111110ms.
[root@linuxer log]# grep "111111" /var/log/messages 2>&- || echo "NULL"
NULL

핵심은 오류출력을 리디렉션하여 클로즈..

2>&-

https://tldp.org/LDP/abs/html/io-redirection.html
홀스님께서 알려주신 URL이다 표준출력에서 -가 뭔지 몰랐다.

[root@linuxer log]# grep "11111" /var/log/messages 2>&- || echo "NULL"
Dec 21 02:51:18 linuxer dhclient[3934]: XMT: Solicit on eth0, interval 111110ms.
[root@linuxer log]# grep "111111" /var/log/messages 2>&- || echo "NULL"
NULL

오랜만의 리눅스 포스팅...역시 shell은 끝이없다.

AWS-CloudShell

OK! Thank You!

amazon linux2 기반의 클라우드 쉘이다.

가볍고 빠르고 일부리전만 지원하고..

얼른한국 리전도 지원해주세요.!

본격적으로 스펙을 파악해 보자.

-bash-4.2# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay          30G   12G   17G  41% /
tmpfs            64M     0   64M   0% /dev
shm             1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/nvme1n1     30G   12G   17G  41% /aws/mde
/dev/loop0      976M  2.6M  907M   1% /home
tmpfs           1.9G     0  1.9G   0% /proc/acpi
tmpfs           1.9G     0  1.9G   0% /sys/firmware

은근무거운데?

-bash-4.2# free
              total        used        free      shared  buff/cache   available
Mem:        3977864      270404     2099668         392     1607792     3495176
Swap:             0           0           0

메모리 수준 무엇?

-bash-4.2# cat /proc/cpuinfo | grep model
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz

CPU 좋고 용량 좋고 메모리 좋고

[cloudshell-user@ip-10-0-153-179 ~]$ sudo systemctl start httpd
Failed to get D-Bus connection: Operation not permitted

서비스는 실행할수 없고..

그래고 엄청 짱짱하네..

기다려온 만큼 성능이 좋다!

AWS-gp3-speed-test

볼륨 두개를 만들었다

mount /dev/nvme1n1p1 /mnt/gp3
mount /dev/nvme2n1p1 /mnt/gp2
yum install gcc zlib-devel
wget https://codeload.github.com/axboe/fio/tar.gz/fio-3.24
tar zfxv fio-3.24
cd fio-fio-3.24/
./configure --prefix=/home/fio
make; make install

필요한 라이브러리 gcc, zlib-devel 설치후 컴파일.

fio 는 나도 처음써보는 툴이다

fio --directory=/mnt/gp3 --name fio_test_file --direct=1 --rw=randread \
--bs=4K --size=1G --numjobs=7 --time_based --runtime=180 --group_reporting \
--norandommap

3분동안 하나의 스레드가 7개의 1G 파일을 4K 단위로 Direct I/O 모드의 Random Read 로 읽는 테스트이다.

Jobs: 7 (f=7): [r(7)][100.0%][r=11.7MiB/s][r=3001 IOPS][eta 00m:00s]
fio_test_file: (groupid=0, jobs=7): err= 0: pid=2450: Wed Dec  2 06:59:19 2020
  read: IOPS=3016, BW=11.8MiB/s (12.4MB/s)(2121MiB/180004msec)
    clat (usec): min=188, max=296635, avg=2319.05, stdev=1213.65
     lat (usec): min=188, max=296635, avg=2319.21, stdev=1213.65
    clat percentiles (usec):
     |  1.00th=[  408],  5.00th=[  922], 10.00th=[ 1287], 20.00th=[ 1598],
     | 30.00th=[ 1762], 40.00th=[ 1926], 50.00th=[ 2057], 60.00th=[ 2212],
     | 70.00th=[ 2474], 80.00th=[ 2933], 90.00th=[ 3818], 95.00th=[ 4621],
     | 99.00th=[ 6194], 99.50th=[ 6587], 99.90th=[ 7767], 99.95th=[ 8455],
     | 99.99th=[10028]
   bw (  KiB/s): min= 9848, max=32328, per=100.00%, avg=12069.08, stdev=167.76, samples=2513
   iops        : min= 2462, max= 8082, avg=3017.27, stdev=41.94, samples=2513
  lat (usec)   : 250=0.05%, 500=2.12%, 750=1.59%, 1000=1.99%
  lat (msec)   : 2=40.61%, 4=45.04%, 10=8.59%, 20=0.01%, 50=0.01%
  lat (msec)   : 250=0.01%, 500=0.01%
  cpu          : usr=0.12%, sys=0.29%, ctx=543082, majf=0, minf=93
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=542985,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=11.8MiB/s (12.4MB/s), 11.8MiB/s-11.8MiB/s (12.4MB/s-12.4MB/s), io=2121MiB (2224MB), run=180004-180004msec

Disk stats (read/write):
  nvme1n1: ios=542478/13, merge=0/3, ticks=1253070/0, in_queue=1078350, util=99.97%

정확히 3000iops 가 나온다.

그럼 로컬 디바이스 테스트 해볼까?

fio --directory=/mnt/gp2 --name fio_test_file --direct=1 --rw=randread \
--bs=4K --size=1G --numjobs=7 --time_based --runtime=180 --group_reporting \
--norandommap
fio-3.24
Starting 7 processes
Jobs: 7 (f=7): [r(7)][100.0%][r=11.7MiB/s][r=2997 IOPS][eta 00m:00s]
fio_test_file: (groupid=0, jobs=7): err= 0: pid=1316: Wed Dec  2 07:13:16 2020
  read: IOPS=3016, BW=11.8MiB/s (12.4MB/s)(2121MiB/180004msec)
    clat (usec): min=192, max=298525, avg=2318.95, stdev=1162.93
     lat (usec): min=192, max=298525, avg=2319.12, stdev=1162.93
    clat percentiles (usec):
     |  1.00th=[  457],  5.00th=[  963], 10.00th=[ 1254], 20.00th=[ 1565],
     | 30.00th=[ 1729], 40.00th=[ 1909], 50.00th=[ 2057], 60.00th=[ 2245],
     | 70.00th=[ 2540], 80.00th=[ 3032], 90.00th=[ 3818], 95.00th=[ 4490],
     | 99.00th=[ 5932], 99.50th=[ 6259], 99.90th=[ 6915], 99.95th=[ 7373],
     | 99.99th=[ 8455]
   bw (  KiB/s): min= 9808, max=26696, per=100.00%, avg=12069.37, stdev=141.33, samples=2513
   iops        : min= 2452, max= 6674, avg=3017.34, stdev=35.33, samples=2513
  lat (usec)   : 250=0.01%, 500=1.48%, 750=1.61%, 1000=2.48%
  lat (msec)   : 2=41.05%, 4=44.98%, 10=8.40%, 20=0.01%, 250=0.01%
  lat (msec)   : 500=0.01%
  cpu          : usr=0.12%, sys=0.30%, ctx=543092, majf=0, minf=90
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=543002,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=11.8MiB/s (12.4MB/s), 11.8MiB/s-11.8MiB/s (12.4MB/s-12.4MB/s), io=2121MiB (2224MB), run=180004-180004msec

Disk stats (read/write):
  nvme2n1: ios=542683/0, merge=0/0, ticks=1253810/0, in_queue=1076380, util=99.74%

엥 결과가 같다..왜지? 3000iops 로 고정된다 gp2인데..

gp3를 분리하고 테스트한다.

Jobs: 7 (f=7): [r(7)][75.6%][r=11.7MiB/s][r=3001 IOPS][eta 00m:44s]

그럼 gp3연결하고 iops 를 올리고 다시 gp3 에 테스트한다.

fio-3.24
Starting 7 processes
Jobs: 7 (f=7): [r(7)][100.0%][r=23.4MiB/s][r=6002 IOPS][eta 00m:00s]
fio_test_file: (groupid=0, jobs=7): err= 0: pid=1393: Wed Dec  2 07:29:50 2020
  read: IOPS=6033, BW=23.6MiB/s (24.7MB/s)(4242MiB/180002msec)
    clat (usec): min=146, max=327858, avg=1158.79, stdev=1152.61
     lat (usec): min=146, max=327858, avg=1158.95, stdev=1152.62
    clat percentiles (usec):
     |  1.00th=[  281],  5.00th=[  371], 10.00th=[  441], 20.00th=[  586],
     | 30.00th=[  685], 40.00th=[  766], 50.00th=[  848], 60.00th=[  947],
     | 70.00th=[ 1090], 80.00th=[ 1434], 90.00th=[ 2343], 95.00th=[ 3294],
     | 99.00th=[ 5014], 99.50th=[ 5342], 99.90th=[ 6456], 99.95th=[ 8455],
     | 99.99th=[26608]
   bw (  KiB/s): min=16360, max=37232, per=100.00%, avg=24140.01, stdev=241.45, samples=2513
   iops        : min= 4090, max= 9308, avg=6035.00, stdev=60.36, samples=2513
  lat (usec)   : 250=0.64%, 500=13.39%, 750=23.96%, 1000=26.32%
  lat (msec)   : 2=23.16%, 4=9.85%, 10=2.63%, 20=0.01%, 50=0.04%
  lat (msec)   : 100=0.01%, 250=0.01%, 500=0.01%
  cpu          : usr=0.24%, sys=0.53%, ctx=1086208, majf=0, minf=87
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=1085994,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=23.6MiB/s (24.7MB/s), 23.6MiB/s-23.6MiB/s (24.7MB/s-24.7MB/s), io=4242MiB (4448MB), run=180002-180002msec

Disk stats (read/write):
  nvme2n1: ios=1085375/0, merge=0/0, ticks=1249280/0, in_queue=1077940, util=100.00%

gp3의 iops 가 올라간건 확인이 된다.

정리하자면 gp2의 성능테스트시에 iops 가 3000으로 고정된다. 아마 대역폭기반 계산이라 정확하게 3000으로 측정되어 실제 디스크의 iops 가 아닌거 같다.

대역폭을 측정할수 있는 툴인가........툴을까봐야하는데 귀찮다..그건 나중에...-_-;