대용량트래픽과 무중단배포 절차 / GCP . DOCKER . JENKINS . NGINX . RABBITMQ . ELASTICSEARCH

[skarltjr]

vm을 통해 배포하기

1. gcp에서 vm인스턴스 생성

• 여기서는 region은 서울로
• 부팅디스크 : centOS
• http/https모두혀용

2. gcp vm인스턴스에서 ssh를 사용하여 명령

• sudo yum install docker

• sudo systemctl start docker

• sudo docker run -d -p 80:80 docker/getting-started

• ssh란? : Secure Shell Protocol, 즉 네트워크 프로토콜 중 하나로 컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해 서로 통신을 할 때 보안적으로 안전하게 통신을 하기 위해 사용하는 프로토콜.

• 여기서는 gcp,aws의 인스턴스 서버에 접속하여 해당 머신에 명령을 내릴 때 ssh를 사용

3. 배포하고자하는 프로그램 jar파일로 패키징 후 깃허브에 업로드

4. 깃허브에 올려둔 jar파일을 gcp인스턴스에서 다운로드

• ssh를 통해 인스턴스에서 wget , java install // sudo yum install wget
• 이 후 wget + jar파일주소를 통해 인스턴스서버에서 jar파일 다운로드 // wget 주소
• 인스턴스서버에 설치한 java를 통해 jar파일 실행 // sudo java -jar cpu-0.0.1-SNAPSHOT.jar(자르파일)

---

Dockerized 애플리케이션 배포

• https://spring.io/guides/gs/spring-boot-docker/ : 도커파일 작성법

  1. local에서 dockerfile을 빌드하여 도커이미지 생성

     // Dockerfile
     FROM openjdk:8-jdk-alpine
     ARG JAR_FILE=target/*.jar
     COPY ${JAR_FILE} app.jar
     ENTRYPOINT ["java","-jar","/app.jar"]

• 도커허브 저장소 create

• 인텔리제이에서 메이븐 빌드 명령어 : docker build -t 도커허브사용자이름/저장소이름 . 를 통해 이미지빌드 여기서는 docker build -t skarltjr/spring-boot-cpu-bound

• 인텔리제이에서 docker run -p 8080:8080 springio/gs-spring-boot-docker : 로컬에서 실행해보기 여기서는docker run -p 80:80 skarltjr/spring-boot-cpu-bound

• vm에서는 jar파일을 직접실행 / 여기서는 도커이미지안에 있는 jar파일을 실행한것

2. 도커이미지를 도커허브에 푸쉬하여 이미지를 저장소에 저장/업로드

   • 인텔리제이에서 docker push skarltjr/spring-boot-cpu-bound:tagname
   • 여기서는 tagname을 지정하지않았으니 docker push skarltjr/spring-boot-cpu-bound을 수행
   • denied: requested access to the resource is denied / 도커허브에 로그인필요
   • 다시 push
   • 확인

3. GCP인스턴스에서 저장소에있는 이미지를 풀로 다운로드

   • ssh를 통해 인스턴스에 docker다운로드
   • sudo yum install docker
   • sudo systemctl start docker로 도커 실행하기
   • sudo docker pull skarltjr/spring-boot-cpu-bound로 인스턴스에서 pull하기
   • sudo docker run -p 80:80 skarltjr/spring-boot-cpu-bound 를통해 80번 포트를 사용하기 때문에 내부외부 연결 후 실행

4. 다운로드된 이미지를 run하면 컨테이너가 되어 애플리케이션이 실행된다.

   • artillery를 통해 vm과 비교해보기

---

---

---

Jenkins

• jenkins인스턴스와 그냥 인스턴스 만들어서 jenkins 활용 비교해보기
• jenkins인스턴스에 jenkins 다운로드 / ssh를 통해

  
  sudo yum install wget
  sudo yum install maven  // 메이븐에는 자바도 포함되어있어서 sudo yum install java를 하면 Nothing to do가 뜬다. 즉 자바도 설치된다.
  sudo yum install git
  sudo yum install docker

// sudo yum install jenkins를 하면 패키지가 없다고 뜬다. -> 따로 패키지를 추가해줘야한다 sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key sudo yum install jenkins // 이 후 젠킨스 다운로드 sudo systemctl start jenkins // jenkins 데몬 실행 sudo systemctl status jenkins // 데몬 실행 확인

![화면 캡처 2021-02-06 162644](https://user-images.githubusercontent.com/62214428/107112068-203b3180-6898-11eb-855a-622602bdfcd0.png)
- 이렇게 젠킨스가 활성화되면 웹으로 접근할 수 있다
- 그러나 이 떄 젠킨스는 8080포트로 열려있는데 지금 애플리케이션은 80번포트로 지정해놨기 때문에 8080포트도 열어줘야한다.
- 인스턴스 생성시 http,https는 허용했기 때문에 지정한 80포트와 https 443포트는 열려있다
- gcp 방화벽 규칙설정에서  대상 : 네트워크 모든 인스턴스에 대해 모든 IP범위 0.0.0.0/0   TCP포트8080으로 설정
![화면 캡처 2021-02-06 163218](https://user-images.githubusercontent.com/62214428/107112189-05b58800-6899-11eb-8085-ee64bd62aa19.png)
- 확인
![화면 캡처 2021-02-06 163415](https://user-images.githubusercontent.com/62214428/107112201-2bdb2800-6899-11eb-9b57-bc6dd56020cb.png)
- 이 후 인스턴스 IP:8080을 통해 웹에서 jenkins getting started접근가능
- ssh에서 `sudo cat /var/lib/jenkins/secrets/initialAdminPassword`를 통해 초기 비밀번호확인 후 인스턴스 IP:8080에 접속
- 이 후 플러그인 (ssh)설치하고 젠킨스 계정 다시 설정
![화면 캡처 2021-02-06 164407](https://user-images.githubusercontent.com/62214428/107112382-8c1e9980-689a-11eb-87b6-57d5892cd927.png)

설정
- gcp에 2개의 인스턴스 : jenkins instance / worker instance를 만들었는데
- 젠킨스가 워커로 접속하여 도커이미지를 pull받고 이를 run시키는것
- 이 때 젠킨스만 워커에 ssh로 접근하도록 설정해줘야한다 . 해커의 접근방지
- 따라서 젠킨스 인스턴스만 워커인스턴스에 접근하도록 설정해줘야한다
#### 중요 : 어떻게 이러한 설정이 가능한가?
- 기본적으로 평문을 암호문으로 encode(암호화)  / 반대는 decode복호화
- 대칭키 : 암호화 -복호화 에서 사용하는 키가 동일
- 비대칭키 : 암호화 -복호화 에서 사용하는 키가  다른것 
- 비대칭키에서 두 개의 키는 분명 관계가 있다. 그러나 같지않다.
![화면 캡처 2021-02-06 165753](https://user-images.githubusercontent.com/62214428/107112641-79a55f80-689c-11eb-838e-d7060a3772d4.png)
#### 결론적으로 jenkins인스턴스에서 개인키와 공개키를 만들고  공개키를 worker인스턴스에 등록해주면 오직 젠킨스만 워커인스턴스에 ssh로 접속가능 
- 이를위해 젠킨스 인스턴스에서  `ssh-keygen -t rsa -f ~/.ssh/id_rsa` 를 통해 공개키 개인키 쌍을 만들고
- .ssh 폴더로 이동하여 생성된것을 확인
![화면 캡처 2021-02-06 171251](https://user-images.githubusercontent.com/62214428/107112931-9478d380-689e-11eb-8798-aabcb4f4e6b6.png)
- 이 후`[kisa0828@jenkins-instance-1 .ssh]$ vi id_rsa.pub` vi id_rsa.pub명령어를 통해 확인한 공개키를 복사한 후 워커인스턴스 ssh로 접속한 후` vi ~/.ssh/authorized_keys`로 파일을 수정하여 젠킨스 인스턴스에서 복사한 공개키를 워커인스턴스 키 파일에 붙여넣기로 등록
- 이때!!!! 주의할점 공개키를 붙여넣을 때 엔터키가 포함된채로 - 에러 창늘려서 확인해보기
- 추가적으로 이 폴더들의 권한을 변경해줘야한다. 워커인스턴스 ssh에서 폴더권한 변경

[kisa0828@cpu-worker-instance-1 .ssh]$ chmod 700 ~/.ssh [kisa0828@cpu-worker-instance-1 .ssh]$ chmod 600 ~/.ssh/authorized_keys

- 젠킨스 환경설정에서 개인키등록 + ssh 서버 등록(워커인스턴스 등록) : 젠킨스 인스턴스 개인키를 등록하고 (ssh server = )연결할 인스턴스정보 
![화면 캡처 2021-02-06 194336](https://user-images.githubusercontent.com/62214428/107115983-b4ff5880-68b3-11eb-8c6e-3e45c5dc458f.png)
- 이 후 새로운ITEM등록 = 스크립트 작성 - freestyle
- 빌드 후 조치에서 동작할 명령어를 작성 - run명령어 // send build artifacts
- build now를 통해 빌드 후 빌드히스토리에서 생성된 파일 console output 으로 빌드/배포 로그확인해보면 ?
- 안된다. 왜냐?  앞에서 sudo명령어를 사용했는데 8080포트를 열고 변경했기 때문에 sudo가 필요가없다. 어차피 nginx가 앞에서 요청을 받아줄거기 때문에 nginx만 80번포트면 문제가없다.  -> 구성에서 `docker run -p 8080:80 skarltjr/spring-boot-cpu-bound` 변경
- 다시 빌드 후 로그확인 
- 그럼 되는가? 당연히안된다.  워크인스턴스에 도커를 깐적이없기 때문에
- 삽질하면서 배우기  :  젠킨스 인스턴스 ssh에서 공개키 swp파일꺼 복사붙여넣기하다 삽질한것도 기억
- 워크인스턴스에서 도커 다운로드 sudo yum install docker
- 도커데몬 실행 sudo systemctl start docker

1. 결론적으로 명령어는nohup docker run -p 8080:80 skarltjr/spring-boot-cpu-bound > /dev/null 2>&1 & 설정 nohup과 맨 뒤& = 이 명령을 백그라운드로 동작시키겠다.

   /dev/null 2>&1 = 표준에러를 표준출력으로 리다이렉션

2. 워커인스턴스 authorized_keys에 젠킨스인스턴스 공개키 추가
3. 권한설정 [kisa0828@cpu-worker-instance-1 .ssh]$ chmod 700 ~/.ssh [kisa0828@cpu-worker-instance-1 .ssh]$ chmod 600 ~/.ssh/authorized_keys
4. 워커인스턴스에 도커가 없다면 install
5. sudo systemctl start docker
6. sudo chmod 666 /var/run/docker.sock

   
   ![화면 캡처 2021-02-06 230843](https://user-images.githubusercontent.com/62214428/107120315-50062b80-68d0-11eb-85e1-f423a5476a18.png)

[skarltjr]

스트레스 테스트 툴로 성능테스트하기

• node : artillery
• vscode사용
• npm install로 artillery다운로드
• 34.64.70.44 = vm 외부 ip = 테스트하고자하는 / yaml파일 설정 후
• vm인스턴스로 jar파일 실행 후
• vscode터미널을 통해 artillery.cmd run --output report.json .\cpu-test.yaml
• html로 데이터를 보기위해 artillery.cmd report .\report.json

// cpu-test.yaml
config:
  target: "http://34.64.70.44"
  phases:
    - duration: 60
      arrivalRate: 1
      name: Warm up
scenarios:
  # We define one scenario:
  - name: "just get hash"
    flow:
      - get:
          url: "/hash/123"

[skarltjr]

Nginx 로드밸런싱을 통한 무중단 배포

• gcp 워커인스턴스를 3개 다 만드는게 아니라 gcp가 제공해주는 기능 . 복사

• 머신 이미지 -> 머신이미지 만들기

• 이 후 인스턴스를 만들어준다

• 주의 : 이렇게 만들어진 인스턴스는 모두 기존 워커인스턴스와 동일한 환경을 갖는다. 여기서 동일하다는 것은 파일에 대한내용. 설치해준 패키지나 다운로드한것들이 동일한것이지 젠킨스 배포관련설정,8080 포트띄워준 도커 애플리케이션은 해당 x

• 인스턴스 ip 8080으로 확인해보기

3개의 워커인스턴스에 젠킨스를 통해 배포 자동화를 하기 위해 젠킨스 설정

• 설정에서 ssh server추가
• 그러나 auth fail - 그렇다고 매번 젠킨스 인스턴스 공개키를 각각의 인스턴스에 매번 복사해줘야하는가?
• 이를위해 gcp에서ssh키를 관리하는곳이있다. - 메타데이터
• ssh키에 들어가서 젠킨스 공개키를 항목추가
• 다시 젠킨스에서 test configuration해보면 모두 success확인 후 저장
• 젠킨스아이템(프로젝트) 에서 기존에는 워커인스턴스1에만 배포했지만 추가를 위해 ->구성 ->add server로 워커인스턴스 2,3도 추가해주면된다.
• 이 때nohup docker run -p 8080:80 skarltjr/spring-boot-cpu-bound > nohup.out 2>&1 & 으로 명령어 변경
• 기존에 /dev/null은 로그없이 / but 로그 남기기위해 nohup.out으로 변경 1,2,3모두
• 젠킨스 console output으로보면 문제가 없어보이지만 gcp에서 각각 인스턴스에서 tail -f nohup.out으로 찍어보면
• 1번은 8080포트를 이미 사용중이라고 뜨고 2,3번은 도커 데몬이 실행x라고 뜬다
• 따라서 2,3번은 아래 명령어 실행해주고

  sudo systemctl start docker
  sudo chmod 666 /var/run/docker.sock

• 이 후 젠킨스에서 다시 배포(build now)하고 ip 8080/hello로 확인해보면 잘 동작

Nginx를 위해 인스턴스 추가

• 서울region에 4개밖에 추가가안되기때문에 타이완으로 e2 medium
• nginx 인스턴스 ssh를 접속하여 sudo yum install nginx로 다운로드
• sudo systemctl start nginx 로 시작
• nginx ip만 입력해보면 정상동작확인
• nginx로드밸런싱설정을 위해 sudo vi /etc/nginx/nginx.conf
• 설정파일에 추가
• include와 server 사이에

  upstream cpu-bound-app {
  server {instance_1번의_내부ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
  server {instance_2번의_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
  server {instance_3번의_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
  }

• location에

  location / {
  proxy_pass http://cpu-bound-app;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection 'upgrade';
  proxy_set_header Host $host;
  proxy_cache_bypass $http_upgrade;
  }

• 이를통해 로드밸런싱 설정 준비완료
• 무슨 설정인가?
• https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
• 다시 nginx인스턴스ip/hello해보면
• 로드밸런싱 설정은 했지만 적용을 위해 reload or restart를 해야한다
• sudo systemctl reload nginx

  이 때 restart reload의 차이는
  restart : 서비스를 종료 후 재시작 - PID변경
  reload : 프로세스를 종료하지않고 해당 서비스의 설정파일을 다시로딩

• 다시 시도해도 여전히 에러가 나는걸 확인 - nginx 에러로그를 보기위해 sudo tail -f /var/log/nginx/error.log connect() to 10.178.0.15:8080 failed (13: Permission denied) while connecting to upstream, client: 112.151.220.190, server: _, request: "GET /hello HTTP/1.1", upstream: "http://10.178.0.15:8080/hello", host: "35.229.133.12"
• 이 permission denied 구글링해보면
• https://cofs.tistory.com/411에서 찾은내용으로 setsebool -P httpd_can_network_connect on 을 입력해주면된다를 찾음
• root권한으로 다시요청해달라기에 sudo를추가 sudo setsebool -P httpd_can_network_connect on
• 다시 nginx ip/hello로 요청해보면 잘 동작하는걸 확인

결과적으로 nginx에 요청을 했는데 마치 nginx 뒤 설정해둔 서버에서 동작하는 것처럼 작동

• 즉 nginx 1 - n Server로 nginx에서 요청을 받아 로드밸런싱을 통해 뒷단의 서버에서 처리

artillery를 통해 인스턴스3개일때와 1개일때 비교하기

• 500에러는 성능상 더 이상 cpu bound애플리케이션이 요청을 처리할 수 없다

• 502는 500에러 조차 낼 수 없을정도. 애플리케이션이 종료되어서 나타난다. 이때부터 nginx는 이 인스턴스가 더이상 요청을 처리할 수 없다고 판단해서 연결을 끊는다.

• 300초동안 매 초3명의 유저를 투입시킬 때 : 부분부분 튀지만 어느정도 안정적

• 300초동안 매 초 8명의 유저를 투입시킬 떄 : 튀는 부분이 있지만 어느정도

• 이 때 동일한 조건에서 워커인스턴스2,3번을 내리고 단일 인스턴스로 측정해보고 비교해보기

• 그러기위해 2,3번 종료시키기 위해

  실행중인 도커 컨테이너 정보 확인

  
  docker ps // 동작중인 도커정보 출력

실행중인 도커 컨테이너 중 spring-boot-cpu-bound 애플리케이션이 포함된 줄 찾기

docker ps | grep spring-boot-cpu-bound // 이 후 맨 앞 컨테이너 아이디필요없이 찾아낼 수 있다

도커 컨테이너 종료시키기

docker container kill -s 15 {컨테이너 id} // 이를통해 애플리케이션이 스스로 모든 로직을 처리한 후에 잘 종료하도록해준다.

- 이렇게 2,3번 두개의 인스턴스를 종료하고 1번 하나로만 성능측정해보기 : 502 에러 - 처리불가
![화면 캡처 2021-02-07 183455](https://user-images.githubusercontent.com/62214428/107142546-31a53c00-6973-11eb-8ddf-e49d6d93fd92.png)

- 이로써 cpu-bound 애플리케이션을 nginx의 로드밸런싱을 통해 분산처리했을 때 훨씬 안정적인 트래픽을 유지할 수 있는것을 확인했다.

- 다시 젠킨스에 접속해서 build now를 통해 배포를 하여 종료했던 2,3도 다시 동작시키고
- nginxIp/hello로 접속해서 동작을 확인하고 + 개별 인스턴스도 동작하나 확인해보고

#### 그렇다면 로드밸런싱으로 무중단 배포가 정말 이뤄지고 있는가?
- 확인을 위해 artillery스트레스 테스트를 동작시키는 도중에 1,2번 인스턴스를 하나씩 종료해보면
- 그래도 동작이 진행된다는 것은 - 여전히 3번 인스턴스를 통해 처리중이고 즉 무중단 배포가 진행되는것을 알 수 있다.
-  실행해본 결과 artillery test중에 2,3번을 내리고 다시 배포를 했음에도 중단없이 요청이 처리가 되는것을 확인할 수 있었고 결과적으로 무중단 배포가 실행 + 도중에 다시 젠킨스에서 build now를 통해 배포하여 2,3번을 살렸다. 만약 중간에 튀는 부분이 있다면 그것은 2,3번을 내리고 다시 배포하는 동안 1번 혼자서 모든 요청을 처리했기 때문이라고 추측 - 결과보기
![화면 캡처 2021-02-07 185013](https://user-images.githubusercontent.com/62214428/107142912-569aae80-6975-11eb-8784-40d8efe3af08.png)

[skarltjr]

GithubWebhook과 jenkins를 통한 배포자동화

• 나의 저장소이거나 저장소를 fork해서 push/webhook설정 권한획득

• 젠킨스에 접속하여 프로젝트(아이템) -> 구성 -> 소스코드 관리 Git체크 -> 저장소 Url추가 -> Build에서 Excute shell // 자동으로 배포를 위하여 매 배포마다 실행을 해줘야할 명령어를 설정 -깃허브에서 변경사항을 체크하고 다시 패키징을 통해 생성된 jar파일을 배포 -배포를 위해선 메이븐 clean / packing을 통해 타겟디렉토리clean/ 변경사항을 포함하여 다시 패키징을 통해 jar파일 생성 -메이븐 mvnw활용 -> 저장 후 다시 build now -> 빌드가 실패하는 걸 확인 mvnw에 permission denied확인 -> 그러므로 권한을 변경시켜줘야한다. -> 다시 build now - 성공확인

• console output을 통해 젠킨스 로그를 살펴보면 현재 실행중인 명령이 docker를 통해서라는걸 확인

• 그러나 jar파일로 실행을 하기위해 jar path를 복사하여 ->구성 - 빌드 후 조치에서 모든 인스턴스에 대해

• 당연히 지금도 제대로 동작x - 명령어를 보면 java로 실행하겠다고 한다.

• 워커인스턴스에서 docker로 동작시키기위해 docker를 다운로드했지만 java는 다운로드한 적이 없다

• 워커인스턴스 모두 ssh접속하여 java다운로드

• 당연히 또 안된다 - 로그 출력을 위해 중단이 안된다. 다시 명령어 변경을 해줘야하는데 nohup sudo java -jar cpu-0.0.1-SNAPSHOT.jar > nohup.out 2>&1 &

즉 지금 애플리케이션은 docker를 통해서가 아니라 jar파일을 직접 실행 중

• 이전 도커는 8080포트 연결

• 그러나 지금은 더 이상 도커 x

• 그러니 지금은 워커인스턴스ip/hello 하면 바로 연결이 된다. = 애플리케이션에서 지정한 80포트를 사용

• nginx는 8080포트인데 애플리케이션은 80포트 따라서 애플리케이션 모두 8080포트 변경

• 이 내용을 푸쉬하고 자동화

1. 우선 자동화를 위해 실행중인 애플리케이션 모두 종료 -워커인스턴스 ssh로 접속해서 -ps -aux | grep java 실행중인 프로자바 프로세스 검색 -3개의 프로세스 실행중인 걸 확인 후 모두 죽임

2. 깃허브 저장소에서 setting - webhook -add webhook에서 payload를 등록 -http://34.64.101.145:8080/github-webhook/ 젠킨스 외부ip:8080 -contentType : json으로변경

헷갈렸던게 여기서 jar배포파일을 끌어오는게 아니라 이cpu-bound 레퍼지토리에 있는 코드들을 packing해서 자르파일로 만들어서 실행

3. source tree에서 레퍼지토리 클론받기 -클론받은 파일을 인텔리제이로 다시열면 (여기서는 document에 저장해뒀음 ) -여기서 properties에서 포트 8080로 변경후 소스트리에서 변경사항 커밋해주고 마스터에서 push해주기 -젠킨스에서 자동으로 다시 배포가 일어난것을 확인할 수 있다. -인스턴스 ip:8080으로 접속이 잘 되는지 확인 👍 -추가적 확인을 위해 hello request에 응답으로 hello kiseok으로 변경해서 push한 후 살펴보기 -push 후 다시 배포가 일어나는것을 확인했는데 변경이 안된다??? -1번인스턴스 ssh를 통해 tail -f nohup.out으로 로그를 찍어보니

Description:
Web server failed to start. Port 8080 was already in use.
Action:
Identify and stop the process that's listening on port 8080 or configure this application to listen on an
other port.

-이미 8080포트를 사용하고 있는 놈이 존재 -프로세스 확인하고 죽이기 위한 명령 lsof를 사용하기 위해 인스턴스 모두 lsof 다운로드 (L임) // ★ sudo yum install -y lsof -sudo kill -15 $(sudo lsof -t -i:8080) 명령어를 젠킨스에서 모든 ssh server 에 추가 -다시 hello kiseok2로 변경 후 푸쉬하고 배포 후에 확인해보면

그런데 만약 배포진행중에 이런 방식으로 자동화 배포를 한다면 3개의 인스턴스 모두가 재배포를 위해 내려갔다가 다시 올려질텐데 그럼 그동안 nginx를 거쳐 들어온 요청을 처리할 서버가 없다.

• 배포사이에 딜레이를 주는 방법 -sleep 5 ssh에서 sleep 명령어를 사용하면 여기선 5초동안 멈춘 후 그 다음 명령을 받게 할 수 있다.
• 젠킨스를 통해 2,3번 ssh server에 이 명령어를 추가
• 충분한 방법이 아니기 때문에 여러 방법 공부하기 - 배포스크립트 작성법 공부

[skarltjr]

DB I/O bound Application

• postgresql 인스턴스를 하나 더 생성
• 인텔리제이에서 도커로 docker run --name pgsql -d -p 5432:5432 -e POSTGRES_USER=postgresql -e POSTGRES_PASSWORD=postgrespassword postgres 이 후 애플리케이션 실행 확인
• // POSTGRES_USER는 db에서 사용할 유저이름 POSTGRES_PASSWORD는 패스워드 postgres도커이미지 파일 이름 .당연히 이에맞춰 properties설정
• 이 후 yml / properties에서 로컬에서 db를 사용할 땐 spring.datasource.url=jdbc:postgresql://localhost이었지만
• 인스턴스 내부에서 db를 실행하기위해 postgresql인스턴스 내부아이피로 localhost를 변경
• 여기서 5432/postgresql에서 postgresql 이름을 지정한 적이 없는데 왜 postgresql이냐?

  POSTGRES_DB
  This optional environment variable can be used to define a different name for the default database 
  that is created when the image is first started. If it is not specified,
  then the value of POSTGRES_USER will be used.
  즉 POSTGRES_DB를 설정해주면 db의 이름을 지정, 여기서는 지정하지않았기때문에 디폴트값으로 username을 사용

sudo yum install docker // 도커설치 sudo systemctl start docker // 도커데몬 실행 sudo chmod 666 /var/run/docker.sock // 권한부여 docker run --name pgsql -d -p 5432:5432 -e POSTGRES_USER=postgresql -e POSTGRES_PASSWORD=postgrespassword postgres // 도커로 psql실행 ★여기서 원래는 도커에서 psql을 사용하여 계속 저장하기위해 volume을 잡아줘야 db에 있는 내용을 저장가능. // 기본포트 5432 postgres는 이미지 이름 , 유저 패스워드는 db에서 사용할

• iobound app을 위한 워커인스턴스를 따로 또 만들어서 할 수 있지만 여기서는 기존의 cpu -worker인스턴스 재사용

• ★대신 젠킨스에서 새로운 배포 아이템을 만들기

• 이 때 기존 cpu-bound application deploy아이템을 복사하여 생성할 수 있는데 (어차피 배포과정은 jar파일 clean packing을 통해 동일하게 진행할것이기 때문에)

• 새로운 아이템에서

• 추가로 깃허브주소는 io bound 저장소 url로 변경 + jar파일 이름도 변경(인텔리제이에서 maven - plugin - jar를 통해 jar파일 생성 후 이름복사로 추가)+ 당연히 명령어도 io-0.0.1-SNAPSHOT.jar실행을 위해 변경 + branch도 여기서는 main으로 변경

• sourcetree로 properties변경사항 commit 후 push

• 현재 저장소에서 webhook설정을 하지않았기 때문에 자동배포x 젠킨스 build now

• nginx를 통해 접근해보면 동작하는것을 확인

[skarltjr]

I/O Bound - 깃 플로우를 통해 기능개발

• 페이징기능을 위해 sourcetree에서 깃플로우로 paging브랜치 따기(깃플로우 기능개발시작)
• 여기서는 현재url: jdbc:postgresql://10.140.0.3:5432/postgresql 이지만 로컬에서 개발을 위해 주석처리 후 localhost로 변경해서사용
• 실제로는 properties파일을 통해 @Profile을 나눠서하기
• 간단한 페이징 기능 추가

  @GetMapping("/posts")
  public Page<Post> getPostList(@PageableDefault(size = 20, sort = "id", direction = Sort.Direction.DESC) Pageable pageable) {
      return postRepository.findAll(pageable);
  }

• 커밋 : 이 때 여기서 yml or properties에서 url변경 된 파일은 커밋스테이지에 올리면 안된다. 기능개발 종료 대신 PR로 수행하기
• 푸쉬 : dev와 feat:paging push( 깃허브에서 확인 후 pr로 merge하기)
• pr시 base repository는 나의 레퍼지토리 / feat -> dev로
• 변경사항 반영을 위해 sourcetree에서 feat pull당기기
• origin dev와 로컬 dev가 다른것을 확인할 수 있다. - dev도 pull --------------- 다음기능 개발
• 다음으로 개발해야 할 글 번호로 조회하기를 위해 새 기능 브랜치따기(find-by-id)
• 동일하게 개발 후커밋하고 find-by-id브랜치 push / dev는 이전에 이미 push해서 올려놨다.
• pr 후 find-by-id pull
• 동일하게 origin dev와 로컬 dev가 다른것 확인 후 dev도 pull --------------- 마지막으로 기능 추가
• dev브랜치에서 find-by-content브랜치따고
• content를 포함한 content를 가진 post 리스트로 반환기능 추가

  @GetMapping("/search")
  public List<Post> findPostsByContent(@RequestParam String content) {
      return postRepository.findByContentContains(content);
  }

• find-by-content브랜치에서 커밋 후 push
• pr 후 pulll
• dev도 pull받아서 맞춰주기

---

• 마지막으로 main에 합쳐주기 merge
• 메인브랜치에서 병합
• 이 후 push

이제 이 변경사항을 젠킨스를 통해 배포하기

---

artillery를 통해 테스트해보기

• 이 떄 dataset을 만들기 - 구글에서 korean dataset검색을하면 이미 많이 정리되어있음. 다운로드

• 구글docs 스프레드시트로 파일 - 가져오기- 업로드 (txt파일 csv파일로 확장자 변경해서 업로드) - 필요없는 열 지우기 - 이 후 다운로드(csv로)

• artillery test / post요청으로 글 작성테스트 / 333초동안 초당 3개씩

• 1000건에 대해서 안정적임을 확인

• 다음으로 1만건에 대해 테스트하기

• 고도화된 테스트 스크립트

• 1. 60초 동안 초당3번씩 웜업 - 2. ★120초 동안 극단적으로 100번씩 요청으로 점프 - 3.600초동안 동일하게 100번 요청 유지

• 이 2번과 같이 갑자기 요청이 들이닥치는 순간을 잘 해결해야 대용량 트래픽에 대해 대처할 수 있다.

• 500에러와 3.7만건의 타임아웃발생을 확인

• 초당 3->100은 무리 / 50으로 조정 + post생성 요청 후 think( 대기) 1초 후 글목록 조회까지 추가하여 다시테스트

• 합리적인 결과가 나왔지만 여전히 타임아웃발생
• rabbitMQ로 글 작성을 효율적으로 개선하기

[skarltjr]

RabbitMQ : message Queue★

• 서버가 죽는 이유? : 톰캣은 들어오는 요청을 큐에 저장하고 놀고있는 스레드가 있으면 이를 보내서 처리하는데 만약 요청이 너무많아 큐에 저장할수조차 없다면 서버가 죽는다 or 처리되는 시간이 30초 이상인경우 timeout
• 쓰레드를 늘리면되는가? : 어차피 cpu를 공유하기때문에 1/n으로 나눈다고 달라지지않는다.
• timeout시간을 늘리면되는가? : 오히려 처리되면 안될것들이 처리되기 위해서 큐에 더 쌓이게된다.

글 작성 요청을 따로 queue에 저장하였다 처리하기 위한 message queue

• 글작성 요청 -> 컨트롤러로 들어온 글 작성에 대한 요청들은 따로 queue에 넣어놓고 쓰레드는 다음 다른 요청을 받을 준비를 한다.

• 톰캣의 queue와 다른 점 : 톰캣의 큐보다 저장에 특화된 큐 / 만약 톰캣의 큐는 톰캣이 종료되면(서버가 죽으면) 큐도 사라지고 그 안에 저장된 내용도 당연히 같이 사라진다.

Message Queue의 장점

1. 비동기성 : 요청이 몰리는 경우 mq 같은경우 요청을 저장한 후 하나씩 처리해나갈 수 있다. 즉 톰캣같은경우 서버가 죽으면 큐도 날아가버리는 반면 여기서는 저장이 가능 + 따라서 A -> mq ->B 순서에서 A는 로직에 상관없이★ 자신의 할일을 하고 큐에 넣은 후 다시 요청을 받을 수 있는 상태

2. 애플리케이션간 의존성 제거 : A -> B로 API를 통해 데이터를 전달하는 경우 배포과정에서 B가 죽으면 보내려던 데이터는 사라진다. 반면 큐를 중간에 추가해주면 데이터는 여전히 저장이 되어있다. 이 후 B가 다시 정상작업이 가능해지면 저장된 요청을 처리한다.

3. 큐의 이중화 : 큐도 결국 애플리케이션이기 때문에 죽을 수 있다. 여러개의 큐를 사용하여 하나가 죽더라도 이어나갈 수 있도록

4. 신뢰성 : 요청이 실패하면 다시 큐로 가져온다. 이 후 다시 요청

---

실행

• cmd를 통해docker run -d --hostname my-rabbit --name some-rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3-management 도커이미지 받아서 실행하기 / 5672포트를 통해 메세지를 주고받고 15672포트는 모니터링 툴을 위한 포트 + 도커 데스크톱으로도 rabbit mq 확인

• http://localhost:15672 로 username/password : guest로 접속 / 필요할 때 admin에서 계정생성 여기서는 guest로

• queue를 이용하기

• 큐 설정

• 생성확인 후 접속해보기

• 메이븐 의존성 추가

  <dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-amqp</artifactId>
  </dependency> 

• 야믈 or properties에 rabbitmq

  spring:
  datasource:
  #    url: jdbc:postgresql://10.140.0.3:5432/postgresql
  url: jdbc:postgresql://localhost:5432/postgresql
  username: postgresql
  password: postgrespassword
  jpa:
  show-sql: true
  hibernate:
    dialect: org.hibernate.dialect.PostgreSQLDialect
    ddl-auto: update
  rabbitmq:
  host: localhost
  username: guest
  password: guest
  port: 5672

• 메세지를 큐에 집어넣는 producer / 큐에서 메세지를 가져오는 consumer가 필요

  
  1. producer
  @Component
  @RequiredArgsConstructor
  public class Producer {
  
  private final RabbitTemplate rabbitTemplate;
  
  public void sendTo(String message) {
      rabbitTemplate.convertAndSend("CREATE_POST_QUEUE",message);
  }
  }

2. post 컨트롤러 변경 @PostMapping("/post") public Post createPost(@RequestBody Post post) throws JsonProcessingException { producer.sendTo(objectMapper.writeValueAsString(post)); return post; /return postRepository.save(post);/ }

• postman을 통해 post요청을 해보고 rabbitmq로 큐에 메세지 저장되어있는지 확인하기( 도커로 pgsql켜주고 로컬에서 실행되는 psql 종료시켜주기)

• 당연히 db에 안들어갔으니 id는 null

• 메세지 뽑아서 확인해보면

• 저장을 위한 consumer

  
  @Component
  @RequiredArgsConstructor
  public class Consumer {
  private final ObjectMapper objectMapper;
  private final PostRepository postRepository;
  
  @RabbitListener(queues = "CREATE_POST_QUEUE")
  public void handler(String message) throws JsonProcessingException {
      Post post = objectMapper.readValue(message, Post.class);
      postRepository.save(post);
  }
  }

- rabbitMQ 인스턴스 새로 만들기
- 당연히 rabbitMQ에서 5672포트와 15672포트를 사용하기 때문에 방화벽 열어주기 
- sourcetree를 통해 커밋준비 이 때     host: rabbitmq인스턴스 내부아이피 /      url: jdbc:postgresql://postgres인스턴스 내부아이피 확인하기 

spring: datasource: url: jdbc:postgresql://postgres인스턴스 내부아이피/postgresql username: postgresql password: postgrespassword jpa: show-sql: true hibernate: dialect: org.hibernate.dialect.PostgreSQLDialect ddl-auto: update rabbitmq: host: rabbitmq인스턴스 내부아이피 username: guest password: guest port: 5672

- 우선 rabbitmq 인스턴스에 도커 컨테이너 띄우기 

sudo yum install docker sudo systemctl start docker sudo chmod 666 /var/run/docker.sock docker run -d --hostname my-rabbit --name some-rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3-management

- rabbitmq인스턴스 외부아이피:15672로 모니터링 툴 접속 후 동일하게 queue만들어주기 
- 모든 내용 커밋을 위해 dev에서 새로운 브랜치를 따고 커밋 후 푸쉬 
- 레퍼지토리에서 pr로 merge하기(당연히 dev <- feat으로 머지)
- feat에서 pull , dev 에서 pull로 확인
- main이랑 dev 병합하기
![화면 캡처 2021-02-13 160103](https://user-images.githubusercontent.com/62214428/107844196-bcbf7f80-6e14-11eb-8f21-87c9108dd08a.png)

- 이 후main도 푸쉬하여 마무리
- 배포 전 글 목록 0번(첫번쨰 페이지 캐싱)추가

### db부하를 줄이기 위해 글 목록 첫 페이지 캐싱하기  / 내부구현보다 redis 사용이 효율적 
- 매 번 첫번째 페이지 요청마다 db에 접근하는 대신 미리 첫 페이지를 땡겨와서 저장해두면 db에 부하를 감소시킬 수 있다.
- chron 표현식 : https://www.leafcats.com/94

1. 스케쥴링이 가능하도록 설정하고
![화면 캡처 2021-02-13 160856](https://user-images.githubusercontent.com/62214428/107844329-cb5a6680-6e15-11eb-879c-9d76129fb446.png)

2. 글 목록 요청에서 만약 0번째. 첫 페이지를 요청하는 경우에는

@GetMapping("/posts")
public Page<Post> getPostList(@PageableDefault(size = 20, sort = "id", direction = Sort.Direction.DESC) Pageable pageable) {
    if (pageable.getPageNumber() == 0) {
        return postCacheService.getFirstPostPage();
    } else {
        return postRepository.findAll(pageable);
    }
}

3. 1초마다 미리 끌어온 첫 페이지에 대한 내용을 반환해주기. / 즉 많은 첫페이지에 대한 요청이 매우 많은 경우에 미리 가져온 데이터를 반환해줌으로 추가적인 쿼리발생 x  / 이 경우    yml에서 show-sql: false로 변경해줘서 로그 남기지않기

@Component @RequiredArgsConstructor public class PostCacheService {

private final PostRepository postRepository;

private Page<Post> firstPostPage;

@Scheduled(cron = "* * * * * *")
public void updateFirstPostPage() {
    firstPostPage = postRepository.findAll(
            PageRequest.of(0, 20, Sort.by("id").descending())
    );
}

public Page getFirstPostPage() { return this.firstPostPage; } }

- 확인을 위해 localhost에서  show-sql: true로 실행해보면 계속 미리 땡겨오는걸 알 수 있다.
![화면 캡처 2021-02-13 163354](https://user-images.githubusercontent.com/62214428/107844714-47a27900-6e19-11eb-9e74-fdc766f70c79.png)

- 동일하게 dev에서 브랜치 따서 커밋 후 push 하여  pr로 merge한 후  dev브랜치 pull당긴 후 main병합하여 push
- 배포 후 확인

### artillery를 통해 글 작성 테스트 
- rabbitmq를 적용했을 때 글 작성 테스트의 결과는 ?

테스트 스크립트 config: target: "http://35.229.133.12" phases:

• duration: 60 arrivalRate: 3 // 1분동안은 초당 3개씩 웜업 name: Warm up
• duration: 120 arrivalRate: 3 // 이후 2분동안 3->초당50개로 갑작스러운 트래픽증가 rampTo: 50 name: Ramp up load
• duration: 600 arrivalRate: 50 // 이 후 10분동안 초당50개의 요청 유지 name: Sustained load payload: path: "ratings_test_10k.csv" fields:
  • "content" scenarios:
    • name: "just post content" flow:
  • post: url: "/post" json: content: "{{ content }}"
  • think: 1
  • get: url: "/posts"

    
    ![화면 캡처 2021-02-13 192450](https://user-images.githubusercontent.com/62214428/107847716-2a79a480-6e31-11eb-9a10-fb3e3c5b7ba2.png)

• 결과 : 이전보다 rabbitmq를 적용한 후 훨씬 많은 양이 처리되었다.

• 그러나 여전히 전체적으로 정상처리가 안되는데 - 워커인스턴스는 region서울 / nginx는 타이완 / rabbitmq는 일본

• 즉 하나의 요청을 처리하는데 지리적 위치로 인한 전송속도로 지연

• 이를위해 워커인스턴스2,3번을 지우고 네트워크 지연을 막기위해 그 자리에 rabbitmq와 nginx를 끌어온다

★ 요점을 잘 파악 해야한다.

• ★만약 cpu bound app이라면 이 경우 워커인스턴스가 줄어드니 당연히 성능이 저하된다.

• ★ 그러나 지금 중요한 것은 cpu bound x / io bound . 즉 네트워크의 속도가 성능을 결정한다.

• 그럼 당연히 네트워크 지연을 막는것 > 요청을 처리할 cpu의 갯수 보다 중요

• 무엇이 병목인지를 판단해야한다.

• 워커인스턴스2번 삭제 후 nginx 인스턴스 - 새 머신 이미지 생성 - 머신이미지로 새로운 인스턴스 생성(서울로)\

• nginx2에서 nginx서비스 시작

• 이전에 nginx인스턴스를 복사했기 때문에 워커인스턴스 3번에 대한 정보를 지워줘야한다.

• sudo vi /etc/nginx/nginx.conf에서 instance3에 대한내용 삭제

• sudo systemctl start nginx

• 어차피 머신이미지로 파일들은 모두가져왔고 설정,상태에 대해서만 다시 설정해주면된다.

  sudo yum install docker
  sudo systemctl start docker
  sudo chmod 666 /var/run/docker.sock
  docker run -d --hostname my-rabbit --name some-rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3-management

• 확인을 위해 nginx2 아이피:15672 rabbitmq로 접근해보기

• 새로운 인스턴스니까 queue추가해주기

• 인텔리제이에서 rabbitmq host 주소를 변경해주기 nginx2로 들어갈거기 때문

  rabbitmq:
  host: nginx2인스턴스 내부아이피
  username: guest
  password: guest
  port: 5672

• 당연히 레퍼지토리에도 올리기 / 단 이경우에는 간단한 변경이기때문에 메인브랜치에서 바로 커밋 푸쉬

• 마지막으로 젠킨스 구성변경 - 3번 워커인스턴스 삭제 후 buildnow를 통해 메인브랜치 배포

• 이제 다시 artillery로 테스트

여전히 완벽히 처리 x

• 로그를 보기위해 nginx2인스턴스에서 sudo tail -f /var/log/nginx/error.log

• (24: Too many open files) - 구글링 - https://medium.com/hbsmith/too-many-open-files-%EC%97%90%EB%9F%AC-%EB%8C%80%EC%9D%91%EB%B2%95-9b388aea4d4e

• 각 프로세스의 NOFILE Limit를 변경해줘야한다.

• nginx의 프로세스 아이디를 알기위해

• sudo prlimit --nofile --output RESOURCE,SOFT,HARD --pid 1309 를 통해 pid 1309의 리밋확인

• sudo cat /proc/sys/fs/file-max 를 통해 최대 max값 확인 = 368595

• sudo prlimit --nofile=100000 --pid=1309 으로 리밋 올려주기 10만으로 / 1310도 //100000 --pid 띄워야한다 중간에 . 개고생함

• 마무리로 다시 스트레트 테스트 진행

• 모두 성공 정상처리

결과적으로 i/o bound app은 db의 속도가 중요. db에서의 병목을 해결해야한다.

[skarltjr]

글 목록조회 성능 테스트

• 50만건에 대해글 목록조회 테스트하기
• 워커인스턴스 4개까지 추가해주기 /
• 젠킨스 구성설정 후 배포( 메타데이터로 젠킨스 공개키 설정은 이미 했다.

• 시스템 설정에서 젠킨스에서 새로만든 인스턴스 ssh에 접근할 수 있도록 추가 / 프로젝트 구성에서 배포스크립트의 ssh서버 추가

• 이ㅣ 후 배포

• 이 후 테스트

  config:
  target: "http://34.64.207.46"
  phases:
  - duration: 60
    arrivalRate: 3
    name: Warm up
  - duration: 120
    arrivalRate: 3
    rampTo: 50
    name: Ramp up load
  - duration: 6000
    arrivalRate: 50
    name: Sustained load
  payload:
  path: "ratings_test_50k.csv"
  fields:
    - "content"
  scenarios:
  - name: "just post content"
  flow:
    - post:
        url: "/post"
        json:
          content:  "{{ content }}"
    - think: 1
    - get:
        url: "/posts"      

• 현재 db에 60만 건에 대한 post insert완료

• search로 60만건에 대해 검색해보고 시간이 얼마나 나오나 확인하기

• keyword : 영화

1번째 시도 2번째 시도

• keyword : 재미

• keyword : 한국

모든 테스트는 rabbitMQ 큐에 여전히 처리해야 할 데이터가 남아있을 때(유저들이 계속 검색하고있는 환경) 시행

• 50만건인데 이정도 검색속도

• ★만약 데이터가 500만건이면 데이터베이스가 검색속도를 여전히 유지할 수 있을까?

• ★검색을 위해서는 데이터베이스는 부족한점이있다.

• 이를 위해 elastic search

[skarltjr]

nginx에서 connection refuse가 났을 때

• 확인을 해보니 rabbitmq와 연동된 글 작성에서 오류
• 알고보니 nginx인스턴스에서 rabbitmq 실행 x
• 도커설치부터 rabbitmq 재연결
• nginx아이피 : 15672로 rabbitmq에서 큐생성 후 다시 배포하여 확인

추가로 에러가 났을 때 각인스턴스에서 에러로그를 확인해보고 설정 혹은 설치해야할 것을 다시 확인

• rabbitmq의 큐에는 요청데이터가 쌓였는데 db에 들어가지 않았다 -> 워커인스턴스에서 확인해보니 8080포트가 이미 사용중이라함 -> 배포스크립트에서 8080포트 미리 지우라고 작성했는데? -> lsof를 워커인스턴스에 설치하지 않아서 명령어 안먹었음

[skarltjr]

Elastic Search

• db와의 차이점

ES의 문서 저장 방식 / Inverted Index(역 색인)

• db : 직관적

• 문서 -> 내용

• ES : 문서- >내용에 추가로 단어 ->문서로 찾을 수 있는 테이블이 추가된다.

• 즉 특정 단어가 포함된 문서를 빠르게 찾을 수 있다. (역 색인)

• 그런데 만약 "재미"라는 단어로 검색하면 여기서는 "재미있다"를 포함한 문서는 검색이 안된다. /한국어는 ES에서 제공하는 플러그인 NORI를 사용하여 형태소 분석

Shard 샤드

• 문서가 1~100까지 있다고 했을 때 이 문서들을 쪼개서 저장
• 왜 중요한가? : 만약 각각의 저장소를 각각의 인스턴스에 올려서 사용하면 효율성 증가 / 스케일아웃

레플리카

• 샤드는 각각의 인스턴스마다 서로다른 데이터를 저장

• 레플리카는 복사본

• 만약 여기서 1번 인스턴스가 죽으면 다른 인스턴스에 1번의 복제본인 레플리카를 저장 / 단 여기서 2번 인스턴스에 1번인스턴스의 데이터를 저장하는것은 당연히 쓸모없는 일.. 똑같은 데이터이기때문에

[skarltjr]

ES를 통해 검색 요청의 성능을 끌어올리자

• 우선 rabbitMQ인스턴스는 삭제
• nginx내부아이피로 접근하며 그렇기때문에 당연히 이전에 nginx인스턴스에서 rabbitMQ에 접근해서 queue를 설정해뒀고 그걸쓰는것. 즉 rabbitMQ인스턴스에서 사용하는게 없다 = 삭제해도된다.

  rabbitmq:
  host: 10.178.0.21 / nginx내부아이피
  username: guest
  password: guest
  port: 5672 

목표 = ES 클러스터를 구축. 4개의 es인스턴스를 마치 하나의 인스턴스처럼 묶어주기

• 지리적으로 가까운 도쿄에 ES인스턴스 4개 설치
• 4개의 인스턴스 ssh로

  
  # ES 노드에서 실행해야 할 명령어
  # 1. 공통
  sudo yum install -y docker
  sudo systemctl start docker
  sudo chmod 666 /var/run/docker.sock

sudo sysctl -w vm.max_map_count=262144 // 가상메모리를 많이 사용하기때문에 사이즈 늘려주기

2. 1번 노드에서만 실행시키는 명령어 (인스턴스 내부 IP)

<1>. docker network create somenetwork // 네트워크 만들어주기 <2>. docker run -d --name elasticsearch --net somenetwork -p 9200:9200 -p 9300:9300 \ -e "discovery.seed_hosts={1번 IP 빼고 나머지 3개 IP}" \ {}괄호 없이 쉼표로 -e "node.name=es01" \ -e "cluster.initial_master_nodes=es01,es02,es03,es04" \ -e "network.publish_host={1번 IP}" \ elasticsearch:7.10.1 <참고 : 메모장에 옮겨서 안틀리게 명령어 전체를 한 번에 붙여넣어라 - <2>번할 때 docker부터 마지막 10.1까지 한 번에 붙여넣어라> # 3. 2번 노드에서 실행시키는 명령어 docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 \ -e "discovery.seed_hosts={2번 IP 빼고 나머지 3개 IP}" \ -e "node.name=es02" \ -e "cluster.initial_master_nodes=es01,es02,es03,es04" \ -e "network.publish_host={2번 IP}" \ elasticsearch:7.10.1 # 4. 3번 노드에서 실행시키는 명령어 docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 \ -e "discovery.seed_hosts={3번 IP 빼고 나머지 3개 IP}" \ -e "node.name=es03" \ -e "cluster.initial_master_nodes=es01,es02,es03,es04" \ -e "network.publish_host={3번 IP}" \ elasticsearch:7.10.1 # 5. 4번 노드에서 실행시키는 명령어 docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 \ -e "discovery.seed_hosts={4번 IP 빼고 나머지 3개 IP}" \ -e "node.name=es04" \ -e "cluster.initial_master_nodes=es01,es02,es03,es04" \ -e "network.publish_host={4번 IP}" \ elasticsearch:7.10.1 ``` - 노드들이 떴는지 확인하기위해 9200 번으로 접근해야한다 : 9200방화벽 열어주고 확인하기  - 확인을 위해 es instance 1번 외부아이피 : 9200으로 접근해보기 - 이 때 es head extension을 사용 - localhost대신 접속한 아이피로 connect  ### ES가 db보다 좋은가? - ★ 데이터를 저장한다는 공통점이 있지만 다르다 - es는 실시간처리 불가 / 인서트 후 딜레이가 있지만 사실상 거의 체감 x - 트랜잭션과 롤백 불가 - 데이터를 진짜 업데이트하지 않는다. / 삭제 후 다시 만든다. - ★ 즉 애플리케이션이 트랜잭션에 의존(만약 결제같은 프로그램)이라면 es는 사용 x ### jpa- db 대신 elastic search를 사용해보기 //todo

[skarltjr]

• hash처럼 단순반복 연산의 비중이 매우 높다면 그건 cpu자체보다 물리적인 회로의 도입을 고려
• 아무리 cpu가 성능이 좋아도 단순반복에서는 물리적 회로

I/O BOUND 애플리케이션에서의 기술적 선택 요소

★ aws, gcp ,azure 등 클라우드 vs on-premise(독자적인 서버 구축)

★ 스트레스 툴 / node.js의 artillery

• java(nGrinder) / python(locust)등이 있다.

★ CI/CD 툴 - jenkins

• gitlab . bamboo .teamcity등이 존재

★ 배포방식 . 롤링(하나씩)

• 블루그린 / 배포를 위해 기존 서버만큼 그린 서버 구축 -> 그린 서버에서 배포준비가 완료되면 앞 쪽 로드밸런싱을 담당하는 곳에서 요청을 모두 새로운 그린서버로 보낸다.

• 카나리 배포도 존재( 블루그린에서는 이전 버전과 새 버전이 공존 x / 카나리는 요청이 두 곳 모두에 들어가서 공존)

★ 배포시 단순히 30초 sleep이 아니라 서버가 요청을 받을 준비가 되었는지를 판단하기 위해 health check

• 실제 운영서비스라면 애플리케이션이 정상적으로 작동하고있는지 확인하는 health check스크립트를 작성해야한다.

★ 관계형 db vs nosql

• https://github.com/skarltjr/Memory_Write_Record/issues/16#issue-811720558

  ★ RabbitMQ vs kafka

• https://ellune.tistory.com/29참고

  ★글 목록 캐싱 redis

• redis 고려

• 선택에 이유가 있어야한다.
• 테스트를 통해 어디서 병목이 생기는지 파악하자