실무 문제 해결

private vpc에 elasticache가 있고, bastion host를 경유해서 접속해야 하는 상황이다.다음과 같이 에러에서 표시된 ip, port를 쉼표로 연결해주면 된다. https://www.jetbrains.com/help/idea/redis.h

기능 작성을 완료한 zzz 서버를 시작하려 했는데, 다음 에러가 발생했다.There is no correlation between the Go import path and the package specifier in the .proto file.The latter is

저번 달까지 내가 짯던 코드 형식이다. 참고로 기존 실무 코드는 헥사고날 아키텍처가 아니라 레이어드 아키텍처로 되어있다.이 코드의 문제는 서비스의 퍼블릭 메서드를 테스트하기 어렵다는 것에 있다.모놀리식 아키텍처라면 딱히 겪지 않을 것 같은 문제다. 하지만 MSA는 서비

graphql에서 edge (또는 realtionship)에 filter(또는 input, where)를 넣고 싶다.예를 들면, 다음과 같다. (코드 출처: https://keystonejs.com/docs/guides/filters잘 보면, people 뿐만

사용자가 어떤 컨텐츠에 대해 bookmark 또는 pass를 할 수 있다고 하자.어떤게 적절한 스키마가 될 수 있을까?기존에 User 스키마와 Contents 스키마가 있다고 하자. (sql은 작성 편의상 네이밍, 문법 등은 고려하지 않았다.)1안의 경우 bool로 관

실무에서 기획에 따라 개발하고 있던 중이었다. 다음은 그 요구사항이다.사용자마다 컨텐츠에 대한 커서가 필요하다.커서는 원형큐처럼 순환하는 형태다.컨텐츠가 추가될 때마다 커서도 추가된다.해당 기능은 많은 사용자가 쉽게 접근할 수 있다.이 원형 큐 커서를 관리하는 데이터를

실무에서 서버 하나에 gRPC와 http 포트를 두개 띄울 필요가 있었다.각각 포트1과 포트2라고 했을 때, 서버 하나는 포트1과 포트2의 요청을 모두 처리할 필요가 있었다. 그래서 동시성이 필요하다고 생각하였고 고루틴을 활용하였다. 또한 gRPC와 http가 계속 작

graphql을 실무에서 써본지 4개월 됬다. graphql 기본 문법이라던가, graphql에 edge(relationship) filter를 걸어보는 등 여러 가지 해본 것 같다.그러면서 여러 가지 장단점을 느낀 거 같다.잘 알려진 장점으로, graphql은 res

10/11에 회사 서비스가 런칭되었다. 서비스가 런칭되기 이전에는 DB 칼럼 변경 등이 자유로웠다. 왜냐하면 실제 서비스를 사용하는 사람들이 없었기 때문이다.하지만, 서비스가 런칭되고 나서는 그럴 수가 없다. 그 이유는 버전 호환성 문제 때문이다.서비스가 런칭되고 나서

중복, 누락, 혼재가 없어야 MECE다.비즈니스 커뮤니케이션을 할 때 제일 먼저 내가 상대방에게 보고해야 할지, 설득해야 할 지를 정해야 한다.목적을 정하고 나서 주제를 정하자.주제를 정하고 나면 근거를 만들자.근거가 부족하면 여러 가지 측면을 고려하여 하위 주장과 하

다음 절차는 내가 실무(MSA, graphql 환경)를 통해 터득한 스키마, API 설계 방법이다.뭘 하든 간에 이게 가장 우선이다. 처음에는 도메인 이해가 부족하기 때문에 스키마나 API 설계도 어렵다. 하지만 점차 설계를 하면 할수록 도메인에 대한 이해도 올라간다

CTO님의 피드백 나는 저번 달까지만 해도 테스트 코드를 잘못 작성하고 있었다. CTO님이 내 서비스 레이어의 테스트 코드를 보더니, 이건 단위 테스트가 아니라고 하셨다. 통합 테스트 코드에 가깝기 때문에 그냥 지우는 게 낫다고 하셨다. 내 서비스 레이어 테스트 코드

회사에 일정 주기마다 작동하는 대량 작업 스케쥴러 코드가 있다.해당 코드들은 내가 작성했지만, 시간이 지나면서 유지보수하기 번거로워졌다.상황은 아래 그림과 같다. 서비스 패키지에는 실제 스케쥴러가 작동하는 로직의 코드를 배치했다. 그리고 컨트롤러 패키지엔 스케쥴러의 강

로컬, 개발계 환경에서 잘 작동하던 API가 운영계에서 잘 작동하지 않는 문제가 발생했다.모바일 프론트로 확인했을 때, 운영계 엔드포인트만 잡혀있는 버전의 경우 API 호출에서 하얀 화면이 노출되었다. 해당 API는 mutation으로, 서버에게 데이터 생성을 요청하는

파일 업로드를 하기 위해 graphql로 업로드하는 로직을 연구하고 있었다. 해당 로직은 예제를 참고해서 완성했고, 서버에서 API가 정상 작동함을 확인하였다.하지만, 서버 앞 단의 미들웨어가 문제였다. Mesh Gateway라는 미들웨어인데, MSA 서버들의 데이터

상황 몇 십 만개의 데이터를 갱신하는 스케쥴러들의 작동이 이상이 생겼다. ArgoCD 로그를 보니, 다음과 같은 것이 찍혀있었다. 트랜잭션 데드락이 발생하고 있었다. 다음 명령어를 활용해서 MySQL의 최근 상태를 확인해보았다. 확인해보았더니, 다음과 같았다.

마이크로서비스 아키텍처를 위한 표준화된 서버 구조를 설계하는 과제를 맡았습니다. 주요 요구사항은 다음과 같았습니다.모든 마이크로서비스가 일관된 방식으로 구성될 수 있는 표준 프레임워크 제공HTTP(GraphQL), gRPC 등 다양한 프로토콜을 유연하게 지원개발자 생산