페이지 개발은 next.js와 react를 이용했다. 예전에 조금 사용해본 적이 있고, 꽤 예쁜 UI를 비교적 쉽게 만들 수 있어서 채택했다. daisyUI를 이용해 테마 기능도 쉽게 적용이 가능했다.

앱을 배포하기 위해 네이버 클라우드 플랫폼(NCP)을 사용했다. DB는 필요없이 서버 1대와 DNS 서비스, public IP 서비스를 이용했다. 도메인을 구매했다. 처음에는 wonderthink라는 도메인이 마음에 들어서 구매대행을 통해 구입했는데, 사이트 성격과 맞지 않는것 같아서 prettyutils.com으로 도메인을 변경했다! NCP와 도메인 구매 대행 업체에서 DNS와 서버를 매핑해주니 인터넷에서 도메인이름으로 사이트에 접근이 가능해졌다.

SSL 설정도 다행히 무료로 할수있는 방법이 있었다. nginx와 certbot이란 걸로 쉽게 설정 가능했다. 배포는 서버에 git pull한 뒤에 도커 빌드하여 실행하는 간단한 스크립트를 만들어두었다.

SEO에 대해서 잘 모르지만 개선해보려고 노력했다. head 태그에 적절한 타이틀, 키워드를 설정해주었다. 그리고 페이지 본문에도 설명을 꽤 자세하게 써주었다. 아직까지 페이지 검색 순위가 굉장히 낮아서 좀 더 개선이 필요하다

처음엔 사이트를 개발하고 데스크탑에서만 확인해봐서 모바일 UI 친화도가 낮았다. 그래서 나중에 모바일에서의 UI도 개선하려고 시도했다. css의 속성을 responsive하게 변경하여 어느정도 개선할 수 있었다. 하지만 safari나 모바일에서 잘 안되는 부분도 여전히 존재한다.

도커 컨테이너가 stop된 적도 있었다. 그래서 사이트에 접근하니 502 bad gateway 오류가 발생했다. 도커 컨테이너를 재실행해도 바로 종료되었다. 그러다가 nginx access 로그에서 "No space left on device"를 확인했다. NCP 모니터링에서도 서버 디스크 용량이 100%인 것을 확인했다. 그래서 먼저 nginx log를 지워줬는데 이건 kb 수준으로 디스크 용량에 큰 영향이 없었다. 원인을 파악해보니 도커 빌드 중에 build cache가 많이 생성되는 것 같았다. docker system prune -a로 해결했다. df -h로 확인하니 도커가 사용하는 filesystem이 크게 줄어들었다.

실습 순서

1. 도커 설치, 샘플 컨테이너 실행해보기
2. k8s에 배포할 샘플 애플리케이션 생성
3. 애플리케이션을 컨테이너 이미지로 패키징, 실행, 레지스트리에 이미지 push

1. 도커 설치, 샘플 컨테이너 실행해보기

• docker desktop 설치

• docker run {image}을 했을 때 발생하는 일

2. 샘플 애플리케이션 생성

const http = require('http');
const os = require('os');

console.log('Kubia server starting...');

var handler = function(request, response){
 console.log('recieved request from' + request.connection.remoteAddress);
 response.writeHead(200);
 response.end('you've hit ' + os.hostname() +'\n');
};

var www = http.createServer(handler);
www.listen(8080);          

• 위 애플리케이션을 실행하기 위해 Node.js를 별도로 다운로드할 필요가 없다고 함! 도커로 애플리케이션을 컨테이너 이미지로 패키징하면, 어디에서든 실행가능하기 때문이라고 함..!

3. 컨테이너 이미지로 패키징, 실행

• 애플리케이션을 이미지로 패키징하기 위해 Dockerfile이라는 파일을 만들어야 한다!
• Dockerfile docs

FROM node:7 #컨테이너 이미지 설정
ADD app.js /app.js #이미지의 루트 디렉토리에 추가
ENTRYPOINT ["node", "app.js"] #이미지 실행 시 수행할 명령어?

• 이미지가 빌드되는 과정 도커파일의 명령을 읽어서 이미지를 빌드한다. 이미지는 여러개의 레이어로 구성된다고 함.

• 컨테이너 이미지 빌드, 실행, 이미지 푸시

  # m1이라 platform 이슈때문에 실행이 안 된다...
  $ docker build -t {생성할 이미지명} {build context 위치(PATH or URL)}
  $ docker run --name {생성할 컨테이너명} -p 8080:8080 -d {이미지}
  

$ docker push {이미지}

도커 컨테이너 플랫폼 소개

개요

• 컨테이너 기술은 오랫동안 사용돼 왔지만 도커가 등장하면서 더 널리 알려졌다고 함. 도커는 패키징 과정을 단순화해서 컨테이너를 여러 시스템에 쉽게 이식 가능하게 하는 최초의 컨테이너 시스템이라고 함.

• 리눅스 컨테이너 기술로 가상머신과 거의 동일한 수준의 격리를 제공.

• 도커는 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼이라고 함. 애플리케이션을 전체 환경과 함께 패키지화할 수 있고, 중앙 저장소로 전송하고, 도커를 사용하는 모든 컴퓨터에 전송할 수 있다!

도커의 주요 3가지 개념

• image 애플리케이션과 환경을 패키지화한 것

• registry 원격 도커 이미지 저장소

• container 도커 기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너라고 함.

도커 이미지의 빌드, 배포, 실행

가상머신 vs 도커 컨테이너

k8s 소개

개요

• k8s는 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이라고 함.

• 가장 간단하게 표현한 k8s 시스템

• k8s는 클러스터 어딘가에 컨테이너화된 애플리케이션을 실행하고 구성 요소 간에 서로를 찾는 방법?에 관한 정보를 제공하고 모든 애플리케이션을 계속 실행하게 한다고 함.

상세 아키텍처

• control plane 클러스터를 제어하고 작동시킨다고 함..?

  • API 서버 유저, 컨트롤 플레인 구성 요소와 통신..?

  • 스케줄러 배포를 담당한다고 함.. (= 애플리케이션 구성 요소를 워커 노드에 할당)

  • 컨트롤러 매니저 복제본?, 워커 노드 추적, 노드 장애 처리? 등의 기능을 수행...?

  • Etcd 클러스터 구성을 지속적으로 저장..?하는 분산 데이터 저장소...?

• 노드 (워커 노드) 컨테이너화된 애플리케이션을 실행하는 시스템.

  • 컨테이너 런타임 컨테이너를 실행

  • Kubulet API 서버와 통신하고 노드의 컨테이너를 관리한다고 함..

  • kube-proxy 트래픽 로드밸런싱을 한다고 함..

k8s에서 애플리케이션 실행

1. 애플리케이션을 1개 이상의 컨테이너 이미지로 packaging
2. 해당 이미지를 레지스트리(원격 저장소)로 push
3. k8s API 서버에 앱 description을 게시!
   • 디스크립션에 기술된 내용 예시 컨테이너 이미지 애플리케이션 구성 요소?가 포함된 이미지 구성 요소들이 통신하는 방법? 함께 배치되야 하는 구성 요소 정보

• 디스크립션으로 컨테이너를 실행하는 방법 디스크립터를 k8s에 제출하면, 각 파드의 지정된 복제본 수만큼 가능한 워커 노드들에 할당.

  • API 서버가 app description을 처리할 때, 스케줄러는 각 컨테이너에 필요한 리소스를 계산. 남은 리소스를 가지고 워커 노드에 지정된 컨테이너를 할당.

  • kubelet은 컨테이너 런타임(도커)이 필요한 이미지를 가져와 컨테이너를 실행하도록 지시.

• 실행된 컨테이너 유지 k8s는 배포 상태가 디스크립션과 일치하는지 지속적으로 확인한다고 함. 인스턴스가 제대로 동작하지 않으면 k8s가 자동으로 다시 시작한다고 함!!

• 이동한 컨테이너 접근 고정 IP..?

질문들

• 도커로 배포, 실행한다는 말의 의미를 정확히 모름

• 모든 도커 이미지는 다른 레이어 위에 구성된다?

• k8s는 많은 머신을 운영할 때 효과적인데, 그런 조직 잘 없는듯한데 k8s를 왜 쓰는지?

• 무슨 뜻인지 이해 안 됨. "k8s를 사용하면 모든 노드가 하나의 거대한 컴퓨터인 것처럼 수천 대의 컴퓨터 노드에서 소프트웨어 애플리케이션을 실행할 수 있다"

• k8s는 클러스터의 운영체제라고 볼 수 있다? 근데 클러스터란 정확히 뭐 말하는거지

• 상세 아키텍처에서 각 구성요소들이 뭐하는건지 모름.... 일단 A지점에서 B지점으로 이동하는 법을 배우고 나서, 자동차의 각 구성 요소 배우는 식으로 공부하라고 조언함!

• 배포 상태가 디스크립션과 일치하는지 지속적으로 어떻게 확인함..?

• 애플리케이션을 왜 격리함?

• 리눅스 컨테이너 기술이 뭔지 모름

• 뭐 리눅스에서 격리시키는 방법이라 보면 되겠지. 다음과 같은 방법으로 구현한다고 함!!

  • 리눅스 네임스페이스로 가시성을 제한
  • 리눅스 컨트롤 그룹으로 프로세스가 사용할 수 있는 리소스를 제한 (cgroups) 각각의 커널을 가지는 VM 인스턴스와 달리, 컨테이너로 격리하면 동일한 커널을 호출해서 보안 위험이 발생할 수 있다는데 그럼 도커도 보안 위험 있는건가?

• hypervisor (가상화 프로세스) 잘 모름 여러 다른 종류의 guest OS를 동작할 수 있게해주는 가상화 소프트웨어라 보면 됨

• 도커 image가 정확히 어떻게 생겼는지 보고싶다

OAuth 2.0이란

• OAuth 2.0은 자신이 소유한 리소스에 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 프로토콜이라고 함..

  1. 어떤 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한 요청.
  2. 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근.

• OAuth 토큰은 발렛 키처럼 클라이언트의 접근 권한을 리소스 소유자가 허용한 범위로 제한할 수 있다고 함.

• OAuth는 한 시스템이 다른 시스템의 어떤 구성 요소에 대한 접근 권한을 얻을 수 있게 해주는 것.

  OAuth 2.0 프레임워크는 리소스 소유자를 대신해 HTTP 서비스와 리소스에 대한 접근 요청 승인을 조정하거나 리소스 소유자를 대신해 서드파티 애플리케이션에게 리소스에 대한 접근을 허용해주는 방식으로 HTTP 서비스에 대한 서드파티 애플리케이션의 접근을 가능하게 해준다...

• 구성 요소 2장에서 자세히 다룬다고 함. 핵심은 OAuth를 통해 클라이언트가 리소스 소유자 대신 보호된 리소스에 대한 접근 권한을 획득하는 거라고 함..

• 책의 예시 상황 사진 저장 서비스(회사 A), 사진 인화 서비스(회사 B)가 있음. 저장 사이트에 사진을 업로드했고, 인화하고 싶다. 그런데 두 서비스는 다른 회사가 제공하여 계정이 연동되지 않는다. 리소스 소유자는 인화 서비스에 사진 접근 권한을 위임해줘야 하는데, 사진에 대한 접근을 완전히 위임하지 않고 제한하고 싶은 상황.

  • 리소스: 사진 저장 사이트의 API
  • 저장 API의 클라이언트?: 인화 서비스
  • 리소스 소유자: 유저

자격 증명 공유

• 사용자의 자격 증명을 그대로 저장해 이용하는 것은 위험해서 한정된 상황에서만 사용해야 한다고 함...

LDAP (Lightweight Directory Access Protocol) LDAP를 이용하면 클라이언트 애플리케이션은 사용자로부터 자격 증명을 직접 수집한다고 함.. 사용자에 대한 "중간자 공격"의 한 형태라고 볼 수 있다고 함...

• 개발자 키를 클라이언트에 발급하고, 클라이언트는 그것을 이용해 보호된 리소스를 직접 요청하는 방법도 있다고 함...

• 서드파티 서비스에 공유할 목적으로만 사용되는 특별한 비밀번호를 사용자에게 발급하는 방법도 있다고 함...

접근 권한 위임

• OAuth는 유저가 보호된 리소스에 대한 자신의 접근 권한 일부를 클라이언트 애플리케이션에게 위임하기 위해 설계된 프로토콜이라고 함. 이를 위해 OAuth 시스템에는 Authorization Server(인가 서버)가 포함된다고 함.

• 위 과정에서 리소스 소유자의 자격 증명이 클라이언트에게 노출되지 않았다?? 리소스 소유자가 인가 서버에 인증하는 것과 별개로 클라이언트와 인가 서버가 통신?

• OAuth의 힘은 권한 위임이라는 개념이라고 함.. 인가 프로토콜로 불리지만, 권한 위임 프로토콜이라고 할 수 있다고 함.

  예를 들어, 사진 인화 서비스가 유저에게 사진 저장 사이트 접근 요청. 사진 저장 사이트는 인화 서비스가 요청한다고 유저에게 알리고 승인여부 요청. 유저가 승인하면 인화 서비스에게 저장 서비스 접근 권한을 위임하게 됨.

• OAuth 시스템은 주로 TOFU 원칙(Trust, On First Use)을 따른다고 함.. 보안적 결정이 런타임에 사용자에게 요구되는 걸 말함.. 처음 한번 사용할 때만 신뢰 여부 결정.

OAuth 2의 장단점

• 인가 서버

  • 클라이언트를 여러 신뢰 레벨로 분류 가능?
  • 복잡성이 클라이언트에서 서버로 이동한다?
  • 모든 클라이언트와 유저의 자격 증명과 토큰을 관리해야 한다고 함..

• 클라이언트

  • 단지 클라이언트의 자격증명?과 토큰을 안전하게 관리하면 된다고 함.

• OAuth2의 확장성과 모듈화는 가장 큰 장점 중 하나라고 함..

• 구현할 때 보안 취약점들이 있다고 함. RFC 6819 - OAuth Threat Model Document

OAuth2가 아닌것?

• 토큰을 얻는 방법, 사용 방법이 OAuth의 기본적인 부분이라고 함.

• OAuth는 Http와 독립적으로 정의되지 않는다? TLS 같은 안전한 전송 계층 매커니즘의 도움이 필요하다고 함... (HTTPS)

• OAuth는 인증 프로토콜이 아니다. 누구인지 알 필요없고, 허락해줬다는게 중요하다고 함..

• OAuth는 토큰의 포맷을 결정하지 않는다고 함.. 근데 편의를 위해 JWT, token introspection 프로토콜의 개발로 이어졌다고 함.

• OAuth2는 암호화 방법을 정의하지 않는다고 함.. JOSE?

질문들

• OAuth는 웹 API를 보호하기 위해 사용되는 보안 프로토콜이다? (로그인 대신해주던걸로만 알고있었는데...)

• 등장 인물들 헷갈림 애플리케이션, 리소스 소유자 리소스 소유자가 누구 말하는거?, 리소스가 어떤 리소스 말하는거?

• 중간자 공격(Man In The Middle Attack) 잘 모름.

• 사용자가 토큰을 관리하는 방식 vs OAuth 프로토콜에서 클라이언트가 토큰을 관리하는 방식

• OAuth는 원래 API를 사용하기 위해 설계됐으며, 주요 상호 작용은 웹 브라우저 밖에서 이뤄진다?

• 클라이언트의 자격 증명이 정확히 어떤 것?

• OAuth에서 클라이언트가 침해되더라도 리소스 소유자의 자격 증명 데이터는 유출되지 않는다? (애초에 그것을 사용하지 않는다고 함.)

• 메시지 시그니처?

애플리케이션 서버 구성 (클라우드)

1. aws 가입

2. AMI(Amozon Machine Image) 선택 AMI는 EC2 인스턴스를 시작하는데 필요한 정보?를 이미지로 만들어 놓은 것이라고 함.

3. 보안그룹 설정 SSH 접속 키 잘 보관해두기(pem 키 = RSA 키인듯) 접근 허용 IP 설정.(난 걍 ssh에 대해 다 열어뒀음.)

4. 고정 IP 할당, ec2에 연결

5. ec2 서버에 접속

   ssh -i {pem key 위치} {ec2 ip address}

   ~/.ssh/config에 Host 등록하면

   ssh {config 파일에 등록한 서비스명} 으로 접속 가능하다고 함.

6. ec2에 접속한 후

   • ec2에 java 11 설치하기

   • 타임존 변경

DB 서버 구성 (클라우드)

• aws에서 Relational Database Service라는 크라우드 기반 RDB 제공 모니터링, 알람, 백업, High Availability를 지원한다고 함..

1. RDS -> create database MariaDB(프리티어) 선택 마스터 유저(admin) id,password 설정 public access 가능하도록 설정 DB명 설정

2. RDS 설정

   • 파리미터 그룹 수정 후 RDS에 연결 timezone charset? max connection

3. DB 클라이언트로 RDS 접속 테스트 mysql과 mariadb가 100% 호환 안된다는 경고는 뜨는데 접속은 됨. (intellij에서 안되길래 mysql workbench로 접속해봄)

4. ec2에서 RDS 접근 ec2에 mysql 설치

   // 접속 
   mysql -u {계정} -p -h {host 주소} 

ec2에 애플리케이션 배포

• git 설치

 sudo yum install git
 git clone {repo 주소}

• 배포란? 프로젝트 코드를 받아서 maven / gradle로 테스트 및 빌드 서버(ec2)에 해당 프로젝트를 실행(재실행)하는 것이라고 함.

• 빌드 스크립트 작성

  • git pull
  • build
  • run application

  #!/bin/bash

  REPOSITORY=/home/ec2-user/app/step1
  PROJECT_NAME=toy-blog-be

  cd $REPOSITORY/$PROJECT_NAME/

  echo "> Git Pull"
  git pull

  echo "> building project..."
  ./gradlew build

  echo "> cd step1"
  cd $REPOSITORY
  echo "now directory = $PWD"

  echo "> copy build file"
  cp $REPOSITORY/$PROJECT_NAME/build/libs/*.jar $REPOSITORY/

  echo "> checking running application's pid"
  CURRENT_PID=$(pgrep -f ${PROJECT_NAME}.*.jar)

  echo "running application's pid: $CURRENT_PID"

  if [ -z "$CURRENT_PID" ]; then
          echo "> no running application"
  else
          echo "> kill -15 $CURRENT_PID"
          kill -15 $CURRENT_PID
          sleep 5
  fi

  echo "> deploying new application..."
  JAR_NAME=$(ls -tr $REPOSITORY/ | grep jar | tail -n 1)

  echo "> JAR Name: $JAR_NAME"
  nohup java -jar $REPOSITORY/$JAR_NAME 2>&1 &

• 빌드 스크립트 실행하면 nohup이란 명령어때문에 계속 실행된 상태를 유지한다고 함..

대학 시절

2학년

2018년에 전역하자마자 코딩을 본격적으로 시작했다. 전역할 때쯤 뭘 먹고살지 진지하게 고민하기 시작했고, 입대하기 전에 존경했던 교수님이 스쳐지나가며 했던 말이 생각났다.

"코딩만 잘해도 먹고 산다"

전자 하드웨어가 이론 위주이고 어렵고 고리타분하다고 생각해서 하기 싫었던 내게 매우 달콤한 말이었다. (심지어 수전증이 있어서 무언가를 조립하는건 자신이 없다) 그래서 전역하자마자 학부연구생으로 들어가서 c언어로 자료구조 및 알고리즘을 구현하며 코딩을 배웠다. 연구실 형들이 숙제 검사를 해주듯이 꼼꼼히 봐주셔서 코딩에 잘 입문할 수 있었던 것 같다. 어려운 과제를 끝낼 때 마다 알을 깨고 나왔다는 느낌이 들었고, 컴퓨팅적 사고가 탑재되기 시작했다. 특히 종이에 쓰면서 디버깅을 하다보니 그 당시에 유행하던 말인 '컴퓨팅적 사고'가 무엇을 말하는지도 알 것 같았다. 약 6개월 동안 자료구조와 알고리즘만 공부하고 구현했고, 코딩의 매력과 비전을 알게 되었고 평생을 바쳐도 괜찮을 분야라는 생각이 들었다.

2학년 2학기에는 자바스크립트로 게임을 만들어보는 수업이 있었다. 화면에 물체를 그리고 움직이게 하니까 재밌었다. 매우 뉴비스럽지만 처음으로 몇천 줄 수준의 프로그램을 작성해봤었다. 에어하키 게임 코드 이러한 게임을 3개 정도 만들었는데, 다른 게임들의 코드는 어디있는지 찾아봐야 하지만 그저 비슷한 로직이 반복되어서 노가다만 하면 짜는 코드이다. (지금 보니 유지보수하기 매우 안좋은 코드같다)

코딩에 잘 입문했지만 아직까지 진로는 막연하게만 생각하고 있었던 것 같다. 단순히 알고리즘이 가장 가치있는 것이고 이것만 잘 알면 되겠지라고 생각했었다.

3학년

2019년. 컴퓨터 관련 기초 과목들을 배우느라 학교 수업만 열심히 따라간 것 같다. 지금 돌아보면 학부연구생을 그만둔 후에 찾아온 약간의 정체기였던 것 같다. 그리고 괜히 보안쪽에 관심을 가졌다가 수확은 없는 공부를 했던 시기라고 생각한다. 예를 들어 컴파일러와 정적분석을 위한 수학, 정적 분석 툴 관련 리서치, 리버스 엔지니어링, 시큐어 코딩 학습 등에 시간을 투자했었다...

서블렛, jsp는 여름방학 때 혼자 3주 정도 공부하면서 입문했고, 2학기 때 서블렛, jsp로 간단한 웹서비스를 만들어보는 수업을 들었다. (여름 방학 때 jsp를 한 번 해봐서 자만하고 있었는데, 수강 인원이 적어서 시험을 조금 못보니 B+를 받았다..)

'웹개발'에 입문했지만 아직까지 웹개발에 큰 흥미를 느끼지 못했고, 여전히 알고리즘이 더 가치있는 것이라고 생각하고 있었다.

4학년

2020년. 코딩테스트라는 것을 통과해야 취업할 수 있음을 알게 됐다. 그래서 1월부터 알고리즘 문제풀이 사이트인 '백준 온라인 저지'에서 문제를 풀기 시작했다. 문제를 풀어보니 정말 뇌에 자극이 많이 됐고, 잘하고 싶었고, 잘 할 수 있을 것 같았다. ACM ICPC라는 알고리즘 대회도 알게 되어 팀원을 모집해서 스터디를 했고 대회에도 참여했다. 스터디를 하고 대회를 준비하다 보니 나는 엄청난 뉴비이고, 실력이 쉽게 늘지 않음을 알 수 있었다.

그렇게 2020년은 주로 알고리즘만 공부했다. 대회를 준비했던 것도 있지만 알고리즘 문제만 잘 풀면 취업할 수 있는줄 알았다. 그런데 그게 아니었다. 코딩테스트가 예선전이었다면 면접이 본선임을 알게 됐다. 잘 기억은 안나지만 몇 군데 지원을 해서 쉬운 코테는 붙었는데 면접에서 모두 떨어졌던 것 같다. 알고리즘 문제를 푸는 것 외에 무언가를 더 해야한다고 판단했다.

2021년 상반기

본격적인 웹개발 학습 시작

4학년이 끝날 때쯤 스프링 프레임워크를 알게 되었고, 2021년 1월부터 본격적으로 자바, 스프링을 이용한 웹개발을 공부하기 시작했다. 채용 공고마다 스프링 프레임워크라는 기술을 요구하길래 이게 도대체 무엇인지 궁금해서 한 번 해보자고 생각했었다. 그런데 정말 잘 만들어놓아서 놀랐다. 예전에 서블렛, jsp로 코딩하던 때랑은 완전히 달랐다. 웹개발이란 분야가 무엇을 하는지, 회사를 다니게 되면 어떤 형태의 개발을 할지 이제야 감이 잡혔다.

자바, 스프링 관련 많은 책을 보며 공부했고, 알고리즘 스터디와 면접 스터디를 해봤고, 협업 프로젝트도 한 번 모집해봤다. 사실 알고리즘 스터디는 꼭 필요했다기 보단 혼자서만 공부하니 심심하기도 하고, 감만 유지하기 위해 했었다. 면접 스터디는 카카오 엔터프라이즈 면접에서 받은 충격때문에 모집했다. (나의 첫 면접은 카카오 엔터프라이즈였다. 자바도 익숙하지 않았을 때 프리인터뷰를 봤는데 인터뷰가 끝나고 10분 뒤에 지원해줘서 고맙다는 메일을 받았다.)

협업 프로젝트 모집은 협업 경험이 없는 내게 가장 필요하다고 생각했다. 하지만 안면도 없는 사람들을 모집해서 그런지 책임감없는 모습들을 많이 봤다. 프로젝트는 잘 끝내지 못했지만 개발 방향에 대해 이야기를 해보며 커뮤니케이션 경험을 해본 것은 도움이 됐다.

첫 인턴

웹개발을 공부한지 약 6개월만에 채용연계형 인턴에 합격했다! 가장 가고 싶은 회사는 아니었지만 괜찮은 회사라고 생각했어서 만족했었다. 교육형 프로젝트를 진행하며 웹 개발에 대한 전반적인 감을 잡을 수 있었다. 특히 자바스크립트로 화면을 조작하고 그리는 부분, SQL에 더 익숙해졌다.

하지만 정규직으로 전환되지 못했다. 돌아보면 예외처리에 대한 개념도 없을 정도로 개발 경험이 부족했고, 마인드도 좋지 못했던 것 같다.

2021년 하반기

책 위주로 반년 이상 공부하다 보니 아는게 꽤 많아졌다. 큰 규모의 개발은 못해보고, 협업 프로젝트도 제대로 진행되지 못해서 아는건 좀 많은데 개발은 별로 안해본 상태가 된 것 같다.

알고리즘 문제풀이 감이 좋을 때였어서 네이버 계열사 4군데 공채 코테에 모두 합격했다.(네이버, 네이버 클라우드, 라인, 네이버웹툰) 하지만 빈약한 개발 경험과 그닥 좋지 않은 마인드로 인해 모두 1차 면접에서 떨어졌다.

2번째 인턴

그래도 겨울에 체험형 인턴에 합격하여 3개월 동안 일할 기회를 얻었다. 간단한 신규 프로젝트를 인턴들에게 전적으로 맡겨서 프로젝트의 설계부터 배포까지 라이프사이클을 경험했다. 백엔드 개발자인지 UI 개발자인지 모를 정도로 화면 개발이 많았지만, 부족하다고 생각했던 상품 수준의 코드 작성 경험과 협업 경험을 쌓을 수 있었서 목표는 이루었다.

그리고 이 때 만났던 인턴 동기들은 지금 내가 가장 좋아하는 개발자 친구들이다. (개발자 친구가 거의 없기도 하다) 동기들은 나보다 먼저 취업을 했는데, 동기들의 취업 소식을 들었을 때 확실히 뭔가 잘못 살고있구나라는 생각이 들었다. 사실 그동안 취준을 하면서 최선을 다했다고 말할 만큼 열심히는 안했던 것 같다. 예를 들어 개발자로서의 삶과 나머지 삶은 분리되어 있었다. 그리고 개발자가 되고 싶은 이유도 편하게 하고 싶은 일을 하면서 쉽게 돈 벌 수 있을거라 생각했기때문이다. 이러한 안좋은 마인드를 가지고 시간을 보냈고, 성숙하지 않은 내면을 확인하게 되어서 후회가 많이 됐다.

2022년 상반기

3번째 인턴

2021년 겨울에 체험형 인턴을 하면서 다른 채용 연계형 인턴에 지원했었는데 합격했다. 가장 가고 싶은 회사는 아니었지만 좋은 회사였고 3개월 동안 일했다. 처음으로 재택이 아닌 출근을 했는데 3개월 동안 끼니가 해결되어 좋았고, 다른 직군의 인턴 동료분들과도 교류할 수 있는 프로그램이 있어서 꽤 재밌었다. 하지만 또 전환에 실패했다..!

기술적으로, 직업 의식적으로는 많이 성장했지만 동료와의 관계와 팀에 잘 맞는지도 중요했다. 전환 면접 때 거의 대부분의 시간을 나의 팀 적응 관련 단점에 대해서만 이야기해서 전환이 되면 이상하다고 생각했던 것 같다. ㅋ_ㅋ 멘토분들과는 비교적 잘 소통했는데 멘토가 아닌 다른 팀원분들과는 잘 어울리지 못한 것이 안 좋게 평가받은 것 같다. 사실 일을 해보니 내가 생각했던 것과 많이 달라서 마음이 조금 떠나있었던 것은 사실이다. 그럼에도 취업해서 안정적인 삶을 살고싶은 마음이 컸기때문에 전환이 되기를 바랬다.

그래도 이전 인턴 때 보다 서버 개발쪽으로는 더 많이 배웠다. 다양한 것들을 리서치하고 적용해볼 수 있도록 멘토님들이 잘 코치해주셔서 도움이 많이 됐던 인턴 경험이었다! 예를 들어 servlet filter를 적용하며 WAS와 스프링 컨테이너의 구조를 더 잘 알게 된 점, 약관 API 개발 및 비동기 처리, API를 보호하기 위해 circuit breaker 적용, 리액티브 프로그래밍 입문, 프론트엔드 페이지 개발, 여러 리팩토링, 여러 학습(nginx, agile 방법론, clean code, docker, kotlin) 등 다양한 경험을 했다.

마지막 인턴

3번째 인턴이 끝날 때 쯤에 가장 가고 싶었던 회사에 채용연계형 인턴으로 지원했었는데 합격했다! 이제 실력, 직업의식 면에서는 자신이 있었다. 하지만 팀에 잘 어울리는 것을 이전 인턴 때 잘하지 못했기 때문에 증명이 필요했다.

회사 생활을 해보니 사람, 근무 환경, 개발 분야 모두 너무 좋았다. 이전 인턴 때보다 개인을 더 존중해주는 분위기였고, 더 관심을 가져주셨고, 의견을 말하기 더 편했다. 회사 건물은 국내가 아닌 세계에서 제일 좋은게 아닐까 싶을 정도로 좋았다. 식당에서 샐러드가 제공되는 것도 좋았다. 개발 분야도 백엔드만 집중적으로 해서 화면 개발의 부담이 사라진 것도 좋았다! 그래서 이번 인턴을 할 동안은 다른 곳에 지원하지 않고 올인해봤다.

짧은 인턴 기간 동안이지만 자는 시간외에 대부분의 시간동안 인턴 프로젝트에 몰입했던 것 같다. 잠도 눕자마자 잠들어서 꿀잠을 잔 경우가 많았고, 5시간 정도 자니 눈이 떠졌다. 회사에 가기 전에 1~2시간 정도 도움이 될 내용을 학습했고, 퇴근하고 나서는 부족했던 부분이나 어려웠던 부분을 복습했다. 주말에는 항상 수영장에 가서 체력을 기르고 스트레스를 풀었다. 그랬더니 살도 5kg 정도 빠지고 건강해졌고, 주중에 열심히 일할 수 있었던 것 같다.

회사 적응은 동료분들이 관심가지고 응원해주셔서 내 목소리를 편하게 낼 수 있었고, 나도 가까워지기 위해 노력한 결과 잘 적응한 것 같다!

정규직 전환

전환 결과 발표를 엄청 오래 기다린 끝에 정규직 전환에 성공했다!

이렇게 기다림이 힘들었던 적은 없는데 가장 가고 싶었던 곳이고, 오래 기다려서 엄청 힘들었던 것 같다. 이곳에 떨어지면 다시 한 번 돌아가야 한다는 생각, 먼저 사회에 진출해있는 친구들의 모습에 대비되는 내 모습을 떠올리는 것도 너무 힘들었다. 회사 회식 때 전환이 안되면 혼자 창업하겠다고 술김에 호기롭게 말했는데 결과를 기다리느라 불안해서 아무것도 손에 잡히지 않는 내 약한 모습에 조금 실망하기도 했다. 결과를 기다리는 동안 체스 게임을 구현해봤는데 어려워서 내 실력에도 조금 현타가 오기도 했다.

그래도 전환 합격 메일을 받으니 마음이 편해졌다. 드디어 취준이라는 긴 터널을 빠져나간다는 생각에 기뻤고, 프로 인턴러인 내가 인턴이 아닌 신입 개발자라는 사실이 조금 어색하다. 취준 기간은 힘들었지만, 가치관이 확립된 것 같고 내면이 더 성숙해질 수 있는 시간이었던 것 같다. 만약 졸업할 때쯤 기술적으로 잘 준비가 되어 있어서 쉽게 취업을 했다면, 나의 직업의식과 삶에 대한 태도가 그리 좋지 못했을지도 모른다. 좋게 봐준 회사와 동료분들에게 너무 고맙고 그에 보답할 수 있도록 노력하고 싶다. 더 큰 목표로는 사회에 좋은 영향을 줄 수 있는 개발자, 어른이 되고 싶다.

DHCP

• Dynamic Host Configuration Protocol

• 옛날에는 컴퓨터를 네트워크로 연결하려면 직접 주소를 할당해야 했다고 함.. 번거로워서 Bootstrap Protocol이라는게 만들어졌고, DHCP로 발전됐다고 함.

• DHCP는 컴퓨터가 IP 주소를 자동으로 얻을 수 있는 응용층 프로토콜이라고 함.

패킷 구조

DHCP 초기화 과정

• Discover, Offer, Request, Acknowledgement 4가지 패킷으로 초기화가 진행됨. 앞 글자를 따서 DORA 프로세스라고 부른다고 함..

• DHCP 초기화 과정 직접 확인해보기

  # window에서 아래 명령어를 입력하면 ip가 release됨. 
  ipconfig /release 

  

1. Discover 패킷

   • 컴퓨터가 DHCP 서버 주소를 몰라서 Discover 패킷은 DHCP 서버 주소를 찾기 위해 전송된다고 함.

2. Offer 패킷

   • 

3. Request 패킷
   • 

4. Ack 패킷

   • 

   • 이제 클라이언트는 ip 주소를 가짐.

DHCP lease renewal

• 임대 갱신의 경우 discover, offer 패킷은 필요없다고 함(확인됨.) request, ack만 필요.

DHCP 옵션

• 메시지 유형 옵션은 필수임. Discover, Offer, Request, Decline, ACK, NAK, Release, Inform 등의 메시지 유형이 있다고 함.

DHCPv6

• 기존의 DHCP 패킷이 IPv6 주소 길이를 담을 수 없어서 DHCPv6가 고안됐다고 함.. 자세한건 스킵..

DNS

• DNS 서버는 클라이언트, 다른 DNS 서버와 공유하는 (ip 주소, DNS 이름) DB에 저장한다고 함.

• DNS는 조회-응답 방식으로 동작한다고 함. query 패킷, response 패킷 2개가 사용됨.

• DNS는 UDP에 의존.

패킷 구조

DNS 재귀

• 인터넷 DNS 구조는 계층적이라고 함. 클라이언트, 로컬 DNS 서버, 외부 DNS 서버 관계 보면 프록시 같은 모습인듯? (프록시라 불러도 되려나..?)

DNS zone(영역)

• 영역 전송은 두 컴퓨터 간에 영역 데이터?가 전송될 때 발생한다고 함..

HTTP

• 웹 페이지 볼 수 있게 해주는 프로토콜

• 트래픽의 가장 높은 비율을 차지하는 프로토콜이라고 함...

• 패킷 예시 패킷 구조는 달라질 수 있다고 함.

SMTP

• Simple Mail Transfer Protocol

이메일 보내고 받기

• 이메일 클라이언트인 Mail User Agent(MUA)로 디지털 사서함에 접근한다고 함. 이메일을 보내면 MUA에서 이메일 서버인 Mail Transfer Agent(MTA)로 전송된다고 함.

이메일 추적

• 예시
  • MUA(나) -> 로컬MTA, SMTP 사용
  • 로컬 MTA -> 원격 MTA, SMTP 사용
  • 원격 MTA -> MUA(상대방), IMAP 사용

smtp 패킷 확인이 안됨........................

질문들

• DHCP가 자동으로 IP를 얻는 과정은?

• 0.0.0.0 vs 255.255.255.255 차이 명확히 모르겠음.

• DHCP에는 자채 내장된 신뢰성 측정 수단이 있어서 UDP 쓸 수 있다는데.. 신뢰성 어케 보장하는건지 모르겠음.

• DHCP offer, request 명확히 모르겠다. 각 단계가 정확히 뭘 하는건지

• request가 IP 주소를 얻는 과정이 아직 완료되지 않아서 여전히 IP 주소 0.0.0.0으로부터 온다는게 무슨 말인지 정확히 모르겠음.

• 왜 IP 임대 갱신할 때는 request, ack 패킷만 사용될까?

• DHCP 메시지 유형에서 Decline이랑 NAK 차이는? Inform은 어떤 메시지?

• ISP가 운영하는 DHCP 서버가 있는건가?

• DNS가 UDP를 사용할 수 있는 이유는

• Flags 필드에서 Reply code로 응답의 오류 여부를 알 수 있기때문이려나? UDP에도 checksum이 있긴한데... UDP는 error correction 안하지. 만약 패킷에 오류가 있으면 그 패킷을 버리고 재요청하지도 않으니.. DNS 요청이 뭐 잘못되면.. 재요청하겠지. 재요청해서 실패할 확률은 극히 낮겠지..?

• 영역 데이터, 영역 전송이 뭔지 모르겠음

• DNS가 TCP 쓸 수도 있다는데.. TCP 쓰는 DNS 패킷 관찰이 안되네...

• https 쓰는 사이트는 http 패킷 안잡힘... TLSv1.3으로 데이터 암호화해서 전송하는데 그래도 http가 많이 쓰인다고 말하는건가? TLS가 많이 쓰인다고 말해야하는거 아님? TLS가 http over tls이긴 한데..

TCP

• Transmission Control Protocol

• TCP의 가장 큰 목표는 host-to-host 데이터 전달에 신뢰성을 주는 것이라고 함. TCP는 데이터를 전송하기 전에 연결을 설정하기 때문에 connection-oriented 프로토콜이라 불림. rfc 793 - TCP

패킷 구조

port

• 모든 TCP 통신은 TCP 헤더에 있는 발신지, 목적지 포트 번호를 이용한다고 함. 서버로 요청하는 경우, 발신지 포트는 그다지 중요하지 않고, 수신 대기 중인 목적지 포트를 알아야 함.

• port 분류

  • 시스템 포트 그룹(well known, 1~1023)
  • 임시 포트 그룹(1024~65535)

연결 설정

• 모든 TCP 기반 통신은 두 호스트 간의 3 way handshake로 시작해야 한다고 함.

• 연결 설정 과정

  1. A -> B, SYN
  2. B -> A, SYN/ACK
  3. A -> B, ACK

연결 해제

• TCP 연결 해제는 통신이 완료된 후 두 컴퓨터 간의 연결을 정상적으로 종료하는데 사용된다고 함.

• 연결 해제 과정

  1. A -> B, FIN/ACK B -> A, ACK

  2. B -> A, FIN/ACK A -> B, ACK

TCP 재설정

• 이상적으로 연결이 종료되지 않고, 갑자기 끝나는 경우도 있음. 연결할 수 없는 컴퓨터로 패킷이 보내지면 RST(Reset) 플래그가 설정된 TCP 패킷이 보내진다고 함.. RST 패킷은 아무 내용이 없는 TCP 패킷이라 연결을 종료하게 됨.

UDP

• 신속한 전송을 목표로 함. DNS와 DHCP는 전송 속도가 중요해서 UDP를 사용한다고 함. UDP에는 패킷이 성공적으로 전송됐는지 확인하는 기능이 없다고 함. DNS, DHCP는 오류 검사 및 재전송 타이머를 자체 처리한다고 함.

• connectionless protocol 호스트 간의 연결 설정, 종료 과정이 없음.

패킷 구조

질문들

• TCP 연결 종료가 QUIC 이런 프로토콜에 영향을 받아서 좀 최적화되는거 같은데..? 관찰해보니.. 마지막 ACK 같은 경우는 SYN/ACK로 쓰이기도 하는듯?

• 재전송 타이머 확실히 모름.

개요

• ARP, IPv4, IPv6, ICMP, ICMPv6 같은 네트워크 계층 프로토콜을 다룸

ARP

배경지식

• Address Resolution Protocol의 약자.

• 논리 주소와 물리 주소. 논리 주소는 여러 네트워크를 통해 간접적으로 연결된 장치 간의 통신. 물리 주소는 하나의 네트워크에서 스위치를 통해 직접 연결된 장치 간의 통신. 대부분의 경우 통신을 위해 이 2가지 주소 지정 방식이 함께 동작한다고 함.

• 스위치에는 CAM(Content Addressable Memory) 테이블이 있다고 함. 이 테이블에는 각 포트에 연결된 모든 장치의 MAC 주소가 나열되어 있음. 스위치는 CAM을 이용해서 어떤 포트로 트래픽을 보낼지 결정한다고 함.

• ** TCP/IP (IPv4)에서 IP 주소를 MAC 주소로 해석하는게 RFC 826에 정의된 ARP라고 함. ** rfc 826 - Ethernet Address Resolution Protocol

ARP 해석 과정

• ARP 해석 프로세스에서는 ARP 요청, 응답 2개의 패킷만 사용한다고 함.

1. ARP 요청 IP 주소가 X인 컴퓨터의 MAC 주소를 알려달라는 브로드캐스트 요청을 함.

2. ARP 응답 IP 주소가 X인 ARP 요청이 찾는 장치는 자신의 MAC 주소를 응답함. 전송 장치?는 수신 장치의 (MAC, IP) 주소 연관을 이용해 자신의 캐시를 업데이트 한다고 함..

의미 없는 ARP

• 의미 없는 ARP는 좋은 것이라고 함... 의미 없는 ARP는 한 네트워크의 모드 호스트가 (IP, MAC) 주소 매핑을 갱신하도록 함.

IP

• OSI layer 3 프로토콜의 주요 목적은 네트워크 간의 통신. 즉, inter network(인터넷)

• LAN (Local Area Network) 모든 장치가 허브나 스위치로만 연결된 단순한 네트워크. 2개의 LAN을 연결하려면 라우터를 사용한다고 함. 인터넷은 수백만 개의 LAN과 라우터의 모음이라고 함..!

IPv4

주소

• IPv4 주소는 네트워크에 연결된 장치를 고유하게 식별하는데 사용되는 32비트 번호.

• ip 주소는 네트워크 부분과 호스트 부분으로 구성된다고 함. 네트워크 부분은 어떤 LAN인지 식별. 호스트 부분은 해당 LAN에서의 장치를 식별.

  ip 주소와 서브넷 마스크는 주로 CIDR 표기법으로 작성됨. 예시) 10.10.1.22/16 -> 네트워크 부분이 상위 16비트, 나머지 하위 16비트가 개별 호스트 식별.

패킷 구조

• TTL 패킷이 통과할 수 있는 라우터의 최대 수. 라우팅에 문제가 생기면 라우터 간에 무한 루프가 생길 수 있음. 그래서 TTL 설정이 없으면 패킷의 수가 증가하여 DOS가 발생하게 되고, 네트워크 대역폭이 고갈됨. 그래서 TTL이 꼭 필요하다고 함!

• packet fragmentation 데이터 스트림?을 작은 단편으로 분할해 더 안정적으로 데이터를 전달하기 위한 ip의 기능이라고 함. 데이터링크 계층(네트워크 인터페이스, 대표적으로 이더넷)의 MTU 크기에 따라 패킷의 최대 크기가 결정된다고 함. MTU보다 패킷이 크면 단편화되는 거임.

IPv6

• 128 비트 주소공간

주소

• 은근히 까다로움

패킷 구조

• IPv4 보다 오히려 더 단순해짐.

IPv6에서 ARP

• 브로드캐스트가 비효율적이라 간주되어 브로드캐스트 트래픽을 지원하지 않는다고 함.. 유니캐스트, 멀티캐스트, 애니캐스트를 지원. 브로드캐스트를 지원하지 않다 보니 ARP 이용 못함.

  그래서 NDP(Neighbor Discovery Protocol)라는 것을 사용한다고 함.. NDP의 Neighbor Solicitation이라는 걸 이용한다고 하고... 이 기능은 ICMPv6를 이용한다고 함...

단편화

일단 스킵

IPv6 전환 프로토콜?

일단 스킵

ICMP

• Internet Control Message Protocol TCP/IP의 유틸리티 프로토콜이라고 함.. 대부분의 네트워크 문제 해결 도구는 ICMP 메시지 중심이라고 함..! RFC 792 - internet control message protocol

• ICMP는 IP의 일부이고, 메시지를 전송하기 위해 IP에 의존한다고 함.

패킷 구조

ICMP 예시

• ping (에코 요청, 응답)

• traceroute 한 컴퓨터에서 다른 컴퓨터로의 경로 파악하는데 사용된다고 함. IP의 도움을 받아 ICMP를 이용해 패킷 경로 파악 가능.

ICMPv6

• RFC 4443

질문들

• 같은 네트워크에 있다면 IP는 필요 없으려나? 근데 같은 네트워크에 있는지는 어케 알 수 있을까?

• ip 패킷 헤더에서 header length, total length등은 왜 필요함?

• 잘못 구성된 라우터는 왜 잘못 구성된거임? 라우팅 테이블이 잘못된 정보를 담고 있는 건가 왜 잘못 구성됨? stale한 데이터 문제?

• ipv6에는 checksum 없는데... 그럼 오류검사 안하는거임? -> layer 2랑 4에 이미 checksum있다고 함.. 그럼 ipv4도 checksum 하지말지 왜 한거..?

• 트래픽 분류에서 애니캐스트가 뭔지 모름

• NDP(Neighbor Discovery Protocol) 모름 이웃 간청, 이웃 광고...

• traceroute 내부 동작.. TTL 값을 1씩 증가시키며 경로를 추적하는데.. 어떤 알고리즘 쓰였을지 (다익스트라?) Shortest Path with Dijkstra’s Algorithm

• wireshark 대신 커맨드라인 도구를 사용하는 이유

  • GUI 도구인 wireshark보다 더 빠르다고 함.
  • 유닉스 파이프라인을 이용해서 다른 도구에 결과를 제공하는데 적합하다고 함..
  • 와이어샤크는 종합툴이지만 커맨드라인 툴을 사용하면 원하는 정보만 얻을 수도 있다고 함..

• tcpdump는 가장 인기있는 커맨드라인 패킷 분석 애플리케이션이라고 함.

패킷 캡처

$ sudo tcmpdump

$ ifconfig # 캡처할 인터페이스 목록 조회
$ tcpdump -i {캡처할 인터페이스}

# 수집한 패킷을 파일에 저장하기
$ tmpdump -i {인터페이스} -w {파일명} 

# 저장한 파일 읽기
$ tcpdump -r {파일명} -c{limit}

패킷 캡처 결과 출력

tcpdump -v # -v는 자세한 정보 표시 옵션(verbose)

필터 적용

tcpdump '{필터 조건식}'

# 예시
tcpdump 'tcp dst port 80' -w 파일명.pcap 

질문들

• ICMP 프로토콜 까먹음.

• 유닉스 파이프라인 이용해서 tcmpdump 결과를 다른 도구에 직접 제공하는게 무슨 말인지 정확히 모르겠음. 직접 해보면 바로 감잡을듯 한데..

• tcpdump 결과 읽는거 어색함

• tcpdump 통계 기능 모름

• 와이어샤크는 패킷 스니핑 애플리케이션 중에 하나.

역사

• 1998년에 GNU public license에 따라 처음 발표됐고, 2006년에 wireshark라는 이름으로 변경됐다고 함. 현재 500명 정도가 개발하고 있다고 함!

장점

• 1000개 이상의 다양한 프로토콜을 지원한다고 함. IP, DHCP, DNP3?, BitTorrent 등

• 사용자 편의성 GUI

• 비용 무료

• 커뮤니티 활발

• 오픈소스라서 소스코드 볼 수 있음! wireshark github 무려 85000개의 커밋...

• 여러 운영체제 지원 윈도우, 리눅스, OS X 등

설치

• Wireshark 공식 홈페이지 Download ChmodBPF.pkg라는 것도 설치해줘야 함. (와이어샤크 시작하면 화면에 설치링크 있어서 그거 클릭하면 됨.) 패킷 캡처 권한 설정 관련된 거라고 함.
• brew를 이용한 설치도 가능한듯?

와이어샤크 기초

• 메인 창 캡처한 모든 패킷이 나타남. 패킷 목록, 패킷 세부 정보, 패킷 바이트(원시 형식의 패킷) 등 확인 가능.

• 설정 패킷 캡처 방식(capture), 트래픽 필터(filter expressions), 통계(statistics) 등의 관련 설정 가능.

• coloring rules

구성 파일, 프로파일

...

질문들

• DNP3 프로토콜 모름

• BitTorrent 프로토콜 잘 모름

• WinPcap/libpcap 캡처 드라이버(라이브러리?)가 뭔지 모름. -> Winpcap이 pcap 패킷 캡처 API의 윈도우 구현이라고 함. libpcap은 리눅스용 패킷(layer 2 = 데이터링크 계층) 캡처 API라고 함.

• 구성 파일, 프로파일 사용법 잘 모르겠음..

• 데이터를 잘 캡처하기 위해 패킷 스니퍼를 어느 위치?에 배치할지 결정하는게 효과적인 패킷 분석을 위해 중요하다고 함.

• 패킷 스니퍼를 설치할 장소?를 결정하는 법에 대해 다룸.

무차별 모드

• promiscuous mode
• 네트워크에서 패킷을 스니핑하기 위해서는 무차별 모드 드라이버를 지원하는 네트워크 인터페이스 카드가 필요하다고 함...
• 클라이언트는 ARP 브로드캐스트 패킷을 수신은 하는데, 자기 MAC 주소가 아니면 그냥 버린다고 함. 이게 효율적이지만 패킷 분석할 때는 좋지 않음. 근데 NIC의 무차별 모드를 사용해 모든 트래픽을 캡처할 수 있다고 함..

허브에서 스니핑

• 허브가 설치돼 있는 네트워크에서 스니핑하는 게 왜 패킷 분석가의 꿈이라고 함. 근데 허브 기반 네트워크는 관리가 힘들어서 요즘에는 안쓴다고 함..

• 한 번의 하나의 장치만 허브와 통신할 수 있다고 함.. 그래서 허브에 연결된 장치들은 서로 경쟁한다고 함. 그래서 패킷이 충돌하여 패킷을 여러번 보내야 할 수도 있고, 네트워크 성능이 저하될 수 있다고 함.

스위치에서 스피닝

• 스위치는 최신 네트워크 환경에서 사용되는 가장 일반적인 유형의 연결 장치라고 함.

• 브로드캐스트, 멀티캐스트, 유니캐트 트래픽 사용 가능하고 전이중 통신 가능.

• 근데 스위치 환경은 패킷 분석하기 더 어렵고 복잡하게 만든다고 함...

• 스위치 환경에서 다른 컴퓨터를 스니핑하기 위한 방법은 포트 미러링, 허빙 아웃, 탭 사용, ARP 캐시 포이즈닝 등의 방법이 있다고 함.....

port mirroring

• 특정 포트의 모든 트래픽을 다른 포트에 복사하게 하는 명령을 실행해서 패킷 스니핑하는 것 같음.
• 데이터 손실이 있을수 있어서? 좋은 모니터링 방법은 아니라고 함..

hubbing out

• 어떻게 한다는건지 잘 모르겠음. 사실 쓸 일도 없을거라 예상..! 나중에 실제로 필요해지면 제대로 알아보는 걸로...

탭 사용

• 네트워크 탭은 두 지점 사이에 배치해서 두 지점 사이의 패킷을 캡처할 수 있도록 하는 장치라고 함.

ARP cache poisoning

• ARP 동작 방식 ARP는 같은 네트워크에서 한 컴퓨터가 다른 컴퓨터와 통신하기 원할 때 시작된다고 함. ARP 캐시(테이블)를 검색해 IP주소와 연관된 MAC 주소가 있는지 찾음. 없으면 브로드캐스트 주소 ARP 요청을 보냄. 해당 IP주소를 가진 컴퓨터는 ARP에 응답하여 MAC 주소를 회신하고, 아닌 컴퓨터들은 무시한다고 함.

• ARP cache poisoning 동작 방법 ARP spoofing이라고도 불림. 스위치에 연결된 네트워크에 회선을 태핑하는 방법이라고 함...

• Cain & Abel 툴 사용? ARP 캐시 포이즈닝 공격 시도할 수 있는 보안 툴이라고 함.

라우팅 환경에서 스니핑

• 스위치 환경에서 이용 가능한 모든 기술은 라우팅 환경에서도 적용할 수 있다고 함.

질문들

• 패킷 스니퍼를 물리적으로 어디에 설치한다는게 무슨 말인지? -> 실제로 하드웨어적으로 패킷 스니핑 장치를 연결하는 건가? 그럼 직접 못해보는데...

• 네트워크 인터페이스 카드(NIC)에 대해 자세히 모름. 네트워크 카드랑 똑같은건가? 어떻게 생겼는지, 구체적으로 어떤 역할을 하는지..

• 허브가 설치돼 있는 네트워크에서 스니핑하는 게 왜 패킷 분석가의 꿈일까? -> 허브는 브로드캐스팅하니까. 허브의 빈 포트에 패킷 스니퍼를 연결하면 허브에 연결된 모든 컴퓨터의 트래픽을 분석할 수 있지.

• 포트 미러링, 허빙 아웃, 탭 사용, ARP 캐시 포이즈닝이 뭔지 모름.

• IP 주소(계층 3)를 이용해 MAC 주소(계층 2)를 알아내는 원리 까먹음. -> 계층 2의 ARP 프로토콜을 이용해 수행됨.

• 스위치에 연결된 네트워크에 회선을 태핑한다는게 무슨 말??

개요

• 네트워크 문제를 잘 이해하려면 패킷 레벨을 잘 알아야 한다고 함. 모든 네트워크 문제는 패킷 레벨에서 일어나기 때문. 패킷 레벨은 아무것도 숨기지 않기 때문에 암호화된 것 외에 비밀은 없다고 함.

패킷 분석

패킷 스니퍼

• 패킷 분석은 일반적으로 패킷 스니퍼로 수행된다고 함. 네트워크 데이터를 캡처하는데 패킷 스니퍼를 사용한다고 함. tcpdump, wireshark 등의 도구가 있다.

패킷 스니퍼 동작 방식

1. 수집 원시 2진 데이터를 수집한다고 함. 네트워크 카드는 주소가 지정여부와 상관없이? 모든 트래픽을 수신할 수 있다고 함..

2. 변환 캡처된 2진 데이터를 읽을 수 있는 형식?으로 변환

3. 분석 캡처되고 변환된 데이터를 분석..

컴퓨터 통신

protocol

TCP, IP, ARP, DHCP 같은 의사소통 규약들을 의미. 프로토콜은 연결 초기 설정, 연결 협상, 데이터 형식, 오류 감지 및 수정, 연결 종료 문제들을 해결한다고 함.

OSI 7계층 모델

프로토콜은 OSI 참조 모델을 기반으로 기능?에 따라 분리된다고 함.

• application

• presentation 데이터의 인코딩, 디코딩

• session

• transport 신뢰성

• network 호스트의 논리적 주소인 IP주소로 데이터 라우팅.

• datalink 물리적 장치(mac주소) 식별. bridge, switch

• physical 물리적 매체

OSI 모델을 통한 데이터 흐름

• 응용 ~ 물리 계층으로 내려갔다가 물리~응용 계층으로 올라가는 흐름.
• 각 계층은 인접한 계층과만 통신한다
• 각 게층에서 제공하는 프로토콜 서비스는 상호 의존적이지 않다고 함..

데이터 캡슐화

• 서로 다른 계층에 있는 프로토콜은 데이터를 캡슐화해서 전달한다.
• bit, frame, packet, segment, data

네트워크 하드웨어

• 허브 물리 계층에서 동작하는 중계 장치. 허브는 패킷을 받아 허브에 연결된 모든 컴퓨터로 전송. (브로드캐스팅) 전송된 패킷을 수락하거나 거부하는건 수신 장치에 달려 있다고 함. 수신측은 패킷의 이더넷 헤더의 MAC 주소를 검사해 해당 패킷이 자신의 것인지 판단한다고 함. 요즘엔 허브 대신 스위치가 사용된다고 함.

• 스위치 고밀도? 네트워크에서 허브의 가장 좋은 대안이라고 함. 허브와 마찬가지로 패킷을 전송. 허브와 달리 지정한 컴퓨터에게만 패킷을 보낸다. 스위치는 mac주소 기반으로 장치 식별함. 즉, 데이터링크 계층에서 동작함.( = 같은 네트워크 내의 통신) 패킷을 전송할 포트를 결정하기 위해 테이블에 (맥주소, 포트)를 저장해둔다고 함.

• 라우터 네트워크 계층에서 동작. 패킷을 다른 네트워크로 라우팅.(다른 네트워크 = 다른 LAN?)

트래픽 분류

• 네트워크 트래픽은 브로드캐스트, 멀티캐스트, 유니캐스트 3가지로 분류한다고 함.

broadcast

• 브로드캐스트 패킷은 네트워크 세그먼트의 모든 포트로 전송되는 패킷이라고 함.
• 데이터링크 계층에서 ff:ff:ff:ff:ff:ff인 MAC 주소가 브로드캐스트 주소.
• 브로드캐스트 도메인 브로드캐스트 패킷이 이동할 수 있는 범위 (라우터를 거치지 않고)

multicast

• 단일 발신지에서 여러 목적지로 동시에 패킷을 전송하는 수단.
• 멀티캐스팅의 목적은 가능한 적은 대역폭을 사용하는 것이다??

unicast

• 한 컴퓨터에서 다른 컴퓨터로 직접 전송.

질문들

• 패킷 분석으로 네트워크 특성, 네트워크 사용자, 사용 피크타임, 안전하지 않은 애플리케이션 어떻게 알아냄?

• OSI 약자 Open Systems Interconnection Reference Model. ISO에서 권장하는 표준일 뿐 프로토콜 개발자가 꼭 따라야하는건 아니라고 함. TCP/IP 모델이 더 선호된다고 함.

• OSI가 기능에 따라 분리된다는 게 정확히 어떤 의미?

• application 계층이 최종 사용자가 볼 수 있는 유일한 계층?

• presentation 계층에서 데이터의 인코딩, 디코딩이 정확히 뭔지

• bridge, switch가 정확히 뭐하는거더라?

• half-duplex(반이중) mode이 뭐더라

• MAC 주소 (Media Access Control address) 무슨 의미인지 정확히 모름 하드웨어 생산 시점?에 정해진다는 건 아는데 왜 저런 명칭으로 불리는지..

• 서브넷 마스크가 정확히 뭐더라.. 네트워크 범위 결정짓는거였던거 같은데

• 애플리케이션이 해야 할 일을 작업(task)라는 단위로 분할하면 프로그램의 구조를 간결하게 잡을 수 있다고 함. 다음과 같은 장점이 있다고 함.
  • 프로그램의 구조를 간결하게?
  • 트랜잭션의 범위를 지정하여 오류에 효과적으로 대응 가능
  • 작업 실행 부분의 병렬성 극대화

스레드에서 작업 실행

• 작업의 범위, 작업 실행 정책을 잘? 설정해야 함..

작업을 실행하는 방법

1. 기장 기본적인 방법 작업을 단일 스레드에서 순차적으로 실행하기. 서버-클라이언트 구조에서 요청 처리 과정은 I/O 작업이 큰 부분을 차지. 만약 서버 애플리케이션이 단일 스레드에서 동작하면, I/O 작업때문에 다른 요청을 전혀 처리하지 못하게 됨.

2. 작업마다 스레드를 생성하는 방법 요청이 들어올 때 마다 새로운 스레드를 하나씩 만들어 실행시키면 응답 속도를 더 높일 수 있음. 이렇게하면 요청을 병렬로, 동시에 처리 가능. 동시에 스레드 안전성을 확보해야 함.

스레드를 많이 생성할 때의 문제점

• 작업마다 스레드를 매번 생성하는 정책은 상용 서비스에서 사용하기에는 무리가 있다고 함.

1. 스레드 라이프 사이클 문제 스레드 생성, 제거 작업에도 자원이 소모된다고 함.. -> delay

2. idle 상태에 있는 스레드가 많아질수록 많은 메모리를 필요로 함. JVM GC 부하가 늘어나고, CPU를 사용하기 위해 여러 스레드가 경쟁하는 상황이 되어서 많은 컨텍스트 스위칭 비용도 발생하게 됨.

3. OutOfMemoryError 발생 가능성 자원이 고갈되어 프로그램이 멈추는 경우가 발생하지 않는지 꼭 테스트해야 한다고 함!! 요청마다 스레드를 만들면, 요청 엄청 많아져서 자원 고갈시켜 OutOfMemoryError 발생 가능하다는 거임

Executor 프레임워크?

• 작업(task)는 논리적인 업무? 단위, 스레드는 특정 작업을 비동기로 동작시킬 수 있는 방법.

• java.util.concurrent 패키지의 Executor 인터페이스에 스레드풀들이 제공됨.

실행 정책

thread pool

• 스레드풀은 풀 내의 스레드로 처리할 작업을 쌓아둬야 해서 작업 큐와 밀접한 관련이 있다고 함.
• 풀 내부의 스레드를 사용해 작업을 실행하는 방식은, 매번 스레드를 새로 만드는 것보다 많은 장점이 있다고 함!
  • 자원 절약
  • 스레드가 이미 만들어져 대기하고 있어 딜레이 감소
  • 스레드 풀의 크기를 적절히 설정하면 프로세서 활용도 증가하면서도 스레드를 매번 생성할 때와 달리, 스레드 간에 한정된 자원을 두고 경쟁하는 것도 완화될 것.

Executor 동작 주기?

• Executor를 제대로 종료시키지 않으면 JVM 종료가 안되기도 한다고 함.. 종료 방식은 graceful / abrupt등 여러가지가 있다고 함.

• ExecutorService의 상태는 running, shutting down, terminated 3가지 상태가 있다고 함

• 실행 거절 핸들러(rejected execution handler) 이미 종료 절차가 시작되거나 종료된 이후에 새로운 작업을 등록하려 하면 실행 거절 핸들러를 통해 오류로 처리한다고 함.

지연 작업, 주기적 작업

병렬로 처리할만한 작업

• I/O bound task ex) 이미지 다운로드, DB 쿼리 등 네트워크 타는거..

• Callable, Future 사용 가능하다고 함..

질문들

• thread life cycle?

• single thread executor는 작업을 처리하는 스레드가 1개뿐이라는데.. 안좋은거 아님? 이게 효율적임?

• newCachedThreadPool은 왜 이름에 캐시가 들어가있는거?

• Timer 클래스 vs ScheduleThreadPoolExecutor 클래스

• Callable 인터페이스..?

• 표현 영역과 응용 영역은 도메인과 사용자를 연결해 주는 매개체
• 응용 영역은 표현 영역에 의존하지 않음. (ex. 응용 영역은 사용자가 브라우저를 사용하는지, REST API를 호출하는지, TCP 소켓을 사용하는지 알 필요가 없고 사용자가 요청한 기능 실행과 실행 결과 반환에 집중.)

응용 서비스의 역할

• 사용자의 요청을 처리하기 위해 도메인 객체를 가져와 사용.

  도메인 로직은 응용 서비스가 구현하면 안 되고 도메인 객체가 구현. 그 이유는..

  • 코드 응집성
  • 코드 중복 방지 (ex. Member 암호 확인 기능을 Member가 구현) 서비스는 구현된 기능을 사용만!!

• 응용 서비스는 실행 흐름 제어, 트랜잭션 처리 담당

  도메인객체_흐름_제어(request){
    1. 레포지토리에서 애그리거트 가져오기
    2. 애그리거트가 도메인 기능 실행
    3. 결과 반환
  }

  애그리거트_생성(request){
    1. 데이터 유효성 검사
    2. 애그리거트 생성
    3. 레포지토리에 애그리거트 저장
    4. 결과 반환 
  }

응용 서비스의 구현

• 응용 서비스가 표현 영역에 의존하지 않도록 주의

값 검증

• 표현 영역: 필수 값, 값의 형식 검증
• 응용 영역: 논리적 오류 검증 (또는 모든 검증을 응용 영역에서 수행)

개요

• 여러 스레드가 특정 객체를 동시에 사용하려고 할 때, 안전하게 동작하도록 객체를 공유하고 공개?하는 방법

(메모리) 가시성

• 가시성이라는게 쓰기는 아니고 읽기에 관련된 내용인거고, 읽기 동기화라고 불러도 될듯.

• 메모리상의 공유된 변수를 여러 스레드에서 사용할 수 있게 하려면 반드시 동기화 기능을 구현해야 한다고 함 (만약 읽기만 하면 동기화 안해도 되겠지?)

• 코드 재배치 메모리 상의 변수를 대상으로 작성해둔 코드가 '반드시 이런 순서로 동작할 것이다'라고 단정지을 수 없다고 함... 그래서 여러 스레드가 사용하는 변수는 항상 적절한 동기화 기법을 적용해야 한다고 함..

stale data

• 최신값이 아닌 데이터(유통기한이 지난)

64비트 변수

• 64비트를 사용하는 숫자형(double, long)에 volatile 키워드를 사용하지 않은 경우에 이상한 값이 생길 가능성이 있다..? volatile로 지정되지 않은 64비트 값에 대해서는 메모리에 쓰거나 읽을 때 2번의 32비트 연산을 사용할 수 있도록 허용하고 있다고 함. 그래서 64비트 변수의 값을 쓰는 기능과 읽는 기능이 서로 다른 스레드에서 동작하면, stale data를 읽어올 가능성이 생긴다고 함...

락과 가시성

• 동일한 락 사용.

volatile 변수

• 약한? 동기화 기능을 제공해주는거라고 함. volatile로 선언된 변수의 값을 바꿨을 때, 다른 스레드에서 항상 최신의 값을 읽어갈 수 있도록 보장해준다고 함. 프로세서, 프로세서 외부에 캐시되지 않는다고 함.

  volatile boolean asleep;
  ...
  while(!asleep){
      countSheeps();
  }

• 정리하면 연산의 단일성은 보장하지 못하고, 가시성만 보장한다.

객체의 공개와 유출

• 공개(published)

  
  public static final String SAMPLE  = "sample string";
  
  public String getString(){ return SAMPLE;}

• 유출(escaped) 의도적으로 공개하지 않았는데 외부에서 사용할 수 있게 공개된 경우를 유출 상태라고 함...

• 생성자 안전성...

스레드 한정

• thread confine.

• 특정 객체가 단일 스레드에서만 사용된다고 확신할 수 있으면 동기화가 필요 없음

• 스택 한정 기법 primitive 타입의 로컬 변수를 이용하여 스레드 한정 객체형 로컬 변수는 외부로 공개될 때 문제가 생길 수 있음

• ThreadLocal 스레드 한정을 도와주는 방법 중 하나.. 실제 구현이 아닌 개념적으로는 ThreadLocal는 Map<Thread,T>같은 구조라고 함.

• static으로 선언된 ThreadLocal에 스레드 단위로 트랜잭션 컨텍스트를 넣어두면 편리하다고 하는데..* 안 해봐서 공감 안 됨....

불변성

• 불변 객체도 동기화 안해도 멀티 스레드에서 안전하게 사용 가능. 객체의 상태가 변하는게 문제인데, 불변 객체는 안 변하니까.

• 객체가 불변이라는 것과 참조가 불변이라는 것은 구분해야 함

객체를 안전하게 공개하기

...

질문들

• 소스코드의 특정 블록을 동기화시키려고 하면 메모리 가시성(memory visibility) 문제가 발생? 메모리 가시성 문제가 정확히 뭐지? 소스코드랑 뭔 상관?

• 코드 재배치의 경우... 컴파일러나 프로세서, JVM 등이 코드가 실행하는 순서를 바꾼다는데... 실제 예제 좀 보고 싶다.. 진짜 내가 작성했던 코드 중에도 그런게 있었을까..?

• volatile 적용해야 할 때를 알아채기 힘들듯.

• 생성자 안전성 잘 이해안됨

• ThreadLocal, 관련된 멀티스레드 관련 코드 작성해보기

• ThreadLocal이 재사용성을 떨어뜨리는 이유는?

• c++에서 const와 java에서 final의 차이

• 초기화 안전성?

• 객체의 생성메서드가 제대로 완료되지 않은 상태라는게... 예를 들어 예외가 발생해서 제대로 완료되지 않은 경우를 말하는건가?

• 그런듯..

개요

• 병렬 프로그램이 단순히 스레드와 lock만 신경써서 될 일은 아니라고 함 멀티 스레드에 안전한 코드는 변경 가능한 공유 상태에 대한 접근을 관리하는 것. (shared, mutable data)

• 스레드 안전성은 데이터에 제어없이 동시에 접근하는 걸 막으려는 의미라고 함.

• 키워드는 멀티스레드, 공유된 상태, 단일 연산 정도로 볼 수 있을듯.

thread safety

• 여러 스레드가 객체에 접근할 때 계속 의도한대로 정확하게 동작하면 스레드 안전하다고 함

상태없는 서블릿

• 상태없는 서블릿(다른 클래스를 참조하지도 않고, 전역변수도 없는)은 기껏해야 지역변수만 사용. 지역변수는 스레드의 스택에 저장되고, 다른 스레드가 접근할 수 없음!! 그래서 상태없는 객체는 항상 thread safe하다!!

  @ThreadSafe
  public class StatelessServlet implements Servlet{
    public void service(ServletRequest req, ServletResponse res){
        ...
    }
  }

상태가 있는 서블릿

@NotThreadSafe
public class UnsafeCountingServlet implements Servlet{
    private long count;

    public void service(ServletRequest req, ServletResponse res){
        ...
        count++;
        ...
    }
}

위 코드는 thread safe하지 않다는데... 흠....... 나도 비슷한 상황을 겪었는데 그 때 상황은 JPA 엔티티에 count 변수가 있었고, count 변수값을 변경하는 메서드를 따로 동기화 해주지는 않았음. 그 때랑 이 코드는 다른 상황인가..? 이 코드는 여러 스레드가 확실히 동시에 접근할 수 있음. 근데 JPA 엔티티의 count 필드 변경 함수는 1개의 http request에 의해 실행되는 것. 그래서 여러 스레드가 접근하거나 하지는 않는듯. 다른 상황이네.

race condition

• check and act 유효하지 않은 값을 참조해서 다음에 뭘할지 결정 lazy initialization이 대표적인 check and act.

• read modify write 이전 상태를 기준으로 객체를 변경( check and act랑 비슷한 말 같은데..)

• 경쟁 조건을 피하려면 변수가 변경되는 동안, 다른 스레드가 해당 변수를 사용하지 못하도록 막아야 함.

lock

• 단일 연산 변수(AtomicInteger, AtomicReference<> 같은거)로는 여러 상태값의 동기화를 보장하지 못해서 lock으로 단일 연산으로 만들어줘야 함. 여러 동작을 단일 연산으로 만드는거니까 트랜잭션의 atomic한 성질이랑 좀 비슷한 느낌이네.

• 암묵적인 락(모니터 락) 자바는 synchronized 구문으로 락을 제공. 스레드가 synchronized 블록에 들어가기 전에 자동으로 확보되며, 해당 블록을 벗어날 때 해제됨. 상호배제 방식(mutual exclusive)으로 동작한다고 함.

• reentrant(재진입성) 암묵적인 락은 재진입 가능하다고 함. (이미 락을 획득한 스레드가 다시 락을 확보할 수 있는거라고 함...) 부모 클래스의 메서드를 오버라이드하고 두 메서드에 모두 synchronized가 붙어있을 때, 재진입성이 없으면 데드락에 빠진다고 함..

lock으로 상태 보호하기

• 락은 공유된 상태에 여러 스레드가 순차적으로 접근하도록 해서 일관된 상태를 유지할 수 있도록 해줌.

• 하나의 락으로 동기화해야 한다?

활동성과 성능

• 용어

  • 안전성: 잘못된 일이 생기지 않는다
  • 활동성: 원하는 일이 결국 일어난다?
  • 성능: 원하는 일이 빨리 일어나는 정도

• synchronized 블록의 범위를 줄이면 스레드 안전성을 유지하면서 쉽게 동시성(성능)을 향상 가능.

• 락을 얻고 해제하는 것도 부하가 꽤 된다고 함. 그래서 synchronized 블록을 너무 잘게 쪼개는 것도 좋지 않다고 함...

Questions

• 운영체제 책에서 나왔던 모니터락, 세마포어, 뮤텍스 등등 조금 까먹었음..

동시 작업에 대한 역사

• 운영체제는 여러 프로그램을 각자의 프로세스 내에서 동시에 실행할 수 있도록 발전했다. 프로세스마다 자원을 할당하기 때문이다.

• 프로세스 개념은 자원 활용, 자원의 공정한 공유, 편의성? 측면을 고려하다 보니 만들어졌다. 스레드도 같은 이유로 고안됐다고 함..

• 스레드 덕분에 한 프로세스 안에 여러 프로그램 제어 흐름이 공존할 수 있게 되었다. 스레드는 프로세스에 할당된 자원(메모리 공간)을 공유함. 그래서 한 프로세스 내의 모든 스레드는 같은 변수에 접근하고, 같은 heap에 객체를 할당함...

스레드의 이점

• 스레드를 잘 쓰면 비동기적인 흐름을 순차적인 느낌으로 바꿀 수 있다..?

• 서버 애플리케이션에서 자원 활용도와 처리율을 높이는 데 유용하다고 함..!

• 프로세서 스케줄링의 기본 단위는 스레드이다..? 그래서 스레드가 여러 개인 프로그램은 여러 프로세서에서 동시에 실행될 수 있어서 효율적임.

• 여러 스레드를 사용하면 프로세서가 하나라도 처리 속도를 높일 수 있다??? 예를 들어 blocking I/O 때문에 CPU가 놀 때 다른 스레드를 실행하면 되니까..!

스레드 사용의 위험성

• 안전성 vs 활동성 vs 성능

• 스레드가 많은 프로그램은 컨텍스트 스위칭이 더 빈번하고, 상당한 부담이 된다고 함. 실행중인 컨텍스트를 저장하고 다시 읽어오면서 메모리 지역성이 손실되고, cpu 시간을 스케줄링에 소모하게 됨. 스레드 동기화는 컴파일러 최적화를 방해하고, 메모리 캐시를 지우기도 한다고 함...! 컨텍스트 스위칭이 성능에 어느정도나 영향을 주는지는 감 없음...

Questions

• 스레드는 복잡한 비동기 코드를 더 단순한 순차적 코드로 바꿔 복잡한 시스템을 단순하게 개발할 수 있게 해준다고 함...

• 그런가..? 복잡한 비동기 코드는 뭔데?

• 스레드는 멀티프로세서 시스템의 능력을 최대한 끌어낼 수 있는 가장 쉬운 방법이라고 함...

• 그렇겠지.. 그런가..?

• event loop vs event dispatch thread

• object finalization

• RMI (Remote Method Invocation) 다른 JVM에서 실행 중인 객체의 메서드를 호출할 수 있게 해주는 건데.. head first design pattern 책에서 proxy 패턴 소개할 때도 나왔던 건데 잘 모름. marshal/ unmarshal도...

여러 애그리거트가 필요한 기능

• 한 애그러거트로 기능을 구현할 수 없을 때, 계산의 주체는 어떤 애그리거트인지에 대한 문제
  • 예시) 결제 금액 계산 로직 -> 상품, 주문, 할인 쿠폰, 회원
  • 한 애그리거트에 넣기 모호한 도메인 기능을 특정 애그리거트에 구현하면 안 된다고 함 자신의 책임 범위를 넘어가기 때문이라고 함 도메인 기능을 별도 서비스로 구현하는 방식으로 해결할 수 있다고 함..

도메인 서비스

• 도메인 서비스는 도메인 영역에 위치한 도메인 로직을 표현할 때 사용한다고 함.. 응용 서비스가 응용 로직?을 다룬ㅏ고 하면 도메인 서비스는 도메인 로직을 다룸. 주로 다음과 같은 상황에 사용된다고 함

  1. 계산 로직. 여러 애그리거트가 필요한 로직, 한 애그리거트에 구현하기에는 복잡한? 로직. 도메인 서비스를 사용하는 주체는 애그리거트가 될 수도 있고, 응용 서비스가 될 수도 있다고 함

  2. 외부 시스템 연동이 필요한 도메인 로직 현재 시스템 A가 외부 시스템 B와 연동할 때 인터페이스는 연동한다는 관점으로 작성하지 않고, A의 도메인 로직 관점에서 작성한다!! DIP 적용할 때, infra 기준으로 인터페이스 만드는게 아니라 도메인 기준으로 만들었던 것과 동일한 개념인듯?

• 패키지는 도메인 영역에 위치.. 도메인 로직을 표현하기 때문이라고 함

의문점

• 도메인 기능을 별도 서비스로 구현하는 방식이 어떤 모습인지 모르겠음
• 한 애그리거트에 구현하기에는 복잡한 로직이 어떤걸까
• 외부 시스템 연동이 필요한 도메인 로직은 어떤 것이 있을까? -> 주문 취소하면 결제도 취소해야하는데 결제 취소는 외부 서비스 주로 사용한다고 함

• 테스트하기 쉬워진다라는 말을 체감하지 못함. 테스트 코드는 언제 꼭 필요할까?

개요

• EDM은 특정한 경계 컨텍스트를 구현하기 위해 개발한 작은 애플리케이션이라고 함.

• consumer microservice

  • 입력 이벤트 스트림으로부터 이벤트를 소비/처리

• producer microservice

  • 이벤트 스트림에 이벤트를 생산

• 이벤트 브로커는 이벤트 스트림을 제공한다고 함..

• EDM은 이벤트 브로커에 이벤트를 생산/소비하는 공통 기능을 공유하며 비동기로 통신하다고 함...

토폴로지

마이크로서비스 토폴로지

• 마이크로서비스가 이벤트를 받아들이고, 처리, 출력하는 구성을 의미

• 변환, 저장, 방출등을 data driven operation이라고 함..

비즈니스 토폴로지

• 비즈니스 로직을 처리하는 (마이크로서비스, 이벤트 스트림, API)의 집합이라고 함 즉, 서비스 사이의 관계에 대한 토폴로지

이벤트의 내용

• 비즈니스와 관련된 모든 것은 이벤트가 될 수 있다고 함..
• 이벤트는 발생한 사건의 recording이라고 함.. 로그와의 차이는 이벤트는 single source of truth라고 함.

이벤트 구조

• 이벤트는 주로 (key,value) 형식으로 표현한다고 함

unkeyed event

• 하나의 사실을 진술한 형태로 나타낸 이벤트? 예) 고객이 상품을 클릭했다는 사실을 이벤트로 표현할 수 있다고 함... key,value 쌍이 (-, 상품 번호)로 키가 없는 이벤트로 표현할 수 있다고 함.

entity event

• entity는 식별자가 있는 유일한 것
• entity 이벤트는 어느 시점의 엔티티 상태값들을 기술한다고 함 예) (상품 id, 상품)

keyed event

• key가 있는 이벤트이지만 entity를 나타내는건 아닌 이벤트라고 함.. 예) (상품 id, 상품 스트림?)

• entity event가 특정 시점의 엔티티 상태라면 keyed event는 여러 시점에서의 엔티티 상태들을 value로 가진다고 보면 되나..?

table stream duality

• 엔티티 이벤트 스트림에서 흘러온 엔티티 이벤트를 순서대로 적용하면 stateful table(상태 저장 테이블)을 구체화할 수 있다..??

• 테이블-스트림 이원성..?(table stream duality) 이벤트들이 upsert되어 상태 테이블을 이루거나, 반대로 각 업데이트들을 이벤트 스트림에 발행하여 테이블을 엔티티 이벤트의 스트림으로 바꿀 수도 있다는 것을 의미..

• 붙임 전용(append only) 파일? mysql binlog가 예시라는데, binlog는 모든 데이터 변경에 대한 로그임. docs / mysql binary log overview append only라는게 replication 위한 거고, 현재 존재하는 데이터를 변경없이 그대로 append하게 해주는 속성을 말하는듯. 그래서 붙임 전용 불변 로그라고도 부르는 듯

• 키 있는 이벤트는 툼스톤 이벤트(값이 null인데 key는 있는 이벤트)로 삭제한다고 함...

• 붙임 전용 불변 로그는 compaction이 필요하다고 함.. compaction은 이벤트 브로커가 내부 로그 크기를 줄이려고 key별로 가장 최근 이벤트 하나만 보관하는 거라고 함.. (compaction도 tradeoff가 있음을 추측 가능.)

이벤트 데이터 스키마

• consumer가 producer에게 따로 물어보지 않고 이벤트 컨텐츠와 의미를 해석할 수 있다면 이상적이라고 함.. 구글 프로토콜 버퍼같은 스키마 기술..?이 EDM에서 많인 쓰이는 2가지 기능을 제공한다는데... 스키마 변경, 스키마화한 데이터를 객체로 변환하는 부분을 도와준다고 함...

이벤트 브로커

• 이벤트 브로커의 역할은 이벤트를 받아서 queue 또는 이벤트 스트림에 저장하고, 다른 프로세스가 이것을 소비할 수 있도록 제공하는거라고 함..

• scalability, durability, high availability, high performance 특징이 필요하다고 함.

• 이벤트 보관과 처리에 관련된 여러 요건들이 있음.. 근데 하나도 안 와 닿아서 일단 스킵

추가 고려 사항

이것도 안 와닿아서 일단 스킵

이벤트 브로커 vs 메세지 브로커

• 이벤트 브로커는 메세지 브로커 대신 쓸 수 있지만, 메세지 브로커는 이벤트 브로커 기능을 완전히 대체할 수 없다고 함...

• 메세지 브로커 발행/구독 메세지 큐를 이용. producer가 큐에 메세지를 쓰면 consumer는 메세지를 받아 소비하고 ACK를 보냄. ACK 신호가 확인되면 메세지는 삭제됨

• 이벤트 브로커 순서대로 쌓은 로그를 제공할 목적으로 설계되었다고 함. 메세지 브로커와 달리 여러 컨슈머가 이벤트에 마음껏 접근 가능하다고 함. 파티션된 이벤트 스트림이라는거 때문에 가능한듯. (메세지 브로커는 큐 단위로만 처리되어 한 이벤트는 한 컨슈머만 소비가능하다고 함)

  그리고 이벤트 브로커에서는 이벤트를 소비해도 이벤트가 보존됨.

• 컨슈머는 이벤트 스트림이나 큐로 이벤트를 소비한다고 함..

• 이벤트 브로커는 서비스가 데이터를 생산,소비하는 유일한 장소가 된다고 함..

• 이벤트 브로커가 single source of truth이 되면, 개발이 편해진다고 함..

대규모 마이크로서비스 관리

• 마이크로서비스는 수가 많아지면 관리하기 어려워진다고 함

• 마이크로서비스를 소유한 팀별로 관리/배포할 수 있어야 한다고 함

• 도커같은 컨테이너 기술로 애플리케이션 격리시키고, 쿠버네티스 같은 컨테이너 관리 소프트웨어로 관리하면 됨.

비용

• 비용문제도 사소한 문제가 아니라고 함

의문점

• 경계 컨텍스트 개념이 그리 와닿지 않음

• 이벤트를 소비한다는게 구체적으로 어떤 동작을 하는건지 모름

• 이벤트 스트림에 이벤트를 생산한다는게 어떤 동작을 하는건지 모름

• 이벤트 브로커가 어떻게 생겼는지 모름

• keyed event는 이벤트 스트림의 한 파티션 내에서 data locality를 보장하기 위해 이벤트 스트림을 파티셔닝하는 용도로 쓰인다는데.. 무슨 말인지 모름

• table stream duality에서 테이블을 이벤트 스트림으로 만든다는게, 구체적으로는 SQL 쿼리들 모아놓은걸 이벤트 스트림으로 만드는거 아님?

• 구글 프로토콜 버퍼가 뭐하는 것이고, 왜 쓰는지 모름

• 컨슈머가 이벤트를 소비하는 방법(이벤트 스트림 또는 큐) 이해 안 됨