Redis

들어가며 ACOR v1.3.0에서 HTTP와 gRPC 서버 어댑터가 추가되었다. 이제 ACOR을 마이크로서비스 아키텍처에 쉽게 통합하거나, 별도의 서버로 배포할 수 있다. 이 포스트에서는 두 어댑터의 사용법과 배포 방법을 살펴본다. 아키텍처 개요 v1.3.0에서 pkg/server 패키지가 추가되어 기존 pkg/acor API를 HTTP JSON과 gRPC로 노출한다: ┌ │ └ ─ ─ ─ ─ ─ ─ ─ C ─ ─ l ─ ─ i ─ ─ e ─ ─ n ─ ─ t ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ ┘ ─ ─ ─ ─ ▶ ┌ │ │ └ ┌ │ └ ┌ │ └ ─ ─ ─ ─ ─ ─ ─ H ─ ─ ─ ─ ─ ─ T ─ ─ p ─ ─ ─ ─ T S ─ ─ k ─ ─ ─ ─ P e ─ ─ g ─ ─ R ─ ─ / r ─ ─ / ─ ─ e ─ ─ g v ┬ │ ▼ a ┬ │ ▼ d ─ ─ R e ─ ─ c ─ ─ i ─ ─ P r ─ ─ o ─ ─ s ─ ─ C ─ ─ r ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ │ ┘ ┐ │ ┘ ┐ │ ┘ HTTP 서버 기본 사용법 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 package main import ( "log" "net/http" "github.com/skyoo2003/acor/pkg/acor" "github.com/skyoo2003/acor/pkg/server" ) func main() { ac, err := acor.Create(&acor.AhoCorasickArgs{ Addr: "localhost:6379", Name: "sample", }) if err != nil { log.Fatal(err) } defer ac.Close() httpHandler := server.NewHTTPHandler(ac) http.Handle("/", httpHandler) log.Println("HTTP server listening on :8080") log.Fatal(http.ListenAndServe(":8080", nil)) } API 엔드포인트 Method Path 설명 POST /add 키워드 추가 POST /remove 키워드 삭제 POST /find 텍스트 검색 POST /find-index 위치 정보와 함께 검색 POST /suggest 자동완성 제안 POST /suggest-index 위치 정보와 함께 자동완성 GET /info 컬렉션 정보 POST /flush 컬렉션 삭제 요청/응답 예제 키워드 추가 ...

들어가며 ACOR v1.3.0에서 Redis 관련 두 가지 중요한 개선사항이 추가되었다. 첫째, 다양한 Redis 토폴로지(Sentinel, Cluster, Ring)를 지원하게 되었고, 둘째, Redis 통신 중 발생하는 에러를 명시적으로 처리하도록 API가 개선되었다. Redis 토폴로지 지원 문제 상황 v1.3.0 이전에는 단일 Redis 인스턴스(Addr)만 지원했다. 프로덕션 환경에서는 고가용성을 위해 Redis Sentinel을 사용하거나, 대용량 데이터 처리를 위해 Redis Cluster를 사용하는 경우가 많다. ACOR을 이런 환경에서 사용하려면 별도의 작업이 필요했다. 해결 방법 v1.3.0에서는 AhoCorasickArgs 구조체에 토폴로지별 필드를 추가하여 다양한 Redis 배포 방식을 지원한다: ...

들어가며 ACOR v1.3.0에서 새로운 커맨드라인 도구 acor가 추가되었다. 이제 Go 코드를 작성하지 않고도 터미널에서 바로 Aho-Corasick 오토마톤을 조작할 수 있다. 이 포스트에서는 CLI의 주요 기능과 사용법을 살펴본다. 설치 바이너리 다운로드 GitHub Releases에서 플랫폼별 바이너리를 다운로드할 수 있다: 1 2 3 4 5 6 7 8 9 # macOS (Apple Silicon) curl -LO https://github.com/skyoo2003/acor/releases/download/v1.3.0/acor_1.3.0_darwin_arm64.tar.gz tar xzf acor_1.3.0_darwin_arm64.tar.gz sudo mv acor /usr/local/bin/ # Linux (x86_64) curl -LO https://github.com/skyoo2003/acor/releases/download/v1.3.0/acor_1.3.0_linux_amd64.tar.gz tar xzf acor_1.3.0_linux_amd64.tar.gz sudo mv acor /usr/local/bin/ 소스에서 빌드 1 2 3 git clone https://github.com/skyoo2003/acor.git cd acor make build 빌드된 바이너리는 bin/acor에 생성된다. ...

들어가며 Aho-Corasick 알고리즘은 다중 패턴 문자열 검색을 위한 고전적인 알고리즘이다. 사전에 등록된 여러 키워드를 입력 텍스트에서 동시에 효율적으로 찾을 수 있어, 스팸 필터링, 민감 정보 탐지, 자동완성 등 다양한 영역에서 활용된다. ACOR은 이 Aho-Corasick 알고리즘을 Go로 구현하고 Redis를 백엔드 저장소로 사용하는 라이브러리다. v1.3.0에서는 기존 API를 확장하여 매칭된 키워드의 위치 정보를 제공하는 Index APIs가 추가되었다. 이 포스트에서는 FindIndex와 SuggestIndex API의 설계와 구현을 심층 분석해본다. 기존 API와의 차이점 v1.3.0 이전에는 Find와 Suggest 두 가지 검색 API가 있었다: ...

들어가며 ACOR v1.2.0을 릴리즈했다. 이번 버전은 프로젝트 구조를 Go 표준으로 정리하고 몇 가지 버그를 수정하는 데 집중했다. 표준 프로젝트 구조로 변경 v1.2.0에서는 Go 커뮤니티의 표준 프로젝트 레이아웃을 따르도록 구조를 변경했다 (#2). Go 프로젝트가 성장하면서 파일 구조를 체계적으로 관리할 필요가 있었다. Standard Go Project Layout 가이드라인을 참고하여: pkg/: 외부에서 import 가능한 패키지 코드 internal/: 내부 전용 코드 cmd/: 메인 애플리케이션 이런 구조를 적용함으로써 프로젝트의 의도를 더 명확히 전달할 수 있게 되었다. 지원 Go 버전 변경 Go 버전 지원 정책을 업데이트했다 (#5). ...

들어가며 ACOR v1.1.0을 릴리즈했다. 이번 버전은 새로운 기능 추가보다는 프로젝트의 기반을 현대화하는 데 집중했다. Go 생태계의 변화에 맞춰 의존성 관리와 CI/CD 시스템을 최신 표준으로 전환했다. 왜 Go modules로 전환했는가 ACOR은 처음 Glide를 사용해 의존성을 관리했다. Glide는 Go에 공식 의존성 관리 도구가 없던 시절, 커뮤니티에서 널리 사용되던 도구였다. 하지만 Go 1.11부터 Go modules가 공식으로 도입되면서 상황이 바뀌었다. Glide의 한계는 명확했다: 유지보수 중단: Glide는 더 이상 활발히 개발되지 않는다 버전 관리: 정확한 버전 고정과 의존성 트리 관리가 번거롭다 재현성: 다른 환경에서 동일한 빌드를 보장하기 어렵다 Go modules는 이 문제들을 해결한다. go.mod 파일 하나로 의존성을 관리하고, Semantic Versioning을 기반으로 버전을 제어한다. 무엇보다 Go 도구 체인에 내장되어 있어 별도 설치가 필요 없다. ...

들어가며 문자열 검색은 소프트웨어 개발에서 자주 마주치는 문제다. 특정 키워드 하나를 찾는 것은 간단하지만, 수백 개의 키워드를 동시에 찾아야 한다면 어떨까? 각 키워드마다 텍스트를 순회한다면 비효율적일 것이다. Aho-Corasick 알고리즘은 이 문제를 우아하게 해결한다. 1975년 Alfred V. Aho와 Margaret J. Corasick이 개발한 이 알고리즘은 여러 패턴을 동시에 효율적으로 검색할 수 있다. ACOR은 이 Aho-Corasick 알고리즘을 Go로 구현하고 Redis를 백엔드 저장소로 사용하는 라이브러리다. 이 포스트에서는 ACOR의 소개와 Aho-Corasick 알고리즘의 기본 개념, 그리고 사용법을 살펴본다. ...