분류 전체보기 (29) 썸네일형 리스트형 [INFRA/DB] 롤백을 고려해 하위호환성을 갖춘 스키마 설계하기 📑 Table of Contents📝 롤백을 고려하게 된 이유🤔 스키마는 어떻게 롤백할 수 있지?🙋 첫 시도, 롤백용 스크립트를 작성하기🔍 스키마 롤백, 꼭 필요한가? ✅ flyway 를 사용함으로서 하게 된 오해 ✅ SRE 원칙을 통한 깨달음🚀 Expand and Contract 전략 ✅ 예시로 이해해보기 ✅ DDL 별 원칙🚀 Flyway 설정 일부 변경🚀 시드 데이터가 필요한 경우, R prefix 사용하기📝 롤백을 고려하게 된 이유지난 1개월하고도 몇주간의 프로젝트를 진행하는 상황에서, 우리는 잦은 요구사항의 변화를 겪게 됐다. 이에 따라 코드는 빠르게 변경이 이뤄졌고, 버그 픽스도 심심찮게 필요했다. 그러나 QA 를 하거나, 데모데이를 해야 하는 .. [INFRA] 보안을 고려해 서버 아키텍처를 설계해 보자 📝 들어가며우리는 기존에 dev 서버만 존재했고, prod 서버는 존재하지 않았다.prod 서버를 구축하는 과정에서 보안을 고려해 설계한다면, 어떤 설계를 할 수 있을지에 대한 고민을 시작했다. 그 과정에 대해 기록해보고자 한다.1️⃣ 인바운드 규칙우리가 가장 먼저 고려한 것은 인바운드 규칙이었다. 현재 AWS 의 ec2 를 이용해 서버를 구축한 dev 서버에서의 인바운드 규칙은 모두에게 열려 있었다. 22번 포트는 우테코 규약에 따라 특정 IP (우테코 캠퍼스 내부) 만 접속할 수 있었으나, 나머지 포트들은 모든 IP 가 접근할 수 있었다.클라이언트가 직접 사용하는 IP가 결국 dev 서버의 IP 였기 때문에, 악의적인 사용자가 해당 IP로 대량의 요청을 보내면 서비스가 쉽게 다운될 수 있는 구조였다.. [우아한 테크코스 7기] 레벨3를 돌아보며 📝 들어가며레벨3 는 그 어떤 레벨보다 치열하고, 재밌고, 시간이 빠르게 흘러 갔다. 아쉬움과 뿌듯함이 공존하는 시간들이었다. 레벨3 를 통해 다양한 경험을 해왔지만, 가장 인상적이었던 것은 ‘진한 협업’이다. 그동안 사이드 프로젝트나 대학교 내에서의 팀프로젝트를 여러번 해왔기에 협업 자체에는 큰 어려움이 없을 거라는 생각을 했었다. 그러나 이는 나의 오산이었다. 다른 사이드 프로젝트 당시에는 말 그대로 ‘사이드’이기에 각자의 시간을 보내는 동시에 주기적으로 만남을 갖고 프로젝트를 진행하는 경우가 많았다. 레벨3 에서는 회사와 같이, 어찌보면 회사에 다니는 사람들보다 더 길게, 자주 같이 시간을 보내야 했다. 이 과정 속에서 나도 모르는 나의 부정적이거나 긍정적인 모습들을 발견할 때가 많았다. 그래서 .. [INFRA/DB] Flyway를 고르기까지 - DB 의 마이그레이션도 에자일해야 해 🤔 왜 DB 스키마 마이그레이션 도구의 도입을 고민하게 되었는가에자일 한 방식으로 1차 데모데이 / 2차 데모데이를 거치면서 개발에 임하고 있는 현재, 계속해서 엔티티의 구성이 달라지는 것은 당연하다. 우리 팀의 경우에도 기획에 2-3번은 엎어지고, 일부가 조금씩 수정되기도 했다. 뿐만 아니라 팀원 간의 이해가 조금씩 어긋나서 엔티티의 구조가 달라지는 경우도 허다했다. 그렇기에 DB 스키마 마이그레이션 도구가 필요할 것이라는 예상은 하고 있었다. 그러나 생각보다 빨리 필요성을 느끼게 되었다. 배포 환경에서 500 에러가 터졌기 때문이다. 왜 문제 상황이 발생했을까?기존에 amount 라는 필드가 존재했다. 그러나 이의 명확성을 위해 cupAmount 라는 필드명으로 변경했다.그러나 운영 환경의 ddl-.. [JPA] EAGER는 join 이 아니다 ✍🏻 글 작성의 계기어느덧 레벨3의 프로젝트를 진행하며 팀원들에게 fetchType 은 LAZY 로 하는 게 좋다는 말을 했다. 그러자 팀원들이 왜냐고 물었고, 한마디로 선뜻 정리하지 못하는 나를 발견했다. 그저 'EAGER 는 join 이 아니야..' 라는 애매한 말만 되풀이했다. 이후 내용을 정리해서 팀원들에게 이를 바탕으로 글 작성까지 하게 됐다. 🔎 이 글을 이런 분들께 추천합니다LAZY 로 매번 설정하긴 하는데, 왜인지는 솔직히 잘 모르겠다 하시는 분들매번 EAGER 는 join 이 되는 것이라고 생각하고 있는 분들EAGER 가 고려되는 상황블로그 서비스를 구현하고 있다고 가정해보자. Blog 는 게시글, BlogMember 는 작성자를 의미하며 Post 가 N:1 의 관계로 Member 를.. [JPA] 💥 관습적인 EntityManager 의 clear 사용을 멈추세요 (feat. JPQL 과 1차 캐시) 🤔 궁금증을 갖게 된 계기 리뷰어 분과 대화를 주고 받다가, EntityManager 의 clear 를 사용한 이유에 대한 질문을 받았다. 이에 대해 나는 단순 지식 확인 측면이겠거니 - 하고 딱히 나의 지식을 더블 체크하지 않고 답변을 작성했었다. 나의 의도는 레포지토리의 코드가 제대로 동작하는지에 대한 검증을 하고자 하는 것이었다. 만약 EntityManager 의 clear 를 하지 않으면 실제 쿼리를 날리는 것이 아니라 1차 캐시를 확인해 쿼리를 날리지 않을 것이라고 생각했다. 그래서 작성한 대부분의 테스트 코드에서 습관적으로 EntityManager.clear 를 호출했다. 나름 확신이 있었기에 호기롭게 대답했다. 그런데 리뷰어의 답변은 다음과 같았다. 오싹한 기분이 들었다. 혹시 영속성 .. [SpringBoot] 빈 등록과 생성은 다르다 (feat. BeanDefinition) 🕵🏻♀️ 궁금증을 갖게 된 계기학습 과정에서 다음과 같은 예시 코드를 마주하게 됐다.@Testvoid test3() { StaticApplicationContext context = new StaticApplicationContext(); context.registerBeanDefinition("printer", new RootBeanDefinition(Printer.class)); BeanDefinition helloDef = new RootBeanDefinition(Hello.class); helloDef.getPropertyValues().addPropertyValue("name", "Spring"); helloDef.getPropertyValues().addProp.. [우아한 테크코스 7기] 방탈출 예약 관리 미션 회고 지난 레벨1의 인터뷰 과정에서 배웠던 내용들을 다시 떠올려 키워드를 선정하는 데에 생각보다 어려움을 겪었다. 이전에는 노션에 키워드들을 뽑아내고 정리하는 방식으로만 기록을 해뒀었는데, 이렇게 하니 어떤 맥락에서 이 고민들을 했었는지에 대한 기억이 휘발되어서 아쉬움을 느꼈다. 그래서 레벨2부터는 매 미션마다 회고를 기록할 것을 다짐했다. 🌞 다시 처음으로 돌아가보기이전에도 스프링 부트를 활용해 본 경험이 있었으나, 차근차근 개념을 익혀 가며 습득했다기보다는 필요할 때마다 개념들을 마구잡이로 학습했다. 그래서 이번 미션에서 스프링 부트를 시작할 때 내가 모르는 키워드가 있다면 놓치지 않고 학습할 것을 다짐했었다. 그래서 이번 미션을 진행하는 과정에서는 '적어도 내가 쓴 코드에서는 모르는 내용이 없도록' .. 이전 1 2 3 4 다음
