perseverance

배경현재 프로젝트로 개발중인 snappy라는 서비스에서는 여러 사용자가 촬영한 사진을 다음과 같이 보여주게된다. 현재 각각의 사진들은 사용자가 촬영한 원본 사진 그대로 홈화면에서 사용중이다. 서비스의 특성상 사진을 확인하는 사용자가 많을텐데 이렇게 원본 사진을 그대로 사용자에게 보여주는 것은 네트워크 지연뿐만아니라 네트워크 트래픽도 많아져 aws에 지불해야할 요금이 서비스가 커지면 커질수록 높아질 것이다. 또한 사진뿐만아니라 모임의 logo 이미지 등 원본 이미지의 크기가 필요없는곳에 불필요하게 원본 이미지 크기만큼 다운받고 있어 이또한 문제가 된다.   잘 생각해보면, UI에 맞는 크기의 이미지를 불러오면 원본 이미지를 불러오는 것에 비해 속도도 더 빠르고 네트워크 트래픽도 더 낮아질 것이다.그럼 어떻..

도입저번시간에 작성한 성능 테스트 자동화 환경 구축기(1)에 대한 내용을 정리해 보면, 성능 테스트를 위해 여러 가지 요소들이 필요했다. 우선, 성능 테스트를 위한 대량의 요청을 생성해주는 nGrinder, 서버 상태를 모니터링할 수 있는 PinPoint, 그리고 성능 테스트 대상이 되는 API 서버를 AWS 상에 구축해야 했다. 이를 위해 우리는 Terraform을 활용하여 AWS 자원(EC2, VPC, RDS 등)을 코드로 관리할 수 있도록 설정하였다. 하지만 단순히 AWS 자원을 콘솔이 아닌 코드로 관리할 수 있게 되었다고 해서 성능 테스트 자동화 환경을 구축했다고 말할 수는 없다. 그렇다면, 진정한 의미에서 성능 테스트 자동화 환경을 구축했다고 말하려면 무엇이 더 필요할까?자동화의 필요성성능 테스..

배경서비스를 실제로 사용자에게 공개하기 전에 해야 할 중요한 작업 중 하나는, 내가 만든 서버가 어느 정도의 사용자 유입을 감당할 수 있는지를 파악하는 것이다. 이를 알아낸다면 예상되는 사용자 수를 기준으로 서버를 개선하고, 안정적인 서비스를 제공할 수 있다.나 역시 DND 프로젝트에서 snappy라는 서비스를 개발하면서, 사용자에게 서비스를 공개하기 전에 서버가 어디까지 버틸 수 있는지 확인하고 싶었다. 그래서 성능 테스트를 도입해보았고, 이번 테스트 과정에서 어떤 문제들이 있었는지, 그리고 그 문제들을 어떻게 해결해 나갔는지에 대해 작성해보려 한다.성능 테스트성능 테스트를 하려면 무엇이 필요할까? 우선 가장 먼저 생각나는 것은 내가 만든 서버이다. 서버는 이미 만들어 놓았기 때문에 이 부분은 문제없다..

DND라는 IT 동아리에서 프로젝트를 기획할때 우리가 중요하게 생각한 한가지는 바로 로그인 없이 사용자가 접근할 수 있게 하는거였다. 로그인이 있다면 귀차니즘이 강한 사용자는 바로 나갈게 뻔하다. 나또한 로그인이 있어야 사용할 수 있는 서비스를 보다보면 그냥 나가기 일쑤였다. 하지만 로그인없이 사용자가 했던 행동들을 다 어떻게 기억할 수 있단 말인가? 우리가 개발하기로 한 프로젝트에서는 로그인은 없지만 사용자가 촬영한 사진, 사용자가 참여하고 있는 모임, 사용자가 모임에서 사용하고 있는 닉네임 등을 알고 있어야 했다. 로그인의 주 역할은 해당 요청을 보낸 사용자가 누구인지 알려주는 역할을 한다. HTTP는 상태를 유지하지 않는 프로토콜이라는 것은 네트워크를 배우다 보면 누구나 접하는 개념이다. 그렇기 때..

현재 진행중인 프로젝트에서 쪽지 관련 API를 만들면서 겪었던 문제들을 어떻게 해결하였는지 적어보려 한다.1. Table 설계현재 구현하려는 쪽지 기능은 카톡과 같이 한사람이 여러 채팅방을 가질 수 있으며 각각의 채팅방은 1대1 채팅방을 기본으로 한다.이를 바탕으로 처음 설계한 Table은 다음과 같다.user table은 간략히 표현해 보았다.각각의 컬럼을 설명하자면 다음과 같다.[room table]id: pk값last_content: 해당 채팅방의 마지막 쪽지 내용time: 해당 대화방에서 마지막으로 주고받은 쪽지 시간sender_id: 최초로 쪽지를 보낸 user의 pk값 (fk)receiver_id: 최초로 쪽지를 받은 user의 pk값 (fk)sender_is_deleted: 최초로 쪽지를 보..