라이브 운영중인 환경의 테이블에 인덱스 추가시 고려사항

어우 soap님 질문 남겨주셔서 감사합니다. 꽤나 위험한 작업을 하셨군요 ㅠㅠ 많이 떨리셨겠어요... 먼저 발생하신 장애는 기본적으로 발생가능한 장애입니다. 왜냐하면 SharedLock 을 잡기떄문에 쓰기가 차단되는걸로 보여요.SELECT는 허용될겁니다. 그래서 데이터가 많게된다면, 해당 데이터들을 모두 스캔하는 동안 쓰기데이터가 대기하면서 커넥션 풀이 고갈되는걸로 보여요.. 해결하는 방법으로는 CONCURRENTLY 를 사용하는겁니다. 이러면 ShareUpdateExclusive 을 잡기떄문에 블로킹은 딱히 없기는하지만, 좀 더 오래걸리고 부하도 더 크기는 합니다.대신 서비스는 무중단으로 가능하죠 이외에도 고려할만한게 있다면, 우선적으로 디스크 공간을 확인하셔야해요. WAL 증가도 존재하고 인덱스 생성으로 인해 크기를 더 잡아먹기 때문에 디스크가 여유있는지 확인해주시고 복제본이 있다면, WAL 증가로인해 복제지연이 발생하여 데이터가 정상적으로 표기되지는 않는지 확인해보시면 좋을꺼같습니다. 근데 뭐... 사실 가장 좋은 방법은 사용자가 별로 없는 시간대에 최대한 영향을 주지 않는 시간대에 실행하는게 좋습니다. 이런 경우에는 굳이 CONCURRENTLY 를 쓸 필요도 없겠죠 어느정도 질문에 대한 답이 되셨을까요?? 혹시 추가적인 질문이 있다면 남겨주세요!!

gRPC 실무에서 질문

안녕하세요 IwantKtor님 질문 남겨주셔서 감사합니다. 우선 대규모의 서비스를 운영하는 회사인가보네요 축하드립니다!! 분석에 대한 순서를 말씀해주셨는데, 일단 가장 대표적인거는 .proto 파일 분석입니다. 사실상 중앙화된 proto 레포가 어디에 있는지 파알하는것이 우선적일꺼같아요. 그리고 데이터팀이기 떄문에 사실상 모든 서비스를 보실필요는 없어요. 필요한 데이터만 보시면 될꺼같아요.이벤트 및 로그 생성 서비스 주체데이터 파이프라인에 붙어있는 서비스 위주로어차피 입사하시면 초기 서비스 구성도를 설명해주시니 이 과정에서 가장 대량의 처리를 담당하거나 코어 레벨로써 관리가 되는 서비스를 물어보시면 될 꺼 같습니다.추가로 Wiki라던지 문서들 한번 쭉 읽어보시는것도 방법입니다. .proto 파일을 읽어보시는 순서도 아시면 좋기는 한데, 사실상 명확하게 어떤 역할을 하는지 해당 파일에서 잘 관리가 되어있을 확률이 높습니다. 그러기 때문에 proto 파일에서 Server 블록을 위주로 보시면 좋지 않을까 싶어요. 근데 사실 실제로 사용이 되는지는 모르는거죠. 그래서 트래픽이 실제로 동작을 하는지도 같이 확인해보시면 좋을꺼같습니다.grpcCurl을 활용하시면 좋을꺼같네요.

job, step execution 관련 질문 드립니다.

안녕하세요 배고프면근손실님 질문 남겨주셔서 감사합니다. 음 아무래도 리스너 설정이 되어있을 확률이 있을꺼 같습니다. ExecutionContextPromotionListener 확인이 필요할꺼같아요. 왜냐하면 해당 리스터는 Step이 완료될 떄 지정한 key를 JobExecutionContext 로 복사하는 역할을 수행하기 떄문에 해당 부분을 확인해보시면 좋을꺼같아요.

Orchestration SAGA 패턴 보상에 대한 질문입니다.

안녕하세요 won님 답변이 늦어서 죄송합니다. 개인적으로 이 SAGA 패턴이라는게 저는 막 정해진 방식은 없다고 생각을 해요. 상황에 따라 맞춰서 가는게 맞다고 생각은 합니다. 하지만 그래도 표준에 대한 기준으로 잡아보자면, 저는 계속 진행하면서 각 보상 결과를 독립적으로 추적하는 구조가 되어야한다. 라고 말할 수 있을꺼같아요. 왜냐하면 가정을 해주신 2번 롤백이 실패했다는 상황이 사실상 1번 자체를 시도조차 하지 않는다는건 좀 다른 문제입니다. 상태 자체가 다르다고 느껴져요. 명시적으로 우리가 잘못되었다고 1번 서비스는 롤백 시도도 안한다는게 일단 의도적으로 우리가 이걸 방치한다는 관점이기 떄문입니다. 최소한 시도를 해야 이걸 시도했는지 시도를 하지 않았는지 히스토리에 남아있는다는 관점도 있기 떄문이에요. 이 SAGA라는것의 최종적인 목적이 결국 시스템이 일관된 상태를 유지한다. 가 기본적인 목표입니다. 그래서 1번은 독립적으로 실행되어야 해요. 의존성관점에서도 이 틀은 벗어나지 않습니다. SAGA에서 의존성이라는 관점은 단순하게 롤백 순서를 지켜야한다. 정도의 관점이지 이걸 롤백을 건너 뛰어도 된다 까지는 다루지 않는게 맞는거 같아요. 추적 관점은 보통은 우리가 상태 추적을 위한 step을 독립적으로 관리하시는게 편하실겁니다. 예를들어 음.. 예시적인 코드로 표현하자면 이런 형태가 될꺼같아요.saga_instance saga_id, status (COMPENSATING | COMPENSATION_FAILED | COMPLETED) 이렇게 status를 스탭마다 두어서 관리를 하는거죠. 이러한 관점에서 WAL 이라는 패턴도 한번 적용해보시면 도움이 되실꺼같아요. 혹시라도 추가적인 질문이 있다면 남겨주세요 좋은 질문 남겨주셔서 감사합니다!

DI시 eager과 lazy

안녕하세요 IwantKtor님 질문 남겨주셔서 감사합니다!!제가 깜빡하고 답변을 못드렸네요 죄송합니다 ㅠ.ㅠ 늦게라도 답변을 드리자면, 우선 get 은 선언 즉시 가져오는 행위고 lazy 는 접근 할 떄 값을 가져오는 행위죠. 우리가 이걸 JPA 관점에서도 실제로 적용이 가능한 형태고요 get은 보통 그래서 함수 내부나 초기화 블록에서 사용이 되소 lazy 는 클래스 프로퍼티 관점에서 사용이 됩니다. 그래서 좀 더 딱 정리를 해보자면 get 는 routing 블록 내부에서 이미 DI 컨텍스트가 준비된 시점에 호출 할 떄사용이 되거나, lazy 는 클래스 프로퍼트 즉 순환 의존이 생길꺼 같을 떄 사용한다고 봐주시면 될꺼같습니다. 감사합니다!

강의가 검은 화면으로 나옵니다.

안녕하세요!! 이건 인프런측에서 제공해주는 서비스다보니.... 제쪽에서 무언가 처리해드릴 수 있는 부분이 없습니다 ㅠ.ㅠ 저도 한번 문의해보도록 하겠습니다!!

오라클

안녕하세요 에어님!! 질문 주셔서 감사합니다. 네 들으시는데에 있어서 도움이 되실꺼 같아요. SQL의 기본적인 문법이나 핵심적인 문법 그리고 DDL 설계 및 트랜잭션이나 ACID같은 개념들이 사실상 RDBMS의 공통적인 항목이라서 그대로 적용이 가능합니다. 물론 온전하게 문법이 같지는 않아요. 예를들어 이런 부분들은 따로 학습하시면 좋습니다.LIMIT → ROWNUM 또는 FETCH FIRST n ROWS ONLY AUTO_INCREMENT → SEQUENCE IFNULL → NVL그래서 기본기를 MySQL로 다지고, Oracle 문법 차이점만 추가로 정리하시면 실무 적응에 큰 문제 없으실겁니다.!

Redis 큐

강의에서도 한번 언급드렸떤거 같은데, 간단합니다. 정말 간단한 메시지 큐가 필요한 경우에 사용하시면 됩니다.Kafka나 RabbitMQ를 새로 띄우기가 좀 부담스러운 경우가 되겠죠.

Redis Hash

음.. 어떤 관점으로 보냐에 따라서 다를꺼같습니다. 일단 당연하게도 일반적인 상황에서는 String을 주로 사용하니깐 그냥 그대로 사용하셔도 됩니다. 하지만 음... 기준을 좀 잡아보자면 이런 조건에서는 Hash가 유리할꺼같아요.객체 필드 일부만 업데이트할 때 (HSET user:1 age 26)필드가 많고 부분 조회가 잦을 때메모리 절약이 중요할 때 (ziplist 인코딩 덕분에 작은 Hash는 매우 효율적) 그래서 사실상 트래픽이 낮을 떄를 기준으로 한다면 둘은 차이가 거의 없어요. 일반적으로 이런 서비스의 병목은 사용하시는 Redis의 타입보다는 네트워크 왕복횟수나 들어가는 키의 설계에서 옵니다. 그래서 뭐 기본적으로 String + Json을 사용한다고 잘못되었다고 말하는거 자체가 잘못된겁니다. 그렇게 사용하셔도 무방하고 앞서 제가 기준을 잡았던 기준들에 대해서 저런 상황이 발생한다면, 그떄 한번 사용해보시는것을 고려해보시는게 어떨까싶습니다.

service 를 interface 로 두는 이유

안녕하세요 쵸잉님 질문 주셔서 감사합니다. 말씀해주신부분처럼 굳이 인터페이스를 사용하지 않아도 됩니다. 이건 개인적인 스타일에 가까운거 같아요. 그래서 제 코드가 옳다고 말씀드리기에는 좀 조심스러운 부분이 있습니다. 근데 분리하게 되었을 떄 가질 수 있는 장점은 몇개 있습니다. 대표적으로 CGLIB 같은 문제로 인해서 생성자 제약을 피할 수도 있고, DIP 원칙의 관점에서 구현체가 바뀐다는 부분도 가정했을 떄 변경하기도 편하죠. 뭐 굳이 따지자면 이런 이유들이 다양하게 있는데, 우리가 현실적으로 코드 작성할 떄 막 이런 케이스까지 고려하지는 않습니다. 그래서 쵸잉님이 원하시는 스타일로 작성하셔도 큰 문제는 없을꺼같네요. 어디까지나 개발은 각자만의 스타일이 있으니깐요 ㅎㅎ 이정도면 이해가 되셨을까요??감사합니다!