📌서비스 원페이지 Notion https://www.notion.so/PIN-TABLE-3985986345c640969a8a8a5c3cabb3e1 [PIN-TABLE] 스토어 웨이팅 플랫폼 💁🏻‍♂️ 01 | 프로젝트 소개 [Pin-Table] www.notion.so 📌 Team Notion https://www.notion.so/Pin-Table-f3dbbfb5b8b546e186122be5fa2694e9 📌 Github https://github.com/pirate99-FinalProject Pintable Pintable has 3 repositories available. Follow their code on GitHub. github.com 📌 블로그 포스팅 https://kyuu-ng.tist..

사나이가 칼을 뽑았으면 무라도 썰어야한다고 했다-! 항해를 하면서 제일 욕심났던 상장을 받았다. 이거보다 더 기쁜게 있을까 〰️ 😚 그간의 노력들을 인정받은것 같아 기쁘고, 외로운 챌린지였지만 역시나 잘했다는 생각이 든다 !!! 2차 전직을 고민할때 누군가는 나한테 이미 탄탄대로를 잘 다져놓고 왜 굳이 힘든길을 가려고 하냐 라는 말을 했었다 쉬운길도 많은데 그동안의 경력을 다 내려놓고 다시 공부부터 시작하는건 쉽지 않은 고민이긴 했다. 내가 엔지니어하면서 가장 힘든 순간이 뭐였어요?라고 묻는다면 한 여름에 서버실에서 냉방병 걸렸을때도 아니고 랜선 정리하면서 사다리랑 바닥 탔을때도 아니고 내가 다루는 제품이 도대체 어떻게 돌아가는지를 3년이 됐음에도 모르겠다는 것 그리고 매일 똑같은 문제가 여러 고객사에서..

아키텍처 구성 시 대용량 트래픽을 부하분산을 할 수 있도록 설계를 하였고, 드디어 성능을 테스트해볼 차례!! 챌린지의 꽃은 아무래도 대용량 트래픽 부하분산이 아닐까 싶다 🤔 🖥 목표 - 주말이나 특정 기념일의 경우 서비스 이용자가 증가하게되는데, 대용량 트래픽이 발생할 것을 대비하여 시스템 정상 동작 작동 여부 확인 및 응답 성능 확인을 위함 - 최대 5000 User 2% 이하의 오류율로 서비스를 하고자 함 🎒 기술적 선택 시스템 부하 분산을 위해 적용한 기술 스택 Scale-Out (AWS EC2) 사용 이유 : 한 대의 Ec2 리소스를 증가(Scale-Up)시켜서 성능향상을 할 경우 장애 상황 발생 시 장애 대처에 어려움 📈 시스템이 정상화 되기 전 다운타임 발생이 불가피함 EC2를 2대로 운용하여..

실전에 들어오면서 처음으로 겪어보고 많이 고민했던 부분인 동시성 제어 🤔 어떨때 동시성 제어가 필요하고, 어떻게 제어해야할까?!에 대해 엄청나게 많이 고민했던 것 같다. 동시성 제어 왜 필요한데? 💁 핀테이블은 예약과 스토어 정보 조회 등 여러 기능을 제공하는데, 이중에서 대기자 등록과 스토어 정보 갱신 부분에서 동시성 오류가 발생하였다. 동시성 오류는 어떠한 공유 자원에 동시에 작업이 이루어질 때(insert, update, delete 등) 실행 순서가 뒤죽박죽이 되면서 오류가 생기는것이였는데 동시성 제어를 통해 여러 트랜잭션들이 성공적으로 동시에 실행될 수 있도록 해주어야했다. 그럼 공유자원을 쓰는곳에는 다 Lock을 걸면 되는거 아니야? 🙅🏻 동시성 오류가 발생하는 부분에 모두 Lock을 걸어서 ..

프로젝트를 시작하면서 팀장으로서 제일 고민이 많았던 부분은 어떻게 해야 효율적인 업무 분배를 할 수 있을까? 이 기능은 어떤 분께 맡기는게 좋을까? 였다. 항해 특성 상 프로젝트 기간이 길지않아서 효율적인 분배가 필요하고, 팀원분들 모두 잘하시는분이지만 우리는 약간 밀짚모자해적단st여서 각자 개성이 있는 사람들로 엮여있어서 역할 분배가 많이 중요했다. 검색 성능 부분은 어떻게보면 우리 프로젝트에서 코어기술 중에 코어기술이였다고 볼 수 있는데 이 부분은 우리 나미 상훈님께 부탁드렸다! 상훈님은 이 당시 select 쿼리정도 알고 계셨는데 상훈님께 검색성능을 부탁드렸던 이유는, 6주간 지켜봤을 때 상훈님은 어떤 어려운일도 시간만 드린다면 어떻게든 해내는 분이셨기 때문에 상훈님에 대한 무한신뢰가 있었다 🙂 검..

최종발표까지 하고 난 이 시점에 회고하면서 생각하자면 정녕 챌린지에는 프론트 팀원이 필요없는것이 맞는가? 하는 의문이 든다. 분명 시작할때는 "프론트적인 요소는 정말 아무것도 없어도 돼요! 버튼 하나만 있어도 됩니다!" 하셨지만 인간의 심리라는게 멋있고 예뻐보이는 프로젝트에 관심이 있지 버튼 하나만 있는 프로젝트 ,, 누가 깊이 들여다 봐줄까 ,, 쏟아지는 최종 발표회에서 시선을 끄려면 프론트적인 부분도 절대 포기할 수 없다고 생각했고, 챌린지팀이라는 존재를 모르는 관람객이 보았을 때 "여기는 화면이 왜이래?"라는 소리를 듣지 않는것이 내 목표고 바램이였다 이 시간에 조금 더 챌린지적인 부분을 꼼꼼히 하는게 좋지 않을까?라는 생각도 잠깐 했지만 어쩔수 없이 보여지는 화면이 부실하면 프로젝트의 완성도가 낮..

데이터 수집을 하면서 두번째로 고민했던 부분은 아키텍처 설계 부분! 그동안 좋아보이는 기술들을 아무런생각없이 그냥 가져다 썼다면 실전 프로젝트에서는 어떠한 기술을 선택할 때 끈적하게 고민해보고 이 기술을 꼭 사용해야하는 이유를 생각한 후 선택하기로 했다. 내가 아키텍처 설계 시 중점을 두고 고민했던 부분은 아래와 같다. 1. 매번 기능을 만들 때 마다 배포를 내가 직접해야한다면 ?.. 난 프로젝트 기간 내내 배포만 해야할 것이다. 2. 대용량 트래픽을 발생시키고 버틸 수 있는 안정적인 서비스를 구현하려면 어떻게 해야할까? 3. 검색 성능을 향상하려면? 어떤 방법이 있을까? 시스템 엔지니어를 했던게 이런 부분에서 조금은 도움이 되지 않았을까 싶다 🥺 개발적인 아키텍처는 아직 잘 몰라도 인프라 적인 부분에서..

실전 프로젝트가 끝나고 그동안 정리해뒀던 고민들의 조각모음을 포스팅 하려고 함 ✏️ 하면서 그때그때 정리하고나서 올리고 싶었지만 .. 더이상 우리 프로젝트의 생각과 아이디어들을 빼앗기고싶지않았음 :( 젭알 그만가져가~!!!!!!! 나도 힘들게 생각한거라구우우우~!!!!!!!!! 서비스 기획 챌린지팀에 기획에 있어 가장 중요한점은 이러한 주제를 선택 했을 때 "1000만건의 데이터를 수집할 수 있는가?" 였다. 첫주에 기획을 할 때 팀원분들이랑 하루에 8시간 넘게 과장 안하고 정말 하루종일 얘기했다고 해도 과언이 아니였다. 이건 어떨까요? 저건 어떨까요? 좋은 아이디어가 많이 나왔었는데 1000만건의 데이터를 수집할 수 있는 주제는 생각보다 많지 않았다. 찾다찾다 이전 기수의 기록지를 찾기도했었는데 정한 ..

드디어 끝나지 않을 것 같던 실전 프로젝트가 끝이 났다 ! 🥺 아키텍처 설계부터 썸네일 제작까지 하나부터 열까지 손길이 안닿은곳이 없었는데 미미의 저축은행 수준이였던 우리 프로젝트가 어느새 6주를 지나서 누군가에게 소개할만한 프로젝트가 되었다는게 감회가 참 새롭다 서비스팀이라는 안전한 선택지를 두고 챌린지팀이라는 모험을 시작하는것을 고민했을 때 챌린지는 사실 쪽박 아니면 대박일거라고 생각했는데 사실 쪽박쪽에 가깝다 생각했었다 서비스팀보다 기존 레퍼런스들도 많이 없을뿐더러 프론트도 디자이너도 없는 프로젝트라니! 백엔드가 가진 기술만으로 휘황찬란한 서비스팀보다 눈에 띄는것 .. 쉽지않다고 생각했음 ,. 하지만 그것만큼 잘 그려나간다면 엄청난 매리트 있는 팀이라고도 생각했다! 백엔드 기술들을 메인으로 내가 하..

오늘은 하루종일 Elastic Search와 싸우고 있었는데 기나긴 싸움 끝에 집나간 데이터 2,123,148건을 되찾았다! 계속 200만건을 읽으면서도 1건만 저장되서 뭔가 이상하다 .. 했는데 ID 값의 문제였다 랜덤하게 생성되지않고 동일한 ID로 계속 생성되고 있었당 ㅎ ; 트러블슈팅을 하면서 ELK 동작 프로세스에 대해서 어쩔수없이 알게됐는데 ELK 만만하게 봤는데 생각보다 러닝커브가 좀 있다 .. 미리 공부 좀 할걸 😅 ELK는 생각보다 참고할문서가 많지않아서 조금 당황했움 ! 그래도 1일차에 logstash를 이용해서 Mysql에 있는 데이터를 ElasticSearch로 데이터를 동기화하고, ElasticSearch에 동기화 된 데이터를 Kibana에서 조회할 수 있게 끔 한건 나룸 되게되게 ..

이번주에 들어서부터 여러 기능을 조금씩 파기보다는 한 기능에 집중해서 분석하고 공부하는 시간을 가지고 있다 그게 진정한 챌린지팀의 묘미라고 해서 ,, 👀 월요일에는 테스트코드(Junit), 동시성제어에 대해서 공부를 하였고 화요일~수요일에는 공부한것을 바탕으로 내 프로젝트에 적용해보고, 내가 성능 개선할 기능에 대해 뜯어보는 시간을 가졌다. 아래의 내용은 오늘 내가 기능을 뜯어보면서, 어떻게 구현할지 고민을 한 부분이다 ! 스토어 정보 업데이트, 어떤 시점에 어떻게 처리해야할까 ? 🤔 기능 : 스토어정보(별점 & 방문자 리뷰 갯수) 업데이트 기능 기능 명세 : 정보가 업데이트 된 스토어가 있을 경우 주기적으로 확인하여 정보를 갱신하는 기능 구현 방향 : 사용자 리뷰 등록 시 상태가 업데이트 된 스토어 정..

이번주는 중간 발표 후 피드백 받은 내용을 기반으로 한 주를 열심히 달렸당 🏃🏻‍♀️🏃🏃‍♂️ 금주 팀 목표 및 개인 목표는 아래와 같음 ! 이번 주 한 일 회고 이번주 한 일 팀 전체 미구현 된 mvp 기능 완성 미구현 기능 List 장소 마커 클릭시 별점 / 리뷰 수 조회 기능 장소 마커 클릭시 웨이팅 현황 조회 기능 (기존에는 웨이팅후에 확인 가능) 사용자 유효성 검사(이메일 요청) 기능 웨이팅 입장 호출(이메일 요청) 기능 장소 마커 클릭 시 리뷰 조회 기능 최대 수용 가능 인원 설정 기능 개인 목표 리뷰 등록/조회 기능 개선 적용 ( Redis Cache + Scheduled + Spring Batch ) 사용자 유효성 검사(이메일 인증) 기능 구현 - BE / FE 웨이팅 호출 기능 구현 - ..

지난주 중간 발표 후 이번주에는 MVP 기능 중 추가가 필요하거나, 개선이 필요한 기능을 우선적으로 만들기로하였다. 우리의 이번주 목표는 위와 같고! 내가 해야할일은 사용자 유효성 검사(이메일) 기능 구현, 웨이팅 호출 기능 구현, 스토어 리뷰 조회 기능 구현 부분이다! 도커 무중단 배포는 해둔다고 쓰긴 했지만 지금 당장 필요할까 ?? 싶어서 이번주에 할지 말지는 고민중이다 맘먹고하면 한 두어시간쯤이면 되지 않을까 생각즁 🤨 이메일 인증 기능 구현(사용자 유효성 검사) 이메일 인증 구현을 만들게 된 사유는 회원 가입만으로도 충분히 사용자에 대한 검증을 했다고 볼 수 있긴 하지만 JWT나 요런걸 사용하지 않기 때문에 추가적인 유효성 검사를 하려는 니즈도 있었고, 웨이팅 예약중인 사용자가 입장 대기상태일 때..

이번주는 지난주에 나태지옥에 빠진 이유로 한 주간 엄청나게 바빴다 💨 실전에 들어오고나서 뭔가 확실한 목표치?가 없다보니 조금 루즈해진감이 없지않았는데 이번주 토요일에 중간 발표 직전에 계획을 거의 80% 이상 수정하면서 엄층나게 바빠진 것 ㅋㅋㅋㅋㅋㅋㅋㅋ 사슴공부법을 프로젝트에도 적용하게 될줄은 몰랐지 나도 .. 무튼 발표날 새벽 4시까지 팀원분들이랑 웃샤웃샤하면서 중간 발표 자료도 잘 만들고, 영상도 잘 찍어내고! 프론트도 하은님의 피드백과 + 시넌님의 손기술로 검수받아서 든든한 마음으로 중간 발표를 진행했다.! 두둥 대망의 중간발표 😎 챌린지팀의 경우 2주차에 중간발표를 하고, 나머지 4주동안 성능 개선을 진행한다. 우리는 핀테이블 이라는 서비스를 만들었는데 지도앱을 통해서 지도를 검색할 수 있고,..

실전 프로젝트 시작한지 얼마 안된 것 같은데 벌써 내일이 중간 발표 .. !!!! !!!! 중간발표까지 2주라는 시간이 주어졌는데 기획 부분에서 반, 파이썬 크롤링 하는데 2/3의 시간을 쓰고 실제 코드는 2~3일만에 후다닥 짠 것 같다 이번에 어쩌다보니 스프링 코드는 다른 팀원분들이 거의 다 짜주시고 나는 프론트 코드랑 ,, 파이썬 위주로 짜게 되었는데 챌린지팀은 프론트 팀원이 없는 대신 간소화 하게 작성해라 ! 거의 없듯이 해라 ! 라고 항해 측에서 설명해준것과 다르게 뭔가 하려면 웹이 계속 계속 필요했다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 새로이 공부하는게 싫어서 html, css, js로만 꾸역꾸역 구현했었는데 우리가 원하는 기능을 구현하려면 더이상 이대로 진행할수가없어서 오늘 리액트 기술매니저님의 조언을 ..