# httpd -T | grep http
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.10.6. Set the 'ServerName' directive globally to suppress this message
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs
.
위의 경우가 그 예이다.
우리가 사용하는 grep, awk 같은 명령어는 buffer를 이용한다. 그런데 stderr는 buffer 를 거치지 않고 출력하기때문에 grep 나 awk를 사용할수 없는 것이다.
이것을 이해하기 위해선 Buffering을 이해해야 한다.
이런 경우 우리는 2>&1 같은 리디렉션을 이용하여 처리를 한다.
2(stderr)>(리디렉션)&(실행한 다음)1(stdout) 이것은 표준에러를 표준출력으로 변경해준다는 의미로 받아들이면 접근이 굉장히 어렵다. 더 풀어써보겠다.
stderr 는 unbuffer 고 이것을 pipe buffer 를 거쳐 stdin 으로 들어가 grep 은 버퍼내의 데이터를 읽어들여서 stdout로 출력하게 되는것이다.
그냥 버퍼까지 올리지 않던 데이터를 리디렉션으로 버퍼에 넣어준다고 생각하자.
# httpd -T 2>&1 | grep http
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.10.6. Set the 'ServerName' directive globally to suppress this message
.
다음과 같이 grep 가 동작한다.
grep 는 버퍼를 사용하는 명령어다. 버퍼를 사용하지 않는 출력(stderr)은 grep 할수없다.
information_schema 스키마는 랜덤샘플링으로 인하여 값의 오차가 생길수 있으므로 정확하지 않음
검증방법
ANALYZE TABLE 테이블명;SELECT table_name, table_rows, round(data_length/(1024*1024),2) as 'DATA_SIZE(MB)', round(index_length/(1024*1024),2) as 'INDEX_SIZE(MB)' FROM information_schema.TABLES WHERE table_schema = '데이터베이스명' GROUP BY table_name ORDER BY data_length DESC LIMIT 10;
ANALYZE 를 진행하며 테이블 확인 - information_schema.TABLES 이 계속 변경되는것이 확인됨
하드웨어 서버에 익숙하고, 서버의 자원을 조금이라도 잘쓰기 위해서 여러 방안을 강구하고 매일 테스트했습니다.
자동화 설치를위해서 Clonezilia로 PXE 자동화 설치를 만들고, Hyper-V기반의 DB호스팅을 만들며, 이런저런 오픈소스를 테스트하고, L4, WAF, IPS등 여러 장비들을 다룰줄알고 셋팅도 하였지만, 남들보다 조금 손이 빠른 그저 그런 잡부중 하나일 뿐이었습니다.
그러던 중에 AWS를 만나며, 새로운 세상을 만났습니다. 그동안 힘들었던 서버 설치는 버튼클릭 몇번이면 되고, 비싸서 사용할수 없었던 솔루션, 고객에게 추천하기 어려웠던 구성들까지 그 야말로 세상의 관념이 변하는 느낌을 받았습니다.
그게 2017년이었습니다.
2017년 11월 부터 자격증을 취득하였습니다.
제 시험기록입니다. 10월 21, 2017 - 1월 03, 2022 까지입니다.
59217 번대의 등록번호에서 2163089번대의 등록번호입니다. 200만명을 시험보는동안 11개의 자격증을 취득한것입니다.
시험은 중간에 3번정도 변경되었습니다. Big data / alexa / data analytics 등으로 생기고 없어졌습니다. 지금 Beta에 있는 ERP SAP도 있지만 이건 무시하겠습니다.
시험을 보고 공부하고, 시간이 지나며, 2017년부터 저는 많이 변했습니다.
호스팅업체의 SE에서 지금은 CSP의 SA로 일하고 있습니다. SE로서 길렀던 능력은 다양한 시스템을 겪고 트러블을 해결하면서 어떤시스템도 어렵지 않게 파악할수 있는 능력이 생겼고, 이 능력을 기반으로 다양한 서비스와 솔루션을 연계하고 옳은 방향으로 비즈니스를 이끌수 있는 방법을 배웠습니다. 그 덕분에 SA로 일할수 있게 되었습니다.
직무를 수행하면서 뿐만아니라 자격증을 공부하고 테스트하면서 간접적으로 느끼고 배운것들까지 저에게 녹아들면서 아키텍팅에대해서 자신감이 붙었습니다.
그러면서 저또한 공부하는 버릇이 붙었고, 그게 저 자신을 만들어갔습니다.
8년차까지 자격증에 대해서 전혀 관심도 없던 저였는데, 어느순간 18개가 넘는 자격증을 취득하게 되었습니다.
자격증은 전문가라는 뜻이 아닙니다. 관심이 있고, 공부를했다는 증명인것입니다. 이것을 업무에 녹이는것은 또 개인의 능력이나, 클라우드 프로바이더의 자격증은 일종의 롤플레잉을 부여하는 방식으로 질문을 던지기 때문에 유사경험이 가능하고, 이것은 나중에 업무를 처리할때 기준을 제시할수 있습니다.
