현재 Windows 11을 사용하는 중이고, 하나의 1TB짜리 SSD를 C드라이브와 D드라이브로 분할해 사용하고 있는 중입니다.
그러나 언제부터 C드라이브의 용량이 거의 꽉 차다시피 차게되고, 더이상 프로그램을 C드라이브에 설치하는 것이 불가능해져 이후부터 설치하게 되는 프로그램들은 D드라이브에 설치했습니다.. 그런데! 분명 C드라이브에 어떠한 파일을 추가한것도 아닌데 자꾸 C드라이브 용량이 없다는 알림이 뜨는 것입니다,, 아래는 당시 C드라이브 상황입니다.. (그나마 원래 100MB 남았다고 하는 상황에서 안쓰는 프로그램들 최대한 삭제해서 만든 용량이 저정도...)
하지만 이 용량도 다시 금방 차올라 결국 D 드라이브 용량 중 140GB를 C드라이브에 연결하는 선택을 하게 됩니다.... 이 선택으로 얼마간은 버틸 수 있겠거니 생각하고 컴퓨터를 다시시작 하는데..?
왠걸 140GB 이상은 남아있어야 할 C드라이브가 49GB밖에 남아있지 않는 것입니다. 아무리 생각해도 이건 내가 설치한 프로그램의 잘못이 아니다 라는 생각에 원인을 찾기 시작합니다. 당시 아래 블로그를 참고했고, 여기서 시도한 방법들은 거의 다 해본 것 같습니다.
구라 제거기, Wise머시기 프로그램도 사용해봤지만 5GB 정도의 용량만 확보할 수 있었고, 제가 찾던 140기가 이상의 용량은 얻지 못했습니다. 결국 직접 문제의 파일을 찾고자 위 블로그 글 중 TreeSize 라는 프로그램을 설치하였고 그 원인을 찾을 수 있었습니다.
TreeSize 프로그램을 실행하면 아래와 같은 화면이 나오는데, 이 리스트 중 C드라이브를 가장 많이 잡아먹고 있던 파일이 무엇인가??? 찾아보니 pagefile.sys가 혼자서 무려 260GB 가량을 차지하고 있었던 것이었습니다ㅡㅡ 이 파일은 가상메모리 페이징에 사용되는 파일인데, 현재 시스템에서 이 파일의 사이즈를 제한해두지 않아 프로그램 사용 시 마다 계속 페이징된 부분들이 쌓였던 것 같습니다..
실제로 [시스템 속성] - [고급] - [성능 설정] - [고급] 탭에 들어가보면 가상 메모리 파트가 나오는데 여기서 바로 그 문제의 현상을 목격할 수 있었습니다. 262GB.....한숨 나오네요...
손 좀 봐주기 위해 [변경] 에 들어가보니 페이징 파일의 크기가 권장 크기에 비해 말도 안되게 커져있는 것을 확인할 수 있었습니다.
이렇게 만든 원인은 "모든 드라이브에 대한 페이징 파일 크기 자동 관리" 체크 박스가 해제되어 있는 상태였는데.. 이를 체크해두는게 권장사항이라고 합니다.. 별도로 페이징 파일 크기를 커스텀 해주고 싶을 경우 이 체크박스를 풀고 원하는 크기를 설정해주면 됩니다. 이러한 부분은 (https://hkebi.tistory.com/1321) 블로그를 참고했습니다.
이렇게 체크박스를 체크하고 컴퓨터를 재시작하면 아래와 같이 정상으로 보이는 상태의 볼륨 사용량을 볼 수 있습니다....
대게는 저 체크박스가 활성화되어있을텐데 저의 경우 어쩌다 해제가 되었던건지 모르겠네요,, 뭔가 툴 만지다가 건드렸나 싶은데 추후에 다시 이러한 상황이 목격되면 이 부분도 조사해봐야겠습니다..
2022년 11월 3일, 삼성동 코엑스에서 진행된 AWS Industry Week에 다녀왔다.
클라우드에 관심이 생긴 이후 오프라인으로 진행되는 큰 행사에 참석해본 것이 처음이었기에 설레는 마음으로 다녀왔던 것 같다. 낮까지 학교 수업이 있었기 때문에 앞 타임 강연에는 참석하지 못했지만, 중간 휴식시간쯤에는 도착해서 파트너 부스랑 그 이후 진행되었던 강연들은 볼 수 있었다.
AWS Industry Week는 각 산업 분야별로 AWS를 이용하고 있는 기업의 담당자에게 기업 내 클라우드 적용 사례를 직접 전해 들을 수 있었던 행사였다. 클라우드에 대한 개념을 공부하며 늘 궁금해했던 부분이 이러한 개념 및 서비스들을 많은 양의 트래픽이 오가는 실제 서비스에 어떤 식으로 적용할 수 있을지에 대한 부분이었는데, 이에 대해 들을 수 있어 재밌었다. 또한 최근 기업에서의 클라우스 사용 동향에 대해서도 들을 수 있어서 유익했던 것 같다.
뿐만 아니라 그밖에 AWS 솔루션 및 파트너 부스들의 클라우드 솔루션들을 구경하면서 요즘 시장에서 어떠한 부분이 필요하고 중요하게 여겨지는지에 대해 알 수 있었다.
진행되었던 강연 목록은 아래와 같다. 각 산업분야별로 서로 다른 룸에서 강연이 진행되었기 때문에 중간에 자리를 옮길 것이 아니라면 사실상 한두 개 정도의 분야를 골라서 들어야 했다. 나는 개인적으로 현대화나 인프라 구축 쪽으로 관심이 있었기 때문에 금융 및 핀테크 분야를 선택했었다. 레벨 200으로 표시된 강연들 뿐이었지만, 생각보다 공부했던 개념들이 많이 들렸고 어려웠다기보다는 적용사례에 대해서 흥미롭게 잘 보고 왔던 것 같다.
이후 내용은 강연 중 메모했던 것을 기록용으로 다시 정리해 적어둔 것이다.
<1> 모더나이제이션(현대화) 여정
모더나이제이션 접근방법
(Relocation/Rehost) : 그냥 단순 마이그레이션. 통째로 올리는 것
경량화된 아키텍처 (Replatform) : 서비스 코드는 건드리지 않은 채 컨테이너화 시켜 AWS 서비스에 올리는 것 (ECS, Fargate, EKS)
최적화 아키텍처 (Refactor/Rewrite) : 비용, 속도 면에서 효율을 높이기 위해 서비스 코드 부분까지 건드리는 것 (3rd party -> open source, 높은 성능 및 확장성을 위해 서비스 특성에 따른 DB 선택 등)
손쉬운 모더나이제이션을 위해 관리형 서비스나 서버리스를 사용할 수 있다.
기술적인 부분에서 여력이 된다면 마이크로서비스(MSA)로 설계하는 것이 좋다. (비즈니스 경량화를 위해)
기업에서 실제로 모더나이제이션 시 고려한 부분
서비스 특성에 따라 서로 다른 아키텍처로 구성
모놀리식이 아닌 MSA로 설계
컨테이너 활용, k8s 기반 MSA 적용, Framework 변경
자원 최적화
EFS, EC2, DynamoDB 등에서 버스트 모드로 동작하는 서비스에 대한 이해 필요
적용 사례 : EFS의 버스트크레딧 모드 사용 중 Lambda를 이용하여 사용량 증가 시 Provisioned 모드로 전환
성능 회적화
AWS Cloudfront 도입
비용 최적화
탄력적 리소스 운영 : 리소스 사용량 조정/최소화
트래픽/리소스 사용량이 적은 시간대의 운영대수 축소
일시적 트래픽 증가에 대해 Auto-Scaling 활용
아키텍처 개선
로그 적재 방식 변경(RDB -> DDB -> S3)
matlab 통계 정보를 이용하여 리소스 사이즈 조정, 비용이 큰 리소스 대체
SQL 쿼리 튜닝, 배치 시간 단축
약정기간 할인 : RI, SP 할인
필수 리소스 약정 적용
신규 리소스 적용 및 갱신 재적용
모더나이제이션 효과
온프레미스의 유량제어 시스템 제거 가능
MSA로 독립성을 보장하여 부담 없는 배포 가능
속도 개선
<2> 금융 클라우드, 네트워크 인프라 구축
금융 분야 클라우드 컴퓨팅 도입 고려 사항
전자금융감독규정
망분리
보안 및 컴플라이언스
금융감독원 클라우드 이용 보고
CSP 안정성 평가
금융 클라우드, 네트워크 인프라 구축 시 고려 사항
망분리 및 접근 통제
Amazon VPC
AWS 클라우드에서 다른 가상의 네트워크와 논리적 분리 구성
목적에 맞는 별도의 VPC 환경 구축
Subnet & Route table
Network Segmentation을 위한 Subnet, Route Table 설정
Network access control list (NACL)
서브넷 외부와 내부 트래픽을 제어하기 위한 방화벽 역할
Firewall
네트워크 경계 보안을 위한 Network Firewall, IDS, IPS 사용
외부 인터페이스 연계
AWS Direct Connect : AWS로 전용 네트워크 연결
AWS Site-to-Site VPN : VPC와 온프레미스를 인터넷을 통한 IPSEC VPN으로 연결
AWS PrivateLink : 외부에 노출되지 않는 Private 연결 제공
인프라 구축 사례
1. 개발/운영 환경의 분리
선택지 1. Subnet Isolation
장점 : 빠르고 쉽게 구현 가능
단점 : 보안 요건을 충족하기 위해 복잡한 NACL 및 Security Group 적용 필요 (완전 분리는 아니기 때문에 실수로라도 두 환경 간 통신이 이루어질 가능성이 여전히 있다..)
선택지 2. VPC Isolation
장점 : 복잡한 NACL 및 Security Group 없이 보안 요건 충족 가능
단점 : 개발/운영 환경이 하나의 계정(account)에 존재하기 때문에 실수로라도 보안적인 리스크 발생 가능
선택지 3. Account Isolation
개발/운영 환경이 아예 다른 계정에서 구성되어 있기 때문에 보안 리스크 최소화 가능
복잡하고 IAM Assuming 개념에 대한 이해 필요
선택지 3 채택! Account 분리 구성 : User -> Security account -> dev account / prod account
Security account : 로그인을 위한 계정 IAM 사용자 외에 다른 어떠한 리소스도 없다. 따라서 IAM 사용자 계정이 탈취되어도 할 수 있는 게 없다.
dev, prod account : 개발, 운영 환경을 위한 계정 IAM 사용자로 로그인할 수 없다. security의 IAM 사용자로 역할 전환을 하던지, 루트 사용자를 이용하여 로그인하는 방법으로만 로그인을 할 수 있다.
2. 서버 접근
선택지 1. SSH
장점 : 사용이 편하고 익숙한 도구
단점 : SSH 접근을 위한 키 관리 필요
선택지 2. AWS Session Manager
장점 : AWS에서 제공하며, Bastion 없이 사설 IP 인스턴스에 접근 가능
단점 : X
선택지 3. AWS Partner Solution
장점 : 보안적으로 더 많은 기능 제공
단점 : 도구 자체에 대한 설치 및 운영 리소스 필요
선택지 3 채택! AWS Partner Solution 이유 : Teleport의 session recording 기능 (session 사용하는 모습 녹화.. 오타 치는 거까지 전부 녹화됨)
단점 보안책 : Teleport Client 설치 자동화 (AWS Lambda와 SSH Run Command 이용)
3. 모니터링 시스템 구성
이상 징후 감지 : CloudWatch (+ Terraform)
필요 정보 전파 : Chatbot
구성 : CloudWatch -> SNS -> Chatbot -> Slack
4. 외부와의 연동
선택지 1. Site-to-Site VPN
사용 사례 : 상대방의 환경이 On-Premise 혹은 Cloud 이면서 VPN 사용이 가능할 경우
VPN 벤더별로 configuration을 제공하기 때문에 이 configuration만 전달하면 된다. (간편함)
선택지 2. Direct Connect
사용 사례 :상대방의 환경이 On-Premise 이면서 VPN 사용이 불가능할 경우
제 3자의 IDC를 거쳐서 전달하는 방식.
Direct Connect를 지원하는 업체와 계약을 해야만 한다. (현재 한국 내 지원 업체 : KINX, LG U+)
선택지 3. Private Link
사용 사례 :상대방의 환경이 AWS 일 경우
NLB(network loadbalancer)만 사용 가능
초기 구축 시 기술적으로 조금 더 어렵고, NLB와 Route53에 대한 추가적인 설정 필요
장점!! 통신이 필요한 구간만 연결되도록 할 수 있기 때문에 안전한 네트워크 구성 가능 (private IP로 통신 가능)
그냥 peering을 할 경우 두 대상 간 통신이 완전 open 되기 때문에 이에 비해 안전하다.
선택지 3 채택! Private Link 앱 서비스와 페이 서비스 간에 필요한 경우에만 연결되도록 하고 이외에는 통신할 수 없도록 할 수 있다.
향후...
TGW 도입 : 네트워크 연동이 필요한 부분에 Hub & Spoke 구조로 개선
firewall 등을 이용하여 아웃바운드 접근제어 강화
비용 최적화 : Savings Plan, Reserved Instance, Graviton, S3 Storage Class
struct dirent {
/* Always zero */
long d_ino;
/* Position of next file in a directory stream */
long d_off;
/* Structure size */
unsigned short d_reclen;
/* Length of name without \0 */
size_t d_namlen;
/* File type */
int d_type;
/* File name */
char d_name[PATH_MAX+1];
};
typedef struct dirent dirent;
struct DIR {
struct dirent ent;
struct _WDIR *wdirp;
};
typedef struct DIR DIR;
주로 사용되는 systemcall prototype
static DIR *opendir(const char *dirname);
static struct dirent *readdir(DIR *dirp);
static int closedir(DIR *dirp);
static void rewinddir(DIR *dirp);
//directory라는 파일을 읽기 위해 사용하는 파일 포인터를 맨 앞으로 이동
