정리 블로그

Linux Directory의 구조는 트리 형식으로 되어있으며, /usr/bin (root디렉토리>usr디렉토리>bin디렉토리) 처럼 상/하위 디렉토리로 구성되어 있음.

처음 루트 디렉토리에서 ls 명령어를 입력해보면, 해당 디렉토리에 대한 용도는 생각해보지 않고 사용하였으나 제대로 인지하고 목적에 맞게 사용하면 좋을 것 같아 정리.

(디렉토리는 윈도우의 폴더라고 생각하면 됨)

/ (루트)

 - 최상위 디렉토리이며, 트리 형식의 리눅스 모든 디렉토리 중 꼭대기의 디렉토리

/bin

 - 기본적인 명령어가 저장된 디렉토리이며, 리눅스를 사용하면서 입력하는 command 들이 이 곳에 저장되어 있음. ls, rm, netstat 등의 명령어들이 저장됨

/dev

 - 시스템 디바이스 파일을 저장하는 디렉토리. device를 의미하며, CD-ROM, 장치 드라이버, 프린터 등의 주변 장치들이 존재하는 디렉토리

/home

 - 사용자가 접속 시, 초기에 들어가는 화면임. 사용자에게 할당된 개인에 대한 부분. useradd로 계정 생성 시, 해당 디렉토리에 사용자 계정의 디렉토리가 생성됨.

/lib64, /lib

 - 커널모듈, 시스템에 필요한 라이브러리가 저장되어있는 디렉토리.

 - 리눅스 기반의 MAC의 경우, 'uname' command를 입력하면 darwin 이라는 뜸(TMI)

/mnt, /media

 - 마운트 포인트로 사용하는 디렉토리. 사용자가 직접 마운트하는 포인트로 사용되며, /media 와 마운트한다는 측면에서는 비슷하지만 CD-ROM과 USB를 연결하면 /media 디렉토리에 자동으로 마운트 되는 차이.(/media 는 자동 마운트 경로, /mnt 는 사용자가 마운트 시키는 경로

/proc

 - 여러 프로세스 이름에 따라 많은 디렉토리들이 존재. 현재 실행중인 프로세스에 대한 정보와 데이터를 가지고 있으며, 실제 존재하지 않으며 메모리상으로 존재함. '가상파일시스템'이라고도 불리우며, cpu 사용값, I/O 포트 등의 프로세스에 대한 다양한 정보가 들어있음.

/run

 - 시스템의 현재 정보를 저장하고 있는 디렉토리

/srv

 - 서버를 위한 디렉토리로, 외부 사용자와 공유를 위해 사용하는 디렉토리. 따라서 비교적 접근 권한이 낮게 설정되어있음.

/tmp

 - 임시 파일을 위한 디렉토리로 윈도우 OS의 tmp와 같은 역할을 한다고 생각하면 됨.

/var

 - 로그, 캐싱 파일등이 위치할 수 있으며 파일의 크기가 추후 계속 확장되는 경우 사용함.(로그 축적과 같이 점차 증가하는 경우)

/boot

 - Boot Loader 가 존재하는 디렉토리이며,  시스템 부팅에 필요한 파일들이 위치하기에 조심해야함.

/etc

 - 시스템의 거의 모든 설정이 저장되어있는 디렉토리. 'passwd'와 'fstab', 'profile' 등이 들어있음.

/opt

 - 유닉스 계열은 이 디렉토리에 응용 프로그램을 설치하지만, redhat 계열은 /usr/local 프로그램별로 설치하거나, RPM(Redhat package Manager)가 필요한 곳에 자동 설치.

/root

 - 시스템 루트 관리자의 홈디렉토리

/sbin

 - /bin 디렉토리의 역할과 비슷하지만, 루트유저만 사용할 수 있는 명령어가 저장되어있음.

/sys

 - 커널 하드웨어 정보를 제공하며, 매번 다시 시작할때마다 새로 생성.

/usr

 - 시스템이 아닌 사용자가 주로 사용하는 디렉토리이며, 각 사용자의 개인영역(루트 사용자는 접근 가능). 여러 언어 관련 헤더 파일들도 저장되는 디렉토리

- AWS의 ELB는 3개의 세부 항목으로 나뉘어져있으며, 인입되는 트래픽을 EC2, 컨테이너, IP 주소, Lambda 함수와 같은 대상으로 트래픽을 분산시키는 역할을 함. 애플리케이션의 고가용성, 자동 확장/축소, 보안 기능을 함.

- Health Check를 통해 LB 하단의 상태를 체크(EC2 등)

ALB(Application Load Balancer) / NLB(Network Load Balancer) / CLB(Classic Load Balancer)

- Application Load Balancer

  - 프로토콜 HTTP 및 HTTPS 트래픽의 로드 밸런싱에 가장 적합.

  - 마이크로서비스와 컨테이너 등 애플리케이션 아키텍처 전달을 위한 고급 요청 라우팅 기능 제공

     (인입된 트래픽을 PATH에 기반으로 처리)

  - 7계층(어플리케이션 단)에서 작동하며, VPC 내의 대상으로 트래픽을 라우팅

  - 1개의 EC2에서도 여러개의 포트(80, 8080)로 로드밸런싱 가능

  - URL Path 기반, Host 기반, Redirection, HTTP 헤더 기반, 쿼리 문자열 파라미터 기반, 소스 IP주소 CIDR 기반 라우팅을 지원 (Redirection의 경우, 하나의 URL에서 수신되는 요청을 다른 URL로 리디렉션 가능.)

  - Lambda 함수를 대상으로 사용 가능(Lambda 함수를 사용하여 EC2, 컨테이너, 온프레미스 서버 등으로 확장 가능)

- Network Load Balancer

  - 프로토콜 TCP, UDP 및 TLS(Transport Layer Security, 전송 보안 계증) 트래픽의 로드 밸런싱에 가장 적합.

  - 4계층(Transport 단)에서 작동하며, VPC 내의 대상으로 트래픽을 라우팅.

  - 초당 수백만 개의 요청을 처리하며 지연 시간을 매우 낮게 유지

  - 갑작스러운 일시적 트래픽 패턴 처리 최적화

  - 1개의 EC2에서도 여러개의 포트(80, 8080)로 로드밸런싱 가능

  - EC2 인스턴스, 마이크로 서비스 및 ECS로 라우팅 가능.

  - ALB, CLB의 IP는 한번 씩 변경되는 것에 반하여, NLB는 IP 변경이 없음.

- Classic Load Balancer

  - EC2 인스턴스에 기본적인 로드 밸런싱을 제공

  - 기본 로드밸런서라고 생각하면 됨.

** 내용을 정리하고 보니, CLB의 특징이 제일 적어 다른 장점이 많은 LB를 사용할 것이라는 생각을 하실 수도 있겠습니다만, 실제로 사용하다보면 저는 특수한 케이스가 아닌 이상 제일 설정이 간편하다는 이유로 CLB를 많이 사용하고 있습니다 :) AWS에서 제공하는 ELB 개념을 정리해보고자 작성하였으며, 추후 AZURE의 LB에 대해서도 정리를 진행하여 두 개의 서비스를 비교해보면 유익할 것 같습니다.

DevOps

 Development(개발) + Operations(운영) 의 합성어로, 아래 목적을 위해 만들어졌다.

• 제품 출시까지 걸리는 기간(time to market) 단축
• 새로운 판의 더 낮은 실패율
• 픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)
• 복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)

즉, 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적.

SRE(Site Reliability Engineering)

 DevOps는 운영에 대해 초점을 맞췄다면, SRE의 핵심은 안정성에 초점을 맞추며, DevOps의 안에 포함될 수 있는 개념이라고 이해하였습니다. SRE에 관심을 가져야 하는 사람은 DevOps 뿐 아니라, System Admin과 IT 전문가들도 관심을 가져야 되며, 일정 수준의 안정성이 보장되지 않는다면 비즈니스에 치명적으로 작용할 수 있음을 주의해야 합니다. 

 어떠한 시스템도 100% 안정성을 가지고 운영될 수 없지만, 안정성의 수준을 정하고자 한다면 답은 "주요 관련자가 적절하다고 생각하는 특정 수준"을 의미한다고 합니다.(해당 의미는 MicroSoft의 Doc을 참고하여 작성하였습니다.)

----------------------------------------------------------------------------------------------------------------------------

DevOps 및 SRE는 동일한 과제를 해결하기 위한 두 가지 병행 시도임을 알아야 합니다. SRE는 DevOps 이후의 다음 진화 단계가 아닙니다. SRE는 “DevOps의 미래”로 생성된 것이 아닙니다.(MS Docs 발췌)

MS Docs를 조금 더 참고하고 싶으시다면,

docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/3-sre-in-context

위 Docs를 참고하면 도움이 될 것 같습니다.

서로 다른 계정의 AMI를 공유하는 방법.

- EC2의 이미지를 생성하여 저장한다.

- 저장된 이미지는 AWS Console 좌측 'AMI'에서 확인 가능

(원본 계정)

'AMI'에서 공유하고자 하는 이미지를 클릭 후 우클릭 시,

'Modify Image Permissions' 클릭.

클릭했을 때, 팝업창.

- 'This Image is currently' 에서 Public를 클릭하면 전체 공유가 되는것 같은데, 불안해서 못해봤습니다..

- Private으로 공유하였고, AWS Account Number에 공유받고자 하는 계정의 Number 입력.

   (입력 후 Add Permission 필수)

- Add "create volume" permissions to the following associated snapshots when creating permissions: 에는 해당 이미지 원본 EC2의 Volume들이 나타나며, 박스 클릭 시 이미지 공유와 함께 Volume 스냅샷도 같이 공유됨.

(해당 내용은 아래에서 한번 더 언급 예정)

(공유 받는 계정)

'SungtaekYoo' 계정에서 공유한 AMI를 확인할 수 있습니다.(해당 이미지는 다른 AMI 공유 스크린샷이라 이름이 다르니 참고.

- 공유 완료 후 다른 계정에서 EC2내 AMI를 들어가면 보이지 않음.

- 글쓰기박스 왼쪽에 기본설정 'Owned by me'이기 때문에 보이지 않고, 클릭 후 'Private images'로 변경 후 확인 가능함.

** 이 작업은 원래 계정의 이미지를 다른 계정의 이미지로 복사하는 개념이 아님.

원래 계정의 이미지를 공유하는 개념이기때문에 공유되어있는 이미지가 원래 계정에서 이미지 삭제 혹은 Permission 제거를 한다면 공유받는 계정에서도 사라지게됩니다.(직접 테스트 결과)

** 위에서 언급하였던 'Modify Image Permission'에서 'Add ~~~블라블라' 체크하여 볼륨의 스냅샷까지 체크된 경우에 원본에서 이미지를 삭제하여도 볼륨의 스냅샷은 유지되어있으며, 해당 스냅샷으로 볼륨 생성 가능합니다.(직접 테스트 결과)

** AWS의 마켓플레이스를 통해 생성한 경우, AMI 이전을 통해 바로 생성되지 않을 수 있습니다.(저의 경우 마켓을 통해 생성한 MQ였습니다.)

이 때, 서버 생성 시에 발생하는 에러의 주소를 복사하여 이동하면 서버 생성 마켓플레이스로 들어가지는데, 해당 서비스를 Subscribe해야 생성 가능합니다.(제 기준 MQ서버 이전 시, MQ 서버 내에 모든 설정 동일. 물론 MQ서버기 때문에 송수신하는 메세지 경로 혹은 IP 설정을 다시해줘야함.)

1. WEB-LB와 mod_proxy & mod_jk를 통한 서버 구성
 -. WEB-Server의 Apache에 mod_jk 혹은 mod_proxy 설정을 통해 로드밸런싱 가능.
 -. WEB-Server와 WAS-Server 간의 통신 에러 발생 시, src IP 확인이 가능함.
   (src IP가 확인 가능할 경우, 통신이 비정상적인 상황에서 통신 확인 가능)

2. WEB-LB와 WAS-LB를 통한 서버 구성
 -. 통신 에러 발생 시, WEB, WAS간의 통신 에러인지, LB와 WAS간의 통신 에러인지 확인 불분명.
   (WAS-Server에서 확인 시, LB IP가 출력됨)
 -. 이벤트 등으로 인한 WAS-Server 증설 시, 추가 설정이 적음.

 -. AWS&AZURE TAM 또한, 해당 형식으로 아키텍쳐 구성 추천

Apache
 1. WEB-Server를 구동시키는 역할
 2. mod_jk 또는 mod_proxy 설정을 통하여 WAS에 로드밸런싱을 할 수 있음.(Apache와 Tomcat 연동)
   *mod_jk 
        -. 발전된 로드 밸런서 / 패킷 사이즈 8K 이상 지원
        -. 별도 모듈을 빌드하고 관리 필요
    mod_proxy
        -. 패킷 사이즈 8K 이상 지원하지 않음
        -. 도메인 모델 클러스터링을 지원하지 않음
        -. 별도 모듈이 필요 없음


Tomcat
 1. WAS-Server를 구동시키는 역할