속닥속닥

스프린트 1, 2, 3때 인프라 쪽을 전혀 다루지 않다가 4에 들어서 인프라를 다루게 되었다. 앞서 인프라를 담당했던 팀원들에게 간단하게 인수인계를 받았는데 막상 해보려하니 생각하지 못했던 부분에서 막히는 경우가 있었다. 이번에도 소나큐브를 실행시키려는데 명령어를 잘친

부하테스트 툴을 선정하는데 JMeter, nGrinder, k6 중에서 고려를 했다.k6의 경우 결과 시각화를 하려면 유료로 서비스를 쓰거나 CLI로 쓰고 그라파나와 결합을 해야했다. 또 자바스크립트로 테스트를 작성해야해서 거부감을 갖는 팀원도 있었다. JMeter는

환경을 어떻게 설정하고 테스트해야할지 감이 잘 오지 않아서 실험을 여러번 다시했다. 그리고 아직도 완전히 정답을 찾은 것 같지는 않지만 나름대로 이유를 세우면서 테스트를 해보려했다. 1\. Nginx에 부하테스트 vs WAS에 부하테스트처음에는 Nginx 인스턴스에 부

이번 스프린트 요구 사항에 무중단 배포가 있었다. 실제로 예전에 별 생각 없이 저녁 시간에 배포를 하다가 '속닥속닥 왜 지금 안돼요?'라는 말을 들은적이 있어서 이번 무중단 배포에 관심이 갔다. 새로운 기능이 추가되거나 버그가 수정되어 배포를 할 시 서비스가 잠깐 멈추

이 글은 이스트와 함께 작성한 글입니다. 속닥속닥 프로젝트(https://github.com/woowacourse-teams/2022-sokdak)를 진행하면서 현재는 문제가 되지 않지만 시간이 갈수록 데이터가 쌓이면서 문제가 될 수도 있겠다라고 생각한 부분이

프로젝트를 하면서 DB 인스턴스가 하나 밖에 없어서 불안했었다. 혹시나 어떤 실수를 해서 DB를 날리거나 정상작동 하지 않으면 대응을 할 수 없었기 때문이다.또 조회용 DB와 데이터 쓰기용 DB를 분리하면 성능을 개선할 수 있다는 얘기를 들어서 궁금했다. 그래서 고가용

이전 글에서 Replication 원리와 아키텍처에 관해 다뤘다. 이제 실제 어떻게 진행했는지 정리한다. 레플리카 서버에서 소스 서버의 바이너리 로그 파일명과 파일 내에서의 위치(Offset 또는 Position)로 개별 바이너리 로그 이벤트를 식별해서 복제가 진행되는