개발일기 - 2022-05-16

10일부터 몸상태가 안 좋았었는데 벌써 7일째다.
기분나쁜 인후통 그리고 복통이 살짝 있다.

오전

• LocalStack 을 활용한 SQS 구축
• DailyScrum
• Object Builder 설계

오후

• Code Review
• Thing 에 name property 삭제
• Thing Relation 기반한 데이터 조회 API 스펙 정의
• User 관련 코드 수정
• Object Builder 설계

---

ObjectBuilder 설계를 시작했다.
아키텍쳐상 필수적으로 Queue가 필요하여 Production에선 AWS SQS를 활용할 예정이었고, Local은 RabbitMQ등을 활용해야 하나 생각했었는데, 찾아보니 AWS서비스의 Local 구현체인 LocalStack 이 있었고, SQS도 지원하고 있어 알아봤다.

Terraform 기반의 Helm으로 관련 내용을 정리하고 설치해봤다.

LocalStack Terraform 설정 파일

resource "helm_release" "localstack" {
  name      = "localstack"
  namespace = kubernetes_namespace.local.metadata[0].name

  repository = "https://helm.localstack.cloud"
  chart      = "localstack"

  values = [
    "${file("values/localstack_values.yaml")}"
  ]
}

로컬에서 구동하려면 aws-cli와 같은 역할을 하는awscli-local 가 필요하다.

$ pip install awscli-local

환경변수 설정이 필요

$ vi ~/.zshenv

# localstack
export LOCALSTACK_HOST=localhost

$ source ~/.zshenv

간단한 사용법은 다음과 같다.

# queue 생성
$ awslocal sqs create-queue --queue-name sample-queue-fifo

# queue 목록 조회
$ awslocal sqs list-queues

# 메시지 생성
$ awslocal sqs send-message --queue-url http://localhost:4566/00000000000/sample-queue --message-body "test"

# 메시지 읽기
$ awslocal sqs receive-message --queue-url http://localhost:4566/00000000000/sample-queue --attribute-names All --message-attribute-names All --max-number-of-messages 10

# 메시지 삭제 
$ awslocal sqs delete-message  --queue-url http://localhost:4566/00000000000/sample-queue --receipt-handle lqpmqeedarryzhmgvlthpnlucbqpdugigexchqlkwubmuasyxafqouvjbhaekchrixluefcrwwyzsexwgdgyuqzqparaoptsmbtipzuyyrkfusdhfkgnqvzefnqlqlzhybuskhsdlneyoalswgfhqcbeamczapkkzytmrbgvuwwbkgldbdmznscsu

현재 SQS 하나만 동작하도록 해두었다.

설정은 했지만 관련해서 정작 코드는 하나도 못짰다.

백오피스 프론트 개발을 담당하는 팀원이 하위 구성요소의 목록을 조회할 수 있는 방법을 문의해왔는데 구성상 종속 구조에 대한 단일 질의가 구현되어 있지 않았다.

현 상태에서 처리할 수 있는 방법은

• relations 조회
• 조회된 정보의 targetId를 기반으로 n번 호출하여 정보 조회

현재로선 ids 를 기반으로 조회(GET) 하도록 되어 있지 않기 때문에 굉장히 비효율적이었다.
우선 그렇게 쓰도록 얘기했으나, 아무래도 걸려 별도의 API형태를 파라미터를 추가하여 구현하였다.

relation의 targetId를 기반으로 한번에 조회하는 방법을 구현했고, 무리 없이 구현되었다.

진행하다가 보니 이전부터 거슬렸던 thing의 name property에 대한 검토 요청을 받았다.

빠른 의사결정이 필요한 것 같아 coworking 하는 팀원과 같이 짧은 화상 미팅을 진행했다.
안건은 다음과 같았다.

• thing 의 name 프로퍼티 삭제
• 위에서 고민했던 하위 구조의 정보를 한번에 조회하는 API 형태에 대한 공유
• 파일 생성시 unique ID 생성방안
• 속도가 local 환경에서 느려 이게 정상적인지 몰라 AWS에 환경구축하여 실제 걸리는 속도 테스트 해야할 것 같다는 의견 전달

을 진행했다.

관련해서 논의한뒤 바로 빠르게 name을 삭제하고 PR 올렸다.

User에 대한 코드 리뷰요청을 받고 진행중인데, 코드의 스타일 차이가 커서 관련해서 리뷰를 진행하다가 병목현상이 되는 것 같기도 해서, 우선 Code Review는 Approve하고, 별도로 정리해서 전달하고자 직접 관련 코드를 수정했고, PR을 올릴 예정이다.

ObjectBuilder 에 대해서 계속 고민중인데, jsonb 보다는 text로 관리하는게 좋겠다는 생각이 들었다.

현재로선

• structure 와 데이터를 분리하는 방안
• 빌드된 최종 결과물은 따로 관리하는 방안
• string replace로 처리하는 방안
  등을 고심중에 있다.

내일은 UseCase 정리후, DB설계를 하고, 그 후에 개발에 착수할 수 있을것 같다.

M1 맥북이라서 생기는 이슈도 갑자기 튀어나온다.

2022-05-16T22:33:51,934 ERROR  [main] i.n.r.d.DnsServerAddressStreamProviders: Unable to load io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider, fallback to system defaults. This may result in incorrect DNS resolutions on MacOS.

찾아보니 M1 Apple Silicon 에서만 발생하는 현상이라
Local환경에서만 별도의 처리를 해주어야 하는것 같다.

build.gradle.kts 파일에서

plugins {
    id("com.google.osdetector") version "1.7.0"
}

var isAarch64 = false
if (osdetector.arch.equals("aarch_64")) {
    isAarch64 = true
}

// For Apple silicon
if (isAarch64) {
    implementation("io.netty:netty-resolver-dns-native-macos:4.1.72.Final:osx-aarch_64")
}

원래는

plugins {
    id("com.google.osdetector") version "1.7.0"
}
if (osdetector.arch.equals("aarch_64")) {
    implementation("io.netty:netty-resolver-dns-native-macos:4.1.72.Final:osx-aarch_64")

}

이렇게 설정했었으나, 모듈을 찾을 수 없다고 나와 dependencies 내부에선 사용할 수 없나보다 싶어 별도의 변수로 정의하고 처리했다.

뭔 산들이 이렇게 많은지..

오늘은 피곤해서 바로 자야겠다.