마이데이터 필수 API 솔루션 D-Bridge v2.5 GS인증 1등급 획득

 

 

사이버이메지네이션의 API 솔루션 D-Bridge가

21년 3월 2.0버전으로 GS인증 1등급 획득 후 22년 1월 18일 2.5버전으로 GS 인증 1등급을 획득 하였습니다.

 

D-Bridge는 2016년 제품 런칭 이후

API 서비스와 관련된 금융권 신규 비즈니스 “서비스 제휴 연동용 서비스” “오픈뱅킹 서비스”에 적용되어 우수성을 인정 받아 왔으며, 최근 대신증권, DB손해보험, 미래에셋캐피탈 등 다수의 금융권 마이데이터 서비스 구축 사업을 수주하고, 시책변화에 빠르게 대응하며 프로젝트를 완성하여 API 필수 솔루션으로 자리매김하고 있습니다.

 
D-Bridge는

- 인프라 구성 및 개발자 친화적 솔루션으로 서비스 확장이 수월

- 편리한 API 개발 및 API 라이프사이클 관리

- 금융, 마이데이터 보안 가이드 준수하여 보안체계 제공

- 서비스 환경 및 제도 변화에 능동적으로 대처하는 서비스 제공 등

국내 기업환경에 최적화된 API 제품으로 최대 금융권 레퍼런스를 확보하고 있으며, 재구매율이 높은 제품입니다.

 

[레퍼런스 소개]

https://solution.cyber-i.com/.../api/dbridge/reference.cmd

 

[제품활용 소개]

https://solution.cyber-i.com/products/api/dbridge/use.cmd

New Multi-Channel Dynamic CMS

시큐어 코딩 가이드 및 보안점검 도구를 통한 보안 취약점 점검 방법

목차는 아래의 순서에 따라 진행합니다.

 

1. 개요

 

2. 설계 예시

2-1 게시판 목록

2-2 게시물 조회

2-3 게시물 등록

2-4 게시물 수정

 

3. 보안 점검 도구

3-1 Burp Suite

3-2 Fiddler

3-3 Wireshark

 

-----------------------------------------------------------------------------

 

개요

 

OWASP에서 발표한 취약점 Top 10은 아래와 같습니다.

 

A1. 인젝션

A2. 취약한 인증

A3. 민감한 데이터 노출

A4. XML 외부 개체(XXE)

A5. 취약한 접근 통제

A6. 잘못된 보안 구성

A7. 크로스 사이트 스크립팅

A8. 안전하지 않은 역직렬화

A9. 알려진 취약점이 있는 구성요소 사용

A10. 불충분한 로깅 및 모니터링

 

취약한 인증, 취약한 접근 통제는 Top10 중에서도 상위권에 랭크되어 있으며. 주기적으로 발표하는 OWASP Top 10에서 항상 빠지지 않을 정도로 중요한 취약점 내용입니다.

 

  

한국인터넷진흥원에서 있는 시큐어 코딩 가이드에서도 관련된 내용을 확인할 수 있습니다.

 

쿠키 또는 Hidden 필드등의 외부입력 값이 보안기능을 수행하는 중요 파라미터로 사용되는 경우 프록시 서버에서 파라미터를 조작하여 부적절한 인가가 발생할 수 있다.

 

중요기능이나 리소스를 요청하는 경우 HTML 화면에서 기능을 안보이게 설정하여도 URL을 통해 접근할 수 있으므로 인증을 거치지 않고 처리할 경우 공격자에게 노출될 수 있다.

 

 

 

위의 코드는 인증대상 및 방식(SR2-1)에 대한 안전하지 않은 코드와 안전한 코드의 예시이다.

기능을 수행하기전에 로그인 세션 정보의 유무, 권한 체크등의 간단한 프로세스이지만, 개발자들은 기능개발을 중점적으로 두는 경향이 있어 간과할 때가 많습니다.

  

2. 설계예시

2-1. 게시판 목록

게시판 목록을 구현할 때, 필요한 보안 사항의 시퀀스 다이어그램과 체크리스트이다.

Coreframe에는 OWASP ESAPI 탑재되어 있어 인젝션, XSS 등의 취약점들은 모두 필터링되게 설계되어있어 나머지의 보안항목에 대해서만 설계하면 된다.

  

게시판 목록 로그인 여부 검증, 로그인 계정의 접근 권한 검증

접근 권한 체크가 존재하지 않아 URL을 통해 직접 접근할 경우 게시판에 접근이 가능하다.

jspx(컨트롤러단) 또는 jsp 페이지에서 선택하여 접근 권한 체크를 해주면 된다.

 

2-2 게시물 조회

게시물 조회 시엔 게시판의 유형에 따라 DB조회후에 로그인 세션 정보와 output의 파라미터 값이 적절한 값인지 체크해줘야 한다. 예를들어, 인사 정보와 같은 개인 정보를 조회 시에 파라미터 변조를 통해 다른 사용자의 정보를 조회할 수 있으므로 세션 정보와 output을 비교하도록 한다.

 

게시물 조회 로그인 여부 검증, 로그인 계정의 접근 권한 검증

접근 권한 체크가 존재하지 않아 URL을 통해 직접 접근할 경우 게시물에 접근이 가능하다.

jspx(컨트롤러단) 또는 jsp 페이지에서 선택하여 접근 권한 체크를 해주면 된다.

 

게시물 조회 output이 정상적인지 검증

DB에서 데이터 조회 후에 output에 대한 검증 없이 파라미터를 set하기 때문에 파라미터 변조 시 다른 사용자의 정보에 접근할 수 있다.

로그인 체크와 세션정보와 output의 비교 체크를 추가하여 타 사용자의 정보에 접근을 막는다.

 

2-3. 게시물 등록

 

 

게시물 등록 시엔 등록 페이지 접근 시, 등록 버튼 클릭 시에 접근 권한 체크를 해줘야 한다.

 

게시물 등록 로그인 여부 검증, 로그인 계정의 접근 권한 검증(페이지 이동)

게시물 등록 - 로그인 여부 검증, 로그인 계정의 접근 권한 검증(버튼 클릭)

ajax 전송방식은 POST를 해야함(GET방식으로 전송 시 URL에 데이터 노출)

에러 처리가 존재하지 않아 접근 권한이 없는 사용자가 등록을 시도해도 처리할 수가 없다.

 

 

 

2-4. 게시물 수정

게시판 수정 페이지 접근 시 파라미터 변조를 통해 타 사용자의 게시물의 수정 페이지에 접근하여 정보를 확인하고 무단으로 수정을 할 수 있으므로 로그인 세션 정보와 output을 비교하여 검증해야 한다.

 

게시물 수정 로그인 여부 검증, 로그인 계정의 접근 권한 검증(페이지 이동)

DB조회 후 output에 대한 검증이 존재하지 않아 파라미터(게시물 번호) 변조를 통해 타 사용자의 게시물에 접근 가능하다.

 게시물 수정 로그인 여부 검증, 로그인 계정의 접근 권한 검증(페이지 이동)

 

3. 보안 점검 도구

1. Burp Suite

웹 동작 시 클라이언트와 서버 사이에 프록시 서버를 구축하여 패킷을 프록시 서버를 거치게 하여 중간에서 패킷을 확인하거나 변조하여 서버에 패킷을 전달해주는 프록시 도구

 

사용법

2. Fiddler

웹 동작 시 클라이언트와 서버 사이에 프록시 서버를 구축하여 패킷을 프록시 서버를 거치게 하여 중간에서 패킷을 확인하거나 변조하여 서버에 패킷을 전달해주는 프록시 도구

 

사용법

 

* 필터링

 

* 파라미터 변조

 

3. Wireshark

네트워크 트래픽을 캡쳐하여 패킷을 분석하여 모의해킹, 취약점 분석등의 쓰이는 네트워크 분석 프로그램이다.

 

사용법

 

* No. : 패킷을 수집한 순서

* Time : 패킷을 수집한 시간

* Source : 패킷을 보낸 주소

* Destination : 패킷 도착 주소

* Protocol : 프로토콜 정보

* Length : 패킷의 길이

* Info : 패킷 정보

와이어 샤크를 통해 패킷을 캡처하게 되면 수많은 패킷들이 캡처되기 때문에 Statistics(통계)를 사용하여 요약된 정보를 통해 패킷을 분석해야 한다.

대표적으로 쓰이는 4가지 통계 자료를 살펴보도록 하겠습니다.

 

* Protocol Hierachy 프로토콜에 관련된 통계 자료를 확인할 수 있다.

 * Conversation 출발지 IP, 도착지 IP, 크기, 시간등 IP에 대한 정보를 확인할 수 있다.

 

* Packet Counter HTTP 상태 코드에 대한 통계 정보를 확인할 수 있다.

 

 * Requests Request에 응답한 페이지의 목록을 확인할 수 있다.

 

Statistics를 이용하여 대략적인 패킷의 분석이 끝났으면 필터링과 Stream을 통해 자세한 내용을 확인하면 된다.

 

* 필터링 필터링을 통해 원하는 패킷만을 추출하여 확인할 수 있다.

 

 * Stream- 패킷의 데이터를 조합하여 볼 수 있다(파일로 저장 가능)

 

 

감사합니다.

 

 

New Multi-Channel Dynamic CMS

사이버이메지네이션 API 솔루션 ‘D-Bridge2.0’ GS인증 1등급 획득

 

안녕하세요.

 

이번 글은 사이버이메지네이션의 API 솔루션 제품인 ‘D-Bridge2.0’ GS인증 1등급 획득 소식을 전하고자 합니다.

 

GS인증은 한국정보통신기술협회(TTA)가 국내 소프트웨어의 완성도를 평가하기 위해 마련한 제도로 D-Bridge가 취득한 1등급은 인증 최고 단계입니다.

 

아래 링크를 통해 D-Bridge2.0의 GS인증 1등급 획득 보도기사를 확인하실 수 있습니다.

 

[보도기사 링크]

- 아시아경제 

news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=277&aid=0004866991

 

- 한국경제

news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=015&aid=0004515230

 

- 디지털타임스

news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=029&aid=0002661474

 

- 데이터넷 

www.datanet.co.kr/news/articleView.html?idxno=157309

 

- IT비즈뉴스

www.itbiznews.com/news/articleView.html?idxno=31853

 

New Multi-Channel Dynamic CMS

마이데이터 필수 API 솔루션 ‘D-Bridge’ GS 인증 1등급 획득

 

(주)사이버이메지네이션의 API서버 제품인 ‘D-Bridge2.0’이 한국정보통신협회(TTA)로부터 품질 우수 소프트웨어에 부여되는 GS(Good Software) 인증 1등급을 획득했다.

 

GS인증은 한국정보통신기술협회(TTA)가 국내 소프트웨어의 완성도를 평가하기 위해 마련한 제도로, ISO 국제 표준을 기준으로 일정 수준 이상을 만족한 경우에만 인증서 및 인증마크를 수여하게 되며, D-Bridge가 취득한 1등급은 인증 최고 단계이다.

 

D-Bridge는 다양한 데이터 소스(Database, Middleware, I/O) 연계, Total API Lifecycle Management, 강화된 API 보안, 사용통계정보 제공 JSON, XML, SOAP등 다양한 통신 프로토콜이 지원되는 기업환경에 최적화된 API 솔루션이다. 2016년 출시 직후 SK증권 납품을 필두로 대형 증권/보험사/기관 등에 납품하며 업계 최다 금융권 레퍼런스를 보유하고 있으며, 지난 5년간 오픈 API 시스템 사업을 꾸준히 수행하고 있다.

 

8월 예정된 마이데이터 본격 시행을 앞두고 마이데이터 사업자에게 고객의 개인정보를 안전성이 보장된 API방식(2021년 8월 4일 API시스템 의무 구축(신정법 제22조의9) 발효)으로 제공해야 함에 따라 API 인프라 구축에 대한 관심과 함께 사업관련 문의가 쇄도하고 있다.

 

 

DBridge 상세기능

 

DBridge 레퍼런스

 

 

New Multi-Channel Dynamic CMS

웹 서비스 동작구조와 소켓 통신

안녕하세요.

이번 글은 웹 서비스 동작 구조와 소켓 통신을 알아보겠습니다.

 

목표

 

     Client - Server 구조

     Static Page & Dynamic Page 구분

     Server 구성 Web/Was 차이 이해

     Session & Timeout

     3-Way handshake 이해

     Apache Timeout

     WAS(Tomcat) Timeout

     Web - WAS - DB 연동

     WAS-DB 사이의 Timeout

     OS level Timeout

 


Client – Server 구조 1

Client가 Server에 요청을 하면 Server는 결과물을 Client에 응답하는데 이러한  구조를 Client - Server 구조라고 합니다.

단순화시키면 위와 같은 모습을 가집니다. 이때 요청과 응답은 클라이언트와 서버가 각각 소켓을 만들어서 주고받는데 소켓에 관해서는 아래쪽에서 알아보겠습니다.

Static Page & Dynamic Page

클라이언트가 서버에 페이지를 요청할 요청하는 인터넷 페이지에는 2가지 종류가 있습니다. Static Page와와 Dynamic Page인데인데 이름에서 있듯이 변하지 않는 페이지와 변하는 페이지입니다.

 

1.    Static Pages

             : 항상 동일한 페이지를 반환하며 image, html, css 등으로 구성된 정적인 페이지입니다.

1.    Dynamic Pages

             : 인자의 내용에 맞게 동적인 contents 반환합니다.따라서 접속할 때마다 페이지의 내용이 바뀝니다.

 

Web & WAS

서버도 Web Server와 WAS(Web Application Server)로 나누어지는데

Web Server  Static Page, WAS Dynamic Page 처리한다고 보면 됩니다.

 

1.    Web Server

      : Static Page 처리(정적인 컨텐츠 제공), 동적인 컨텐츠가 필요할 경우 해당 요청을 WAS 전달, WAS 처리한 결과를 클라이언트에게 전달

 

1.    WAS

      : Web Server + Web Container 로 구성. DB 조회나 다양한 로직 처리 동적인 컨텐츠를 제공

 

WAS Web Server + Web Container 로 이루어져 있으며 이때 Web Container 동적인 페이지를 처리합니다. WAS에도 Web Server 있기 때문에 Web Server 없이 WAS 존재하는 것도 가능합니다.

 

Web Server 와 WAS 분리

WAS 에는 Web Server 포함되어 있기 때문에 WAS 로만 서버를 구성해도 됩니다. 그러나 일반적으로 Web Server 와 WAS 분리하는 경우가 많은데 여기에는 여러 이유가 있습니다.

 

1.    서버 부하의 방지

      : WAS 정적, 동적 페이지 모두를 처리할 있다고 하지만 그만큼 WAS 부담이 많아지게 됩니다. 그래서 기능을 분리해서 서버의 부하를 줄이기 위해서 Web Server WAS 분리합니다.

 

1.    보안을 위하여

      : WAS에는 실제 Web Application 올라가기 때문에 외부와 직접 연결되면 중요한 파일이나 소스들이 노출될 있습니다. 그래서 이를 막기 위해서 Web Server WAS 앞단에 배치합니다.

 

1.    Web Server 여러개의 WAS 연결하기 위해

       : 규모가 서비스에서는 수많은 요청을 한군데가 아닌 여러 군데에서 처리하기 위해 동일한 Web Application 여러 띄웁니다. Web Server 두고 여러 WAS들을 Web Server 연결해서 Web Server 들어오는 수많은 요청을 WAS 적절하게 분배해줍니다.

 

1.    여러 Web Applications 서비스하기 위해

       : Java 서버, PHP 서버와 같이 서로 다른 서버를 하나의 Web Server 연결해서 서비스할 있습니다.

 

Client – Server 구조2

 

Web Server WAS 별도로 구성한다고 했을 위에서 단순화 시켰던 Server - Client 구조를 다시 그리면 위의 그림과 같은 구조라고 있습니다.

 

일반적으로 Web Server 는 Apache 많이 사용하며 WAS Tomcat 많이 사용합니다. Tomcat Apache Tomcat 이라고도 부르는데 Web Server 역할도 있기 때문에 Apache Tomcat 이라고 부르는 것을 있습니다.

이중화 Web Server WAS 위와 같이 구성되어 있으며 각각의 웹과 WAS 들이 이중화 되어 있습니다.

 

 Timeout

위에서 봤던 Server - Client 구조를 다시 보겠습니다.

 

Client 에서 Server 요청을 보내면 Web Server 요청이 갑니다. 그리고 해당 요청에 동적인 데이터가 필요하다면 요청을 다시 WAS 보냅니다. 그리고 WAS에서도 DB 접속을 해서 해당 데이터를 가지고 있습니다.

이렇게 클라이언트의 요청에 대해 한번의 요청이 아니라 여러 단계의 요청이 있을 있습니다.

 

그런데 통신 과정 중에 문제가 발생하면 요청과 응답이 제대로 이루어지지 않을 있습니다. 문제가 발생한 상황에서 응답을 계속해서 기다리기만 하면 무한정 대기해야 하는 상황이 생깁니다. 그래서 특정 시간이 지나도록 응답이 제대로 이루어 지지 않으면 클라이언트와 서버의 접속을 끊어야 하는데 요청을 기다리는 한계 시간을 Timeout 이라고 합니다.

 

그리고 요청과 응답에 여러 단계가 있기 때문에 Timeout 여러 종류가 있습니다.

 

 3-Way Handshake

 Client - Server 구조1 에서 서버와 클라이언트가 통신을 소켓을 이용한다고 했습니다. 서비스의 경우 TCP 소켓으로 연결을 하는데 TCP 소켓은 서버와 클라이언트의 연결을 확인하고 연결이 확인이 되었을 에서야 데이터를 전송합니다.

 

Client - Server 통신을 바로 페이지를 요청 하고 요청에 대한 응답을 받는게 아니라

1번과 2번의 단계를 통해서 Client - Server 의 통신이 가능한지 연결을 확인하고 연결이 확인 뒤에야 실제 데이터에 대한 요청인 3번과, 4번의 응답이 이루어집니다.

 

1,2번의 Client Server 연결을 확인하는 것을 3-Way HandShake 라고 합니다.

 

그림에서는 1번과 2번으로 요청과 응답의 2단계인 것으로 표현되어 있지만 실제로는 3단계 과정을 통해서 연결을 확인합니다.

 

사진과 같이 3단계 과정을 거쳐 Client Server 연결을 확인합니다.

 

     Syn : 연결을 요청하는 패킷

     Ack : 요청에 응답하는 패킷

 

1.    Client 서버에게 Syn 패킷을 보냅니다.

2.    Server 는 받은 Syn 패킷에 +1 하여 Ack 패킷으로 보냅니다. 그리고 서버도 Client에게 별도의 Syn 패킷을 보냅니다.

3.    Client Server에게서 Ack Syn 패킷을 정상적으로 받았다면 상태를 Established 변경하고 Server에게 받은 Syn 패킷에 +1 하여 다시 Server 에게 Ack 패킷으로 전송합니다. 그리고 Server Ack 받으면 Established 상태를 변경합니다.

 

  3단계의 과정을 통해서 연결이 확인 되면 그때부터 데이터가 전송됩니다. 그리고 과정이 끝이 나야 서버에 로그가 저장이 됩니다. 만약 3-Way handshake 제대로 이루어지지 않으면 서버의 로그에 기록이 남지 않은 채로 연결이 끊어집니다.

 

위의 2 단계 Server Client ack 다시 보낼 까지 대기를 하게 되는데 대기 시간을 Connection timeout 이라고 합니다.

  

SYN Flooding

3-Way handshake 의 취약점을 이용해서 서버를 공격하는 방법이 있는데 이를 SYN Flooding 이라고 합니다.  (SYN Flooding DOS 종류)

 

     SYN Floding : 3-Way handshake 2단계에서 Server Client에게 ack + syn 을 보내고 다시 Client 에게 ack 받을 때 까지 Server 대기를 해야 하는데 1단계 요청만 무수히 많이 보내서 Server 대기 중인 상태를 많이 만드는

 

이러한 공격을 막기 위해서는 여러가지 방법을 사용할 있지만 바로 위에서 봤던 Connection Timeout 시간을 조절하는 방법을 알아보겠습니다.

 

Apache Connection Timeout

 Apache Web Server 환경 설정에서 Connection Timeout 값을 설정할 있습니다.

Connection Timeout 이지만 Apache 환경설정에서는 그냥 Timeout 이라는 이름으로 되어 있습니다.

 

 

(설치경로)/httpd/conf/httpd.conf

 

해당 위치의 파일 열어서 수정하면 됩니다.

 

Timeout300

Apache Timeout 값의 기본값은 300() 설정되어 있습니다.

Client Server 상황에 맞게 값을 적절하게 조절해 줍니다. 해당 값이 너무 길다면 DDOS 공격에 취약해질 있으며 반대로 값이 너무 작으면 인터넷 속도가 느린 Client 아예 접속을 없게 됩니다.

 

 Apache Keepalive Timeout

3-Way handshake 통해서 Client Server 연결이 확인되고 나면 데이터의 요청과 전송이 이루어집니다. 그리고 전송이 끝나고 나면 Client Server 연결은 끊어지고 다음 요청 다시 3-Way handshake 해서 연결을 확인하고 데이터를 주고 받습니다.

 

그러나 요청 마다 연결을 확인하는 것은 비효율적이기 때문에 연속된 요청과 응답에 대해서 소켓을 재사용 있습니다. 이것을 Keepalive 라고 부릅니다.

 

 

KeepAlive On/Off ( 기본값 : ON)

KeepAlive Timeout 5(초)

MaxKeepAliveRequests 100

 

위의 Apache Timeout 동일한 파일에서 설정을 있습니다.

 

KeepAlive : On/Off 하여 설정 가능

KeepAlive Timeout : KeepAlive On 상태에 유효한 값이며 해당 시간() 동안 요청이 없으면 연결을 끊습니다.

MaxKeepAliveRequests : KeepAlive On 상태에서 유효한 , 최대 번의 요청까지 연결을 계속 사용할지 결정. 0 무제한

 

WAS Session Timeout (Tomcat)

 Apache 같이 Tomcat Timeout 있습니다.

 

Tomcat WebServer 역할도 같이 있기 때문에 앞선 Apache Timeout KeepAliveTimeout 있습니다. 그러나 Apache 연동하여 사용하면 Tomcat Apache 사용하지 않습니다.

 

 

Apache 에서는 Connection Timeout 그냥 Timeout 이라고 하였으나 Tomcat 에서는 Connection Timeout 으로 표기 합니다.

 

그리고 Web Server처럼 WAS 요청과 응답 시간을 설정하는 Session Timeout 이 있습니다.

 

Tomcat 기준으로 Session Timeout 설정에는 3가지 방법이 있으며 우선순위가 있습니다.(1>2>3)

 

1.    프로그램에 직접 코딩

 

<%

             session.setMaxInactiveInterval(int)

%>

 

1.    WEB/INF/web.xml 파일

 

<web-app>

             <session-config>

                           <session-timeout>15</session-timeout> //분

             <session-config>

</web-app>

 

1.    /conf/web.xml 파일

 

<session-config>

                           <session-timeout>30</session-timeout> //분

<session-config>

 

Web - WAS - DB 연동

 

 

Apache Tomcat 연동하여 사용하고 Tomcat  DB 연동해서 사용하려면 중간에 모듈이 필요합니다.

 

1번의 Apache - Tomcat 연동의 경우

1.    mod_jk

2.    mod_proxy

3.    modproxyajp

 

3가지 방법을 사용할 있으며

2번의 Tomcat Oracle DB 연동의 경우 JDBC OJDBC 라는 모듈을 사용합니다.

 

모듈을 통해서 연동을 하기 때문에 모듈과 다음 대상과의 통신에 대한 Timeout 있으나 모듈에 따라 설정이 다릅니다.

 

WAS & DBMS 통신과 Timeout

 

WAS DB 통신 사이에는 3가지 Timeout 있습니다.

타임아웃들은 계층구조를 가지고 있으며 상위 타임아웃은 하위 타임아웃에 의존성을 가지고 있습니다.

JDBC Driver Socket Timeout 정상으로 동작하지 않으면 Statement Timeout Transaction Timeout 정상으로 동작하지 않습니다.

 

그리고 JDBC Driver SocketTimeout OS SocketTimeout 설정에 영향을 받습는다. JDBC Driver SocketTimeout 설정하지 않아도 네트워크 장애 발생 이후 30분이 지나서 자동으로 복구되는 것은 OS SocketTimeout 설정 때문입니다.

 

 

1.    Transaction Timeout

             : 프레임워크나 어플리케이션 레벨에서 유효한 타임아웃, StatementTimeout x N(Statement 수행 ) + a(가비지 컬렉션 기타) 라고 합니다. 전체 Statement 수행 시간을 제한할 사용합니다.

( Statement 를 아주 많이 수행할 때의 시간제한이라고 생각하면 됩니다.)

 

1.    Statement Timeout

             : Statement 하나가 얼마나 오래 수행되어도 괜찮은지에 대한 한계 시간 입니다. Statement DB 쿼리를 보내는 객체입니다. java.sql.Statement.setQueryTimeout(int timeout) 메서드로 설정할 있습니다.

 

1.    JDBC Driver Socket Timeout

             JDBC Driver 소켓을 사용하여 DB 연결하는데 어플리케이션과 DB 사이의 Connection Timeout 처리는 DB에서 하지 않습니다. 따라서 소켓에 Timeout 설정해야 하는데 Socket Timeout JDBC Driver에서 설정할 있습니다.

 

Socket Timeout 2가지 방법이 있으며 드라이버별로 설정 방법이 다릅니다.

             3-1. Socket Connect Timeout

                           : Socket.connect(SocketAddress endpoint, int timeout) 로 설정

             3-2. Socket Read/Write Timeout

             :            Socket.setSoTimeout(int timeout) 로 설정

 

 

OS level socket timeout

위의 SocketTimeout이나 ConnectTimeout 설정하지 않으면 어플리케이션이 네트워크 장애를 감지할 없습니다. 그러나 OS level 에서도 SocketTimeout 시간을 설정할 있기 때문에 값을 통해서 네트워크 연결 끊김을 확인할 있습니다.

 

Linux Socket Timeout

Server 에는 주로 Linux 사용하기때문에 Linux Socket Timeout 설정에 대해 알아보겠습니다.

Linux Socket Timeout에는 3가지 파라미터가 있습니다.

 

1.    tcpkeepalivetime : 전송된 마지막 패킷과 첫번째 Keepalive 의 간격. keepalive 유지하는 시간을 의미하며 기본 7200초(2시간)으로 설정되어 있습니다.

 

/proc/sys/net/ipv4/tcp_keepalive_time 7200

 

 

1.    tcpkeepaliveprobes : tcpkeepalivetime 에 의해 보낸 keepalive 세그먼트를 보낼 횟수. 기본 설정 되어 있는 9회가 지나 가면 연결이 종료 됩니다.

 

/proc/sys/net/ipv4/tcp_keepalive_probes 9

 

 

1.    tcpkeepaliveintvl : keepalive 세그먼트를 보내고 다시 확인 하기 위한 시간. 처음 keepalive 를 보내고 미응답시 다음 keepalive 보낼 시간. 기본 75초로 설정되어 있습니다.

 

/procs/sys/net/ipv4/tcp_keepalive_intvl 75

 

 

서버에 기본 설정된 위의 내용을 종합해보면 Client - Server 구조에서 2시간 동안 데이터를 주고 받은 경우가 없으면 서버는 keepalive 세그먼트를 보내고, Client 미응답시 75 이후 keepalive 세그먼트를 보내고, 9 동안 미응답시 연결을 종료하게 됩니다.

 

 

정리

 

지금까지의 전체 흐름을 그려보면 위와 같습니다.

 

#과제

 

감사합니다.

 

 

 

New Multi-Channel Dynamic CMS

Open API _오픈뱅킹 운영현황 및 향후 일정

안녕하세요.

오픈뱅킹 서비스 도입이 후 참가기관 확대 지침에 따라 오픈뱅킹 서비스 구축 및 API 제품(D-Bridge)에 대한 문의가 증가하고 있어, 오픈뱅킹 관련 내용을 정리하였습니다.

 

1. 오픈뱅킹

오픈뱅킹은 은행의 금융 결제망을 표준화해 하나의 애플리케이션(앱)으로 모든 은행의 계좌 조회나 출금·이체 서비스가 가능하도록 개방하는 것으로, 지난해 12월 전면 도입되었다.

 

Open API 조합을 통해 다양하고 새로운 금융 서비스 개발 가능 (이미지: 금융결제원)

 

 

2. 오픈뱅킹 해외사례

국가 관련정책
EU ㅇ PSD2(Payment Services Directive 2) 도입(‘18.1월)
✓ 은행 API를 핀테크 기업에 수수료 등 차별 없이 제공토록 의무화
ㅇ GDPR(General Data Protection Regulation)에서는 ‘개인정보이동권’을 도입하여 고객의 정보 자기결정권 강화(‘18.5월)
영국 ㅇ 9대 주요 은행 대상 오픈 API 서비스 실시(‘18.1월)
✓ 은행들이 오픈 API를 통해 타은행의 고객 정보를 받아, 타은행 계좌의 접근 등 다양한 서비스 실시 → 은행의 결제기능 강화 및 경쟁 확대
ㅇ 英OBIE(Open Banking Implementation Entity)는 기술사양, 보안 등 API 표준요건을 담은 Open Banking Standard 3.0 발표(‘18.9월)
※ 英 오픈뱅킹 API 이용건수는 19.8월 1.1억건으로 작년 동월(420만건)대비 약 26배 성장
호주 ㅇ 재무부에서 오픈뱅킹 구현을 위한 권고안 발표(‘18.2월)
✓ (4대 주요은행) ‘19.7월 신용·직불카드 및 예금·거래계좌부터 시작하여 20.2월까지 주택담보대출 등으로 확대 예정
✓ (기타 은행) 12개월 시차를 두고 점진적으로 확대, ‘22.7월 전 은행권의 전 금융상품에 대한 API 공개 예정
일본 ㅇ 은행법 개정을 통해 핀테크 기업에 대한 API 제공 등 의무화(‘18.6월)
✓ 핀테크 기업에 대한 API 제공 기준 공시 및 기준 충족업체에 대해 API 제공 의무화 (법 시행 후 2년내 은행 API 구축 노력 명시)
⇨ 日당국, ‘20년까지 110개 은행이 API 공개를 완료할 것으로 예상

 

3. 오픈뱅킹 운영현황

19년 12월 18일 시행 이후 가입자, 계좌등록 및 API 건수 증가추세 (20.7.6)

금결원에 따르면 API 이용건수 일평균 659만건, 누적10억 5천만건을 기록했다.

API 이용건수(월) API 이용건수(일평균) API이용건수(누적: 19.10.30~20.06.30)
1억 9천만건 659만건 10억 5천만건

 

또한 지난해12월 제도 전면 시행 이후 가입자는 4,096만 명,계좌 등록은 6,588 만좌를 기록했다. 

중복 서비스를 제외할 경우 가입자는 2,032만명으로, 국내 경제활동인구(지난 5월 기준) 72%가 오픈뱅킹 서비스를 경험했다

등록계좌(누적) 가입자수(누적)
6,588만좌 4,096만명

 

오픈뱅킹 가입자 가운데 79%가 핀테크를 통해 가입했고 은행이 21%를 차지했다등록 계좌 수도 핀테크가 64%로 은행(36%)보다 많았다

가입자 등록계좌
은행 21%, 핀테크 79% 은행 36%, 핀테크 64%

 

업권별로는 은행의 경우 잔액조회(84.5%), 핀테크 기업은 출금이체(82.5%) 이용이 가장 빈번한 것으로 나타났다.

은행 핀테크 합계
잔액조회 84.5% 출금이체 82.5% 출금이체 29.9%, 잔액조회 59.2% = 89.%

 

4. 오픈뱅킹 참가기관 확대 및 향후 일정

금융투자업계에 따르면 올해 12월부터 은행에 이어 농협, 저축은행 등 제2금융권 고객도 오픈뱅킹 서비스 이용이 가능해진다. 참여 기업은 상호금융, 저축은행, 증권사 등이다. 농협 등 7개 서민금융기관과 미래에셋대우, 메리츠, 신한금융투자 등 17개 증권사가 참여한다. 

오픈뱅킹 참가기관 확대(이미지: 금융결제원)

 

 - 7~8월: 참가신청 접수 및 참가 절차 일괄진행

 - 7월~11월: 전산개발 및 테스트, 관련 규정 개정 등

 - 12월~: 준비가 완료된 참가기관별로 순차 실시

 

 

(API 솔루션 DBridge)

제품 특징

제품 레퍼런스

 

(참고)

금융결제원, 오픈뱅킹 운영 및 추진현황 발표자료(2020.07.06)

 

New Multi-Channel Dynamic CMS

2020 보안기술 개발 동향

1. 서론

최근 인공지능 기술의 발전에 힘입어 사이버 공격자들은 새로운 형태의 지능화된 알고리즘을 활용한 신·변종 사이버 공격과 자동화 기술을 활용하여 대규모의 사이버 보안 공격을 시도하고 있다. 이러한 추세에 힘입어 점점 고도화되고 다양해지는 사이버 공격에 효율 적으로 대응하기에는 기존의 보안 솔루션들은 많은 한계를 보이고 있다. 사이버 위협에 능동적으로 대비하기 위해서 보안 업계에서는 인공지능을 보안 분야에 적용하는 것에 주 주목 하고 있다. 보안이 인공지능과 결합하게 되면 네트워크, 위협 인텔리전스, 취약점 분석, 악성코드 분석, 실시간 탐지 및 대응 등 다양한 보안 분야에서 보안 능력이 획기적으로 향상될 것으로 예상되고 있다

 

2. 인공지능 보안 위협

인공지능 기술은 분명 현재의 보안 기술단계를 한 단계 끌어올려, 이를 통해 안정적인 비즈니스 환경의 연속성을 보장해줄 뿐만 아니라, 효율적인 인력운용이 가능하다는 장점이 있다.

그러나 이러한 인공지능을 방어측의 전유물이라고 생각하면 큰 오산이다. 인공지능을 적용하여 창과 방패처럼 공격 측과 수비 측에 공평한 기회를 제공한다. 방어 측에서 보면 인공지능이 다양한 악성코드의 공격 유형을 머신러닝 기법을 통해 자동으로 분류 및 분석하여 대응책을 마련하듯이 공격 측에서도 현재 시스템이 가지고 있는 보안 취약점을 지속적으로 탐지하고 공격하여 보안의 허점을 찾아낸다. 또한, 공격자를 효과적으로 위장하는 데에도 사용될 수 있다.

 

3. 네트워크 기반 침입탐지

네트워크 기반 침입탐지(Network-Based Intrusion Detection: NIDS)는 인가되지 않은 사용자가 정보자원에 불법으로 접근하거나, 정보자원을 고갈시키는 행위를 검출하고 이에 대처하는 것을 말한다.

현재 사용되고 있는 네트워크 기반 침입탐지 시스템의 상용제품 대부분은 각종 공격에 대한 특징(signature)을 분석하여 이것을 자동으로 감지할 수 있는 패턴형태로 만들어 놓고, 실시간으로 네트워크 패킷을 관찰하여 동일한 패턴이 발생하면

침입(Intrusion)을 알리는 오용탐지(Misuse Detection)가 주류를 이루고 있다. 이러한 방식은 비교적 높은 정확도를 보여주고 있으며, 실제 사용에서도 어느 정도 효율적이라고 할 수 있다. 그러나, 각종 공격(Attack)을 분석하여 패턴을 만들기 위해서는 해당 분야의 특별한 전문가(Expert)가 필요하기 때문에, 패턴의 생성과 유지보수에는 높은 비용이 요구된다. 또한, 이미 패턴이 존재하던 공격이 약간 우회하여 행해지면, 기존의 패턴만으로 새롭게 변형된 공격을 감지하기가 어렵다. 그러므로 전문가 기반의 오용 탐지 기법은 새로운 유형의 공격에 대해서는 매우 취약할 수밖에 없다.

오용 탐지와는 다르게 평소 정상적인 네트워크 사용에 대한 각종 통계적인 자료를 만들어 놓고, 이 자료의 범위를 벗어나는 네트워크 상의 트래픽(Traffic)이 발생하면 침입이 발생했다고 판단하는 통계적 기반의 비정상 행위 탐지(Statistics-Based Anomaly Detection) 기법도 있다. 이 방법은 일부 공격들에 대해서는 매우 효과적이지만, 공격이 단지 몇 개의 패킷으로 구성되어 있는 경우는 효율적이지 않다.

이러한 이유로 대부분의 상용 네트워크기반 침입탐지 시스템은 전문가에 의한 오용 탐지를 주축으로 하고, 통계적 기반의 비정상 행위 탐지를 보조적으로 사용하고 있다. 그러나 이러한 방법들만으로는 다양한 유형의 공격을 완벽하게 탐지하기에는 한계가 있다.

이를 해결하기 위해 인공지능을 적용하면 정상적인 네트워크 패킷과 각종 비정상적인 네트워크 패킷을 수집하고, 이 패킷에 대해 다양한 머신러닝 알고리즘을 적용하여 학습된 지식을 기반으로, 실시간으로 생성되는 패킷들에 대해 정상 및 비정상 여부를 판단할 수 있다.

 

4. 데이터 전처리

기존 전통적인 보안 솔루션은 한계를 보이고 있고, 이를 위한 해결책이 인공지능 기술을 활용해야 한다는 것은 알겠는데, 그렇다면 “어떻게 보안에 인공지능을 적용을 할 것인가?”라는 문제가 남는다.

인공지능의 기본 동작 원리는 수십 수백만 혹은 그 이상의 데이터들을 우선 학습을 하고, 학습을 통해 나온 컴퓨터가 계산한 알고리즘을 이용한다. 가령 고양이 사진과 고양이 사진이 아닌 것을 학습시킨 뒤, 한 번도 보여주지 않은 사진을 보여주고 이것이 고양이 인지 아닌지의 판단은 학습을 통해 나온 알고리즘에게 물어보는 것이다.

정상적인 네트워크 패킷과 각종 비정상적인 네트워크 패킷을 수집하는 것이 첫번째 우선이 되어야 하며, 이 수집된 데이터들을 손실률을 줄이면서 딥러닝 알고리즘에 바로 적용할 수 있는 형태로 만들어져야 한다. 이를 데이터 전처리라고 하고, 전처리에 대한 방법은 아래와 같다.

 

 

우선 네트워크 트래픽을 pcap을 이용하여 세션 단위로 읽고 txt파일로 저장한다.

 

 

그렇게 나온 txt 저장된 데이터를 28 x 28 크기의 png 이미지로 이미지화한다.

 

 

이런 과정으로 수집된 네트워크 세션 데이터는 CNN, RNN, LSTM 등 다양한 딥러닝 알고리즘 등에 바로 적용해서 사용할 수 있다.

 

5. 딥러닝 알고리즘 사용하기 위한 라이브러리

데이터가 준비가 되었다면, CNN, RNN, LSTM 등의 다양한 딥러닝 알고리즘에 적용을 해볼 수 있을 텐데, 이때 딥러닝에 필요한 수학적 기초나 딥러닝의 이론, 신경망 구조, 그리고 사용 방법을 모두 설명하기는 거의 책 한 권에 가까운 양이다.

여기서는 딥러닝 알고리즘에 적용하기 위한 주요한 딥러닝 라이브러리를 소개를 하고자 한다.

 

 

텐서플로우는 구글이 2015년 오픈소스로 공개한 뒤로, 다양한 자료와 범용성을 기반으로 가장 널리 사용되고 있다. 2016년 바둑에서 이세돌 9단을 꺾은 알파고에 텐서플로우가 적용됐다. 일본 금융사 SMFG개 개발한 신용카드 사기 탐지 시스템이 텐서플로우로 제작이 되었다. GitHub에서 가장 많이 사용되는 딥러닝 프레임워크이기도 하다.

케라스는 모듈화, 최소주의, 확장성이 뛰어난데, 네이버 페이의 카드결제 시스템 중 이상 거래 감지 시스템에 케라스 딥러닝 기반으로 개선한 예가 있다.

파이토치는 페이스북 인공지능 연구팀이 만들었으며, 진입장벽, 유연성, 속도가 뛰어나다. 다만 자료와 예제를 구하는 것이 단점으로 꼽힌다.

Deeplearning4j 세계에서 가장 인기 있는 개발언어인 Java로 만들어졌으나, 역시나 사용자 층이 깊지 않다. 일본의 AI 솔루션 기업 넥스트리머에서 이상 거래 탐지 연구에 활용된 바 있다.

Apapche MXNet은 아마존이 공식 지원하며, 폭넓은 언어 지원과 사용범위가 강점이다. C++, 스칼라, 줄리아, 매트랩, 자바스크립트, 클로저, 펄, R 등의 언어를 지원하여, 모바일 기기부터 서버 수준까지 지원한다.

 

6. 주요 네트워크 기반 침입탐지 시스템

 

6.1 다크트레이스

- 모든 사용자 및 디바이스의 이상 징후를 머신러닝, 인공지능 기법을 활용하여 실시간으로 자동 분석하고 그 이상 여부를 판별,

  차세대 위협 감지 솔루션

- 인간의 면역체계와 유사하게 단말, 서버 등 모든 디바이스에 대한 데이터 흐름을 통해서 정상행위를 학습하고 이에 위반하는

  이상행위 판별

 

6.2 사이런스

- 기존에 수집된 악성코드의 특성을 다양한 머신러닝 알고리즘을 적용하여 학습하고, 이 학습한 데이터를 기반으로 전혀 새로운

  형태의 악성코드도 분류해 낼 수 있는 인공지능을 탑재

- 700만 개 이상의 파일 특징을 0.1초 이내에 종합하여 분석

 

7. 결론 및 시사점

최근 국내에서 열리고 있는 보안 컨퍼런스의 주제를 살펴보면, 인공지능 또는 머신러닝, 빅데이터 등이 70% 이상을 차지하고 있다. 이는 그만큼 현재 보안업계에서 인공지능에 대한 관심이 뜨겁다는 것을 보여주는 반증이라고 할 수 있다. 인공지능의 보안 분야 적용은 보안 시스템을 노리는 공격자와 방어자 모두에게 공평한 발전의 기회를 제공하고 있다.

과거의 사이버 공격은 뚜렷한 목적 없이 불특정 다수를 상대로 공격이 이루어진 것에 반해, 최근에는 금융, 교통과 전력 등 국민의 생명과 재산뿐만 아니라 국가 기반시설을 대상으로 정치, 경제적, 군사적 의도를 가지고 특정 대상을 공격하는 양상으로 변모하고 있다.

국가나 기관이 최신 보안 장비와 솔루션을 도입하여 운용하고 있고, 오랜 기간 노하우를 갖고 있음에도 불구하고, 날로 진화하는 공격을 실시간으로 막지 못해 피해를 입는 사례가 급속하게 증가하고 있으며, 때문에 인공지능의 도입은 필연이라 고 볼 수 있다.

 

8. 참고

인공지능 기술 원리의 이해 / 송경빈

인공지능 기법을 이용한 네트워크 기반 침입탐지 기술 동향 / 이창훈

인공지능을 활용한 보안기술 개발 동향 / 국경완, 공병철

인공지능 기술 및 산업 분야별 적용 사례 / 국경완

A Study of Data Preprocessing for Network Intrusion Detection based on Deep Learning / Kimoon Jeong

CNN과 RNN의 기초 및 응용 연구 / 이은주

 

 

New Multi-Channel Dynamic CMS

Flutter

1.   Flutter란?

Flutter는 Google에서 만든 Cross-Platform Framework입니다. 하나의 코드로 Android / IOS, Desktop App까지 개발할 수 있습니다. 언어는 구글이 개발한 Dart를 사용합니다.

 

2.   Widget

Flutter에서는 모든 것이 Widget으로 시작합니다. Image, Icon, Text, Row, Column, Padding도 모두 Widget입니다. Flutter는 크게 Material Widget과 Cupertino Widget을 자체적으로 제공하기 때문에 look&feel, 빠른 속도, 커스터마이즈, 확장 가능성 등을 지원받습니다.

 

Flutter은 Widget과 Renderer들을 플랫폼 영역에서 앱의 영역으로 옮겨서 위젯들의 커스터마이징이 가능해졌고 확장 가능해졌습니다. 플랫폼의 캔버스를 통해 디바이스 스크린에 위젯을 그리고 이벤트들(터치, 타이머 등)과 서비스(위치, 카메라) 등에 접근하게 됩니다.

Dart 프로그램(초록색) 영역과 네이티브 플랫폼 코드(파란색) 사이에는 인코딩과 디코딩을 담당하는 인터페이스가 여전히 존재합니다. 그러나 JavaScript 브릿지와 비교했을 때 비교할 수 없을 정도로 빠른 성능을 가지고 있습니다.

 

 

Flutter을 이용해서 간단한 위젯 트리를 만들었습니다.

이 코드에서 레이아웃 포함 모든 것은 위젯입니다. Center 위젯은 위젯의 부모(위의 예제에서는 스크린)의 중앙에 위젯의 자식 위젯들을 위치시킵니다. Column 위젯은 이 위젯의 자식 위젯들을 수직으로 나열시킵니다. 이 Column은 Text 위젯과 Icon 위젯(색 속성을 가지는)을 가지고 있습니다. Flutter는 Column뿐 아니라 Row, Grid, List 등 꽤나 많은 위젯을 포함하고 있습니다. 게다가, Flutter는 Silver Layout Model이라고 칭하는 스크롤링을 위해 사용되는 고유한 레이아웃 모델을 가지고 있습니다. 스크롤링은 반드시 즉각적이면서도 부드럽게 반응해야만 사용자들이 물리적인 화면을 드래그했을 때, 손끝에 이미지가 붙어있는 듯한 느낌을 줍니다. Flutter의 레이아웃은 굉장히 빨라서 바로 이것을 해낼 수 있습니다.

 

4.   Dart 프로그래밍 언어

 Flutter는 새로운 프레임마다 새로운 뷰 트리를 구축합니다. 하나의 프레임을 위해 많은 수의 객체들을 생성하게 됩니다. 

Dart는 이러한 시스템에서 굉장히 효율적인 “generational garbage collection”을 사용하고 있습니다. 이 정책에서는 객체들 (특히 짧은 시간 동안 살아있는 객체들)의 비용이 매우 쌉니다. 또한 Dart는 앱에서 필요한 코드만을 포함시키는 “tree shaking”라는 컴파일러를 가지고 있어서 아주 큰 위젯 라이브러리에서 한 개 혹은 두 개만을 사용하더라도 부담 없이 사용하시면 됩니다.

 

5.   StatelessWidget과 statefulWidget

Flutter의 Widget 은 StatelessWidget과 StatefulWidget를 상속받아 만들 수 있습니다. Widget 은 Build 메서드를 포함하며, 이 Build 메서드를 이용해서 Layer Tree를 만듭니다. StatelessWidget 은 단 한번만 Build 과정이 일어나기 때문에 한번 그려진 화면은 계속 유지되며, 성능이 좋습니다. StatefulWidget 은 state를 포함하며, setState 가 발생할 때마다 다시 Build 과정이 일어나기 때문에 동적 화면을 쉽게 구현이 가능합니다.

 

6.   적합성

Flutter로 만든 앱은 오래된 os뿐 아니라 최신 os에서도 동일하게 동작합니다. 더불어, 미래의 os버전에서도 동일하게 동작할 것입니다. 위젯은 앱의 일부이기 때문에 플랫폼의 업데이트로 인해 앱이 갑자기 이상하게 보이거나 하는 문제가 발생하지 않습니다.

 

 

New Multi-Channel Dynamic CMS

검색엔진 비교_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

bizXpress(CMS)_삼성선물 납품

안녕하세요.

사이버이메지네이션이 수주한 삼성선물 ‘홈페이지 재구축’ 프로젝트에 대해 설명 드리겠습니다.

 

해당 프로젝트는 사이버이메지네이션의 CMS 솔루션인 bizXpress를 적용하여 컨텐츠 관리 기능을 개선하고,

모바일 홈페이지 위주의 OSMU(One Source Multi Use) 홈페이지 구축, 실시간 시황 서비스를 개발하게 됩니다. 

 

- 기간: 2020년 3월 ~ 7월

- 개발방향

   (1) 반응형 웹페이지 구축

   (2) CMS 적용 컨텐츠 관리기능 개선

   (3) 홈페이지 통계수집 로그분석

   

프로젝트가 완료 되는대로 다시 안내 드리겠습니다.

감사합니다.

 

 

bizXress 레퍼런스 보러가기

 

 

http://solution.cyber-i.com/

 

New Multi-Channel Dynamic CMS