y-log

Elasticsearch를 처음 설치하다 보면 항상 보는 에러들이 몇 가지 있습니다.

 1) root 계정으로 실행할 수 없으며

 2) openfiles, max process 값을 수정해야하고

 3) swappiness 값 설정 변경 요청도 있습니다.

Elasticsearch 실행 시 발생한 Max user processes Error

그 중에 elasticsearch는 openfiles와 max process는 최소 65535로 설정하라며, 커널에서 해주는 기본 설정보다 큰 값을 요구하는데요,

오늘은 해당 파라미터가 정확히 어떤 것을 가르키는지 그리고 설정된 값 이상이 되면 어떤 일이 일어나는지 알아보겠습니다.

1. Max user processes

Max user processes의 의미는 하나의 계정에서 최대로 실행할 수 있는 process의 개수를 말합니다. OS에서의 확인은

# ulimit -a (sofe ulimit)

# ulimit -aH (hard ulimit)

위 명령으로 확인 가능합니다. (현재 제 서버의 설정 값은 아래와 같습니다.)

max user processes

그럼 아래 테스트 코드를 통해 설정된 max user processes의 값을 넘기면 어떻게 되는지 확인해보겠습니다.

4000개 Thread 생성 후 유지

대략적인 코드의 내용은 HTTP 요청이 오면 비동기로 4천개의 Thread를 동시에 생성하고 20분간 유지하는 코드입니다.

그리고 실제로 Thread를 늘려보면,

Thread 생성 중 OOM 발생

그림처럼 ulimit -a 명령의 max user processes 결과와 같이 ec2-user 계정은 1024개까지 스레드를 생성한 후, OOM 에러 메세지를 발생하며 멈춰버리게 됩니다. (이 경우 ec2-user 계정에서는 쉘 명령어 입력 등 어떤 작업도 동작하지 않습니다.)

<리눅스에서는 스레드와 프로세스를 동일하게 봅니다.>

2. Open files

다음은 Open files입니다. 이 값은 프로세스가 가질 수 있는 최대 파일의 개수를 의미합니다.

리눅스는 모든 프로세스나 세션(소켓)들을 파일로 관리하기 때문에 이 값의 설정은 서버에서의 Connection연결 작업에 매우 중요한 내용이 됩니다.

(설정 값을 넘어가게 되면 리눅스에서 파일을 열 수 없어 프로세스 실행이나 Connection 연결이 안되기 때문!)

그럼 소켓을 open files 값 보다 많이 만들어 테스트를 해보겠습니다.

(1) Java 환경 TEST

 - RestTemplate로 소켓 생성 요청을 보내고, 요청을 받은 서버에서 20분간 응답을 대기 시킵니다.

 - 요청을 동시에 1100개를 보내 open files가 1024로 제한인 서버에 에러가 발생하면 테스트 성공입니다.

   (기본적으로 java, spring 관련 file이 몇 개 오픈됩니다.)

아래는 테스트 코드 일부입니다.

connection 소켓 생성 후 응답 대기 Code

그리고 동시에 요청을 보낼 API 요청 스크립트를 작성합니다.

API 요청 쉘

쉘을 실행하여 테스트를 진행하면…

openfiles 개수가 1024 값을 넘어 1516개 까지 열림!

위 그림처럼 소켓이 1024개가 넘어도 에러 메시지 없이 동작하는 것을 볼 수 있습니다. 그럼 한번 더 스크립트를 실행해보겠습니다.

2048개 까지 생성된 모습

이제 에러가 발생했습니다. 파일은 딱 2048개 까지만 열린 것을 확인할 수 있는데요, openfiles의 값은 soft로 설정된 값이 아닌

그림처럼 Hard 옵션 값까지 file이 생성된다는 것을 알 수 있습니다.

그런데…! 알고 보니 java 환경에서는 hard 값을 따라가는게 맞지만 Python에서는 아니라고 합니다…

(2) Python 환경 TEST

빨간 박스 : 1024개의 열린 파일 생성 / 파란 박스 : 1024개 이후 파일을 하나 더 열어본다

위 처럼 파이썬 스크립트로 file을 임의로 열어봅니다. 1021개 까지는 파일이 문제없이 열리지만(stdin, stdout, stderr 표준 입/출력 3개 제외)

이후로 여는 파일에서는 Too many open files 에러가 발생합니다!

(3) Java와 Python 환경의 차이?

테스트 결과 Java는 hard 옵션까지 파일이 오픈되고 Python은 soft 값까지 오픈됨을 알 수 있었습니다. 그 이유를 찾기 위해 strace 명령을 통해 java 프로세스 동작을 추적해보면

kernel 5.15ver에서 테스트 (이전 버전은 prlimit64 함수 대신 getrlimit, setrlimt 함수 사용)

위 그림처럼 java 프로세스가 시작됨과 동시에 prlimit64라는 함수가 rlim_cur=1024값을 rlim_max=2*1024(hard limit) 값까지 업데이트하는 로그가 찍혀있는 것을 볼 수 있었습니다.

JDK에서 MaxFDLimit 옵션 활성화 (기본값)

그 이유는 설치된 JVM에서 MaxFDLimit 옵션을 통해 limit을 올려주었기 때문이라고 합니다! (기본적으로 활성화된 옵션)

즉, 리눅스 OS에서는 JDK 실행 시 커널에서 prlimit64 함수를 통해 자동으로 limit 사이즈를 증가시켜준다는 것을 알 수 있었습니다.

3. 정리

 - (Linux 환경) JAVA에서 동시에 생성 가능한 쓰레드 수는 Max user processes를 따라간다.

 - (Linux 환경) JAVA에서 소켓 통신(API나 모든 Connection)은 open files 옵션을 따라간다.

  -> JAVA에서는 JDK 코드에서 자동으로 soft limit값은 hard limit값까지 업데이트 됨

  -> Python은 soft limit 값에서 제한이 걸림

나의 개발 환경에 맞게, Max user processes와 open files의 적절한 값을 찾아 설정하는 것이 중요하겠습니다!

<공동저자>

https://giraffe-lee.tistory.com/7

<참조>

https://techblog.woowahan.com/2569/

네트워크 구성하기

VPC, Subnet, Route Table, Internet Gateway, EndPoint 그리고 IaC

AWS VPC (Virtual Private Cloud)란?

AWS Cloud 내부에서 구성되는 사용자의 AWS 계정 전용 가상 네트워크로 이곳에서 AWS 리소스를 시작할 수 있다.

AWS에서는 디폴트로 Amazon EC2-VPC를 제공하지만 Amazon VPC는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사하다.

또한 AWS VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. IP 주소 범위와 VPC 범위를 설정하고 서브넷을 추가하고 보안 그룹을 연결한 다음 라우팅 테이블을 구성한다.

VPC는 Amazon 콘솔에서 생성된다. 또한 하나의 VPC는 하나의 Region내에서만 생성이 가능하지만 두개 이상의 리전에 걸치는 것은 불가능하다. 하지만 하나의 VPC는 여러 개의 AZ에 걸쳐서 생성될 수 있고 가질 수 있는 IP 주소의 range는 2^16으로 제한된다.

VPC는 독립된 하나의 네트워크를 구성하기 위한 가장 큰 단위이다. 각 region에 종속되며 [RFC1918](https://tools.ietf.org/html/rfc1918)이라는 사설 IP 대역에 맞추어 설계해야 한다. VPC에서 사용하는 사설 IP 대역은 아래와 같다.

1️⃣ 10.0.0.0 ~ 10.255.255.255(10/8 prefix)

2️⃣ 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)

3️⃣ 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)

각 대역폭마다 고정되어있는 prefix가 다르다. IPv4 주소인 xxx.xxx.xxx.xxx에서 .으로 구분된 xxx은 0~255 사이의 숫자이며 이는 8bits로 표현할 수 있다. 즉 1번은 00001010~, 2번은 0101100.0001~, 3번은 11000000.10101000~가 앞에 고정되어 있고 나머지 주소 범위에 해당하는 IP 주소를 할당할 수 있다. 아래와 같이 10.0.0.0/16으로 설정된 IP 대역폭은 총 65,536개의 프라이빗 IPv4 주소를 가진다.

VPC에서 한번 설정된 IP 대역은 수정할 수 없으며 각각의 VPC는 독립적이기 때문에 서로 통신할 수 없다. 만일 통신을 원한다면 VPC 피어링 서비스를 통해 VPC 간에 트래픽을 라우팅할 수 있도록 설정할 수 있다.

public / private Subnet이란?

서브넷은 VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻한다. VPC를 잘게 나눈 것이 서브넷이기 때문에 VPC보다 대역폭이 낮으며 하나의 AZ(Availability Zone)에 하나의 서브넷이 연결되기 때문에 region의 AZ 수를 미리 확인하고 설정해야한다.

서브넷은 다시 Public Subnet과 Private Subnet으로 나뉠 수 있다. 인터넷과 연결되어있는 서브넷을 public subnet이라고 하고 인터넷과 연결되어있지 않은 서브넷을 private subnet이라고 한다. 이처럼 인터넷 연결 여부로 subnet을 구분하는 이유는 보안을 강화하기 위함이다. public subnet에 존재하는 인스턴스는 인터넷에 연결되어 아웃바운드, 인바운드 트래픽을 주고받을 수 있다. 반면 private subnet은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없다. 즉 인터넷과 연결되어 외부에 노출되어 있는 면적을 최소화함으로써 네트워크 망에 함부로 접근하는 것을 막기 위함이다.

VPC 내에는 보통 public subnet과 private subnet으로 구성되어 있다.

• public subnet
  • internet gateway, ELB, public IP/Elastic IP를 가진 인스턴스를 내부에 가지고 있다.
  • 특히 Public subnet 내에 있는 nat instance를 통해서 private subnet 내에 있는 instances이 인터넷이 가능하게 한다.
• private subnet
  • 기본적으로 외부와 차단되어 있다.
  • private subnet 내의 인스턴스들은 private ip만을 가지고 있고 internet inbound/outbound가 불가능 하고 오직 다른 서브넷과의 연결만이 가능하다.

Router

라우터는 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야 하는지 알려주는 표지판 역할을 수행한다. 각각의 서브넷은 네트워크 트래픽 전달 규칙에 해당하는 라우팅 테이블을 가지고 있으며 요청이 발생하면 가장 먼저 라우터로 트래픽을 전송한다. 일반적으로 VPC 내부 네트워크에 해당하는 주소는 local로 향하도록 한다

Routing Table

네트워크상의 특정 목적지까지의 거리와 가는 방법등을 명시하고 있는 테이블로 라우터는 어떤 목저지를 찾아갈 때 이 라우팅 테이블을 보고 찾아가게 된다. 쉽게 말하면 라우터가 여러 가지 정보를 종합해서 얻어낸 네트워크에 대한 지도를 라우팅 테이블이라고 한다.

ip address에 routing 경로를 정의하여 subnet에서 밖으로 나가는 outbound traffic에 대한 routing 경로를 설정하는 것

VPC 내에는 subnet이 있고 각 subnet은 각기 다른 네트워크 대역을 가지고 있고 한 subnet에서 다른 한쪽 subnet으로 가기 위해서는 라우팅이 필요하다.

VPC 내부에 대해서는 자동으로 라우팅이 생성되기 때문에 별다른 설정 없이 한 subnet에서 다른 subnet으로 통신이 가능하다. 이는 보이지 않는 암시적 라우터인 vpc router를 통해 가능하게 되는 것이다. subnet으로 리소스를 보낼 때 이 vpc router를 거쳐야 한다.

AWS에서의 라우팅 테이블은 subnet이 라우터를 통해 보내는 네트워크 트래픽이 전달되는 위치를 제어하는 역할을 한다. 귐게 말해 라우팅에 대한 하나의 규칙을 정의하는 것이다.

Internet Gateway

VPC와 인터넷이 통신할 수 있도록 도와주는 VPC 컴포넌트

단순히 인터넷과의 통로 역할을 할 뿐 아니라 NAT의 역할도 수행한다.

인터넷 게이트웨이는 VPC 리소스와 인터넷 간 통신을 활성화하기 위해 VPC에 연결하는 게이트웨이이다. 앞서 설명했듯 public subnet만 외부와 통신해야 하므로 public subnet의 라우팅 테이블에만 인터넷 게이트웨이로 향하는 규칙을 포함한다. 아래 그림과 같이 라우팅 규칙을 설정하면 네트워크 요청 발생 시 목적지의 IP 주소가 10.0.0.0/16(VPC 내부)에 해당하는지 확인한다. 해당하지 않는 모든 트래픽은 인터넷 게이트웨이를 통해 외부로 전송되어 목적지를 찾는다.

NAT Gateway

public subnet만 인터넷 게이트웨이를 통해 외부와 트래픽을 주고받을 수 있다면 private subnet의 트래픽은 무조건 VPC 안에서만 처리된다는 뜻일까?

그렇지 않다. private subent 역시 마찬가지로 인터넷과 통신할 수 있다. 하지만 private subnet에서 직접하는 것은 불가능하므로 트래픽을 public subnet에 속한 인스턴스에 전송해서 인터넷과 통신을 해야 한다.

NAT 게이트웨이가 이 역할을 수행한다. private subent에서 발생하는 네트워크 요청이 VPC 내부의 주소를 목적지로 하는 것이 아니라면 public subnet에 존재하는 NAT로 트래픽을 전송한다. 트래픽을 받은 NAT는 public subnet의 라우팅 규칙에 따라 처리함으로써 private subnet이 인터넷과 통신할 수 있도록 한다.

VPC EndPoint (private Link, VPC 엔드 포인트)

VPC 엔드포인트는 인터넷 게이트웨이나 NAT 게이트웨이와 같은 다른 게이트웨이 없이 AWS 서비스와 연결하여 통신할 수 있는 private connection을 제공하는 서비스이다. Private link를 통해 AWS 서비스와 연결함으로써 데이터를 인터넷에 노출하지 않고 바로 접근할 수 있다.

또한 연결하는 서비스의 IP 주소를 바꾸는 등 네트워크 정보의 변경 등의 작업에서 불필요하게 발생하는 비용을 줄일 수 있다.

코드형 인프라 IaC

수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말함

IaC를 사용하면 인프라 사양을 담은 구성 파일이 생성되므로 구성을 편집하고 배포하기 더 쉬워진다. 또한 IaC는 매번 동일한 환경을 프로비저닝하도록 보장한다.

IaC는 구성 사양을 코드화하고 문서화 함으로써 구성 관리를 지원하며, 따라서 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있다.

버전 제어는 IaC의 가장 중요한 부분이고다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요하다.

코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다는 뜻이기도 하다.

IaC로 인프라 프로비저닝을 자동화하면 애플리케이션을 개발하거나 배포할 때 마다 개발자가 직접 서버, 운영 체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없어진다.

인프라를 코드화하여 템플릿을 만들고 프로비저닝할 때 이 템플릿을 사용하면 된다. 이러한 작업은 수동으로 진행할 수 도 있고 자동화 툴을 사용할 수 도 있다.

reference.

link

기본적으로 프라이빗 클라우드, 퍼블릭 클라우드, 하이브리드 클라우드, 멀티클라우드로 4가지의 유형으로 나눌 수 있다.

퍼블릭 클라우드

일반적으로 최종 사용자가 소유하지 않은 IT 인프라에서 생성되는 클라우드 환경

전통적으로 오프프레미스에서 구동되었지만, 오늘날 퍼블릭 클라우드 제공업체는 클라이언트의 온프레미스 데이터 센터에서 클라우드 서비스를 구동하기 시작했다. 이로 인해 위치와 소유권을 통한 구분은 사라지게 되었다.

환경이 멀티플 테넌트로 파티셔닝 또는 재배포되는 클라우드를 모두 퍼블릭 클라우드라고 볼 수 있다.

멀티 테넌시는 단일 소프트웨어 인스턴스로 서로 다른 여러 사용자 그룹에 서비스를 제공할 수 있는 소프트웨어 아키텍처로 SaaS 제품이 그 예이다.

서로 다른 고객이 서버 리소스를 나누어 사용하는 공유 호스팅을 멀티 테넌시라고 부르기도 한다.

반대의 의미인 단일 테넌시에서는 소프트웨어 인스턴스 또는 컴퓨터 시스템 하나에 최종 사용자 또는 사용자 그룹이 하나만 있다.

• 대표적인 퍼블릭 클라우드 제공업체
  • AWS
  • Google Cloud
  • Microsoft Azure
  • etc

프라이빗 클라우드

단일 최종 사용자 또는 그룹의 전용 클라우드 환경으로, 실행 시 대개 해당 사용자 또는 그룹의 방화벽으로 보호된다.

완전히 독립적인 액세스 권한이 있는 단일 고객만 기반 IT 인프라를 독점적으로 사용하는 경우 이러한 모든 클라우드를 프라이빗 클라우드라고 정의할 수 있다.

그러나 이제는 프라이빗 클라우드라고 해서 온프레미스 IT 인프라에서만 구동할 수 있는 것은 아니다. 또 오프 프레미스에 위치한 벤더 소유의 임대한 데이터 센터에 프라이빗 클라우드를 구축하는 조직도 있기 때문에 위치와 소유권은 더이상 차별화 요소가 아니다.

이로 인해 프라이빗 클라우드의 하위 유형도 여러 가지가 생겨났다.

• 관리형 프라이빗 클라우드

고객은 타사 공급 업체가 배포, 설정 및 관리하는 프라이빗 클라우드를 구축하고 사용

관리형 프라이빗 클라우드는 IT 팀의 인력이나 기술이 부족한 경우 보다 나은 프라이빗 클라우드 서비스와 인프라를 제공할 수 있도록 기업을 지원하는 클라우드 제공옵션이다.

• 전용 클라우드

다른 클라우드 내에 있는 클라우드

퍼블릭 클라우드 또는 프라이빗 클라우드에 전용 클라우드를 구축할 수 있다.

예를 들어, 회계 부서에서는 조직의 프라이빗 클라우드 내에 전용 클라우드를 보유할 수 있다.

하이브리드 클라우드

단일 IT 환경 처럼 보이지만, 실제로는 여러 환경이 LAN, WAN, VPN 및/또는 API를 통해 연결된 형태다.

하이브리드 클라우드는 복잡하고 어떤 상황인지에 따라 요건 또한 다르다.

예를 들어 하이브리드 클라우드에는 다음이 포함될 수 있다.

• 1개 이상의 프라이빗 클라우드와 1개 이상의 퍼블릭 클라우드
• 2개 이상의 프라이빗 클라우드
• 2개 이상의 퍼블릭 클라우드
• 1개 이상의 퍼블릭 클라우드 또는 프라이빗 클라우드에 연결되는 베어메탈 또는 가상 환경

애플리케이션을 개별적이지만 연결되어있는 다중 환경 내외로 이동할 수 있는 경우 하이브리드 클라우드라고 볼 수 있으며, 사실상 거의 모든 IT 시스템이 이러한 추세다.

적어도 이러한 환경 중 일부는 온디맨드로 확장할 수 있는 통합 IT 리소스에서 제공되어야 하고, 모든 환경이 통합 관리 및 오케스트레이션 플랫폼을 사용해 단일 환경처럼 관리되어야 한다.

멀티클라우드

2곳 이상의 클라우드 공급업체가 제공하는 2개 이상의 퍼블릭 또는 프라이빗 클라우드로 구성된 클라우드 접근 방식

모든 하이브리드 클라우드는 멀티 클라우드이지만, 모든 멀티클라우드가 하이브리드 클라우드인 것은 아니다.

멀티 클라우드가 어떤 형태로든 통합 또는 오케스트레이션되어 연결되면 하이브리드 클라우드가 된다.

명확한 목적, 즉 중요 데이터를 더 효과적으로 제어하기 위해 또는 더 강력한 재해 복구를 위한 이중 스토리지 공간으로서 멀티클라우드 환경을 구축하거나 우연히 멀티 클라우드의 형태가 될 수 도 있다. 어느 쪽이든 확장된 환경 포트폴리오를 통해 보안과 성능을 강화하려는 기업들 사이에서 멀티 클라우드가 보편화되고 있다.

자바는 OS에 독립적인 특징을 가지고 있다.
JVM이 OS와 프로그램의 사이에서 기계어로 행석앻주는 역할을 하기 때문이다.

JVM JAVA Virtual Machine

컴파일된 바이트 코드를 기계가 이해할 수 있는 기계어로 변환

스택기반의 가상 머신 

메모리 관리와 GC를 수행

자바 코드의 실행 과정

1. 개발자가 자바코드를 작성한다. 

2. ( .java ) 인 파일을 자바 컴파일러를 통해 자바 바이트 코드로 컴파일한다.

3. 컴파일 된 바이트 코드를 JVM의 Class Loader에 전달한다. 

4. Class Loader는 동적 로딩을 통해 필요 클래스들을 로딩 및 링크하여 Runtime Data Area에 올린다. (JVM의 메모리)

5. 실행 엔진은 JVM메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다.

JVM
Class Loader + Runtime Data Areas + Execution Engine

Class Loader 특징

1. 계층 구조 

클래스 로더는 여러 클래스 로더끼리 부모-자식 관계를 이루어 계층적인 구조로 되어 있다.

• 부트스트랩 클래스 로더 Bootstrap Class Loader
  • 최상위 클래스로더, 유일하게 JAVA가 아닌 네이티브 코드로 구현
  • JVM이 실행될 때 같이 메모리에 올라감
  • Object 클래스를 비롯하여 JAVA API들을 로드함

• 익스텐션 클래스 로더 Extension Class Loader
  • 기본 JAVA API를 제외한 확장 클래스들을 로드함 - 다양한 보안 확장 기능 로드

• 시스템 클래스 로더 System Class Loader
  • (부트 스트랩과 익스텐션 클래스로더가 JVM 자체의 구성 요소들을 로드한다) 시스템 클래스 로더는 어플리케이션의 클래스들을 로드함
  • 사용자가 지정한 $CLASSPATH 내의 클래스들을 로드함

• 사용자 정의 클래스 로더 User-Defined Class Loader
  • 어플리케이션 사용자가 직접 코드 상에서 생성하여 사용하는 클래스 로더
  • WAS와 같은 프레임워크는 서로 독립적으로 동작하게 하기 위해서 이를 위해 사용자 정의 클래스 로더들을 사용하여 클래스 로더의 위임 모델을 통해 어플리케이션의 독립성을 보장함

2. 위임모델 

처음 바이트 코드를 넘겨받은 클래스로더.

필요한 클래스를 로드할 때 혹은 실행 엔진에서 명령어 단위로 바이트 코드를 실행하다가 처음으로 참조하는 클래스에 대해 클래스 로더에게 로드를 요청할 때.

로드를 요청받은 클래스 로더는 다음 순서대로 요청받은 클래스가 있는지 확인함

1. 클래스 로더 캐시
2. 상위 클래스 로더
3. 자기 자신

이전에 로드된 클래스인지 클래스 로더 캐시를 확인한다.

없다면 상위 클래스 로더를 하나씩 거슬러 올라가며 확인하는데, 이 때 올라가는 도중에 클래스를 발견하더라도 부트 스트랩 클래스 로더(최상단 로더)까지 확인을 해서 부트 스트랩 클래스 로더에도 해당 클래스가 존재한다면 그 클래스를 로드하게 된다.

3. 가시성 제한

클래스 로더가 클래스 로드를 요청받았을 때 위임 모델에 의해서 클래스 로더 캐시를 확인하고 없으면 상위 클래스 로더를 확인한다. 이때 하위 클래스는 확인이 불가능한 특성이 바로 가시성 제한이다.

4. 언로드 불가

클래스를 로드하는 것은 가능하지만 그 반대로 unload하는 것은 불가능하다.

5. 이름 공간

네임 스페이스는 각 클래스 로더들이 가지고 있는 공간으로 로드된 클래스를 보관하는 공간

위임 모델을 통해서 상위 클래스 로더들을 확인해야할 때 확인하는 공간이 바로 이름 공간

네임 스페이스에 보관되는 기준은 FQCN Fully Qualified Class Name 으로 패키지 명까지 포함되어있는 식별자를 뜻한다.

각각의 클래스 로더가 각자 네임 스페이스를 가지고 있기 때문에 FQCN이 같은 클래스라도 네임스페이스가 다르면 다른 클래스로 갖주한다. ( 이 기능을 통해 로드한 클래스 로더를 제거하고 언로드의 효과를 줄 수 있다. )

클래스 로드 과정 

1. 로드 - 클래스 파일을 가져와서 JVM의 메모리에 로드한다.

2. 검증 - 클래스 로드 전 과정 중에서 가장 복잡하고 시간이 많이 걸리는 과정으로, 읽어들인 클래스가 자바 언어 명세 및 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.

3. 준비 - 클래스가 필요로 하는 메모리를 할당한다. 

4. 분석 - 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다.

5. 초기화 - 클래스 변수들을 적절한 값으로 초기화한다. (static 필드들은 설정된 값으로 초기화 )

런타임 데이터 영역 Runtime Data Area

JVM이 OS 위에서 실행되면서 할당받는 메모리 영역이 바로 런타임 데이터 영역이다.

이 영역은 크게 5가지, 세분화시 6가지로 나눠 볼 수 있다. 

PC 레지스터, JVM 스택, 네이티브 메서드 스택은 스레드마다 하나씩 생성되고 

힙, 메서드 영역은 모든 스레드가 공유해서 사용된다.

• PC 레지스터 
  • Program Counter 레지스터는 현재 수행 중인 명령의 주소를 가지며 스레드가 시작될 때 생성되며, 각 스레드마다 하나씩 존재함
• JVM 스택 
  • 스택 프레임이라는 구조체를 저장하는 스택
  • 예외 발생 시 printStackTrace( ) 메서드로 보여주는 Stack Trace의 각 라인 하나가 스택 프레임을 표현함
  • 스레드가 시작될 때 생성되며 각 스레드마다 하나씩 존재함
• 네이티브 메서드 스택
  • 자바 외의 언어로 작성된 네이티브 코드를 위한 스택
  • JAVA Native Interface를 통해 호출하는 C/C++ 등의 코드를 수행하기 위한 스택으로, 언어에 맞게 스택 생성
• 힙
  • 인스턴스 또는 객체를 저장하는 공간
  • Garbage Collection의 대상
  • JVM 성능 등의 이슈에서 가장 많이 언급되는 공간
  • 힙 구성 방식이나 가비지 컬렉션 방법 등은 JVM 벤더들의 재량
• 메서드 영역 
  • 모든 스레드가 공유하는 영역
  • JVM이 시작될 때 생성된다.
  • JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메서드에 대한 정보, static 변수, 메서드의 바이트 코드들을 보관함
• 런타임 상수 풀
  • JVM 동작에서 가장 핵심적인 역할을 수행하는 곳
  • 각 클래스와 인터페이스의 상수 뿐만 아니라, 메서드와 필드에 대한 모든 레퍼런스까지 담고 있는 테이블
  • 어떤 메서드나 필드를 참조할 때 JVM은 런타임 상수 풀을 통해 해당 메서드나 필드의 실제 메모리상 주소를 찾아서 참조한다.

실행 엔진 Execution Engine

실행 엔진은 클래스 로더를 통해 런타임 데이터 영역에 배치된 바이트 코드를 명령어 단위로 읽어서 실행

바이트 코드와 각 명령어는 1바이트 크기의 OpCode와 추가 피연산자로 이뤄져있음

실행 엔진은 하나의 OpCode를 가져와서 피연산자와 작업을 수행한 다음 OpCode를 수행하는 식으로 동작한다.

이 수행 과정에서 실행 엔진은 바이트 코드를 기계가 실행할 수 있는 형태로 변경한는데 두가지 방법을 사용한다.

• 인터프리터 
  • 바이트 코드 명령어를 하나씩 읽어서 해석하고 실행한다. 하나하나의 해석은 빠르지만 전체적인 실행 속도는 느리다는 단점을 가진다. 
  • JVM 안에서 바이트 코드는 기본적으로 인터프리터 방식으로 동작한다.
• JIT 컴파일러 Just-In-Time
  • 인터프리터의 단점을 보완하기 위해 도입된 방식
  • 바이트 코드 전체를 컴파일하여 네이티브 코드로 변경하고, 이후에는 해당 메서드를 더이상 인터프리팅 하지 않고 네이티브 코드로 직접 실행하는 방식
  • 전체적인 실행 속도는 인터프리팅방식보다 빠르다 ( 네이티브 코드는 캐시에 보관하기 때문에 한 번 컴파일된 코드는 캐시에서 바로 꺼내어 실행해 빠르게 수행된다 )
  • 하지만 JIT 컴파일러가 컴파일하는 과정은 바이트 코드를 하나씩 인터프리팅 하는 것보다 훨씬 오래 걸리기 때문에 JVM은 해당 메서드가 얼마나 자주 호출되고 실행되는 지를 체크하고, 일정 기준을 넘었을 때만 JIT 컴파일러를 통해 컴파일 하여 네이티브 코드를 생성한다.

참조

• https://steady-snail.tistory.com/67   
• https://github.com/gyoogle/tech-interview-for-developer/blob/master/Language/%5Bjava%5D%20%EC%9E%90%EB%B0%94%20%EC%BB%B4%ED%8C%8C%EC%9D%BC%20%EA%B3%BC%EC%A0%95.md

SQL Injection

웹 사이트의 보안상 허점을 이용해 특정 SQL 쿼리문을 전송하여
공격자가 원하는 데이터베이스의 중요한 정보를 가져오는 해킹 기법이다.

대부분 클라이언트가 입력한 데이터를 제대로 필터링하지 못하는 경우에 발생한다.

공격이 쉬운 난이도에 비해 피해가 상당하기 때문에
보안 위협 1순위로 불릴만큼 중요한 기법이다.

간략한 공격 시나리오

예를 들어 회원이 자신의 일련번호를 조회할 수 있는 상황이 있다고 가정하자.

기본적인 SQL 진행은 클라이언트가 일련번호 조회를 클릭하여 웹서버에 이름이 들어가고 DB에 입력한 값이 있는지 확인 후 존재한다면 번호 DB를 출력해준다.

예를 들어 번호 조회를 클릭하면 url이 http://numbersearch.com/mysearch?=ohyaelim 이 된다고 가정하자.

그럼 공격자의 조회는 http://numbersearch.com/mysearch?=blackhat  에서 탈취하고 싶은 정보의 유저인 ohyaelim으로 변경해줘야하는데, 그냥 변경하는 것으로는 현재 로그인 된 자신과는 다르기 때문에 웹서버에서 인정하지 않는다. 

그러므로 특정 쿼리문을 넣어준다. 'ohyaelim' or '1' = '1' 과 같이 넣어부념 1과 1은 같다라는 구문이 참이므로 결과를 출력해준다.

이러한 SQL Injection의 공격 범위는 매우 다양하다.

bypass
data access
content change
db delete

공격 종류 및 방법

Error based SQL Injection

- 논리적 에러를 이용한 SQL Injection

SQL 공격 기법은 여러가지가 있는데 논리적 에러를 이용한 SQL Injection은 가장 많이 쓰이고 대중적인 공격 기법이다.

앞서 살펴봤던 공격 시나리오가 여기에 해당된다. 

select * from client where name='ohyaelim' and password='1122'

가 올바른 로그인의 예라면 

select * from client where name='ohyaelim' and password=' or '1'='1

와 같이 작성해 or 앞의 값과 뒤에 값 중 하나라도 참이면 참이므로 이 구문 자체가 참으로 인식되어 로그인에 성공하게 된다.

UNION based SQL Injection = UNION

- 명령어를 이용한 SQL Injection

SQL UNION이란, 여러개의 SQL문을 합쳐 하나의 SQL문으로 만들어주는 방법이다. 
쿼리를 날리기에 앞서 사전 조건이 필요하다. Union 하는 두 테이블의 컬럼 수가 같아야 하고 데이터 형이 같아야 한다.

UNION과 UNION ALL로 나뉘는데 중복 값을 제외 하고 안하고의 차이다. 

UNION - 중복 값을 제외한다.

UNION ALL - 중복 값을 제외하지 않고 전체를 합친다.

입력값을 title 과 contents 컬럼의 데이터랑 비교한 뒤 비슷한 글자가 있는 게시글을 출력한다.

여기서 입력값으로 Union 키워드와 함께 컬럼 수를 맞춰서 SELECT 구문을 넣어주게 되면 두 쿼리문이 합쳐서서 하나의 테이블로 보여지게 된다.

현재 인젝션 한 구문은 사용자의 id와 passwd를 요청하는 쿼리문으로 인젝션이 성공하게 되면, 사용자의 개인정보가 게시글과 함께 화면에 보여지게 된다.

( * 물론 패스워드를 평문으로 데이터베이스에 저장하지는 않겠지만 인젝션이 가능하다는 점에서 이미 그 이상의 보안위험에 노출되어 있습니다. 이 공격도 역시 입력값에 대한 검증이 없기 때문에 발생하게 되었다. )

Blind SQL Injection 

- Boolean based Blind SQL Injection

Blind SQL Injection은 데이터베이스로부터 특정한 값이나 데이터를 전달받지 않고, 단순히 참과 거짓의 정보만 알 수 있을 때 사용한다. 로그인 폼에 SQL Injection이 가능하다고 가정 했을 때, 서버가 응답하는 로그인 성공과 로그인 실패 메시지를 이용하여, DB의 테이블 정보 등을 추출해 낼 수 있다.

위 사진과 같은 예시를 살펴보면 limit 키워드를 통해 하나의 테이블만 조회하고, SUBSTR 함수로 첫 글자만, 그리고 마지막으로 ASCII 를 통해서 ascii 값으로 변환해준다. 만약에 조회되는 테이블 명이 Users 라면 ‘U’ 자가 ascii 값으로 조회가 될 것이고, 뒤의 100 이라는 숫자 값과 비교를 하게 된다. 거짓이면 로그인 실패가 될 것이고, 참이 될 때까지 뒤의 100이라는 숫자를 변경해 가면서 비교를 하면 된다.  공격자는 이 프로세스를 자동화 스크립트를 통하여 단기간 내에 테이블 명을 알아 낼 수 있다.

한글자씩 끊어온 값을 아스키코드로 변환시키고 임의의 숫자와 비교하여 참과 거짓을 비교하는 과정을 거쳐가며 계속 질의를 보내어 일치하는 아스키코드를 찾아내는데 이러한 과정을 반복하여 결과들을 조합하여 원하는 정보를 얻어냄으로써 공격을 이루어지게 한다. 많은 비교 과정을 요하므로 악의적 목적을 가진 크래커들은 자동화된 툴을 사용하여 공격한다. 

Blind SQL Injection

- Time based SQL

Time Based SQL Injection 도 마찬가지로 서버로부터 특정한 응답 대신에 참 혹은 거짓의 응답을 통해서 데이터베이스의 정보를 유추하는 기법이다. 사용되는 함수는 MySQL 기준으로 SLEEP 과 BENCHMARK 이다.

위의 그림의 예시에서 로그인 폼에 주입이 되었으며 임의로 abc123 이라는 계정을 생성해 두었는데 악의적인 사용자가 abc123’ OR (LENGTH(DATABASE())=1 AND SLEEP(2)) – 이라는 구문을 주입한 상황이다. 

 주입된 구문에서, LENGTH(DATABASE()) = 1 가 참이면 SLEEP(2) 가 동작하고, 거짓이면 동작하지 않는다. 이를 통해서 숫자 1 부분을 조작하여 데이터베이스의 길이를 알아 낼 수 있다. 만약에 SLEEP 이라는 단어가 치환처리 되어있다면, 또 다른 방법으로 BENCHMARK 나 WAIT 함수를 사용 할 수 있다. 

BENCHMARK 는
BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye'));
이런 식으로 사용하고 이 구문을 실행 하면 약 4.74초가 걸린다. 

Stored Procedure SQL Injection

- 저장된 프로시저에서의 SQL Injection

stored procedure는 일련의 쿼리들을 모아 하나의 함수처럼 사용하기 위한것이다.

공격에 사용되는 대표적인 저장 프로시저는 MS-SQL 에 있는 xp_cmdshell로 윈도우 명령어를 사용할 수 있게 된다. 단, 공격자가 시스템 권한을 획득 해야 하므로 공격난이도가 높으나 공격에 성공한다면, 서버에 직접적인 피해를 입힐 수 있는 공격이다.

Mass SQL Injection

- 다량의 SQL Injection 공격

 2008년에 처음 발견된 공격기법이다.

기존 SQL Injection 과 달리 한번의 공격으로 다량의 데이터베이스가 조작되어 큰 피해를 입히는 것을 의미한다. 보통 MS-SQL을 사용하는 ASP 기반 웹 애플리케이션에서 많이 사용되며, 쿼리문은 HEX 인코딩 방식으로 인코딩 하여 공격한다. 보통 데이터베이스 값을 변조하여 데이터베이스에 악성스크립트를 삽입하고, 사용자들이 변조된 사이트에 접속 시 좀비PC로 감염되게 하는데 이렇게 감염된 좀비 PC들은 DDoS 공격에 사용됩니다.

대응방안

• 입력 값에 대한 검증 
• Prepared Statement 구문 사용
• Error Message 노출 금지
• 웹 방화벽 사용

입력 값에 대한 검증

SQL Injection 에서 사용되는 기법과 키워드는 엄청나게 많습니다. 사용자의 입력 값에 대한 검증이 필요하다. 서버 단에서 화이트리스트 기반으로 검증해야 한다. 블랙리스트 기반으로 검증하게 되면 수많은 차단리스트를 등록해야 하고, 하나라도 빠지면 공격에 성공하게 되기 때문이다. 공백으로 치환하는 방법도 많이 쓰이는데, 이 방법도 취약한 방법이다. 예를 들어 공격자가 SESELECTLECT 라고 입력 시 중간의 SELECT가 공백으로 치환이 되면 SELECT 라는 키워드가 완성되게 된다. 공백 대신 공격 키워드와는 의미 없는 단어로 치환되어야 한다.

Prepared Statement 구문사용

 Prepared Statement 구문을 사용하게 되면, 사용자의 입력 값이 데이터베이스의 파라미터로 들어가기 전에DBMS가 미리 컴파일 하여 실행하지 않고 대기하는데 그 후 사용자의 입력 값을 문자열로 인식하게 하여 공격쿼리가 들어간다고 하더라도, 사용자의 입력은 이미 의미 없는 단순 문자열 이기 때문에 전체 쿼리문도 공격자의 의도대로 작동하지 않는다.

Error Message 노출 금지

공격자가 SQL Injection을 수행하기 위해서는 데이터베이스의 정보(테이블명, 컬럼명 등)가 필요하다. 데이터베이스 에러 발생 시 따로 처리를 해주지 않았다면, 에러가 발생한 쿼리문과 함께 에러에 관한 내용을 반환헤 주는데 여기서 테이블명 및 컬럼명 그리고 쿼리문이 노출이 될 수 있기 때문에, 데이터 베이스에 대한 오류발생 시 사용자에게 보여줄 수 있는 페이지를 제작 혹은 메시지박스를 띄우도록 하여야 한다.

웹 방화벽 사용

웹 공격 방어에 특화되어있는 웹 방화벽을 사용하는 것도 하나의 방법. 웹 방화벽은 소프트웨어 형, 하드웨어 형, 프록시 형 이렇게 세가지 종류로 나눌 수 있는데 소프트웨어 형은 서버 내에 직접 설치하는 방법이고, 하드웨어 형은 네트워크 상에서 서버 앞 단에 직접 하드웨어 장비로 구성하는 것이며 마지막으로 프록시 형은 DNS 서버 주소를 웹 방화벽으로 바꾸고 서버로 가는 트래픽이 웹 방화벽을 먼저 거치도록 하는 방법이다.

참고

link1 link2

NoSQL이란?

일명 "SQL만을 사용하지 않는 데이터베이스"
표 형식이 아니며, 관계형 테이블과는 다른 방식으로 데이터를 저장

NoSQL은 Not Only SQL의 약자로 기존 RDBMs 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미하며, 관계형 데이터 베이스의 한계를 극복하기 위한 데이터 저장소의 새로운 형태로, 수평적 확장성을 갖고 있다. 문서, 그래프, 키 값, 인 메모리, 검색을 포함해 다양한 데이터 모델을 사용한다. RDBMS가 클라이언트/서버 환경에 맞는 데이터 저장기술이라면, NoSQL은 클라우드 환경에 맞는 저장 기술이다.

NoSQL 데이터베이스를 사용해야하는 이유

NoSQL 데이터베이스는 탁월한 사용자 경험을 제공하기 위하여 유연성과 확장성을 비롯해 고성능의 매우 기능적인 데이터베이스를 필요로 하는 모바일, 웹이나 게이밍과 같은 다양한 현대적인 애플리케이션에 적합하다.

• 유연성: NoSQL 데이터베이스는 일반적으로 유연한 스키마를 제공하여, 보다 빠르고 반복적인 개발을 가능하게 해준다. 이 같은 유연한 데이터 모델은 NoSQL 데이터베이스를 반정형 및 데이터에 이상적으로 만들어준다.
• 확장성: NoSQL 데이터베이스는 일반적으로 고가의 강력한 서버를 추가하는 대신 분산형 하드웨어 클러스터를 이용해 확장하도록 설계되었다. 일부 클라우드 제공자들은 완전 관리형 서비스로서 이런 운영 작업을 보이지 않게 처리한다.
• 고성능: NoSQL 데이터베이스는 특정 데이터 모델(문서, 키 값, 그래프 등) 및 엑세스 패턴에 대해 최적화되어 관계형 데이터베이스를 통해 유사한 기능을 충족하려 할 때보다 뛰어난 성능을 얻게 해준다.
• 고기능성: NoSQL 데이터베이스는 각 데이터 모델에 맞추어 특별히 구축된 뛰어난 기능의 API와 데이터 유형을 제공한다.

SQL 장점
명확하게 정의된 스키마, 데이터 무결성 보장관계는 각 데이터를 중복없이 한번만 저장
SQL 단점
덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음대체로 수직적 확장만 가능함


NoSQL 장점
스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능
NoSQL 단점
유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음데이터 중복을 계속 업데이트 해야 함데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)

NoSQL의 특징

1. NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않는다.
   • 가장 큰 특징 중 하나는 관계형 데이터 베이스인 RDBMS가 데이터의 관계를 Foreign Key 등으로 정의하고 이를 이용해 Join 등의 관계형 연산을 한다고 하면, NoSQL은 데이터 간의 관계를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며 각 테이블 간의 관계를 정의하지 않고 일반적으로 테이블 간의 Join도 불가능하다.
2. RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다.
   • RDBMS의 복잡도와 용량의 한계를 극복하기 위한 목적으로 등장한 만큼 페타바이트급의 대용량 데이터를 저장할 수 있다.
3. 분산형 구조이다.
   • NoSQL은 기존 RDBMS와는 다르게 하나의 고성능 머신에 데이터를 저장하는 것이 아니라 일반적인 서버 수십 대를 연결해 데이터를 저장 및 처리하는 구조를 갖는다. 즉 분산형 구조를 통해 데이터를 여러 대의 서버에 분산해 저장하고 분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생했을 때에도 데이터 유실이나 서비스 중지가 없는 구조의 형태를 가진다.
4. 고정되지 않은 테이블 스키마를 갖는다.
   • RDBMS와는 다르게 테이블의 스키마가 유동적이다. 데이터를 저장하는 컬럼은 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용된다.
   • 스키마란? 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합이다.

CAP 이론

1. 일관성(Consistency)

일관성은 동시성 또는 동일성이라고도 하며 다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증하는 것을 의미한다. 이것은 관계형 데이터베이스가 지원하는 가장 기본적인 기능이지만 일관성을 지원하지 않는 NoSQL 을 사용한다면 데이터의 일관성이 느슨하게 처리되어 동일한 데이터가 나타나지 않을 수 있다. 느슨하게 처리된다는 것은 데이터의 변경을 시간의 흐름에 따라 여러 노드에 전파하는 것을 말한다. 이러한 방법을 최종적으로 일관성이 유지된다고 하여 최종 일관성 또는 궁극적 일관성을 지원한다고 한다.

각 NoSQL 들은 분산 노드 간의 데이터 동기화를 위해서 두 가지 방법을 사용한다. 첫번째로 데이터의 저장 결과를 클라이언트로 응답하기 전에 모든 노드에 데이터를 저장하는 동기식 방법이 있다. 그만큼 느린 응답시간을 보이지만 데이터의 정합성을 보장한다. 두번째로 메모리나 임시 파일에 기록하고 클라이언트에 먼저 응답한 다음, 특정 이벤트 또는 프로세스를 사용하여 노드로 데이터를 동기화하는 비동기식 방법이 있다. 빠른 응답시간을 보인다는 장점이 있지만, 쓰기 노드에 장애가 발생하였을 경우 데이터가 손실될 수 있다.

2. 가용성(Availability)

가용성이란 모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능해야 함을 보증하는 것이며 내고장성이라고도 한다. 내고장성을 가진 NoSQL 은 클러스터 내에서 몇 개의 노드가 망가지더라도 정상적인 서비스가 가능하다.

몇몇 NoSQL 은 가용성을 보장하기 위해 데이터 복제(Replication)을 사용한다. 동일한 데이터를 다중 노드에 중복 저장하여 그 중 몇 대의 노드가 고장나도 데이터가 유실되지 않도록 하는 방법이다. 데이터 중복 저장 방법에는 동일한 데이터를 가진 저장소를 하나 더 생성하는 Master-Slave 복제 방법과 데이터 단위로 중복 저장하는 Peer-to-Peer 복제 방법이 있다.

3. 네트워크 분할 허용성(Partition tolerance)

분할 허용성이란 지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템은 정상적으로 동작해야 함을 의미한다.

NoSQL의 종류

• Key-Value DB
  • Key와 Value의 쌍으로 데이터가 저장되는 유형으로써 Amazon의 Dynamo Paper에서 유래되었다. Riak, Vodemort, Tokyo 등의 제품이 알려져 있다.

가장 기본적인 형태의 NoSQL 이며 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키-값 구조를 갖는다. 단순한 저장구조로 인하여 복잡한 조회 연산을 지원하지 않는다. 또한 고속 읽기와 쓰기에 최적화된 경우가 많다. 사용자의 프로필 정보, 웹 서버 클러스터를 위한 세션 정보, 장바구니 정보, URL 단축 정보 저장 등에 사용한다. 하나의 서비스 요청에 다수의 데이터 조회 및 수정 연산이 발생하면 트랜잭션 처리가 불가능하여 데이터 정합성을 보장할 수 없다. 
ex) Redis

• Wide Column DB
  • Big Table DB라고도 하며, Google의 BigTable Paper에서 유래되었다. Column Family 데이터 모델을 사용하고 있고, HBase, Cassandra, Hypertable이 이에 해당된다.

하나의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이루어진 데이터를 저장하고 조회한다. 모든 컬럼은 항상 타임 스탬프 값과 함께 저장된다.
구글의 빅테이블이 대표적인 예로 차후 컬럼형 NoSQL 은 빅테이블의 영향을 받았다. 이러한 이유로 Row key, Column Key, Column Family 같은 빅테이블 개념이 공통적으로 사용된다. 저장의 기본 단위는 컬럼으로 컬럼은 컬럼 이름과 컬럼 값, 타임스탬프로 구성된다. 이러한 컬럼들의 집합이 로우(Row)이며, 로우키(Row key)는 각 로우를 유일하게 식별하는 값이다. 이러한 로우들의 집합은 키 스페이스(Key Space)가 된다.
대부분의 컬럼 모델 NoSQL 은 쓰기와 읽기 중에 쓰기에 더 특화되어 있다. 데이터를 먼저 커밋로그와 메모리에 저장한 후 응답하기 때문에 빠른 응답속도를 제공한다. 그렇기 때문에 읽기 연산 대비 쓰기 연산이 많은 서비스나 빠른 시간 안에 대량의 데이터를 입력하고 조회하는 서비스를 구현할 때 가장 좋은 성능을 보인다. 채팅 내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합하다.

• KDoument DB
  • Lotus Notes에서 유래되었으며, JSON, XML과 같은 Collection 데이터 모델 구조를 채택하고 있다. Mongo DB, Cough DB가 이 종류에 해당된다.

키-값 모델을 개념적으로 확장한 구조로 하나의 키에 하나의 구조화된 문서를 저장하고 조회한다. 논리적인 데이터 저장과 조회 방법이 관계형 데이터베이스와 유사하다. 키는 문서에 대한 ID 로 표현된다. 또한 저장된 문서를 컬렉션으로 관리하며 문서 저장과 동시에 문서 ID 에 대한 인덱스를 생성한다. 문서 ID 에 대한 인덱스를 사용하여 O(1) 시간 안에 문서를 조회할 수 있다.
대부분의 문서 모델 NoSQL 은 B 트리 인덱스를 사용하여 2 차 인덱스를 생성한다. B 트리는 크기가 커지면 커질수록 새로운 데이터를 입력하거나 삭제할 때 성능이 떨어지게 된다. 그렇기 때문에 읽기와 쓰기의 비율이 7:3 정도일 때 가장 좋은 성능을 보인다. 중앙 집중식 로그 저장, 타임라인 저장, 통계 정보 저장 등에 사용된다. ex) MongoDB

• Graph DB
  • Euler & Graph Theory에서 유래한 DB이며, Nodes, Relationship, Key-Value 데이터 모델을 채용하고 있다. Neo4J 등의 제품이 있다.

References.

link1 link2

IPC란?

프로세스는 독립적으로 실행된다.
이처럼 독립적인 공간을 가진 프로세스 간 통신에 사용되는 기법이 IPC 통신이다.
프로세스는 커널이 제공하는 IPC 설비를 이용해 프로세스 간의 통신을 할 수 있게 된다.

• IPC = Inter-Process Communication
• 프로세스들 사이에 서로 데이터를 주고받는 행위

• 위 그림처럼 우리가 사용하는 프로세스들은 모두 유저공간(user-space, user-mode)에서 개별로 OS로부터 할당받은 독립된 공간에서 운행중에 있다
• 말한것 처럼 프로세스는 독립된 공간에서 운행하다보니 서로간에 통신이 어렵다는 문제가 있다
• 이를 해결하고자 커널 영역(kernel-space, kernel-mode)에서 IPC(Inter-Process Communication)라는 프로세스들 간에 통신을 제공하고 있다
• 이처럼 프로세스들은 커널이 제공하는 IPC 기술을 통해 프로세스간에 통신을 할 수 있다

IPC의 종류

PIPE (파이프)

• 파이프는 두 개의 프로세스를 연결하고 하나의 프로세스는 데이터를 쓰기만 하고, 다른 프로세스는 데이터를 읽기만 한다
• 부모 자식 간에 단방향 통신으로 자주 사용한다
• 한쪽 방향으로만 통신이 가능한 PIPE의 특징 때문에 Half-Duplex(반이중) 통신 이라고도 불린다
• PIPE는 반이중 통신이기에 하나의 통신선로는 읽기/쓰기 중 하나만 가능하므로 만약 읽기/쓰기, 즉 송/수신을 모두 하기 원한다면 두 개의 파이프를 만들어야 가능하다
• read()와 write()가 기본적으로 block mode로 작동되기에 프로세스가 read 대기중이라면 read가 끝나기전에는 write를 할 수 없다

장점

• PIPE는 간단하게 사용할 수 있다는 장점이 있다. 한쪽 프로세스는 단지 읽기만하고 다른 프로세스는 단지 쓰기만 하는 단순한 데이터 흐름에 적합

단점

• Full-Duplex(전이중) 통신 방식으로 활용하려면 PIPE를 두개 만들어야 하는데, 구현이 꽤나 복잡해 질 수 있다 (굳이 전이중을 활용해야한다면 PIPE말고 다른 방법을 찾는게 효율적일 수 있다)
• buffer가 상대적으로 작기때문에 overflow 될 확률이 높다 (read처리를 빨리빨리 해줘야한다)
• 부모 자식 관계의 프로세스들 사이에서 가능

Named PIPE (익명 파이프)

• Linux는 모든 것을 파일(fd)로 통하고 있다는 개념을 기억하고 보자
• Named PIPE는 통신을 할 프로세스가 명확히 알 수 있는 경우 사용
• 보통 PIPE는 부모자식간에 사용하고 Named PIPE는 전혀 모르는 상태의 프로세스들 사이에서 통신할 경우 사용
• Named PIPE는 부모프로세스와 무관하게 전혀 다른 모든 프로세스들 사이에서 통신이 가능한데, 이유는 프로세스간에 통신을 위해 이름이 있는 파일을 매개체로 사용하기 때문
• mkfifo를 통해 Named PIPE를 생성하는데, mkfifo가 성공하면 이름이 명명된 파일이 생성되고 이를 활용해서 프로세스 간에 통신이 이루어짐

장점

• 기본 PIPE와 비슷

단점

• 읽기/쓰기가 동시에 이루어지지 않음, 단방향 통신, read-only or write-only
• 기본 PIPE와 비슷

PIPE 와 Named PIPE

공통점
먼저 입력된 데이터가 먼저 전달되는 흐름을 가진다는 측면에서 동일한 데이터 흐름 메커니즘을 가진다

차이점
Named PIPE는 사용할 PIPE를 명명할 수 있다는 점
PIPE는 사용할 PIPE를 명명할 수 없다
(그렇기 때문에 PIPE는 익명 PIPE라 부른다)


추가 설명
익명 파이프(PIPE)는 데이터 통신을 할 프로세스가 명확하게 알 수 있을 때 사용
송신할 프로세스는 수신할 프로세스를 알고, 수신할 프로세스는 송신할 프로세스를 아는 경우
가장 대표적인 예가 부모프로세스와 자식프로세스간에 데이터 통신을 하고자 할 때 부모 프로세스와 자식 프로세스는 서로를 명확히 알고 있으므로 굳이 파이프에 이름을 줄 필요가 없을 것이다

반면, 자식과 부모 관계가 아닌 전혀 모르는 프로세스들 사이에서 pipe를 이용해서 통신을 해야하는 경우는 우리가 생판 모르는 사람과 대화를 하려면 이름을 알아야 하듯 pipe에 이름을 주어져야 한다, 그것이 Named PIPE를 만든 이유이다

Message Queue (메시지 큐)

• FIFO(First-In First-Out, 선입선출) 자료구조를 가지는 통신설비로 커널에서 관리
• 입출력 방식으로보면 위에 Named PIPE와 동일하다 할 수 있다
• 차이점이라면, Named PIPE는 데이터의 흐름이라면 Message Queue는 메모리 공간이라는 점
• 어디서나 물건을 꺼낼 수 있는 컨테이너 벨트와 같다 보면 된다
• Message Queue에 쓸 데이터에 번호를 붙힘으로써 다수의 프로세스가 동ㅇ시에 데이터를 쉽게 다룰 수 있다

장점

• 비동기 방식이기에 방대한 처리량이 있다면 큐에 넣은 후 나중에 처리 할 수 있다
• 다수의 프로세스들이 큐에 메시지를 보낼 수 있고 다수의 프로세스들이 큐로부터 메시지를 꺼낼 수 있다
• 분산처리 및 경쟁처리 방식에 사용할 수 있다
• (비동기, 비동조, 탄력성, 과잉, 확장성이 있는데 이건 다른 포스트 참조해도 충분할 거 같다)

단점

• 메시지가 정말 잘 전달되었는지 알 수 없다
• 큐에 데이터를 넣고 나오는 과정에서 오버헤드가 발생 할 수 있다
• 데이터가 많이 쌓일수록 추가적인 메모리 자원이 필요하다

Shared Memory (공유메모리)

• 데이터 공유 방법에는 크게 2가지가 있는데,

1. 통신을 이용해서 데이터를 주고 받는 방법 (ex. PIPE, Named PIPE, Message Queue, ...)
2. 데이터를 공유, 즉 함께 사용하는 것 (ex. Shared Memory, ...)

• • 즉, 공유메모리가 데이터 자체를 공유하도록 지원하는 설비이다
  • Shared Memory(공유 메모리)는 프로세스간 메모리 영역을 공유해서 사용할 수 있도록 허용
  • 프로세스가 공유 메모리 할당을 커널에 요청하면 커널은 해당 프로세스에 메모리 공간을 할당해 주게되고, 이후 어떤 프로세스건 해당 메모리영역에 접근 할 수 있다
  장점
  • 공유 메모리는 중개자 없이 곧바로 메모리에 접근할 수 있기 때문에 모든 IPC중에서 가장 빠르게 작동한다
  • (다시말해, 커널메모리영역에서 관리하기에 빠르게 접근 가능)
  단점
  • 메시지 전달 방식이 아니기에 데이터를 읽어야하는 시점을 알 수 없다
  • 커널 설정에 종속적이기에 사용하기전에 커널에서 허용하고 있는 공유메모리 사이즈를 확인해야 한다

Semaphore (세마포어)

• PIPE, Named PIPE, Message Queue와 같은 다른 IPC 설비들이 대부분 프로세스간 메시지 전송을 목적으로 하는데 반해,
• Semaphore는 프로세스 간 데이터를 동기화하고 보호하는데 그 목적이 있다
• 프로세스간 메시지 전송을 하거나 공유메모리를 통해 데이터를 공유하게 될 경우 발생하는 문제가 공유된 자원에 다수의 프로세스가 동시에 접근하면 안되며 단지 하나의 프로세스만 접근가능하게 해주는것이 세마포어(Semaphore) 이다
• 즉, 운영 체계 또는 프로그램 작성 내에서 공유 자원에 대한 접속을 제어하기 위해 사용되는 신호
• 한 프로세스가 사용하고 있는 동안에 세마포어를 세워서 다른 프로세스를 대기시키고 사용이 끝나면 해제시키는 방법으로 사용

(한가지 예를 들자면, 화장실에 갔을때 화장실 칸을 생각하면 된다. 화장실 한 칸에 대해 관리를 하는것이 뮤텍스이고 화장실 자체를 관리하는게 세마포어가 된다)

장점

• 많은 Thread들은 크리티컬 섹션을 허락받아야 한다. 즉, 크리티컬 섹션에서 충돌이 나지 않는다

단점

• 많은 Thread들은 block을 당한다. 즉, CPU가 가만히 waiting하는 시간 낭비가 발생할 수 있다

Memory Map (메모리 맵)

메모리 맵도 공유 메모리와 마찬가지로 메모리를 공유한다는 측면에서는 비슷하다

• • 차이점은 메모리 맵은 열린 파일을 메모리에 맵핑시켜서 공유한다는 점
  • 파일(fd)는 리눅스의 시스템의 전역적인 자원이므로 즉, 모두 공유할수 있는 자원이므로 서로 다른 프로세스들끼리 데이터를 공유하는데 문제가 없음을 예상할 수 있다
  장점
  • 데이터가 메모리에 이미 올라와있는 것처럼 간단하게 접근 할 수 있다
  • 일반적인 파일 IO에 비해 나은 성능을 보여준다
  • 비동기 IO를 사용하지만 시스템에서 처리해주기 때문에 스레드 문제를 걱정할 필요 없다
  단점
  • 일반 파일 IO에 비해 상당히 많은 메모리를 요구
  • 많은 데이터를 얼마나 오랫동안 메모리에 둘 것인지 컨트롤할 수 없다

Socket (소켓, UDS = Unix Domain Socket)

• 같은 도메인 내에서 연결 될 수 있고 프로세스들 사이의 통신을 가능하게 한다
• 서버단에서는 bind, listen, accept 진행해 소켓 연결을 위한 준비를 한다
• 클라이언트 단에서는 connect을 통해 서버에 요청하고 연결이 수립 된 후에서는 socket에 send 함으로써 데이터를 주고 받는다.
• 연결이 끝나면 반드시 close()로 clear 한다
• 즉, 네트워크를 통해 프로세스간에 통신을 진행한다

장점

• 서버/클라이언트 환경을 구축하는데 용이하다
• Internet Socket인 경우 데이터 유실이 발생할 수 있지만, Unix Domain소켓은 PIPE와 같은 형태로 이루어지고 같은 시스템에서 교환이 일어나므로 패킷이 유실되거나, 순서가 바뀌는 등 문제가 발생하지 않을거라 장담 할 수 있다
• 범용적인 IPC로써 양방향 통신이 가능하다
• 패킷 단위로 주고 받음으로 직관적으로 이해하기 쉬운 코드를 만들 수 있다

단점

• Internet UDP와는 달리 경로를 지정할 수 없다 (다중의 클라이언트를 받아들이는 서버의 경우 문제가 될 수 있다)

References.

link1 link2

OSI 7계층

표준화를 통해 이질적인 포트 문제나 프로토콜 등으로 인한 문제를 해결하여 비용을 절감했다.
또한, 계층별의 기능과 통신 과정을 단계별로 나누어서 쉽게 알 수 있고, 특정한 곳에 이상이 생기면 그 단계만 수정할 수 있기 때문에 편리하다.

1) 물리(Physical)

리피터, 케이블, 허브 등

주로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하는 역할을 한다.

2) 데이터 링크(Data Link)

브릿지, 스위치 등

물리 계층을 통해 송, 수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 역할을 한다.

MAC 주소를 이용해 통신한다.

Frame에 MAC 주소를 부여하고 에러검출, 재전송, 흐름 제어를 진행한다.

3) 네트워크(Network)

라우터, IP

여러 개의 노드를 거칠 때마다 경로를 찾아주는 역할을 하며, 다양한 길이의 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당한다. (전송 계층이 요구하는 서비스 품질을 제공하기 위한 기능적, 절차적 수단을 제공한다.)

라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달해준다.

라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행한다.

4) 전송 계층(Transport)

TCP, UDP

TCP, UDP 프로토콜을 통해 통신을 활성화 한다. 포트를 열어두고, 프로그램들이 전송을 할 수 있도록 제공해준다. 이를 통해 양 끝 단의 사용자들이 데이터를 주고 받을 수 있다.

• TCP : 신뢰성, 연결 지향적
• UDP : 비신뢰성, 비연결성, 실시간

TCP 프로토콜(Transmission Control Protocol)

OSI 계층모델의 관점에서 전송 계층(4계층)에 해당

양종단 호스트 내 프로세스 상호 간에 신뢰적인 연결지향성 서비스를 제공

- IP의 비신뢰적인 최선형 서비스에다가 신뢰적인 연결지향성 서비스를 제공하게 됨

. 신뢰적인 전송을 보장함으로써, 어플리케이션 구현이 한층 쉬워지게 됨

1. 신뢰성 있음 (Reliable)

패킷 손실, 중복, 순서바뀜 등이 없도록 보장

TCP 하위계층인 IP 계층의 신뢰성 없는 서비스에 대해 다방면으로 신뢰성을 제공

2. 연결지향적 (Connection-oriented)                                        ☞ TCP 연결

같은 전송계층의 UDP가 비연결성(connectionless)인 것과는 달리, TCP는 연결지향적 임

이 경우, 느슨한 연결(Loosly Connected)을 갖으므로 강한 연결을 의미하는 

가상회선이라는 표현 보다는 오히려 연결지향적이라고 말함

연결 관리를 위한 연결설정 및 연결해제 필요          ☞ TCP 연결설정, TCP 연결종료

양단간 어플리케이션/프로세스는 TCP가 제공하는 연결성 회선을 통하여 서로 통신

UDP 프로토콜(User Datagram Protocol)

전송 계층의 통신 프로토콜의 하나 (TCP에 대비됨)

- 신뢰성이 낮은 프로토콜로써 완전성을 보증하지 않으나,  

- 가상회선을 굳이 확립할 필요가 없고 유연하며 효율적 응용의 데이타 전송에 사용

1. 비연결성이고, 신뢰성이 없으며, 순서화되지 않은 Datagram 서비스 제공 

- 메세지가 제대로 도착했는지 확인하지 않음 (확인응답 없음)

- 수신된 메세지의 순서를 맞추지 않음 (순서제어 없음) 

- 흐름 제어를 위한 피드백을 제공하지 않음 (흐름제어 없음)

- 검사합을 제외한 특별한 오류 검출 및 제어 없음 (오류제어 거의 없음)

UDP를 사용하는 프로그램 쪽에서 오류제어 기능을 스스로 갖추어야 함

- 데이터그램 지향의 전송계층용 프로토콜 (논리적인 가상회선 연결이 필요없음)

비연결접속상태 하에서 통신 

2. 실시간 응용 및 멀티캐스팅 가능

- 빠른 요청과 응답이 필요한 실시간 응용에 적합

- 여러 다수 지점에 전송 가능 (1:多)

3. 헤더가 단순함

- UDP는 TCP 처럼 16 비트의 포트 번호를 사용하나,

- 헤더는 고정크기의 8 바이트(TCP는 20 바이트) 만 사용

즉, 헤더 처리에 많은 시간과 노력을 요하지 않음

5)세션(Session)

API, Socket

데이터가 통신하기 위한 논리적인 연결을 말한다. 통신을 하기위한 대문이라고 보면 된다.

하지만 4계층에서도 연결을 맺고 종료할 수 있기 때문에 우리가 어느 계층에서 통신이 끊어 졌나 판단하기는 한계가 있다. 

그러므로 세션 계층은 4 계층과 무관하게 응용 프로그램 관점에서 봐야 한다. 

세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능이 있다.

세션 계층(Session layer)은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다. 

동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex)의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다. 

이 계층은 TCP/IP 세션을 만들고 없애는 책임을 진다.

-> 

통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다룬다. 

통신을 하기 위한 세션을 확립/유지/중단 (운영체제가 해줌)

6) 표현(Presentation)

JPEG, MPEG 등

데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당한다.

코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어준다.

파일 인코딩, 명령어를 포장, 압축, 암호화한다.

7) 응용(Application)

HTTP, FTP, DNS 등

최종 목적지로 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.

사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스를 제공한다.

Git이란?

git은 컴퓨터 파일의 변경 사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 오픈소스 분산 버전 관리 시스템이다.

주로 소프트웨어를 개발하며 코드 관리에도 사용되지만 어떠한 프로젝트의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다. (나는 보통 소스코드 관리와 변경사항 추적을 목적으로 사용하고 있다)

Git-flow란?

Git-flow는 Git이 활성화가 될 2010년 정도에 Vincent Driessen이라는 사람이 만든 Git을 사용한 개발 작업 절차이다. Git-flow라고 해서 프로그램 같지만 프로그램이 아닌 약속, 규칙같은 개념이다.

Vincent Driessen또한 Git-flow는 완벽한 방법론이 아닌, 각자 팀에 맞는 개발 환경에 따라 변형해서 사용하는 것이 좋다고 언급했다.

Git-flow의 브랜치

Git-flow의 브랜치는 다음과 같이 구성되어 있다.

• master 와 devleop브랜치
  • master와 develop브랜치가 존재하고, develop브랜치는 master 브랜치에서 시작된 브랜치.
  Develop브랜치
  • develop브랜치에는 상시로 버그를 수정한 커밋들이  추가되게 된다.
  • 새로운 기능을 추가하는  경우  develope 브랜치에서 시작하는 feature브랜치를 생성
  Feature브랜치
  • 이 feature브랜치는 기능 추가 작업이 완료되었다면, develop 브랜치로 merge 
  • 새로운 기능을 추가하는  경우  develope 브랜치에서 시작하는 feature브랜치를 생성
  release 브랜치
  • develop브랜치에 이번 버전에 포함하는 모든 기능이 merge되었다면 , QA를 위해 develop브랜치에서 release브랜치를 생성
  •  QA를 무사히 통과하게되면 relase브랜치를 master와 develop브랜치로  merge
  • QA를  진행하면서 발생한 버그들은 모두 release브랜치에 수정

master와 develop은 항상 유지되는 메인 브랜치들이며 그 외에 feature, release, hotfixes는 필요한 기간에만 유지되는 보조 브랜치들이다.

다음은 Vincent Driessen의 블로그에서 Git-flow를 설명할때 사용하는 이미지이다.

타임라인을 보면 알겠지만 처음에는 master로 시작해 develop브랜치만 존재한다.

아직 소프트웨어를 배포하지 않았기 때문에 develop브랜치에서 개발을 시작한다.

개발을 진행하다가 추가로 필요한 기능이 생기면 feature브랜치를 생성해 작업을 한다. 

feature브랜치는 언제나 develop브랜치로부터 시작된다.

기능을 다 개발했다면 작업한 feature브랜치를 검토한 후 develop브랜치에 병합한다.

이제 이번 버전에서 필요한 기능이 모두 개발되었다면 QA를 위해 release브랜치를 생성한다.

QA를 진행하며 발견하는 버그들은 모두 이 release브랜치를 통해 fix된다.

이제 QA과정이 모두 끝났다면 release브랜치를 master와 develop브랜치로 병합한다.

그리고 master브랜치에 버전명시를 위한 태그를 생성 후 배포한다.

여기까지가 기본적인 개발 단계에서의 Git-flow이다.

하지만 배포 후에도 버그가 발생하는 경우가 있다.

그렇다면 긴급하게 수정을 해야하는데 그럴 경우 hofixes브랜치를 생성해 발생한 버그를 수정한다.

버그 수정이 완료되었다면 release브랜치가 완료됬을 때와 같이 master와 develop브랜치로 병합 후 버그 수정을 완료했다는 태그를 추가한다.

버전 태그

보통 소프트웨어를 표시할때 버전은 x.x.x의 형태로 이루어진다. 이 숫자들은 무엇을 의미할까? 버전의 가장 첫 번째 숫자는 Major Version을 의미한다. Major Version은 보통 1로 시작해서 소프트웨어 전체적으로 큰 변화가 생겼을때 버전 업을 한다. 두 번째 숫자는 Minor Version을 의미한다. Miner Version은 보통 0으로 시작해서 없던 기능의 추가나 기존 기능의 수정 등의 변화가 발생했을 때 버전 업을 한다. 마지막 세 번째 자리는 Build or Maintenance Version이라고 하며 자잘한 버그나 내부적 코드 보안 등의 변화가 발생했을 때 버전 업을 한다. 이 버전은 0으로 시작하지만 생략하는 경우도 있다.

Reference.

link1 link2

컨테이너 초기화와 종료

스프링 컨테이너는 초기화와 종료라는 라이프 사이클을 갖는다.

• 컨텍스트 객체가 생성되는 시점에 컨테이너를 초기화함
• 스프링 컨테이너는 설정 클래스에서 정보를 읽어와 알맞은 Bean 객체를 생성하고, 각 Bean을 연결(의존 주입)하는 작업 수행
• 초기화가 끝난 후 컨테이너를 사용 가능(getBean()등의 작업으로 Bean 객체를 구하는 행위 등)
• 컨테이너 사용이 끝나면 컨테이너를 close() 매서드를 사용해 종료, Bean 객체의 소멸

 기본적으로 Spring의 ApplicationContext 구현은 초기화 프로세스에서 모든 싱글톤 빈을 생성 및 설정

> 따라서 Bean에 문제가 있을 경우 초기화 단계에서 알 수 있다는 장점이 존재

// 1. 컨테이너 초기화
AnnotationConfigApplicationiContext ctx = 
        new AnnotationConfigContext(AppContext.class);

// 2. 컨테이너에서 빈 객체를 구해서 사용
Greeter g = ctx.getBean("greeter", Greeter.class);
String msg = g.greet("스프링");
System.out.println(msg);

// 3. 컨테이너 종료
ctx.close();

1. AnnotationConfigApplicationiContext의 생성자를 이용해서 context 객체를 생성한다.
   이 시점에서 스프링 컨테이너 초기화가 진행되고, 이 스프링 컨테이너는 설정 클래스에서 정보를 읽어와 알맞은 빈 객체를 생성하고 각 빈을 연결(의존주입)하는 작업을 수행한다.
   
   
2. (위에서 초기화되어 사용가능한 컨테이너) getBean()과 같은 메서드를 이용해서 컨테이너에 보관된 빈 객체를 구한다.
   
   
3. 컨테이너 사용을 종료할 때 사용하는 메서드이다. AbstractApplicationContext 클래스에 정의되어 있다.
   AnnotationConfigApplicationiContext가 AbstractApplicationContext를 상속 받기 때문에 close() 사용이 가능하다.

컨테이너 초기화 -> 빈 객체의 생성, 의존 주입, 초기화
컨테이너 종료 -> 빈 객체의 소멸

스프링 빈 객체의 라이프 사이클

객체생성 - 의존설정 - 초기화 - 소멸

스프링 컨테이너는 빈 객체의 라이프 사이클을 관리한다.

1. 빈 객체의 초기화와 소멸 : 스프링 인터페이스

• org.springframework.beans.factory.InitializingBean
• org.springframework.beans.factory.DisposableBean

빈 객체를 생성한 뒤, 초기화 과정이 필요하면

InitializingBean 인터페이스를 상속하고 afterPropertiesSet()메서드를 구현하면 된다.

빈 객체의 소멸 과정이 필요하면 DisposableBean 인터페이스를 상속하고 destroy()메서드를 구현하면 된다.

ex. 데이터 베이스 커넥션 풀, 채팅 클라이언트

메서드 정의 인터페이스

• org.springframework.beans.factory.InitializingBean
• org.springframework.beans.factory.DisposableBean

//초기화 인터페이스
public interface InitializingBean {
    void afterPropertiesSet() throws Exception;
}

//소멸 인터페이스
public interface DisposableBean {
    void Destroy() throws Exception;
}

해당 코드를 수행하면 콘솔 화면에 매서드에서 정의한 "Client.afterPropertiesSet() 실행" 및 "Client.destroy() 실행"이 출력 됨

빈 객체 생성을 마무리한 뒤에 초기화 메서드를 실행한다.
또, 가장 마지막에 destroy() 메서드를 실행한다.

2. 빈 객체의 초기화와 소멸 : 커스텀 메서드

인터페이스로 상속받아 구현하는 것 말고 외부에서 제공받은 클래스를 스프링 빈 객체로 설정하고 싶을 때도 있다.

스프링 설정에서 직접 메서드를 지정할 수 있다.

@Bean태그에서 initMethod 속성과 destroyMethod 속성을 사용해서 초기화 메서드와 소멸 메서드의 이름을 지정하면 된다.

//Client2.java
        ...

// 직접 초기화 메서드 지정
public void connect(){
    System.out.println("Client2.connect() 실행");
}

// 직접 소멸 메서드 지정
public void close(){
        System.out.println("Client2.close() 실행");
}

        ...

이 메서드들을 @Bean 애노테이션의 initMethod 속성과 destroyMethod 속성에 사용될 메서드 이름인 connect와 close를 지정해주면 된다.

@Bean(initMethod = "connect", destoryMethod = "close") public Client2 clien2(){ ... }

초기화 메서드를 직접 실행할 때 초기화 메서드가 두 번 불리지 않다록 조심하자. afterPropertiesSet()이 두번 불릴 위험 있음

빈 객체의 생성과 관리 범위

// 한 식별자에 대해 한 개의 객체만 존재하는 빈
// 싱글톤 범위를 갖는다.
//client1 == client : true
Client client1 = ctx.getBean("client", Client.class);
Client client2 = ctx.getBean("client", Client.class);

------------------------
// client 빈의 범위가 프로토타입일 경우
// 매번 새로운 객체를 생성
// client1 != client : true
Client client1 = ctx.getBean("client", Client.class);
Client client2 = ctx.getBean("client", Client.class);

별도의 설정을 하지 않으면 싱글톤 범위를 갖는데, 특정 빈을 프로토 타입으로 빈을 설정할 수 도 있다. @Scope애노테이션을 사용해주면 된다.

@Bean
@Scope("prototype")
public Client client(){
        ...
}

• 싱글톤 범위를 명시적으로 지정해주고 싶으면 @Scope("singleton)이라고 해주면 된다.
• 프로토 타입은 별도의 소멸 처리를 코드에서 직접 해야 한다.

Reference.

'초보 웹 개발자를 위한 스프링5 프로그래밍 입문'