https://www.notion.so/blog/data-model-behind-notion
노션에서 각 컨텐츠는 블록 단위로 구성된다. 텍스트 블록, 이미지 블록... 이런 식으로.
블록은 다음 속성을 가진다.
- id (uuid로 생성)
- properties
- title : 블록에 들어가는 내용
- 그 외 특정 블록의 프로퍼티 (가령 체크박스의 경우
checked)
기본적으로 content에 블록 id를 list 형태로 관리한다. 그리고 각 블록은 포인터로 다른 블록을 가리킬 수 있다. 즉 하나의 문서는 트리 구조의 블록을 가진다.
현재 워크플로우에서는 github action의 가상 인스턴스에서 CI를 수행하여, 빌드하고 -> 도커 이미지로 말고 -> 도커 허브에 푸시하고 -> 관련 결과를 슬랙에 전송하는 과정을 거친다.
그리고 CD에서는 ec2 인스턴스에 ssh로 접속하여 도커허브에서 이미지를 받아오고 구동시키는 과정을 거친다.
현재는 빌드만 별도로 테스트할 수 있는 방법이 없어서 on:pull_request로 트리거되는 빌드 워크플로우를 추가해줬다.
하지만 이렇게 하면 빌드가 통과하더라도 다시 on:push 때 다시 빌드가 수행되므로 효율적이지 못하다. 그렇다고 이미지로 말아서 푸시하는 과정을 빌드 과정에 넣어버리면, on:push로 트리거될 때 on:pull_request가 수행 중이라면 CD가 실패하거나, 최신 버전이 아닌 이미지를 받아올 가능성이 존재한다.
일단은 on:push에서도 다시 빌드를 하도록 했지만, 만약 워크플로우 간 종속성을 만들 수 있으면 현재 최신 커밋에 대하여 워크플로우가 트리거되었을 때, 이 워크플로우가 종료된 후에 CD가 진행되도록 디펜던시를 정해줄 수 있으면 꽤 좋을 것이다.
CD에는 다양한 방법이 있다. 현재는 관행적으로 후자를 채택하고 있지만, 조만간 무중단 배포를 위해서 blue-green 방식에 적합한 파이프라인을 알아볼 필요가 있다.
CI/CD는 그 방식이 매우 다양하다. docker로 말지 jar로 그냥 올릴지 선택할 수도 있고 아무튼 많다. 보통 두 가지 방식으로 나뉘는 것 같다.
- jar 파일을 S3로 업로드하고, ec2에서 받아서 배포하는 방식
- jar 파일을 도커 이미지로 말아서 도커허브로 푸시하고, ec2에서 이미지를 받아서 구동시키는 방식
1번 방식은 CI/CD가 배포되기 전에 사용하던 방식과 유사하다. 기존에는 ec2 인스턴스에 ssh로 접속하여 jar 파일을 직접 올려주고, 기존에 구동되던 jar을 종료하고, 새로 다운로드한 jar를 실행시켜줘야 했다. 서버는 1-2분정도 다운타임이 발생할 수밖에 없었다. 때문에 백오피스 서비스의 경우 직원들이 퇴근한 6시 이후에 배포를 진행하는 번거로움이 존재했다.
아무튼 이 방식을 그대로 CI/CD에 적용할 수도 있다. 그냥 기존 방식을 그대로 자동화하는 것이다. 로컬에서하는 것처럼 가상 인스턴스에서 jar을 뽑아내고 ec2로 업로드한 다음에 ssh로 접속해서 기존 jar를 끄고 새로운 jar을 실행시킨다.
여기서 더 발전시킨다면? ec2로 업로드하지 않고, s3로 jar을 업로드한 다음, ec2에서는 s3 버킷으로부터 jar을 받아와서 실행시킬 수 있다. 그렇다면 ec2로 직접 업로드하는 것보다 s3를 거칠 때 장점으로는 무엇이 있을까?
사실 s3를 사용할 때의 장점과 거의 동일하다. 물론 s3를 사용하면서 과금이 발생할 수 있다는 문제가 있지만... 아무튼.
가