이전 포스트에서 GitHub Actions와 AWS CodeDeploy를 통해 배포를 자동화하기 위해 여러 설정들을 하는 과정을 거쳤다.이번 포스트에서는 Workflow를 생성하여 실제 배포 자동화가 작동하기까지의 과정을 진행해 볼 것이다.

이전 포스트에서는 GitHub Actions를 통해 Pull Request시 자동으로 테스트를 수행하는 CI 과정을 구현했었다.이번 포스트부터는 AWS의 EC2, S3, Code Deploy 서비스를 이용해 배포까지 자동화하는 CD 과정을 구현해 보자.

main 브랜치에 Pull Request를 할 때마다 해당 브랜치에 대해 자동으로 Junit 테스트를 수행하도록 하는 설정을 진행해보도록 하자.

프로그램 : 디스크에 저장된 실행할 수 있는 형태의 파일프로세스 : 프로그램이 main memory에 로드되어 실행되고 있는 것Text(Code) 영역 : 실행 중인 프로그램의 바이너리(어셈블리)코드Data 영역 : 전역 변수가 저장된다.Stack 영역 : 로컬 데이터

Leaf가 아닌 node들은 자식 node(page)에 대한 주소를 갖고 있고, Leaf node들은 실제 데이터 레코드가 어떤 페이지에 위치해 있는지의 주솟값을 가지고 있다.MyISAM - Primary Key Index와 Secondary Index 둘 다 ROWI

DB의 실제 데이터는 HDD, SSD 같은 보조기억장치에 저장된다.CPU나 DRAM 등에 비해 처리 속도가 매우 느리다.DB에서 순차I/O는 그렇게 많지 않고, 대신 랜덤I/O 작업이 많으므로 HDD보다 SSD가 DBMS에는 좀 더 적합하다.여러 개의 Page를 디스크

B-Tree의 B는 Binary가 아닌 Balanced로, 균형이 잡힌 트리라는 의미의 자료구조이다. 트리의 노드가 한쪽으로만 쏠리지 않도록 노드 삽입 및 삭제 시 특정 규칙에 맞게 재정렬하여 전체적으로 balance를 유지한다.

HTTP는 connectionless하고 stateless하다는 특징을 가진다. Connectionless와 Stateless사용자 인증과 같이 서버에서 지속적으로 클라이언트의 상태나 정보 등을 알아야 할때, 단점이 될 수 있는 connectionless하고 state

HTTP는 여러 가지 특징을 갖고 있는데, 그 중 Connectionless와 Stateless에 대해 알아보자.HTTP는 7계층의 프로토콜로, TCP/IP를 기반으로 한다. TCP/IP의 경우 기본적으로 연결을 종료하지 않으면 그 연결은 종료되지 않고 유지된다. 만약

HTTPS와 SSL/TLS에 대해 알아보자.

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

한 클래스는 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 한다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다.

JVM의 메모리 구조-메소드 영역, 힙 영역, JVM 스택 영역, PC Register, Native Method Stack

NoSQL에 대해 알아보자