citeFred’s Blog

/

/

Project [CafeService]

citeFred’s Blog

/

/

Project [CafeService]

Share

🏷️

Project [CafeService]

# of Posts

10

1 more property

Gallery

Search

EC2편 참고자료

https://wickies.tistory.com/102

https://dev-coco.tistory.com/68

EC2 Console에서 MySQL 초기 설정 참고

https://blogshine.tistory.com/322

https://amor-fati.tistory.com/156

RDS 연결하기 포함편 참고

https://velog.io/@u-nij/Spring-Boot-AWS-RDS-MySQL-%EC%97%B0%EB%8F%99%ED%95%98%EA%B8%B0

EC2에 github pull때, TEST 가 충돌이 난다 제거필요, application.properties를 직접 찾아가서 생성해줘야함

TEST파일은 빌드할때 오류가 발생하나보다. 삭제한것을 다시 pull받고 돌리니 빌드가 된다. 하지만 런타임단계에서 오류가 발생하는데,

application.properties 파일 자체가 github에서 제외되었기 때문, 보안땜에 github은 안올리는데, EC2 서버컴에서 pull받으면 이것자체가 없으니 빌드하면 JDBC정보 등등을 못찾을거다.

.gitignore로 제외한것이 있다면, bootjar 빌드에 필요한것은 직접 찾아가서 생성해줘야한다.

우분투 방화벽 ufw 설정 및 허용, EC2 배포시 8080을 혹시나 막았는지 확인할것

ufw 활성화하기

[Spring][HCD 12일차]69 팀프로젝트 배포와 인증서 적용(재실습필요!) [작성중!!🚧]

우선 SSL까지 고쳐지면 빠르게 이부분해보자!

Github Action을 통해 PR또는 Push등을 통해 어떠한 액션에 따라 배포빌드를 자동화 시키는것으로 보여진다.

현재 문제는 수정사항이 생기면 내가 직접 Filezilla를 통해 EC2 인스턴스에 jar파일을 업로드하고, 그걸 실행시키는데

이 행동 하나 하나를 github action을 통해 자동화 시키는 것이 목표인 것으로 보여진다. 고치고 어떤 부분들이, 어떤 설정들이 이 행동들을 자동화시키는지 확인해야 한다. 잠시 작성중!!

[Spring][HCD 추가 3일차]72 CI/CD 파이프라인? [작성중!!🚧]

단위 테스트 해보기

Repository 단위 테스트 해보기

Service 단위 테스트 해보기

Controller 단위 테스트 해보기

통합 테스트 해보기

[Spring][HCD 10일차]67 테스트코드 작성해보기 [작성중!!🚧]

테스트코드 부족한 부분 생각

검색 기능 테스트 코드 구현 중

@ExtendWith(MockitoExtension.class)를 사용하는 경우와

MockitoAnnotations.initMocks(this)를 + @BeforeEach 메서드를 사용하는 경우

간단하게 검색의 성공과 실패에 대한 테스트 코드를 작성해보았다.

이 코드에서의 문제점은 Entity에 직접 Setter 메소드가 필요한 점이었다. 이는 테스트 코드를 위해서 실제 프로젝트의 Entity 클래스에 @Setter가 필요해지면서 데이터를 변형 시킬 수 있는 가능성이 높아져서 테스트코드의 의도와는 다르게 의도하지 않은 DB 조작이 발생할 수 있어 올바르지 않다.

따라서 Mockito 모의 객체를 생성하는 방식으로 변경해보았다.

Mock객체를 통해서 모의 Menu, Store를 생성할 수 있으며, 객체의 필드 또한 모의 필드값을 입력하면서 마치 DB에 있는 데이터처럼 테스트를 진행 할 수 있다.

기본적인 성공 실패 보다 많은 예외 및 유효성검사 와 관련된 테스트 케이스를 만들어볼 필요가 있다.

[Spring][HCD 추가 2일차]71 검색부분 테스트코드 작성해보기

HTTP는 Hyper Text Transfer Protocol의 줄임말로 서버와 클라이언트가 통신하는데 정해놓은 규약이라 할 수 있다.

HTTP의 안전성?

HTTP 통신은 특별한 보안이 없다. 예를들어 악의를 가진사람이 HTTP의 신호를 약탈한다면 통신내용이 외부에 드러나게 된다. 해당 통신 사용자의 개인정보나 중요한 보안이 그대로 보여질 수 있다.

HTTPS 간단 사용이유

HTTP는 전송계층의 TCP위에서 동작한다. 여기서 SSL(Secure Sockets Layer)라는 보안 계층이 전송 계층 위에 올라간다. HTTPS는 TCP위에→SSL위에→HTTP를 얹어서 통신하는것으로 보안이 보장된 통신을 하는 프로토콜이다.

[Spring][HCD 추가 1일차]70-1 HTTPS 적용 이유

내 도메인은 가비아에서 구매했고, Route 53에서 호스팅영역으로 연결해야한다.

도메인 자체를 AWS에서 구매했으면 큰 문제가 없었을것 같은데, 외부에서 구매한 도메인을 사용하고 있기 때문에

Route 53을 도메인의 DNS 서비스로 만들려면(퍼블릭 호스팅 영역의 레코드를 사용하여 도메인의 인터넷 트래픽을 라우팅하기 위해) 도메인 등록을 업데이트하여 이러한 이름 서버를 사용해야 한다.

이 부분에서 가이드를 잘못 따라가면서 문제가 있었을 지도 모른다. 다시 호스팅영역을 삭제하고 새로 생성해보려고한다.

[Spring][HCD 추가 1일차]70-2 ACM-Route53-EC2 배포의 HTTPS 이상 트러블슈팅 - 도메인과 Route53부터 다시 연결하기

https:// 로 정상적으로 접속이 안된다. 설정이 뭔가 잘못되었다. [작성중!!]

배포 단계에서 https 설정을 위해서 SSL 인증서를 발급받았는데 방법은 두가지가 있었다.

아마존 AWS 서비스 중 Aws Certificate Manager (ACM) 을 통해서 무료로 SSL 발급 받기.

도메인 및 호스팅 업체(ex: cafe24, 가비아 등)으로 부터 SSL 유료 발급 받기.

이번에 적용시켜 본 것은 ACM을 통해서 SSL을 발급 받고, 아마존 인프라 환경 내에서 적용시키는 방법이었다. 배포 컴퓨터 자체가 EC2의 인스턴스이기 때문에, 뭔가 자동으로 적용시켜 주는 것 같았다. 하지만 뭔가 생소하긴하다. 아마존 서비스는 뭔가 호스팅 이런 용어를 사용하지 않아서 약간의 혼동이 있었다. 그리고 대부분 클라우드 환경으로 조금 예전부터 한국에서 사용되오는 cafe24같은 호스팅업체의 방식들이 들어있긴 하지만 뭔가 햇갈린다..

하지만 cafe24, 가비아 같은 한국 업체들의 서비스 형태는 대부분 비슷하게 느껴졌다.

어찌 되었든, AWS 서비스 내에서 해결되는 문제로 보여져서 내가 전체적으로 어설프게 알고 있는 부분과 좋은 가이드를 비교하며 차이점을 보면서, 가이드를 천천히 다시 따라가서 문제를 찾아보고자 한다.

내가 각 서비스마다 해야할 것과 그 서비스의 핵심 내용은 다음과 같다.

ACM에서, 인증서발급 및 구매한 특정 도메인에 SSL 적용

Route 53에서, 인스턴스의 서버 실행 시 연결되는 포트

EC2에서, 인스턴스 외부아이피와 연결

위 과정은 글로는 좀 복잡해보이지만 그냥 계속돌아가는 컴퓨터 한대에 인터넷이 연결되어있고 홈네트워크가 아닌(192.168.0.1~255 : xxxx) 외부 다른 위치에서 저 PC에 접속(외부 ip를 통해)하면 된다는 내용으로 이해하고 있는데, 잘못되거나 부족한 부분이 많다. 거기에 SSL 인증서가 추가되어 조금 혼동이 있다. 어떻게 적용되는지 조금 정리가 잘 된 가이드, 또는 나의 환경과 목표와 유사한 사례를 찾아내는 것이 우선이다.

참고 개발 블로그들

[Spring][HCD 추가 1일차]70 ACM-Route53-EC2 배포의 HTTPS 이상 트러블슈팅중.. 우선 네트워크 CS에 대해 좀 더 정확히 알아보기

테스트 코드란?

단위 테스트란?

단위 테스트란?

통합 테스트란?

[Spring][HCD 11일차]68 테스트 코드? TDD란? 모의?Mock? Mockito? 단위테스트? 통합테스트? [작성중!!🚧]

'핵심기능': 각 API 별 수행해야 할 비즈니스 로직이다.

‘부가기능’: 부가적인 기능

핵심 기능과 부가 기능을 구분하는 기준은?

이것이 AOP의 방향이다. AOP는 Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다.

어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다.

간단히 말하면 다른 부분에 계속 반복해서 쓰는 코드들을 발견할 수 있는 데 이것을 흩어진 관심사 (Crosscutting Concerns)라 부른다.

위와 같이 흩어진 관심사를 Aspect로 모듈화하고 핵심적인 비즈니스 로직에서 분리하여 재사용하겠다는 것이 AOP의 취지다.

AOP 주요 개념

Aspect : 위에서 설명한 흩어진 관심사(부가기능)를 모듈화 한 것. 주로 부가기능을 모듈화함.

Target : Aspect를 적용하는 곳 (클래스, 메서드 .. )

Advice : 실질적으로 어떤 일을 해야할 지에 대한 것, 실질적인 부가기능을 담은 구현체

JointPoint : Advice가 적용될 위치, 끼어들 수 있는 지점. 메서드 진입 지점, 생성자 호출 시점, 필드에서 값을 꺼내올 때 등 다양한 시점에 적용가능

스프링 AOP 특징

[Spring][HCD 8일차]63 AOP란?

AOP 활용할 부분을 생각해보기

Spring Boot 프로젝트에서 AOP를 적용하는 부분들이 보통 어떤 부분들인지 궁금했다. 어디에서 사용해야겠다 라는 것 자체가 시나리오를 고려하는 과정인데, 어떤 시나리오에 적합할 지 감이 안왔다. 통상적으로 AOP를 적용하는 사례들을 조사했다.

로깅(Logging): 가장 일반적으로 사용되는 AOP 시나리오 중 하나는 로깅으로 애플리케이션의 여러 부분에서 로그를 일관되게 남기려는 경우 AOP를 사용 할 수 있다.

트랜잭션 관리(Transaction Management): 트랜잭션을 관리하기 위해 AOP를 사용할 수 있다. 예를 들어, 특정 메서드 또는 클래스에 트랜잭션 관리 로직을 적용하여 데이터베이스 트랜잭션을 시작하고 커밋 또는 롤백할 수 있다.

인증 및 권한 부여(Authentication and Authorization): AOP를 사용하여 인증 및 권한 부여 관련 로직을 처리할 수 있다. 예를 들어, 특정 메서드가 실행되기 전에 사용자 인증을 확인하고 권한을 검사할 수 있다.

캐싱(Caching): AOP를 사용하여 메서드 호출 결과를 캐싱할 수 있다. 이를 통해 동일한 메서드 호출의 반복 작업을 줄이고 성능을 개선할 수 있다.

예외 처리(Exception Handling): AOP를 사용하여 예외 처리 로직을 중앙에서 관리할 수 있다. 특히, 여러 메서드에서 공통으로 발생하는 예외를 처리하는 데 유용하다.

메서드 실행 시간 측정(Measuring Method Execution Time): AOP를 사용하여 메서드의 실행 시간을 측정하고 성능 통계를 수집할 수 있다.

위 케이스를 적용하기 전 테스트로 중복 코드제거 해보기

컨벤션을 맞춘다치고 주요 기능인 MenuService, OrderService, ReviewService, StoreService 클래스에 클래스 내 중복을 제거하는 메소드를 만들어 두었었다. 하지만 이 메소드 자체가 위 4개의 서비스 클래스마다 중복되기 때문에 AOP를 통해 모듈화 한다면 효과적으로 중복을 제거 할 수 있다 판단했다.

[1] 의존성 추가

Spring AOP를 사용하기 위해서는 의존성을 추가해야 한다. build.gradle 에 해당 의존성을 추가해준다.

[2] AOP 프록시 활성화(AOP를 앱에 활성화)

[Spring][HCD 8일차]64 AOP 적용

Load more