검색엔진 비교_Solr vs ElasticSearch

안녕하세요.

검색엔진을 개발하는 이슈가 생겨 현재의 인프라 환경에 적합한 오픈소스를 찾다 Apache Lucene을 알게 되었고, 개발하게 되었습니다.

그리고, Lucene을 적용하기 위해 레퍼런스와 여러 문서들을 찾으면서, 새로운 의문점들이 생겨났습니다.

 

정말 이 검색엔진이 가장 좋은가?

성능 면에서 어떤 검색엔진 오픈소스가 더 뛰어난가?

어떤 검색엔진 오픈소스가 관리하거나 구축하기 쉬운가?

 

해당 질문에 대해 항상 명확하고 적용 가능한 답변이 있는 것은 아니지만 어느 목적으로 사용하느냐에 따라 보다 나은 혹은 올바른 선택을 하는데 도움이 될 것입니다.

 

Lucene를 이용하여 검색엔진을 개발을 완료한 지금 뭔가 더 좋은 검색엔진으로 업그레이드 하고 싶은 욕심이 생겨 다시 비교분석을 해보게 되었습니다.

 

출처 : https://db-engines.com

위 순위는 검색포털 사이트(goolgle, bing 등) 검색 횟수/빈도와 IT 커뮤니티(StackOverflow, DBA Stack Exchange 등) 관련 질문 수와 관심 있는 사용자 수 등으로 측정된 검색엔진 순위입니다.

 

독립적으로 Apache Lucene만을 사용하여 검색엔진을 구현하는 것은 어렵습니다. 그래서 대부분은 검색엔진의 기본적인 기능이 구현되어 있는 오픈소스를 주로 사용합니다.

상위 3개의 검색엔진 중 유료로 제공되는 Splunk를 제외한 Elasticsearch와 Solr에 대한 비교를 진행하도록 하겠습니다.

 

두 검색엔진 오픈소스 모두 Apache Lucene을 기반으로 구축되었지만 속도, 확장성, 배포용이성 등과 같은 기능면에서 차이점이 존재합니다.

 

Elasticsearch는 로그 분석, 모니터링, 위치 기반 정보 데이터 분석 및 시각화화 같은 사례에 더 적합하고 자주 사용되며, Solr는 캐시, 전자 상거래와 같이 패킷 및 정렬에 역변환 되지 않은 정적 데이터와 관련하여 더 많은 이점이 있습니다.

 

아래는 검색엔진의 대표적인 기능인 인덱싱, API, 검색에 대해 두 오픈소스를 비교해보았습니다.

 

- 검색엔진의 대표적 기능에 대한 비교

 

1. 인덱싱

  Elasticsearch 5.* Solr 6.* 비고

Data Import

JDBC, Amazon SQS, CouchDB, Git, MongoDB, Redis, RSS, SVN, Twitter 등

JDBC, XML, URL, FileSystem 등

Elasticsearch가 더 다양한 형식에서 데이터를 가져올 수 있도록 기능이 구현되어 있음

수정

수정 데이터만 재색인

전체 재색인

데이터 수정이 자주 발생할 경우 Elasticsearch가 유리

실시간 인덱싱

인덱싱 직후 검색 가능

인덱싱 후 가까운 시간 내 검색 가능

두 오픈소스 모두 실시간 검색이 가능하나 인덱싱 속도는 Elasticsearch가 빠름

스키마 변경 변경시 즉시 적용 변경시 재가동 후 적용

스키마 변경이 잦다면 Elasticsearch를 활용

 

2. API

  Elasticsearch 5.* Solr 6.* 비고
호출타입 JSON XML, CSV, JSON  
JAVA API TransportClient SolrJ  
공식 지원 언어 Go, Haskell, Java, Javascript, .Net, PHP, Python 등 Java  
output 타입 JSON, XML, HTML JSON, XML, PHP, Python, ruby, csv 등 Elasticsearch는 플러그인 설치로 타입 추가 가능

 

3.검색

  Elasticsearch 5.* Solr 6.* 비고
Query DSL 지원 지원하지 않음 Elasticsearch가 Solr보다 다양한 기능의 쿼리 지원
인덱스간 조인 지원하지 않음 지원  
검색 속도 Elasticsearch > Solr  
장문 Text 검색 속도 Elasticsearch > Solr  

 

위 내용을 참조하면 어떤 검색엔진 오픈소스를 사용하는 것이 좋을지 선택하는데 도움이 될 것입니다.

 

아래 이미지는 제가 실제 구축한 Solr 검색엔진 플랫폼입니다.

당시 Solr 검색엔진을 선택한 몇 가지의 이유를 말씀드리겠습니다.

 

1. Elasticsearch 보다 상대적으로 안정적인 검색엔진

2. 검색엔진에 활용될 데이터들이 주로 장문의 Text로 구성

- 활용할 데이터들이 CLOB 데이터 타입이나 크롤링으로 가져오는 Text이며 Indexing 작업이나 스키마 수정이 잦지 않으므로 Solr에 더 적합하다고 판단하였습니다.

 

Solr 검색엔진을 운영하며 느낀 점은 빠른 검색 속도와 높은 안정성(검색 요청 시나 인덱스 작업 시 간단한 오류는 무시) 등이 상당히 만족스러웠습니다. 하지만 결과내 검색이나 Multi Index 검색 등을 지원하지 않아 아쉬움을 느꼈습니다.

 

 

 

 

 

출처

- https://www.elastic.co/kr/

- https://lucene.apache.org/solr/

- https://sematext.com/blog/solr-vs-elasticsearch-differences/

- http://solr-vs-elasticsearch.com

 

 

 

New Multi-Channel Dynamic CMS

AWS를 이용한 서버 구축2_아마존 EC2로 구축하기

안녕하세요. 오늘은 AWS를 이용한 서버 구축 1편에 이어 2편을 소개해드리려고 합니다.

혹시 1편에 대한 내용이 궁금하시다면,  AWS를 이용한 서버 구축1 을 통해 내용을 확인해주세요~

 

1. 클라우드란?

   EC2 구축에 들어가기 앞서 클라우드에 대해 간략하게 알아보겠습니다.

 

1)   클라우드 정의

     니콜라스 카스의 정의에 따르면 IT 자원을 구매하거나 소유할 필요 없이 필요한 만큼 사용료를 주고 사용하는 서비스 입니다.

 

2)   클라우드 분류

      IaaS : 인프라 자원을 서비스

      PaaS : 개발에 필요한 환경 서비스

      SaaS : 사용자가 원하는 소프트웨어 서비스

3)   IaaS 종류

     ① Amazon EC2

      Microsoft Azure

      Google Cloud Platform

      Naver Cloud Platform

 

4)   Amazon EC2 만의 장점

      ① 시장점유율이 가장 높음

       다양한 옵션을 맞춤 개발 가능

       앱설치를 위한 엘라스틱 빈스톡이나 EC2 컨테이너 서비스, AWS 람다 및 오토스케일링 같은 서비스도 제공

       방대한 툴과 서비스, 기업친화적 기능으로 어필

 

2. Apache Tomcat 서버 구축

클라우드에 대해 간략히 알아보았으니, 가장 대표적인 클라우드인 Amazon EC2를 활용하여 Tomcat 서버를 구축해 보겠습니다. 아래는 간단한 구성도 입니다.

1)   EC2 생성하기

      AWS Management Console > 컴퓨팅 > EC2 > 인스턴스 이동

      인스턴스 시작        

      Amazon Machine Image(AMI) 선택

         운영체제, 서버, 소스, 리눅스 초기 설정 등이 포함

      인스턴스 유형 선택

         cpu, 메모리, 네트워크 대역

     ⑤ 인스턴스 구성

         인스턴스 개수, 스팟 옵션, VPC, 가용영역, 퍼블릭 IP, IAM, 삭제방지, 모니터링 등 설정

     ⑥ 스토리지 추가

         Root 장치는 필수이며 EBS만 사용가능, 장치 이름, ID, 스토리지 크기, 볼륨 유형, 삭제 방지 등 설정

     ⑦ 보안 그룹 구성

         방화벽 설정

     ⑧ 시작하기

     ⑨ 생성된 인스턴스

2)   EC2 접속하기 (Xshell 기준)

     ① IPv4 퍼블릭 IP 복사

     ② ssh://{계정}:{패스워드}@{퍼블릭 IP}:22

     ③ 접속확인

 

3)   EC2에 소스 올리기 (FileZilla 기준)

     ① IPv4 퍼블릭 IP 복사

     ② 호스트, 사용자명, 비밀번호, 포트 입력 후 빠른 연결

     ③ 연결확인

     ④ 로컬에 있는 소스 더블클릭 또는 드래그하여 리모트로 파일 올리기

4)   Apache Tomcat 서비스 실행

      {Tomcat Home}/bin/catalina.sh start

5)   서비스에 접속하기

      {IPv4 퍼블릭 IP}:{port}

3. Amazon RDS 이용

구축한 서버에 Amazon에서 제공하는 DB를 연결해 보겠습니다.

아래는 간단한 구성도 입니다.

 

1)   RDS 생성

     ① AWS Management Console > 데이터베이스 > Amazon RDS > 데이터베이스

     ② 데이터베이스 생성    

     ③ 엔진 선택

     ④ 사용 사례 선택

     ⑤ DB 세부 지정

     ⑥ 고급 설정 구성

     ⑦ 생성확인

    

2)   접속하기(Toad for Oracle 기준)

     ① RDS 선택

     ② 연결 & 보안 탭에서 엔드포인트 및 포트 확인

     ③ Toad로 접속

     ④ 쿼리조회

 

3)   WAS서버 연결하기

     ① 엔트포인트 확인

     ② config 파일에 연결 정보 입력

     ③ catalina log에서 connection 확인

 

4.  Apache Web 서버를 이용한 이중화

이중화를 하기 위하여 톰켓 앞단에 WEB서버를 구축하고, 2개의 Tomcat 서버로 연결해보겠습니다.

아래는 간단한 구성도 입니다.

 

1)   Apache와 Tomcat 연결하기

     ① Tomcat EC2의 프라이빗 IP 확인

     ② httpd-vhosts.conf 파일 수정

     ③ workers.properties 파일 수정

2)   Apache 실행

     ① {Apache Home}/bin/apachetl start 명령어로 실행

     ② ps –ef | grep httpd 명령어로 실행 확인

3)   서비스 접속하기

     ① Apache EC2 인스턴스의 Ipv4 퍼블릭 IP 확인

     ② {Ipv4 퍼블릭 IP}:{port}

5. WEB서버 없이 ELB를 이용한 이중화

Apache WEB을 Amazon에서 제공하고 있는 Network load balancer로 교체하여 이중화를 해보겠습니다.

아래는 간단한 구성도 입니다.

1)   ELB 생성 및 Tomcat EC2와 연결

     ① AWS Management Console > 컴퓨팅 > EC2 > 로드밸런서 이동

     ② 로드 밸런서 생성

     ③ 로드 밸런서 유형 선택

     ④ 로드 밸런서 구성 지정

     ⑤ 보안 그룹 구성 지정

     ⑥ 대상그룹 생성

     ⑦ 대상 그룹에 인스턴스 추가

     ⑧ 대상 그룹 확인

     ⑨ 생성된 ELB 확인

2)   서비스 접속하기

     ① ELB의 DNS 이름 확인

     ② ELB DNS 이름으로 접속

6. AUTO SCALING 구축

전통적인 서버대신 IaaS를 사용할 경우 가장 큰 이점이 되는 AUTO SCALING을 적용해보도록 하겠습니다.

아래는 간단한 구성도 입니다.

1)   서버 부팅시 Tomcat 자동실행

      AUTO SCALING으로 자동 생성되는 EC2는 서버와 소스들은 전부 들어 있더라도 서비스가 시작되어 있지 않기 때문에 서버가 켜질 때 tomcat 서비스도 자동으로 실행이 되어야 합니다.

 

     ① tomcat1 서비스 생성

          vi /etc/rc.d/init.d/tomcat

    ② tomcat1 내용 작성

        #!/bin/bash

       # Startup script for the Tomcat Server

       # chkconfig: 345 50 50

       # description: Tomcat is a Web application server.

       # processname: java

       # directory : CATALINA_HOME=

       source /etc/profile

       export CATALINA_HOME=

       case "$1" in

              start)

                    echo "Starting tomcat: "

                    su - approot -c $CATALINA_HOME/bin/startup.sh

                    ;;

              stop)

                   echo "Shutting down tomcat: "

                   su - approot -c $CATALINA_HOME/bin/shutdown.sh

                    ;;

              restart)

                    echo "Restarting tomcat: "

                    su - approot -c $CATALINA_HOME/bin/shutdown.sh;

                    su - approot -c $CATALINA_HOME/bin/startup.sh

                    ;;

              *)

                   echo "Usage: service tomcat1 {start|stop|restart}"

                   exit 1

          esac

          exit 0

 

      ③ tomcat1 권한 변경

           chmod 755 tomcat

      ④ tomcat run level에 등록

          chkconfig --add tomcat

     ⑤ run level 에 등록되었는지 확인 (run level이 3,4,5 일 때 구동 된다.)

          chkconfig --list tomcat

 

2)   80 포트 사용하기

AUTO SCALING으로 자동 생성되는 EC2는 80 PORT로 ELB에 붙어 로드벨런싱이 되기 때문에 80으로 들어오는 트레픽을 tomcat 서비스 port로 연결을 해주어야 합니다.

 

     ① 방화벽 설정

        vim /etc/sysconfig/iptables

     ② 내용 변경

          # Generated by iptables-save v1.4.7 on

          *nat

           :PREROUTING ACCEPT [0:0]

           :POSTROUTING ACCEPT [32:2633]

           :OUTPUT ACCEPT [32:2633]

           -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

           COMMIT

           # Completed on

    ③ 설정한 방화벽 적용

         /etc/rc.d/init.d/iptables restart

    ④ iptables run level에 등록

        chkconfig --level 2345 iptables on

    ⑤ run level 에 등록되었는지 확인  

       chkconfig --list iptables

 

3)   AMI 생성하기

위의 설정을 마친 EC2 인스턴스로 AMI를 만들고 그 이미지로 EC2 인스턴스가 생성되어야만 AUTO SCALING이 정상 작동합니다.

     ① 인스턴스 우클릭 하여 이미지 생성

     ② 이미지 이름 및 볼륨 크기 설정

     ③ 생성된 AMI (1~5분 정도의 시간이 소요 됨)

4)   AUTO SCALING 시작 구성 생성

      ① AWS Management Console > 컴퓨팅 > EC2 > AUTO SCALING > 시작 구성 이동

      ② 시작구성생성  

      ③ 3) 에서 생성한 AMI 선택

      ④  cpu, 메모리 선택

      ⑤  시작 구성의 이름 지정

      ⑥ 스토리지 용량 및 볼륨 유형 지정

      ⑦ 방화벽 설정

      ⑧ 생성된 시작 구성 확인

 

5)   AUTO SCALING 그룹 생성

     ① AWS Management Console > 컴퓨팅 > EC2 > Auto SCALING > Auto Scaling 그룹이동

     ② Auto Scaling 그룹 생성

     ③ 4) 에서 생성한 시작 구성 지정

     ④  자동으로 만들어지는 인스턴스가 로드 밸런스로 들어오는 트래픽을 받을 수 있도록 로드 밸런서의 대상 그룹 지정

     ⑤  인스턴스가 몇개까지 늘어날지, 어떤 지표 상태에서 인스턴스가 추가가 될것인지 지정

     ⑥ Auto Scaling 그룹 생성

     ⑦ 생성된 Auto Scaling 그룹 확인

     ⑧ 시간이 지나면 자동으로 인스턴스가 0에서 1로 변한 것을 확인

     ⑨ 생성된 인스턴스 목록 확인

     ⑩ 인스턴스가 생성 될 시 활동 기록

     ⑪ 인스턴스가 삭제 될 시 활동 기록

 

7. 캐시서버 연결하기

 사용자의 지역과 서버의 지역이 같으면 페이지가 빠르게 로딩이 되지만 그렇지 않을 경우 매우 느리게 로딩이 됩니다. 이것을 해결 하기 위하여 캐시서버를 사용 하는데, Amazon에서는 CloudFront를 제공합니다. 속도 뿐만 아니라 캐시서버에서 응답을 대부분 처리하기 때문에 서버에 가해지는 트래픽이 감소하게 되는 이점이 있습니다. 지금까지 만들어진 서버에 CloudFront를 적용해 보겠습니다. 아래는 간단한 구성도 입니다.

1)   CloudFront 생성하기

     ① Create Distribution

     ② 전송 방식을 선택합니다.

         Web : 일반적인 웹서버, RTMP : 동영상 실시간 스트리밍

     ③ 오리진 설정

         오리진 도메인, 구분 ID 등 설정

     ④ 기본 캐시 동작 설정

         프로토콜, 캐시 유지기간, 쿠키 전달, 쿼리 문자열 전달, URL 제한 등 설정

     ⑤ 배포설정

         요금수준, 도메인 연결, SSL 인증서, Root 파일명, 접속로그, 메모 등 설정

     ⑥ 생성된 CloudFront

         배포가 모든 에지 로케이션에 전파되기 까지 약 15분~20분 소요

  2)   서비스 접속하기

 

8 . Jmeter로 성능 테스트 하기

APACHE 제단의 Open Source인 Jemeter는 서버의 성능을 측정하는 툴로 다양한 프로토콜을 지원하며, 서버의 Resouce 자원까지 모니터링이 가능하고, 다양한 plugin을 제공하고 있습니다. 또한 스크립트도 넣을수 있고, Max, Linux, Windows 에서 동작을 합니다. 여기서는 간략하게 사용방법을 알아보고, 직접 테스트까지 해보겠습니다.

 

1)   설치하기

     ① https://archive.apache.org/dist/jmeter/binaries/

        다운 받은 zip 파일 압축 해제

 

2)   실행

     ① /bin/jmeter 실행

 

3)   상단메뉴

 

4)   왼쪽 창

5)   비교 테스트

     ① 비교는 아래와 같이 요청 설정하였으며, 호출 간격은 1초를 주었고, 요청횟수는 20번을 요청하였습니다.

     ② 아래는 응답속도를 그래프로 나타낸 것이며, CloudFront = 전통 CloudFront > ELB > WEB = WAS > 전통 WEB 순으로 나왔습니다.

     ③ 아래는 각각의 평균 수치입니다.

 

 

 

 

New Multi-Channel Dynamic CMS

AWS를 이용한 서버 구축1

AWS (Amazon Web Services)

아마존닷컴이 제공하는 원격 컴퓨팅 서비스이며, 클라우드 서비스의 대표적인 아마존 웹 서비스 (AWS)를

이용한 서비스를 구성하기 위하여 AWS의 기본 개념을 알아 보도록 하겠습니다.

 

1. 리전 (Region)

- 지리적 위치 (서울, 도쿄, 북경 등)

- 장애 발생 등을 고려하여 최소 2개 이상의 가용 영역으로 구성

- 아마존 사이트를 통하여 리전 위치와 개수 확인 가능

- AWS 클라우드는 전세계 18개의 지리적인 리전이 있으며 서울에도 리전이 있음

- 리전에 따라 과금 체계가 다르기 때문에 비용을 고려한 리전 선택이 필요

https://aws.amazon.com/ko/about-aws/global-infrastructure

2. 엣지 (Edge Location)

- 콘텐츠 혹은 정적 파일을 빠르게 전달하기 위한 배포 서비스 인프라

- 개별 지역에서 사용자에게 더 빠르게 파일을 배포 할 수 있어 서비스 속도를 높임

- CDN(Content Delivery Network) : 콘텐츠 배포 네트워크. 콘텐츠를 사용자가 빠르게 받을 수 있도록

  전세계에 위치한 캐시 서버 복제 서비스

- CDN 서비스를 제공하기 위한 캐시 서버

 

3. 가용영역 (AZ:Availability Zone)

- 리전 내부에 분리된 서버군 데이터 센터의 클러스터

- 개별 가용 영역은(AZ)로 구성

- 다른 가용 영역의 장애로부터 격리

- 재난 및 재해 시 서비스의 가용성을 위해 분리한 구성

 

 

4. 애플리케이션을 위한 인프라 서비스

AWS 글로벌 인프라 위에 모든 자원이 서비스로 제공됨

 

4.1 EC2(Amazon Elastic Compute Cloud)

 

- Amazon EC2에 대한 정보 

   (1) 컴퓨팅 요구 사항의 변화에 따라 컴퓨팅 용량 조절 가능

   (2) 리눅스 OR 윈도우 운영체제 중에 선택

   (3) 안정성을 위해 여러개의 아마존 서비스의 리전과 가용영역에 걸처 배포 해야함

         (DR을 고려한 2개 안정적인 영역에 배포)

   (4) 인스턴스별로 태그를 사용하여 Amazon EC2 리소스를 관리

   (5) 실제로 사용한 용량만큼 비용을 지불

 

 - Management Console을 통해 Amazon EC2 인스턴스 시작

   (1) Amazon EC2 인스턴스를 설치할 AWS 리전을 지정

   (2) 사전 구성된 Amazon 머신 이미지 (AMI)에서 Amazon EC2 인스턴스 시작
       (일반 PC를 예로 들면 이미지CD를 이용하여 PC설치하는것과 같은 개념임)

   (3) CPU, 메모리, 스토리지 및 네트워크 요구 사항에 따라 인스턴스 유형을 선택

   (4) 네트워크, IP주소, 보안그룹, 스토리지 볼륨, 태그, 키페어를 구성

       * Amazon 머신 이미지 (AMI) 세부 내용

         - 인스턴스 루트 볼륨 템플릿 (ex. 운영체제, 애플리케이션서버, 애플리케이션)

         - AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작 권한 (제어키:키페어)

         - 시작될 때 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스

          (제공하는 AMI 이용이나 사용자가 만들어 사용가능)

 

 - 인스턴스 생명주기: 콘솔에서 수동관리하며 API(또는 툴)로 자동관리 할 수 있음

 

 - 인스턴스 메타데이터 및 사용자데이터

    (1) 실행중인 인스턴스 내에서 모든 인스턴스 메타데이터 카테고리를 확인

        - http://IP/latest/meta-data

        - http://IP/latest/user-data

    (2)리눅스 인스턴스 호스트명 조회를 위한 메타 데이터 사용 예

       - $ curl  http://IP/latest/meta-data/hostname

       - $ GET http://IP/latest/meta-data

 

4.2 EBS(Amazon Elastic Block Store)

 

- Amazon EBS에 대한 정보

   (1) 데이터를 빠르게 액세스하고 장기간 지속해야 하는 경우

   (2) EBS 볼륨을 암호화된 볼륨으로 시작할 수 있으며, 볼륨에 저장된 데이터, 디스크 I/O, 볼륨에서 생성된 스냅샷이 모두 암호화 됨

   (3) Amazon S3까지 지속되는 EBS 보륨의 특정 시점 스냅샷을 생성할 수 있음

 

 - Amazon EBS 볼륨 유형

  SSD HDD
볼륨유형 범용SSD(gp2) 프로비저닝된 IOPS SSD 처리량 최적화 HDD(st1) 콜드 HDD(sc1)
설       명 다양한 트랜젝션 로드에 적합 미션 크리티컬 애플리케이션에 적합한 고성능 SSD 자주 액세스하고 처리량 집약적인 워크로드에 적합한 저렴한 HDD 자주 액세스하지 않는 워크로드에 적합한 최저비용 HDD
성능속성 용량 작은 용량에 유리 처리량 우선 Data 저장공간 우선

 - Amazon EBS 사용 사례

   (1) OS : 부트/루트 볼륨, 보조 볼륨에 사용

   (2) 데이터베이스 : 성능 요구 사항에 맞춰 확장

   (3) 엔터프라이즈 애플리케이션 : 미션 크리티컬 애플리케이션을 실행 할 수 있는 안정적인 블록 스토리지 제공

   (4) 비즈니스 연속성 : EBS 스냅샷을 사용해 정기적으로 백업하여 데이터 손실 및 복구 시간을 최소화

   (5) 애플리케이션 : 어떤 애플리케이션이든 설치 및 지속

 

 - Amazon EBS 생명주기

4.3 S3(Amazon Simple Storage Service)

 

- Amazon S3 에 대한 정보

    (1) 버킷에 저장할 수 있는 객체수에 제한이 없음

    (2) 객체 크기는 최대 5TB 지원 하며, 버킷 크기는 제한이 없음

    (3) HTTP/S 엔드 포인트를 사용하여 웹에서 원하는 양의 데이터를 저장하고 검색할 수 있음

    (4) AWS를 사용하여 서버측 암호화를 하거나, 고객이 관리하는 클라이언트 측 암호화를 하도록 선택할 수 있음

 

 - Amazon S3 개념

   (1) 데이터를 버킷 내에 객체*로 저장

   (2) 객체는 파일과 해당 파일을 설명하는 모든 메타데이터 구성

   (3) 하나의 계정에 최대 100개의 버킷 보유

   (4) S3 생성시 어느 리전에 생성할지를 지정하여야 함

   (5) 버킷을 프로젝트 단위로 생성하여 사용 가능

 

 - Amazon S3 버전 관리

   (1) 성능저하 없이 실수로 덮어쓰거나 삭제하는 것을 방지

   (2) 모든 업로드에 대해 새 버전을 생성

   (3) 삭제된 객체를 쉽게 검색하거나 이전 버전으로 롤백 가능

   (4) Amazon S3 버킷의 세가지 상태

 

* 객체키

 

 - Amazon EBS 와 S3의 비교

  Amazon EBS Amazon S3
패러다임 파일 시스템이 있는 블록 스토리지 객체 저장소
성     능 매우 빠름 빠름
중 복 성 가용영역의 여러 서버에 걸쳐 있음
(데이터 센터 내)
리전 내 여러 시설에 걸쳐 있음
(데이터 센터 간)
보     안 데이터 볼륨 및 스냅샷
(EC2 인스턴스만 접근 가능)
암호화 (퍼블릭 키/프라이빗 키)
인터넷 액세스 불가능* 가능**
일반적 사례 디스크 드라이브 온라인 스토리지 (한번 쓰고 여러번 읽는 경우)

 * 서버에 탑재하고 FTP등으로 설저하면 인터넷에서 액세스 가능

 ** ACL이 모든 사용자가 읽을 수 있도록 설정되어 있지 않은 경우 적절한 자격 증명 필요

 

 - Amazon EBS 와  EC2 의 비교

  Amazon EBS Amazon EC2 인스턴스 스토어
차이점 EBS 볼륨에 저정된 데이터는 인스턴스의 수명과 무관하게 유지 로컬 인스턴스 스토어에 저장된 데이터는 인스턴스가 활성화 되어 있는 동안만 유지
영구적 스토리지 휘발성 스토리지

  - EC2 인스턴스 스토어 재부팅, 중단, 종료 비교

  재부팅

중단/시작

(EBS-backed 인스턴스만 해당)

종료
호스트 컴퓨터 동일 호스트 컴퓨터 유지 새 호스트 컴퓨터 실행  
퍼블릭 IP 주소 변경 없음 새 주소가 지정됨  
탄력적 IP주소(EIP) EIP 인스턴스와 연결된 상태로 유지 EIP 인스턴스와 연결된 상태로 유지 EIP 인스턴스와 연결이 끊어짐
인스턴스 스토리지 보존됨 삭제됨 삭제됨
EBS볼륨 보존됨 보존됨 부트 볼륨은 기본적으로 삭제
결제 인스턴스 청구 시간이 변경되지 않음 중단 변경 즉시 비용발생 중단  종료 변경 즉시 비용 발생 중단

 

4.4 RDS(Amazon Relational D Services)

 

 - 데이터 베이스 고려 사항

요구사항 고려사항
RDB 서비스

Amazon RDS

- Amazon Aurora, MySQL, MariaDB, Microsoft중 선택 SQL Server, Oracle 또는 

  PostgreSQL 데이터 베이스 엔진

- 컴퓨팅 및 스토리지 확장

- 다중 AZ 가용
NoSQL 서비스

Amazon Dynamo DB

- NoSQL의 장점인 빠른 성능

- 확장성 및 안정성

- 저렴한 비용
사용자자체 DB 원하는 AMI 적용(확장 가능한 컴퓨팅 및 스토리지, 인스턴스에 대한 제어)

 

4.5 Amazon VPC

 

 - Amazon VPC 구성도

다음 시간에는 AWS를 이용한 EC2 서버 구축에 대해 알아 보겠습니다.

 


AWS를 이용한 서버 구축 2편에 대한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

AWS를 이용한 서버 구축2_아마존 EC2로 구축하기

 

New Multi-Channel Dynamic CMS

성능 TEST를 위한 보고서 3

1. nGrinder

nGrinder는 The Grinder라는 오픈소스를 기반으로 네이버에서 개발한 성능 측정 오픈소스 프로젝트입니다. Jython(Java + Python) 언어를 이용하여 테스트 스크립트 코드를 직접 작성할 수 있어 JMeter에 비해 다소 무겁지만 세밀한 성능테스트를 진행할 수 있습니다. 또한 jython뿐만 아니라 groovy, groovy+maven을 지원하며, Controller는 WAS기반으로 동작합니다.

 

2. nGrinder Architecture

nGrinder는 Controller, Agent, Target으로 나뉘어 있습니다.

Controller 성능테스트를 위해 웹 인터페이스를 제공하며, 테스트 프로세스를 조정할 수 있습니다. 또한, 테스트 결과를 수집하여 통계로 나타내는 역할도 합니다.
Agent Controller의 명령을 받아 실행합니다. 테스트 스크립트를 수행하는 Worker 개념으로 Target이 되는 머신에 프로세스와 스레드를 실행시켜 부하를 발생시키는 역할을 합니다.
Target 테스트 대상이 될 서버입니다.

 

3. nGrinder 설치

nGrinder는 자바 기반이기 때문에 Controller와 Agent를 설치하려면, Oracle JDK 1.6이상 또는 open JDK 1.7이상, Tomcat 6 버전 이상이 사전 설치되어야 합니다.

다운로드 : http://sourceforge.net/projects/ngrinder/files

(다운로드 된 war 파일은 반드시 스페이스가 포함되지 않는 폴더에 설치하셔야 합니다.)

 

4. nGrinder Controller 설치

nGrinder는 Jenkins와 유사하게 자체적으로 실행 가능한 웹 아카이브 파일(WAR)로 배포됩니다. 따라서 WAR 파일을 직접 자바로 실행할 수도 있고, Tomcat 같은 웹 어플리케이션 서버에 올려 실행할 수도 있습니다.

저는 Tomcat 서버에 올려 성능테스트를 진행하도록 하겠습니다.

. 다운로드 받은 WAR 파일을 Tomcat의 webapps 폴더(${TOMCAT_HOME}/webapps)에 저장합니다.

가-1. 만약 nGrinder를 컨텍스트 경로(http://localhost/ngrinder-controller-3.3와 같이)가 없이 바로 http://localhost와 같은 형태로 접근하고자 한다면 WAR 파일명을 ROOT.war로 변경하시면 됩니다.

. nGrinder Controller는 메모리를 많이 사용하기 때문에 메모리 설정이 필요합니다. 아래 설정을 하지 않을 경우, 몇 가지의 관리자 기능이 동작하지 않습니다.

${TOMCAT_HOME}/bin/catalina.sh(리눅스) 또는 ${TOMCAT_HOME}/bin/catalina.sh(윈도우) 파일을 열어 가장 앞 부분에 다음과 같이 메모리 설정을 추가합니다.

다. ${TOMCAT_HOME}/bin/startup.sh(리눅스) 또는 ${TOMCAT_HOME}/bin/startup.bat(윈도우) 파일을 실행합니다.

라. 브라우저를 열고 해당 서버로 접속하면 아래와 같은 로그인 페이지가 나옵니다. (기본 ID/PW는 admin/admin 입니다.)

 

5. nGrinder Agent 설치

가. Tomcat에 설치된 Controller로 로그인을 한 뒤 우측 상단의 메뉴를 클릭하여 “에이전트 다운로드”를 선택해 설치합니다.

나. 설치된 tar 파일을 압축 해제하고, 해제된 폴더로 이동하여 __agent.conf 파일을 확인합니다.   Controller에서 직접 받은 agent 파일의 경우는 ip와 port가 등록되어 있어 수정할 필요가 없습니다. 만약 Controller에서 설정을 바꾸셨다면 agent 설정파일도 수정하여야 합니다.

다. run_agent.sh(리눅스) 또는 run_agent.bat 파일 실행하여 Agent를 실행시킵니다.

라. Agent 실행 후 Controller에서 우측 상단 메뉴의 “에이전트 관리”를 선택하면 아래와 같이 연결된 Agent 목록을 볼 수 있습니다.

 

6. nGrinder 테스트

가. Quick Start를 이용하여 쉽고 빠르게 테스트를 할 수 있습니다. 테스트 대상 URL을 입력하고 “테스트 시작” 버튼을 클릭하면 사용자의 테스트 스크립트가 자동으로 생성되며 테스트 설정 페이지로 이동합니다.

나. 테스트 방식을 설정합니다.

에이전트 Controller와 연결되어 있는 에이전트의 수 만큼 사용가능 합니다.
스크립트 사용자가 해당 주소로 부하를 걸 스크립트를 보여줍니다.
RHEAD 선택된 스크립트의 내용을 보여주는 페이지로 이동합니다.
테스트 대상 서버 테스트를 진행할 서버의 리스트를 보여주며, 추가버튼 클릭 시 테스트 받을 서버를 늘릴 수 있습니다.
테스트 기간 해당 테스트를 얼마만큼 실행할 지 설정하는 항목입니다.
실행 횟수 사용자가 설정한 쓰레드당 몇 번의 테스트를 실행할 것인지를 지정합니다.
Ramp_Up 점차 부하를 가할 수 있는 기능입니다. 부하를 가할 때, 가상 사용자 수를 늘리는 것이 아닌 process나 thread를 늘립니다.
초기 개수 처음 시작 시 가상사용자의 수를 설정합니다.
초기 대기시간 테스트를 언제부터 실행시킬 지를 설정합니다.
증가 단위 해당 process/thread를 몇 개씩 증가시킬지를 설정합니다.
Ramp_Up 주기 설정한 것들의 상승 시간을 설정합니다.

 

6. nGrinder 사용 방법

가. RHEAD 버튼을 클릭하여 생성된 스크립트를 확인/수정 할 수 있습니다.

나. 성능테스트 수행 (수행 중)

성능테스트 수행 중 상단 우측 공 위에 마우스 커서를 올려 놓으면, 팝업 창이 나타나 테스트 진행 메시지를 나타냅니다. 또한, 테스트 진행 현황 탭에서 현재 진행 중인 테스트 상태를 실시간으로 확인할 수 있습니다.

다. 성능테스트 수행 종료 (보고서)

성능테스트가 종료되면 요약된 성능테스트 결과보고서를 보여줍니다. 자세한 결과를 보고 싶으시면 상단에 “상세보고서” 버튼을 클릭하시면 됩니다.

 라. 성능테스트 수행 종료 (상세보고서)

상세보고서 화면에서는 TPS, 평균 테스트 시간, 첫 바이트 평균 도달 시간 등 다양한 정보를 차트로 확인할 수 있습니다.

 

7. JMeter와 nGrinder

7-1 수행결과 비교

동일한 타겟 서버를 대상으로 process/thread 50개씩 20번 반복 총 1000회 호출하여 두 성능 테스트 툴을 비교하였습니다.

두 차트는 시간에 따른 TPS 처리량으로 비슷한 형태의 모양을 나타냅니다. 총 처리 시간은 2:13, 2:12로 거의 동일하며, 최고 TPS, 평균 TPS도 비슷한 값을 가지는 것을 확인할 수 있습니다.

7-2 JMeter 특징

- 최근까지도 꾸준한 Release

- 영문이지만 자세한 매뉴얼과 많은 검색 결과

- 다양한 프로토콜 지원

- 다양한 외부 플러그인을 사용하여 기능 확장 가능

7-3 nGrinder 특징

- 2014년 초 이후 Release 중단

- 국문으로 된 자세한 매뉴얼과 QnA 커뮤니티, 블로그 존재

- 테스트 타켓 서버 모니터링 기능

- 툴이 다소 무거운 감이 있으나, 스크립트 수정으로 세밀한 성능테스트 가능

7-4 결론

두 가지의 성능 테스트 툴을 사용하며 어떤 테스트 툴이 현재 운영중인 서비스의 성능을 테스트 하거나 새롭게 개발할 때 더 유용할지에 대해 고민하였습니다.

현재 운영하는 홈페이지에는 크게 정적 컨텐츠 위주의 페이지와 DB 사용이 많은 페이지로 나뉩니다. 두 성능테스트 툴은 각각 어떤 유형의 페이지에서 효과적일지 확인해봤으나 어떤 유형의 페이지에서든 두 툴은 비슷한 성능테스트 결과를 나타내어 페이지의 유형으로 툴을 선택하기는 어려웠습니다. 그리하여 성능테스트 툴의 결과 외적으로 사용하고 싶은 툴을 선택하였으며 제 선택은 JMeter를 사용하는 것이 더 효과적이며 손쉽게 성능테스트를 할 수 있다고 판단하였습니다.

성능테스트 활용 후 느낀점

성능테스트 툴을 활용해보기 전 성능테스트는 특정 서비스나 사이트의 전체적인 속도를 체크하는 것이라고 생각했습니다.

제 생각과는 다르게 성능 테스트는 서비스 개발 종료시점에 실제 환경과 유사한 상태에서 성능을 테스트하여 발생할 수 있는 문제점을 개선하는 것이었습니다. 이번 기회로 성능 테스트의 필요성을 크게 느껴 추후 새로운 프로젝트나 서비스 개발 종료시점에 성능 테스트를 활용할 예정입니다.

성능 테스트 시 주의해야 할 점은 툴에서 제공하는 그래프나 통계 정보를 맹신하지 않아야 한다는 것입니다. 성능 테스트 툴은 타겟 서버에 부하를 발생시키는 도구 정도로 생각을 하고 타겟 서버의 상태를 직접 모니터링하며, 성능 테스트 툴에서 제공하는 정보를 참고하는 것이 바람직한 성능 테스트라는 생각이 들었습니다.

 

성능 TEST를 위한 보고서 전편의 콘텐츠를 살펴보고 싶다면, 아래를 클릭해주세요.

성능 TEST를 위한 보고서 1

성능 TEST를 위한 보고서 2

 

New Multi-Channel Dynamic CMS

성능 TEST를 위한 보고서 2


1. JMeter

Apache JMeter는 웹 애플리케이션처럼 클라이언트-서버 구조로 된 소프트웨어의 성능 테스트를 위해 만들어진 자바 프로그램입니다. Apache Tomcat의 테스트를 위한 코드에서 시작되어 GUI와 기능을 추가하여 지금의 JMeter가 만들어졌습니다. 원래는 웹 응용 프로그램을 테스트하기 위해 설계되었지만, 현재는 단위/성능/스트레스 테스트 등 많은 곳에서 활용할 수 있습니다. 프로토콜도 계속 추가되어 TCP, HTTP(S), FTP, JDBC, LDAP, SMTP 등 현재 범용으로 사용되는 프로토콜 대부분을 지원합니다.

 JMeter는 실행 시 마치 브라우저(또는 여러 개의 브라우저)에서 동작하는 것처럼 느껴집니다. 그러나 JMeter는 브라우저가 지원하는 모든 작업을 수행하지 않습니다. HTML 페이지에 있는 javascript를 실행하지 않고 HTML 페이지를 브라우저처럼 렌더링하지도 않습니다. 이로 인해 JMeter 툴을 이용한 성능테스트 시 응답 시간은 실제 응답 시간과 조금 차이가 날 수 있습니다.

 

2. JMeter 설치

다운로드 : http://jmeter.apache.org/download_jmeter.cgi (최신버전 다운로드)

                https://archive.apache.org/dist/jmeter/binaries/ (이전버전 다운로드)

윈도우에 설치를 원하시면 zip 파일을 받아 압축을 풀어 사용하시면 됩니다. JMeter를 실행하기 위해서는 Java 6 이상이 설치되어 있어야 합니다. (최신 버전 4.0의 경우는 Java 8 이상)

저는 현재 개발 환경이 Java 7로 설치되어 있으므로, apache-jmeter-2.13.zip을 다운로드하여 사용하였습니다.

압축을 풀고 bin 폴더 안에 있는 jmeter.bat 파일을 실행시키면 오른쪽과 같은 JMeter GUI가 실행됩니다.

JMeter는 부하 발생을 목적으로 하는 프로그램이어서 외부 웹 서버에 접속해서 테스트하면 외부 서버에 부하가 발생하거나 내부 네트워크 트래픽에 과부하를 줄 수 있으므로 사용 방법을 익히는 단계에서는 자신의 로컬에 테스트 타깃 서버를 만들어 놓고 테스트를 진행하는 것이 좋습니다.

 

3. JMeter 사용 방법

JMeter에서는 테스트 스크립트를 “Test Plan”이라고 표현합니다. 웹 서버를 테스트하기 위한 간단한 Test Plan을 만들어 보겠습니다.

- Test Plan 작성 순서

 가. Thread Group 추가 및 설정 : 가상 사용자(Thread)의 숫자와 반복 횟수, 반복 시간을 설정합니다.

 “Test Plan > add > Threads(Users) > Thread Group” 추가

Number of Threads(users) Thread 생성 개수를 의미합니다.
Ramp-up Period(in seconds) 전체 Thread가 전부 실행되는 시간을 의미합니다. 예를 들어, Thread의 개수가 5개이고 Ramp-up Period가 15초 일 경우, 첫 번째 Thread가 수행된 후 다음 Thread가 수행될 때가지 3초를 대기한다는 의미입니다.
Loop Count 각 Thread가 몇 번씩 실행할 것인지를 의미합니다. Forever를 체크 시 개수 상관없이 무한대로 실행됩니다.

위와 같은 Thread Group 설정은 10명이 10번씩 Test Plan을 반복하라는 의미로 총 100회 Test Plan을 수행합니다.

 

- Test Plan 작성 순서

 나. Config Element(HTTP Request Defaults) 추가 및 설정 : 실제 Thread가 어떤 동작을 하는지 설정합니다.

 “Thread Group > add > Config Element > HTTP Request Defaults” 추가

Server Name or IP 성능테스트를 수행할 도메인 명 또는 IP 입력합니다. (전체 URL을 입력하지 않습니다.)
Port Number 포트를 입력합니다.
Path 호출할 전체 URL에서 IP 또는 도메인 명과 Port를 제외한 나머지 URL을 입력합니다.
Send Parameters With the Request 호출한 URL에 전달할 Parameter를 설정합니다.

 

- Test Plan 작성 순서

 다. HTTP Request Sampler 추가 및 설정

 “Thread Group > add > Sampler > HTTP Request” 추가 (테스트 페이지의 개수 만큼 추가)

Path 호출할 전체 URL에서 IP 또는 도메인 명과 Port를 제외한 나머지 URL을 입력합니다.
Send Parameters With the Request 호출한 URL에 전달할 Parameter를 설정합니다.

 

- Test Plan 작성 순서

라. Listener 추가 및 설정 : Sampler의 요청에 대한 결과를 수집해서 그 결과 값을 보여주는 Element입니다. 요청을 보낸 후 성공/실패, 응답시간, 응답 메시지 등을 확인하기 위해 반드시 추가되어야 합니다.

 “Thread Group > add > Listener > View Result Tree”

 “Thread Group > add > Listener > Summary Report”

Test Plan이 모두 작성되었으므로 성능 테스트를 실행시켜보도록 하겠습니다.

제가 설정한 Test Plan은 10개의 Thread가 10번씩 수행되며 한번 수행 될 때

localhost:8080/main/main.jsp, localhost:8080/mk/main/main.jsp, localhost:8080/ml/main/main.jsp

세 도메인이 호출되므로 각 도메인당 100번의 호출. 총 300번의 테스트가 이루어집니다.

 

4. JMeter 테스트 결과 확인

가. View Result Tree

각 결과의 요청/응답을 상세하게 살펴볼 수 있는 Listener입니다.

Sampler result 해당 Sampler의 요청 결과를 보여줍니다. 성공/실패 여부를 포함해 응답시간과 크기 등을 보여줍니다.
Request 해당 Sampler가 웹 서버에 보낸 Request 정보를 볼 수 있습니다.
Response data 해당 Sampler의 요청에 대한 응답 메시지를 보여줍니다. 웹 서버로 요청을 보냈으므로 Response data는 html 문서로 출력됩니다.

 

. Summary Report

테스트 결과를 요약해서 보여줍니다. 통합된 요청량, 응답시간, 오류율, 단위 시간당 처리량 등을 확인할 수 있습니다.

 

5. JMeter 플러그인 추가

JMeter는 성능 테스트 IDE 답게 플러그인을 추가할 수 있습니다.

JMeter 플러그인은 https://jmeter-plugins.org 에서 다운로드할 수 있습니다. 저는 Response Times Over Time 이라는 테스트 결과를 차트로 제공하는 플러그인을 다운로드하여 활용해 보겠습니다. 아래 그림과 같이 플러그인을 다운로드합니다.

 

다운로드를 하고 압축을 풀면 아래 화면처럼 lib폴더가 있고 내부에 ext 폴더와 jar이 있습니다. 이 폴더와 파일을 JMeter가 설치된 폴더에 경로에 맞게 각각 넣어주시면 됩니다. 그 후 JMeter를 재실행하면 Listener에 새롭게 추가된 것을 확인할 수 있습니다.

 

시간에 따른 각 도메인별 응답 시간과 트랜잭션 처리량을 차트로 제공합니다.

 

성능 TEST를 위한 보고서 전편의 콘텐츠를 살펴보고 싶다면, 아래를 클릭해주세요.

성능 TEST를 위한 보고서 1

 

 

New Multi-Channel Dynamic CMS

성능 TEST를 위한 보고서 1

1. 성능 TEST ?

서비스 및 서비스 시스템의   성능을 확인하기 위해 실사용 환경과 비슷한 환경에서 테스트를 진행하는 것입니다.

 

2. 성능 TEST의 종류

성능테스트는 목적에 따라 다음과 같이 나뉩니다.

Load 테스트  시스템의 성능을 벤치마크 하기 위한 테스트를 의미합니다. 이 테스트는 부하(Load)를 순차적으로 증가시키면서 응답시간이 급격히 증가하거나 더는 처리량이 증가하지 않거나 시스템의 CPU와 Memory 등이 기준 값 이상으로 증가하는 등 비정상 상태가 발생하는 임계점을 찾아 이를 바탕으로 성능 이슈에 대한 튜닝과 테스트를 반복합니다.
Stress 테스트 임계값 이상의 요청이나 비정상적인 요청을 보내 비정상적인 상황의 처리 상태를 확인하고 시스템의 최고 성능 한계를 측정하기 위한 테스트를 의미합니다.
Spike 테스트 갑자기 사용자가 몰렸을 때 요청이 정상적으로 처리되는지 그리고 그 업무 부하(Workload)가 줄어들 때 정상적으로 반응하는지를 확인하기 위한 테스트를 의미합니다.

Stability 테스트 / Soak 테스트

긴 시간 동안 테스트를 진행해서 테스트 시간에 따른 시스템의 메모리 증가, 성능 정보의 변화 등을 확인하는 테스트를 의미합니다. 짧게는 한 두 시간부터 길게는 며칠 동안 진행합니다.

 

3. 성능 TEST 용어

트랜잭션(Transaction)

일정한 단위를 나타내며, 주로 업무/기능별로 트랜잭션을 정의합니다. 웹 어플리케이션에서는 주로 화면 조작을 통한 요청(Request)과 그에 대한 응답(Response) 화면을 하나의 트랜잭션으로 정의하여 사용합니다.

TPS(Transaction Per Second)

1초에 처리할 수 있는 트랜잭션의 수를 나타내며, 성능테스트의 가장 중요한 지표로 사용됩니다. 예를 들면, 성능테스트 결과 30TPS가 나오면 1초에 30개의 트랜잭션을 처리할 수 있다는 의미입니다.

응답시간(Response Time)

사용자가 요청을 보낸 시점부터 처리 결과가 사용자 PC의 화면에 보여질 때까지의 시간을 의미합니다. 웹 어플리케이션의 경우는 Network Time + Server Time + Client Time의 총합을 나타냅니다. 최근 들어 정보 기술의 발달로 인해 더욱 빠른 응답시간이 요구되므로 사용자 측면에서 뿐만 아니라 서비스 공급자 입장에서도 매우 중요한 지표입니다.

 

4. 성능 TEST 목적

성능테스트는 일반적으로 시스템 개발 종료시점에 수행하며, 응답시간과 처리량, 병목구간 등을 실제 서비스 전에 확인하여 서비스나 서비스 시스템의 문제점을 개선하는데 주로 목적을 가집니다.

 

5. 성능 TEST 기대효과

(1) 시스템 측면 : 주요 성능 결함 및 구조적 위험 우선 식별, 운영시스템 성능 최적화, 유지보수 비용  및 시스템 비용 최소화 등

(2) 사용자 측면 : 서비스의 품질 개선, 응답시간 향상을 통한 업무 효율 증대, 사용자 만족도 향상 등

 

6. 성능 TEST의 필요성

(1)  4초 Rule : 4초 이내에 응답이 오지 않으면 다른 사이트로 이동하는 습성

    -  0.5초 : 웹사이트의 첫 화면이 0.5초 안에 방문자의 눈길을 끌지 못하면 고객을 놓침  

       (2006년 지트린 가드 박사, ‘행동과 정보과학‘ 발표 논문 중)

   - 1초 : 1초 지연으로 1%의 매출 감소(아마존)

   - 3초 : 소비자가 웹사이트에 첫 인상을 갖는 시간

   - 4초 : 온라인 구매자들이 최대한 견딜 수 있는 평균 로딩시간(고객 이탈 시간)

(2)  웹 사이트의 장애로 인한 파급효과

     - 70%의 기업이미지 손상

     - 50% 매출 손실

     - 35% 장애 복구 비용

     - 22% 고객 상실

(3) 웹/인터넷을 이용하는 고객의 약 46%가 가장 즐겨찾는 Site의 문제로 인해 다른 Site로 옮긴 경험이 있으며,

      사용자의 92%가 Site 선택의 가장 중요한 요소는 안정적인 시스템. 즉 신뢰성이라고 응답 위와 같은 통계들을 통해 

      웹 성능테스트는 선택이 아닌 필수라는 것을 확인할 수 있습니다.

 

다음 시간에는 성능 TEST 에 주로 이용되는 OPEN Source 에 대해 알아 보도록 하겠습니다.

 


성능 TEST에 대한 더 자세한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

▶ 성능 TEST를 위한 보고서 2

▶ 성능 TEST를 위한 보고서 3


 

 

 

New Multi-Channel Dynamic CMS

OPEN Source를 이용한 검색엔진 개발(2)

 

지난 포스팅 OPEN Source를 이용한 검색엔진에 대한 기본적인 내용을 공유 하였고 

이번 회차에서는 검색엔진의 수집, 색인, 검색에 대한 내용에 대해 상세히 공유 하도록 하겠습니다.

 

수집 검색엔진의 목적에 맞게 사용자가 필요로 하는 정보를 준비하는 과정

 

 

- 다양한 형태로 존재하는 비정형 데이터(정보)를 필요에 따라 추출

 

        - 가장 많이 사용되는 웹 페이지 크롤링과 DBMS에 저장된 데이터를 수집하는 과정을 통해 예를 들어 설명

 

 

1.  크롤링

 

      웹 페이지를 그대로 가져와서 데이터를 추출해 내는 행위. 크롤링을 하는 소프트웨어를 크롤러라고 부름

 

   - 검색 엔진에서는 웹 상의 다양한 정보를 자동으로 검색하고 색인하기 위해 사용.

 

   - 일일이 해당 사이트의 정보를 검색하는 것이 아닌 끊임없이 새로운 웹 페이지를 찾아 종합하고 찾은 

     결과를 이용해서 또 새로운 정보를 찾아 색인을 추가하는 작업을 반복 수행

  

  

         [크롤링 흐름도]

 

     2.  Apache Nutch

         웹 사이트 크롤링을 위한 오픈 소스 웹 크롤러 소프트웨어 프로젝트

 

        -  Apache Lucene을 기반으로 만들어졌기 때문에 독립적으로 수집, 색인, 검색 가능 하고 하지만 

        특수한 데이터 수집과 다양한 검색을 활용하기 위해 Solr를 함께 사용

     Nutch Crawler Architecture

     - Crawler는 페이지를 수집하고 페이지에 대한 index를 만들고 Searcher는 유저의 요청을 받아서 

       필요한 정보를 찾아 보여주는 역할

가.   Segment Crawler에 의해 수집되고 인덱스된 페이지의 모음

나.   Fetch list segment로부터 추출한 URL 목록

다.   Index – 가져온 모든 페이지를 색인화 한 것으로 각각의 세그먼트 색인들을 병합

     (1) 수집이 최초로 시작될 seed URL 설정

     (2) 새로운 segment로부터 fetchlist를 생성

     (3) Fetchlist의 URL로부터 Page를 수집

     (4) 수집된 Page로부터 링크를 얻어옴

     (5) 2~4단계 반복

     (6) 중요도와 link정보를 update

     (7) 수집한 페이지의 색인 생성

     (8) 색인으로부터 중보된 페이지를 제거

 

[크롤로 흐름도]

 

Apache Nutch 설치

 

 - Apache Nutch 공식홈페이지 (http://nutch.apache.org) 에서 ‘apache-nutch-X.XX-bin.tar.gz’ 파일 다운로드

 

 -  설치 파일 압축 풀기

- ${APACHE_NUTCH_HOME}/conf/nutch-site.xml

 가. Nutch 프로젝트 설정 파일

 나. 반드시 ‘http.agent.name property에 값을 입력해야 실행 가능

 

 다. 그 외 크롤링 컨텐츠의 크기 제한(http.content.limit), 외부링크 개수제한(db.max.outlinks.per.page)등 설정

 

 

-  ${APACHE_NUTCH_HOME}/urls/seed.txt

   크롤링 시 검색할 첫 사이트를 설정

-  ${APACHE_NUTCH_HOME}/conf/regex-urlfilter.txt

   정규표현식을 사용해 크롤링 할 사이트를 필터링

 

Nutch 크롤링 실행 방법

- 크롤링 수행할 첫 URL 설정

  (${APACHE_NUTCH_HOME}/urls/seed.txt)

- 크롤링 실행

 

  (${APACHE_NUTCH_HOME}/bin/crawl urls/seed.txt [생성될 크롤링 디렉토리명] [반복횟수])

   - 세그먼트 확인

 

     (${APACHE_NUTCH_HOME}/bin/crawl urls/seed.txt [생성될 크롤링 디렉토리명] [반복횟수])

 

 3. Apache Solr

     Http 요청에 대한 처리와 응답을 하는 웹 기반 검색엔진

- Apache Lucene을 기반으로 만들어져 색인과 검색은 Lucene 엔진을 사용

-  기본적인 UI를 제공하고 독립적인 서버로 구현되어 있기 때문에 사용에 용이

 

Apache Solr 설치

 -  Apache Solr 공식홈페이지 (http://lucene.apache.org/solr/) 에서 ‘solr-X.X.X.tar’ 파일 다운로드

-  설치 파일 압축 풀기

 

-  실행

 

Solr Dataimport 실행 방법

     -  JDBC 라이브러리 추가 ( ${APACHE_SOLR_HOME}/server/lib/ )

   - 설정 파일에 Dataimport Handler 추가 ( ${APACHE_SOLR_HOME}/server/solr/[Core]/conf/solrconfig.xml)

    -  data-config.xml 작성

    (solrconfig.xml 파일의 경로에 생성 ${APACHE_SOLR_HOME}/server/solr/[Core]/conf/data-config.xml)

   - managed-schema 파일에 검색 필드 설정

 

    (${APACHE_SOLR_HOME}/server/solr/[Core]/conf/managed-schema)

 

 

  색인

  1.  역색인 - 검색 키워드가 주어졌을 때에 어떠한 문서에서 나타났는지를 알려주는 자료구조

특정 주제를 대상으로 매핑하는 색인(Index)와 반대되는 개념으로 역색인(Inverted Index)는 의미가 있는

  단어를 기준으로 매핑

 

- 이러한 이유로 Full Text Search에 훨씬 유리하고 빠름

 [색인]

 [역색인]

 

2. 형태소 분석 - 검색에 최적화된 색인파일을 만들기 위한 색인어 추출방식 중 문장의 

   의미를 가지는 최소단위로 분리하는 과정 (Tokenizer + Filter)

 

Solr에서 기본으로 제공되는 형태소 분석기는 한글 형태소 분석기는 없으므로 따로 추가해주어야 함

[색인과정]

 

  형태 분석기 추가

 

 - 아리랑 형태소 분석기 다운로드

 

   http://osasf.net/uploads/sw/arirang.lucene-analyzer-6.2-1.1.0.jar

 

   http://osasf.net/uploads/sw/arirang-morph-1.1.0.jar

 

 - Solr 서버에 형태소 분석기 추가

 

  ( ${APACHE_SOLR_HOME}/server/solr-webapp/webapp/WEB-INF/lib/ 경로에 다운로드 받은 분석기 업로드 )

 

 - 색인이 필요한 필드에 타입 설정

 

   ( ${APACHE_SOLR_HOME}/server/solr/[Core]/conf/managed-schema )

 

 3.  색인 예제

    Nutch 크롤링 데이터 색인

- Nutch 크롤러와 Solr 연동하여 데이터 색인

  ( ${APACHE_NUTCH_HOME}/bin/nutch solrindex [솔라 서버 URL/[core ]] [디렉토리명/crawldb] -linkdb [디렉토리명/linkdb] [디렉토리명/segments/*] )

    -  Solr Dataimport 색인

 

    (Solr 서버 -> Core 선택 -> Dataimport > Excute ) 

  

 

 검색

 

   1.  Solr를 활용한 기본 검색 방법 (URL 호출)

 

 Parameter

Default 

설명 

 Q

 -

 검색 쿼리

 Ex) q=필드명:검색할 Term

 [Solr 서버 주소]/[Core]/select?q=column_doc:시간

 Start

 0

 검색된 결과 리스트의 시작점

 rows

 10

 검색된 결과 리스트의 수

 Fl

 -

 결과값에 반환 될 필드

 Ex) fl=필드명1,필드명2,.

 [Solr 서버 주소]/[Core]/select?   q=*:*&column_doc,menu_nm

 fq

 -

 결과 내 검색(AND 조건)

 Ex) fq=필드명:검색할 Term

 [Solr 서버 주소]/[Core]/select?q=column_doc:
 시간 &fq=column_doc:정보

 Sort

 -

 오름/내림차순으로 검색할 필드 지정

 Ex) sort=필드명1 (ASC|DESC),필드명2 (ASC|DESC)

 [Solr 서버 주소]/[Core]/select?q=*:*&sort=column_doc   DESC,menu_nm ASC

 wt

 Xml

 반환된 결과 표출 타입(json, csv, xml )

 Ex) wt=json

 Hl

 

 반환된 결과에 검색어 강조 표시 여부

 Ex) hl=true

 Hl.fl

 

 강조 표시를 나타낼 필드 설정

 Ex) hl.fl=column_doc

 Hi.simple.post
Hl.simple.pre

 <em>
</em>

 매칭되는 검색어 앞, 뒤로 삽입할 태그 지정

 Ex) hl.simple.pre=<em>&hl.simple.post=</em>

 

 

     2.  Solr를 활용한 기본 검색 방법 (Java 라이브러리)   

 

 

지금까지 검색엔진의 주요 수집, 색인, 검색에 대한 주요 내용 및 OpenSource를 이용하여 

개발 하는 방법에 대해 알아 보았습니다

 


Open Source 검색 엔진 개발 1편에 대한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

▶ OPEN Source를 이용한 검색엔진 개발(1)


 

New Multi-Channel Dynamic CMS

OPEN Source를 이용한 검색엔진 개발(1)

OPEN Source를 이용하여 자체적으로 검색엔진을 개발한 내용입니다

검색엔진 제작을 위한 개요 부분과 수집, 색인, 검색에 대한 내용으로 2번에 걸쳐 내용을 공유하도록 하겠습니다

 

 

검색엔진이란?  

용자가 필요로 하는 정보를 수집하여 내용을 분석한 뒤 찾기 쉬운 형태로 조직하여(색인), 정보에 대한 요구가 발생할 때 해당 정보를 빠르게 찾아 제공(검색)하는 시스템이나 프로그램

 

검색엔진의 구조

 

1. 수집: 검색엔진의 목적에 맞게 사용자가 필요로 하는 정보를 준비하는 과정

    - 대부분의 오픈소스 검색엔진 솔루션에서는 DB, File(doc, xls, pdf ), Log에 존재하는 데이터를 

      수집하는 기능을 제공

    - Web page의 경우는 크롤링을 이용

2. 색인: 수집된 내용을 분석하여 특정 데이터를 빠르게 찾을 수 있도록 저장하는 과정

   - 형태소 분석을 통해 최소 단위의 의미 있는 단어(Term) 추출

   - 역색인(Inverted Index) 방식으로 데이터를 저장

 

                i.  대용량 텍스트 검색을 위해서 고안된 방법

 

               ii.  특정 주제를 대상으로 매핑하는 색인과 반대되는 개념으로 의미가 있는 단어를 기준으로 매핑

 

              iii.  역색인 방식이 Full Text Search에 훨씬 유리하고 빠름

    - 형태소 분석(의미를 가지는 최소 단위를 분리하는 과정 (Tokenizer +Filter))

     

구분 

RDBMS 

검색엔진

 데이터 저장 방식

정규화

역정규화

 전문(Full Text) 검색 속도

느림

 빠름

 의미 검색

 불가능

 가능

 JOIN

 가능

 불가능

 수정 / 삭제 속도

 빠름

 느림

 

3. 검색: 사용자로부터 검색 요청을 받아 검색 결과를 변환하는 과정

   - 사용자가 검색 최상의 결과를 위해 랭킹 알고리즘이 중요

   - TF-IDF(Term Frequency - Inverse Document Frequency)

     i. 특정 단어가 문서 내에 얼마나 자주 등장하는 지를 나타내는 TF

     ii. 특정 단어가 전체 문서에서 얼마나 자주 등장하는지(흔한지)를 나타내는 IDF

 

검색엔진 개발을 위한 Open Source

1. Apache Lucene

   - 색인과 검색 기능을 제공하는 자바 언어로 만들어진 오픈소스 정보검색(Information Retrieval)* 라이브러리임

   - 독립된 프로그램이 아닌 소프트웨어 라이브러리로 Lucene 라이브러리만을 사용해 검색 서비스를 

     구현하기 위해선 추가적인 개발이 필요

 

2. Apache Solr, Elasticsearch

   - Apache Lucene 기반으로 검색 서비스를 위한 다양한 기능들이 포함되어 만들어진 오픈소스 검색엔진 솔루션

   - HTTP 요청에 대한 처리와 응답을 하는 웹 기반

   - 기본적인 UI를 제공하고 독립적인 서버로 구현되어 있기 때문에 사용에 용이

 

 구분

 Apche Solr

 Elasticsearch

 주요 활용영역

 문서 원문 검색

 상품 검색 / 이상징후 감지 

 & 모니터링

 색인방식

 전체 데이터를 수정

 수정된 데이터만을 수정

 검색 속도

 느림

 빠름

 색인 속도

 느림

 빠름

 장점

 안정화된 오픈소스 

 장문 데이터 검색에 용이

 실시간 색인 가능

 검색, 색인 속도가 상대적으로 빠름

 단점

 검색, 색인 속도가 상대적으로 느림

 장문 데이터 검색 시 속도 저하

 

3. Apache Nutch

   - Apache Lucene 기반으로 만들어진 웹 크롤러 솔루션

   - 독립적으로 수집, 색인, 검색 기능

   - Solr나 Elasticsearch와 같이 UI를 제공하지 않고 검색 기능도 다양하지 못해 주로 웹 페이지 

     크롤링을 목적으로 사용

 

일반적인 검색엔진 서버 구성

 

검색엔진 자체 개발을 위한 기본 개념적 설명이며, 수집, 색인, 검색 부분에 대해 

다음편에서 조금 더 상세히 공유하도록 하겠습니다. 


Open Source 검색 엔진 개발에 대한 더 자세한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

▶ OPEN Source를 이용한 검색엔진 개발(2)


 

 

 

 

New Multi-Channel Dynamic CMS

java10 및 서블릿 jsp 어플리케이션 구조

java10

오라클이 3 20 Java SE 10(JDK 10) GA(general availability)를 발표했다. JDK 10은 자바 커뮤니티 프로세스 내 JSR 383에 명시된 대로 자바 SE 10 플랫폼의 상용 가능한 구현입니다.

2018 3 20일 발표. 일반 지원은 2018 9월에 종료될 예정이다. var 키워드를 이용한 지역 변수 타입 추론, 병렬 처리 가비지 컬렉션, 개별 쓰레드로 분리된 Stop-The-World, 루트 CA 목록 등이 추가되었다. 또한 JDK의 레포지토리가 하나로 통합되었으며, JVM 힙 영역을 시스템 메모리가 아닌 다른 종류의 메모리에도 할당할 수 있게 되었다. 실험 기능으로 Java 기반의 JIT 컴파일러가 추가되었고, 이전 버전에서 Deprecated 처리된 API Java SE 10에서 모두 삭제되었습니다.

jdk 릴리스에 대한 자세한 내용은  https://blogs.oracle.com/java-platform-group/introducing-java-se-10  블로그를 참조하면 되며 블로그에 명시된 명세서를 기반으로 작성해 봤습니다.

 

1. JEP 286: Local-Variable Type Inference

java 10의 변화 중 코드 측면에서 가장 흥미로운 점을 하나 고르라면 당연 Local Variable Type Inference 입니다. 로컬변수 선언을 var 를 이용하여 기존의 엄격한 타입 선언 방식에서 탈피하여 컴파일러에게 타입을 추론하게 할 수 있습니다. 기존에 lombok에서 제공하는 val/var 기능을 사용하고 계셨다면 크게 생소하진 않을 내용입니다.

Local Variable Type Inference는 다음과 같은 상황에서만 사용할 수 있습니다

초기화된 로컬 변수 선언 시

반복문에서 지역변수 선언 시 (enhanced for loop 포함)

Java 9에서 등장한 jshell를 이용하면 쉽게 테스트할 수 있습니다.

2. JEP 296: Consolidate the JDK Forest into a Single Repository

개발을 단순화하고 간소화하기 위해 JDK 포리스트의 수많은 리포지토리를 단일 리포지토리에 결합합니다.


3. JEP 204) 가비지 컬렉터 인터페이스 

GC (garbage collector) 인터페이스를 도입하여 다양한 가비지 콜렉터의 소스 코드 분리할 수 있도록 개선시켰습니다.


4. JEP 307: Parallel Full GC for G1

Java 9에서 default Garbage Collector G1 full GC를 피하도록 설계되었지만, concurrent GC에서 충분한 young area를 확보하지 못하면 full GC가 발생합니다. 기존 G1에서 full GC를 수행할 때 싱글 쓰레드 방식으로 동작하는 mark-sweep-compact 알고리즘을 사용하였습니다. G1 이전의 default 였던 parallel collector 처럼 G1에서도 full GC를 병렬화 시켜 G1의 최악의 케이스에서 지연 시간을 개선시켰습니다.


5. JEP 310: Application Class-Data Sharing

기존의 Class-Data Sharing(CDS) 기능을 확장해 애플리케이션 클래스를 공유 아카이브에 배치하고 서로 다른 자바 프로세스들이 공유함할 수 있도록 개선함으로써, startup 시간을 단축시키고 메모리 사용량을 최적화 시켰습니다. 기존에 AppCDS 기능은 상업용으로 Oracle JDK에서만 제공되었으나, 오픈소스화 되어 Open JDK에도 사용할 수 있게 되었습니다.


6. JEP 312: Thread-Local Handshakes

JVM safepoint Stop the World를 의미합니다. Thread-Local Handshake는 이런 safepoint가 발생하는 지점들을 줄이기 위한 프로젝트입니다. 모든 쓰레드를 동시에 멈춰야 했던 기존과 달리 쓰레드를 개별로 멈출 수 있게 되었고, VM safepoint를 수행하지 않고도 개별 Thread에서 콜백을 실행할 수 있습니다.


7. JEP 313: Remove the Native-Header Generation Tool (javah)

${JAVA_HOME}/bin 디렉터리 안에는 JDK에서 제공하는 수많은 툴들이 존재합니다. javah는 그 중에 하나로, 코드에 native 메서드들을 사용할 경우 JNI 헤더 파일들을 생성해줍니다. Java 8부터 javac에서 JNI 헤더 파일 생성을 지원하기 때문에 javah이 더 이상 필요하지 않아 제거되었습니다.


8. (JEP 314) 추가 유니 코드 언어

태그 확장 : BCP 47 언어 태그의 추가 유니 코드 확장을 구현하기 위해 java.util.Locale 및 관련 API를 향상시킵니다.


9. (JEP 316) 대체 메모리 장치의 힙 할당

HotSpot VM Java 객체 힙을 사용자가 지정한 대체 메모리 장치 ( : NV-DIMM)에 할당 할 수 있도록합니다.


10. (JEP 317) 실험적인 Java 기반 JIT 컴파일러

Java 기반 JIT 컴파일러 Graal Linux / x64 플랫폼에서 시험용 JIT 컴파일러로 사용할 수 있습니다.


11. (JEP 319) Root Certificates

JDK에서 루트 인증서 CA (Certificate Authority) 인증서의 기본 세트를 제공합니다.


12. (JEP 322) 시간 기반 릴리스 버전 관리

현재 및 미래의 시간 기반 릴리스 모델에 대한 Java SE Platform JDK의 버전 문자열 스키마와 관련 버전 정보를 개정합니다.


서블릿/jsp 어플리케이션 구조

 

1. Servlet(서블릿)

서블릿을 한줄로 정의하자면 아래와 같이 정의할 수 있습니다.

웹프로그래밍에서 클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그래밍 기술


[ Servlet 특징 ]

클라이언트의 요청에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트

html을 사용하여 요청에 응답한다.

Java Thread를 이용하여 동작한다.

MVC 패턴에서 Controller로 이용된다.

HTTP 프로토콜 서비스를 지원하는 javax.servlet.http.HttpServlet 클래스를 상속받는다. UDP보다 속도가 느리다.

HTML 변경 시 Servlet을 재컴파일해야 하는 단점이 있다.

일반적으로 웹서버는 정적인 페이지만을 제공합니다. 그렇기에 동적인 페이지를 제공하기 위해서 웹서버는 다른 곳에 도움을 요청하여 동적인 페이지를 작성해야 합니다. 동적인 페이지로는 임의의 이미지만을 보여주는 페이지와 같이 사용자가 요청한 시점에 페이지를 생성해서 전달해 주는 것을 의미합니다. 여기서 웹서버가 동적인 페이지를 제공할 수 있도록 도와주는 어플리케이션이 서블릿이며, 동적인 페이지를 생성하는 어플리케이션이 CGI입니다.

JSP 특징

->빈즈(Beans)라고 하는 자바 컴포넌트를 사용할 수 있다.

->최초 서블릿으로 컴파일된 후에 메로리에서 처리되기 때문에 많은 사용자가 접속도 원할히 할 수 있다.

->JSP 또는 다른 서블릿간의 데이터 공유가 쉽다.(page, request, session, application, scope)

-> 자바의 모든 기능을 사용 할 수 있다.

 

JSP의 동작원리

기존 html 동작

기존의 HTML을 사용할 시 사용자가 특정 도메인 주소로 접속을 시도 하면, DNS 서버에서 IP주소를 반환 받아해당 포트로 접속을 시도하고 DocumentRoot로 설정된 디렉토리에서 index.html파일을 읽는다

 

JSP 구성과 흐름도

특정 도메인 주소로 접속을 시도하고 IP를 받은 후, 80포트로 접속을 시도한다.

웹 서버는 요청내용을 분석하고, 서블릿 컨테이너에게 요청을 넘긴다.

그리고 서블릿 컨테이너에서 JSP 파일에 해당하는 서블릿이 있는지 확인하고, 없을 경우 JSP 파일을 서블릿으로 컴파일한다. 컴파일된 JSP는 서블릿으로 변환되어 컨테이너에 적재된다.

서블릿 내용 중 데이터베이스 처리 부분이 있으면, 데이터베이스에서 데이터를 가져온다.

화면에 보일 내용을 정리해서 HTML 문서 형태로 클라이언트에 재 전송한다웹브라우저는 웹 서버에서 보낸 텍스트 내용 중 HTML 태그를 분석해서 적절히 변환하여 화면에 보여준다.


New Multi-Channel Dynamic CMS

오라클 자바 라이선스 정책 변경 이슈

1. 자바 유료화?

지난 6월 오라클의 자바 SE 서브스크립션모델 발표 이후로 현재까지 자바 유료화에 대한 많은 논쟁이 있었다. 관련하여 IT관련 기사와 커뮤니티, 오라클 OTN 등을 검색하면서 알게 된 내용들을 정리하여 공유하고자 한다.

일단, 자바라는 언어는 GPL라이선스로 무료이다다만 오라클이 제공하는 자바 SE는 사용목적에 따라 달라진다. 일반적인 목적의 컴퓨팅에선 무료이나 상업용, 업무용등 상업 목적인 경우는 별도의 라이선스가 필요하다. 또한 내장 장치에 JRE를 사용하거나 상용 기능을 사용 하려면 Oracle로부터 라이센스 비용이 필요하다.

그렇다면 상용기능은 어떤 것이 있는지 살펴보자

Java SE Advanced Java SE Suite에는 다음과 같은 상용기능이 포함되어 있다.

 Java Flight Recorder

 Java Flight Recorder (JFR)는 실행중인 Java 응용 프로그램에 대한 데이터를 수집, 진단 및 프로파일링하기 위한 도구이다.

내부 JVM 후크(hook)를 사용하여 동작할 수 있도록 설계되었다. Flight Recorder가 캡처한 이벤트는 메모리 할당, 쓰레드 상태 변경, IO 동작, CPU 동작을 포함한다.

 Java Mission Control

 JMC는 효율적이고 상세한 데이터 분석을 가능하게 해주는 고급 도구 모음으로 고급 Java 모니터링 및 관리 기능을 제공한다. JMC는 코드 성능, 메모리 및 대기 시간과 같은 일반적인 분석 영역에 대한 섹션을 제공한다.

 Advanced Management Console

 엔터프라이즈에서 사용되는 Java 응용 프로그램 및 Java Runtime Environment 버전을 관리하는 시스템 관리자를 위한 기능.

 Java SE Enterprise Installer

 Microsoft Windows Installer (MSI) Enterprise JRE 설치 프로그램을 사용하여 Windows에서 Java Runtime Environment를 설치 및 설치 제거하는데 필요한 기능.

 Java Usage Tracker

 Java Usage Tracker Oracle Java SE Advanced Oracle Java SE Suite Java Runtime Environment (JRE)가 시스템에서 어떻게 사용되고 있는지를 추적한다

다음으로 보다 확실한 오라클의 공지내용을 확인하기 위해 Oracle Java SE 8을 설치해 보았다.

그러면 아래 그림과 같은 안내 문구가 나온다.

링크된 추가정보를 클릭해보니 ( https://www.java.com/ko/download/release_notice.jsp )

“Oracle Java SE 8에 대한 공용 업데이트는 최소한 2020년 말일까지 개인용으로 계속 사용할 수 있습니다. 2019 1월 이후 릴리스되는 Oracle Java SE 8에 대한 공용 업데이트의 경우 상용 라이센스 없이는 업무용, 상업용 또는 운용용으로 사용할 수 없습니다.” 라고 명시돼 있다.


이상으로 오라클 자바의 유.무료사용에 대한 기준들을 살펴 보았다.

다음으로는 자바 SE 서브스크립션의 혜택, 비용, 지원정책 등에 대해서 살펴보자.


2. 자바 SE 서브스크립션

혜택

기존에 제공되던 상용 제품, Java SE Advanced, Java SE Advanced Desktop Java SE Suite 등이 Java SE 서브스크립션 모델로 변경되었다. 그리고 기존 영구 라이선스는 구매 시 기술지원 및 유지보수 옵션을 연단위로 별도 구매했지만, 자바 SE 서브스크립션은 라이선스, 프로그램 업데이트 및 기술지원 등의 혜택이 모두 포함돼 있다.

자바 SE 서브스크립션의 혜택 범위는 다음과 같다.

l  클라우드, 서버 및 데스크톱 배포에 대한 Oracle Java SE 라이센스 및 지원

l  성능, 안정성 및 보안 업데이트에 대한 지원

l  공개 업데이트가 끝난 일부 자바 SE 버전 지원

l  오라클 자바 SE8 7 엔터프라이즈 관리 모니터링 및 배포 기능

l  마이 오라클 서포트를 통한 24시간 지원

l  공개적으로 사용 가능한 릴리스에 포함되기 전에 치명적인 버그 수정에 대한 지원

비용

서브스크립션 모델은 자바 SE 서브스크립션과 자바 SE 데스크톱 서브스크립션으로 나뉘며 서브스크립션 모델 이용 가격은 자바 SE 서브스크립션의 경우 100개 미만 프로세서당 월 25달러이며, 데스크톱 가격은 1000명 미만 사용자당 월 2.5달러에서 시작한다. 구매 볼륨별 할인이 적용되며, 1·2·3년 단위로 구매할 수 있다.

예를 들어보자. JAVA SE SUBSCRIPTION PRICING 인 경우 Processor 기준이다.

오라클에는 Oracle Processor Core Factor Table 을 기준으로 라이센싱 인수가 붙는다. SPARC T3 processor 라면 0.25 를 곱해줘야 한다. 6 core 라면 ( 0.25 * 6 = 1.5 )이므로 2개의 프로세서 라이선스가 필요하다. 또 다른 예를 들면 10개의 코어가 설치된 Oracle Processor Core Factor Table 에 명시되지 않은 하드웨어 플랫폼용 멀티코어서버에는 10개의 프로세서 라이선스가 필요한 것이다.

아래는 오라클 홈페이지에 있는  가격표이다.


Java SE Desktop Subscription Pricing

Volume

 Subscription Metric

 Monthly Subscription Price

 1-999

 Named User Plus

 $2.50

 1,000-2,999

 Named User Plus

 $2.00

 3,000-9,999

 Named User Plus

 $1.75

 10,000-19,999

 Named User Plus

 $1.50

 20,000-49,999

 Named User Plus

 $1.25

 50,000+

 Contact for details

 


Java SE Subscription Pricing

Volume

 Subscription Metric

 Monthly Subscription Price

 1-99

 Processor

 $25.00

 100-249

 Processor

 $23.75

 250-499

 Processor

 $22.50

 500-999

 Processor

 $20.00

 1,000-2,999

 Processor

 $17.50

 3,000-9,999

 Processor

 $15.00

 10,000-19,999

 Processor

 $12.50

 20,000+

 Contact for details

 


구독한 라이센스 기간이 종료되면?

사용자는 사용 권리를 잃어버린다. 라이센스를 갱신하거나 다른 무료 OpenJDK 바이너리로 전환해야 한다.


자바를 무료로 사용하고 싶다면?

자바 SE 라이선스를 구매하지 않을 경우 오픈소스 기반의 OpenJDK를 활용하면 자바를 무료로 이용할 수 있다. 자바11 이상부터 오라클 JDK는 유상으로만 공개되며, 대신 자바11에서 오라클 JDK와 동일한 기능을 갖춘 오픈소스 기반 오픈JDK 바이너리가 무료로 제공될 예정이다.


JDK 업데이트 및 지원 정책

JDK 버전업은 메이저 버전업과 마이너 버전업으로 구성된다. 메이저 버전업이 진행되면 이전 버전에 대한 마이너 버전업은 중단된다. 메이저 버전업의 주기는 6개월로 JDK 기능이 추가 및 변경된다. 마이너 버전업은 버그 수정 및 보안 패치만 적용된다. 기술지원 정책은 각 JDK별로 다르게 적용된다. 9월 등장할 자바11부터 오라클 JDK 3년마다 장기지원(LTS)에 대응한 메이저 버전이 등장할 예정이다. 유료 사용자는 최대 8년동안 LTS 업데이트를 할 수 있다


Java SE 공개 업데이트

해제 

 조지아 협약날짜

공개업데이트 

알림의 끝 

 상용 사용자 

최종 업데이트

 개인 사용자 

최종 공개 업데이트

 7

 2011 7

 2014 3

 2015 4

 8

 2014 3

 2017 9

 2019 1  ****

 2020 12  ****

 9(비 LTS)

 2017 9

 2017 9

 2018 3

 10(18.3 ^ ) ( LTS)

 2018 3

 2018 3

 2018 9

 11이상

 더 이상 적용 할 수  없음


Oracle Java SE 지원 로드맵 

해제 

 조지아 협약날짜

프리미엄 지원

 연장 지원

 지속적인 지원

 6

 2006 12

 2015 12

 2018 12

 무기한

 7

 2011 7

 2019 7

 2022 7

 무기한

 8

 2014 3

 2022 3

 2025 3

 무기한

 9 ( LTS)

 2017 9

 2018 3

 사용 불가

 무기한

 10 (18.3 ^ ) ( LTS)

 2018 3

 2018 9

 사용 불가

 무기한

 11 (18.9 ^ LTS)

 2018 9 ***

 2023 9

 2026 9

 무기한

 12 (19.3 ^  LTS)

 2019 3 ***

 2019 9

 사용 불가

 무기한


3. 무료 사용을 위한 OpenJDK

JDK JVM을 제공하는 OpenJDKGPL v2 with the Classpath Exception 라이센스로 무료이다. 자바 스펙을 명시한 JSR 336, JSR 337를 빠짐없이 완전히 구현한 구현체이다.

OpenJDK 운영 주체인 오라클 또한 OpenJDK를 기반으로 자사의 부가적인 기능을 추가한 Oracle JDK를 제작하여 배포한다. 또한 오라클은 OpenJDK를 오라클 JDK와 기능 측면에서 같은 수준으로 만들겠다는 계획을 가지고 있으며 작업은 9월 완료 예정이라고 한다.

만약 오라클이 아닌 서드파티 업체가 OpenJDK를 기반으로 공인된 JDK를 제작하여 배포하려면 오라클의 유료 라이센스인 OCTLA(OpenJDK Community TCK License Agreement)에 가입해야 한다. 현재 전세계에 여러 업체가 가입되어 있다이 업체들이 OpenJDK 기반의 자체 빌드를 배포하려면 오라클의 엄격한 TCK 인증을 통과해야 한다.

OpenJDK   Windows 버전이 존재한다. 공식 사이트( http://jdk.java.net/ )에서 무료로 다운로드 가능하다. 또한, 특정 개인이나 단체가 OpenJDK 소스를 빌드하여 다운로드 할 수 있도록 링크를 제공한다.( https://adoptopenjdk.net ).

참고로 OpenJDK 사용시 JVM 위에서 수행되는 코드는 공개할 의무가 없다고 한다. JVM 자체는 GPL 2.0 라이선스를 따르지만, 외부 연동을 위한 API들은 Classpath Exception 라이선스가 적용되기 때문이다.


4. 다른 JDK 벤더

OpenJDK를 멀티 플랫폼 바이너리로 빌드하여 배포하는 대표적인 업체로는 Azul Systems가 있다. 개발 환경과 운영 환경 모두 Oracle JDK의 대안으로 좋은 평가를 받고 있다

Azul Systems(미국 소재의 Java Runtime 제작 전문 회사) Zulu라는 OpenJDK 기반 빌드에 부가 기능을 추가한 WindowsLinuxMac OS X 바이너리를 무료로 제공한다. 이 회사는 서버 부하에 최적화된 Zing이라는 JVM을 판매한다. 엔터프라이즈 시장에서 Oracle JDK의 대안으로는 현재 독보적 위치에 있다.

Zulu 의 라이센스 정책은 크게 두가지로 나뉘는데, 개인이나 기업 모두 Zulu 을 사용하는 것은 무료이고, 기술지원(Subscription)은 유료로 구입이 가능하다. 참고로 같은 회사에서 개발하여 판매되는 Zing OracleJDK 와 마찬가지로 상용으로만 판매된다.

참고로 Zing 가격은 1-10 수량인 경우 프리미엄 지원 포함한 연간 구독 가격이 서버( physical or virtual ) $3,500 USD 이며 Zulu Enterprise 가격은 아래와 같다.

 Max # of Supported Systems

 Price/Year (Standard Support)

 Price/Year (Premium Support)

 25

 $13,200

 Not available

 100

 $31,600

 $37,900

 1000

 $94,900

 $113,900

 Unlimited

 $284,600

 $341,500

Zulu 이외에도 현재 사용 가능한 JVM 의 수는 훨씬 다양하다.

( https://en.wikipedia.org/wiki/List_of_Java_virtual_machines )


5. 오라클 자바 유료화에 대한 대응

먼저 유료화 대상이 될 수 있는 시스템의 규모 파악부터 필요해 보인다.

상용기능을 쓰고 있는지 유료화 대상 버전인지를 구분하고 오라클의 지원을 받기 원한다면 오라클 JAVA SE Subscription 에 따른 예산을 책정 해야 할 것이다. 만약 무료 OpenJDK를 사용하려면 기존 솔루션이나 서비스 등이 정상 작동하며 호환이 되는지 확인하는 과정이 필요하겠다.

또 다른 대안으로는 Azul Systems 의 무료 JDKZulu를 사용하거나 유료이지만 평가가 좋은 Zing이라는 JVM을 사용하는 것도 고려해야 할 대상이다.

참고로 표준프레임워크 포털에 게시된 답변에도 OpenJDK에 대한 언급이 있다.

표준프레임워크 최신 버전인 3.7 OpenJDK와의 호환성 제공 하고 있으며 표준프레임워크 최신 버전인 3.7의 사용을 권장한다고 답하고 있다.


6. 맺음

설마 설마 했던 오라클 JDK 유료화가 라이선스 모델 변경으로 가시화 됐다.

개인 사용자는 상관없지만 기업들을 상대하는 개발자 혹은 개발업체 입장에서는 우려가 되는게 사실이다.

OpenJDK는 오라클 JDK와 상호 호환된다고는 하나 기존 자바로 된 솔루션들에 대한 OpenJDK 환경에서의 확인이 필요 할 듯 하다.


참고사이트

https://www.oracle.com/java/java-se-subscription.html

https://docs.oracle.com/javacomponents/index.html

https://www.java.com/ko/download/release_notice.jsp

http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf

http://www.oracle.com/technetwork/java/javase/overview/index.html

http://www.oracle.com/technetwork/java/javase/eol-135779.html

http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf?ssSourceSiteId=otnen

http://okjsp.pe.kr:8080/article/490213

https://www.azul.com/products/pricing/



New Multi-Channel Dynamic CMS