WSL2는 현재 컴퓨터 구성에서 지원되지 않습니다. "가상 머신 플랫폼" 선택적 구성 요소를 사용하도록 설정하고 BIOS에서 가상화가 사용하도록 설정되어 있는지 확인하세요. 실행하여 "가상 머신 플랫폼"을 사용하도록 설정: wsl.exe --install --no-distribution error code: wsl/service/createinstance/createvm/hcs/hcs_e_hyperv_not_installed

그래서 일반적으로 WSL을 설치시의 조건을 확인해서 뭔가 빠트린게 있나 확인해보았습니다.

1. Windows 기능 켜기/끄기 -> Linux용 Windows 하위 시스템 선택확인

(또는 cmd 관리자에서 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 명령어 )

2. BIOS CPU 가상화 기능켜기

를 해보았는데도 여전히 설치 오류가 났습니다.

그래서 그나마 이전 Docker 컨테이너를 다 이미지로 커밋해놓았기 때문에 WSL Ubuntu를 다시 설치해야겠다고 생각했습니다.

WSL Ubuntu20.04 설치

1. PowerShell을 열고 다음과 같은 명령어를 쳐 설치된 배포판을 확인

2. 다음 명령어를 실행하여 배포판을 제거

   wsl --unregister

   3. 제거를 완료하고 다음 명령어를 실행해 WSL을 다시 시작합니다.

      wsl --shutdown

   4. 다음 명령어를 쳐서 Ubuntu20.04를 설치합니다.

      wsl –install -d Ubuntu20.04

Docker WSL에서 사용하기

먼저 docker desktop을 설치합니다.

이후에, docker desktop의 setting에 들어간 후,

다음과 같이 설정을 완료합니다.

그리고 docker ps 명령어를 치니 다음과 같은 오류가 떴습니다.

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Head "http://%2Fvar%2Frun%2Fdocker.sock/_ping": dial unix /var/run/docker.sock: connect: permission denied

그래서 usermod로 사용자를 docker 그룹에 추가까지 완료 후 터미널 재접속까지 했으나 permission denied 또 발생하였습니다.

따라서 /var/run/docker.sock 파일의 권한을 666으로 변경하여 그룹 내 다른 사용자도 접근 가능하게 변경하였더니 위와 같이 docker명령어가 잘 실행됨을 알 수 있었습니다.

Cassandra 로그분석을 하던 중,

Writing Memtable-local@974563919(0.342KiB serialized bytes, 2 ops, 0%/0% of on/off-heap limit), flushed range = (null, null]

위와 같은 로그가 있었다. 여기서 Memtable은 메모리에 있는 테이블이고 974563919는 메모리 테이블의 식별자일 것이다.

위 로그를 한 번 뜯어보자

Memtable

Memtable은 각 Cassandra 테이블에 대해 생성된 메모리 내 캐시이다. 캐시이니 최근에 읽거나 수정한 데이터가 포함되어 있다. 따라서 노드에서 테이블의 데이터를 읽을 때마다 먼저 Memtable에 최신 데이터가 있는 지 확인한다. 최신 데이터가 없다면디스크에서 데이터를 읽고 MemTable에 캐시한다. 최대 크기, 시간 제한, 업데이트 수 등 정의된 기준이 충족되면 디스크에 flush된다.

On-heap

on-heap은 일반적으로 자바 어플리케이션에서 객체를 생성하면 저장되는 메모리 영역(Java Heap)이다. GC(Garbage collector)가 관리하는 영역이기도 하며, 따라서 객체의 생성, 소멸 또한 유저가 관여를 하지 않아도 된다. 하지만 GC작업을 하는 중에는 이른바 Stop the world로 GC 쓰레드를 제외한 다른 쓰레드는 실행 중지가 되며 메모리의 큰 객체를 처리 중에는 상당히 어플리케이션 성능 저하가 심하다.

Off-heap

Cassandra 2.1부터 offheap 메모리를 memtable에 사용할 수 있다. off-heap는 Heap 바깥의 (즉, GC의 관리하에 있지않다) serialized objects가 저장되는 메모리 영역이다. GC가 관리하지 않는 대신 유저가 라이브러리를 통해서 관리할 수 있다. 유저가 관리하기에 GC의 Stop the world로 인한 어플맄이션 성능 저하를 방지할 수 있다.

로그분석

따라서 로그 분석을 하면 974563919번 2회 연산된 메모리 캐시 테이블이 0.342KiB 크기의 직렬화된 데이터를 가지고 디스크의 SSTable에 플러시했다는 것이다. 이것이 또한 off heap, on heap 최대치의 0%를 차지한다는 것이다. 즉 크기가 매우 작다는 것. 이때 (null, null]은 특정 범위가 지정되지 않아 전체 범위가 플러시 대상일 수 있다.

출처

https://stackoverflow.com/questions/6091615/difference-between-on-heap-and-off-heap https://avdeo.com/tag/partition-summary/

방대한 로그에서 원인을 찾는 노하우

시각으로 범위를 좁힌다.

장애가 발생했을 시 장애가 발생한 시각 부근의 메시지를 확인하는 것이다. 또한 로그를 확인할 때 시스템 부하를 줄이기 위해 tail이나 head 명령을 사용해 파일의 일부만 출력하는 것도 노하우다. *다음은 리눅스 서버의 시스템 로그 파일에 대해 날짜를 지정해서 추출하는 예이다, *

노이즈 제거하기

장애 발생 시각 즈음에 나타난 모든 메시지가 장애 원인은 아니다. *장애 시각 즈응에 확인한 오류 메시지가 장애 발생 전부터 출력되기 시작해서 장애 발생 후에도 계속해서 출력되고 있다면 노이즈일 가능성이 크다. * 이때는 grep의 -v옵션을 이용해 추출대상에서 노이즈를 제거해준다.

키워드로 범위를 좁힌다.

로그를 확인하는 시점에 장애 원인을 거의 추측할 수 있다면 해당 장애일 때 반드시 출력되는 문자열을 미리 알 수 있다. 이런 경우에는 해당 문자열을 바탕으로 검색하는 것이 가장 빠른 길이다. 예를 들면 아파치 오류에 대해 "server reached MaxClients"로 검색하면 아파치가 MaxClient에 이르렀는지 알 수 있다.

[root@docker-centos httpd]# tail -n 1000 /var/log/httpd/error_log | grep "server reached MaxClients"

오류 문자열

오류가 발생할 때 자주 출력되는 로그 레벨 문자열을 키워드로 사용하는 게 좋다. 이 때 waring은 WARN으로도 쓰일 수 있고 warning으로 쓰일수도 있다. 따라서 검색 시 대소문자를 구별하지 않게 하기 위해 grep의 -i 옵션을 사용할 수 있다.

[root@docker-centos httpd]# tail -n 1000 /var/log/hoge/applications.log | grep -i "warn"

메시지 양을 주목

오류 메시지에는 아무것도 출력되지 않았는데 사이트가 보이지 않거나 메일이 전송되지 않는 등 서비스에 문제가 생기는 경우가 있다. 이런 경우는 요청 대비 시스템의 처리 성능이 뒷받침하지 못하는 것이 원인이다. 시각별로 엑세스 로그를 집계해보자.

[root@docker-centos httpd]# tail -n 10000 access_log | grep "May" | cut -d ':' -f 2,3 | sort | uniq -c

여기서 "cut -d ':' -f 2,3"은 :를 기준으로 2, 3번째 필드를 추출하고 uniq -c는 중복을 카운팅하여 제거해서 출력하라는 것을 뜻한다.

엑세스한 소스 IP 주소별로 집계하면 어떤 IP 주소에서 엑세스가 많았는 지 알 수 있다. 특정 IP 주소의 접속이 극단적으로 많으면 부정 엑세스나 검색 엔진 로봇에 의한 스캔일수도 있다.

[root@docker-centos httpd]# tail -n 10000 access_log | grep "May" | awk '{print $1}' | sort -n | uniq -c | sort

하지만 메시지 양을 비교하는 방법은 신중하게 해야한다. 할인판매 같이 엑세스 양이 무척이나 많은 날일수도 있기에 엑세스가 많은 날인지 고려해서 사용해야한다.

6가지 일반적인 비정상 패턴

키워드

일부 부정 키워드(Ex: "OutOfMemory")가 로그 메시지에 나타나면 이 로그는 비정상

로그 템플릿 수

일부 템플릿의 수는 크게 증가하거나 감소

로그 템플릿 시퀀스

일반적인 정상 패턴에서는 로그 템플릿 시퀀스가 A->B->C로 나타나는데, A->C->B 등 순서가 바뀜을 확인했다면 시스템의 이상을 의심해볼 수 있음.

변수 값

로그의 특정 변수에는 시간비용과 같은 물리적의미가 있으며, 이를 추출하여 시계열 형식의 메트릭으로 집계가 가능하다. 여기서 나온 메트릭에서 이상을 식별할 수 있다.

변수 분포

예를 들어, Nginx 엑세스 로그에는 Ip 주소나 Http상태 코드 정보가 들어있다. 예를 들어, Http 상태코드에서 502에 많이 치우치면 시스템 이상, 특정 IP주소에서의 요청이 급격하게 많다면 보안상 공격을 의심해볼 수 있다.

시간 간격

네트워크 정체 등의 성능문제로 인해 로그 간 시간간격 (timestamp 간격)이 길어질 수 있다. 또한 시간 간격 이상이 템플릿 수 이상의 결과를 초래할 수도 있다.

이상 패턴과 시스템 이상 시나리오

다음은 일반적으로 많이 사용되는 어플리케이션, OS, DB, HW, JVM GC등의 로그파일에서 나올 수 있는 이상 패턴과 시스템 이상 시나리오다.

Application(Application error)

이상 패턴

템플릿 수 변화(ex: "connection refused" 증가), 이전에 없던 로그 패턴(unknown error messages)

이상(사고) 시나리오

System unavailability, application error

Operation System(Linux, Windows, AIX..)

이상 패턴

키워드(ex: "soft lockup", "page allocation failure") 총 로그 수, 템플릿 수 변화(ex: "creatin session" 감소)

이상(사고) 시나리오

Out of Memory, node hang, hardware failures

DataBase(Oracle, DB2, MySQL ..)

이상패턴

키워드(ex: "ORA-", "Level: Error"), 새로운 로그 패턴

이상(사고) 시나리오

DB 서버 다운, 성능 저하, SQL defect

하드웨어(Switch, F5 네트워크 디바이스 등)

이상패턴

키워드(ex: "Illegal state transition", "address conflict detected"), 새로운 로그 패턴, 로그 템플릿 수 변화

이상(사고) 시나리오

IP address 충돌

분산시스템(HDFS, OpenStack)

이상패턴

키워드(ex: "IOException"), 템플릿 시퀀스 이상(wrong order of execution), 새로운 로그 패턴

이상(사고) 시나리오

Task failed, instance failure

Operation(유저 행동)

이상패턴

템플릿 수 변화, 템플릿 시퀀스 이상

이상(사고) 시나리오

Illegal operation, security issue

Middleware(Web server ex: Nginx acess, Apache Access)

이상패턴

변수 분포 이상(ex: "return code, IP address 치중), 총 로그 수 변화

이상(사고) 시나리오

System unavailability, illegal user access, security threat

미들웨어(JVM GC)

이상패턴

키워드(ex: "OutofMemory"), 로그 템플릿 수 변화("FullGC" 수 증가), valiable value(GC time cost 이상)

이상(사고) 시나리오

GC overhead limit exceeded, full heap space, memory leak

미들웨어(메시지 큐 ex: IBM MQ)

이상패턴

키워드(ex: "error occur", "ended abnormally", "exception"), 새로운 로그 패턴, 로그 템플릿 수 변화

이상(사고) 시나리오

message queue stuck

[root@docker-centos httpd]# systemctl restart httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.

다음과 같이 httpd를 시작하려고 하니 에러가 났다.

/var/log/messages 로 로그를 확인해보았더니, 다음과 같은 내용을 확인할 수 있었다.

May 06 23:27:28 docker-centos.example.com systemd[1]: Starting The Apache HTTP Server... May 06 23:27:28 docker-centos.example.com httpd[10936]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 May 06 23:27:28 docker-centos.example.com httpd[10936]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 May 06 23:27:28 docker-centos.example.com httpd[10936]: no listening sockets available, shutting down May 06 23:27:28 docker-centos.example.com httpd[10936]: AH00015: Unable to open logs May 06 23:27:28 docker-centos.example.com systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE May 06 23:27:28 docker-centos.example.com systemd[1]: Failed to start The Apache HTTP Server. May 06 23:27:28 docker-centos.example.com systemd[1]: Unit httpd.service entered failed state. May 06 23:27:28 docker-centos.example.com systemd[1]: httpd.service failed.

address가 이미 사용되고 있었다는 오류였다.

1. 일단 먼저 실행중인 httd 프로세스를 모두 강제 종료 시킨다.

   [root@docker-centos httpd]# ps ax | grep httpd | awk '{print $1}' | xargs kill

2. 그 다음에는 80번 포트 사용하고 있는 pid를 확인한다.

   [root@docker-centos httpd]# netstat -nlp | grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 8572/nginx: master

n은 호스트 이름과 서비스 이름 대신 IP 주소와 포트 번호를 표시하도록 하고, l은 리스닝하고 있는 소켓을 보여준다. -p는 해당 포트를 사용 중인 프로세스의 PID와 프로그램 이름을 표시한다.

3. 그 프로세스를 종료한다.

   kill -9 (프로세스 아이디)

4. httpd 재시작한다. 성공.

배경

출처: https://itwiki.kr/w/%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88_%EA%B0%80%EC%83%81%ED%99%94

전통적인 단일 환경

과거에는 BareMetal의 하나의 시스템에 여러가지 어플리케이션을 운영하다가, 점차 하드웨어 가격이 작아지고, 성능은 좋아지고, 운영해야할 어플리케이션은 많아져 가상화 플랫폼으로 옮겨지게 되었다.

가상화 플랫폼

가상화 플랫폼에서는 Hypervisor위로 가상 운영체제를 설치하고 그 위에 어플리케이션을 올리게 되었다. 그런데 이 가상환경 위에 운영해야하는 어플리케이션이 많아지면서, 이러한 가상환경 플랫폼으로는 한계가 생기게 되었다.

컨테이너 플랫폼

그래서 나타난게 컨테이너 플랫폼이다. 컨테이너로 운영되는 어플리케이션은 용량이 작다. 실제 어플리케이션과 그걸 실행할 수 있는 최소한의 환경만 들어가 있기 때문이다.

그리고 isolated되어있고, 확장성이 좋다.

APP과 그걸 실행하기 위한 라이브러리 또는 NodeJS같은 환경을 컨테이너에 넣는다.

왜 굳이 리눅스에서 돌려야 할까?

*=>리눅스 커널 기능을 써야 하기 때문이다. *

chroot

독립된 공간 형성

namespace:

Isolate 기능 지원: 하나의 컨테이너와 하나의 다른 컨테이너가 완전히 독립될 수 있도록 한다.

cgroup

필요한만큼 HW를 지원해준다.

이 기능들은 모두 리눅스 커널에 있다. 이 리눅스 커널에 있는 기능을 기반으로 해서 컨테이너를 만든다.

windows와 Mac OS는 커널이 없기에 Hypervisor 기능들을 활성화 해야 컨테이너를 돌릴 수 있게 된다.

그냥 프로그램과 컨테이너는 뭐가 다를까?

일반 프로그램: 서버 프로그램인 app.js가 있다. 이것은 nodeJS기반에서 동작하므로 이 서버 프로그램을 실행하기 위해서는 그 전에 먼저 nodeJS를 설치해야한다.

컨테이너: dockerfile을 통해 nodeJS와 app.js를 가지고 컨테이너 빌드한다. 이 컨테이너를 실행하면 자동으로 서버 플로그램을 실행한다.

그래서 왜 쓸까?

*개발자가 만든 그대로 어시서든 돌아간다. 확장/축소가 쉽고, MSA, DEVOPS에 적합하다. *

개발자가 application container를 만들면 A고객사에 제공을 한다. 고객사는 원래 개발자가 어플을 만들 때 사용한 환경과 다르기에 고객사의 환경에서 어플을 돌린거와 결과가 다를 수 있다. 하지만 컨테이너 기반으로 만들어서 제공을 하면 컨테이너를 돌리면 같은 결과가 나온다. 즉, 환경에 구애받지 않는다.

또한, 컨테이너의 용량이 100MB라고 하자. scale-out을 하고 싶으면 그저 컨테이너를 하나 더 설치하면 되는 것이다. 그러면 200MB가 소요되는 것이다. 즉, 확장 축소에 매우 유리하다.

sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

이 명령어를 쳤더니

https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found

이 에러가 떴다. 패키지를 못찾는다는 에러가 떠서 정보를 찾던 중, https://www.inflearn.com/news/1198141 이런 글을 발견했다. 구글에서 해당 repository를 지원하지 않는다는 것이다.

쿠버네티스의 공식홈페이지의 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ 에서 해결법을 찾을 수 있었다. 역시 공식문서의 힘은 대단하다고 생각했다.

공식문서대로 cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/ enabled=1 gpgcheck=1 gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni EOF 로 정보를 kubernetes.repo를 수정했더니 해결되었다.

==== AUTHENTICATING FOR org.freedesktop.systemd1.reload-daemon === Authentication is required to reload the systemd state. Authenticating as: root Password:

라고 systemctl명령어를 쓸 때, 이런 오류가 뜰 때가 있다.

해결법은 간단하다

관리자 전용의 권한이므로 당연히 상위 권한 요구하게 된다. 미리 권한 부여해두던지 안 하면 무조건 비번 묻게 된다. (계정이 서비스 관리 권한을 안 가진한)

sudo --를 사용하던가 root로 접속해서 실행하면 된다.

sed -i.bak -r 's/(.+ swap .+)/#\1/' /etc/fstab

위 명령어를 실행시키면 /etc/fstab에서 swap부분이 있는 줄을 전체 주석처리한다. 주석처리하면 무슨일이 벌어질까?

/etc/fstab

/etc/fstab을 열어보니 다음과 같은 줄이 있었다.

/dev/mapper/centos_k8s-swap swap swap defaults 0 0

/dev/mapper/centos_k8s-swap은 스왑 파티션을 나타내는 장치의 경로이다. swap은 파일 시스템 유형을 나타내며, defaults는 기본 마운트 옵션을 나타낸다. 마지막 두 열은 보통 시스템 백업과 파일 시스템 체크에 사용되는 것으로, 스왑 파티션에는 보통 0이나 비어있는 값이 사용된다.

주석처리하면 어떻게 될까?

위의 /dev/mapper/centos_k8s-swap swap swap defaults 0 0 라인을 주석 처리하면, 시스템이 해당 스왑 파티션을 인식하지 않게 된다. 시스템 부팅할때 스왑 파티션을 마운트하지 않으며, 따라서 *해당 스왑 공간을 사용할 수 없게 된다. *

다만 스왑 파티션은 시스템이 컴퓨터의 메모리를 다 썼을 때, 여분 공간을 만들어서 쓰는 것이므로 이것을 주석처리하면 시스템 메모리 부족 현상에서 문제를 느낄 수 있으니 주의해서 서야한다.

표 출처 : https://blog.naver.com/PostView.nhn?blogId=sdrock&logNo=221508545540

리눅스에 로그인을 하면 자동으로 쉘 스크립트가 실행된다. 이것을 환경설정 쉘스크립트라고 한다. 위의 표는 환경설정 쉘스크립트인데 적용되는 범위가 다르다.

일반적으로 리눅스에 접속을 하면 /etc/profile -> ~./bash_profile -> ~/.bashrc -> 로그인 쉘 프롬프트 순으로 켜진다.

가령 vagrantfile의 설정파일 config.sh에

echo 'alias vi=vim' >> /etc/profile

이라는 내용을 작성해두면 vagrant up으로 프로비저닝 후, 자동으로 위의 alias가 적용되어 있다.

cfg.vm.provision "shell", path: "install_pkg.sh"

쉘의 내용은 다음과 같다.

install_pkg.sh

#!/usr/bin/env bash #install packages yum install epel-release -y yum install vim-enhanced -y

그랬더니

Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"

다음과 같은 에러가 떴다.

문제 분석

mirrorlist.centos.org 서버에 resolve할 수가 없다는 내용이다. 나는 다음의 2개의 문제가 있다고 생각했다.

1. mirrorlist.centos.org 사이트에 문제가 없어 응답을 받아올 수 없다

2. mirrorlist.centos.org IP에 도달 할 수가 없다

나는 2번이 더 가능성이 높다고 생각했고, DNS 서버 주소가 등록이 안되어있나라고 생각했다.

문제 해결

$ sudo vi /etc/resolv.conf

로 들어가서 DNS서버 주소가 등록되어있는 지 확인해보았다. nameserver 10.0.2.3이 등록되어있었고,

ping 10.0.2.3

이렇게 핑 테스트를 하니 응답을 전혀 받을 수 없었다. 따라서 등록되어있는 DNS에게는 요청을 받을 수 없는 상태다. 그래서 새로 구글 DNS를 등록하고 다시 프로비저닝 시키니 잘 작동했다.

nameserver 10.0.2.3

vagrant up

을 실행시켰더니

stderr: vboxmanage.exe: error: failed to get device handle and/or partition id for 0000000001ed7590 (hpartitiondevice=0000000000000a7d, last=0xc0000002/1) (verr_nem_vm_create_failed) vboxmanage.exe: error: details: code e_fail (0x80004005), component consolewrap, interface iconsole

이러한 에러가 떴다.

해결법

cmd를 관리자 권한으로 실행한 뒤,

bcedit

를 실행한다.

여기서 hypervisorlaunchtype이 Auto로 되어있다면

bcedit /set hypervisorlaunchtype off

로 off로 바꿔주고 재부팅한 후, vagrant up을 한다.

사용자명 is not in the sudoers file. This incident will be reported.

sudo 명령어를 쳤을 때, 위와 같은 에러가 나는 경우가 있다.

이것은 현재 사용자가 sudo 권한이 없다는 뜻이다.

해결방법

su

명령어를 쳐서 root계정으로 들어간다.

$ vi /etc/sudoers

위와 같이 파일을 들어간다. 그리고 파일에는 다음과 같은 내용이 있다.

root ALL=(ALL) ALL

위와 같은 부분 아래에

사용자명 ALL=(ALL) ALL

을 입력하고 저장한다.

다만, 그냥 vi로는 readonly로 적용되니

visudo -f /etc/sudoers

명령어를 통해 들어간다.

만약 sudo 명령어를 칠때 password를 적용하고 싶지 않다면,

사용자명 ALL=(ALL) NOPASSWD:ALL를 사용하면 된다.

특정 명령어만을 sudo 권한을 주고 싶다면, 그렇게 하는 방법도 있다.

로그인 인증처리하는 attemptAuthentication(req, res)

Authenticate하는 주체

@Override
    public Authentication attemptAuthentication(HttpServletRequest req, HttpServletResponse res)
            throws AuthenticationException {
        try {

            RequestLogin creds = new ObjectMapper().readValue(req.getInputStream(), RequestLogin.class);
            //authenticationManager가 id와 pw를 바교해줌
            return getAuthenticationManager().authenticate(
                    new UsernamePasswordAuthenticationToken(creds.getEmail(), creds.getPassword(), new ArrayList<>()));

        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

authenticate()는 인증 필터에서 로그인 인증을 처리하는 부분 attemptAuthentication에 적용된다. 코드에서 알 수 있듯이 authenticate하는 주체는 AuthenticationManager이다.
authenticationManager는 구현체인 providerManager가 각각의 인증을 실질적으로 처리하는 AuthenticationProvider를 찾는다.

authenticate()메소드의 처리과정

ID검증: UserDetailsService에서 DB에서 사용자를 조회. 사용자가 없을 경우 UserNotFoundException 예외를 발생시킨다. 성공하면 UserDetails 객체를 반환한다. (select pwd from users where email=?)

Password 검증: 반환 받은 UserDetails 객체에 저장된 Password와 Authentication에 저장된 Password(로그인시 입력한 Password)를 matches 메서드를 이용하여 비교. 일치하지 않는다면 BadCredentialException 예외를 발생시킨다. (passencoder로 login정보에서 패스워드 암호화함)

추가 검증 까지 완료하면 Authentication(유저 정보, 권한 정보)를 AuthenticationManager에게 전달. AuthenticationManager는 Filter에게 전달하고, Filter는 이 정보를 전역적으로 사용할 수 있게 SecurityContext에 전달한다.(그래서 attemptAuthentication의 리턴값이 Aithentication이다.)

Authentication 클래스는 다음과 같다

public interface Authentication extends Principal, Serializable {
    Collection<? extends GrantedAuthority> getAuthorities();

    Object getCredentials();

    Object getDetails(); ->

    Object getPrincipal();

    boolean isAuthenticated(); // 인증되면 true로 변함

그렇게 Filter에게 반환한 Authentication 객체는 다음과 같이 jwt토큰을 만들고 response에 넣기 위해 다음의 메소드의 인자로 들어간다.

@Override
    protected void successfulAuthentication(HttpServletRequest req, HttpServletResponse res, FilterChain chain,
                                            Authentication auth) throws IOException, ServletException {
        String userName = ((User) auth.getPrincipal()).getUsername();
        UserDto userDetails = userService.getUserDetailsByEmail(userName);
        //토큰 생성
        byte[] secretKeyBytes = Base64.getEncoder().encode(environment.getProperty("token.secret").getBytes());

        SecretKey secretKey = Keys.hmacShaKeyFor(secretKeyBytes);

        Instant now = Instant.now();

        String token = Jwts.builder()
                .subject(userDetails.getUserId())
                .expiration(Date.from(now.plusMillis(Long.parseLong(environment.getProperty("token.expiration_time")))))
                .issuedAt(Date.from(now))
                .signWith(secretKey)
                .compact();

        res.addHeader("token", token);
        res.addHeader("userId", userDetails.getUserId());

    }

authentication 객체에서 userName(email)을 추출한다. 이 정보를 가지고 나중에 인가에 사용될 userId 등을 추출한다.

JWT 토큰 만들기

위 그림은 실제 jwt토큰값을 디코딩한 사진이다. jwt토큰은

Header(암호 알고리즘).Payload(userId, 토큰만기(env 설정값)).secret key(env 설정값)

을 암호화시킨다.

그리고 이것을 response 정보에다가 userId, 토큰값을 헤더에 추가한다.

아래는 필자의 AuthorizationFilter 코드이다.

    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            ServerHttpRequest request = exchange.getRequest();

            if (!request.getHeaders().containsKey(HttpHeaders.AUTHORIZATION)) {
                return onError(exchange, "No authorization header", HttpStatus.UNAUTHORIZED);
            }



            String authorizationHeader = request.getHeaders().get(HttpHeaders.AUTHORIZATION).get(0);
            String jwt = authorizationHeader.replace("Bearer", "");

            if (!isJwtValid(jwt)) {
                return onError(exchange, "JWT token is not valid", HttpStatus.UNAUTHORIZED);
            }

            return chain.filter(exchange);
        };
    }

valid된 jwt토큰이 아니면 JWT token is not valid 에러문이 떴어야 했는데, 그것도 아니었다. 즉, AuthoriztionFilter는 정상적으로 통과된것이었다.

경로 권한설정부분에서 문제가 있었다.

혹시 경로에서 내가 권한을 잘 못 줬나는 생각에 WebSecurity설정 코드부분을 보았다.

http.authorizeHttpRequests((authz) -> authz
                                .requestMatchers(new AntPathRequestMatcher("/actuator/**")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/h2-console/**")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/users", "POST")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/h2-console/**")).permitAll()

//                        .requestMatchers("/**").access(this::hasIpAddress)
                                .requestMatchers("/**").access(
                                        new WebExpressionAuthorizationManager("hasIpAddress('127.0.0.1') or hasIpAddress('172.30.1.48')"))
                                .anyRequest().authenticated()
                )
                .authenticationManager(authenticationManager)
                .sessionManagement((session) -> session
                        .sessionCreationPolicy(SessionCreationPolicy.STATELESS));

        http.addFilter(getAuthenticationFilter(authenticationManager));
        http.headers((headers) -> headers.frameOptions((frameOptions) -> frameOptions.sameOrigin()));

보면은 일반적인 GET요청에도 authenticationFilter를 적용하고 있던것이었다!. 사실 Get요청시에는 인가필터만 적용하면 된다. 따라서

.requestMatchers(new AntPathRequestMatcher("/**", "GET")).permitAll()

를 추가하였더니 403에러가 사라지게 되었다.

41, Adding block pool BP-185116165-<*>-1512025890710,['155.230.91.226']

43 Cached dfsUsed found for /home/james/hadoop-2.7.4/hdfs/data/current/BP-185116165-<>-1512025890710/current: <>,"['155.230.91.226', '12435390464']

46 Adding replicas to map for block pool BP-185116165-<*>-1512025890710 on volume /home/james/hadoop-2.7.4/hdfs/data/current...,['155.230.91.226']

51 Periodic Directory Tree Verification scan starting at <*> with interval of 21600000ms,['1514035486079ms']

52 Block pool <> (Datanode Uuid <> service to deimos26/<>:9000 <> <> <> <*>,"['BP-185116165-155.230.91.226-1512025890710', 'null)', '155.230.91.226', 'beginning', 'handshake with NN']"

15, Added global filter 'safety' (class=org.apache.hadoop.http.HttpServer2$QuotingInputFilter),[]

16, Added filter <> <> to context <*>,"['static_user_filter (class=org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter)', 'datanode']"

17, Added filter <> <> to context <*>,"['static_user_filter (class=org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter)', 'logs']"

18, Added filter <> <> to context <*>,"['static_user_filter (class=org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter)', 'static']"

154, Added filter <> <> to context <*>,"['static_user_filter (class=org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter)', 'secondary']"

155, Added filter <> <> to context <*>,"['static_user_filter (class=org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter)', 'static']"

156, Added filter <> <> to context <*>,"['static_user_filter (class=org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter)', 'logs']"

3385 Added filter 'org.apache.hadoop.hdfs.web.AuthFilter' (class=org.apache.hadoop.hdfs.web.AuthFilter),[]

3653, Added filter <> <> to context <*>,"['RMAuthenticationFilter (class=org.apache.hadoop.yarn.server.security.http.RMAuthenticationFilter)', 'cluster']"

193, Registering class <> for class <>,"['org.apache.hadoop.yarn.server.nodemanager.containermanager.container.ContainerEventType', 'org.apache.hadoop.yarn.server.nodemanager.containermanager.ContainerManagerImpl$ContainerEventDispatcher']"

문제점:

1. 명백히 port번호, ip_adress, node name 등 이더라도 서로 다른 토큰이 안나오면 무조건 static으로 취급한다. ex: 51, 52번과 같이 포트번호가 9000이외가 없으니..

2. 16, 17, 18번을 보면 filter 네임은 변수로 되어있지만 15번, 3385번은 static 취급한다. 왜냐하면 16, 17, 18은 15, 3385와 토큰 수가 달라 아예 다른 이벤트로 취급되기 때문이다. 다른 이벤트로 취급되기에 16, 17, 18은 filter name토큰이 달라 로 취급하지만, 15, 3385내에서는 필터네임이 다 같기에 static으로 취급한다. *로그 의미가 이토록 비슷한데 토큰수가 달라서 다른 이벤트로 취급되는 것이 문제**

Spark 로그

conda activate logparser

를 실행했을 시

usage: conda [-h] [--no-plugins] [-V] COMMAND ... conda: error: argument COMMAND: invalid choice: 'activate' (choose from 'clean', 'compare', 'config', 'create', 'info', 'init', 'install', 'list', 'notices', 'package', 'remove', 'uninstall', 'rename', 'run', 'search', 'update', 'upgrade', 'build', 'content-trust', 'convert', 'debug', 'develop', 'doctor', 'index', 'inspect', 'metapackage', 'render', 'skeleton', 'repo', 'server', 'verify', 'token', 'env', 'pack')

라는 에러가 떴었다. 이것은

$ source ~/anaconda3/etc/profile.d/conda.sh

이 명령어로 해결가능하다. ~에는 아나콘다3의 경로를 입력해주면 된다.

우리가 많이 쓰는 Maven과 Gradle은 빌드 관리 도구이다. 그렇다면 빌드는 뭐고, 빌드 관리 도구란 무엇일까?

빌드

빌드와 컴파일은 개념을 혼동하기가 쉬운데, 빌드는 컴파일뿐만이 아니라 소스코드 파일부터 시작해서 컴퓨터에서 실행할 수 있는 독립적인 형태로 변환되는 과정 전체를 말한다. 자바를 예로 든다면, 개발자가 작성한 .java이 컴파일돼서 .class파일로 변환되고 resource를 .class에서 참조할 수 있는 위치로 옮긴다. 또한 META-INF와 MANIFEST.MF 들을 하나로 압축하는 과정이다. 즉, 우리가 작성한 소스코드와 자원을 JVM이나 톰캣같은 WAS가 인식할 수 있도록 패키징하는 과정을 말한다.

빌드 관리 도구

소스코드에서는 여러가지 외부 라이브러리를 참조해 사용하는데, 빌드 관리도구는 사용자가 관리할 필요없이 필요한 라이브러리를 자동으로 관리한다.

빌드관리 도구는

1. 종속성 다운로드
2. 컴파일
3. 컴파일된 바이너리 코드를 패키징(Packaging)
4. 테스트 실행
5. 프로덕션 시스템에 배포

Maven, Gradle이 이러한 빌드 관리도구이다.

Maven

*메이븐은 대표적인 Lifecycle관리 목적 빌드 도구이다. *

아래와 같은 라이프 사이클을 가진다. (1) clean : 빌드 시 생성되어있었던 파일들을 삭제한다. (2) validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계 (3) compile : 프로젝트 소스코드를 컴파일 하는 단계 (4) test : 단위 테스트를 수행하는 단계. 테스트 실패 시 빌드 실패로 처리하며, 스킵이 가능하다. (5) package : 실제 컴파일된 소스 코드와 리소스들을 jar, war 등의 파일의 배포를 위한 패키지로 만든다. (6) verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인한다. (7) site : 프로젝트 문서와 사이트 작성, 생성하는 단계 (8) deploy : 만들어진 package를 원격 저장소에 release하는 단계

또한 Maven은 필요한 라이브러리를 pom.xml에 정의한다.

Gradle

gradle은 Ant Builde와 groovy script를 기반으로 구축된, maven을 대항(?)하는 빌드 툴이다. 캐시를 사용하고, 빌드 속도가 Maven에 비해 10~100배 가량 빠르며, Java, C/C++, Python 등을 지원한다.

Groovy

Groovy는 JVM에서 실행되는 스크립트 언어이다. 또한 컴파일 과정이 필요없다. Java문법과 유사하여 if else절등을 사용할 수 있다.

무엇을 사용하는 것이 좋을까?

예전에야 Maven을 많이 썼지만, 지금은 속도와 가독성면에서 Gradle이 압도적이기에 Gradle로 많이 넘어온 추세라고 한다. 시간과 비용이 들지만 배워두는게 좋다고 생각하다.

JAR, WAR

기본적으로 JAR, WAR 모두 Java의 jar 옵션 (java -jar)을 이용해 생성된 압축(아카이브) 파일로, 애플리케이션을 쉽게 배포하고 동작시킬 수 있도록 관련 파일(리소스, 속성 파일 등)을 패키징 한 것이다.

JAR (Java Archive)

JAVA 어플리케이션이 동작할 수 있도록 자바 프로젝트를 압축한 파일 -Class (JAVA리소스, 속성 파일), 라이브러리 파일을 포함함 -JRE(JAVA Runtime Environment)만 있어도 실행 가능함 (java -jar 프로젝트네임.jar)

WAR (Web Application Archive)

-Servlet / Jsp 컨테이너에 배치할 수 있는 웹 애플리케이션(Web Application) 압축파일 포맷 -웹 관련 자원을 포함함 (JSP, Servlet, JAR, Class, XML, HTML, Javascript) -사전 정의된 구조를 사용함 (WEB-INF, META-INF) -별도의 웹서버(WEB) or 웹 컨테이너(WAS) 필요 즉, JAR파일의 일종으로 웹 애플리케이션 전체를 패키징 하기 위한 JAR 파일이다.

스프링부트는 내장WAS가 있어, WAR를 사용할 필욘 없다. 외장 WAS를 이용할 계획이 있다면 WAR를 사용하는 것이 좋겠지만, 그렇계획이 없다면 JAR를 사용하는 게 좋다.

카프카의 탄생배경

위 그림은 카프카를 개발해낸 링크드인이 카프카를 도입하기 전의 데이터 처리 시스템이다.

위와 같은 아키텍처는 다음과 문제점이 있다.

1. 실시간 트랜잭션 처리와 비동기 처리가 동시에 이루어지지만 통합된 전송 영역이 없으니 복잡도가 증가할 수 밖에 없다. 따라서 문제를 발견하고 조치를 취하려면 여러 데이터 시스템을 확인해야한다.

2. 데이터 파이프라인 관리의 어려움이 있다. 키-값 저장소, 모니터링 시스템, RDBMS, 하둡 등 제각기 파이프라인 별로 데이터 포맷과 처리하는 방법들이 달라 운영에 어려움이 있다.

따라서 카프카 창시자는 다음과 같은 목표를 가지고 새로운 시스템을 만들기 시작했다.

• 프로듀서와 컨슈머의 분리
• 메시징 시스템과 같이 영구 메시지를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지 최적화
• 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

따라서 다음과 같은 카프카 기반의 시스템을 만들었다.

위와 같이 카프카를 적용한 후에는 모든 이벤트/데이터를 중앙에서 관리를 하게되었다. 또한 카프카가 제공하는 표준 포맷으로 연결되어있어 포맷 걱정도 할 필요가 없었다. 이젠 카프카에만 데이터를 전달하면 나머지는 필요한 곳 또는 다른 서비스들이 각자 가져갈 수 있어 자신의 업무에만 집중하면 되었다.

카프카의 동작 방식과 원리

기존 메시징 시스템을 사용하는 pub/sub 모델은 대규모 데이터보다는 간단한 이벤트를 서로 전송하는데 사용되었다. 왜냐하면 메시징 시스템의 교환기의 부하, 각 컨슈머의 큐 관리, 큐에 전달되고 가져가는 메시지의 정합성, 전달 결과를 관리하기 위한 내부 프로세스가 복잡하기 때문이었다. *즉, 메시지의 보관, 교환, 전달 과정에서 신뢰성을 보장하는 것에 중점을 맞췄기 때문에 속도와 용량은 크게 고려하지 않았다. *

카프카는 메시지 시스템이 지닌 성능의 단점을 극복하기 위해, 메시징 시스템 내에서의 작업량을 줄이고 이렇게 절약한 작업량을 메시징 전달 성능에 집중시켜서 고성능 메시징 시스템을 만들었다.

카프카의 메시지 전달 순서

1. 프로듀서는 새로운 메시지를 카프카로 보낸다.
2. 프로듀서가 보낸 메시지는 카프카에 토픅에 도착해 저장된다.
3. 컨슈머는 카프카 서버에 접속하여 새로운 메시지를 가져간다.

카프카의 특징

1. 프로듀서와 컨슈머의 분리: 카프카는 메시징 전송 방식 중 메시지를 보내는 역할과 받는 역할이 완벽하게 분리된 pub/sub방식을 적용했다. 위 그림과 같이 서버가 1대가 더 추가된다면 단순하게 서버만 추가되는 것이 아니라 연동해야할 시스템이 많아지기 때문에 추가적인 작업도 매우 늘어난다. 게다가 일대일로 통신하고 있던 모니터링 서버에 문제가 생겨 응답이 늦어지는 경우가 발생하면, 연쇄작용으로 모니터링 서버와 연결된 다른 서비스 서버들에서도 지연 등의 이슈가 발생할 수 있다. 하지만 오른쪽과 같이 카프카를 중앙에 놓으면 서비스 서버들은 카프카로 메시지를 보내는 역할만 하면 되고, 모니터링이나 분석 시스템들도 카프카에 저장되어 있는 메시지만 가져오면 된다.

2. 멀티 프로듀서, 멀티 컨슈머

카프카는 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조로 되어있다. 이렇게 하면 하나의 데이터를 다양한 용도로 사용하는 요구를 쉽게 충족할 수 있다.

3. 디스크에 메시지 저장

트래픽이 일시적으로 폭주해 컨슈머의 처리가 늦어지더라도 카프카의 디스크에 안전하게 보관되어있기 때문에, 컨슈머는 메시지 손실 없이 메시지를 가져갈 수 있다.

4. 확장성

카프카 클러스터는 3대의 브로커로 시작해 수십 대의 브로커로 확장 가능하다.

5. 높은 성능

카프카는 고성능을 위해 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용하고 있다.

이상으로 카프카의 전체적인 탄생배경, 구조, 특징 등을 알아보았습니다. 다음 편에서는 카프카의 디자인에 대해 알아보겠습니다.

사용자가 매 번 객체를 생성하고, 관리할 때마다 객체 간의 결합성이 커진다. 그럴 때마다 코드의 복잡성은 커지며 사용자는 번거로움을 느낀다. 이것은 곧 요구사항 변경의 취약을 의미한다. 객체인스턴스의 생성, 소멸을 관리해주는 게 따로 있을 수 없을까?

IOC 컨테이너

컨테이너는 객체의 생성주기를 관리하고, 생성된 객체에게 추가적인 기능을 제공하는 것을 뜻한다.

스프링 프레임워크도 이러한 객체의 생성, 소멸, 의존성 등을 담당하는 컨테이너가 따로 있는 데 이것이 바로 IOC 컨테이너이다.

*인스턴트의 생성부터 소멸까지 생명주기를 사용자가 아닌 컨테이너가 따로 관리해주어 사용자는 오로지 로직에만 집중하면 된다. *

How?

위 그림을 보자. 사용자는 Factory라는 클래스의 객체를 Container에 등록하고 싶다. 그러면 @Component나 @Bean을 통해 스프링 빈으로 등록하면 된다. 그러면 Factory 객체는 따로 사용자가 아닌 컨테이너가 따로 관리해준다. 사용자는 번거롭게 Factory객체를 생성을 하지않고 그저 @Autowired를 붙여 컨테이너에서 불러내주기(DI)만 하면 된다.

IOC(Inversion of Control)

이렇게 사용자가 객체를 관리하는 것이 아닌 컨테이너가 따로 관리해 사용자가 로직에만 집중할 수 있게 하는 것은 제어의 역전 즉, IOC라고 한다.

DI(Dependency Injection)

사용자는 그저 객체를 생성하지 않고, @Autowired를 통해 객체를 삽입해 불러올 수 있는데, 이것을 의존성 주입 즉, DI라고 한다.