시뻘건 개발 도전기

엘라스틱 서치 검색엔진은 웹에서 정보를 수집해 검색 결과를 제공하는 프로그램이다. 검색 결과로 제공되는 데이터의 특성에 따라 구현 형태가 달라진다. 검색 시스템은 대용량 데이터의 검색 결과를 제공하기 위해 검색엔진을 기반으로 구축된 시스템이다. 수집기를 이용해 데이터를 수집하고 이를 다수의 검색엔진을 이용해 색인하여 UI로 검색 결과를 제공한다. 엘라스틱서치는 이와 같은 검색엔진이며 이를 사용하여 검색 시스템을 구축할 수 있다. 검색 시스템 검색 시스템의 구성 요소 검색 시스템은 데이터를 수집하는 수집기, 데이터를 저장하는 스토리지, 데이터를 검색에 적절한 형태로 변환하는 색인기, 색인된 데이터에서 일치하는 문서를 찾는 검색기로 구성된다. 수집기 수집기는 웹에서 필요한 정보를 수집하는 프로그램이다. 웹상..

앞서 언급한 분산의 포인트는 OS 캐시 활용과 인덱스(색인) 사용 그리고 확장을 고려하여 시스템을 설계하는 것이다. (MySQL은 물론이고 RDBMS는 인덱스를 생성하고 그로 인해 빠르게 데이터를 검색할 수 있는 구조가 마련되어 있다.) 보통 신규 프로젝트를 개발하게 될 때면 테이블 스키마를 그려하고 create table 쿼리로 테이블을 생성할 수 있다. 이 부분이 큰 규모일 수록 중요한 부분이 생기는데, 스키마를 얼마나 고려했는지, 분산과 확장성을 얼마나 고려했는지에 따라서 데이터가 큰 차이로 증감할 수 있다는 것을 이전 포스팅을 통해 알게되었다. 따라서 대량의 데이터가 저장되는 테이블일 수록 래코드가 최대한 작아지도록 컴팩트하게 설계되어야 한다. MySQL의 인덱스 경우에는 빠른 탐색을 위해 B트리..

지금까지 캐시가 I/O에 미치는 영향에 대해서 알아 보았다. (학교에서 language를 배울 때 캐시를 전혀 알려주지 않고 컴퓨터 개론 등의 수업에서만 캐시를 간략하게 언급하고 지나갔던 기억이 난다. 정작 현업에서는 캐시를 아주 잘 사용하고 있고 꼭 필요한 부분에서 어떤 방식으로 캐시를 사용할지에 대해 명확하게 정의하여 사용한다.) 데이터 처리 시 압축해서 저장해두면 디스크 내용을 그대로 캐싱할 수 있고, 데이터의 규모보다 물리 메모리가 더 클 때 전부 캐싱할 수 있다는 사실을 알게 되었다. 그렇다고 메모리를 대규모에 따라 계속해서 늘리기만 할 수 없다. (경제적인 비용과 밸런스 등 고려) 이럴 때 "복수 서버 확장"이 필요할 수도 있다. 어느정도 성장한 기업의 서버는 대부분 이 방안을 채택하여 사용할..

트래픽이 증가하게되면서 우리는 장비의 성능을 끌어올리거나 개수를 늘릴 수 있고, application의 캐시 등 성능개선, DB서버의 I/O 최소화 등 작업을 진행하면서 기본적으로 알아야할 사항들이 상당히 많다. 일전에 언급했던 스케일업과 스케일아웃이 많이 볼 수 있는 대응 방법인데, 보통은 스케일아웃을 많이 채택한다. 그 이유는 많은 것들이 있을 수 있지만 웹 서비스에 적합하고 비용이 저렴하며 시스템 구성에 유연성이 있다는 점이 높게 평가되고 있다. 스케일아웃의 특징은 하드웨어를 횡으로 전개해서 CPU 부하의 확장성을 확보하기 쉽다. 하지만 DB 서버 측면에서는 I/O 부하가 잦게 일어난다. [그림 1]을 보면 알 수 있듯이 프록시의 요청이 AP 서버를 거처 DB에 도달해서 DB측에 I/O가 발생한다...

대규모 데이터의 처리는 왜 소규모 데이터보다 어려운가? 데이터는 디스크에서 로드해서 메모리에 저장한다고 이전 토픽에서 언급한 바있다. 속도를 따지고 보자면 메모리가 디스크보다 훨신 빠르기 때문에 메모리에서 계산해야 빠른 결과를 볼 수 있는 것이다. 이 부분이 포인트가 된다. 메모리는 비교적 디스크보다 크기가 작기 때문에 대규모 데이터를 처리하기엔 적합하지 않다. 그러나 속도 측면에서 볼 때는 디스크보다 메모리에서 계산하는 것이 효율적이다. 이 사실에서 알 수 있는 부분은 메모리 내에서 계산할 수 없는 정도의 데이터라면 디스크에 두고 특정 데이터를 검색한다는 것이다. 디스크는 왜 메모리보다 느린가? 디스크는 물리적인 탐색을 통해 검색하기 때문에 속도에 영향이 있을 수 있다. 디스크에는 헤드라고 하는 녀석과..

JPA(Java Persistence API)를 알기 위해서는 ORM(Object-Relational Mapping)을 알아야 한다. ORM은 객체와 관계형 데이터베이스를 맵핑해주는 녀석이다. 이전에 언급했듯이 자바의 객체와 관계형 데이터베이스간의 차이가 문제를 일으킬수 있다. 이 문제를 최소화 시키기 위해서 ORM이라고 하는 기술이 등장했다. JPA가 바로 자바 플랫폼의 ORM 표준 기술이다. JPA는 [그림 1]과 같이 동작하게 되는데, JPA가 자바 애플리케이션과 JDBC 사이에서 하는 일은 다음과 같다. 패러다임 불일치 해결 (DB 연동 시 유의할점 #2 참고) SQL query 생성 Entity 분석 (추 후에 이야기 하겠지만 여기서의 엔티티란 테이블을 객체화 시킨 것을 이야기 한다.) 우리는 ..

애플리케이션을 개발할 때 상용계 운영과 유지보수도 함게 생각하면서 개발해야 한다. 결국, 내부 로직이 복잡하면 복잡할 수록 유지보수가 어렵고 운영에도 영향을 미치기 쉬울 수 있다. 데이터베이스를 연동 할 때도 복잡해서는 안된다는 이야기이다. 이전 글에서 언급한 것 처럼 개발을 하게 된다면, 유지보수가 말도 못하게 힘들 수 있다. 그렇다고 데이터베이스 연동을 안할 수 없지 않는가. 데이터베이스는 객체지향 이야기 되는 추상화, 상속, 다형성의 개념이 없고, 구조 조차도 다르다. 즉, 객체와 RDB는 각각 지향하는 목적이 다르기 때문에 사용 방법과 표현방식에 차이가 있을 수 밖에 없다. 이 것을 패러다임 불일치 문제라고 이야기 한다. 이러한 문제때문에 객체 구조를 DB 테이블 구조에 저장하는데에 한계가 있을 ..

Database를 연동하게 된다면, 우리는 코드 상에서 query를 날리는 로직이 필요할 것이다. 그렇다면 우리가 해야할 일은 다음과 같을 것이다. 드라이버 로드 -> connection 생성 (혹은 DB pool 사용) -> DB 연결 -> sql auery 실행 -> 자원해제 데이터베이스에 접근 할 때마다 상기 내용과 같은 작업이 반복적으로 이루어져야만 한다는 이야기다. 이를 해결하기 위해 JDBC를 사용하는 것이다. spring JDBC를 사용하기 위해 spring-jdbc maven lib이 필요하다. 찾는 방법은 이전 글의 maven Repository를 참고하자. #12 : spring 관련 docs 및 API 참고 자료 spring을 사용하려면 spring docs는 필수로 보아야하고, 어떤..