Sn._.Jay

배경은 https://sunup1992.tistory.com/77 에서 볼 수 있고 해당 글에 이어 구체적으로 어떻게 적용하고 세팅했는지 방법을 정리하였다. 구조 현재 구조는 EC2 - ELB - API gateway 로 되어있고 ELB까지 VPC로 막혀있음 CloudFront 배포 시 ELB를 원본 설정을 하면 VPC가 있다하더라도 CloudFront 라우팅을 통해 Request를 받으면 될 것이라 생각해 계속 ELB로 연결한다고 꽤 오래 삽질을 했다. VPC로 막혀있으면 CloudFront 통해 연결하면 origin 닿는데 실패했다고 response가 계속 넘어온다. 그래서 CloudFront의 원본을 API Gateway로 설정하였음 Route 53에서 해외 호출용 Domain을 따로 만들어 Cl..

배경 한국에서 제공 중인 서비스들을 묶어 카타르 기업에 제공하기로 하였음 스마트팜 센서값들을 계속 받고 그 값들을 2차, 3차로 계산해서 저장해야하는 센서 메인 서버는 카타르 근처 바레인 리전에 생성해서 배포하기로 하였음 Ation 서버는 적당한 latency가 있어도 사용에 문제없기에 굳이 바레인에 똑같이 RDS랑 서버를 만들어서 하고싶지 않았다. (한국에서도 외국인 노동자들은 와이파이 없으면 사용을 못 하는데 스마트팜 특성상 와이파이가 미약하게 터지는 곳도 많아 사실 카타르에서 사용하는 것과 별반 다르지 않은 유저 환경이라 판단하였다) 근데 중동에서 한국 리전을 보는건 생각보다 Latency가 더 심할 것 같다는 걱정을 지울 수가 없고 VPN을 통해 테스트를 해볼까했지만 해봤자 뭐해라는 생각이 들면..

거진 5년 경력동안 노드 및 파이썬으로 경력 잘 쌓았고 이제 탈노드를 위해 진행 예정인 사이드프로젝트 백엔드 서버는 java로 구성하기로 마음 먹었다. 이를 위해 커리어리의 주니어 자바 개발자를 위한 100가지 질문에 대해 답을 정리하면서 영접을 잡아보고자 한다. (진행 중) (고마워요 커리어리) JDK와 JRE의 차이점은 무엇입니까? JDK : Java Development Kit / JRE : Java Runtime Environment JRE는 자바 실행 환경으로 실행시키는데 필요한 라이브러리 JVM(자바 가상 머신)이 포함되어있다. JDK는 JRE를 또 포함한 개념으로 개발자들이 개발할 때 필요한 도구들을 지칭하는 개념(개발할 때 실행도 시켜야하니 JRE가 포함되는 것) ==와 equals의 차이..

페인포인트 : ElasticSearch에 센서 시계열 데이터들이 쌓이고 있는데 이게 끊겨도 얼럿이 오지 않고 있다. 그래서 문제가 생겨 끊겨도 즉각적으로 알지 못 하고 그냥 날려버릴 때가 있음 대안 : 데이터가 끊기면 슬랙 얼럿을 보내주자! 조건 1 : 한번 발송하고 나서 다음 날 까지 다시 발송해주지 않았으면 좋겠음 조건 2 : 그러고 하루 지나면 다시 발송 조건 3 : 모든 센서에 대해서 체크, 발송하는게 아니라 센서당 특정 값에 대해서만 대표값으로 모니터링 조건 4 (이건 나만의 기준) : 하반기 AWS 비용 줄이기 대작전을 하고 있는 중이기 때문에 비용 최대한 안 들어가게 해보자 첫번째 아이디어 : ES 데이터를 담당하는 Repository에 node schedule > cron을 통해 1시간마다..

> 새로운 회사를 오고 이전 회사에서 안 쓰는 AWS 서비스들을 많이 사용하고 있다. 이에 이름만 알고 있었던 서비스들에 대해 어떤 서비스이고 어떤 역할을 하는지 간단하게 어떻게 사용하고 있는지 정리하고자 한다. Amazon Cognito 유저 인증 관리 및 유저 정보를 관리해주는 서비스 > 우리가 유저 Table을 만들고 관리할 필요가 없어짐 Amazon Amplify (Cognito와 세트) 쉽게 말하면 그냥 모든 개발회사가 만드는 로그인, 회원 가입과 같은 유저 관련 기능을 제공하는 서비스이다. > 백엔드 개발자가 따로 로그인 및 유저 관련 API를 개발할 필요가 없어짐 Druid (쓰려고 했던 것) vs. Amazon Elasticsearch (쓰고 있는 것) AWS elasticsearch는 처..

> 아이오크롭스에 합류하면서 개발적으로 가장 큰 변화는 데이터라고 할 수 있다. 15000평의 스마트팜들의 센서에서 오는 데이터들을 가공, 학습을 해야하기 때문에 데이터 양이 기존에 개발했던 B2B 서비스와 견줄 수 없을 정도로 많아졌기 때문인데 이에 내가 처음으로 직접 접한 것이 Data Lake 구조이다. 이에 공부할 겸 아래와 같이 정리한다. 쉽게 이야기하면 그렇다. Data Lake와 보통 비교되는 것이 기존의 개념, Data Warehouse인데 Data Warehouse는 정말 창고에 넣는 것 처럼 해당 물건(Data)을 정해진 섹터, 카테고리의 몇 층의 공간에 보관을 하는 구조였다면 Data Lake는 호수에 물을 버리듯 그냥 정해진 규칙, 형식 없이 전부 다 저장해버리고 관리를 하겠다는 것..

개발자에 지대한 영향을 주는 회사의 요소는 단연코 그 회사의 PR문화라 할 수 있다. 이건 대부분의 개발자가 알고 있고 시행을 하고자 하지만 보통 높은 확률로 바쁘다는 이유로, 크게 도움되지 않는 다는 이유로 시행되지 않기도 한다. 내가 지금 있는 셀러노트도 PR문화는 그래도 나쁘지 않았고 많은 리뷰도 받고 내가 리뷰를 하며 새로 알게된 것들도 많았다. 그리고 최근 개발자 인원이 많아지면서 지금까지는 인력이 적어 어쩔 수 없었던 것들에 대해 어떻게 개선해 볼 수 있을지 정리 해보자 한다. > 코드 리뷰의 목적 실수를 줄이는 것 아예 돌아가지 않는 실수가 있고 (오탈자 등) 개선의 여지가 명확히 보이는데 급하게 개발하며 놓치고 비효율적으로 개발하는 실수가 있다. 전자는 테스트 코드나 로컬 테스트를 통해 ..

> 막연하게 백엔드 개발자를 시작하며 API 개발을 시작했고 그 안에서 REST API에 최대한 맞춰 개발을 하고자 했었다. 그리고 GraphQL이 프론트쪽에서 핫하다고 하면서 본 내용 중 Rest API의 고질적인 문제점을 보는데 이게 딱 지금 내가 개발하는 API의 문제점이라 생각하고 있는 것들과 겹쳐서 기술한다. = 즉 특정 화면에서의 내가 지금 머리아파는 문제를 GraphQL로 해결 가능할 수도 있다. REST API의 문제 (Over-fetching, Under-fetching) Over fetching : 말 그대로 불필요한 데이터까지 API 결과값에 포함되어 return되는 것을 말한다. 최근 내가 쉽다 API 리팩토링 한 내용 중 하나가 이러한 문제들 때문에 return interface를..

> 43장 몽키 패치보다는 안전한 타입을 사용하기 몽키 패치란? 런타임 중에 property object를 직접적으로 수정하는 일련의 작업들을 말한다. (JS 기준) 이러한 몽키 패치는 일반적으로 안티 패턴 (비효율적이거나 비생산적인 패턴)으로 인식된다. 가끔 옛 버전 기준으로 적용해야하는 케이스를 위해 커스터마이징을 하는 용도로 사용하는 것을 제외하고는 당연히 이러한 패치들은 런타임 중에 특정 시점에 적용되는 것인데도 불구하고 전역 변수로 적용이 되기 때문에 다른 코드에도 영향을 주고 부작용을 발생시킬 수밖에 없음 (아래 케이스 기준으로) 그리고 이렇게 처리하면 Typescript에서는 type에 반영이 안 되기 때문에 type checker에서 걸려 에러가 난다. 예시 window.monkey = '..

> 기계적으로 서버를 만들고 관리하고 있었는데 과정 및 정보들을 기록해본다. (계속 사이드 플젝 진행하면서 오호라 하는 것들을 넣을 것이다.) > 현재 내가 있는 곳 서버는 EC2 - K8S - Node로 구성되어 있다. EC2 보안그룹 설정 하기 > EC2 인스턴스로 들어오고 나가는 트래픽에 대한 규칙을 정하고 제어할 수 있게 한다. (Ex: SSH 접속 포트인 22에 대해서는 특정 개발자의 IP에 대해서만 풀어주거나 http port인 80과 https port인 443에 대해서는 접속 IP 제한을 전부 풀어주게 할 수 있다.) 인바운드 규칙 : 외부에서 인스턴스로 들어오는 리퀘스트에 대한 규칙을 설정해주는 곳으로 유형은 HTTP, HTTPS, SSH 등이 있고 이에 따라 프로토콜, 포트가 설정된다...