24DAY 백엔드 - 20DAY 겜색엔진, 아키텍처 패턴

1. Elastic search

elasticsearch는 Shay Banon이 Lucene을 바탕으로 개발한 분산 검색엔진입니다. 설치와 서버 확장이 매우 편리하기 때문에 개발하고 있는 시스템에 검색 기능이 필요하다면 elasticsearch를 적용하는 것을 권장하고 싶습니다. 분산 시스템이기 때문에 검색 대상 용량이 증가했을 때 대응하기가 무척 수월하다는 것이 장점입니다.

 

우선 관계형 데이터베이스에 익숙한 사람들을 위해 관계형 데이터베이스와 elasticsearch의 용어를 비교한 표를 참고 자료에서 인용했습니다.

 

JSON 기반의 스키마 없는 저장소

elasticsearch는 검색엔진이지만, NoSQL처럼 사용할 수 있습니다. 데이터 모델을 JSON으로 사용하고 있어서, 요청과 응답을 모두 JSON 문서로 주고받고 소스 저장도 JSON 형태로 저장합니다. 스키마를 미리 정의하지 않아도, JSON 문서를 넘겨주면 자동으로 인덱싱한다. 숫자나 날짜 등의 타입은 자동으로 매핑합니다.

확장성과 유연성

elasticsearch는 확장성과 유연성이 매우 뛰어납니다. 플러그인을 이용해 기능을 확장할 수 있습니다. 예를 들어 Thrift 플러그인이나 Jetty 플러그인을 사용하면 전송 프로토콜을 변경할 수 있습니다. 필수 플러그인이라고 할 수 있는 BigDesk나 Head를 설치하면 elasticsearch 모니터링 기능을 사용할 수 있게 됩니다. <예제 2>에서 보는 것처럼 동적으로 복제본 개수를 조정할 수도 있습니다. 다만 샤드 수는 인덱스별로 고정돼 있어 수정이 불가능하므로 노드 수와 향후 서버 확장을 고려해 초기에 적절한 수를 할당해야 합니다.

 

분산 저장소

elasticsearch는 분산 검색엔진입니다. 키에 따라 여러 샤드가 구성되는 방식으로 데이터를 분산한다. 인덱스는 각각의 샤드마다 구성된다. 각각의 샤드는 0개 이상의 복제본을 가진다. elasticsearch는 클러스터링을 지원하며 클러스터가 가동될 때 여러 노드 중 하나가 메타데이터 관리를 위한 마스터 노드로 선출된다. 마스터 노드가 다운되면 자동으로 클러스터 내의 다른 노드가 마스터가 된다. 노드 추가 또한 매우 간단하다. 같은 네트워크에 노드를 추가하는 경우 추가된 노드가 멀티캐스트를 이용해 자동으로 클러스터를 찾아 자신을 추가한다. 같은 네트워크를 이용하지 않을 경우 유니캐스트로 마스터 노드의 주소를 명시해 주어야 한다

2.solr

텍스트 검색 기능을 제공하는 오픈소스 라이브러리 입니다.

• 아파치 재단에서 만든 오픈소스 프로젝트
• 검색 애플리케이션을 만드는데 사용
• 빠르고 확장가능
• 데이터 분산처리 플랫폼인 하둡 위에서도 동작 가능
• 검색기능에 더해 NoSQL 데이터베이스처럼 저장 목적으로 사용 가능

특징

• Restful APIs

  • HTTP 호출을 사용한 검색을 지원
  • 결과값은 JSON, XML, CSV 포맷을 지원

• Full Text Search

  • 단어, 문장 등의 텍스트 검색
  • 오타교정, 검색어 자동완성, 와일드카드 질의 기능을 제공

• Flexible and Extensible

  • Java 메소드 오버라이딩을 통해 커스터마이징 가능

• NoSQL 데이터베이스

  • 큰 용량의 데이터 저장 가능
  • 여러 클러스터로 분산된 파일에 대한 분산 검색 처리

• Admin interface

  • 쉬운 사용을 위한 사용자 친화적 인터페이스 제공

• Highly scalable

  • 전체 클러스터에 replica 추가를 통한 쉬운 확장

3.모놀로직앱

모든 비즈니스 로직이 한 애플리케이션 안에 포함되어 있는 구조를 말합니다.

 

모놀로직 서비스 구성도

 

모든 기능들이 한 애플리케이션에서 동작하는 구조이며 이를 모놀리식 서비스라고 합니다.

 

 

장점 

• 처음에 구조 설계 및 개발이 간단합니다
• 내부 프로세스 간 지연시간이 짧음
• 배포 시, 한번 배포하면 끝입니다.

단점

• 낮은 모듈성
• 낮은 확장성
• 긴 빌드 시간

4.마이크로 서비스

모든 애플리케이션이 마이크로서비스 아키텍처 패턴으로 구성될 필요는 없습니다. 특히, 적은 인원으로 빠르게 시작해야하는 스타트업의 경우 앞으로 어떤 서비스와 컴포턴트가 필요하게 될 지 예측할 수 없는 상황에서 과도하게 시스템을 여러개의 서비스로 쪼갤 필요는 없습니다. 그렇다면 구체적으로 어느 시점에 마이크로서비스 아키텍처에 대해서 고려하는 것이 좋을까요? 일반적으로 다음의 항목들 중에서 대부분이 현재 상황에 해당한다고 생각되면 마이크로서비스 아키텍처 패턴에 대해서 고민을 시작해 보는 것도 나쁘지 않습니다

 

1. 애플리케이션의 배포에 한 시간 이상 소요됩니다.
2. 단순한 기능 하나를 수정해도 전체 기능에 대한 QA가 필요합니다.
3. 단순한 버그 수정이 더 중대한 버그를 새산하는 일이 많아 졌습니다.
4. 현재의 애플리케이션을 기능별로 나눈다고 가정했을 때 수십개의 마이크로 서비스가 가능합니다.

마이크로서비스 구조도

 

일체형 서비스 구조로 인해 시스템 엔트로피가 자꾸만 늘어만 갔씁니다.

 

결국 많은 서비스들이 이런 문제를 해결하기 위해 더 적합한 아키텍처를 찾아서 진화했습니다.

 

장점

• 개발자 생산성 향상
• 테스트 용이성 증가
• 빠르고 지속적인 배포 가능
• 안전성 증가
• 책임이 명확하게 분리됨

단점

• 소스 저장소 및 서버 분리
• 각 마이크로 서비스 간 네트워크 문제 발생 가능
• 각 서비스에 대한 모니터링 필요

 

 

5. SOA

 

기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재조합한 후, 이 서비스들을 서로 조합하여 업무 기능을 구현한 애플리케이션을 만들어 내는 소프트웨어 아키텍처입니다.

 

기존의 시스템이 각각의 독립된 업무 시스템으로 개발되었던 반면 SOA는 기업의 전체 업무가 하나의 거대한 SOA시스템으로 구성이 됩니다.

 

각각의 시스템의 기능들을 업무 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페이스를 구현하여 외부로 서비스 를 제공합니다.

 

새로운 업무를 구현할 때 새롭게 시스템을 신규 개발하는 것이 아니라 이미 제공되어 있는 기존의 서비스들을 조합하여 하나의 업무를 구현할 수 있습니다. 

 

소프트웨어의 재사용성과 레고웨어 의 연장성

 

급격한 비즈니스 환경의 변화에 따라 비즈니스 요구를 민첩하게 IT 시스템에 반영해야 하는 필요성이 생겼고, 각 업무별로 독립된 시스템의 형태로 개발되어 잇는 업무 시스템들을 통합하기 위해 SOA가 대두 되었습니다.

 

SOA는 "서비스와 이를 조합하여 애플리케이션을 구성 하는 것"

 

 

6. CQRS와 이벤트 소싱

CQRS는 Command and Query Responsibility Segregation(명령과 조회의 책임 분리)을 나타냅니다.

이름처럼 시스템에서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다. 이제 명령과 조회에 대해 정의할 필요가 있습니다. CQRS에서 명령은 시스템의 상태를 변경하는 작업을 의미하며 조회는 시스템의 상태를 반환하는 작업을 의미합니다. 

 

너무 단순하다고 생각될지 모르겠지만 이것이 전부입니다. 어쩌면 CQRS에 대한 오해는 CQRS가 생각보다 복잡하지 않기 때문일지도 모릅니다. 이 단순한 규칙이 몇 가지 응용기술과 조합되어 시스템에 적용되면 그 모습은 무척이나 다양합니다. 그만큼 CQRS를 설명하는 정보들이 표현하는 구현체의 모습이 제각각이고 여기서 혼란이 시작될 가능성이 있습니다. CQRS를 설명할 때 명령 처리기 패턴을 애기하기도 하고 다른 경우는 다계층 아키텍처나 이벤트 소싱을 다룹니다. 이것을 모두와 DDD를 조합하기도 합니다.

 

7. serverless

서버가 없다는 의미입니다. 이는 BaaS와 FasS, 이렇게 두 가지로 나뉘어질 수 있는데요, 서버가 없다는 건, 그냥푠일뿐 사실 작업을 처리하는 서버는 존재하기 합니다. 다만, "서버의 존재"에 대해서 신경쓰지 않아도 됩니다. 서버가 어떤 사양으로 돌아가고 있는지, 서버의 갯수를 늘려야 할지, 네트워크는 어떤걸 사용할지, 이런걸 설정할 필요가 없습니다.

 

BaaS(Backend as a Service)

 

보통 우리가 모바일 혹은 웹 애플리케이션을 만들게 될 때, 백엔드 서버개발을 진행하게 됩니다. 엄청 단순하게 생각하지면, 계산기, 혹은 그림판 수준으로 프론트엔드 쪽 코드로만 충분히 이뤄질 수 있다면, 백엔드 서버를 만들 필요가 없겠습니다. 하지만 데이터를 저장하고, 다른 기기에서도 접근하고, 공유하기 위해서는, 백엔드 개발은 필수적입니다.

 

서버 개발을 하다보면, 고려할 사항이 꽤 많습니다. 유저가 늘어나게 된다면 서버의 확장도 고려해야하고, 보안성 또한 고려해야합니다. 그래서 탄생한 서비스가, Firebase 같은 BaaS 입니다. 이 시스템에서는, 앱 개발에 잇어서 필요한 다양한 기능들(데이터베이스, 소셜 서비스 연동, 파일시스템등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현 할 수 있게 해주고, 비용은 사용한 만큼 나가게 됩니다. 서버의 이용자가 순식간에 늘어나게 되어도, 따로 대비를 안해주어도 알아서 확장이 됩니다.

 

장점

1. 클라이언트 위주의 코드

 

2. 가격

 

3. 복잡한 쿼리가 불가능함

 

 

FaaS(Function as a Service)

 

FaaS는 프로젝트를 여러개의 함수로 쪼개서, 매우 거대하고 분산된 컴퓨팅 자원에 여러분이 준비해둔 함수를 등록하고, 이 하무들이 실행되는 횟수만큼 비용을 내는 방식을 말합니다.

 

우리가 등록한 함수는 특정 이벤트가 발생했을 떄 실행됩니다.

• 주기적으로 실행되게끔 설정 할 수 있습니다. 5분마다, 1시간마다, 하루마다 이런식으로 말이죠, 크롤링 작업, 주기적 처리를 할 때 좋습니다.
• 웹 요청을 처리 할 수도 있습니다. 예를 들어서 특정 URL 로 들어오면 어떠한 작업을 하게끔 할 수 있습니다. 이를 통하여 백엔드 API를 구성 할 수도 있습니다.
• 콘솔을 통하여 직접 호출 할 수도 있습니다.