linuxer-admin

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


먼저 제소개를 하자면, 시스템엔지니어로 10년차, AWS를 다룬지는 3년이 됐습니다.

요즘 시스템 엔지니어로 시작을 꺼리는 분들이 많습니다.

이유는 클라우드가 급 부상 하고 있기 때문입니다. 물어보면 대부분 클라우드 엔지니어를 하고싶다. 말합니다. 그런데 클라우드 엔지니어는 뭐고, 시스템 엔지니어는 뭐길래 이렇게 이야기가 많을까요?

그럼 두 직군의 차이부터 한번 이야기해봐야 할거 같습니다.

시스템 엔지니어는 클라우드가 생기기 이전부터 시스템 전반을 책임지는 역할로, 주로 셋팅과 구성 그리고 트러블슈팅을 맡아서 하던 직군입니다.

클라우드 엔지니어는 클라우드를 가지고 인프라를 구성하고 트러블 슈팅을 합니다.

어? 뭐가 다른거죠? 궁금하실 텐데요. 사실 별반 다르지 않습니다. 시스템 엔지니어가 클라우드를 사용해서 시스템을 구축할수도 있는거고 클라우드 엔지니어가 지원을 위해 온프렘의 서버를 보기도 해야합니다.

사실 이 두 직군의 차이는 시작 지점이 어디에 있냐의 차이일 뿐 하는일의 근본적인 차이는 없습니다. 그렇다면 뭘 배워야 하고, 뭘해야 할지가 중요할텐데요.

먼저 리눅스가 중요합니다. 정말 중요합니다.

클라우드 엔지니어로 시작하게 되면 리눅스를 깊게 다루지 않게 됩니다. 이유는 클라우드 플랫폼 내에서 기술지원을 하기때문에 중점적으로 배우는것은 플랫폼의 사용법과 구성인것입니다. 거기에 lock-in 이 발생하게 됩니다. 보통 lock-in 이라 하면 다른 플랫폼으로 떠날수 없는 서비스나 사이트를 말하는것인데, 이 문제점이 사람에게도 발생하는 것입니다. 이부분이 나쁘다는건 아닙니다. 저도 AWS를 정말 좋아하니까요. 하지만, 제공되는 서비스만 사용해서는 사용자 이상으로 나아갈 수 없게됩니다. 그래서 언제든, 탈 플랫폼을 하기위해선 유연하게 여러 솔루션을 사용하고 배우는 기반이 있어야 합니다.

그것이 바로 엔지니어 에겐 리눅스입니다. 그럼 리눅스로 뭘해야 할까요?

일단 명령어에 익숙해 져야 합니다. 리눅스의 상태를 확인하고, 프로세스의 상태를 확인할수 있는 방법을 알아야 합니다.

그 다음은 로그를 보고 서비스를 확인할 수 있어야 합니다. 이전의 엔지니어가 여기까지 했다면 요즘의 엔지니어는 로그를 가공하고 지표로서 사용할 수 있는 능력까지 길러야 합니다.

너무 두루뭉실 했나요? 그럼 기업에서 요구하는 사항으로 예를 들어볼까요?

선호 자격 요건입니다.

Tomcat, Nginx, IIS, DB, Mail, DNS 등 구축 및 운영 관리 경험을 보유한 분
Shell Script & Query 사용 경험이 있는 분
네트워크, 방화벽, VPN등 네트워크 및 보안에 대한 이해도가 높은 분
IaC (Infra as a code)등의 구축 경험 및 OSS 등의 솔루션 사용 경험이 있는 분

사실 선호 자격이라 적었지만, 선호자격이라기 보단 10년차 IT 인프라 운영 직무에 있는 사람에겐 반드시 겪었어야 하는 과정의 요건일 겁니다.

그럼 정리해볼까요.

클라우드 엔지니어와 시스템 엔지니어는 시기상의 문제입니다.
결국 엔지니어는 IT 인프라를 다루는 포지션이 될것입니다.

배워야하는 순서라면 시스템의 코어인 리눅스부터 네트워크까지를 전체로 다우는 교육이 좋습니다.

기본이 튼튼하면 클라우드도 금방 배울수 있습니다.

그럼 빅히트의 요강을 보고 배워야 하는 우선 순서를 알아볼까요.

  1. Tomcat, Nginx, IIS, DB, Mail, DNS 등 구축 및 운영 관리
  2. Shell Script
  3. 네트워크, 방화벽, VPN등 네트워크 및 보안
  4. EC2, RDS, Aurora, CF, Cloudformation 등 다양한 클라우드 인프라 서비스
  5. IaC (Infra as a code)등의 구축 경험 및 OSS 등의 솔루션

이정도 순서로 배워야할것들을 정할수 있습니다. 서비스부터 점점 인프라까지 배우는것이죠.

한번에 모두를 다할순 없으니 시간이 될때마다 개념이라도 알아두시는게 좋습니다.

그럼 이만 시작하는 엔지니어를 위한 짧은 글을 마치겠습니다.

AWS-S3-directory-size

aws s3 ls s3://linuxer-wp/wp-content/uploads/2019/08/ --human-readable --summarize

aws s3 명령어만으로 조합.

aws s3 ls s3://linuxer-wp/ --recursive --recursive | grep 2020 | awk 'BEGIN {total=0}{total+=$3}END{print total/1024/1024" MB"}'

aws s3 ls + grep + awk total+=$3더한것.

linux-lsof

사이트 확인중 이상 증상이 있는 고객이 있었다.

사용량이 많아지면 mysql.sock 에러가 발생하는 것이었다.

apache 에서 mysql 접속시 socket을 생성한다는건 일반적으로 접속을 Localhost 로 설정해야 하는데, local의 database를 사용하지 않는 상태였다.

socket을 사용하는 에러를 찾기위해 lsof 를 먼저 사용했다.

lsof | grep sock
httpd 15233 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15250 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15250 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15258 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15258 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15312 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15312 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15314 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15314 apache 5u sock 0,7 0t0 658393448 can't identify protocol

can't identify protocol mysql.sock 문제가 아니라 apache 의 sock 문제가 발생하고 있었다.

can't identify protocol 는 소켓이 완전히 닫히지 않거나 누수가 있다고 판단되는데, 확인이 필요했다. 요인은 openfile 갯수나 여러가지 요인이 있을거라 생각해서 먼저 openfile을 확인했다.

ulimit 로 확인한 openfile 갯수는 1024와 일단 수정해 줬다.

echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf
ulimit -Hn 65536
ulimit -Sn 65536

cat /proc/net/sockstat
sockets: used 261
TCP: inuse 17 orphan 0 tw 44811 alloc 54 mem 49
UDP: inuse 5 mem 15
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

sockstat 를 확인시에 현재는 문제가 되는 상태는 아니었다.

이 조치 이후 추가적인 모니터링을 진행할 것이다.

AWS-IP-list

wget https://ip-ranges.amazonaws.com/ip-ranges.json

wget 으로 먼저 aws 의 IP list 를 받는다.

yum install jq

jq를 다운받는다.

jq '.prefixes[] | select(.region=="ap-northeast-2") | select(.service=="S3") | .ip_prefix' < ip-ranges.json
"52.219.60.0/23"
"52.219.148.0/23"
"52.219.56.0/22"
"52.219.144.0/22"

IP list를 필터하여 확인한다.

jq '.prefixes[] | select(.region=="ap-northeast-2") | select(.service=="S3") | .ip_prefix' < ip-ranges.json | tr -d '"'
52.219.60.0/23
52.219.148.0/23
52.219.56.0/22
52.219.144.0/22

tr 로 " 를 삭제한 예제.

NCP-VPC-Update

드디어 NCP 에도 VPC가 업데이트 되었습니다.

VPC 모드로 전환하면 파란색으로 인터페이스가 전환됩니다.

금융존은 주황색

TMI는 여기 까지고 VPC를 생성해 보겠습니다.

아직 none-rfc-1918은 지원하지 않습니다. 다른 벤더에서도 rfc1918을 쓰는것을 권장하지만, none-rfc-1918의 필요성이 가끔 있으므로 차차 업데이트 되지 않을까 생각됩니다.

VPC 이름에는 대문자를 사용할 수 없습니다.

생성할떄 public / privite 으로 지정해서 만들게 됩니다. 인스턴스를 생성할때 public 으로 생성하면 인스턴스 용도로만 사용할수있고, private 으로 생성하면 로드벨런서 용도와 일반용도를 나누어서 생성할수 있습니다.

AWS 에서 계층화 된 서브넷의 구성에서 자유도를 빼놓은 구성같습니다.

사용자가 선택할수 있는 pub/pri 구분은 서브넷을 생성할 때 만 결정할 수 있는 것 입니다.

라우팅 테이블의 메뉴가 있긴 하나, 이 라우팅 테이블은 서브넷간 통신과 VPN 통신등을 컨트롤하는거고 public / privite 은 한번 설정하면 수정할 수 없습니다.

일단 VPC 와 Subnet을 생성했으니, 한번 classic 모드와 VPC 모드 전환시도를 간단하게 진행해 보겠습니다.

classic 모드에서 인스턴스를 생성하고, 이생성한 인스턴스를 이미지로 만든후 vpc에서 이미지로 인스턴스를 생성해보겠습니다.

생성된 서버이미지를 이제 VPC 모드에서 보겠습니다.

안보입니다.

여긴어디 나는누구........그럼 어쩌지...vpc mode 로 전환 어쩌지..

짤봇!

아직 전환할수 있는 지원은 안나온거 같고..서로 풀을 공유하지 않는것으로 보입니다.

이후 3월 4일 패치내용입니다.

서버이미지 공유와 Classic 에서 VPC로 이미지 복제기능이 런칭되었습니다.

아주 칭찬해!

옮길수있는 이미지리스트는 정해져있지만 아주 수월하게 이동이 가능합니다.

https://manvscloud.com/?p=516

manvscloud 님의 블로그를 링크하며 글을 마칩니다.