Tagged: 리눅스

Python JSON Tool 을 이용한 Readable한 JSON 출력하기.

Python 을 설치하면 JSON Tool 이 포함됩니다. Python JSON Tool 을 이용한  Readable한 JSON 출력이 가능합니다. 즉 쉘 상에서 JSON 포맷을 보기 좋게 볼수 있습니다. 보통은 다음과 같이 출력되서 쉽게 알아보기 힘듭니다.

curl 을 이용한 JSON 출력
Shell
1
2
]$ curl http://api.joind.in
{"events":"http:\/\/api.joind.in\/v2.1\/events","hot-events":"http:\/\/api.joind.in\/v2.1\/events?filter=hot","upcoming-events":"http:\/\/api.joind.in\/v2.1\/events?filter=upcoming","past-events":"http:\/\/api.joind.in\/v2.1\/events?filter=past","open-cfps":"http:\/\/api.joind.in\/v2.1\/events?filter=cfp"}

이를 보기 좋게 출력하는 방법은 다음과 같습니다.

python -mjson.tool 이용
Shell
1
2
3
4
5
6
7
8
]$ curl -s http://api.joind.in | python -mjson.tool
{
    "events": "http://api.joind.in/v2.1/events",
    "hot-events": "http://api.joind.in/v2.1/events?filter=hot",
    "open-cfps": "http://api.joind.in/v2.1/events?filter=cfp",
    "past-events": "http://api.joind.in/v2.1/events?filter=past",
    "upcoming-events": "http://api.joind.in/v2.1/events?filter=upcoming"
}

 

리모트 스크립트 제작기

DevOps 가 대두되면서 지속적인 배포(Continuous Delivery) 가 핵심으로 떠오르면서 수만은 서버에 한꺼번에 명령어를 내리고 파일을 전송하고 설정파일을 관리하는 소프트웨어가 인기를 끌고 있다.

대표적으로 Chef, Puppet, Saltstack, Ansible 등을 들수 있는데 이들은 지속적인 배포 뿐만 아니라 시스템과 소프트웨어를 통합해 플랫폼으로서 수많은 서버들의 상태를 동일하게 유지시켜준다.

그런데 몇 해전만 해도 이런것들이 부족했던 시절이 있었는데, 이때 내가 다니던 직장에서 수천대의 서버를 관리해야하는 일이였다. 이러한 소프트웨어가 없던 시절에 나는 개인적으로 이와 비슷한 것을 만들어 사용했는데 그때 당시로 돌아가 어떤 생각으로 만들었었는지 개선했는지를 정리해보고자 한다.

쉘 스크립트

처음에 수십대 서버에 명령어를 보내야했다. 궁리를 한 끝에 생각난 것이 쉘 스크립트로 돌리자는 거였다. 리눅스를 조금 한 사람이면 expect 라는 명령어를 알 것이다. 이 명령어는 어떤 명령어를 날렸을 경우에 돌아오는 답변을 미리 기대해(expect)해서 그것을 파싱하고 자동으로 다시 답변을 해주는 명령어였다.

수백대에 명령어를 보내야 했었는데, 수백대의 서버이름은 파일로 저장해놓고 expect 쉘 스크립트를 작성하면 될 일이였다.

expect 스크립트 예.
Shell
1
2
3
4
5
6
7
8
#!/usr/bin/expect -f
spawn ssh aspen
expect "password: "
send "PASSWORD\r"
expect "$ "
send "ps -ef |grep apache\r"
expect "$ "
send "exit\r"

그런데 이게 생각만큼 쉽지 않았다. 먼저 쉘 스크립트를 지금도 잘 모르지만, 예외처리를 하기에 힘들었다. 로그인은 성공했지만 예기치 못하게 접속이 차단되거나 기대했던 프롬프트가 나오지 않아서 명령어가 실행되지 않는등 문제가 많았다.

그래도 그때 당시에는 좋았다. 오류가 나오기도 했지만 100대중 5대 내외여서 나름대로 좋았는데, 사람이 간사한게 처음에는 불편했던것을 감수했지만 시간이 지나자 감수했던 불편함을 어떻게든 없애고 싶은 생각이 들었다. 불편했던 것들은 다음과 같았다.

  • 기대하는 프롬프트가 다양하게 나타났다.
  • 예외처리를 하기가 힘들었다.
  • 정상적인 결과나 오류등을 파일로 저장하고 싶었다.
  • 동시에 여러서버들에 실행되길 원했다.

쉘 스크립트말고 다른 프로그래밍 언어를 사용하면 최소한 예외처리나 정상적결과나 오류등을 파일로 저장하는 것이 가능해질것 같았고 평소 사용하던 Python 프로그래밍을 사용해보기로 했다.

expect 프로그래밍 for python

Python은 아주 좋은 언어임에 틀림이 없었다. expect 프로그램을 지원하는 python 라이브러리가 존재했다. pexpect 모듈이 그것이였다.

pexpect 모듈과 Python 이 지원하는 쓰레드(thread) 그리고 로깅(logging) 기능을 조합하면 좋은 꽤나 쓸만한 프로그램이 나올것이 분명해 보였다.

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import pexpect
import sys, getpass
 
COMMAND_PROMPT = '[$#] '
TERMINAL_PROMPT = r'Terminal type\?'
TERMINAL_TYPE = 'vt100'
SSH_NEWKEY = r'Are you sure you want to continue connecting \(yes/no\)\?'
 
def login(host, user, password):
 
    child = pexpect.spawn('ssh -l %s %s'%(user, host))
    fout = file ("LOG.TXT","wb")
    child.setlog (fout)
 
    i = child.expect([pexpect.TIMEOUT, SSH_NEWKEY, '[Pp]assword: '])
    if i == 0: # Timeout
        print('ERROR!')
        print('SSH could not login. Here is what SSH said:')
        print(child.before, child.after)
        sys.exit (1)
    if i == 1: # SSH does not have the public key. Just accept it.
        child.sendline ('yes')
        child.expect ('[Pp]assword: ')
    child.sendline(password)

15번째줄에 보면 기대되는 프롬프트를 적어준다. 위 예제에서는 간단하게 나왔지만 Python이 제공하는 정규표현식을 사용할 수도 있다. 위 예제를 기반으로 쓰레드를 붙이고 로깅을 붙이고 해서 여러서버에 동시에 명령어를 넣을 수 있게 되었다.

나름대로 만족하고 있었는데, 기대되는 프롬프트가 문제였다. 리눅스는 다양한 배포판을 사용하다보니 기대하는 프롬프트가 조금씩 달랐다. 거기다 SSH 접속할때에 가끔씩 인증키가 충돌이 나는 일도 있어서 기대하는 프롬프트를 리스트로 가지고 있어야 했다.

귀찮은게 문제였다. 어떻게 하면 저런것까지 신경 안쓰면서 명령어를 날리고 로깅을 할 수 있을까 하는 문제 말이지…

pxssh 모듈

pxssh 모듈은 귀찮이즘에 적어드는 시기에 찾은 신변기(?) 였다. 이 Python 모듈은 기대하는 프롬프트를 신경쓸 필요가 없었다. 최초로 접속하는 서버일지라도 알아서 HostKey 를 교환했고 프롬프트가 달라도 알아서 해주는 매우 좋은 녀석이였다.

pxssh 예제
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
s = pxssh.pxssh()
try:
    s.login(host, 'root', '1234', login_timeout=60)
 
except pxssh.ExceptionPxssh, e:
    flag = 0
    s.close()
    log.error(host+' - '+str(e))
    result= RED + 'Failed' + ENDC
 
if flag == 1:
    for command in self.commandList:
        s.sendline(command)
        flag = s.prompt(self.session_timeout)
        if flag is False:
                log.error(host+' - '+command+"\n Time out")
                s.terminate()
                result= RED + 'TimeOut' + ENDC
        print host+' - '+s.before
        log.info(host+' - '+s.before)
 
s.logout()

pxssh 모듈은 위의 예제처럼 기대되는 프롬프트는 필요가 없다. 대신 한가지 특징이 있는데, pxssh 모듈은 결과값을 before, after 변수에 저장된다. 그래서 19번째 라인처럼 값을 불러오면 된다.

그런데, 한가지 문제가 있었다. 이번에는 파일을 전송하고 싶었던 것이다.

paramiko 모듈

이런저런 고민을 풀면서 일명 자동화 명령어 프로그램을 만드는 동안에 많은 검색을 하게되면서 많은 자료를 모울 수 있다. 그러던중에 paramiko python 모듈을 보게 됐다.

paramiko 는 ssh, sftp 프로토콜을 지원줘서 python 으로 ssh, sftp 프로그래밍이 가능하도록 만들주는 라이브러리였다. 올타쿠나!! 이거야!! 그래서 명령어 전송부터해서 파일 전송을 전부 이것으로 교체하기로하고 만들었지만 문제가 있었다.

paramiko 의 SSHClient 클래스를 지원하는데 이는 SSH를 이용해서 로그인을 할 수 있도록 한것인데, 문제는 pxssh 와 비교해보니 속도면에서 많이 느렸다. (물론 내가 잘못 짠 것일 수도 있다.) 그래서 paramiko 는 파일 전송을 하는데 사용하고 명령어를 쓸때는 pxssh 를 사용하도록 스크립트 두개를 사용하도록 했다.

paramiko 를 이용한 파일 전송
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
try:
    transport = paramiko.Transport((host, 22))
    transport.connect(username='root', password='1234')
 
    sftp = paramiko.SFTPClient.from_transport(transport)
    sftp.put(self.sourcefile, self.targetfile)
 
    sftp.close()
    transport.close()
    log.warning(host+' - '+self.targetfile)
except Exception, e:
    log.error(host+' - '+ str(e))
    result= RED + 'Failed' + ENDC

대충 위와같이 프로그램을 짰다.

지금은 Python에서 Fabric 프로그램이라고 많이 사용하고 있다. fabfile.py 에 관련 내용을 작성하면 fab 명령어가 이 파일을 자동으로 인식해 내부에 작성된 메소드들을 실행해주는 방법이다. 파일 전송도 가능하다.

요즘은 Chef, Puppet, Saltstack 과 같은 것들을 사용하면 파일 배포및 명령어도 아주 쉽게 할수 있는 시대에 살지만 아주 간단하게 뭔가를 하고 싶을때에 종종 만들어 두었던 python 프로그램들을 사용하곤 한다.

Opensshd 7.0에서 바뀐점

OpenSSHD 7.0 에서 바뀐점이 있습니다. SSH 데몬이 인증을 하는 방법에는 다음과 같이 두가지가 있습니다.

  1. 패스워드 인증 – interactive authentication methods
  2. 인증키 방식

패스워드 인증 방법을 “interactive authentication methods” 라고 합니다. 그런데, OpenSSHD 7.0 에서는 root 로그인할때에는 더 이상 이 인증 방법을 지원하지 않습니다. 

CentOS 7 에서 Opensshd 7.0 이상 패키지를 설치를 해서 root로 로그인을 할려고 보니 패스워드 입력 프롬프트는 나옵니다. 하지만, 맞는 패스워드를 아무리 쳐도 로그인이 안되더군요. 그래서 뭔가 바뀌었나 싶어서 Changelog 를 살펴보니 다음과 같은 문구를 보게 되었습니다.

OpenSSH 7.0 Changelog 일부
Vim
1
2
3
4
5
6
7
8
* The default for the sshd_config(5) PermitRootLogin option has
   changed from "yes" to "prohibit-password".
 
* PermitRootLogin=without-password/prohibit-password now bans all
   interactive authentication methods, allowing only public-key,
   hostbased and GSSAPI authentication (previously it permitted
   keyboard-interactive and password-less authentication if those
   were enabled).

OpenSSHD 에 설정내용중에 “PermitRootLogin” 옵션이 있는데, 이전에는 이게 yes/no 를 입력하도록 되어있었지만 7.0 이상부터는 “without-password/prohibit-password” 로 변경되었고 “prohibit-password” 를 한다고 하더라도 모든 interactive authentication methods 를 차단(Ban)하고 인증키 방식을 지원한다고 되어 있습니다.

요약을 하면 root 사용자로 openssh 7.0 이상 서버에 로그인하기위해서는 인증키 방법을 이용해야 한다는 겁니다.

SSH 인증키 생성 방법.

인증키 생성은 다음과 같이 ssh-keygen 프로그램을 이용합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
]# ssh-keygen
ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): <- 패스워드 입력
Enter same passphrase again: <- 패스워드 다시 입력
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:hTKgHOAhLrRG9onwe9PaoB/68iSbtAQmxkZNw7i+NxY jejua@test2.systemv.pe.kr
The key's randomart image is:
+---[RSA 2048]----+
|+*+o.            |
|O+B+o.   .       |
|.B=+  o . .      |
|=. . . o .       |
|+=. + . S        |
|=o E =           |
|  * = .          |
| +.% .           |
|  B+=            |
+----[SHA256]-----+

이렇게하면 “/root/.ssh/id_rsa, /root/.ssh/id_rsa.pub” 두개의 파일이 생성이 됩니다. id_rsa 는 private key 이고 id_rsa.pub 는 public key 입니다. public key 는 sshd_config 설정파일에 기재된 이름으로 변경해줍니다.

1
AuthorizedKeysFile      .ssh/authorized_keys

id_rsa.pub 를 authroized_keys 파일로 바꿔 줍니다.  id_rsa 파일은 usb나 접속을 할려고하는 컴퓨터에 복사해 둡니다.

이제 다음과 같이 접속을 시도합니다.

Shell
1
ssh -i id_rsa root@192.168.96.6

 

ps, openssh-server 7.0 이상 패키지는 Fedora 배포판 23 버전에서 찾을 수 있습니다. Fedora 23 배포판은 7.1 버전 입니다.

SaltStack 에서 Jinja 사용시 유용한 팁

Salt 는 Jinja Template 을 지원해 Salt 파일 작성시에 프로그래밍이 가능하도록 되어 있습니다.  예를들어 배포판별로 아파치 웹 서버의 패키지 이름이 다른데, Jinja Template 를 이용하면 프로그래밍을 할 수 있습니다.

Jinja Template 를 이용한 프로그래밍.
YAML
1
2
3
4
5
6
7
apache:
  pkg.installed:
    {% if grains.os_family == 'RedHat' %}
    - name: httpd
    {% elif grains.os_family == 'Debian' %}
    - name: apache2
    {% endif %}

Salt 의 grains 을 이용해서 배포판을 가지고 오고 조건식(if statement)를 이용해서 패키지명을 명시해주고 있습니다.

하지만 이렇게하면 Salt 자체의 YAML 문법과 섞여서 읽기가 힘든 부분이 있습니다. 그래서 이를 다음과 같이 개선할 수 있습니다.

조금 개선된 Jinja Template 사용.
YAML
1
2
3
4
5
6
7
8
9
{% if grains.os_family == 'RedHat' %}
{% set name = 'httpd' %}
{% elif grains.os_family == 'Debian' %}
{% set name = 'apache2' %}
{% endif %}
 
apache:
  pkg.installed:
    - name: {{ name }}

조건식을 앞으로 빼고 변수를 이용해서 패키지명을 저장해주고 이 변수를 Salt YAML 문법에 사용하는 것입니다. 앞에 버전보다는 Jinja 문법과 YAML 이 분리가 되어서 읽기가 매우 편해졌습니다.

또 다른 좀 더 나은 버전으로는 앞의 Jinja 문법을 다음과 같이 간소화할 수 있습니다.

가장 좋은 Jinja Template 사용법.
YAML
1
2
3
4
5
6
7
8
{% set name = {
    'RedHat': 'httpd',
    'Debian': 'apache2',
}.get(grains.os_family) %}
 
apache:
  pkg.installed:
    - name: {{ name }}

출처: Salt Formulas

Vim 디렉토리 구조.

Vim 은 Unix/Linux 시스템에서 가장 있기는 편집기(Editor) 입니다. 터미널상에서 다양한 파일들을 편집할 수 있고 다양한 기능을 제공 합니다. 다양한 기능들은 플러그인(Plugin) 들로 제작되어 필요로하는 기능들만 사용할 수 있습니다. 이러한 플러그인들은 Vim 의 디렉토리에 넣기만하면 동작하도록 아주 간편하게 되어 있습니다.

이 문서는 다음의 문서를 직역해서 만들어졌습니다. 이글의 저작권도 원글에 있음을 밝힙니다.

기본 레이아웃(Basic Layout)

Vim 은 여러파일들로 분리된 플러그인들을 지원합니다.  “~/.vim” 디렉토리 아래에 새성할 수 있는 아주 많은 다른 디렉토리들은 많은 것을 의미합니다.

이제 아주 중요한 디렉토리들에 대해서 살펴보고 그들에 대한 스트레스를 날려버리자.

~/.vim/colors/

~/.vim/colors/ 안에 파일들은 컬러(Color) 스킴(Shemes)들을 다룹니다. 예를들어 (vim 실행상태에서 Command Mode 에서) “:color mycolors” 를 실행한다면 Vim 은 “~/.vim/colors/mycolors.vim” 파일을 찾을 것이고 그것을 실행할 겁니다. 이 파일은 컬러 스킴을 생성하는데 필요한 모든 Vimscript 명령어들을 포함해야 합니다.

여기서 컬러 스킴에 대해서 다루지 않을 것입니다. 만일 자신만의 컬러 스킴을 원한다면 이미 존재하는 컬러스킴을 복사하고 수정하면 됩니다. “:help” 는 여러분의 침구라는 걸 기억하세요(응?)

~/.vim/plugin/

“~/.vim/plugin/” 안에 파일들은 Vim 이 시작되는 매순간마다 각각 실행 됩니다. 이러한 파일들은  Vim 을 시작할때 마다 항상 로드되어질 원하는 코드를 포함한다는 것을 의미합니다.

~/.vim/ftdetect/

“~/.vim/ftdetect/” 안에 모든 파일들 역시 Vim이 시작될때마다 실행되어 집니다.

“ftdetect”는 “filetype detection”을 의미 합니다. 이 디렉토리안에 파일들은 탐지와 파일들의 파일타입이 지정하거나 아무것도 안하는 자동명령어들을 설정합니다. 이것은 하나 혹은 두라인 이상 길게 존재하지 않는다는 것을 의미합니다. (뭔소리??)

~/.vim/ftplugin/

“~/.vim/ftplugin/” 안에 파일들은 다릅니다.

The naming of these files matters! Vim 이 버퍼의 “filetype” 값으로 지정되면, “~/.vim/ftplugin/” 에서 일치하는 파일을 찾습니다. 예를들어, 만약 “set filetype=derp” 를 실행하면, Vim 은 “~/.vim/ftplugin/derp.vim” 을 찾을 것입니다. 그리고 만약 파일이 존재한다면 이것을 실행할 것입니다.

Vim 은 또한 “~/.vim/ftplugin/” 안에 디렉토리들을 지원 합니다. 예제에서 “set filetype=derp” 는  “~/.vim/ftplugin/derp/” 안에 모든 “*.vim” 파일들을 실행 시킵니다.  이것은 플러그인의 “ftplugin” 파일들을 로지컬 그룹으로 나눕니다.

이러한 파일들이 매번 버퍼의 filetype을 실행시키기 위해서는 반드시 buffer-local 옵션들을 지정해줘야 합니다. 만얀 전역적으로 옵션들을 지정했다면 모든 열린 버퍼들을 덮어쓰게 됩니다.

~/.vim/indent/

“~/.vim/indent/” 에 파일들은 “ftplugin” 파일과 매우 유사합니다. 그들은 그들의 이름을 기반으로 로드됩니다.

“indent” 파일들은 그들의 파일타입에 들여쓰기와 연관된 옵션들을 지정하고 이러한 옵션들은 buffer-local에 존재해야 합니다.

당연히, 단순하게 “ftplugin” 파일들에 이러한 코드를 집어넣을 수 있지만 Vim 사용자들이 당신이 무슨 일을 하는지 이해할수 있도록 이것을 분리시키는게 더 낫습니다. 이건단지 관습적인 것인데, 플러그인 제작자를 배려하도록 그것을 따르는게 좋습니다.

~/.vim/compiler/

“~/.vim/compiler/”에 파일들은 정확하게 indent 파일들처럼 동작합니다. 이것은 이름을 기반으로 현재 버퍼에서 compiler-related 옵션들을 지정합니다.

~/.vim/after/

“~/.vim/after/” 디렉토리는 약간의 꼼수같은 겁니다.  이 디렉토리에 파일들은 Vim 이 시작될때마다 로드되어 지지만, “~/.vim/plugin/” 에 파일이후에나 로드되어 집니다.

이것은 Vim의 내부 파일들을 오버라이드(override) 하도록 허용합니다.

~/.vim/autoload/

“~/.vim/autoload” 디렉토리는 굉장한 꼼수다. 들리기로는 실제보다 뭔가 더 복잡해 보입니다.

아주 간단하게 말하면, “autoload” 는 실제로 필요할때까지 플러그인 코드 로딩을 지연시키는 방법입니다.

~/.vim/doc/

마지막으로, “~/.vim/doc/” 디렉토리는 플러그인에 대한 문서를 위한 디렉토리 입니다.

리눅스 공유 메모리

리눅스 공유 메모리는 아주 특별하고 중요합니다. 튜닝하는데 있어서 매우 중요한 요소이기 때문입니다. PostgreSQL 를 세팅할때에도 반드시 해줘야 하는 것이기에 정확하게 무엇인지 짚고 넘어가고자 아는 선에 적습니다.

페이지(Page)

가장 먼저 이야기할 것이 바로 페이지(Page) 입니다. 리눅스 시스템은 메모리를 가상으로 만들어 관리합니다. 웃기게도 리눅스 시스템에서 동작하는 프로그램들은 자신들이 시스템의 모든 메모리를 사용할 수 있다, 아니 그보다 더 많은 메모리를 사용할 수 있다라고 착각을 합니다. 이는 리눅스 시스템이 메모리를 가상화해서 프로그램들에게 보여주기 때문입니다.

문제는 리눅스 시스템은 가상화된 메모리들을 페이지(Page)라는 단위로 쪼개서 관리합니다. 특정 크기를 정해서 페이지단위로 나뉘어 관리를 하는데 이렇게 해야지만이 가상화를 하기에 훨씬 쉽고 운영체제를 제작하는데 손이 덜 간다고 합니다.

그런데 이 페이지는 크기를 가지고 있으며 이를 확인하는 방법은 다음과 같습니다.

리눅스 페이지 크기 확인
Shell
1
2
]# getconf PAGESIZE
4096

단위는 bytes 여서 정확하게 4kb 가 됩니다.

이게 무척이나 중요한 것이 PostgreSQL 데이터베이스 세스템에서 Shared_Buffer 값을 계산할때에 페이지 크기를 알아야 합니다.

공유 메모리(Shared Memory)

리눅스 시스템은 놀랍게도 공유메모리(Shared Memory)를 제공합니다. 이게 정말로 뚱딴지 같은 소리인데 왜냐하면 이 공유 메모리는 프로세스간에 서로 공유하기위해서 메모리이기 때문입니다.

프로세스는 자신만의 메모리를 필요로 합니다. 그것으로 끝입니다. 하나의 프로세스가 다른 프로세스의 메모리에 자료를 가져가면 그건 잘못된 것이고 절대로 그렇게 동작하지도 않습니다. 그런데 프로세스 사이에 자료를 공유하고 싶을때 어떻게 해야 할까요?

이럴때 바로 공유 메모리를 사용합니다. 공유 메모리의 특징은 다음과 같습니다.

  • 공유메모리는 최초로 공유 메모리를 만드는 프로세스에 의해서 만들어 집니다. 이렇게 만들어진 메모리는 커널이 관리해 줍니다.
  • 한번 만들어진 공유 메모리 공간은 직접 삭제를 하거나 리눅스 시스템이 재부팅을 하거나 해야지만 없어집니다. 모든 프로세스가 더 이상 공유 메모리를 사용하지 않는다고 자동 삭제되는 일은 결코 없습니다.

뭔가 대단히 있어보이는 듯한데, 한마디로 정의 하면

프로세스간에 데이터를 공유하고자 할때 사용하는 메모리로 커널에 의해서 관리 되어진다.

입니다. 참 쉽조잉~

그런데, 이 공유 메모리는 아주 많이 사용되어지기 때문에 이 공유메모리 양을 얼마로 해주냐가 리눅스 튜닝의 시작입니다. 실제로 커널 파라메터에 다음과 같은게 있습니다.

sysctl.conf 설정.
1
kernel.shmmax = 4294967296

많이들 하는 튜닝입니다. 최대 공유 메모리를 얼마나 할 것인가 하는 겁니다.

공유 메모리는 최소(SHMMNI), 최대(SHMAX), 그리고 시스템을 통틀어 모든 공유 메모리 세그먼트의 총합(SHMALL) 로 구분이 되는데 이들의 최대 용량(제한 용량)은 다음과 같이 확인할 수 있습니다.

1
2
3
4
5
6
7
]# ipcs -lm
 
------ Shared Memory Limits --------
max number of segments = 4096          <--- SHMMAX
max seg size (kbytes) = 67108864      
max total shared memory (kbytes) = 17179869184   <---- SHMALL
min seg size (bytes) = 1

그런데, 여기서 주의해야 할 것이 있습니다. 커널은 이값을 지정할때에 shmmax 는 ‘bytes’ 단위이고 shmall 은 ‘pages’ 단위 입니다.

Shell
1
2
3
4
5
6
7
8
9
10
11
]# cat /proc/sys/kernel/shmmax
68719476736
]# cat /proc/sys/kernel/shmall
4294967296
]# ipcs -lm
 
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 67108864
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1

위에 보시면 커널에 할당된 shmall 값과 ‘ipcs -lm’ 해서 나온 값이 다릅니다. 이는 단위의 차이로 인한 것으로 커널의 shmall 값은 page 단위이기 때문에 다음과 같이 계산하면 ‘ipcs -lm’가 똑같아 집니다.

Shell
1
2
(4294967296 * 4096)/1024
17179869184

SHMMAX 값은 새로운 메모리 영역을 할당할때, 그러니까 shmget() 함수를 호출할때에  사용가능한 최대 메모리 양을 말합니다. 다시 강조하면 shmget()함수를 이용할때입니다. 이는 단일 프로세스가 공유메모리를 호출하기 위한 최대 값이라는 이야기 입니다.

SHMALL 은 시스템을 통틀어 모든 프로세스가 사용 가능한 공유메모리 양입니다.

이게 왜 중요해?

대부분 데이터베이스 시스템을 다룰때에 이 부분이 문제가 됩니다. ORACLE, PosgreSQL의 경우에 바로 이 공유 메모리 설정이 작으면 설치가 진행이 안된다거나 서버가 구동된다하더라도 오류 메시를 내보내고 오류를 내는 경우가 많습니다.

어떻게 설정해야 잘 하는 것일까? 혹은 적절한 값은 무엇인가는 어떤 시스템을 다루느냐에 따라서 달라집니다. PostgreSQL 의 경우에 Shared_buffers 값이 있는데, 이 값은 PostgreSQL에서 데이터를 캐쉬하는데 얼마의 RAM을 사용할 것인지를 지정합니다. PostgreSQL의 경우에 Subprocess 모델 기반으로 각 프로세스별 데이터를 공유하기위해서는 바로 공유메모리가 필요하고 Shared_buffers 는 결국 공유 메모리 입니다. 따라서 운영체제에서 PostgreSQL이 요구하는 Shared_buffers 메모리 값보다 적은 공유 메모리를 설정하면 PostgreSQL이 동작하지 않습니다.

PostgreSQL 의 경우에 Shared_buffers 메모리는 32GB 경우에 8GB 를 Shared_buffers 로 권장하고 있습니다. Shared_buffers 메모리는 공유메모리이고 단일 프로그램이 사용할 것이 때문에 SHMMAX 는 최소 8GB로 해야 합니다.

최대 공유메모리는 32GB-4GB 정도해서 28GB를 SHMALL로 지정해줍니다. 정리를하면

Shell
1
2
shmmax=8589934592 (8GB)
shmall=7340032 (32-2GB/4096)

위와같이 지정할 수 있겠습니다.

공유 메모리 사용현황

공유메모리 사용현황은 ‘ipcs -a’ 명령어를 이용해서 확인할 수 있습니다.

공유메모리 사용현황
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
]# ipcs -a
 
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0052e2c1 98304      postgres   600        32955408384 37
 
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x00000000 0          root       600        1
0x00000000 32769      root       600        1
0x0052e2c1 2654210    postgres   600        17
0x0052e2c2 2686979    postgres   600        17
0x0052e2c3 2719748    postgres   600        17
0x0052e2c4 2752517    postgres   600        17
0x0052e2c5 2785286    postgres   600        17
0x0052e2c6 2818055    postgres   600        17
0x0052e2c7 2850824    postgres   600        17
0x0052e2c8 2883593    postgres   600        17
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

Phoronix 벤치마크 하기

이 글은 Phoronix 벤치마크 하기 에 대한 글  입니다.

Phoronix 는 리눅스  벤치마크 테스트 툴 입니다. 이툴은 하드웨어 벤치마크와 소프트웨어 벤치마크를 모두 지원 합니다. 하드웨어 벤치마크는 새로운 사양의 서버가 들어왔을때에 CPU, RAM 대역폭, DISK I/O 성능들을 측정을 말하며 소프트웨어 벤치마크는 GCC 컴파일러, Kernel 성능들을 측정하는 것일 말합니다.

Phoronix 의 성능측정 결과는 HTML 파일로 저장이 되며 https://openbenchmarking.org 자동으로 포스팅하는 기능이 있어 여러사람과 결과를 공유할 수 있습니다.

Installation

설치환경은 CentOS 6 입니다. CentOS 의 경우에 Epel Yum 저장소를 추가하면 다음과 같이 Phoronix 가 설치가 가능합니다.

Phoronix 설치
Shell
1
yum search phoronix

Phoronix 사용법

Phoronix 는 벤치마크를 위한 것을 모듈로 만들어 놓고 필요한 벤치마크를 하고 싶다면 필요한 모듈을 설치하면 됩니다. 어떤 벤치마크 모듈이 있는지 확인하고 싶다면 다음과 같이 합니다.

phoronix 활용가능한 벤치마크 테스트 리스트.
1
2
3
4
5
# phoronix-test-suite list-available-tests
pts/phpbench                   - PHPBench                            System
pts/polybench-c                - PolyBench-C                         Processor
pts/portal                     - Portal                              Graphics
pts/postmark                   - PostMark                            Disk

리스트를 보면 모듈파일명, 모듈명, 영역으로 나뉘어 보여줍니다. 영역은 이 벤치마크가 무엇을 대상으로 하는지를 알려줍니다.

벤치마크 모듈은 다음과 같이 설치합니다.

phoronix 테스트 모듈 설치
Shell
1
phoronix-test-suite install compress-7zip

벤치마크를 할때는 하고자하는 벤치마크 모듈들을 연달아 적으면 됩니다.

CPU 벤치마크

CPU 벤치마크를 위해서 다음의 모듈들을 설치해 줍니다.

Shell
1
phoronix-test-suite install postmark rodinia fftw system-decompress-bzip2 c-ray compress-gzip compress-pbzip2 x264 openssl encode-mp3

그리고 다음과 같이 벤치마크를 돌립니다. 결과는 화면으로도 뿌려지지만 html 로도 저장이 됩니다.

마지막에 이와같이 OpenBenchmarking.org 사이트에 올릴거냐고 물어봅니다. 테스트결과는 /var/lib/phoronix-test-suite/test-results 에 저장이 됩니다.

Memory 벤치마크

Memory 벤치마크 모듈 설치.
1
phoronix-test-suite install ramspeed stream

필요한 모듈은 위와같이 하면 되고 테스트도 앞서 CPU 때와 비슷하게 모듈을 가지고 실행하시면 됩니다.

Disk I/O 벤치마크

Disk I/O 벤치마크 모듈 설치
1
phoronix-test-suite install fs-mark iozone hdparm-read aio-stress

벤치마크 결과

powerline vim 플러그인 설치

vim 를 사용하다보면 상태바에 많은 정보를 표시해주면 좋습니다. 이를 위해서 .vimrc 에다가 많은 설정을 사용해서 사용하지만 이것을 아예 Plugin으로 할 수 있도록 제공해주고 있습니다.

Vundle 설치

vim 플로그인을 쉽게 설치하고 제거하기를 도와주는 플로그인 매니저중에 Vundle 를 사용하겠습니다. 설치는 다음과 같이 해줍니다.

Vundle 설치.
1
2
3
$ mkdir -p ~/.vim/bundle
$ cd ~/.vim/bundle
$ git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vim

설치는 이와같이 Vundle.vim 파일을 넣어주면 끝납니다.

.vimrc 파일 수정

인터넷을 보면 다양하게 .vimrc 파일이 있습니다. 이 파일에는 어떤 플러그인을 할지도 정의되어 있습니다.

.vimrc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
syntax on
set nocompatible
set hls
set scs
set visualbell
set ignorecase
"set laststatus=2
"set statusline=%<%F%h%m%r%h%w%y\ %{strftime(\"%Y/%m/%d-%H:%M\")}%=\ col:%c%V\ ascii:%b\ pos:%o\ lin:%l\,%L\ %P
filetype off
 
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
 
Plugin 'gmarik/Vundle.vim'
 
Plugin 'Syntastic'
 
Plugin 'Shougo/neocomplete'
Plugin 'Shougo/neosnippet'
Plugin 'Shougo/neosnippet-snippets'
 
Plugin 'vim-addon-manager'
 
Bundle 'davidhalter/jedi-vim'
 
Bundle 'Lokaltog/powerline', {'rtp': 'powerline/bindings/vim/'}
 
call vundle#end()
 
filetype plugin indent on     " required!
 
"let g:syntastic_python_checkers = [ 'pep8' ]
let g:syntastic_python_checkers = [ 'flake8' ]
let g:syntastic_always_populate_loc_list = 1
let g:syntastic_auto_loc_list = 1
let g:syntastic_check_on_open = 1
let g:syntastic_check_on_wq = 0
 
" powerline
"language en_US.UTF-8
"let g:Powerline_symbols = 'fancy'
set guifont=DejaVu\ Sans\ Mono\ for\ Powerline\ 9
set laststatus=2
 
syntax on
 
" Solarized stuff
let g:solarized_termtrans = 1
set background=dark
colorscheme solarized

위의 내용에 필요한 것들을 하나씩 설치해야 합니다.

vim Plugin 설치하기

이제 필요한 것들은 모두 되었습니다. 다음과 같이 vim 에 plugin 을 설치합니다.

1
2
# vim 을 열어서 commmand mod 에서
:PluginInstall

이렇게하면 vim 창이 수직으로 분할되면서 Plugin이 설치됩니다.

solarized.vim 테마 설치

이 테마는 다음의 주소에서 다운로드 받을 수 있습니다.

설치는 다음과 같이 해줍니다.

1
2
3
4
5
6
$ cd /tmp
$ wget http://ethanschoonover.com/solarized/files/solarized.zip
$ unzip solarized.zip
$ cd solarized/vim-colors-solarized
$ mv colors ~/.vim
$ mv autoload ~/.vim

Python 코딩 스타일 자동 체크 및 수정하기

이것은 Syntastic vim 플러그인을 위한 것입니다. python 문법체크는 pyflake, pep8 등이 있는데, 이를 위해서 python 모듈을 설치해줘야 합니다.

pep8 pyflakes
1
]$ sudo pip install pep8 pyflake8 autopep8

링크: vim에서 python 으로 자동문법&수정하기

그리고 다음의 파일을 다운받아 ~/.vim 디렉토리 아래에 압축 해제합니다.

파일: Autopep8 and salt syntax checker
vim syntaxchecker for python
코딩 스타일이나 문법이 맞지 않은 파일을 열거나 저장할려고 하면 위 화면과 같이 화면이 수평분할되면서 문제를 지적해줍니다. vim 의 command mode 에서 ‘:Autopep8’ 를 입력하고 엔터를 치면 자동으로 수정을 해줍니다. 물론 문법 오류의 경우에는 수정을 해주는 경우도 있지만 안되는 경우도 있습니다만 코딩 스타일의 경우에는 대부분 자동으로 수정이 됩니다.

Ubuntu 에 zsh 설정하기

zsh 을 이용하면 다양한 테마를 사용할 수 있고 이 테마들은 각 작업때마다 터미널에 관련 작업 상태들을 표시해주어 편리합니다. 예를들어 git 를 사용하시는 분들은 zsh 를 설치하고 테마를 설정해주면 터미널에 git 관련 상태들이 프롬프트에 표시되어 편리합니다.

이 문서는 Ubuntu 에 zsh 설정하기 에 관한 글 입니다.

zsh 설치

Ubuntu 의 경우 zsh 설치는 아주 쉽습니다. apt-get 을 이용해서 설치합니다.

zsh 설치
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# apt-get install zsh
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  zsh-common
Suggested packages:
  zsh-doc
The following NEW packages will be installed:
  zsh zsh-common
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,726 kB of archives.
After this operation, 11.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu/ trusty/main zsh-common all 5.0.2-3ubuntu6 [2,119 kB]
Get:2 http://archive.ubuntu.com/ubuntu/ trusty/main zsh amd64 5.0.2-3ubuntu6 [607 kB]

테마 설치 및 설정

테마는 각 계정당 해줍니다. 사용할 계정에 설정을 해주시면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
$ wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh
--2015-09-16 16:54:57--  https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh
Resolving github.com (github.com)... 192.30.252.129
Connecting to github.com (github.com)|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh [following]
--2015-09-16 16:54:58--  https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 103.245.222.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|103.245.222.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2331 (2.3K) [text/plain]
Saving to: ‘install.sh’
 
100%[=========================================================================================================================================>] 2,331       --.-K/s   in 0s
 
2015-09-16 16:54:58 (214 MB/s) - ‘install.sh’ saved [2331/2331]
 
$ sh install.sh
Cloning Oh My Zsh...
Cloning into '/home/salt/.oh-my-zsh'...
remote: Counting objects: 680, done.
remote: Compressing objects: 100% (552/552), done.
remote: Total 680 (delta 15), reused 508 (delta 3), pack-reused 0
Receiving objects: 100% (680/680), 418.75 KiB | 301.00 KiB/s, done.
Resolving deltas: 100% (15/15), done.
Checking connectivity... done.
Looking for an existing zsh config...
Using the Oh My Zsh template file and adding it to ~/.zshrc
Copying your current PATH and adding it to the end of ~/.zshrc for you.
Time to change your default shell to zsh!
Password:
         __                                     __
  ____  / /_     ____ ___  __  __   ____  _____/ /_
/ __ \/ __ \   / __ `__ \/ / / /  /_  / / ___/ __ \
/ /_/ / / / /  / / / / / / /_/ /    / /_(__  ) / / /
\____/_/ /_/  /_/ /_/ /_/\__, /    /___/____/_/ /_/
                        /____/                       ....is now installed!
 
 
Please look over the ~/.zshrc file to select plugins, themes, and options.
 
 
p.s. Follow us at http://twitter.com/ohmyzsh.
 
 
p.p.s. Get stickers and t-shirts at http://shop.planetargon.com.
➜  ~

마지막에 기본쉘을 바꾸기위해서 사용자 계정의 패스워드를 물어보고 입력을 해주면 기본쉘이 zsh 로 바뀝니다.

이제 git 프롬프트를 위해 테마설정 작업을 해줍니다. 설치할때 Oh-My-Zsh 를 이용했기 때문에 이를 위한 테마를 설치해줍니다.

1
2
3
4
$ cd ~/.oh-my-zsh/custom
$ git clone https://github.com/bhilburn/powerlevel9k.git themes/powerlevel9k
$ vim ~/.zshrc
ZSH_THEME="powerlevel9k/powerlevel9k"

이제 로그아웃 했다가 로그인을 하면 프롬프트가 바뀌어 있고 git 디렉토리에 들어가면 프롬프트에 git 상태가 표시가 됩니다.

프롬프트에는 glyphs 를 표시해주기도 하는데, 이를 위해서는  powerline font patch 를 해줘야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
$ mkdir ~/.fonts
$ cd ~/.fonts
$ wget https://github.com/powerline/powerline/raw/develop/font/PowerlineSymbols.otf
$ wget https://github.com/powerline/powerline/raw/develop/font/10-powerline-symbols.conf
$ fc-cache -vf ~/.fonts/
/home/salt/.fonts: caching, new cache contents: 1 fonts, 0 dirs
/home/salt/.fonts: caching, new cache contents: 1 fonts, 0 dirs
/var/cache/fontconfig: not cleaning unwritable cache directory
/home/salt/.cache/fontconfig: cleaning cache directory
/home/salt/.fontconfig: not cleaning non-existent cache directory
fc-cache: succeeded
$ mkdir ~/.config/fontconfig/conf.d/
$ mv 10-powerline-symbols.conf ~/.config/fontconfig/conf.d/

마지막으로 power line patched font 를 설치해줍니다.

1
2
3
4
5
6
7
$ cd /tmp
$ git clone https://github.com/powerline/fonts.git
$ cd fonts
$ sh install.sh
install.sh: 8: install.sh: [[: not found
install.sh: 21: install.sh: [[: not found
All Powerline fonts installed to /home/salt/.fonts

관련 링크

AWS Kinesis

이 글은 AWS Kinesis 이 무엇인지에 대한 개념적인 글입니다.

다음의 자료를 기반으로 작성되었습니다.

  1. Introducing Amazon Kinesis (SlideShare)
  2. Introduction to Amazon Kinesis (Youtude)

Big Data

인터넷의 발전으로 인해서 하루에도 계산하기 힘든 데이터가 쏟아집니다. 과거와는 달라진 이러한 환경을 우리는 간단히 Big Data 시대라고 하지요. 어찌보면 과거에도 Big Data 는 있었지만 요즘과 구별되는 것은 누구든지 Data 를 생산할 수 있다는데에 있습니다. 그러다보니  과거와는 다르게 쏟아지는 데이터를 분석해서 유의미한 데이터를 뽑아내는 기술이 필요하게 되었는데 이게 바로 Big Data 의 진정한 의미 중에 하나 입니다.

누구나 생산해내는 데이터들을 유의미한 의미의 정보로 가공해내는 것이 바로 Big Data 기술이라고 할 수 있습니다.

Batch VS Streaming

과거 이야기를 좀 더 해보면, 과거에도 데이터를 분석해내는 방법이 있었습니다. 첫번째로는 데이터를 모우는 겁니다. 그리고 그것을 특정한 저장소에 저장을 합니다. 대부분 데이터베이스시스템에 저장을 했습니다. 그리고 그것을 이용해서 쿼리문을 이용해서 데이터를 뽑아 냈습니다.

그런데, 데이터를 모으고 데이터베이스에 저장하고 하는 부분은 특정 시간에 서버에 작업을 걸어놓아하는 경우가 많았습니다. 간단하게는 리눅스 시스템에서 크론(Cron) 을 이용해서 특정 배치 프로그램을 돌려서 데이터를 모우고 데이터베이스에 집어넣는 방법을 이용했지요.

하지만 Big Data 시대에 이 방법이 과연 유용한가 하는 문제가 있습니다. 몇분, 몇시간, 몇일간격으로만 배치작업을 돌리는건 쏟아지는 데이터 속도보다 빠르지 못하다보니 데이터분석을 할 수 없는 경우가 많습니다. 설사 분석을 해낸다고 해도 이미 시간이 많은 흐른뒤라서 시의성을 가지지 못하는 정보가 될 겁니다.

그래서 등장한 것이 스트리밍(Streaming) 입니다. 스트리밍, 물 흐르듯 그때그때 데이터를 분석해내면 유용한 정보를 얻기위해서 기달릴 필요가 없을 겁니다. 그때 그때 분석한 데이터를 데이터베이스에 저장하거나 파일로 저장하는것도 가능합니다.

그래서 현대의 Big Data 분석 소프트웨어들은 전부다 Streaming 을 지원하도록 발전되어 왔습니다.

현대의 BigData 구조
현대의 BigData 구조

많은 소프트웨어들이 이렇게 데이터 수집, 분석처리, 저장, 분석 및 리포트 영력으로 나뉘어 발전되어지고 있습니다.

위 그림에서 문제가 하나 있습니다. 데이터 수집 부분과 데이터 처리부분 입니다. 이 부분이 문제가 되는 이유는 데이터 수집하는 소프트웨어와 처리하는 소프트웨어간의 데이터 교환을 맞춰줘야 하고 둘이 동기화 되어 처리되어야 합니다. 어느 한쪽이 병목이 생기면 문제가 생길 수도 있습니다.

AWS Kinesis

AWS Kinesis 는 데이터 수집구간과 데이터 처리구간 중간에 위치합니다. 이렇게 중간에 위치하는 소프트웨어를 만든 이유는 다양한 데이터들을 수집하고 이것을 다양한 포맷으로 만들어 줍니다.

Kinesis 를 이해하는데 헷깔리는게 있는데, Kinesis 가 ‘스트리밍 데이터 처리’ 를 해준다는 것입니다. 여기서 스트리밍 데이터 처리라는 말은 스트리밍으로 데이터를 분석해준다는 이야기가 아닙니다.

다양한 형태로 들어오는 데이터를 가공해서 다양한 분석 소프트웨어가 사용가능하도록 다양한 출력물을 만들어내주거나 데이터 저장소에 저장하도록 해줍니다.

기본의 Streaming 처리
기본의 Streaming 처리

기존의 Streaming 처리구조 입니다. 수많은 다양한 데이터들이 들어오고 이것을 처리하는 가공하고 분석하는 도구들이 붙어 있습니다.

AWS Kinesis
AWS Kinesis

AWS Kinesis 는 다양한 데이터들을 빠르게 가공해줍니다. 그리고 이러한 데이터들은 다양한 포맷으로 출력줌으로써 다양한 소프트웨어서 사용해주게 해줍니다.

다어그램으로 표현하면 다음과 같습니다.

AWS Architecture
AWS Architecture

AWS Kinesis 는 다양한 입력 데이터와 출력을 해줍니다.

AWS Kinesis Sending & Reading Data from Kinesis Streams
AWS Kinesis Sending & Reading Data from Kinesis Streams

Amazon 에서는 Kinesis 를 다음과 같이 설명하고 있습니다.

Amazon Kinesis는 완전관리형 스트리밍 데이터 서비스입니다. 수십만 개의 소스에서 클릭 스트림, 애플리케이션 로그, 소셜 미디어와 같은 다양한 유형의 데이터를 Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다. 그러면 몇 초 안에 Amazon Kinesis 애플리케이션에서는 스트림의 해당 데이터를 읽고 처리할 수 있습니다.

“Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다” 이 말의 의미를 잘 생각해본다면 이것이 무엇인지 감을 잡을 수 있을 겁니다.