* 온프레미스(on-premise): 기업이 데이터 센터를 보유하고 시스템 구축부터 운영까지 모두 수행하는 방식을 온프레미스라고 합니다. 반면 클라우드는 데이터 센터를 보유하지 않아서 탄력적인 인프라 구성이 가능하고 서버나 네트워크 등 초기 시스템 투자에 드는 비용이 적은 대신 시간이 지날 수록 온프레미스에 비해 유지비용이 많이 발생합니다.
* 도커 컨테이너: 도커 이미지가 메모리 위에 상주하여 실제 코드가 수행되는 프로세스
* 도커 이미지: 사용자가 실행할 코드가 들어있는 바이너리. 한번 생성하면 수정이 불가능
* 컨테이너는 휘발성 프로세스 입니다. 컨테이너 내부의 파일시스템에 파일로 저장하였다 하더라도 컨테이너 삭제시 모든 데이터가 사라집니다. 그렇기 때문에 설치하더라도 컨테이너를 종료하면 설치된 패키지가 없어집니다.
* 도커파일 작성
도커이미지를 생성하기 위해서는 Dockerfile이라는 텍스트 문서를 작성해야 합니다.
사용자는 Dockerfile에 특정 명령을 기술하여 원하는 도커이미지를 생성합니다.
특정명령이란,
- Dockerfile에 기반이미지를 지정
- 원하는 소프트웨어 및 라이브러리를 설치하기 위한 명령을 기술
- 컨테이너 실행시 수행할 명령을 기술하는 것
Dockerfile 기초
1. 도커빌드
docker build <PATH> -t <IMAGE_NAME>:<TAG>
ex) docker build . -t hello:1
[DEV][ sfs@localhost /home/sfs/dock ] $ docker run hello:1 hello guest, my version is 1.0 [DEV][ sfs@localhost /home/sfs/dock ] $ docker run hello:1 pwd /root [DEV][ sfs@localhost /home/sfs/dock ] $ docker run -e my_ver=1.5 hello:1 hello guest, my version is 1.5 [DEV][ sfs@localhost /home/sfs/dock ]
2. Dockerfile 심화
ARG
Dockerfile 안에서 사용할 수 있는 매개변수를 정의합니다. 파라미터로 넘겨지는 변수의 값에 따라, 생성되는 이미지 내용을 바꿀 수 있습니다.
[DEV][ root@localhost /root ] $ vi /etc/firewalld/zones/public.xml <?xml version="1.0" encoding="utf-8"?> <zone> <short>Public</short> <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description> <service name="ssh"/> <service name="dhcpv6-client"/> <port protocol="tcp" port="3306"/> <port protocol="tcp" port="9000"/> </zone>
서버는 socket 함수를 호출해서 소켓을 생성하고, bind 함수로 포트에 연결한 후 listen함수로 클라이언트로부터 연결 요청을 받는다.
이때 소켓의 상태는 CLOSED에서 LISTEN이 된다. 클라이언트가 connect 함수를 호출하면 서버는 LISTEN 상태에서 SYN_RCVD 상태가 된 다음 ESTABLISHED 상태가 된다. 자료의 전송은 서버와 클라이언트 모두 ESTABLISHED 상태일 때 가능하다.
연결의 종료는 누가 먼저 종료를 시작하는가에 따라 상태가 달라지는데, 서버의 경우 클라이언트에서 먼저 종료를 시작하면 CLOSE_WAIT, LAST_ACK 상태를 거쳐 CLOSED 상태가 된다. 반대로 서버에서 먼저 종료를 시작하면 FIN_WAIT_1, FIN_WAIT_2, TIME_OUT 상태를 거쳐 CLOSED 상태가 된다.
클라이언트는 우선 socket 함수를 호출해서 소켓을 생성하고, connect 함수를 호출해서 서버와 연결하는데, SYN_SENT 상태를 거쳐 ESTABLISHED 상태가 된다. 그러면 자료의 송수신이 가능하게 된다.
연결준비단계
TCP는 연결형 서비스이다. 따라서 TCP로 통신하려는 두개의 호스트는 별도의 제어정보를 주고받음으로써 호스트간의 연결을 이루어낸다.
클라이언트의 응용프로그램에서 서버와 연결하기 위해 connect 함수를 호출하면 특정 제어비트를 1로 설정한 TCP 패킷을 서로 교환함으로써 이루어지는데 패킷 3개를 서로 교환하기 때문에 3-way handshaking이라고 부른다.
* 1단계(SYN 패킷 전송)
우선 클라이언트는 제어비트(control bit)중 SYN 비트를 1로 설정한 TCP 제어 패킷(SYN 패킷)을 서버로 전송해 연결을 시도한다.
TCP는 송수신되는 자료의 바이트 순서를 관리하는데, SYN 패킷에 기록된 일련번호와 확인번호 필드의 값으로 순서를 추척한다.
처음 SYN 패킷에는 클라이언트가 사용할 일련번호의 시작값을 일련번호 필드에 기록해서 전송한다.
즉, SYN 패킷의 일련번호 필드에는 연결후 자료를 송수신할 때 사용할 ISN이 있다.
* 2단계(SYN_ACK 패킷 전송)
서버는 제어비트중 SYN비트와 ACK비트를 1로 설정한 SYN_ACK 패킷을 클라이언트로 전송함으로써 클라이언트에게 SYN 패킷을 잘 받았음을 알린다. 역시 서버가 사용할 ISN을 SYN_ACK 패킷의 일련번호 필드에 기록해서 전송한다.
* 3단계(ACK 패킷전송)
클라이언트는 2단계의 SYN_ACK 패킷을 서버로부터 받은후 두 호스트간에 연결이 되었다는 것을 확인하고, 제어비트의 ACK 비트를 1로 설정한 TCP 제어패킷을 서버로 보낸다.
자료 송수신 단계
원격지로 자료를 전송할 때 응용 프로그램의 버퍼의 내용은 커널의 TCP 송신버퍼로 복사된다.
응용프로그램의 버퍼의 내용 모두가 커널의 TCP 송신버퍼에 복사될 때가지 응용프로그램은 차단된다.
TCP 송신버퍼의 크기는 옵션 SO_SNDBUF으로 지정한다.
응용프로그램의 버퍼의 크기가 크거나 송신버퍼에 비어있지 않아서 모두 복사하지 못하면 응용프로그램이 차단된다.
TCP 소켓옵션
#include <sys/types.h>
#include <sys/socket.h>
int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen);
s: 옵션을 읽거나 수정하려는 소켓 기술자
level: 옵션을 해석하는 커널 내 시스템 코드의 구분
optname: 소켓의 옵션을 수정할 옵션 이름
optval: 수정할 옵션의 값
optlen: 인자 optval의 메모리 크기
SO_KEEPALIVE 옵션
SO_KEEPALIVE 옵션은 TCP 소켓에 적용된다. 이 옵션을 1로 설정하면 일정시간(통상 2시간)동안 해당 소켓을 통해 어떤 자료도 송수신되지 않을때, 커널에서 상대방의 상태를 확인하는 패킷을 전송한다.
소켓이름
처리구분
적용 프로토콜
SO_KEEPALIVE
SOL_SOCKET
TCP
ACK 패킷으로 정상이라고 응답하는 경우 응용프로그램에는 어떠한 통보도 하지 않고 커널간의 확인만으로 상대방이 살아있음을 확인하고 마무리 한다. 상대방으로부터 아무런 응답이 없거나 RST 응답을 받으면 소켓을 자동으로 종료한다.
기본적으로 SO_KEEPALIVE 옵션은 서버측 소켓에 설정되어 상대방 시스템의 고장이나 정전, 네트워크 연결이 끊기는 등 통신이 불가능한 상황을 탐지해준다. 상대방 시스템이 고장난 경우 ETIMEOUT 오류를, 상대방 시스템까지 네트워크 연결이 불가능한 경우 EHOSTUNREACH 오류를 반환한다. 응용프로그램에서는 해당 오류에 따라 처리하면 된다. 시스템이나 네트워크 문제가 아닌 응용프로그램 문제라면 으용프로그램이 종료될 때 상대방 커널에서 FIN 패킷을 보내 연결 종료를 시작하기 때문에 응용 프로그램에서는 EOF에 대한 처리를 하면 된다.
나중에 클라이언트로부터의 연결 요청을 받을 수 있도록 socket 함수를 이용하여 네트워크 연결 장치인 소켓을 생성한다.
아래 예는 TCP용 전화기를 준비한 경우라 할 수 있다. 즉, TCP 통신이 가능한 TCP용 소켓을 생성하였다고 생각하면 된다.
int s_socket = socket(PF_INET, SOCK_STREAM, 0);
2. 연결 요청을 수신할 주소 설정
클라이언트로부터의 연결 요청을 받을 서버 IP주소와 포트를 설정하고 있다.
여기서 IP주소는 INADDR_ANY, 포트번호는 9000번으로 설정하고 있는데, 이는 현재 서버의 9000번 포트를 목적지로 하는 모든 연결 요청에 대해 처리하겠다는 의미이다. IP주소로 INADDR_ANY를 설정한 이유는 한 컴퓨터에 여러장의 랜카드가 장착되어 있어서 여러개의 IP 주소가 할당되고, 서버 응용프로그램은 이들 IP를 통해 들어오는 모든 연결요청을 받아 처리해야 하기에 사용한 것이다.
c_socket으로 변수 c_addr에 설정된 주소에 연결을 시도한다. 이와 관련해서 서버와의 연결은 커널 내부에서 3-way handshaking을 거쳐 이루어진다. 클라이언트는 클라이언트 커널에서 서버연결에 사용할 포트(예: 2345번 포트)를 결정하기 때문에 클라이언트 프로그램에서는 포트번호를 특별히 지정하지는 않는다.
SO_KEEPALIVE 옵션은 TCP 소켓에 적용된다. 이 옵션을 1로 설정하면 일정 시간(통상 2시간)동안 해당 소켓을 통해 어떤 자료도 송수신되지 않을 때, 커널에서 상대방의 상태를 확인하는 패킷을 전송한다. 이 패킷에 대해 상대방이 정상적이면 ACK 패킷을 전송한다.
ACK 패킷으로 정상이라고 응답하는 경우 응용 프로그램에는 어떠한 통보도 하지 않고 커널 간의 확인만으로 상대방이 살아 있음을 확인하고 마무리한다. 상대방으로부터 아무런 응답이 없거나 RST 응답을 받으면 소켓을 자동으로 종료한다.
기본적으로 SO_KEEPALIVE 옵션은 서버측 소켓에 설정되어 상대방 시스템의 고장이나 정전, 네트워크 연결이 끊기는 등 통신이 불가능한 상황을 탐지해 준다. 상대방 시스템이 고장난 경우 ETIMEOUT 오류를, 상대방 시스템까지 네트워크 연결이 불가능한 경우 EHOSTUNREACH 오류를 반환한다. 응용 프로그램에서는 해당 오류에 따라 처리하면 된다. 시스템이나 네트워크 문제가 아닌 응용 프로그램 문제라면 응용 프로그램이 종료될 때 상대방 커널에서 FIN 패킷을 보내 연결 종료를 시작하기 때문에 응용 프로그램에서는 EOF에 대한 처리를 하면 된다.
만약 SO_KEEPALIVE 옵션이 설정되지 않은 상태에서 상대방 시스템이 고장이거나 네트워크 연결 등에 장시간 문제가 발생하면 응용 프로그램은 아무런 상황을 모른 체로 계속해서 상대방의 응답을 기다려야 하는 상황이 발생한다.
SO_KEEPALIVE 옵션은 자료의 송수신이 일정 시간 동안 없을 경우 응용 프로그램이 아닌 커널에서 상대방의 상태를 파악하기 위해서 패킷을 보내는 옵션임을 알았다. 그런데 여기서 일정 시간은 보통 2시간 정도이고, 커널 변수로 관리된다. 따라서 커널 변수를 수정해서 시간을 조정할 수 있지만, 이런 경우 다른 모든 소켓에도 적용되기 때문에 전체 성능에 영향을 준다. 때문에 신중을 기해야 한다.
This means the interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the connection is marked to need keepalive, this counter is not used any further
Epoll은 리눅스에서 select의 단점을 보완하여 사용할 수 있도록 만든 I/O통지 모델이다.
파일 디스크립터를 사용자가 아닌 커널이 관리를 하며, 그만큼 CPU는 계속해서 파일 디스크립터의 상태 변화를 감시할 필요가 없다.
즉, select처럼 어느 파일 디스크립터에 이벤트가 발생하였는지 찾기 위해 전체 파일디스크립터에 대해서 순차검색을 위한 FD_ISSET 루프를 돌려야 하지만, Epoll의 경우 이벤트가 발생한 파일 디스크립터들만 구조체 배열을 통해 넘겨주므로 메모리 카피에 대한 비용이 줄어든다.
#incude <sys/epoll.h>
int epoll_create(int size)
fd들의 입출력 이벤트 저장을 위한 공간을 만들어야 하는데, epoll_create는 size만큼의 입출력 이벤트를 저장할 공간을 만든다. 그러나 리눅스 2.6.8 이후부터 size 인자는 사용되지 않지만 0보다는 큰 값으로 설정을 해 주어야 한다. 커널은 필요한 데이터 구조의 크기를 동적으로 조정하기 때문에 0보다 큰 값만 입력하면 된다.
반환 값으로는 정수형 데이터가 반환이 되는데, 이를 일반적으로 epoll fd라하며 이 fd를 통해 앞으로 epoll에 등록 된 fd들을 조작하게 된다.
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
epoll_ctl은 epoll에 fd들을 등록/수정/삭제를 하는 함수인데 일반적으로 epoll이 관심을 가져주길 바라는 fd와 그 fd에서 발생하는 관심있는 사건의 종류를 등록하는 인터페이스로 설명된다.
* epfd : epoll fd 값
* op : 관심가질 fd를 등록할지, 등록되어 있는 fd의 설정을 변경할지, 등록되어 있는 fd를 관심 목록에서 제거할지에 대한 옵션값
* fd : epfd에 등록할 관심있는 파일 디스크립터 값
* event : epfd에 등록할 관심있는 fd가 어떤 이벤트가 발생할 때 관심을 가질지에 대한 구조체. 관찰 대상의 관찰 이벤트 유형
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout)
epoll_wait는 관심있는 fd들에 무슨일이 일어났는지 조사한다. 다만 그 결과는 select나 poll과는 차이가 있다. 사건들의 리스트를 (epoll_event).events[] 의 배열로 전달한다. 리턴값은 발생한 사건들의 갯수가 리턴된다.
* events : 이벤트가 발생된 fd들을 모아놓은 구조체 배열.
* maxevents : 실제 동시접속수와 상관없이 maxevents 파라미터로 최대 몇개까지의 event만 처리할 것임을 지정해 주도록 하고 있다. 만약 현재 접속수가 1만이라면 최악의 경우 1만개의 연결에서 사건이 발생할 가능성도 있기 때문에 1만개의 events[] 배열을 위해 메모리를 확보해 놓아야 하지만, 이 maxevents 파라미터를 통해 한번에 처리하길 희망하는 숫자를 제한할 수 있다.
* timeout : epoll_wait의 동작특성을 지정해주는 중요한 요소인데, 밀리세컨드 단위로 지정해주도록 되어 있다. 이 시간만큼 사건발생을 기다리라는 의미이며 기다리는 도중에 사건이 발생하면 즉시 리턴된다.
-> timeout(-1)로 지정해주면 영원히 사건을 기다리는 blocking상태가 된다.
-> timeout(0)로 지정해주면 사건이 있건 없건 조사만 하고 즉시 리턴하는 상태가 된다.
Edge Trigger(ET)
특정 상태가 변화하는 시점에서만 감지.
특정 디지털 신호 000 111 000 111 000 111 일 경우 신호가 0에서 1로 변하는 시점에서만 이벤트가 발생한다.
소켓 버퍼에 대응하면, 한번에 읽을 수 있는 데이터 버퍼가 600인데, 데이터가 1000바이트가 도착했다면, 600바이트만 읽고 나머지 400바이트는 읽지 않은 상태에서 더 이상의 이벤트는 발생하지 않는다.
읽은 시점을 기준으로 보면 더이상의 상태 변화가 없기 때문이다.
따라서 한번에 읽을 수 있는 바이트 이상의 데이터가 오게 된다면 추가적인 작업을 따로 해주어야 한다.
ET로 작동하게 하려면 Non-blocking 소켓으로 생성해 줘야 하며 epoll에 관심 FD로 등록 할 때 EPOLLET로 설정해 주어야 한다.
서버의 트리거 모드가 엣지 트리거인 경우,한번에 전송 가능한 패킷 버퍼 사이즈보다 보내야 하는 데이터의 사이즈가 더 클 경우, 여러번에 걸쳐 write를 하게 되면 엣지 트리거의 특성상 정상적으로 데이터를 전부 읽어드릴 수 없는 경우가 생긴다.
Level Trigger(LT)
특정 상태가 유지되는 동안 감지.
특정 디지털 신호 000 111 000 111 000 111 에서 1에 대한 Trigger 라면 1이 유지되는 시간동안 횟수에 상관없이 이벤트가 발생한다.
소켓 버퍼에 대응하면, 한번에 읽을 수 있는 데이터 버퍼가 600인데, 데이터가 1000바이트 도착했다면, 600바이트를 읽고 소켓 버퍼에 아직 데이터가 유지되고 있는 1인 상태이기 때문에 한번 더 이벤트가 발생하여 나머지 400바이트를 읽게 된다. 즉, 소켓 버퍼가 비어지는(0이 되는) 순간까지 계속해서 이벤트가 발생이 된다.
LT는 기본으로 설정되어 있으며 select나 poll은 LT만 지원이 된다.
서버의 트리거 모드가 레벨 트리거인 경우, 입력 버퍼에 데이터가 수신된 상황에서 이를 빠르게 읽어들이지 않으면 epoll_wait() 함수를 호출할 때 마다 이벤트가 발생하게 된다. 이로인해 발생하는 이벤트의 수가 계속 누적되는데, 이를 현실적으로 감당하는건 불가능하다. 따라서, 정상적인 접속-접속종료 테스트에 대한 처리가 불가능해질 수 있다.
