팀 프로젝트 10일차 회고 & 기술 회고

·2022년 5월 19일
0

팀 프로젝트

목록 보기
12/34

여전히 ELK을 많이 쓰게 되는 날이였다.

재미야 있지만, 실제로 이것을 쓸 수 있는 기회가 오지 않을 것 같아서 아쉬울 따름이다.

조금 더 빠르게, 이제는 쉴 시간이 없다.

현재 팀프로젝트의 현황은 백엔드의 api 개발은 상당히 많이 진행이 되었고
페이지 CSS 작업이 이루어지며, 지도를 활용한 rest api와 toast ui를 이용한 웹 에디터 작업이 진행되고 있다.

상상한 것보다 페이지가 상당히 많이 나와서, 작업의 양이 많다보니 기능 추가에 대해서 이야기 했던 것을 최대한 쳐내고
일단 페이지가 나오면 바로 api를 활용하는 작업이 들어가야한다고 이야기를 했다.

팀장이자 PM의 역할을 맡고 있다보니 이런 것들도 조율이 필요하다고 느꼈다.
그리고 어쩔 수 없이 나오는 타임어택 개발의 시작이랄까.... 마감에 맞춰서 개발을 해야하는 상황이 제대로 벌어졌다고 생각한다.

언제나 집단에는 착한 사람과 나쁜 사람이 있는 것처럼,
어쩔 수 없이 리더의 역할을 하고 있는 상태에서는 좋은 사람이 되는 것은 힘들다고 생각한다.

물론 능력없는 리더는 더더욱 가치가 없기에 더욱 더 노력을 하고 작업을 하며 최대한 조율을 해주며 진행을 하고 있지만
나만의 생각일 수도 있고, 어떻게 생각하고 있는지는 솔직히 모르겠다.

집중과 선택

api가 어느정도 나오다보니 고민이 생긴 부분이 존재했다.
이것은 진도가 빠른 몇 팀에서 발생하고 있는 문제로 확인이 되고 있는데

  1. 뭔가 새로운 라이브러리와 프레임워크를 활용하여 무언가를 추가할 것인가?
  2. 지금까지 만들어놓은 것들의 TDD 작업을 통하여 조금 더 정교한 api를 구성을 할 것인가?

이 두가지의 경우의 수로 이야기가 많이 오가게 되었다.

사실 기획이 잡혀있다보니, 기획의 방향성이 크게 뒤틀리는 것에 대한 작업은 무리가 있다보니
추가를 한다는 것이 쉽게 나오지 않았다.

몇명과 이야기해본 것으로는 텐서플로우를 사용하여 인공지능을 학습시켜서 19금 필터링이라던가 욕설 필터링 같은 것을 고려하고 있다고는 하는데 정말 마땅하게 추가를 해야할 수 있는 것들이 생각나지 않았다..

그래서 일단 지금 뿌려놓은 작업에 대한 리팩토링 및 다양한 문서화 작업을 하고
페이지가 작업이 되었을 경우에서야 할 수 있는 몇개의 작업을 남겨놓고는
백엔드쪽은 조금 더 집중에 포커스를 맞춰서 작업을 진행하고 있다.

Logstash Multiple Pipelines

작업을 하다보니 권한이 나누어지는 게시판이 생겨나게 되어서, 이것에 대한 제목 검색을 어떻게 하는 것이 좋을까? 라는 고민을 하게 되었다.

하지만 관계형 데이터베이스에서 일부를 검색하는 것이 불가능하지 않나, 라고 판단이 들어서 열심히 사용하고 있던 ELK에
여러가지의 conf 파일을 만들어서 사용하는, 멀티플 파이프라인을 구성하게 되었다.

예전부터 해보고 싶었던 작업이였는데, 생각보다 정보가 없었고(...) 너무 빈약해서 도대체 이걸로 뭘 어떻게 하라는거지? 라는 생각을 하고 있었는데,

정말 별게 없어가지고 좀 당황했다(^^..)

구성하는 방법

일단 여러개의 conf 파일이 있어야한다, Multiple이니까(?)
그리고 그것에 대한 Path를 pipelines.yml 에 적어줌으로써 적용을 시킬 수 있다.

이런식으로 id와 config의 Path를 지정해주고, workers는 일하는 작업의 수를 지정할때 사용한다.
정의를 안하면 디폴트 값이 있는 것으로 파악되는데 그냥 내가 참고했던 많은 글에 1이 들어가있어서 집어넣어놨다(??)

아, 여기서 중요한 점이 있는데, conf의 Path는 실제로 도커 내부에 들어가게 되는 Path를 입력해줘야한다.

yml 파일에 대한 자세한 설정값 => https://www.elastic.co/guide/en/logstash/current/logstash-settings-file.html

그리고 docker-compose의 logstash volums에 모든 것을 적어주면 적용이 되는 것을 확인할 수 있다.

mysql에서도 일부만으로 검색하는 query가 존재했다.

모양은 이렇게 생겼다. like를 활용한 문법이라고 생각하고는 있다.

board.boardTitle의 data중에서 일부라도 있는 것을 가져오는 쿼리문을 이렇게 사용한다.

뭔가 elasticsearch의 Ngram이 많이 생각나는 구조랄까..
실제로는 이게 풀텍스트 검색이라고 속도가 상당히 느리기 때문에 활용은 잘 하지 않는다는 이야기를 듣긴 했는데

그래도 있는데도 지금까지 몰라서 고민을 했다는게......

profile
물류 서비스 Backend Software Developer

0개의 댓글