김영재

현재 취업을 준비중인데 과제로 Strapi에 분석을 요청 받았다. 나는 처음 들어보는 프레임워크여서 이게 뭐지 라는 생각이 들었고 알아본 결과 정말 놀라운 프레임워크라는 것을 알게되었다. Strapi는 Node.js 기반의 오픈 소스 CMS(Content Management System) 프레임워크이며, Strapi를 사용하면 RESTful API, GraphQL API 및 관리자 패널을 쉽게 구축할 수 있다. Strapi는 사용하기 쉽고 확장성이 높으며, 데이터 모델링, 데이터베이스 연결, 인증 및 권한 부여 등의 기능을 제공한다. Strapi를 사용하면 개발자는 데이터베이스를 다루는데 필요한 일부 기능을 구현할 필요가 없으므로 더욱 빠르고 효율적으로 개발할 수 있는 장점을 가지고 있다. Strapi는..

6주동안 진행된 프로젝트에서 우리는 따로 Nginx을 붙이지 않았다. 처음에 그 이유는 결국엔 Nginx는 로드밸런싱이고 개인적으로 찾아보고 생각했을 땐 Nginx의 역할, 장점들이 대부분 AWS 로드밸런서에서 처리가 된다고 생각했기때문이다. 그래도 뭔가 확실한 답이 없고 AWS 로드밸런서, Nginx들 둘 다 붙인 아키텍처도 많아서 멘토님에게 물어본 결과 멘토님은 보안적 이유로 Nginx는 꼭 붙여야하며 WAS가 바로 노출이 되는 건 보안적으로 좋지않기때문이라하셨다. 시간이 없어 이렇게 멘토링은 끝이 났고 꼭 붙여야한다는 생각으로 조금 더 이것 저것을 찾아보면 찾아볼수록 난 의문이 들었다. AWS 로드밸런서도 어떻게 보면 앞단에 있기때문에 바로 노출이 되는건 아니라는 생각이 들었다. 그리고 심지어 우리..

가끔 공부하기 싫을 때 코드너리에 가서 오늘의 토픽을 본다. 같은 것이라도 다양한 방식이 있고 어떤 걸 더 선호하고 주로 쓰는 걸 투표하고 결과를 보는 건데 숫자 반올림 방법에 대해 보았다. 보통 나는 반올림 할 때 Math.floor를 쓴다. 왜냐면 이것밖에 모르기때문에 고민조차 안 했다. 그런데 새로운 방식이 있더라? ~~문법을 혹시 들어본 적 있나?? 대부분 모르는 거 같은데 const num = 4.5 const floorNum = ~~num console.log(floorNum) // 4 이런 식으로 가능했다. 정말 신기했지만 뭔가 이상했다. num은 4.5인데 반올림이면 5가 되어야하는데 콘솔은 4가 찍혔다. 그래서 찾아보니 ~~은 반올림이 아닌 버림이라고 했다. 투표 문제 자체가 잘못된것이었..

우리는 2월 1일 수요일 오후 6시에 프로젝트를 배포하였다. 우리는 챗봇이 있었고 실시간 상담 기능 또한 있었다. 여기서 문제점이 생겼는데 우리가 관리자다보니 상담을 직접 해주어야하고 사용자는 상담 요청을 언제 할 지 모르니 무한 대기를 해야했다. 따로 소켓을 이용해서 만든 알람 기능도 없었고 알람 기능이 있다하더라도 자리에 앉아서 대기해야하는건 똑같았다. 그래서 이 문제를 해결해야겠다라고 생각했고 이왕이면 모바일로도 확인이 가능하길 원했기에 어떻게 이것을 해결할까 고민했다. 우선 구조를 설명하자면 우린 누군가 상담 요청을 하면 방을 만들고 DB에 저장한다. 만약 로그인 한 유저면 그 유저아이디로, 로그인을 하지않았으면 IP로 방을 만들어 DB에 저장한다. 만료시간을 두어 10분동안 입력이 없을 시 자동..

필너츠 프로젝트는 ECS로 배포하면서 여러가지의 문제에 봉착했다. 그 중 하나가 ECS로 무중단 배포를 적용 시킬 수 있으며, 블루 / 그린, 롤링 중 하나를 설정할 수 있지만 블루 그린은 자원이 비교적 많이 필요하기에 롤링으로 선택했다. 배포 자동화에 대해 자세히 알고싶으면 https://youngjae0412.tistory.com/52 를 참고하면 된다. 롤링은 배포가 진행되는 동안 구버전과 신버전이 공존하기 때문에 호환성 문제가 발생할 수 있지만 가용 자원이 제한적이기때문에 알맞는 배포방식이었다고 생각한다. 가용 자원이 한정적이어서 롤링을 선택하였지만 우리는 t3a.small로 배포하여 cpu가 2048mb였다. 여기서 컨테이너의 CPU의 할당을 1024로 하게 되면 신버전을 배포할 때 CPU가 모..

프로젝트 중 우리는 배포를 ECS로 하였고, 로깅, 모니터링을 Cloud Watch, 컨테이너는 Container Insights를 통해 하였다. 여기서 문제가 생겼다. 배포 후에 프론트에서 400번, 500대 에러가 나오면 인프라, 배포 담당인 나는 그냥 내 아이디로 로그인해서 로그를 보면 되지만, 팀원들은 볼 방법이 없었다. 간단하게 내 AWS 아이디, 비번를 공유하면 해결되는 문제이지만 너무 야매적인 방법이었다. 우선, AWS 조직을 만들어서 했으면 쉽게 해결할 수 있는 문제였다. 하지만, 솔직히 프로젝트 초기 단계에 누가 조직을 만들 생각을 했을까. 또한, 개인적으로 Cloud Watch의 로깅, 모니터링은 왜인지 모르게 보기 불편했다. 내가 잘 몰라서 불편했을수도 있는거지만 뭔가 그래프나 나뉜 ..

API Gateway로 요청을 보낼 때 Api key를 헤더에 담아 보내는 것으로 보안을 해결했고 헤더는 다 노출이 되고 심지어 API key는 사용량 조절을 위해 주로 쓰이고 보안적으로 쓰지않는 것을 권유하고있다. 그래서 이왕하는거 나는 진짜 한번 제대로 구성해보자 라는 마음으로 세팅을 했다. 우선 권한 부여자 워크플로우부터 보여주겠다. 먼저 클라이언트에서 API Gateway로 요청을 보내면 Auth function이 실행되며 allow / deny 을 돌려준다. 만약 allow면 원래 API gate way로 트리거가 엮여있던 람다가 정상적으로 실행되고 deny이면 403번을 뜨면서 에러가 뜬다. 또한 그 외는 500에러가 뜬다. 권한부여자 세팅은 간단한데 먼저 lambda를 하나 생성해주고 API..

현재 이메일인증, 휴대폰인증은 람다를 통해서 요청을 보내며 원래는 x-api-key를 담아서 요청을 보내야만 에러가 안 나도록 해놨다. 하지만 헤더에 x-api-key가 노출이 되기에 보안적으로 전혀 안전하지가 않았다. 그래서 보통은 권한부여자를 통해 보안적으로 간다고하는데 이것 역시 헤더에 담아서 보내기에 노출이 되며 안전하지가 않았다. 우선 Apikey 자체를 보안적으로 쓰기엔 적절하지않다고한다. 보통 이것으로 사용량 조절을 많이하고 보안적으로는 권한부여자가 맞다고 하는데 람다를 하나 더 만들어 거기에서 권한이 있는지 없는지 체킹하고 권한이 있으면 람다로 보내고 없으면 에러를 띄우는 방식이었다. 그래서 권한부여자에서 jwt를 이용해서 프론트에서 요청을 보낼때마다 토큰을 새로 보내주면 그 토큰이 유효한..

우리는 회원가입 시 이메일, 닉네임, 비밀번호를 받아왔는데 mvp에 이메일 찾기 / 비밀번호 찾기도 있었다. 그러다보니 이메일찾기를 할려면 이메일을 제외한 유니크값이 필요하기에 휴대폰 번호를 넣었다. 또한 휴대폰 번호가 유니크 값이기에 다른 사람의 휴대폰번호로 회원가입을 막아야하기에 휴대폰 인증까지 넣었다. sms를 보내는 방법은 여러가지이지만 우리는 Naver cloud platform Simple & Easy Notification Service를 도입했다. 구글링해보면 도입하는 방법은 잘 나와있기에 생략하고 굳이 우리 서버에 인증을 둘 필요가 없기에 이메일 인증과 마찬가지로 람다로 뺐다. exports.lambdaHandler = async (event, context) => { const axio..

우린 사진 업로드를 multer로 하지않고 PresignedURL로 구현하였다. 그 이유는 이미지를 받는거 자체가 크기가 있다보니 서버가 그만큼 일해야하기에 서버에서 그 이미지를 직접 받지않는 방법을 찾아봤고 그 결과 PresignedURL이 가장 적합하다 라는 결과가 나왔다. 리사이징의 이유는 보통 사진 용량이 2~3메가 정도되는데 우린 유저이미지로 쓰기에 사진 크기가 그렇게 클 이유가 없다. 더군다나 이미지의 크기가 큰만큼 가져오는데 느려짐으로 크기를 줄여 좀 더 빠르게 가져올 수 있게 리사이징 해주기로 하였다. 먼저, 프론트가 백한테 PresignedURL을 요청하면 백은 유효기간이 정해진 PresignedURL을 발급해준다. 그러면 프론트는 그 URL로 put 요청으로 사진을 담아보내면 직접 S3..