미로

재직중인 회사에서 팡리이 포함된 기능이 있는 엔드포인트를 새로 추가 및 수정을 진행하게 되었다.

이때 수정 시 PUT이나 PATCH를 사용할때 폼 요청이 지원되지 않는 부분을 정리 할겸 작성을 했다.

불가능한 이유는 일단 지원을 하지 않기 떄문인데 지원을 하지 않는 이유에 대해서는 깊게 알아보기는 어려울 것 같다.

통상 작업을 하게되면 조회(GET), 등록(POST), 수정(PUT OR PATCH), 삭제는(DELETE)를 사용하느데 이미지와 같이 엮어서 사용하게될때 등록할떄는 상관 없지만 수정시에는 폼데이터를 사용할 수 없다.

이번에 요청 받은 작업을 진행 할때 폼데이터를 리스트로 받아 처리를하게 되어서 어쩔 수 없이 수정도 Post를 통해서 작업을 했는데 이게 꼭 이렇게만 처리를 해야하는지 에 대해서는 고민이 든다.

구글링 및 참고 블로그 포스팅을 보면 GET / POST 만 가능한 이유는 다음과 같다.

폼 요청이 GET / POST 만 가능한 이유..

/**
하단 내용은 다른 게시글을 참고하여 작성하였다. 
HTML5.초안에 나왔던 사안이지만 Ian에 의해 무산되버리고 이는 스레드로 나와 있다.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c0

이 논쟁이후 추가 드래프트도 나온다 
(https://www.w3.org/TR/2015/NOTE-form-http-extensions-20150929/#http-put-form)


Delete는 없어도 되지만, Put의 경우 payload를 통해 헤더를 구성하는 방식을 제안하기 때문이라고 한다.

또한 Form은 서버에 정보를 제출하기 위해 존재하는데 Delete와 Put은 아니다. (Get같은 경우는 URL에 폼 데이터를 추가해 서버로 전달하는방식이다.)

Post 와 Put은 전달해주는 payload를 처리하는 요청 대상 리소스가 주체가 되냐, 아니면 대체가되냐의 차이가 크기때문에 요청대상 주체가 될수 없는 Put은 쓰일수 없다는 이유도 있다 한다.

즉 Get은 form 정보를 줄게 리소르를 줘!!
post는 form정보를 처리해줘!
Delete는 URI는 리소르를 정확하게 식별하고 요청하기 때문에 form을 통해 값을 전달할게 없고 (header로 토큰 등등정도)
Put은 대상 리소르를 대체하는 payload를 보내라는 것인데,

Form의 정의를 보면 The

HTML element represents a document section containing interactive controls for submitting
interactive control 형태의 라는 것이 있다.
즉 뭔가를 요청하기 위해 필요한데이터를 보내는 것인데
이 관점에서 리소스 요청 대상 그 자체가 Put으로 담기에는 의미를 위반한다는 관점이라 한다. (확실히 form자체의 뜻을 보니 이해가 더 간다)

**/

신규 API를 작성하여 배포할 일이 생겨 복습겸 스웨거 어노테이션을 정리하고자 한다.

@ApiOperation(
        value = "유저 정보 조회"
        , notes = "유저의 ID 를 통해 해당 아이디의 상세 정보 조회 한다.")
@ApiImplicitParams(
        {
            @ApiImplicitParam(
                name = "id"
                , value = "자격증 아이디"
                , required = true
                , dataType = "string"
                , paramType = "path"
                , defaultValue = "None"
            )
        ,
            @ApiImplicitParam(
                name = "fields"
                , value = "응답 필드 종류"
                , required = false
                , dataType = "string"
                , paramType = "query"
                , defaultValue = ""
            )
        })
		@ApiResponses({
        @ApiResponse(code = 200, message = "성공입니다.")
        , @ApiResponse(code = 400, message = "접근이 올바르지 않습니다.")
    })
    @GetMapping("/user/{id}")
    public  ResponseEntity<UserResponse> getUser(@PathVariable(name = "id") String id) {
        return userService.findUserInfoById(id);
    }

@ApiOperation = Method 설명

• Controlloer 안에 method 의 설명을 추가할 수 있다.

@ApiImplicitParam = RequestParaemter 설명

• 해당 API Method 호출에 필요한 Paraemter들의 설명르 추가할 수 있다.
• ApiImplicitParams을 통해 복수개의 정보를 사용 할 수 있다.

@ApiResponse = Response 설명

• 해당method의 Response에 대한 설명을 작성할 수 있다.
• 복수개의 Response 에 대한 설명을 추가하고 싶다면, ApiResponse를 통해 사용 가능하다.

스웨거의 기본 Response message 삭제방법

• 위와 같이 기본 response 가 노출이 되는데 이를 제거 하기 위헤서는 Swagger config에 Docket에 useDefaultResponseMessages(false)를 설정해주면 된다. (설정 시 401, 403, 404 응답이 사라진다.)

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString
public class UserRequest {
    
    @ApiModelProperty(
        name = "id"
        , example = "gillog"
    )
    @ApiParam(value = "사용자 ID", required = true)
    private String id;

		@ApiModelProperty(example = "teter문")
    @ApiParam(value = "사용자 이름")
    private String name;

    @ApiParam(value = "token 갱신 값")
    private String tokenRefresh;
}

@ApiModelProperty = DTO 예제 설명

• ApiModelProperty를 DTO Class Field에 추가하면, 해당 DTO Field의 예제 Data를 추가할 수 있다.
• property의 name은 생략할 수 있다.

@ApiParam = DTO field 설명

• DTO field에 대한 설명을 추가할 수 있다.
• Controlloer PathVarialbe 기타 파라메터에 대한 설명도 추가 가능

    @ApiIgonre
		@GetMapping("/user/{id}")
    public  ResponseEntity<UserResponse> getUser(@PathVariable(name = "id") String id) {
        return userService.findUserInfoById(id);
    }

@ApiIgnore Swagger UI 표기제외

• Controller 나 메소드를 스웨거 상 비노출 처리 할 수 있다.
• ApiOperation 옵션 hidden을 true로 만들어서 엔드포인트를 숨길 수 있다.

재직중인 회사에서 옆 동료가 레거시를 수정하는 중에  도움을 요청하였다..

대략적인 문제는 특정 엔드포인트 호출시 내부 로직을 보니 같은 쿼리를 키값 만큼 루프를 돌며 쿼리를 호출하는데 해당 쿼리가 0.5초나 걸려 루프사이즈가 커질 수록 점점 느려지는 문제가 있는것을 확인했다 나를 포함한 옆 동료분들도 직접 작업을 한게 아니라서 왜 이렇게 만들었는지는 알수가 없다..

해당 문제를 해결하기 위해 data Grip 에 일단 쿼리를 실행해 보았다.

위 이미지는 문제로 보이는 쿼리를 실행계획으로 돌려본 결과값이다.

제일 상단에 나오는 부분이 문제가 있는 듯하다.

rows에 나오는게 가장 많은데다가

possible key에는 분명히 가능하지만 실제 key에는 인덱스가 타지 않는다.

타지 않는 인덱스를 보니 boolean 필드이다.

아래는 스택오버플로우

https://stackoverflow.com/questions/10524651/is-there-any-performance-gain-in-indexing-a-boolean-field

설명하자면 boolean 필드에 값이 너무 많다면 인덱스를 사용하지 않는다고 한다..

항상 일을 하고 있지만 항상 배우게 된다..

신규 리소스를 배포가 제대로 이루어지지 않아 확인을 해보니 배포 후? 빌드를 하는 중에 디비가 연결이 되지 않아 끊기는 문제가 생겼다.

해당 리소스 ec2 에서 핑 테스트를 해보니 아래와 같은 에러가 발생하였다.

Unable to execute HTTP request: Network is unreachable

혹시나 하여 핑을 구글에 날려보아도 먹통이다..

내가 알아보고 확인한 결과 총 5가지 문제중 하나로 인해 나오지 않을까 싶어 해당 케이스 를 정리해보았다.

1. 네트워크 연결 문제: 이 오류는 네트워크 연결에 문제가 있는 경우 발생할 수 있습니다. 예를 들어 컴퓨터나 서버가 인터넷에 연결할 수 없으면 AWS EC2 엔드포인트와 통신할 수 없습니다.

• 내 로컬에서는 이상이 없음으로 위 문제는 아니다.

2.  보안 그룹 설정: EC2 인스턴스와 연결된 보안 그룹이 올바르게 구성되지 않은 경우 인스턴스가 다른 리소스와 통신하지 못할 수 있습니다. 보안 그룹이 적절한 IP 주소 및 포트의 트래픽을 허용하는지 확인하십시오.

• 혹시나 변경된 정보가 있는지 aws 콘솔 로 들어가 확인 해 보아도 변경사항이 없었다.

3. 라우팅 테이블 설정: VPC와 연결된 라우팅 테이블이 올바르게 구성되지 않은 경우 인스턴스가 다른 리소스와 통신하지 못할 수 있습니다. 라우팅 테이블이 트래픽을 올바른 대상으로 라우팅하도록 구성되어 있는지 확인하십시오.

• 라우팅 테이블 또한 확인하고 최근에 변경 사항이 없어서 문제가 없었다.

4. 방화벽 설정: 컴퓨터나 서버에서 방화벽을 활성화한 경우 방화벽이 AWS EC2 엔드포인트에 대한 트래픽을 차단할 수 있습니다. 방화벽이 적절한 IP 주소 및 포트에 대한 트래픽을 허용하는지 확인하십시오.

• 방화벽 그룹 또한 변경사항이 없어서 문제가 아닌듯 보인다.

5. AWS 서비스 문제: 드물지만 AWS 서비스 자체의 문제로 인해 이 오류가 발생할 수 있습니다. AWS 상태 페이지를 확인하여 EC2 또는 기타 서비스에 진행 중인 문제가 있는지 확인하십시오.

• 위 4가지 문제가 아니기 때문에 의심 스러운 부분은 여기 뿐인듯하다.

내가 전문가는 아니기 떄문에  일단  해당 ec2 를 중단 및 재시작을 하는 방향으로 시도해보았다.(해당 ec2는 개발 서버 였기에)

재 시작을 통해 빠르게 복구 될 줄알 았지만 이번엔 재시작 이후 cpu 점유율이 미친듯이 오르는 문제에 부딪쳤다..

아래는 점유율이 오르는 문제를 해결하기 위해 참고한  블로그 사이트 이다. 

https://nan-sso-gong.tistory.com/32

결론 부터 말하면 완전 중단 후 텀을 두고 재 시작을 하니 죽어도 내려가지 않던 CPU 점유율이 점진적으로 줄어 들었다..

위 참조 블로거를 보시면 스택오버 플로우에도 나와 같은 거지같은 상황을 맞이한 사람들이 있는데 이사람들 또한 크레딧 문제가 아니라는 생각에 모두 stop and start(역시 말 안들을떄는 재부팅이 최고..)

를 가장 많이 투표되었다.

일을 굉장히 짧게 한건 아니지만 항상 새롭다..

얼마전 회사에서 exception처리되는 메세지들이 오는 채널에 아무것도 오지 않는 이상한 일이 발생하였다. 

오류는 아래와 같다.

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; nested exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

위와 같은 에러가 발생을 하였는데 내용을 보니  SSL 인증 관련 에러 발생으로 인해 슬랙 webhook 에러 이다.

아래는 에러 해결을 위한 참고 자료 이다.

https://www.skyer9.pe.kr/wordpress/?p=7544

간단하게 해결 방법을 기술하자면  JDK 버전이 낮아서 나온문제이다. 현재 레거시 프로젝트 들은 1.8.0_66 을 사용중인데 워낙 낮은 버전이다 보니 기존 자바 버전들을 모두 사이드 이펙트 없는 수준까지는 해당 리소스 ec2 들마다 직접 자바를 설치하고 진행 하였다.

역시 버전관리는 주기적으로 꼭 해줘야한다..

회사에서 db를 직접 핸들링 하여 조회 삭제 를  하는 중에  아래와 같은 오류가 발생하였다.

구글링을 해보니 테이블이 깨진것이기 떄문에 콘솔창에서 직접 복구를 해야한다고 나온다.

check table product_images; -- 테이블 조회
analyze table product_images; -- 테이블 분석
repair table product_images;  -- 테이블 복원

테이블을 체크 결과 아래와 같은 에러를 확인하였다.

Wrong bytesec: 0-0-0 at linkstart: 3650572 Corrupt 에러가 있는것을 확인하였다

아래는 에러 참고 링크
https://dba.stackexchange.com/questions/68187/mysql-wrong-bytesec-0-0-0-at-linkstart-0

에러라는게 어디서든 발생하지만 해결방안이 생각보다는 간단해서 다행이다.