네트워크
-VPC
-서브넷
-라우팅 테이블
-인터넷 게이트 웨이
-보안그룹
-탄력적 IP
vpc(Virtual Private Cloud)
aws 클라우드에 격리된 클라우드 공간을 항당해 aws 리소스를 이용할 수 있는 서비스
private와 public으로 나누기 위해서는 vpc를 하나 추가해서 설정해 사용하면 된다.
서브넷
연결되는 서버 컴퓨팅 자원들에 내부 IP를 할당하는 것
라우팅 테이블
연결된 서브넷들을 라우팅 한다.
서브넷들을 4개 만들어서 두개만 할당하는 등 활용할 수 있다.
인터넷 게이트 웨이
외부와 연결하기 위한 게이트웨이
보안그룹
vpc에서 보안그룹에 들어가면 내가 만들어 놓은 보안 그룹을 확인할 수 있는데 그 안에서 인바운드, 아웃바운드 규칙을 설정할 수 있다. 인바운드 규칙은 다음 소스에 해당하는 보안그룹만 해당 s3에 접근할 수 있음을 의미하는 부분이고 아웃바운드 규칙은 내가 외부 api를 호출할 때 그 포트를 열어놓아야 api를 호출 할 수 있다는 것을 의미한다..
인바운드 규칙에서 소스에 0.0.0.0을 설정하면 모든 사용자를 허용할 수 있다.
탄력적IP(고정IP)
ec2를 중단했다 실행만 해도 IP가 가변적으로 바뀌는 것을 알 수 있는데 내가 한 인스턴스만 계속 쓰고 싶다면 탄력적 IP를 사용하면 된다. 왼쪽 탭에서 탄력적 IP를 눌러서 만든 후에 내 인스턴스중 하나와 연결하면 그 인스턴스는 중단했다가 실행해도 고정적 IP를 가지게 된다.
지난번에 이어 EC2 생성부터 시작
EC2 생성은 t2 micro를 기반으로 거의 디폴트 설정을 따라가면 된다. 여기서 22번 포트는 ssh 프로토콜이다.
이렇게 인스턴스를 생성하고 난 후에 git bash를 통해 접속한다.
명령어는
ssh -i "keypair" ubuntu@"원격IP주소"
#파이썬 파일을 python3가 아닌 python으로 실행하기 위한 명령어
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 10
#pip 설치
sudo apt-get update
sudo apt-get install -y python3-pip
# 버전 확인
pip3 --version
# pip3 대신 pip 라고 입력하기 위한 명령어
# 아래 명령어를 입력하면 pip 라고 쳐도 pip3를 작동시킬 수 있습니다.
sudo update-alternatives --install /usr/bin/pip pip /usr/bin/pip3 1
# 파이썬 개발에 필요한 라이브러리 설치
pip install flask boto3 flask-cors
Elastic Load Balancer
서버가 하나라면 다운됐을때 안정성에 문제가 있기 때문에 뒷받침해주는 EC2를 여러개 묶어서 사용하기 위한 ELB를 사용한다.
라우터 추가
위는 직접 만드는 방법이고 항상 상주하지 않기 위해서 쓰는 aws기 때문에 트래픽에 따라 자동으로 만드는 방법도 있다.
AMI 만들기
AMI는 EC2를 복사해서 다음에 쓸 때 편하게 붙여넣기 하기 위한 방법이다.
다음으로 Auto Scaling을 구성하면 되는데 여기는 내일 듣자.
JPA 상속관계 매핑
관계형 데이터베이스는 상속관계가 없지만 슈퍼타입과 서브타입이라는 모델링 기법이 객체 상속과 유사하다고 할 수 있다. 이런 논리 모델을 실제 물리 모델로 구현하는 방법은 세가지로 볼 수 있다.
각각의 테이블로 변환하는 조인전략
통합 테이블로 변환하는 단일 테이블 전략
서브타입 테이블로 변환하는 구현 클래스마다 테이블 전략
JPA의 기본전략은 단일 테이블이다.
Item을 상속하는 각 클래스를 만들고 @Entity를 붙여주면 출력되는 값을 통해 알 수 있다.
이제 각 전략들을 구현해보자.
부모 테이블 Item에
@Inheritance(strategy = InheritanceType.JOINED)를 선언해주면 조인 전략을 실행하는 것을 알 수 있다.
main에서 1차 캐시의 메모리를 db로 .flush(); 해주고 clear로 메모리를 비워준 다음에
Movie findMovie = em.find(Movie.class, movie.getId());
를 하면 JPA가 자동으로 InnerJoin을 실행해주는 것을 가시적으로 볼 수 있다.
@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn //DTYPE 설정
public abstract class Item {
@Id @GeneratedValue
private Long id;
private String name;
private int price;가독성을 위해 GetterSetter는 생략한 Item class인데 여기서 @DiscriminatorColumn을 선언해주면 Default로 DTYPE Column을 선언해주는데 관례상 남기는 것이 좋다.
그냥 만들어도 단일 테이블이지만 설정을 하면 이렇다.
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn
public abstract class Item {
@Id @GeneratedValue
private Long id;
private String name;
private int price;단일테이블이 성능은 가장 좋다. 또한 DTYPE을 따로 명시해주지 않아도 자체적으로 만들어준다. 생각해보면 당연하다.
@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@DiscriminatorColumn
public abstract class Item {
@Id @GeneratedValue
private Long id;
private String name;
private int price;이렇게 하면 구현 클래스마다 테이블이 만들어진다.
단순하게 넣고 뺄 땐 좋지만 조회를 할 때 타입을 Item으로 조회하려고 하면 모든 테이블의 id를 다 찔러보는 대참사가 난다. 성능상 손해가 많다.
정리를 해보면 이렇다. 조인을 기본으로 생각해야 하고 구현클래스마다는 쓰면 안된다.
조인 전략의 장점
-테이블 정규화
-외래키 참조 무결성 제약조건 활용가능
-저장공간 효율화
단점
-조회시 조인을 많이 사용, 성능 저하
-조회 쿼리가 복잡함
-데이터 저장시 INSERT SQL 2번 호출
단일 테이블 전략의 장점
-조인이 필요 없으므로 일반적으로 조회 성능이 빠름
-조회 쿼리가 단순함
단점
-자식 엔티티가 매핑한 컬럼은 모두 null 허용
-단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있고 상황에 따라서 조회 성능이 오히려 느려질 수 있다.
구현 클래스마다 테이블 전략의 장점
-서브타입을 명확하게 구분해서 처리할 때 효과적
-NOT NULL 제약조건 사용 가능
단점
-여러 자식 테이블을 함께 조회할 때 성능이 구림(UNION 필요)
-자식 테이블을 통합해서 쿼리하기 어려움
@MappedSuperclass
공통 매핑 정보가 필요할 때 사용
오늘의 후기
AWS에 대해 드디어 좀 이해가 될것같다. 파편화 돼 있던 기억이 오늘 강의를 전체적으로 다시 들으면서 이해가 됐다. 그렇게 어려운 부분은 아니었던것 같은데 일전에 들었을 때는 집중해서 듣지 않았던 것인가 반성하게 된다.