AWS EC2 디스크 크기 늘리기

EC2를 사용하다보면 처음 예상과는 다르게 디스크 공간이 부족한 경우가 생깁니다.

EC2에서 EBS 볼륨을 사용한다면 서버를 중지하지 않고도 디스크 크기를 쉽게 늘릴수 있습니다. 현재 세대 인스턴스(t2, m3, m4, c3, c4, r3, r4등)만 가능하고 이전세대 인스턴스(m1, m2, c1, c2, t1 등) 를 사용하는 경우 인스턴스를 중지하고 작업해야합니다.

  1. AWS 콘솔에 접속후 크기를 늘리고자 하는 EC2 인스턴스의 볼륨을 선택
  2. ‘Modify Volume’ 을 눌러서 새로운 디스크 크기를 입력
  3. 볼륨의 상태정보중 “State” 값이 in-uses-optimizing 으로 변경된후 다음 작업 진행
  4. EC2 인스턴스에 SSH로 접속

lsblk 명령어를 입력해서 현재 상태를 확인

[email protected]:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 60G 0 disk
└─xvda1 202:1 0 30G 0 part / 

여기서 보면 xvda 디스크 크기는 새로 변경한 60G 인데 그 밑에 있는 파티션은 아직 바뀌지 않아서 30G로 되어 있습니다.

파티션을 늘리기 위해 다음 명령어를 입력

$ sudo growpart /dev/xvda 1
$ sudo resize2fs /dev/xvda1

여기서 주의할점은 처음 명령어에서는 /dev/xvda 라는 디스크 이름을 적고 공백 다음에 숫자 1을 입력했는데 두번째 명령어에서는 /dev/xvda1 으로 파티션 이름을 입력했다는점 입니다.

다시 lsblk 명령어를 실행하면 파티션의 크기도 60G로 늘어난것을 확인할 수 있습니다.

[email protected]:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 60G 0 disk
└─xvda1 202:1 0 60G 0 part / 

df -h 명령어를 이용해서 디스크 용량을 볼때도 늘어나 있습니다.

[email protected]:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G   12K  3.9G   1% /dev
tmpfs           799M  484K  798M   1% /run
/dev/xvda1       59G   22G   35G  39% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G     0  3.9G   0% /run/shm
none            100M     0  100M   0% /run/user

참고정보

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

서버 삽질 : 레일스 puma 서버 무한 재시작 `require’: : cannot load such file

회사 서버를 ansible 을 이용해서 설치하기 위해 전환하던중 찾기 어려운 오류를 만나게 되서 정리합니다.

현상

puma 웹서버를 실행하면 puma_error 에러 로그에 아래와 같은 에러가 출력되면서 계속해서 재시작됩니다. puma를 클러스터 모드로 시작하게 했는데 마스터 프로세스는 그대로 인데 워커 프로세스가 계속 재시작했습니다.

/yyy/xxx/~/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'/yyy/xxx/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': : cannot load such file -- bundler/setupcannot load such file -- bundler/setup ( (LoadErrorLoadError)

서버가 시작되려고 하는데 bundler 에서 원하는 젬을 찾지 못하고 있었습니다. 아무리 봐도 bundler 설정이나 rbenv 설정은 잘 되 있어서 puma 설정을 바꾸면서 테스트 하다보니 prune_bundler 옵션이 있는 경우에만 이런 오류가 발생하는것을 알게 되었습니다.

해결

rbenv 설치할때 ansible galaxy에서 받은 zzet/rbenv 를 사용하고 있었는데 이걸 직접 만든 role을 이용해 설치하는 방법으로 변경했더니 오류가 사라졌습니다.

zzet/rbenv 롤을 살펴보니 아마도 문제가 되었던것은 rbenv 플러그인중 rbenv-default-gems 때문이었던거 같아서 플러그인을 설치하지 않게 하려고 직접 만든 ansible role을 사용했습니다.

rbenv-default-gems는 루비 설치후 자동으로 설치될 gem을 설정하는건데 이중에 bundler도 있었고 이로 인해 어디선가 오류가 발생했었던거죠. 굳이 이것을 사용하지 않아도 되서 직접만든 ansible 롤을 사용하면서 해결되었습니다.

삽질지수

이번 삽질의 삽질 지수는 4입니다. (삽질지수 범위 1 ~ 5 단계) 서버 삽질은 항상 최고의 삽질 지수를 자랑합니다. 그 이유는 원인을 찾는데도 오래 걸리고 재현하는것도 오래 걸리기 때문이죠.

이번 삽질의 원인을 파악하기 위해 vagrant 에서 루비를 처음부터 다시 설치하기를 20번도 넘게 했습니다. 루비 설치는 시간이 정말 오래 걸려서 한번 설치해두고 다른거 하다가 와서 배포 하면 루비젬 설치하느라 또 시간 걸리고 기껏 해보면 이거 때문이 아니었고… 시간을 많이 잡아 먹는게 힘들었습니다.

마무리

dockerfile 을 이용할때도 마찬가지지만 인프라 설정에서는 공용모듈을 사용한다는게 쉽지 않다는것을 다시한번 느끼게 되었습니다. 소프트웨어 개발에서는 중복되는 코드를 라이브러리 형태로 만들고 다른 사람들과 공유해서 사용해도 문제가 많이 없는데 인프라쪽은 설치 스크립트를 공유한다는게 장점이 많지 않은것 같습니다.

dockerfile도 누군가가 만든 이미지를 상속 받아서 사용하다가 보면 나중에 결국 본인만의 dockerfile을 만들어서 사용하게 되듯이 ansible 의 롤도 처음에는 가져다 사용하다가 서버 상태에 맞는 롤을 결국 직접 만들어 사용하게 되겠다는 생각을 했습니다. 새로운 롤을 만들면서 기존에 공개된 롤을 많이 참고하면서 도움이 되었던 점을 보면 공개된 롤이 쓸모없는것은 아닙니다.

 

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^