스프링 배치

배치 사용 이유​

대량의 레코드의 로깅 분석, 트랜잭션 관리, 잡 프로세스 관리, 잡 재시작, skip, 리소스 관리등 사용성좋은 기능들을 제공해준다. 가장 큰 이점으로는 여러 data formatter를 지원하여 Read, Write 를 도와줘서 복잡한 코드를 사용하지 않아도 사용하기가 쉽다.

또한 중요한 다른 이점으로 청크 기반의 프로세싱을 지원하며, 배치 잡 상태를 관리해주는데, 중단된 실패한 잡의 재시작, 여러 이유로 skip되버린 records의 재시작, 또는 잡의 진행상태 들을 관리해주어 유지보수관리에 용이하다.

배치 아키텍처​

Job 시작 flow​

1. 마지막에 실행된 job을 조회
2. 없으면 새로운 job을 등록
3. 있을 경우 해당하는 job을 조회한다.
   • 여러가지 상태들을 확인한다.
     • ex) step 들의 상태가 running 또는 STOPPING 일시 throw

배치 비지니스 로직 flow​

JobInstance

JobInstace는 논리적으로 실행을 나타낸다. JobInstae는 Job 이름과 인수로 식별된다. Job명이 동일하다면 동일한 JobInstance로 생각을하여, Job이 에러 등으로 처리가 도중에 중단하고 있었을 경우 재실행을 보장 할 수 있고, 처리의 도중부터 실행된다.

JobExecution

JobExecution은 작업의 실행을 나타낸다. JobInstance 와 1:N의 관계를 가진다.
ExecutionContext를 가지고있는데 Spring Batch가 여러 진행 상황과 메타데이터를 체크하기위해 가지기도 하지만 사용자가 공유를위해 사용할 수 도 있다.

StepExecution

StepExecution은 Step의 실행을 나타낸다. JobExecution과 StepExecution은 1:N의 관계를 가진다. JobExecution과 마찬가지로 ExecutionContext를 가지는데, 복수의 step간의 공유를 위해서 사용하지 않을려면 StepExecution을 사용 할 수 있다.

참고

Spring Batch Tutorial: Batch Processing Made Easy with Spring | by Jalal Nasser | DreamiFly | Medium
https://www.baeldung.com/rest-assured-tutorial)

모든 소스는 이곳에서 확인이 가능합니다!

Rest Assured

REST Assured Java 라이브러리를 사용하여 REST 어플리케이션의 HTTP Endpoint에 초첨을 맞춘 테스트 도구이며, MockMVC와 같이 테스트를 편리하게 해주는 유용한 테스트 도구이며, 인수테스트 작성으로도 많이 사용이됩니다.

사용​

gradle.build​

testImplementation 'io.rest-assured:rest-assured'

• 당연하지만, 기본적인 test 를 위한 기본 것들은 import 하고 있어야한다.

코드​

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) //(0)
class RestAssuredApplicationTests {

  protected static RequestSpecification REQUEST_SPEC;

  @LocalServerPort
  private Integer port;

  @BeforeEach
  public void setRequestSpec() {
    RequestSpecBuilder reqBuilder = new RequestSpecBuilder();
    reqBuilder.setContentType(ContentType.JSON);
    reqBuilder.setPort(port);
    REQUEST_SPEC = reqBuilder.build();
  }

  @Test
  void getOrder() {
    ExtractableResponse<Response> actualResponse =
        RestAssured. // (1)
            given(). // (2)
              spec(REQUEST_SPEC).log().all().
            when(). // (3)
              get("/order/{orderId}", 1L).
            then(). // (4)
              log().all().extract(); // (5)

    assertThat(actualResponse.statusCode()).isEqualTo(HttpStatus.OK.value());
    assertThat(actualResponse.jsonPath().getObject(".", OrderController.OrderResponse.class)).isEqualTo(new OrderController.OrderResponse(1L, 10000L, 1000L));
  }

}

간단한 타켓 url 을 get 요청 및 검증하는 테스트입니다.

(0)@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)

• End to End 테스트 목적이니 SpringBootTest를 사용합니다.

• webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT

  • 지정된 포트로 톰캣을 띄우게 됩니다. 이는 실제로 mock이 아닌 별도의 스레드로 톰켓을 시작하게됩니다

  

(1) RestAssured

• RestAssured 를 시작으로 Java DSL 형태로 작성이 가능합니다.

(2) given().log().all()

• 모든 request 헤더와 바디 부분을 상세하게 로깅해줍니다.
• all 말고도 원하는 params, body, path 것을 명시가능합니다.
• given 에서 header 등에 여러 인증을 명시 할 수 있습니다.

(3) when().get("/template/{targetId}", targetId)

• get, post, put 등 원하는 httpMethod를 명시 할 수 있습니다.
• 안에 target url을 넣어서 요청이 됩니다.

(4) then()

• then 절에서는 주로 여러 응답을 검증 할 수 있습니다.
• 또는 응답 로그 확인용으로 사용이 가능합니다.

(5) extract()

• response 로 추출을 할 수 있습니다.
• 가져온 response로 추가 검증이 가능합니다.

log.all

아래왜 같이 콘솔에 요청 또는 응답 로그를 남기겠다고 명시하는 것입니다.

번외​

Mock을 사용하지 않고 end to end 테스트하기 with FeignClient

외부 request 요청 시 FeignClient를 많이 사용하는데, 이는 자연스럽게 외부 자원에 대한 테스트 고민을 하게 만들어줍니다.

여러가지 문제가 있는데요. 그것을 어떻게 해결 할 수 있는지 알아봅시다.

FeignClient 는 Primary default 인 Config 이다.​

즉, Bean으로 같은 name으로 생성해서는 FeignClient 를 갈아끼울 수 있는 방법이 없습니다. 이를 해결하고자 여러 방법이 있습니다.

1. 가장 쉬운 방법은 default를 false로 선언하는 것입니다.

   @FeignClient(
     name = "order",
     url = "${targetUrl}",
     primary = false  // (1)
   )
   public interface OrderClient { 
       public Long orderAmount(Long id);
   }
   
   @Component
   @Primary
   public class FakeOtherOrderClient implements OtherOrderClient { // (2)
   
     @Override
     public Long orderAmount(Long id) {
       return 10000L;
     }
   
   }
   
   @RestController
   @RequestMapping("/order")
   public class OrderController {
   
     private final OtherOrderClient otherOrderClient;
   
     public OrderController(OtherOrderClient otherOrderClient) {
       this.otherOrderClient = otherOrderClient;
     }
   
     @GetMapping("/{orderId}")
     public ResponseEntity<OrderResponse> getOrder(@PathVariable Long orderId) {
       Long amount = otherOrderClient.orderAmount(orderId);
       return ResponseEntity.ok(new OrderResponse(orderId, amount, 1000L));
     }
   }
   
   • 이런식으로 테스트 패키지 아래 위치를 시켜 fake로 만들어서 대신 응답을 뱉을 수 있습니다 (예제는 사실 stub에 가깝긴하지만..)

   (1) @FeignClient(primary = false)

   • false로 primary config 로 등록이 안되도록 명시 해줍니다.

   (2) public class FakeOtherOrderClient implements OtherOrderClient

   • Fake 클래스로 상속을 받아 primary 로 선언을해서 테스트 시 Bean을 강제로 바꿔치기하는 것입니다.

2. 만약 FeignClient가 외부 dependency 인 경우에는 Feign Client에 false를 집어 넣을 수 없는데요 이때에는, OrderClient를 한 번더 감싸서 클래스로 만들고 만든 부분을 fake로 만드는 것입니다.

   • 글로 표현하면 어려운데요. 코드로 보시면 쉬울 거 같습니다!

     @FeignClient(
       name = "order",
       url = "{targetUrl}"
     )
     public interface OrderClient { 
     
         public Long orderAmount(Long id);
     }
     
     @Service
     public class WrapperOrderClient { // (1)
     
       private final OtherOrderClient otherOrderClient;
     
       public WrapperOrderClient(OtherOrderClient otherOrderClient) {
         this.otherOrderClient = otherOrderClient;
       }
     
       public Long orderAmount(Long id) {
         return otherOrderClient.orderAmount(id);
       }
     
     }
     
     @RestController
     @RequestMapping("/v2/order")
     public class OrderControllerV2 { 
     
       private final WrapperOrderClient wrapperOrderClient;
     
       public OrderControllerV2(WrapperOrderClient wrapperOrderClient) {
         this.wrapperOrderClient = wrapperOrderClient; 
       }
     
       @GetMapping("/{orderId}")
       public ResponseEntity<OrderResponse> getOrder(@PathVariable Long orderId) {
         Long amount = wrapperOrderClient.orderAmount(orderId); // (2)
         return ResponseEntity.ok(new OrderResponse(orderId, amount, 1000L));
       }
     }
     
     @Component
     @Primary
     public class FakeOtherOrderClientV2 extends WrapperOrderClient { // (3)
     
       public FakeOtherOrderClientV2(OtherOrderClientV2 otherOrderClientV2) {
         super(null);
       }
     
       @Override
       public Long orderAmount(Long id) {
         return 10000L;
       }
     
     }
     

   (1) public class WrappedOrderClient

   • 우리 코드에서 컨트롤이 가능하도록 WrapperOrderClient를 한 번더 감쌉니다.

   (2) Long amount = wrapperOrderClient.orderAmount(orderId);

   • 일반적으로 사용 사용 할 때와 동일하게 사용합니다. 그저 감싼 객체로 사용을 합니다.

   (3) public class FakeOtherOrderClientV2 extends WrapperOrderClientTest

   • 테스트 패키지에서 생성 후 감싼 객체를 상속을 받게 합니다.

MockMvc와 차이점​

MockMvc는 웹 애플리케이션을 애플리케이션 서버에 배포하지 않고도 스프링 MVC의 동작을 재현할 수 있는 라이브러리이며 대부분 Controller Layer Unit Test(단위 테스트)에 사용됩니다.

실제 서버 환경과 동일한 @SpringBootTest를 사용하지않고 Presentation Layer Bean들만 불러온다. 그리고 그 외 Bean은 Mock 객체 설정을 해주어 순수한 Controller 로직을 테스트를 할 수 있게 도와줍니다

물론 @SpringBootTest 를 사용하면 end to end 테스트가 가능하나, RestAssured 는 bdd기반의 테스트 코드를 작성 할 수 있게 도와줘서 테스트 가독성을 높여주며, json 검증시에도 상대적으로 쉽게 검증이 가능한 장점이 있다.

결론​

이상으로 RestAssured를 알아봤는데요. 그러면 RestAssured의 단점은 SpringBootTest를 사용하게되다보니 테스트 속도가 mock을 사용 할 때 보다 매우 느립니다. 그래서 상황에 맞게 사용하는게 좋고, 개인적으로는 테스트 작성시에 end-to-end 테스트 시에는 BDD 형태로 가독성이 좋은 RestAssured를 사용하고, Unit test 또는 특정 레이어 텟트시에는 mockmvc 로 테스트를 한다면 좋을 거 같습니다.

참고

Restaussred used docs https://www.baeldung.com/rest-assured-tutorial

어른의 문장력

내가 쓴 문장이 어른의 문장일까라고 고민을 한 번 이라도 해봤다면 이책을 추천한다.

타깃을 분명하게​

글을 쓰기 전에 글을 읽는 사람이 누구일까를 먼저 떠올린다.
타깃이 있는 문장은 다음과 같은 특징이있다.

1. 친절하다.
   • 나는 알아도 상대방은 모를 수 있다는 사실을 항상 전제하고 글을 쓴다.
2. 책임을 지려고 한다. 의사 전달이 제대로 안 되거나 상대가 뜻을 이해하지 못하면, 상대방의 탓하는 게 아니라 표현을 정확하게 쓰지 못한 자신을 되돌아본다.

요즘 같이 온라인으로 소통을 많이 하는 시대에서는 더욱 어휘력은 중요하다.

메시지 챙기기​

성과라는 목적이 있는 문장은 반드시 구체적인 메시지를 품고 있어야한다. (p.35) 심리학에는 초두효과, 최근효과라는 것이 있다. 보통 중간보다는 가장 처음과 마지막에 제시된 내용을 더 잘 기억한다는 뜻이다.
블로그를 쓸 때 만앞 또는 맨뒤에 3줄 요약을 쓰면 효과적인 이유이다.

말 끊는 습관 없애기​

나는 주로 고민을 듣는 입장이었는데 곰곰이 생각해보면 진짜로 ‘듣는 사람’이 었는지 반성하게 된다. (p.44)
미국의 사회학자 찰스 더버는 대화 주도권을 자신에게 돌려놓으려는 욕망을 ‘대화 나르시시즘’이라 표현했다. 재밌는 점은 상대방의 대화 나르시시즘 의도는 빤히 보이지만 내가 저지르고 있단느 사실은 쉽게 깨닫기 힘들다.
서로에게 유익한 대화가 되려면 아무리 내 말이하고 싶어서 손가락이 근질근해도 참는 훈련이 필요하다.
상대와 아직 친분이 없다면 격의 없게 다가가는 것보다는 과한 예의를 차리는 편이 낫다. 쿠션어를 적극적으로 사용하는 것도 한 가지 방법인데, 주로 ‘바쁘시겠지만’ ‘죄송하지만’이 있다.
내 마음의 거리와 상대방의 마음의 거리는 다를 수 있다라는 것을 인지하자.

문장 다이어트​

어른의 문장을 쓰려면 글 종류를 불문하고 퇴고를 여러번 해야 한다. 문장 다이어트를 해야한다.

• 있어도 괜찮을 말을 두는 너그러움보다, 없어도 좋은 말을 기어이 찾아내어 없애는 신경질이 글쓰기에선 미덕이다. - 이태준, <문장강화>
  • 과도한 부사제거
  • 들, 것 빼기
    • 영화 제작진들이 무대로 올라갔다.
      → 영화 제작진이 무대로 올라갔다.
    • 우리들은 다음 목적지로 향했다.
      →우리는 다음 목적지로 향했다.
    • 아픈 것은 사실이지만 아닌 척했다.
      • 아팠지만 아닌 척했다.

긍정의 문장이 긍정적인 첫인상을 만든다.​

• 너무 어려워요, 제가 머리가 좀 나빠서요. 여기 계신 분들은 다들 똑똑하신 거 같은데 저만 부끄럽네요 ㅠㅠ
  → 어렵긴 한데 재밋어요. 뭔가 잠들어 있던 도전정신이 꺠어나는 느낌? ㅎㅎ 벌써 다음이 기대돼요!

• 어른의 문장은 긍정적이고 자신감 넘치는 문장이다.

일잘러​

일을 잘하는 사람은 사소한 회의 시간일지라도 맨몸으로 ‘팔랑’ 가기보다는 정갈하게 정리된 문장을 준비한다. 논의 주제와 보고할 내용을 나누어 메모해두면 전달할 내용을 깜빡하지 않는다. (p.68)

어른의 문장 쓰기는 하루아침에 얻는 기술이 아니다. 쓰는 만큼 정갈해진다. 주체적인 나로 살고 싶다면 매일 쓰고 고치기 바란다. ‘나는 내향인이라서…’라는 말은 이제 허울 좋은 핑계에 불과하다.

“특히 스크럼에 들어가기 전에 10분간 정리하는 시간을 가지자.“

정돈된 문장으로 머릿속을 정리하다​

책을 읽은 후 우리는 그냥 뭉뚱그려진 감정과 생각의 덩어리를 갖고 있을 뿐이다. 결국 기억하기 위해서라도, 또 표현하기 위해서라도 말하고 쓰는 것이 중요하다. 걱정이 많을 때는 마인드 맵을 그려보자.(p.90)
간결하고 정확한 문장을 써버릇하면 우유부단한 성격에도 조금씩 균일이 생기지 않을까?

피동형 문장을 능동형으로 바꿔보자.

그녀가 멀리서 나를 바라봄이 느껴졌다.
→ 그녀가 멀리서 나를 바라봤다.

활활 타오르는 장작불을 보니 학창 시절 수련회가 떠올려졌다.
→ 활활 타오르는 장작불을 보니 학창 시절 수련회가 떠올랐다.

이제는 외벌이가 됐으니 그만큼 씀씀이가 적어져야 될 것 같다.
→이제는 외벌이가 됐으니 그만큼 씀씀이를 줄여야겠다.

뭉뚱그리지 말고 구체적으로

공원에는 정말 다양한 사람들이 모여있다.
→안양공원에는 이십 대부터 칠십 대 노인까지 다양한 연령대 사람들이 모여있다.

오랜만에 만난 선생님과 이런저런 대화를 나누었다. →오랜만에 만난 요가 선생님과 새로 취직한 회사 이야기를 나누었다.

말글을 쓰기 전 한 번더 생각하자. 맞춤법, 어긋난 핵심 등등

항상 인사 할 때​

‘안녕하세요’ 이 짧은 인사와 자기소개는 생각보다 많은 의미를 담고 있다.

win-win하는 질문 법​

‘예, 아니요’ 식으로 대답하게 만드는 닫힌 질문보다는 열린 질문이 좋지만, 열린 질문이 추상적인 질문을 의미하지 않는다. 이어령 선생님도 큰 질문을 경계하고 작은 질문을 하라고 강조하셨다.

• 제 글이 어떤가요
  → 제 글의 주제가 잘 드러났나요?

• 행복이 무엇일까요? → 주로 무엇을 하고 있을 때 기분이 좋아요?

• 음악 좋아세요?
  → 요즘 즐겨든는 국내 가수 음악이 있어요?

매니저한테: 저에게 피드백 주실 부분 있으세요?
→ 최근 1주일간 지켜 보시면서(우리는 워너원을 현재 일주일에 한 번씩 한다.),제가 타 팀 협업 또는 팀원간의 커뮤니케이션이 잘 하고 있다고 생각이 드시나요?

내가 이해한 내용을 설명하며 묻는다

불확실한 의사소통을 해결하려고 묻는데 상대의 수준을 얕잡아볼 사람은 없다. 오히려 긴가민가하고 넘어갔는데 문제가 터지면 주워 담기 힘들다.

내가 긴가민가 하면 ‘나만 이해력이 떨어지나?’라고 눈치 볼 필요 없다. 보통 내가 혼란을 느끼면 다른 사람도 비슷한 고충을 겪고 있을 확률이 높다.

서평 제목을 쓸 때 ‘어른의 문장력'을 읽고… 이런 제목은 무조건 피하자. 아무도 읽고 싶지 않을 것이다.

• 문자 한 줄이라도 정갈하게 쓰고 싶다면?: 이 책을 추천한다.

형식을 무시하는 사람이 무시당한다​

신청서 양식에 맞게 쓴 사람을 우선 추렸어요. 그랬더니 몇 명 안 남더라고요?(p.190)
‘자기소개를 500자 내로 써주세요’라는 지문에 열정을 담아 1000자를 쓴 사람도 제외시켰다’
‘이메일 주소에 오타를 쓴 사람, 대답 양식을 건너 뛴 사람은 탈락시켰다.’
내용은 얼마든지 꾸며도 태도는 숨기기 어려운 법이다.
기본에만 충실해도 해결되는 많은 일이 있다. 내가 한 번더 움직여서, 상대방을 배려하는 마음을 가지자.

문장에 허세와 기름기를 빼자​

허세는 어려운 단어들을 의미하고, 기름기는 과도한 외래어를 의미한다.
읽었을 때 편안한 담백한 문장이 사랑받는다.
부탁을 해야 할 때, 문장 앞 이름을 넣는 것은 반응 속도나, 온도가 미묘하게 달라진다.

생각 안 나 대신 끝까지 찾기​

목표를 손으로 쓸 때 키보드로 쓰는 것보다 글로써 쓰면 목표를 이룰 가능성이 높아진다.
이야기를 하다가 떠오를 듯 말 듯 애태우는 기억을 고이 보내지 말고 메모나, 스마트폰이든 어디든 기록을 해서 어떻게든 떠올리자.

“그걸 뭐라고 하지, 모든 게 좋은 시기를 이르는…”
“호황?”
“아니, 아니”
“화양연화?”
“아니, 모든 게 더할 나위 없이 좋다 .뭐 그런 뜻인데 ‘뭐뭐’가 따로 없다! 하는 말 있잖아”
“태평성대!”

휘발성 기억으로 넘기지 말고, 기록하자.
대충 넘어가면 ‘대충 인간’ 이 된다.

느낀점

평소 나는 내가 쓴 문장들이 어른의 문장인가라는 고민을 많이 했는데, 이 책이 어른의 문장은 이런거다라고 가이드를 해주어서 너무 좋았다.
특히,‘문장을 쓸 때, 이렇게 쓰지마세요!’라고 끝내지 않고 실제로 자주 사용하는 문장들을 예시로 들고 다듬어 줌으로써, 어른의 문장은 이런 문장이다라고 말을 해주는 부분이 도움이 많이 되었다.
그리고 스스로 액션 아이템이 몇 가지 생겼는데 그 중 하나 비지니스적으로 커뮤니케이션이 필요 할 때 상대방에게 내 의도가 잘 전달되었나? 이상하게 생각하지 않겠지? 이런 고민들을 정말 많이 한다.
그래서 평소에 부족함을 많이 느꼈는데, 이 책을 읽고 개인 액션 아이템으로 회의 전, 또는 대화 전 논의 주제 정리, 보고 정리 즉, 시작 전 글로 쓰고 체크리스트 작성을 남은 하반기 동안 실행 해 볼 것이다.

프로그래머의 뇌

이 책의 목적은 두뇌가 코드를 처리하는 방식을 이해하도록 돕는 것이다.

코드 잘읽기​

코드가 초래하는 세 가지 종류의 혼란​

1. 지식의 부족
   • LTM (long-term-memory) 장기 기억 공간에 내용이 없다는 것.
     • 반영구적으로 저장하는 곳이다.
2. 정보의 부족
   • STM(short-term memory) 단기 기억 공간에 내용이 없다는 것.
     • 정보를 수집할 때 단기 기억 장소에 일시적으로 저장하지만, 다른 정보를 찾는 과정에서 이미 수집해놓은 정보 중 일부는 잊어 버린다.
3. 처리능력의 부족
   • WM(working memory)
     • 많은 정보를 처리할 때 사용

트레이싱

• 머리속에서 코드를 컴파일하고 실행하는 과정을 의미한다.

프로그래밍 업무와 관련한 인지 사항​

버그 리포트로 받는 경우 버그를 고치기위해 몇개월 전 작성한 코드를 다시 읽어야한다.
코드 분석을 할 때 읽는 내용은 STM에 저장되며, 몇 개월 전에 구현한 내용을 LTM에서 가져올 것이다.과거의 경험으로 기억된 내용뿐만아니라 오류의 해결법 같은 정보 역시 LTM에 저장되어 있다.
이 모든 정보, 즉 STM에 저장된 새로운 버그 리포트 내용, 그리고 LTM에 저장된 유사한 버그의 해결법이나 개인적인 기억 두 가지가 다 작업 기억 공간으로 들어오게 되고, 그제서야 당면 문제에 대해 생각 할 수 있게 된다.

세 가지 인지 과정

1. LTM에서 정보를 인출, 키워드의 의미 같은 것들이 해당
2. 메서드나 변수의 이름과 같이 코드를 읽는 과정에서 발생하는 정보를 STM 일시적으로 저장
3. WM 에서 일어 나는데 코드를 읽고 처리하는 일이 여기서 이루어지는데 예를 들면 ‘인덱스 값이 하나 작다’라고 판단하는 것이다.
4. 서로서로 이 3가지 과정은 보완적으로 작용한다. STM이 n과 같은 변수명을 보게 되면 과거에 읽었던 그와 관련된 프로그램을 LTM으로부터 찾는다. 모호한 단어를 보면 WM이 활성화되며 문맥 속에서 적합한 의미를 찾으려 한다.

컴퓨터와 마찬가지로 인간의 STM인지 능력은 LTM보다 훨씬 적다.

청크단위​

이미지를 청크단위로 기억을 해서 우리는 STM을 더 효율적으로 사용 할 수 있다.

Ozpq odfj vs like love

생소한 문자로 글을 작성하면 STM에 저장하는데 한계가 있지만, 뒤에 문자는 여러 개의 문자를 한 단위로 묶어서 기억 했기 때문에 쉽게 기억이 가능하다.

코드에서 청킹​

디자인패턴이 한 요소가 될 수 있다.

주석문​

일반적으로 개발자들은 주석문을 포함하고 있으면 코드를 읽는 시간이 더 많이 들어간다고 한다. 하지만 이는 개발자들이 주석문을 읽는다는 사실을 시사한다. 이것은 최소한 의미없는 일이 아니라는 것을 보여준다. 코르시비의 연구에 따르면 코드에 주석문이 있으면 새로운 팀원이 코드를 쉽게 이해할 수 있다라고 한다.

주석문은 초급 개발자가 코드를 이해하는 데도 도움이 되지만, 개발자가 코드를 청킹하는 방식에도 영향을 미친다. 취인 판의 연구에 따르면 개발자들은 코드를 읽을 때 주석문에 굉장히 많이 의존한다. 특히 이 함수는 주어진 이진 트리를 중위 순회하며 프린트한다. 같은 고수준 주석문은 코드를 청크 단위로 쪼개는 데 도움이 된다. 반면 i++; 다음에 i를 1만큼 증가’ 같은 저수준 주석문을 넣는 것은 오히려 청킨 작업에 부담이 된다.

청킹 연습​

의도적 연습(deliberate practice)은 어떤 기술을 향상하기 위해 조금씩 연습하는 것을 의미.

1. 코드 선정
   • 어느 정도 익숙해져 있는 코드베이스를 하나 고르기. 정기적으로 작업하지만 주로 작업하지 않는 코드베이스면 좋다. 본인이 오래전에 작성한 코드라도 상관없다. 최대 50라인을 넘지 않도록 해야 한다.
2. 코드 파악
   • 2분을 넘지 않도록 타이머를 설정하고 코드를 파악해라. 시간이 다 되면 코드는 보지 않는다.
3. 코드 재현
   • IDE에 기억을 되살려 코드를 작성해보자
4. 회고
   • 어느 부분을 쉽게 기억했는가?
   • 부분적으로 기억한 코드가 있는가?
   • 전체를 다 기억하지 못한 코드가 있는가?
   • 기억하지 못한 라인들이 있다면 그 이유는 무엇일까?
   • 기억하지 못한 라인에 본인이 익숙하지 않은 프로그래밍 개념 들어 있지 않는가?
   • 기억하지 못한 라인에 본인이 익숙하지 않은 도메인 지식이 있나?

option으로 다른사람이랑 같이 비교해보는 것도 좋다. 자신의 실력을 판단 할 수 있는 근거가 될 수 있다.

자료구조, 디자인패턴, 문법을 아는 부분이 중요한 이유가 코를 효율적으로 읽고 이해하는데 상당한 영향을 미친다. ← STM에 해당하는 부분

업무 중단이 미치는 나쁜 영향​

파닌 교수는 업무 도중 주단이 되면 프로그래머에 어떤 일이 일어나는지 연구 했고 업무 중 도중 중단이 되고 되돌아 가는데 15분 정도 걸렸다고 한다.(p.38)

이건 평소 내가 생각했던 생각이랑 다른 시각인데 난 평소에 문법을 검색을 하면 되지 않나? 대충 알고만 있으면 검색을 해서 적용 할 수 있지 않나라고 생각을 할 수 있지만 이게 계속 반복되다보면 다시 일을 복귀 할 때 컨텍스트 스위칭이 내 생각보다 오래 걸릴 수도 있다는 개념이 신선했다.

문법을 빠르게 배우는 법​

플래시카드 기법 앞에 암기하려고 하는 내용에 대한 프롬포트, 즉 그것을 지칭하는 단어나 질문이 있고 뒷면에는 그에 대한 내용이나 답이 있다.

ex) 기본 문법 → numbers = [ x for x in numbers]

  필터         → odd_numbers = [x for x in numbers if x % 2 = 1 ]

플래시카드 기법은 내가 새로운 업무에 조인을 할 때도 유용할 거 같다. 특히 새로운 도메인 안익숙한 도메인에 조인을 할 때도 새로운 개념이 나오면 알아야하는 용어들을 앞에 적고 뒤에 적는 방식으로 조금 더 빠르게 개념을 이해 할 수 있을 거 같다. (이번주에 적용 해보기!)

일반적으로 STM에 있는 것들을 LTM에 집어 넣으려면 한 달에 한 번씩 복습을 해야한다.

정보를 외우는 것은 기억을 강화한다.​

인출 강도

• 무언가를 기억해내려고 할 때 나오는 강도
  • filter() 함수를 기억을 하고 잇지만 막상 잘 기억을 못한다면 인출강도가 낮도가 얘기한다.
  • 시간이 흐를수록 약해진다

저장 강도

• LTM에 얼마나 잘 저장하고 있는가를 나타낸다.

인출을 하려고 노력을 해야한다.
능동적으로 생각을 할 때 인출의 강도는 높아진다.
너무 쉽게 정보를 찾고 또 그것이 너무 일상적으로 이뤄지다 보니 우리 두뇌는 문법을 기억할 필요가 없다고 느낀다.

구글 검색하기 전에 먼저 능동적으로 의도적으로 기억하려고 시도해보자. 항상 떠올리려고 생각을 해야 내 것이 되는거 같다는 걸 많이 느꼈었다.

프로그래밍 개념을 새로 배울 때 적용 해볼 만 한 내용

• 새로운 개념이 어떤 다른 개념을 생각나게 했는가? 적어보기
• 위에서 적은 관련된 개념에 대해 다음 질문에 답해보기
  • 새로운 개념은 왜 이미 알고 있는 그 개념을 생각나게 했을까?
  • 문법에 공통적인 점이 있는가?
  • 비슷한 환경에서 사용될 수 있는가?
  • 이 새로운 개념은 이미 알고 있는 그 개념 대신 사용될 수 있는가?
  • 동일한 목적을 달성하기 이해 작성할 수 있는 다른 방법을 코드를 알고 있는가? 같은 결과를 갖는 비슷한 코드를 최대한 많이 만들어봐라.
  • 다른 프로그래밍 언어에서 같은 개념이 있는가? 비슷한 동작을 수행하는 다른 언어의 예제 코드를 작성할 수 있는가? 서로 어떻게 다른가?

인지 부하​

인지 부하에는 크게 내재적 인지부하 외재적 인지부하가 있다.
내재적 인지 부하는 내가 이지식을 알고 있냐 모르고 있냐의 차이고
외재적 인지 부하는 지식은 있지만 그걸 적용 할 때 따르는 부하이다.
ex) ( for int v = i / 2; ; v++;) for 문을 알고 있지만 그 안에 내용이 생소할 경우 나타나는 부하이다.

인지 부하를 줄이는 법

1. 리팩터링
2. 코드를 여러번 읽어도 이해가 안된다면 어디서 부터 중점을 두고 읽어야할지 모르는 것이다. 큰 그림을 이해 못 한거일 것이다. 이럴 땐 보조수단을 사용하면 좋다.
   • 의존그래프를 그려보자
   • 정 이해가 안되면 프린트해서 원을 그려보자
   • 원을 연결하고 선을 이어서 보자

알고리즘 공부할 떄 써먹을 수 있겠다. 상태표를 그리고 그안에 나타나는 모든 변수들을 기입하자. 그리고 그 안에서의 흐름을 적어보자 loop문을 적고 그 때의 나타나는 변환을 적어보자. tip 어떤 변수는 생략하고 지나가고 싶을 때 생략하지말고 최대한 자세히 적자.

코드 잘 읽기​

기존 지식의 활성화​

익숙하지 않은 코드를 미리 정한 시간, 5분이나 10분 정도만 봐라 그리고 다음과 같이 질문을 하라

• 가장 먼저 시선을 끈 코드 구성요소(변수, 클래스, 프로그래밍 개념등)은 무엇인가?
• 왜 그런가?
• 두 번째로 주의를 끈 것은 무엇인가?
• 왜 그런가?
• 그 두 가지(변수 ,클래스 , 프로그래밍 개념 등)는 서로 관련이 있는가?
• 코드에 어떤 개념들이 존재하는가? 그 개념 요소들은 다 알고 있는가?
• 코드에 어떤 문법 요소들이 존재하는가? 그 문법 요소들은 다 알고 있는가?
• 코드에 어떤 도메인 개념들이 존재하는가? 그것들을 다 알고 잇는가?

모니터링​

코드를 읽을 때는 무엇을 읽고 있는지, 이해는 하고 잇는지를 계속 추적 하는것이 중요하다. 코드를 프린트를 해서 이해되는 라인과 이해되지 않는 라인을 표시하는 것도 좋은 방법이다.

코드리뷰할 때 적용 해볼 수 있는 요소​

• 코드 작성자가 내린 결정 사항이 무엇인가? 에를 들어 특정 라이브러리나 api를 사용하기로 한 결정, 자료구조, 특정 디자인패턴 등
• 그런 결정을 내리는 데 상정한 가정은 무엇인가
• 그 결정의 효과는 ?
• 그 결정의 잠재적 위험 요소는 무엇인가
• 다른 해결책으로 어떤 것이 있을까?

정신 모델​

문제에 대해 생각할 때 두뇌의 외부에서 만들어지지 않은 모델을 말함. 폴더 구조를 생각 할 때를 예로 들 수 있는데 실제로는 0과 1로 이루어 졌지만 모델로 입혀서 생각을 할 때라고 생각하면된다. 잘못된 정신모델이 LTM에서 완전히 제거가 안되고 남아있을 수 있다.

복잡한 코드에 대한 정신 모델 작업

1. 국지적 모델을 만든다.
   • 큰 개념을 먼저 만든다.
   • 서로 밀접하게 관련되어 있는 라인을 하나의 의존 그래프로 나타낸다고 할 때 이 의존 그래프는 정신 모델을 형성하는 데 중요한 역할을 할 수 있다.
2. 코드에서 관련된 모든 객체와 객체 간의 관계를 나열한다.
   • 코드내에서 객체간에 상호작용을 화이트보드나 디지털 도구를 사용하여 구성 요소를 나열한 다음 그들 사이의 관계를 찾아야 한다.
3. 시스템에 대한 질문을 만들고 이 질문의 답을 사용해서 모델을 개선한다.
   • 시스템에서 가장 중요한 요소는 무엇인가? 모델에 그것들이 포함되어 있나?
   • 이 중요한 요소들 사이의 관계는 무엇인가?
     • 내가 생각 했을 땐 쿠폰이라는 큰 개념이 있고 그 쿠폰에 해당하는 여러 사항들 사용자는 하나의 쿠폰만 쓸 수 있다. 이런 요소요소들의 관계를 적어야한다.
   • 프로그램의 주요 목표는 무엇인가?
   • 목표가 핵심 요소 및 그 관계와 어떻게 관련되어 있는가?
   • 일반적인 사용 사례는 무엇인가? 모델이 그것을 보여주는가?

개념적기계​

• 스키타마 - LTM이 정보를 저장하는 방식이다. 연상을 하고 집어 넣으면 거기에 맞게 조금 더 쉽게 이해를 할 수 있다. 예를 들어 변수를 상자로 설명을 하는 식의 그러나 이러한 점은 때로는 안좋을 수가 있는데 박스에는 여러 값들이 들어갈 수도 있다. 밀접한 정식 모델을 가지고 있으면 (변수 - 상자) 조금 더 외우기 쉬워진다 반대로 뜬금없이 외발자전거 - 변수 이렇게 연관해버리면 이해하기가 어렵다

새로운 언어를 배울 때​

새로운 언어를 배우면 기존에 알고 있던 언어를 LTM에서 유사한 점을 가져와서 STM을 적게 사용하고 작업공간을 효율적으로 사용을해서 조금 더 사용 할 수 있다. 또한 작업에 대한 감정이 좋았었다면 새로운 작업이 주어 졌을 때 과거에 사용했던 알고리즘, 여러 같은 방식을 사용하게 될 확률이 높다.

앞에가 긍정적 전이였으면, 부정적 전이도 있다. 오히려 한 언어에서 다른 언어로의 부정적 전이가 될 수 있다.

꼭 여러 언어를 안다고 지능이 높아지는 건 아니다(체스선수의 예로… )

공통점과 차이점에 의식적으로 주의를 기울이면 새로운 언어를 배우는 일이 쉬워질 것이다.

                      유사점              차이점             비고 

1. 문법
2. 타입
3. 프로그래밍 개념
4. 런타임
5. ide
6. 테스트 방식

오개념​

자신이 옳다고 확신하지만 실제로는 틀릴 때 오개념을 갖게 된다. 오개념은 단순히 자신이 틀렸다는 것을 꺠닫거나 듣는 것만으로는 해결되지 않는다. 오래되고 잘못된 정신모델을 대체할 새로운 모델이 필요하다.

고기의 표면이 타면 수분은 오히려 날라간다! 알고 있는 거와 다르게 수분 손실이 더욱 크다.

알고있는 언어에서 새로운 언어를 배울 때 기존의 지식을 떨쳐내기 위해 많은 에너지를 소비해야 한다. 개념적인 변화가 필요하기 때문에 시간이 오래걸린다. 우리가 똑똑하지! 못해서가 아니라 부정적인 전이가 돼서 그렇다.

오개념 방지하기​

자신이 옳다고 확신하더라도 여전히 틀릴 수도 있따는 것을 아는 것이 중요하다. 열린 마음

흔하게 발생하는 오개념에 대해 의도적으로 연구해봄으로써 그런 오개념에 빠지는 것을 방지 할수 있다. 오개념들에 대한 체크리스트를 사용하는 것이 도움이 될 수 있다. 같은 프로그래밍 언어를 같은 순서로 학습한 다른 프로그래머들에게 조언을 구하는 것이다.

검색을 할 때​

검색은 STM에 무리가 간다. 그래서 이러한 부하를 줄이기 위해 별도의 문서나 노트를 작성하면 도움이 된다. 만약 코드 내에서 살펴 볼 때는 특정 코드를 살펴본 이유를 주석문으로 작성해놓으면 도움이 된다. 나중에 동일한 코드를 검색하고 확인할 때 도움이 될 수 있다.

업무 중단에 잘 대비하는 법​

1. 정신모델 저장
   • 코드를 작성 중에 잠시 중단요청이 들어 옸다면 주석문을 작성하자. 그러면 나중에 작업을 쉽게 재개할 수 있다.
2. 미래 기억 향상
   • 계획을 완성 할 수 없다면 TODO 문을 적극적으로 사용하자. 기한을 정해 놓으면 더 좋다.
3. 하위 목표 라벨 붙이기
   • 하위 목표를 잘 나누자. 큰 부분에 일을 작은 부분의 문제로 쪼개 놓자.

멀티테스킹​

인스턴트 메신저(페이스북) 특히 메세지를 받는 즉시 답장한다고 응답한 학생들이 상대적으로 매우 생산적이라고느끼지만 수행 능력은 떨어졌다.

방해를 받더라도 가급적이면 인지 부하가 낮을 때 중단이 일어나도록 해야 한다. 예를 들어 슬랙에서 상태를 설정한다던지.

새로운 뉴비 개발자 온보딩​

흔한 문제점으로 새로온 뉴비 개발자에게 한 번에 많은 정보들을 준다. 예를 들어 코드베이스, 도메인, 워크플로 등 여러가지 많은 정보를 주게 되는데 이는 인지 과부화를 초래하여 새로운 정보를 기억할 공간이 없어서 적응에 어려움을 겪게 된다. 그리고 새 팀원에게 질문을 하거나 과제를 주게 되는데 선임 개발자는 이것이 그냥 흔한 작은 버그를 고치는 과제였겠지만 이는 양쪽 모두 좌절감을 주게 된다. 새로운 팀원은 매우 어려운 프로젝트라고 생각이되고 선임 팀원은 똑독하지 않다고 생각이 되며, 이는 팀워크가 앞으로 잘 이뤄질 것이라고 기대하기 어렵다.

작업은 하나의 프로그래밍 활동으로만 제한​

탐구 - 코드베이스의 전체적인 이해를 위한 코드 훑어보기 검색 - 특정 인터페이스를 구현한 클래스 찾기 전사 - 구현할 메서드에 대한 명확한 계획을 알려주기 이해 - 코드의 여러 측면에 대해 이해하기, 예를 들면 특정 메서드를 요약하기 증가 - 향후 계획을 포함해서 기존 클래스에 한 가지 기능을 추가하기 적응 기간에는, 구체적으로 다섯 가지 범주 각각에 해당하는 활동을 선택하고 새 팀원에게 하씩 시키는 것이 가장 좋다.

만드는 것보다 이해를 하는 것이 더 좋을 떄도 있다

• 새 팀원이 코드의 특정 부분을 이해하길 원하면 구현 작업 대신, 해당 코드를 이해하도록 요청해야 한다. 예를 들어 기존 클래스의 요약을 작성하거나 특정 기능이 실행에 참여하는 모든 클래스를 기록하도록 요청한다.

새로운 개념을 배우는 사람들은 추상적인 용어와 구체적인 에를 모두 배울 필요가 있다. 또한 새로 배운 개념을 기존 지식과 연결할 시간이 필요하다.

후기​

DDD-START

마틴 파울러 엔터프라이즈 애플리케이션 아키텍처 패턴

도메인 모델시작하기​

1. Get/Set method 습관 X
   • 의미 있는 단어로 사용
2. 불변 객체 사용하기
3. 생성자를 적극적으로
   • 객체를 비지니스적으로 불완전한하게 시작하지 말자 만약 불완전하게 시작이 된다면 그때는 리팩토링을 생각해보자.
4. 유비쿼터스 언어
   • 전문가 관게자 개발자 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서 도메인모델, 코드 테스트 등 모든 곳에서 같은 용어를 사용한다. 이렇게 하면 소통의 모호함이 줄어들고 불필요한 해석 과정을 줄일 수 이싿.
5. 도메인 용어에 알맞은 단어를 찾는 시간을 아까워 하지 말자.

인프라스트럭처 영역은 구현 기술에 대한 것을 다룬다. RDMS 연동을 처리하거나 메시징 큐에 메세지를 전송하거나 수신하는 기능, 몽고 DB나 redis와의 데이터 연동을 처리한다. SMTP를 이용한 메세지 발송 기능을 구현하거나 http클라이언트를 이용해서 rest api를 호출하는 것도 처리한다. 실제 구현을 다룬다. 도메인 영역, 응용 영역, 표현 역역은 구현 기술을 사용한 코드를 직접 만들지 않는다. 대신 인프라스트럭처 영역에서 제공하는 기능을 사용해서 필요한 기능을 개발한다.

계층 구조 고수준 모듈은 의미있는 단일 기능을 제공하는 모듈, 저수준 모듈은 하위 기능을 실제로 구현하는것. 고수준 모듈이 저수준 모듈을 의존하면 안된다. 그러면 테스트도 어렵고 구현 변경이 어려워진다.

DIP

DIP를 잘못 생각하면 단순히 인터페이스와 구현 클래스를 분리하는 정도로 받아드릴 수 있다. 핵심은 고수준 모듈이 저수준 모듈에 의존하지 않도록 하는 것이다.
계층 구조에서 생각해봤을 때 도메인에서 인프라스트럭처를 의존하면 안된다. DIP를 생각해야한다. (p.76)
도메인에 interface를 집어 넣고 인프라에서 그걸 의존받아 구현하게 만들어야한다.

엔티티

주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현.

벨류

배송지 주소를 표현하기 위한 주소Address, Money와 같은 타입이 밸류

애그리거트

엔티티와 밸류 객체를 개념적으로 하나로 묶은 것. Order Entity, OrderLine, Orderer ‘주문’ 애그리거트로 묶을 수 있다.
에그리거트가 잘 되어있으면 복잡한 도메인도 사위 수준에서 모델 간의 관계를 더 잘 파악할 수 있다. (p.99)
경계가 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다. 도메인 규칙에 따라 함꼐 생성되는 구성요소는 한 에그리거트에 속할 가능성이 높다. 함께 변경되는 빈도가 높은 객체는 한 애그리거트에 속할 가능성이 높다. 예를 들어 주문에 상품 개수, 배송지 정보, 주문자 정보, 주문 금액 등이 될 수 있다.
흔히 ‘A가 B를 갖는다’로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉬운데, 항상 그런것은 아니다 좋은 예가 상품과 리뷰이다.
상품 상세 페이지에 들어가면 상세 정보와 리뷰 내용을 보여줘야한다는 요구사항이 있을 때 Product와 Review 엔티티가 한 애그리거트에 속한다고 생각 할 수 있으나 함께 생성되지 않고, 변경될때 한번에 변경되지 않는다. 주체도 다르다 Prodcut는 변경자가 상품 담당자라면 Review는 생성과 변경하는 주체는 고객이다.

에그리거트 루트
에그리거트에 속한 모든 객체가 일관된 상태를 유지하도록 전체를 관리하는 주체 (p.104)

트랜잭션
웬만하면 에그리거트에서 트랜잭션을 한 에그리거트만 변경하자. 응용 서비스에서 수정하도록 구현하자. 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이된다.

리포지터리와 애그리거트​

애그거트는 개념상 한개의 도메인 모델을 표현하므로 객체의 영속성을 처리하는 리포지터리와 애그리거트 단위로 존재한다. Order와 OrderLine을 물리적으로 각각 별도의 DB에 저장한다고 해서 각각 따로 리포지토리를 만들진 않는다. Order는 애그리거트 루트고 OrderLine은 애그리거트에 속하는 구성요소이므로 Order위한 리포지터리만 존재한다.

외래키(ID)로 참조하도록 entity를 설계하면 장점​

1. 애그리거트간의 의존 결합도를 낮춘다.
2. 직접 참조하면 성능에 관련된 여러 고민들을 안해도된다. 지연로딩, 즉시로딩과 같은.
3. 단일 DB를 안써도 된다.확장성에 좋다 에그리트별로 다른 db를 사용 할 수 있다.

ID를 이용해서 사용하면 즉시 로딩 지연로딩을 고민할 필요 없어지고 구현 복잡도도 낮아진다. 경계도 명확해지기 때문에 모델의 복잡도도 낮춰준다. (p.116)

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 된다면 애그리거트에 팩토리 메서드를 구현하는 것을 고려해 보자. 도메인 응집도가 높아지는 효과가 있다. (p.126)

entity에서 기본생성자를 제공해야하는 이유는 DB에서 데이터를 읽어와 매핑된 객체를 생성할 때 기본 생성자를 이용해서 객체를 생성하기 때문이다 jpa 프로바이더가 객체를 생성할 때만 사용한다.

CQRS​

명령모델과 조회모델을 분리하는 패턴이다. 명령 모델은 상태를 변경하는 기능을 구현할 때 사용하고 조회 모델은 데이터를 조회하는 기능을 구현할 때 사용한다.

조회 모델을 구현할 때 JPA를 사용할 때도 있고 마이바티스를 사용할 때도 있고 JdbcTemplate을 사용할 수 있다. 맞춰서 사용하자. 꼭 Jpa만 사용하지 말자.

조회쿼리 깔끔하게 작성하는 법 Spec을 사용하면 코드를 깔-끔하게 조회 쿼리에서 사용 할 수 있다.

public class OrderSummarySpecs {
    public static Specification<OrderSummary> ordererId(String ordererId) {
        return (Root<OrderSummary> root, CriteriaQuery<?> query, CriteriaBuilder cb) ->
                cb.equal(root.<String>get("ordererId"), ordererId);
    }

    public static Specification<OrderSummary> orderDateBetween(
            LocalDateTime from, LocalDateTime to) {
        return (Root<OrderSummary> root, CriteriaQuery<?> query, CriteriaBuilder cb) -> cb.between(root.get(OrderSummary_.orderDate), from, to);
    }
}

List<OrderSummary> results = orderSummaryDao.findAll(spec);
        assertThat(results).hasSize(1);

코드 출처 https://github.com/madvirus/ddd-start2

응용 서비스의 크기​

크게 두 가지 방법으로 응용 서비스를 만드는데

1. 한 응용 서비스 클래스에 한 도메인의 모든 기능 구현

   1. 장점
      • 중복 코드를 없앨 수 있음.
   2. 단점
      • 코드의 줄 수가 길어진다.
      • 관련 없는 코드들이 많아서 코드 이해하는데 시간이 오래 걸릴 수가 있다.

2. 구분되는 기능별로 응용 서비스 클래스를 따로 구현하기

   1. 장점
      • 코드라인을 깔끔하게 유지 할 수 있다.
   2. 단점
      • 중복 코드가 있을 수 있다.
      • 자칫 클랙스가 너무 많아 질 수 있다.

   단점 극복

   • 중복 코드는 helper클래스를 따로 두어서 해결 할 수 있다 (MemberCheckHelper.validateMember)
   • 클래스 많아 지는 부분은 알딱깔짝센

Impl이 필요한가?

오-래전에는 Dynamic Proxy를 사용해서 reflaction을 proxy가 구현됐지만 지금은 알아서 cglib로 사용하기 바이트코드 조작으로 사용하기 Proxy를 구현하기 때문에 인터페이스를 사용하여 상속 받을 일 없으면 안써도 괜찮다.

도메인 서비스​

도메인 서비스는 도메인 영역에서 위치한 도메인 로직을 표현할 때 사용. 로직을 실행 할 때 주체가 모호 할 때 도메인영역에 서비스를 넣을 수 있다.

도메인에 도메인서비스를 주입하지 말자. 메소드로 주입하게 처리하자. (p.239)

도메인 로직인지 도메인 서비스 로직인지 햇갈린다면

상태를 변경하는건지 계산하는건지 생각을 해보자. 상태를 변경하면 도메인에 들어가고 계산을 하게된다면 도메인 서비스 로직에 들어가는 게 코드 유지보수하기가 좋다.

Find 함수에도 version을 강제로 증가 시킬 수 있다

애그리거트루트에 값이 변경이 안되었어도 다른 애그리거트가 변경이 된다면 버전을 업데이트 해줘야한다. 이 때 find 함수 안에 강제로 version 증가 할 수 있도록 LockModeType 인자가 있다

Offline Pessimisitic Lock​

비관적인락과 낙관적인락 보다 더 엄격하게 lock을 거는 방법이다. 컨셉은 조회 할 때부터 락테이블을 만들고 지금 조회중이면 락테이블을 update를 해서 선점을 표시하고, 다른 트랜잭션이 조회를 못하도록 하는 방식이다. 이 방식은 여러 고려사항을 해야하는데 최대 lock잠금 시간을 얼마나 해야 하는지와 선점을 하지 못한 트랜잭션은 어떻게 해야할지가 고려대상이다. 선점을 하지 못한 트랜잭션이 스핀락 문제가 발생 할 수도 있으니 주의 해야한다.

바운디드 컨텍스트 p.278​

모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.
용어를 기준으로 구분한다.
만약 한 바운디드 컨텍스트에서 여러 도메인을 구현해야된다면 패키지로 쪼개서 개발을 하는 게 좋다.

Event 방식으로 구현 시 생각 할 점​

1. 이벤트 주체를 추가 할지 여부
   • Event Entry
     • 예를 들어 요구사항이 Order가 발생시킨 이벤트만 조회하기 이런식으로 요청이 왔을 때 기능을 구현을 할 수가 없다.
2. 포워더에서 전송 실패를 얼마나 허용할 것이냐
   • 이벤트를 전송하는데 3회 이상 실패했다면 해당 이벤트는 생략하고 다음 이벤트로 넘어간다는 등의 정책이 필요하다.
3. 이벤트 손실
   • 이벤트 저장소를 이용하는 방식은 이벤트 발생과 이벤트 저장을 한 트랜잭션으로 처리하기 때문에 트랜잭션이 성공하면 이벤트가 저장소에 보관된다.
4. 이벤트 순서
   • 이벤트 발생 순서대로 외부 시스템에 전달해야 할 경우, 이벤트 저장소를 사용하는 것이 좋다.
5. 이벤트 재처리
   • 가장 쉬운 방법은 마지막으로 처리한 이벤트의 순번을 기억해두었다가 이미 처리한 순번의 이벤트가 도착하면 해당 이벤트를 처리하지 않고 무시하는 것.

이벤트가 헨들러가 멱등성을 가지면 중복처리에 대한 부담이 줄어든다.

예를들어 시스템 장애로 인해 같은 메세지가 보내져도 상관없는 시스템 개인정보의 주소가 변경된다던지 이런 시스템일 경우 중복처리의 부담감이 줄어든다.

CQRS​

도입을 고민 할 때는 트래픽이 많은지와 안 많은지 또 도메인이 복 잡지 안한지를 고민을 하고 CQRS를 고민을하면 두 모델을 유지하는 비용만높고 얻을 수는 있는 이점이 없다. 반면에 트래픽이 높은 서비스으인데 단일 모델을 고집한다면 유지 보수 비용이 높아질 수 있으니 도입을 고려 할만하다.

후기​

Domain Driven Design 책을 읽어야지 하고 지금까지는 개인적으로 도메인에 대해 정말 딥하게 고민 한 적도 없었고
어떤 구조가 더 좋은 구조일까? 도메인을 어떻게 쪼개야 할까? 이런 고민을 깊게 안해 보고 DDD를 읽는 건 도움이 전혀 안된다고 생각을 해서 미루고 미루다가 그래도 최근에는 조금은 어떤 구조가 객체지향적이며 유지보수하기 좋을까라는 고민을 하고 있는 시기여서,
먼저 가볍게 코드도 많은 범균님의 DDD Start를 선택을 했었다. 이 선택은 후회가 없는 선택이였다.
만약 이 책이 아니라 이론만 가득한 책들을 봤다면 아직 "내공이 부족해서 중도 포기를 하지 않았을까"라는 생각을 하게 되었고 가볍게 지금까지 들어보기만 했던 애그리거트 애그리루트 개념에 대해 이해를 할 수가 있었고 단순히 DDD에서 끝내는 것이아니라 MSA를 고려하거나 Event를 처리 할 때 한 번씩 했었던 생각들 나는 어떻게 처리를 했는지 생각을 해 볼 수 있었고, 더욱이 범균님이 실제로 코드들을 작성하면서 했을만한 여러 고민들을 실제로 옆에서 지켜보는 듯한 느낌이 들어 나에게 많은 도움이 되는 책이였다!

규칙없음

색다른 유형의 직장​

스스로 내린 판단을 실행에 옮길 때 거추장스러운 절차를 밟을 필요 없이 오히려 더 많은 자유를 갖게 되면, 직원들은 좀 더 나은 결정을 내리게 되고, 회사도 책임을 묻기 더 쉬워진다. 그러면 더 즐겁고 의욕적인 분위기가 되어 민첩한 조직이 된다. 이러려면 두 가지 요소가 필요한데

인재 밀도를 키워라​

뛰어난 실력을 갖춘 인재들로 조직을 꾸리면 거추장스러운 통제 장치가 필요 없어진다. 인재 밀도가 높을 수록 지원들에게 허용되는 자유는 더욱 커진다.

솔직성을 키워라​

재능 있는 직원들은 서로에게서 많은 것을 배운다. 그러나 예의만 강조하는 규정집은 성과를 내는 데 필요한 피드백을 서로에게 제공하는 것을 막는다. 습관처럼 피드백을 서로 주고받게 되면 일을 더 잘하게 되고 동시에 서로 책임질 수 있는 행동을 하게 되며, 통제는 크게 필요하지 않게 된다.

이 두가지가 되면

통제를 줄이면된다​

몇 가지 가이드라인만 주어지면 되는데 ‘통제가 아닌 맥락으로 이끌 것’.’평사원에게는 상사의 비위를 맞추려 들지 말 것’ 등과 같다.
리더로서 당신의 첫 번째 목표는 직장에 비범한 동료들로만 채워진 근무 환경을 조성하는 것이다.
비범한 동료들은 중요한 일을 능숙하게 처리한다. 또한 놀라울 정도로 창의적이고 열정적이다.
심사가 비뚤어졌거나 게으르거나 착하긴 한데 성과가 별 볼 일 없거나 매사를 부정적으로 보는 사람들이 끼어 있으면, 팀의 전반적인 성과가 저하된다.

자신의 생각을 있는 그대로 말하라(긍정적인 의도로)​

피드백을 주고 받을 때는 선의를 가지고 정식으로 문제를 제기한 후 자신의 감정과 의견, 상대방에 대한 피드백을 솔직하게 표현하게 하였다.

대부분의 여러이유로 피드백을 주기 포기하는데 '까다로운' 사람이라는 인상을 주고 싶지 않다거나, 내키지 않는 논쟁에 말려들고 싶지 않다거나, 사람들이 내 견해를 지지하지 않을 것 같다거나. 그러나 넷플릭스에서 일하는 사람이라면 아마, 말을 꺼낼 것이다. 상사의 구상이 실제로는 제대로 구현되지 않을 것 가탇고 제동을 건 후 더 좋은 아이디어를 제시한다. 동료의 의견에 동의하지 않거나 도움이 될 만한 피드백이 있는데도 말을 하지 않는 것은, 회사에 불충이다.

실제 사례

매니저가 인사 몇마디를 건넨 후 친절한 말투로 몇 가지 피드백을 드리고 싶습니다라며 얘기를 꺼냇다. 나는 아무렇지도 않은 표정을 지으려 애썼다. 그는 내가 사전에 인터뷰이들에게 보낸 이메일이 너무 체적이라서 마치 지를 받는 듯한 느낌이 들었다고 했다. 그후 자칫 불편한 기색이 드러나지 않을까 표정부터 신경이 쓰였다. 나중에 그피드백은 도움이 됐다. 솔직한 피드백이 이처럼 도움이 된다.

부정적인 피드백을 받을 때 인간의 두뇌는 신체적인 위협을 받을 때와 마찬가지로 싸우거나 달아나는 반응을 보이는데, 혈류로 호르몬이 분비되고 대응 시간이 빨라지며 감정이 격해진다.

피드백을 제사해야 할지 고민할 때, 사람들은 두 가지를 놓고 갈등한다. 상대방의 감정을 건드리고 싶지 않다는 생각과 그래도 그 사람이 성공할수 있게 도와야한다는 생각이다. 넷플릭스에서는 간혹 상대방의 기분을 상하게 하더라도 서로 성공할 수 있게 도우라고 말한다. 무엇보다도 올바른 환경에서 올바른 방식으로 접근하면, 상대방의 감정을 상하게 하지 않고도 피드백을 줄 수 있다는 사실을 우리는 확인해싿.

임금님에게 벌거벗었다고 말하라​

피드백을 받을 때의 태도도 중요하다. 어떤 비판에도 감사한 마음으로 대응하고 ‘소속 신호'를 줌으로써 피드백을 마음 놓고 제시해도 좋다는 사실을 보여준다.

목소리에 감사의 뜻을 담거나 상대방에게 물리적으로 가까이 다가서거나 호의적인 시선을 보내는 것 같은 사소한 제스처도 소속 신호가 될수 있다. 용기를 내줘서 고맙다고 말하거나 사람들 앞에서 그런 용기에 관해 언급하는 식의 적극적인 제스처도 좋은 소속 신호다. 소속 신호의 기능은 ‘지금 우리는 안전한가? 우리 앞으로 이들과 어떻게 될 것인가' 보이지 않는 위험이 숨어있는 것은 아닐까'와 같이 오래전부터 인간의 두뇌 속에 자리 잡고 있던 질문에 대답하는 것이다. 상사이든 부하직원이든 회사에 소속된 사람들이 소속 신호를 가지고 모든 순간에 솔직하게 응답할수록 사람들은 더욱 용기를 내어 솔직해질 것이다.

회의 중 누가 반대를 하고 의견을 격하게 주고 받았다면 회의가 끝나고 어깨에 손을 얹고 오늘 회의 아주 좋았어. 의견을 주어 고마웠네라고 미소 짓자

4a 피드백 지침​

피드백을 줄 때​

1. AIM TO ASSIST: 구체적인 행동 변화가 상대방 개인이나 회사에 어떻게 도움이 되는지 분명히 설명한다. 자신을 위한 것이 아님을 분명히 납득시켜야 한다. 외부 파트너와 회의할 때 이를 쑤시는 모습이 무척 거슬립다는 잘못된 피드백이다. 올바른 피드백은 외부 파트너와 회의를 할 때 이를 쑤시는 습관을 고치면, 파트너들이 팀장님을 좀 더 전문가답다고 여길 것이고 그래서 더욱 긴밀한 관계를 쌓을 수 있을겁니다.” 이다.
2. ACTIONABLE: “교수님의 발표 메세지 자체를 망치고 있다" 이는 잘못된 피드백이다. “청중에게 그런 방식으로 의견을 구하게 되면, 결국 특정 사람들만 참여하게 됩니다" 더 좋은 방법은 “회의장에 있는 다른 나라 출신들에게 의견을 구하는 방법을 찾을 수 있다면 교수님의 메세지는 더욱 분명하게 전달될 것입니다.”

피드백을 받을 때​

1. APPRECIATE(감사해라): 어떻게 해야 상대방의 고언을 신중하게 듣고 , 열린 마음으로 그 의미를 짚어보며, 수세를 취하거나 화를 내지 않고 감사한 마음을 표현할 수 있을까" 라고 자문을 해야한다. 자존심이나 체면이 중요한게 아니다.
2. ACCEPT OR DISCARD: 항상 반드시 따를 필요는 없다. 진심을 담아 “고맙다"고 말하되, 피드백의 수용 여부는 전적으로 받는 사람에게 달렸다

모든 것을 공개하라​

투명성은 우리 직원들이 책임감을 가지고 행동할 것으로 회사가 믿는다는 걸 보여주는 가장 중요한 상징적 개념이다. 우리가 그들에게 보여준 신뢰는 그들로 하여금 주인의식과 헌신, 책임감을 갖게 한다.

소수의 불미스러운 행동으로 다수를 문책하는 일은 없어야 한다.

실수를 들어내라​

실수를 들어냄으로써 더 믿음이 가게 되기 마련이고, 리더가 실수를 하면 직원들은 아 실수는 누구나 하는 거구나라고 생각을 하게 된다. 그렇게 되면 성공 여부가 확실하지 않아도 과감하게 모험을 선택한다. 이는 전반적인 회사에 혁신으로 이어진다. 자신의 약점을ㄷ ㅡ러내면 신뢰를 얻을 수 있다. 도움을 청하면 더 배울 수 있다. 실수를 인정하면 용서받을 수 있다. 리더가 실패한 사례를 공개하면 직원들은 더욱 용기를 갖고 모험하게 된다. 성공 했을 때는 조그맣게 얘기하거나, 스스로를 말하지 말고 다른 사람들의 입에서 그 말이 나올 때까지 가다려라, 하지만 실수를 했을 떄는 분명하게 말하고 큰소리로 말함으로써 모든 사람이 당신의 실수를 알고 타산지석으로 삼게하다. ‘잘한 일은 작은 소리로, 실수는 큰 소리로' 말하라

실수 효과​

실수 효과는 똑같은 실수를 저질러도 평소 인상이 좋았던 사람에겐 그 실수가 오히려 그사람의 매력을 증가시키는 반면, 그 반대인 사람에겐 가뜩이나 좋지 않았던 인상이 더욱 안좋아지는 역할을 하는 것이다. **리더는 자신의 실수를 공개하기 전에, 먼저 유능함을 입증하고 사람들의 신뢰를 얻어야한다.**

어떤 의사결정도 승인받을 필요 없다.​

회사의 상사는 직원들의 결정을 승인해 주거나 거부하기 위해 존재한다. 이것이야말로 혁신을 막고 성장을 더디게 하는 가장 확실한 방법이다. 상사의 비위를 맞추려 들지 말라 회사에 가장 이득이 되게 행동하라. 회사 내의 모든 직원이 각자 판단에 따라 의사를 결정할 때 가장 빠르고 가장 혁신적인 아이디어가 나올 수 있다고 생각한다. 분산된 의사결정은 인재 밀도가 높고 극도로 투명한 조직에서만 위력을 발휘한다.

배팅 전후에 취해야 할 조치​

베팅을 잘못했다고 쫓아내지는 않는다. 그보다도 큰일을 벌일 수 있는데도 칩을 사용하지 않거나, 잘못된 판단이 장기간 이어질 경우에만 쫓아냈다.

실패 했을 때는

1. 그 프로젝트에서 무엇을 배웠는지 물어봐라.
2. 그일로 수선을 피우지 마라
   • 성과를 내지 못한 베팅을 두고 법석을 떠는 것은, 앞으로 모험 따위는 생각도 하지 말라고 경고와 다를 바 없다. 사람들은 당신이 말로만 분산 의사결정을 말할 뿐, 실제로는 그런 방식을 용납하지 않는다고 생각할 것이다.
3. 실패를 션샤이닝하라고 요청하라
   • 션사이닝이란 실패한 모험을 숨기지 않는 걸 말함.
   • 자초지종을 솔직하게 밝히는 공개 메모를 쓰도록 권하고, 거기에서 얻은 교훈을 첨가하게 한다.

실패한 베팅은 감춰야 할 ‘sos’가 아니라 누구나 하는 실수일 뿐이다. 그러나 실수를 얼버무리려 하거나 같은 실수를 반복한다면(실수를 인정하지 않으면 반복할 가능성이 커진다), 결과는 심각해진다.

실패에서 어떤 것을 얻었는지 배워라. 그걸 션샤이닝 해서 나의 실수를 팀원들이 하지 않도록 해라

키퍼 테스트​

우리는 가족이 아니라, 팀이다.​

우승팀이 되려면 모든 포지션에 최고의 선수가 자리를 잡고 있어야 한다. 뭔가 큰 잘못을 저지르거나 게으름을 피우지 않는 한 쫓겨날 일은 없다고 생각한다면, 요즘 사람이 아니다. 프로스포츠나 올림픽에서 감독의 역할은 뛰어난 선수를 위대한 선수로 바꾸는 것이다. 안주하지 마라.

즉각적인 키퍼 테스트​

상사와 일대일로 말할 기회가 있을 때 이렇게 묻는 것이다.

“제가 일을 그만둔다고 하면, 어떻게 해서든 저를 붙잡으실 건가요?” 상사의 답을 들으면 자신이 처한 상황을 정확히 알 수 있다.

3가지 반응이 있을 수 있는데

1. 무슨 수를 써서라도 당신을 놓치지 않겠다고 말하는 경우
2. 명확하지 않지만 피드백을 주는 경우 - 제 역하을 할 수 있도록 도와주는 말이니 나쁜건 아니다
3. 노력할 기색이 없는 경우 - 이는 나쁠 수 있지만 아무것도 모르고 있다가 어느 날 아침, 느닷없이 회사를 그만두라는 통고를 받는 거 보다는 낫다.

피드백 서클​

다른 사람의 이야기를 할 때는 그 사람 면접에서 할 수 있는 말만 하라.

360 서면 평가​

사람들은 가능하면 너그럽고 지지하는 어조로 피드백을 주려고 배려한다. 누군가가 선을 넘기면, 이봐요, 그런 말은 도움이 안돼요 라는 피드백이 날라온다 성과 평과는 솔직한 직장 환경을 만드는 데 그다지 바람직한 메커니즘은 아니다. 피드백은 보통 일방적이고(하향 평가) 오직 한 사람(상사)에게서 나오기 때문이다. 반면 360도 서면 평가는 연례적으로 시행 할 수 있는 좋은 피드백 메커니즘이다. 다만 익명이나 점수를 매기는 일은 피하고, 결과를 연봉 인상이나 승진과 연계하지도 마라. 각오가 된 사람에게는 언제든 공개적으로 코멘트를 하라. 긍정적인 코멘트와 시정을 요구하는 코멘트는 25%대 75% 정도가 좋다. 피드백은 실질적인 내용을 담아야 한다.

통제가 아닌 맥락으로 리드하라​

아이가 위험성을 충분히 이해한 것 같다면, 더는 행동을 제한하거나 감독하지 않고 가고 싶어 하는 파티에 가게 해준다. 이것이 맥락으로 리드하는 방식이다. 하지만 평소에 신뢰를 줄 만큼 분별력이 잇는 아이라면, 맥락을 짚어준 다음 삼가서 처신하리라 여기고 그 이상 참견하지 않아야한다. 인재 밀도가 낮을 수록 나서서 감시하고 제대로 된 결정인지 확인해야한다. 밀도가 높다면 맥락만 짚어줘야 제 실력을 발휘할 것이다. 넷플릭스는 상사가 아니라 정보에 밝은 주장이 의사결정권자다. 상사는 팀이 현명한 결정을 내릴 수 있도록 맥락만 짚어줘야한다. 구조는 피라미드가 아니라 나무여야한다. 169p 맥락을 짚어주고 토론하여 의견을 확실하게 조율하라. 부하직원이 어리석은 행동을 했을 때 나무라지 말라. 대신 맥락을 제대로 짚어주지 않았는지 자문해 보라. 목표와 전략을 분명히 전달하고 실행하는데 필요한 의욕을 제대로 불어넣었는가? 팀이 좋은 결정을 내릴 수 있도록 모든 가설과 위험을 확실하게 설명했는가? 비전과 목표에 관해 부하직원들과 의견을 조율했는가?를 의심해라 부하직원들이 당신과 당신 주변 사람들로부터 받은 정보를 사용하여 팀을 바람직한 방향으로 밀고 나갈 때 맥락을 잘 짚어주어 훌륭한 결정을 직접 내리가 하면, 조직은 성공한다.

모든 건 상대적이다.​

전략과 유연성이 필요하다. 항상 모든 사람에게 같은 처방을 할 수 없다. 사소한 실수가 잦으면 고통스럽겠지만, 그래도 무언가를 배울 수 있는 좋은 기화가 된다. 실수는 혁신 사이클에 좋은 영양분이다.

함께 자라기​

오랜만에 다시 읽어보는 함께 자라기

머리말 - “내가 정말 잘할 수 있을까? 아니, 우리가 정말 자랄 수 있을까?”​

“내가 정말 잘할 수 있을까?”의 질문을

• 내가 정말 자랄 수 있을까?
• 우리가 정말 함꼐 자랄 수 있을까?
• 우리가 정말 매일매일 함께 자랄 수 있을까?

자라기 - 학습​

학교 학습 vs 야생학습

• 야생 학습은 대부분 협력적이다.
• 야생 학습은 대부분 비순차적이다
• 야생 학습은 대부분 자료에 한정이 없다.
• 야생 학습은 대부분 명확한 평가가 없다.
• 야생 학습은 대부분 정답이 없다.
• 야생 학습은 대부분 목표가 불분명하고 바뀌기도 한다.

사람을 뽑을 때는 구조화된 인터뷰(행동중심적 인터뷰)와 실제 작업을 해보도록 하는 샘플 테스트, 그리고 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것등을 권장합니다.

행동중심적 인터뷰(structured behavioral interview)란? “개발자로써 협력에 대한 철학이 뭔가요?” 같은 질문은 행동을 묻는 것이 아니라, “지난 프로젝트에서 동료가 어려움을 겪을 때 어떤 행동을 하셨는지 구체적 예를 들어주세요”라고 물어야 합니다.

1만 시간의 법칙을 제대로 적용하려면 “의도적수련”, 애자일 철학을 활용하는 것인데, 즉 피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것, 이 두가지가 중요하다.

내가 A 작업을 개선하려면 두 가지 질문을 해 봐야 한다

1. 어떻게 하면 더하기보다 곱하기를 할 수 있을까? (복리)
2. 어떻게 해야 고바는 비율을 높일 수 있을까 혹은 이자 적용 주기를 짧게 할 수 있는가

• 자신이 이미 갖고 있는 것들을 잘 활용하라.
  • 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮여버릴 수 있다. 올해 몇 권을 읽었다고 자랑하지 말고, 내가 그 지식을 얼마나 어떻게 활용하는지 반성하라.
  • 점과 점을 이어라 이미 습득한 지식, 기술, 경험 등을 서로 연결 지어서 시너지 효과가 나게 하고 하나의 영역에서 다른 영역으로 왔다갔다하는 것을 자주 해서 다른 영역 간을 넘나들기가 수월해지도록 하라.
  • 새로운 것이 들어오면 이미 갖고 있는 것들과 충도을 시도하라.
• 외무 물질을 체화하라.
  • 계속 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다. 주기적으로 외부 자극을 받으면 좋다. 단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다.
• 자신을 개선하는 프로세스에 대해 생각해 보라.
  • A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라
    • 내가 생각한 회고는 어떤 것을 했고, 어떤 것을 느꼈고, 어떤 교훈을 배웠는지, 또 자기계발은 어떤걸 했는지 4가지 정도면 적당 할 거 같다.
  • 나를 개선하는 과정을 어떻게 하면 개선할 수 있을지 고민하라.
• 피드백을 자주 받아라
  • 순환율을 높여라. 1달, 작게라도 실험해 보는 것이 좋다.
  • 일찍, 그리고 자주 실패하라. 실패에서 학습하라

소프트웨어 개발자 vs 컴퓨터 프로그래머 컴퓨터 프로그래머는 다른 사람이 준 스팩대로 개발하는 것을 주 업무로 하며 그 과정에서 협상, 설득이 크게 필요하지 않는다. 반면 소프트웨어 개발자는 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많습니다. 즉 소프트웨어 개발자가 되는 걸 목표로 해야한다.

달인이 되는 비결

1. 동기가 부족하다.
2. 피드백을 제때 받지 못한다

양치질 예 단순하게 양치질을 10년 한다고 달인이 되는 건 아니다. 어떻게하면 더 잘할 것이고 치과의사에게 피드백을 받음으로써 달인이 된다. 어떻게 하면 내가 더 성장 할 수 있을까를 고민 해본다면, 코드 리뷰를 받거나, 짝 프로그래밍을 진행하거나, 고객에게 개발하는 프로그램에서 피드백을 적극적으로 요구하거나, 직관성을 높이려면 다양한 스스로의 실험을 해봐야 할 거 같다. 업무를 받았을 때 기존에는 3일 이내로 잡았다면 마감기한을 2일로 당겨서 진행을 해본다던지 등을 통해 해볼 수 있을 거 같다.

의도적 수련(Deliberate Practice)​

나의 작업 난이도와 실력이 비슷해야한다. 미하이 칙센트미하이의 몰입이론과도 일치하는 부분인다.

업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 것이다.

제자리걸음에서 벗어나기

1. 지루함을 느끼는 경우: 실력 낮추기

   예를 들면 마우스를 안쓰고 키보드로만 개발을 한다던지, 디버거를 안써본다던지, 컴파일을 30초마다가아닌 5분마다 한다던지, 조금 더 집중을 할 수 있는 환경을 만들어서 몰입을 높여 만족도를 높인다.

2. 지루함을 느끼는 경우: 난이도 높이기

   하루만에 할 개발을 한시간만에 개발 한다던지, 100rps 면 되는 시스템을 1,000rps 기준으로 만든다던지. 익숙한 작업을 새로운 언어로 진행한다던지.

3. 불안함을 느끼면 : 실력 높이기

   사회적 접근: 나보다 뛰어난 전문가의 도움을 얻는 것. 짝 프로그래밍을 해달라고 부탁하거나, 스터디

   도구적 접근: 오픈소스를 활용한다던지, 괜찮은 도구를 찾는 것

   내관적 접근: 예전에 했던 비슷한일의 경험을 떠올려 보는 것 그때 일을 어떻게 했는지를 떠 올리면서 해결

4. 불안함을 느끼는 경우 : 난이도 낮추기

   아기 버전을 만든다 0.0.1 버전을 목표로한다. WTSTTCPW(What’s the simplest Thing That Coluld Possibly Work?) 동작을 할 수 있는 가장 간단한 건 뭘까? 쉬운 것 부터 먼저하고 어려운 것을 하자

나는 지금까지 몰입을 했던 경험을 생각해보면

• 책에서 말한바와 같이 일을 할 때 난이도가 70%~80%로 정도 느끼는 일들이 몰입을 이끌었고
• 다른 사람들(개발자들)과 일을 협업을 하면서 데이터를 하나하나씩 맞춰 나가면서 퇴근 후 자기 전 내가 생각하고 수정되어야 할 부분들을 빨리 출근해서 이야기하고 싶다라는 경험을 함으로써 몰입을 했었으며
• 기존 사내에 없었던 성능 테스트를 작성하면서 생겼던 생각하지 못했던 여러 어려웠던 일들이 몰입을 이끌었다.
• 이외에도 여러 피드백을 받을 수 있는 일들을 할 때 나는 몰입을 하였고 일에 대해 만족감이 높았고 성장도 높았었다.

지루함을 느끼지 않도록하자 스스로 몰입을 할 수 있는 환경을 만들어나가자. 몰입을 경험 할 수 있는 환경을 만들면 일의 퍼포먼스가 올라가고, 일적으로나 개인적으로나 만족감 성취감이 높고 성장을 더 할 수 있다.

의도적 수련의 예시

1. 역엔지니어링 설계도 없이 완성품으로부터 설계를 추론하는 행위
2. 새로운 프로그래밍 언어를 배울 때 적극적 읽기(무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법)를 한다.
   • 예) 간단한 단어 개수 세기 프로그램를 만들어본다.
   • 다양한 표준 라이브러리를 보고 스타일을 배운다.

누군가에게 빨리 배우려면

• 프로그래밍 언어를 빨리 배우는 비결이 뭔가요? → 그냥 연습하세요가 된다. 이를 구체적인 사건에 대해 말하도록 유도한다. 최근에 익힌 언어가뭐에요? 어떤 시간별로 행동을 하셨어요?

인지적 작업을 높이려면 내가 이 문제를 해결할 때 어떤 과정을 거치는가를 생각하며 자신의 머릿속을 관찰하고 질문을 던지고 분석하는 것이 도움된다.

함께​

소프트 스킬(커뮤니케이션이나 협력)이 중요하다.

백지장도 맞들면 찢어진다? 톱니바퀴 실험

• 혼자 톱니바퀴 수를 세는 것보다 여러명이서 추상화 규칙을 통해 계산을 하는 식의 확률이 더 높았다.
  • 요기서 추상화란 시각적인 여러가지 요소를 이용하는 것이다. 서로의 시각이 다르기 때문에 그림을 그린다던지 글을 같이 그려나가는 추상화 하는 방법을 말함.

짝 프로그래밍 장점 두 사람이라는 구성은 대화를 통해 추상화를 높이게 한다. 한 컴퓨터라는 구성은 구체화를 통해 검증하게 한다. 즉 커뮤니케이션을 통해 높여간다.

신뢰 공유는 복수공유가 더 좋다. 하나를 공유하였을 때는 신뢰를 깍아먹는 공유가 될 확률이 높지만, 복수를 공유하는 것이 상대방의 신뢰를 더 쌓을 수 있는 방법이다. 그리고 커뮤니케이션이 더욱 더 많아지게되는 효과도 있다. 이는 같은 시간을 투자했는데도 신뢰도도 높아지고 성과도 좋아졌다. 실제로 복수 개의 아이디어를 공유했을 때 팀의 결속이 강화되고 오너십을 느낀다는 연구도 있다.

설득

동료나 상사를을 설득 할 때는 객관적인 자료와 연구자료로 결정되는 게 아니다. 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다. 출발은 단순하게 객관적인 자료를 들이미는게 아니라 내가 설득하려는 사람에게서 하는 것이다. 자료에서 출발하는 것이 아니다. 상대방에 대해 얼마나 이해를 하고 얼마나 대화를 해봤냐에 나온다.

팀장 팀장은 행동을 유대하는 대화로 팀원이 자기주도적으로 되게 돕는 사람. p.105

뛰어난 팀의 비밀

1. 팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다 팀원들이 서로 어떻게 상효작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
2. 5가지 성공적 팀의 특징을 찾았는데, 그중 앞도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이다.
3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있다.

실수관리 실수는 예방하는 것이 아닌 관리하는 것이다. 예방만을 위해 노력한다면 실수를 밝히지 않고 숨기려고 할 것인 반면, 실수를 관리함으로써 관리 대상으로 보는 것이다.

심리적 안전감 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음.

애자일​

기민하게 소프트웨어 개발를 다루는 방법론.
애자일의 불확실성을 다루는 방식은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있다.

불확실성에 대비 학습과 협력을 통해 대비를 할 수 있다.

단어 “고객에게 매일 가치를 전하라”

• 고객: 우리의 진짜 고객은 누구인가.
• 매일: 어떻게 점진적으로 가치를 전달할 것인가?, 어떻게 보다 일찍, 그리고 자주 가치를 전할 것인가?
• 가치를: 무엇이 가치인가? 지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가? 비슷한 수준의 가치를 더 값싸게 전할하는 방법은?
• 전하라: 가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가? 고객이 정말 이 가치를 얻고 싶어하는가?

프로젝트 성공확률엔 고객의 참여가 제일 높은 기여를한다. 무섭고 두렵지만 중요한 일이라면 계속 미루지 않는 것도 중요하다.

애자일 도입 확실성 위에서 애자일을 도입하게 되면 실패 확률이 높다. 애자일을 어떻게 도입 해야하는 가는 사실, 애자일 자체는 방법론이기 때문에 정답은 없다. 방법론은 태생적으로 불확실성이기 높기 때문이다. 곁에 있는 주변 사람들과 조금 탐색해나가고 조금 나아가고 확인하고 반복하면 우리의 현 맥락에 맞는 좋은 전략들을 스스로 만들어 나가는 것이 아닐까?

설득의 과학​

1. 상호성
   • 누군가로부터 호의 선물이나 서비스를 제공받았다면 다시 돌려줘야하는 의무감을 느낀다.
   • 동료가 호의를 배풀었다면 호의 1건을 빚진거다. 자연스럽게 yes라 답변을 외칠 가능성이 높다.
     • 점원이
       1. 사탕 하나를 주면 팁 3% 상승.
       2. 사탕 두개를 주면 팁 14% 상승.
       3. 처음에 사탕 하나를 주고 갑자기 멈춘 후 다시 테이블로 돌아와서는 정말 좋은 분들이신거 같은데 사탕하나를 더 드리고 싶군요. 팁의 금액이 달라졌다 (23%상승).
   • 무엇을 주느냐가 아닌 어떻게 주느냐가 중요하다.
   • 상호성의 핵심은 먼저 주라 이때 단순하게 주는 것이 아닌 개인의 취향을 맞추고 예상치 못하는 것을 주는것이 중요하다.
2. 희귀성
   • 사람들은 갖기 힘든 걸 더 갖고 싶어한다.
     • 여객기의 중지 발표
       1. 다음날 여객기 매출이 상승
   • 누군가에게 상품과 서비스를 제안할 때 상대방이 장점만 얘기하는 게 아니라 손실이 무엇인지를 얘기 해줘야한다.
3. 권위
   • 불확실한 상황에서 신뢰를 할 수 있는 전문가를 따른다.
     • 환자들이
       • 물리치료실에 자격증이나 면허증을 걸어 놓는다.
     • 평상복을 입은 사람보다 제복을 입은사람에게 더 신뢰감이 간다.
   • 더 중요한거는 신뢰할만한 전문가라는 것을 신호로 보내는 것이다.
   • 스스로 떠들고 다닐 수는 없다. 이럴 때는 제 3자를 만드는 것이 좋다.
     • 부동산 중개업체는 고객 문의에대한 reception에 응대 방식이다.
       • 전문성을 먼저 언급한 후 고객에게 설명
         • ~xx씨는 임대분야에 15년 경력이라 잘 설명해주실 거에요. 연결해드릴꼐요.
       • 20% 상승
4. 일관성
   • 상대방을 작게라도 먼저 개입시키는 요소가 있어야한다.
     • 집 앞 흉한 표지물 설치동의에 따른 비결은
       • 사전에 창문에 작디작은 표지판을 설치하게 해서이다. 설치 400% 상승으로 나타남
     • 예약 시간을 잘 지키도록 서면으로 본인이 직접 적게해서 18% 상승
5. 호감
   • 사람들은 자신에게 호감을 가지고 있는 사람들이 예스를 외칠 확률이 높다.
   • 어떻게 호감을 높일 수 있을까?
     1. 사람들은 자신과 비슷한사람
     2. 자신을 칭찬하는사람
     3. 자신과 협력을 하고 공통의 목표로 나가는사람
   • 개인적 정보를 교환하고 그 다음에 협상을 진행함으로써 90% 정도의 성공적인 합의를 이끌어냈다.
   • 다른 사람과의 공통점을 찾아내고 정말 진심으로 칭찬을 해라.
6. 사회적 증거
   • 사람들은 확신이 없는 경우 다른 사람의 행동을 보고 의사를 결정하는 것이다.
     • 호텔에 작은 카드로 수건 재사용을 자연 보호에 도움된다고 말함으로써 35%의 reuse를 이끌어 냄
     • 4일 이상 투숙객은 75% 이상 수건 reuse를 한다. 라는 사실을
       • 75%로의 장기 투숙객은 수건을 재사용한다. 라고 reuse 26% 증가

설득에 사회적 증거를 정직하게 알리는 것은 도움이 된다. 그리고 다른 사람들이 이미 하고 있는 행동을 보여주는 것은 훨씬 더 효과적이다. 특히 자신과 유사한 사람들을 예로 든다면 더욱 효과적이다.

예전에 읽은 데일 카네기 인간관계론의 내용과 비슷한 부분이 많은 거 같다. 상대방을 즉 우리는 동료를 설득을 하기위해서는 기본적으로 신뢰를 얻어야하고 그 신뢰를 얻기 위해서 중요한 게 뭔지 생각을 해보면, 노력과 긍정이 제일 중요하지 않을까 생각이된다. 상대방을 존중하는 마음을 가지고 진심으로하는 칭찬을 하고 항상 미소를 짓고 칭찬을 아끼지 말며 내가 먼저 줄 수 있어야하고 하지만 반대로 내가 먼저 줬는데 상대방이 다음에 안 주었다고 불평 불만하지말고 진심으로 인정해주는 수 많은 노력과 긍정들을 통해 상대방에게 좋은 신뢰를 얻을 수 있는 거 같다.

모든 소스코드는 이곳에서 확인 가능합니다!

ConcurrentHashMap 간단하게 만들어보자

동시성 문제 및 일관성을 위해 Key Value 구조로 사용할 때 가장 쉽게 사용하는 것이 CoucurrentHashMap 이였지만 부끄럽게도 항상 내부구조를 보고 이렇게 동시성을 보장하는 거구나라고 생각만 하고 매번 넘겼었는데 이번 기회에 정리하고 한 번 슥-삭 만들어 보려고 합니다. 그래서 결정한 제목은 간단하게 ConcurrentHashMap 간단하게 만들어보자

ConcurrentHashMap​

뭐 여타 다른 말을 생략하고 ConcurrentHashMap 말고도 여러 Map의 구현체들이 있는데, 왜 필요로 했을까를 먼저 생각해본다면 크게 2가지 정도가 있을 거 같은데요.

1. 우리가 자주 사용하는 HashMap은 thread-safe 하지 않은 java collection입니다.

2. Hashtable은 thread-safe하나 synchronized method 레벨에 사용을하여 비용이 매우 비쌉니다.

   • 즉 다시 말해 비용이 많이드는 이유는 Race condition(경쟁상태)이 발생할 수 있는 code block을 synchronized 키워드로 감싸면, 하나의 스레드만 이 진입할 수 있는데, HashTable은 메소드 레벨에서 synchronized를 걸어버려서 다른 스레드가 먼저 진입한 스레드가 이 code block을 나갈 때까지 계속 기다려야 해서 비용적으로 매우 비싼 Collection입니다.
   
   

   // 해시테이블의 put
   public synchronized V put(K key, V value) {
       ...
   }
   

이러한 이유로 멀티 스레드 환경에서의 map이 필요해졌는데 성능까지 신경 써야 하는 문제가 있어서 등장한 것이 동시성 성능까지 챙기게 되는 ConcurrentHashMap입니다. 참고로 자바 1.5버전부터 들어오게 되었습니다.

💡ConcurrentHashMap은 ConcurrentMap을 구현한 해쉬맵입니다.

ConcurrentMap​

ConcurrentMap은 멀티스레딩 환경에서 키/값 작업에 대한 메모리 일관성을 보장하는 java.util.concurrent의 패키지에 있고 구현체로는 ConcurrentSkipListMap, ConcurrentSkipListMap 두 개가 있습니다.

import java.util.concurrent;

public interface ConcurrentMap<K,V> extends Map<K,V> {
    ...
}

그렇다면 어떻게 동시성을 보장할까?​

사실 동시성을 보장하는 방법 중 가장 쉽게는 synchronized를 쓰면 안전하게 동시성을 보장할 수 있지만 쓰기에 따라서 성능 이슈가 있습니다. 특히 위에서 한 번 얘기 했지만, HashTable 에서 얘기됐던 성능이 가장 큰 문제가 있습니다. 이를 ConcurrentHashMap은 정말 멋지고 어-썸한 여러가지 방법으로 개-선을 했는데 크게 두 가지 방법들로 해결합니다.

1. CAS(Compare And Swap) 알고리즘

   final V putVal(K key, V value, boolean onlyIfAbsent) {
       int hash = spread(key.hashCode());
   ...
       else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {           --1
             if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value))) --2
                 break;                   // no lock when adding to empty bin
         }
   ...
   

2. 새로운 Node를 삽입하기 위해, tabAt()을 통해 해당 bucket을 가져오고 bucket == null로 비어 있는지 확인한다.

3. bucket이 비어 있을 경우 casTabAt을 통해 node를 새로 생성하는데 생성에 실패시에 다시 재시도 한다.

static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
        return (Node<K,V>)U.getObjectAcquire(tab, ((long)i << ASHIFT) + ABASE);
}

static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
                                        Node<K,V> c, Node<K,V> v) {
    return U.compareAndSetObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
}

private static final Unsafe U = Unsafe.getUnsafe();

• Unsafe 메모리 접근에 관련된 함수

2. 이미 버킷에 노드가 존재한다면 버킷별로 synchronized 사용합니다.

   final V putVal(K key, V value, boolean onlyIfAbsent) {
   int hash = spread(key.hashCode());
       ...
       synchronized (f) {
       if (tabAt(tab, i) == f) {
           if (fh >= 0) {
               binCount = 1;
               for (Node<K,V> e = f;; ++binCount) {
                   K ek;
                   if (e.hash == hash &&
                       ((ek = e.key) == key ||
                        (ek != null && key.equals(ek)))) {
                       oldVal = e.val;
                       if (!onlyIfAbsent)
                           e.val = value;
                       break;
                   }
                   Node<K,V> pred = e;
                   if ((e = e.next) == null) {
                       pred.next = new Node<K,V>(hash, key, value);
                       break;
                   }
               }
           }
       ...
   

간단한 성능테스트​

그렇다면 정말 성능에서 많은 차이가 날까? get과 put에 대한 간단한 벤치마크를 작성하면서 Hashtable, concurrentHashMap와 성능을 비교해보겠습니다.
간단하게 5개 스레드를 만들고 1,000,000 개 정도 데이터를 넣고 get을 하는 행위를 통해서 비교를 해보면

    private static final Map<Integer, Integer> testHashTable = new Hashtable<>();
    private static final Map<Integer, Integer> testConcurrentHashMap = new ConcurrentHashMap<>();

    @Test
    void test() throws Exception {
        long hashTableAvgTime = measure_GetPut(testHashTable);
        long concurrentHashMapAvgTime = measure_GetPut(testConcurrentHashMap);

        System.out.println("hashTableAvgTime = " + hashTableAvgTime);
        System.out.println("concurrentHashMapAvgTime = " + concurrentHashMapAvgTime);

    }

    private static long measure_GetPut(Map<Integer, Integer> map) throws InterruptedException {
        ExecutorService executor = Executors.newFixedThreadPool(4);

        long startTime = System.nanoTime();

        for (int i = 0; i < 5; i++) {
            executor.submit(() -> {
                for (int j = 0; j < 1_000_000; j++) {
                    int value = ThreadLocalRandom
                        .current()
                        .nextInt(100_000);
                    map.put(value, value);
                    map.get(value);
                }
            });
        }
        executor.shutdown();
        if (executor.awaitTermination(30, TimeUnit.SECONDS)) {
            System.out.println(map.getClass());
        } else {
            executor.shutdownNow();
        }
        long endTime = System.nanoTime();

        return (endTime - startTime) / 5_000_000;
    }

참고로 환경은 m1book Pro, 16GB에서 테스트 해보았습니다.

대략 10번 정도의 테스트 후에 나온 결과 값입니다.

hashTableAvgTime = 1228
concurrentHashMapAvgTime = 317

확실히, 메소드 레벨에서 락을 거는 방법으로 put을 처리하는 hashtable과 달리 ConcurrentHashMap은 버킷당으로 lock을 걸고 cas 알고리즘을 사용하는등을 통한 여러 기법들로 성능상 상승이 나타난 걸로 보입니다.

길었는데 만들어보는 건 다음 2편에서:)

참고

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html
https://www.baeldung.com/java-concurrent-map
https://www.programiz.com/java-programming/concurrenthashmap
https://www.geeksforgeeks.org/concurrenthashmap-in-java/
https://bcho.tistory.com/1072
https://en.wikipedia.org/wiki/Hash_table
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html
CAS
https://d2.naver.com/helloworld/831311
https://velog.io/@sojukang/Random-대신-ThreadLocalRandom을-써야-하는-이유

Redis에서 Atomic Operation을 위해 Luascirpt와 Multi Exec 중 뭘 써야할까?

Multi와 exec를 사용하면​

Multi와 exec는 레디스에서 트랜잭션을 사용하겠다는 명령어인데 일반적인 RDB와 다르게 롤백기능이없다. (롤백기능이 없는 이유는 단순성과 성능에 상당한 영향을 미치기 때문에 RDB와 다르게 없다고한다.)
그러면 레디스는 어떻게 트랜잭션을 바라볼까? Multi로 선언하면 multi안에 명령어들이 묶여 순서대로 같이 큐에 담기게된다. 그리고 EXEC를 만나는 순간 큐에 담긴 명령어들이 순서대로 한 오퍼레이션에 묶여 실행이되고
만약 큐에 쌓인 명령어가 중간에 실패하는 일이 생기면 실패한 부분만 skip하고 다음부분이 연속적으로 실행되게된다.

> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1

위와 같이, exec의 명령을 한 순서대로 array형태로 응답값을 준다.

watch와 같이 사용하면​

우리가 사용하는 RDB의 optimistic lock과 같은데, 만약 짧은시간에 여러 클라이언트가 동시에 접근 할시 흔히 동시성 문제가 생기는데 watch 를 사용하면 해결이 된다.

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

myKey라는 key에 watch를 주고(키를 감시) 작업 후에, exec(수신 전) 전 다른 클라이언트에서 먼저 val값을 수정을했으면 트랜잭션은 자동으로 실패하게 된다.
이 때는 클라이언트의 수정뿐만 아니라 ttl에 의한 키만료 제거 등과같이 Redis에 자체에 의한 수정도 포함이된다.

💡 Discard Discard는 큐에 담겨있는 것들을 버린다.

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

Luascript란​

루아스크립트는 Redis에 내장된 실행 엔진에 의해 실행되는데. 현재 레디스는 단일 스크립트 엔진인 lua 5.1 인터피리터를 지원한다. 또 스크립트는 서버에서 실행되므로 이는 자연스럽게 네트워킹 리소스를 절약하게 되어 스크립트에서 데이터를 읽고 쓰는 건 매우 효율적이게 작동한다. 또 레디스에서 루아 스크립트를 사용하면 atomic을 함을 보장해준다. 또 루아스크립트를 사용하면 조건적인 update를 여러 키에 컬쳐 지원해주고, 개별의 각기다른 데이터 타입을 원자적으로 결합이가능해진다.

그냥 단순한 사용을 해본다면

>EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 foo bar
OK
> GET foo
bar

조금 더 사용을 해본다면

> EVAL "redis.call('sadd','myset1', 'user1')
redis.call('sadd','myset2', 'user2')
local members = redis.call('keys','myset*') 
local results = {} 
for index,key in ipairs(members) 
do results[index] = redis.call('smembers',key) 
end return results" 

차이점​

multi/exec 는 트랜잭션 응답을 array 형태로 받아서 여러 명령어를 통해 예를들어 작업은 불가능하지만 Luasript는 script를 이용해 가능하다.
예를 들어 lpop으로 담긴 userlist 큐에 순서대로 꺼내서 그 키값으로 user의 점수를 올린다고한다면 luascript를 사용하면 편하다.

> lpush userList user1 user2 user3
> EVAL "
local user = redis.call('LPOP', 'userList')
local result = redis.call('INCRBY', user, 1);

return result " 

뭘 사용해야할까​

multi를 사용하던 luascript 를 사용하던 둘다 atomic하게 한 오퍼레이션에 명령들을 한 번에 같이 보낼 수 있지만 특정 상황에서는 multi/exec로는 구현이 힘들 때가있으니 이때 luascript 사용이 대안이 될 수 있다.

참고

https://redis.io/docs/manual/programmability/eval-intro/
https://stackoverflow.com/questions/62970603/lua-scripts-vs-multi-exec-in-redis
redisTransaction
https://redis.io/commands/eval/
https://scalegrid.io/blog/redis-transactions-long-running-lua-scripts/
https://engineering.linecorp.com/ko/blog/atomic-cache-stampede-redis-lua-script/
lua script limits to solve the problem of inaccurate high concurrency counts

모든 소스는 이곳에 있습니다:)

테스트 전략​

만드는 비용이 적고, 유지보수하기 쉽고, 빨리 실행되고, 안정적인 작은 크기의 테스트들에 대해 높은 커버리지를 유지해야 한다는 것이다. 가장 확실한 건 하나의 클래스가 제대로 동작하는지 확인할 수 있는 단위테스트이다.

테스트피라미드 https://martinfowler.com/bliki/TestPyramid.html
위로 올라 갈 수록 비용이 비싸진다.

테스트를 작성 할 때 지금하려는 목적이 뭔지 생각해야한다.​

테스트는 서비스가 모킹된 대상의 특정 메서드와 상호작용했는지 여부를 검사 할 수 있는데 만약 모든 것을 검증하려다 보면 클래스가 조금이라도 변경되면 테스트가 쉽게 변경이된다. 이는 테스트의 본질을 떨어뜨리는 행위기 때문에 불필요한 부분은 테스트를 하지 않고 중요한 핵심 비지니스만 검증을 하는 것이 더 낫다.

얼마만큼의 테스트면 충분할까?​

라인 커버리지는 중요하지 않다. 80% 로든 심지어 100%로든 버그가 없다고 할 수 없다. 사람마다 다르겠지만 그냥 내가 마음이 불안하지않고 편하다면 충분하다고 생각이든다. 테스트를 실행 후에 마음이 편안한 상태로 배포를 할 수 있으면 충분하다고 본다. 육각형 아키텍처에서의 테스트 전략은

1. 도메인 엔티티를 구현할 때에는 단위 테스트로 커버

2. 유스케이스를 구현 할 때는 단위 테스트로 커버

3. 어댑터를 구현할 때는 통합 테스트로 커버

4. 사용자가 취할 수 있는 중요 애플리케이션 경로는 시스템 테스트로 커버

   
   

시스템 테스트와 통합테스트 의 목적은 다르다.

아키텍처 경계 강제하기​

https://reflectoring.io/book/

애플리케이션 계층은 애플리케이션 서비스안에 유스케이스를 구현하기 위해 도메인 엔티티에 접근한다.
어댑터는 인커밍 포트를통해 서비스에 접근하고, 반대로 서비스는 아웃고잉 포트를 통해 어댑터에 접근한다.
마지막으로 설정 계층은 어댑터와 서비스 객체를 생성할 팩터리를 포함하고 있고, 의존성 주십 메커니즘을 제공한다.
의존성 규칙에 따르면 계층 경계를 넘는 의존성은 항상 안쪽방향으로 향해야 한다.

경계표시를 위해서 자바에서 많이 쓰는 방법이 접근제한자를 쓰는 것이다. package-private(default), protectect, private 를 사용한다.

깨진창문이론​

• 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다.
• 테스트코드가 없는 코드는 테스트코드를 추가하지 않기 쉽다.
• 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기 쉽다.
• 코딩 큐칙을 많이 어긴 코드에서 작업할 때 또 다른 큐칙을 어기기도 쉽다.
• 깃 브랜치를 어지럽게 하면 점점 더 어지러워진다.

의식적으로 지름길을 사용하기​

지름길이 꼭 나쁜건 아니다. 때로는 시간적, 경제적등 다양한이유로 사용 할 수 있다. 이때에는 의도적으로 지름길을 사용했다는 사실을 문서로 남기고 팀에 공유하자 그러면 깨진 창문 이론의 영향을 더 줄일 수 있을 것이다.

• 인커밍 포트 건너뛰기
  • 컨트롤러에서 서비스 바로 접근하기
• 애플리케이션 서비스 건너뛰기
  • 컨트롤러에서 레포지토리 바로 접근하기
• 도메인 엔티티를 입출력 모델로 사용하기
• 유스케이스간 같은 모델 공유하기
  • 다른 유스케이스인데 같은 모델을 공유

도메인이 왕이다​

애플리케이션을 개발 할 때 도메인이 정말 중요하다면, 육각형 아키텍처를 사용 할 수 있다. 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치다. 육각형 아키텍처는 당연한 말이겠지만 DDD의 조력자이다.

경험이 여왕이다.​

인간은 습관의 동물이기 때문에 편안한 길로 가려고한다. 물론 이게 나쁜 결정이 아니지만 다른 경험도 해보면 더 좋은 길을 찾을 수 있기 때문에, 작은 모듈부터 시작을 해서 경험을 해나가는 연습을 가지자. 내가 생각 했을 때는 중요한 것은 정답은 없다 그때그때 다르다 도메인마다 다르고 어떤 소프트웨어를 만드냐에 다르고 팀의 경험에 따라 다르다 그리고 내 마음에 드느냐에 따라서도 다르니 정답이 없다.

참고

만들면서 배우는 클린 아키텍처
로버트마르틴형의원문 → 한글번역
마틴형의테스트피라미드

모든 소스는 이곳에 있습니다:)

계층형 아키텍처의 문제점​

1. 서비스에서 영속성에 강한 결합이 생긴다​

일반적인 프로젝트 구조상 서비스는 영속성 모델을 비지니스 모델처럼 사용하게 되고 이로 인해 도메인 로직뿐만 아니라 여러 영속성 계층과 관련된 작업들을(트랜잭션, 즉시로딩, 지연로딩, 캐시 플러시)등등을 해야한다.

2. 지름길을 택하기 쉬워진다​

여러명이 개발하고 시간이 지나다보면 유틸리티, 헬퍼 등 여러 컴포넌트들이 영속성에 추가하여 개발을 하기쉽고 편하기 때문에 결국 영속성 레이어가 비대해지는 현상이 일어나게된다.

3. 서비스 계층을 스킵 할 수가 있다​

간단한 디비 저장일뿐인 단순한 API일 경우 중간에 있는 서비스를 건너뛰고 바로 컨트롤러에서 영속성 계층에 접근을 해서 작업을 할 때가 있는데 이렇게 되면 여러 문제들이 발생 할 수 있다.

첫 번째 문제는 요구사항이 변경이되면 Controller 여러 추가적인 책임들이 추가가되기 쉬워지는데(혼자 할 때는 괜찮지만, 여러사람이 협업을하다 보면), 레이어간의 책임이 정말 애매모호해 지게된다.

두 번째 문제는 테스트 코드에서의 복잡도가 올라가게 된다. mock을 만드는 등 추가적인 작업을 해야 할 필요가 있게되는데 이러면 테스트 코드를 이해하는데도 시간이 더 걸리고 그러면 테스트 코드 짜기가 점점 더 힘들어지고 싫어지게된다.

4. 수정이 힘들어진다.​

여러명이 협업을하면서 시간이 흐르다보면 서비스계층의 책임이 점점 많아지게 되는데, 이렇게 진행되다보면 테스트 코드도 짜기가 점점 힘들어지고, 기능을 추가 혹은 수정 해야 할 때 선뜻 사이드 이펙트를 예측하기가 힘들어지게 된다.

육각형 아키텍쳐(헥사고날)​

육각형 아키텍처는 알리스테어 코번이 만든 용어로, 로버트 마틴이 클린 차키텍처에서 조금 더 일반적인 용어로 설명 하였다.

안에는 도메인 엔티티와 이와 상호작용하는 유스케이스가 있다. 육각형 바깥에는 애플리케이션과 상호작용하는 다양한 어댑터들이 있다.

왼쪽에 있는 어댑터들은 애플리케이션을 주도하는 어댑터들이다. 코어와 어댑터들간에 통신을 하려면 각각의 포트들을 제공해야한다. 이 포트들은 인터페이스들이 되는 것이다.

가장 바깥쪽에 있는 계층은 애플리케이션과 다른 시스템 간의 번역을 담당하는 어댑터로 구성되어 있다.

Case마다 다른 출력 모델​

항상 나는 이 질문에 고민을 많이 했다. 호출자에게 정보를 어디까지 줘야할까라는 질문에 사실 정답이 없지만, 여러 컨트롤러에서 같은 서비스에 접근을 해야 할 때 처음에는 같은 모델로 돌려주게 개발을 하고 나중에 시간이 지나 점점 눈덩이처럼 점점 커지는 모델들을 경험을 많이 해서 고민이 많았는데 책에서 하는 말이

웹 어댑터의 책임​

1. HTTP 요청을 자바 객체로 매핑
2. 권한 검사
3. 입력 유효성검증
   • 유스케이스에서의 입력 모델 검증과 어댑터에서의 검증의 차이는 맥락의 차이인데 유스케이스에서의 입력 모델에서 유효한 입력만 허용해야한다. 내 생각에는 출금과 관련된 유스케이스에서 유스케이스에서 검증 할 때 있을 때 ‘잔금은 돈은 0원 보다 더 커야 한다’ 의 차이 이지 않을까라고 생각든다.
4. 입력을 유스케이스의 입력 모델로 매핑
5. 유스케이스 호출
6. 유스케이스의 출력을 HTTP로 매핑
7. HTTP 응답을 반환

Create로 이름을 짖는거는 지양하자​

이미 어딘가에 많이 쓰이고 있는 예약어이기 때문에 Create→Register 로 변경하여 이름을 짖자.
CreteAccountController → RegisterAccountController
Create, Update, Delete … naming으로 역할을 만들기 전에 한 번더 생각을 해보는 게 좋다.

여러 작은 클래스들을 만드는 것을 두려워해서는 안된다.​

여러 작은 클래스들을 만드는 것을 두려워해서는 안된다. 작은 클래스들은 파악하기 쉽고, 테스트하기 쉽고, 여러명이서 작업을 할 수 있게된다. 처음에는 공수가 더 들겠지만 나중에 유지보수 할 때에는 시간이 단축될 것이다.

영속성 어댑터​

영속성 어댑터의 책임​

1. 입력을 받는다.
2. 입력을 데이터베이스 포맷으로 매핑한다.
3. 입력을 데이터베이스로 보낸다
4. 데이터베이스 출력을 애플리케이션 포맷으로 매핑한다.
5. 출력을 반환한다.

참고

만들면서 배우는 클린 아키텍처
로버트마르틴형의원문 → 한글번역

모든 소스는 이곳에서 확인 가능합니다 :)

Spring Boot Kafka Grace full Shutdown

Consumer가 메세지를 처리중에 Spring Boot 어플리케이션에서 shutdown event가 일어 났을 때 과연 잘 Shutdown Graceful하게 종료가 되는지가 궁금해서 해보는 실험.

무엇을 테스트하냐​

Consumer가 컨슘 후 데이터를 잘 commit하는지 Conusmer info 관찰

shutdownTimeout : defualt 30초

Kafka version: 2.7.1

SpringBootVersion: v2.5.6

방법​

1. shutdownTimeout 내 정상적으로 모든 메세지가 잘 처리 되도록
   1. Spring Boot Kafka 메세지를 10개 생성
   2. Consume 할 때 처리 시간이 개당 1초가 걸리도록 실험
   3. 모든 메세지를 소비 할 때까지 최소 10초의 시간이 필요한 작업으로 설정
   4. 컨슈머 커밋이 어떻게 되는지 확인
2. shutdownTimeout을 넘어서도록 설정
   1. Spring Boot Kafka 메세지를 10개 생성
   2. Consume 할 때 처리 시간이 개당 10초가 걸리도록 실험
   3. 모든 메세지를 소비 할 때까지 최소 100초의 시간이 필요한 작업으로 설정
   4. 컨슈머 커밋이 어떻게 되는지 확인

Shutdown Signal은 단순하게 2로 테스트할 예정이다.

linux의 shutdow number 확인

https://linuxhint.com/kill-signal-numbers-linux/

• SIGKILL (9): SIGKILL signal 은 프로세스를 즉각 종료 할 때 사용한다.
• SIGINT(2): 사용자의 요청으로 중단이 될 때 사용한다. (e.g., Ctrl+C).
• SIGTERM(15): SIGTERM signal 종료 요청을 보낸다, 요청을 보낼 뿐 SIGKILL은 아니다.

실험 및 결과​

각종 설정은 default로 설정하고 진행한다.

fetch.max.bytes = 52428800
fetch.max.wait.ms = 500
fetch.min.bytes = 1
auto.commit.interval.ms = 5000

1번​

Consumer test.offset.1의 offset 확인

• current-offset: 36
• Lag: 9

어플리케이션 종료 signal 2: SIGINT

2022-06-08 16:45:18.347 DEBUG 11696 --- [ionShutdownHook] s.c.a.AnnotationConfigApplicationContext : Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@34d046b6, started on Wed Jun 08 16:45:09 KST 2022
2022-06-08 16:45:18.347 DEBUG 11696 --- [ionShutdownHook] ySourcesPropertyResolver$DefaultResolver : Found key 'spring.liveBeansView.mbeanDomain' in PropertySource 'systemProperties' with value of type String
2022-06-08 16:45:18.348 DEBUG 11696 --- [ionShutdownHook] o.s.c.support.DefaultLifecycleProcessor  : Stopping beans in phase 2147483547

Debug로 로그 확인

essageListenerContainer$ListenerConsumer : Commit list: {test-0=OffsetAndMetadata{offset=45, leaderEpoch=null, metadata=''}}
essageListenerContainer$ListenerConsumer : Committing: {test-0=OffsetAndMetadata{offset=45, leaderEpoch=null, metadata=''}}
org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Sending OFFSET_COMMIT request with header RequestHeader(apiKey=OFFSET_COMMIT, apiVersion=7, clientId=consumer-test.offset.1-1, correlationId=17) and timeout 30000 to node 2147483646: {group_id=test.offset.1,generation_id=5,member_id=consumer-test.offset.1-1-0fd44995-c1a6-451a-9987-ab35edab9f74,group_instance_id=null,topics=[{name=test,partitions=[{partition_index=0,committed_offset=45,committed_leader_epoch=-1,committed_metadata=}]}]}
org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Received OFFSET_COMMIT response from node 2147483646 for request with header RequestHeader(apiKey=OFFSET_COMMIT, apiVersion=7, clientId=consumer-test.offset.1-1, correlationId=17): OffsetCommitResponseData(throttleTimeMs=0, topics=[OffsetCommitResponseTopic(name='test', partitions=[OffsetCommitResponsePartition(partitionIndex=0, errorCode=0)])])
o.a.k.c.c.internals.ConsumerCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Committed offset 45 for partition test-0
o.a.k.c.c.internals.ConsumerCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Executing onLeavePrepare with generation Generation{generationId=5, memberId='consumer-test.offset.1-1-0fd44995-c1a6-451a-9987-ab35edab9f74', protocol='range'} and memberId consumer-test.offset.1-1-0fd44995-c1a6-451a-9987-ab35edab9f74
o.a.k.c.c.internals.ConsumerCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Revoke previously assigned partitions test-0
o.s.k.l.KafkaMessageListenerContainer    : test.offset.1: partitions revoked: [test-0]
essageListenerContainer$ListenerConsumer : Commit list: {}
o.a.k.c.c.internals.AbstractCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Member consumer-test.offset.1-1-0fd44995-c1a6-451a-9987-ab35edab9f74 sending LeaveGroup request to coordinator localhost:9092 (id: 2147483646 rack: null) due to the consumer unsubscribed from all topics
org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Sending LEAVE_GROUP request with header RequestHeader(apiKey=LEAVE_GROUP, apiVersion=2, clientId=consumer-test.offset.1-1, correlationId=18) and timeout 30000 to node 2147483646: {group_id=test.offset.1,member_id=consumer-test.offset.1-1-0fd44995-c1a6-451a-9987-ab35edab9f74}
o.a.k.c.c.internals.AbstractCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Resetting generation due to consumer pro-actively leaving the group
o.a.k.clients.consumer.KafkaConsumer     : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Unsubscribed all topics or patterns and assigned partitions
o.s.s.c.ThreadPoolTaskScheduler          : Shutting down ExecutorService
o.a.k.c.c.internals.AbstractCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Heartbeat thread has closed
o.a.k.c.c.internals.ConsumerCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Executing onLeavePrepare with generation Generation{generationId=-1, memberId='', protocol='null'} and memberId
o.a.k.c.c.internals.AbstractCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Resetting generation due to consumer pro-actively leaving the group
org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] Received LEAVE_GROUP response from node 2147483646 for request with header RequestHeader(apiKey=LEAVE_GROUP, apiVersion=2, clientId=consumer-test.offset.1-1, correlationId=18): LeaveGroupResponseData(throttleTimeMs=0, errorCode=0, members=[])
o.a.k.c.c.internals.AbstractCoordinator  : [Consumer clientId=consumer-test.offset.1-1, groupId=test.offset.1] LeaveGroup response with Generation{generationId=5, memberId='consumer-test.offset.1-1-0fd44995-c1a6-451a-9987-ab35edab9f74', protocol='range'} returned successfully: ClientResponse(receivedTimeMs=1655698563052, latencyMs=12, disconnected=false, requestHeader=RequestHeader(apiKey=LEAVE_GROUP, apiVersion=2, clientId=consumer-test.offset.1-1, correlationId=18), responseBody=LeaveGroupResponseData(throttleTimeMs=0, errorCode=0, members=[]))

흥미로운 로그가 몇 개 보인다.

1. OFFSET_COMMIT
2. Revoke Listener가 작동을 하고
3. LeaveGroup Request
4. Thread Shutodnw Event가 시작을 하고
5. HeaerBeat thread가 종료 되고
6. LeaveGroup을 받는다.

topic의 offset 확인

• current-offset:45
• lag: 0

2번​

Consumer test.offset.1의 offset 확인

• current-offset: 36
• Lag: 9

어플리케이션 종료 signal 2: SIGINT

2022-06-08 16:45:18.347 DEBUG 11696 --- [ionShutdownHook] s.c.a.AnnotationConfigApplicationContext : Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@34d046b6, started on Wed Jun 08 16:45:09 KST 2022
2022-06-08 16:45:18.347 DEBUG 11696 --- [ionShutdownHook] ySourcesPropertyResolver$DefaultResolver : Found key 'spring.liveBeansView.mbeanDomain' in PropertySource 'systemProperties' with value of type String
2022-06-08 16:45:18.348 DEBUG 11696 --- [ionShutdownHook] o.s.c.support.DefaultLifecycleProcessor  : Stopping beans in phase 2147483547

Shout down TimeOut 이후 로그를 본다면

2022-06-03 18:16:35.861  INFO 9116 --- [ionShutdownHook] o.s.c.support.DefaultLifecycleProcessor  :
 **Failed to shut down 1 bean with phase value 2147483547 within timeout of 30000ms:** 
[org.springframework.kafka.config.internalKafkaListenerEndpointRegistry]

Offset 확인

shutdown timeout으로 인해 Commit이 정상적으로 안된 상태이다.

결론​

Timeout 이내에 메시지는 잘 Graceful하게 처리한다. 그러나 만약 timeout 내에 처리를 못 한다면 메시지를 중복으로 처리하는 상황이 나타날 수 있으니, 적절한 방어 로직과 수동 commit으로 풀어서 처리를하거나 timeout을 알맞게 설정해야 할 거 같다.

참고

https://docs.spring.io/spring-kafka/docs/2.5.17.RELEASE/reference/html/
https://bravenamme.github.io/2020/10/06/graceful-shutdown/
https://docs.confluent.io/confluent-cli/current/overview.html
https://kafka.apache.org/documentation/
signum 번호 설명 zoe kafka cli
consume Config 설명

모든 소스는 이곳에서 확인 가능합니다 :)

N + 1 문제​

JPA를 쓰면서 우리가 일반적으로 발생하여서 해볼 건 다 해봐도 안됐었던 N+1 문제
일반적으로 우리가 흔히 N+1문제가 발생을 할 수 있는데 이미 많은 사람이 알겠지만 킹갓영환님의 책을 보거나 강의를 보면 진짜 다 해결이 가능했는데
내가 마주한 문제는 해결이 안 됐었다. 일반적으로 해결을 위해 그에 상황마다 다르겠지만 흔하게 가장 먼저 lazy로 변경, fetch join, fetch size조정 등 여러 작업을 했는데
해결이 안 됐었다.

코드가 많이 다르고 도메인도 다르지만 그나마 비슷하게 코드를 재현 해보자면

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Member  {
    @Id
  @Column(name = "member_id")
  private Long id;
    
    private String memberEmail;

    @OneToMany(mappedBy = "Member", cascacde = CascadeType.ALL, orphanRemoval = true)
    private Set<Order>  orders = LinkedHashSet<>();

    ...
}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Order  {
    @ID
    @Column(name = "order_id")
    priate Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "memberEmail", referencedColumnName = "memberEmail", nullable = false, updatable = false)
    private Set<Order>  order = LinkedHashSet<>();

    ...
}

이런 느낌의 Entity였다.
이때의 나 빼고 엔티티가 어떤 문제가 있는지 알겠지만 이때까지는 나는 꿈에도 몰랐다. 5시간을 버릴 줄은 몰랐다!

기획: 회원으로 주문 정보를 볼 수 있게 해주세요
나: members 기준으로 Order를 다 가져오면 되겠구나! 음 그러면 가져올 때 속도를 위해 fetch join 해서 가져와야지!

그렇게 다섯시간을 잡아먹을 줄은 몰랐었다.
아니 진짜 핑계를 대자면 이렇게 엔티티를 구성한 건 내가 아니라 기존 코드를 가지고 다른 곳에서 쓰다가 이렇고 저렇고.. 구구절절 할말하안

내가 그린 그린 쿼리​

select a.*, b.*
from member m 
inner join order o on m.memberEmail = o.memberEmail;

이런 느낌의 (너도 한방 나도한방)쿼리를 원해서

Fetch를 쓰자​

public interface ProblemRepository extends JpaRepository<Member, Long> {
        private final JPAQueryFactory queryFactory;

        @Query("SELECT distinct m FROM Member m join fetch m.orders")
    List<Member> findAllFetch();
}

이렇게 조회를 했는데

@Test
void save() {
       // Given

    for (int i = 0; i < 2; i++) {
        Member memFixture = new Member( i + "@naver.com");
        Order orderFixture = new Order(i + "delivery");
        memFixture.addOrder(orderFixture);
        problemRepository.save(memFixture);
        em.flush();
        em.clear();
    }

    List<Member> members = problemRepository.findAllFetch();

    assertThat(members.size()).isEqualTo(2);
    assertThat(members.get(0).getOrders().size()).isEqualTo(1);
    assertThat(members.get(1).getOrders().size()).isEqualTo(1);
}

편의를 위해서 대충 이렇게 했다 가정하고.. 테스트를 돌려서 확인해보니

Hibernate: 

select
  distinct member0_.member_id as member_i1_0_0_,
  orders1_.order_id as order_id1_1_1_,
  member0_.member_email as member_e2_0_0_,
  orders1_.member_email as member_e3_1_1_,
  orders1_.order_status as order_st2_1_1_,
  orders1_.member_email as member_e3_1_0__,
  orders1_.order_id as order_id1_1_0__ 
from
  t_member member0_ 
inner join
  t_order orders1_ 
      on member0_.member_email=orders1_.member_email

음 .. 예상한 쿼리네

Hibernate: 
    /* load com.example.tiljpa.problem.Member */ select
        member0_.member_id as member_i1_0_0_,
        member0_.member_email as member_e2_0_0_ 
    from
        t_member member0_ 
    where
        member0_.member_email=?
Hibernate: 
    /* load com.example.tiljpa.problem.Member */ select
        member0_.member_id as member_i1_0_0_,
        member0_.member_email as member_e2_0_0_ 
    from
        t_member member0_ 
    where
        member0_.member_email=?

?????? 이런 쿼리들이 조회한 멤버 수만큼 다시 쿼리가 쫘라라라라라라라라라라라라라락 나가버렸다..

이때 엥..? 왜 fetch join을 하고 쿼리를 가져왔는데 다시 member쿼리가 나가지??

이떄부터 멘붕의 시작이였다.

디버깅하면서의 추측​

1. 일단 fetch mode를 eager로 바꿔보자..
   • 실패
2. querydsl로 join을 하면 다를까?
   • 실패
3. equals랑 hashcode를 넣어보자
   • 실패
4. 아 이건아닌거같은데 yml에 batch size를 넣어보자
   • 당연히 실패
5. transacton(readonly=true) 때문에 영속성 컨텍스트가 일을 안하나? 좋아 transaction으로만 하자
   • 실패
6. 아 좋아 일단 디버깅을 해보자

   - 디버깅 하면서 보다보니 최초 fetch로 받은 member 객체의 주소와 order가 가지고 있는 member객체의 주소가 확연히 달랐다.  
   ![Untitled](./2022-05-28/Untitled%202.png)          
   
   어 뭐야 왜달라... 이떄부터 무한 챗바퀴 돌듯 그러면 order의 mode를 eager로 바꾸자! (사실 이미 해봤던거였다) 당연히 실패
   

도저히 좋은 생각이 떠오르지 않아 산책을하고 온 후

문득​

문득 우리가 join을 하면 rdb에서 당연히 여러 개 나오는 문제를 우리는 흔히 distnct를 하는데 이때 jpa에서는 Entity의 @Id로 중복을 제거하는 게 생각이 지나가는데 아 그러면 fetchjoin한 이후 가져왔었을 때 영속성 컨테스트에서 **@Id** 로 구분을 한다고 생각이 들어 기존 JoinColumn에 member_email로 되어있는 코드를 member_id로 변경했다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Order  {
    @ID
    @Column(name = "order_id")
    priate Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "member_id", referencedColumnName = "member_id", nullable = false, updatable = false)
    private Set<Member> members = LinkedHashSet<>();

    ...
}

눈 수술 후 건조한 눈 때문에 눈을 개스츠름한 눈빛으로 모니터를 뚫어지게 보며 생각 중에 스쳐 가는 생각이 있었는데, Hibernate 입장에서 생각(뇌 코딩)을 해본다면 당연 할 수 밖에 없구나라는 생각이 들었다.
쿼리를 jqpl로 날려 보내고 온 후에 영속성 컨텍스트에 친구를 memberId를 기준으로 컨텍스트 테이블에 값을 넣어놓고, order를 보는데 안에 Lazy가 떡하니 선언되어 있는 걸 보고 허겁지겁 다시 찾으려고 컨텍스트에서 찾았는데 안보였던 것이다.
그래서 1차 캐시에 없네(Joincolumn에 선언된 member_email을 가지고 key를 찾다 보니 실제로는 fetchjoin으로 넣었던 key는 memberId이였어서) 그러면 db에서 조회해야겠다고 판단하고 다시 lazy조인을 날려 발생한 문제인 거지 않을까?

참고

Inflearn 영환님 강의
JPA 프로그래밍 docs

Transaction Isolation Level

ACID​

ACID는 데이터베이스 내에서 일어나는 하나의 트랜잭션(transaction)의 안전성을 보장하기 위해 필요하다.

• Atomicity: transaction의 작업이 부분적으로 성공하는 일이 없도록 보장하는 성질이다. 송금하는 사람의 계좌에서 돈은 빠져나갔는데 받는 사람의 계좌에 돈이 들어오지 않는 일은 없어야 한다.
• Consistency: transaction이 끝날 때 DB의 여러 제약 조건에 맞는 상태를 보장하는 성질이다. 송금하는 사람의 계좌 잔고가 0보다 작아지면 안 된다.
• Isolation: transaction이 진행되는 중간 상태의 데이터를 다른 transaction이 볼 수 없도록 보장하는 성질이다. 송금하는 사람의 계좌에서 돈은 빠져나갔는데 받는 사람의 계좌에 돈이 아직 들어가지 않은 DB 상황을 다른 transaction이 읽으면 안 된다.
• Durability: transaction이 성공했을 경우 해당 결과가 영구적으로 적용됨을 보장하는 성질이다. 한 번 송금이 성공하면 은행 시스템에 장애가 발생하더라도 송금이 성공한 상태로 복구할 수 있어야 한다.

Read Uncommitted (Dirty Read)​

• 일반적으로 거의 사용하지 않는다.
• 변경 내용이 commit이나 Rollback 여부에 상관 없이 다른 트랜잭션에게 보여준다.
• 어떤 트랙잭션에서 처리한 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있게 된다.
• Dirty read를 유발한다.

Read Committed​

• Oracle Dbms에서 기본적으로 사용되고 있는 격리 수준(Shared Lock을 사용한다)
  • Shared Lock
    • 일반적인 SELECT 쿼리는 lock을 사용하지 않고 DB를 읽어 들인다. 하지만 SELECT ... FOR SHARE 등 일부 SELECT 쿼리는 read 작업을 수행할 때 DB가 각 row에 Shared lock을 건다.
• Commit이 완료된 데이터만 다른 트랜잭션에서 조회 할 수 있다.
• 어떤 트랜잭션에서 처리한 작업이 Commit이 안되어 있다면 다른 트랜잭션은 undo 영역에 있는 기존 값을 참조해서 보여준다.
• Non-repetable read라는 부정합 문제 발생 할 수 있다.

동일 Transaction1 내에서 Select문의 결과값을 받고 작업 도중 만약 다른 Transaciton2에서 insert 또는 update를 했다고 가정 했을 때 Transaction1에서 같은 select에 다른 결과값이 보일 수 있는 문제이다.

글로 설명하면 조금 햇갈리는데 그림으로 보면 쉽다..

https://akasai.space/db/about_isolation/

Repeatable Read​

• Mysql InnoDB에서 기본적으로 사용되는 격리 수준(Shared Lock을 사용한다)
• Non-repetable read라는 부정합 문제가 발생하지 않는다.
• Undo 공간에 백업해두고 실제 레코드 값을 변경한다.
• 언두 영역에 백업된 레코드의 여러 버전 가운데 몇 번째 이전 버전까지 찾아 들어가야 하는지에 있다. Undo 영역에서 특정 트랜잭션 번호의 구간 내에서 백업된 데이터를 보여준다. 하지만 트랜잭션을 종료하지 않으면 무한정으로 언두 영역이 커질 수 있어서 성능 하락이 될 수 있음.

https://www.cyber.pe.kr/2016/11/mysql-innodb-type.html

1. 시스템 테이블 영역
   • DB의 시스템이 생성한 영역이다. 사용자가 생성한 데이터베이스와 테이블, 테이블에 대한 메타 정보 등을 정리하여 관리한다.
2. 트랜잭션 영역
   • DB가 쿼리를 처리하는 과정에서 시스템 상의 오류가 발생할 경우 원상태로 복구하기 위해 쿼리 처리 이전의 데이터를 보관하는 영역이다.
3. 데이터 영역
   • 실제 데이터가 저장되는 영역으로, DB 사용자가 저장한 모든 데이터는 이 영역에 저장된다. 이 영역에서는 DB의 성능을 유지하기 위해 데이터 삭제 시, 완전 삭제 대신 데이터가 삭제된 것으로 표시만 하고 삭제 영역에 데이터를 그대로 유지한다. 이 같은 특징 때문에 삭제된 데이터의 복구가 가능하다.

Serializable​

• 동시성이 중요한 DB에서는 거의 사용하지 않는다.
• 읽기 작업도 공유 잠금을 획득 해야 하며 동시에 다른 트랜잭션은 그러한 레코드를 변경하지 못한다.
• 한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 접근 불가하다

참고

https://suhwan.dev/2019/06/09/transaction-isolation-level-and-lock/ - gap lock, record lock 등 격리 레벨별 설명이 자세하다.
https://www.cyber.pe.kr/2016/11/mysql-innodb-type.html
RealMysql

모든 소스는 이곳에서 확인 가능합니다 :)

스프링 부트에서 Kafka Rebalancing 처리 해보기​

Kafka를 통해 메시지를 받는 애플리케이션을 구성할 때 프로덕션 환경에서는 고려해야 할 여러 상황이 있는데 지금 생각나는 대표적으로 메시지유실, 중복 메시지 Consume, 확장 가능한 key 정하기, 카프카 리밸런싱 등 카프카를 사용하는데 많은 힘듦이 많이 있는데, 카프카 리밸런싱 상황에서 우리의 애플리케이션이 당황하지 않고 처리를 잘 할 수 있는 방법을 소개해 보려고 한다.

카프카 리밸런싱이란?​

먼저 리밸런싱이 뭔지 잠깐 알아보고 간다면, Kafka 토픽을 구성할 때 한 토픽을 여러 개의 Partitions들로 구성하는 일이 많은데, 자연스럽게 Consumer(같은 Group.Id)도 여러 개로 구성이 된다. 이때 메시지를 Consume 하는 상황에서 Consumer가 여러 가지 상황으로 인하여 Broker와 연결이 끊어졌을 때, 일어나는 것이 리밸런싱인데 문제없이 메시지를 소비하게 위해서 브로커가 장애가 일어났다고 판단하고 기존 Consumer에 할당되어 있는 파티션을 다른 Consumer에 재 할당하는 것이다.

그렇다면 꼭 리밸런싱 처리를 해야할까?​

이건 애플리케이션에서 카프카를 사용하는 이유에 따라 다른데, 만약 토픽을 컨슘 할 때 특정 key를 기준으로 컨슘을 하고 있다고 예를 들어 배달 주문에 대해서 카프카를 사용한다고 하였을 때 토픽의 Key를 한식(0 번), 중식(1 번), 양식(2 번), 일식(3 번) 으로 (그럴 리는 없겠지만) 할 경우, 만약 일식을 컨슘하는 애플리케이션이 어떠한 장애로 컨슘을 못한다고 하였을 때, 일식(3 번)의 파티션이 한식(0 번) 파티션으로 할당되었을 때 (런타임에) 처리가 따로 필요할 수가 있다. 한식만 가지고 있는 메뉴 정보를 일식을 포함한 메뉴 정보로 다시 불러온다든지, 아니면 따로 알람 처리를 한다든지 내부 메모리에 가지고 있는 정보들을 초기화 작업이 필요하는 등 여러 가지 처리할 수 있기 때문에 리밸런싱 처리는 카프카를 사용하는 이유에 따라 달라 처리 할 수도 안 해도 된다.

코드로​

코드로 처리하는 부분은 의외로 간단한데 일단 Spring Docs에서 확인을 해본다면
Kafka의 ConsumerRebalanceListener 를 구현한 ConsumerAwareRebalanceListener 를 사용하면 된다.

public interface ConsumerAwareRebalanceListener extends ConsumerRebalanceListener {
 ...

default void onPartitionsRevokedBeforeCommit(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
        try {
            onPartitionsRevoked(partitions);
        }
        catch (Exception e) { // NOSONAR
            LOGGER.debug(e, "User method threw exception");
        }
    }

    default void onPartitionsRevokedAfterCommit(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
    }

    default void onPartitionsLost(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
        try {
            onPartitionsLost(partitions);
        }
        catch (Exception e) { // NOSONAR
            LOGGER.debug(e, "User method threw exception");
        }
    }

    default void onPartitionsAssigned(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
        try {
            onPartitionsAssigned(partitions);
        }
        catch (Exception e) { // NOSONAR
            LOGGER.debug(e, "User method threw exception");
        }
    }

    @Override
    default void onPartitionsRevoked(Collection<TopicPartition> partitions) {
    }

    @Override
    default void onPartitionsAssigned(Collection<TopicPartition> partitions) {
    }

    @Override
    default void onPartitionsLost(Collection<TopicPartition> partitions) {
    }

onPartitionsAssigned 은 파티션 재할당이 성공적으로 완료될 때 호출된다.
onPartitionsRevoked 은 할당되어 있던 파티션이 제거 될 때 호출된다.
onPartitionsLost 은 일반적인 상황에서는 실행이 안되나 만약 컨슈머의 세션 제한 시간이 만료되었거나 컨슈머가 더 이상 그룹에 속하지 않음을 나타내는 치명적인 오류가 수신된 경우 호출된다.

@Component
public class MyListener implements ConsumerAwareRebalanceListener {

  @Override
  public void onPartitionsAssigned(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
      ConsumerAwareRebalanceListener.super.onPartitionsAssigned(consumer, partitions);
      System.out.println("onPartitionsAssigned");
      partitions.forEach(topicPartition -> System.out.println(topicPartition.partition()));
  }

  @Override
  public void onPartitionsLost(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
      ConsumerAwareRebalanceListener.super.onPartitionsLost(consumer, partitions);
      System.out.println("onPartitionsLost");
  }

  @Override
  public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
      ConsumerAwareRebalanceListener.super.onPartitionsRevoked(partitions);
      System.out.println("onPartitionsRevoked");
  }
}

consumer 에는 Consumer에 여러 정보들을 볼 수 있다.
partitions 파라미터로 현재 할당 된 목록을 인자로 준다.

느낀점​

진짜 카프카 너무 어렵다. 특히 카프카에 의존성이 높으면 높을수록 난도가 올라가는 거 같다. 생각 해 볼 부분들이 많은데, 카프카의 메시지를 produce할 때 유실이 나면 안 되는 서비스인데 어떻게 빠르면서 메시지가 유실되지 않을까를 고려 한다든지, 토픽의 key를 어떤 key로 설정하냐에 확정성이 있고 메시지가 잘 분배 될 때라던지, 리파티니셔닝 상황에서의 서비스가 문제가 없을까 메세지를 중복으로 읽을 경우는 없을 거라든지, 중복으로 메시지를 컨슘 할 경우도 있는데 이때는 어떻게 처리 해야 할까 등등 정말 카프카 어렵다. 그런데 막상 이런 걸 하나하나 해결 해서 서비스가 장애 없고 우아하게 잘 돌아가는 걸 할 수 있다면 얼마나 맛이 있을까? 그런 상상을 하면서 야-근을 한다.

참고

https://developer.confluent.io/learn-kafka/apache-kafka/partitions/
https://www.popit.kr/kafka-consumer-group/
group id와 consume id 차이
스프링 Kafka Docs
ConsumerRebalanceListener설명

모든 소스는 이곳에서 확인 가능합니다:)

Spring Gateway Route​

Spring gateway을 사용할 때 일반적으로 2가지 방식으로 route 설정을 할 수 있다.

Yaml​

spring: 
    cloud:
    gateway:
      globalcors:
        corsConfigurations:
          '[/**]':
            allowedOrigins: '*'
            allowedMethods:
              - POST
              - GET
              - PUT
              - OPTIONS
              - DELETE
      routes:
        - id: a-service
          uri: http://localhost:18081
          predicates:
            - Path=/aservice/**
        - id: b-service
          uri: http://localhost:18082
          predicates:
            - Path=/bservice/**

2022-02-19 18:07:46.827 DEBUG 33218 --- [  restartedMain] o.s.c.gateway.config.GatewayProperties   : Routes supplied from Gateway Properties: [RouteDefinition{id='a-service', predicates=[PredicateDefinition{name='Path', args={_genkey_0=/aservice/**}}], filters=[], uri=http://localhost:18081, order=0, metadata={}}, RouteDefinition{id='b-service', predicates=[PredicateDefinition{name='Path', args={_genkey_0=/bservice/**}}], filters=[], uri=http://localhost:18082, order=0, metadata={}}]

Java​

import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RouteConfig {

    @Bean
    public RouteLocator bRoue(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("q-service", r -> r.path("/q-service/**")
                .uri("http://localhost:18081"))
            .route("q-service", r -> r.path("/w-service/**")
                .uri("http://localhost:18080"))
            .build();
    }

    @Bean
    public RouteLocator cRoute(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("c-service", r -> r.path("/c-service/**")
                .uri("http://localhost:18081"))
            .route("d-service", r -> r.path("/d-service/**")
                .uri("http://localhost:18080"))
            .build();
    }
}

라우트들을 나눠서 설정할 수 있다. 그렇다면 따로 설정한 라우터들이 어떻게 같이 합쳐져서 작동하는 것 일까?

Route 구성도

https://zhuanlan.zhihu.com/p/359523303

일단 먼저 봐야할 것은 RouteDefinationLocator이다.

RouteDefinationLocator​

public interface RouteDefinitionLocator {
    Flux<RouteDefinition> getRouteDefinitions();
}

RouteDefinationLocator을 구현한 객체들은 5개가 있다.

1. CachingRouteDefinitionLocator
2. CompositeRouteDefinitionLocator
3. DiscoveryClientRouteDefinitionLocator
4. PropertiesRouteDefinitionLocator
5. RouteDefinitionRepository

DiscoveryClientRouteDefinitionLocator​

Service Discovery(Netflix Eureka, Consul, or Zookeeper)와 연동하여 등록된 서비스들을 기준으로 경로를 만든다.

PropertiesRouteDefinitionLocator​

Yaml에 설정한 property value들이 GateWayProperty 직렬화되어 값이 들어가고

public class PropertiesRouteDefinitionLocator implements RouteDefinitionLocator {

    private final GatewayProperties properties;

    public PropertiesRouteDefinitionLocator(GatewayProperties properties) {
        this.properties = properties;
    }

    @Override
    public Flux<RouteDefinition> getRouteDefinitions() {
        return Flux.fromIterable(this.properties.getRoutes());
    }

}

GatewayProperty 값은 PropertiesRouteDefinitionLocator 에 쓰이게 된다.

CompositeRouteDefinitionLocator​

자바 DSL(편리하게 fluent API를 지원)로 설정한 라우터들의 값이 들어가 있고

CompositeRouteDefinitionLocator에서 PropertiesRouteDefinitionLocator에서 설정한 라우터들에 id가 없을 경우 randid가 들어가게 된다.

public class CompositeRouteDefinitionLocator implements RouteDefinitionLocator {
...
    @Override
    public Flux<RouteDefinition> getRouteDefinitions() {
        return this.delegates.flatMapSequential(RouteDefinitionLocator::getRouteDefinitions)
                .flatMap(routeDefinition -> {
                    if (routeDefinition.getId() == null) {
                        return randomId().map(id -> {
                            routeDefinition.setId(id);
                            if (log.isDebugEnabled()) {
                                log.debug("Id set on route definition: " + routeDefinition);
                            }
                            return routeDefinition;
                        });
                    }
                    return Mono.just(routeDefinition);
                });
    }
}

RouteDefinitionRouteLocator​

Route들을 key를 기준으로 확인 후에 RoutePredicateFactory에 집어넣는다.

public class RouteDefinitionRouteLocator implements RouteLocator {
    
    ...

    public RouteDefinitionRouteLocator(RouteDefinitionLocator routeDefinitionLocator,
            List<RoutePredicateFactory> predicates, List<GatewayFilterFactory> gatewayFilterFactories,
            GatewayProperties gatewayProperties, ConfigurationService configurationService) {
        this.routeDefinitionLocator = routeDefinitionLocator;
        this.configurationService = configurationService;
        initFactories(predicates);
        gatewayFilterFactories.forEach(factory -> this.gatewayFilterFactories.put(factory.name(), factory));
        this.gatewayProperties = gatewayProperties;
    }

    // RoutePredicateFactory 검사
    private void initFactories(List<RoutePredicateFactory> predicates) {
        predicates.forEach(factory -> {
            String key = factory.name();
            if (this.predicates.containsKey(key)) {
                this.logger.warn("A RoutePredicateFactory named " + key + " already exists, class: "
                        + this.predicates.get(key) + ". It will be overwritten.");
            }
            this.predicates.put(key, factory);
            if (logger.isInfoEnabled()) {
                logger.info("Loaded RoutePredicateFactory [" + key + "]");
            }
        });
    }

    public Flux<Route> getRoutes() {
        Flux<Route> routes = this.routeDefinitionLocator.getRouteDefinitions().map(this::convertToRoute);

        if (!gatewayProperties.isFailOnRouteDefinitionError()) {
            // instead of letting error bubble up, continue
            routes = routes.onErrorContinue((error, obj) -> {
                if (logger.isWarnEnabled()) {
                    logger.warn("RouteDefinition id " + ((RouteDefinition) obj).getId()
                            + " will be ignored. Definition has invalid configs, " + error.getMessage());
                }
            });
        }

        return routes.map(route -> {
            if (logger.isDebugEnabled()) {
                logger.debug("RouteDefinition matched: " + route.getId());
            }
            return route;
        });
    }
  ...
}