galera 테스트를 진행하면서 블로그의 max connection을 테스트 할수 있었다. 한계는 명확했다. 50...! 50...!!!!!!!!!! 50!!!!!!!!!!!!!!!! t2.micro 사이즈 의 rds 의 max_connections는 134 인데 50까지 밖에 안된다는건 역시 web의 문제일 확률이 크다. php-fpm에서 문제를 확인할수 있었는데 바로 알게된 이유는 apache의 제한은 그보다 크게 설정되어있기 때문이다. $cat /etc/php-fpm.d/www.conf | grep pm.max_children pm.max_children = 50 => 150 $systemctl restart php-fpm php-fpm 에서 사용할수 있는 자식프로세스 개수를 150개로 변경하였다. 이만하면 충분히 web 인스턴스를 죽일수 있을거라 생각된다. 동접자만 확인하면 되는데 쓸데없이 흥분해서 30000번의 테스트를 보냈다. ...

지난 포스팅에 이어서 맺음하는 포스팅이다. 계획은 일주일 이었으나 이주 가까이 galera를 사용하였다. 이주동안 사용량이나 봇들의 동태 이것저것 모니터링을 했지만.. 부하가 없었다.. 그래서 부하테스트는 직접하기로 마음을 먹었다! 먼저 비용부터 보자. Cost Explorer 에서 일별 서비스별로 본 그래프이다. 여기서 중요한건 EC2 비용인데 0.47$ 정도다. t3.nano 3대 하루 비용인데 1달정도 하면 14.1$ 정도 나온다. 정말 얼마 안나온다. 깜짝놀랄정도. 그렇다면 성능을 확인해 볼까? 구성을 나열하자면 NLB-mariaDB-cluster(t3.nano 3ea) 간단한 구성이다. 지금 이 블로그로 테스트를 진행하여 보았다. ...

문제는 아래 URL 에서 발췌하였다. https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf 영문 You are building a website that will retrieve and display highly sensitive information to users. The amount of traffic the site will receive is known and not expected to fluctuate. The site will leverage SSL to protect the communication between the clients and the web servers. Due to the nature of the site you are very concerned about the security of your SSL private key and want to ensure that the key cannot be accidentally or intentionally moved outside your environment. Additionally, while the data the site will display is stored on an encrypted EBS volume, you are also concerned that the web servers’ logs might contain some sensitive information; therefore, the logs must be stored so that they can only be decrypted by employees of your company. Which of these architectures meets all of the requirements? ...

더미파일 생성 $dd if=/dev/zero of=/root/swapfile bs=1024 count=2000000 1580109+0 records in 1580109+0 records out 1618031616 bytes (1.6 GB) copied, 23.3556 s, 69.3 MB/s 생성된 파일 확인 $ll /root/swapfile total 1580112 -rw-r--r-- 1 root root 1618031616 Sep 7 20:24 swapfile swapfile 에 권한 생성 $chmod 600 /root/swapfile swap 생성 $mkswap /root/swapfile Setting up swapspace version 1, size = 1.5 GiB (1618026496 bytes) no label, UUID=89d2f092-7fee-4fa2-854a-77a914e79367 swap 마운트 $swapon /root/swapfile $free -m total used free shared buff/cache available Mem: 983 136 75 18 771 669 Swap: 1543 0 1543 swap 자동 마운트 rc.local 하단에 추가 ...

패스워드 유효성 검증 로그인 실패 5 계정 잠금 5분 $vi /etc/pam.d/common-auth 16번째줄 삽입 auth required pam_tally2.so file=/var/log/tallylog deny=5 even_deny_root unlock_time=300 $vi /etc/pam.d/common-account 16 줄에 삽입 account required pam_tally2.so 패스워드 만료 모듈 설치 #apt-get -y install libpam-pwquality 패스워드 만료 모듈의 경우에는 사용자를 새로 만들때만 영향을 줍니다. 따라서 기존유저에 적용시에는 명령어로 지정해주어야 합니다. 패스워드 사용가능 최대 기간 #chage -m (days) (user) PASS_MAX_DAYS 180 패스워드 사용가능 최소 기간 #chage -m (days) (user) ...

safari 계열의 브라우저에서 내 블로그가 정상적으로 열리지 않았다. 여러번 시도해야 열렸고, 한번에 열리지 않았다. 이원인을 찾기위해서 로그분석부터 부단한 노력을했으나, 한동안 해결할수 없었다. 그런데 어제 오픈카톡방의 박주혁 님께서 safari에서 정상적으로 열리지 않는다는 스크린샷을 올려주셨다. 인증문제가 아닐까 생각했지만 인증문제는 아니었고 이문제를 해결하기 위해선 내 웹서버의 설정을 설명해야 한다. amazon linux에서는 httpd-2.4.39-1.amzn2.0.1.x86_64이 기본으로 설치되는 apache 이다. 그리고 php는 여러가지 버전을 repo로 지원하고 있는데 amazon-linux-extras 명령어로 사용가능한 repo를 확인할수 있다. 일단 이부분에서 내가 old한 엔지니어라는 사실을 알았다. 나는 apache-php 연동은 반드시 module로 연동을 한다. 그런데 amazon linux는 amazon-linux-extras install php7.3 명령어를 사용하면 module로 설치하는 것이 아닌 php-fpm 방식으로 php가 설치된다. ...

문제는 아래 URL 에서 발췌하였다. https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf 번역은 google 번역기이며 알아보기 어려운 부분을 조금 수정하였다. 실제 수정한것은 3번문제 조금이며 대부분 구글번역기를 의지하였다. 이번 글에선 3번문제 까지 풀이하였으니 참고바란다. 오역은..구글신님께 확인하시길 바란다. 틀린문제나 오역 오타 테클 환영하오니 이상한부분이 있다면 언제든 댓글달아 주시라! 1번 문제다. 원문 Your company’s on-premises content management system has the following architecture: – Application Tier – Java code on a JBoss application server – Database Tier – Oracle database regularly backed up to Amazon Simple Storage Service (S3) using the Oracle RMAN backup utility – Static Content – stored on a 512GB gateway stored Storage Gateway volume attached to the application server via the iSCSI interface Which AWS based disaster recovery strategy will give you the best RTO? Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Generate an EBS volume of static content from the Storage Gateway and attach it to the JBoss EC2 server. Deploy the Oracle database on RDS. Deploy the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon Glacier. Generate an EBS volume of static content from the Storage Gateway and attach it to the JBoss EC2 server. (Glacier does help to give best RTO) Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Restore the static content by attaching an AWS Storage Gateway running on Amazon EC2 as an iSCSI volume to the JBoss EC2 server. (No need to attach the Storage Gateway as an iSCSI volume can just create a EBS volume) Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Restore the static content from an AWS Storage Gateway-VTL running on Amazon EC2 (VTL is Virtual Tape library and doesn’t fit the RTO) ...

홍콩 / 바레인 리전이 리전 리스트엔 있으나 들어가면 활성화 하라고 뜬다. 이전에는 리전 선택버튼이 비활성화로 되어있었다. 여기에서 홍콩이나 바레인 을 선택하면 아래와 같은 페이지가 뜬다. 계속을 눌러서 활성화로 가는것도 가능하다. 그게 아니라면 내계정으로 이동후에 저기 빨간부분에서 활성화 누르면 된다. ..... 원랜 선택이 비활성화 였는데 메뉴가 좀바뀌었다.. 뻘쭈미..태그안쓰고 포스팅해야징...

고객사에서 ubuntu user 에 777 퍼미션을 부여해 버렸다. chmod -R 777 /home home 디렉토리 하단으로 모든 퍼미션이 777이 부여되었고 ubuntu계정까지 777 권한이라 KEY를 사용하여 로그인을 할수 없는 상태가 되어버렸다. 이경우에 할수있는 방법은 SSM session manager로 접속할수 있다면 간단하게 해결되었을 문제이나 신규로 생성된 인스턴스인터라 SSM을 사용하고 있지 않았다. 이경우엔 다른인스턴스에 /home 파티션만 떼서 붙여서 권한을 복구한다음에 정상화 할수 있었다. session manager 는 권한과 상관없이 동작하는지 확인하고 싶었다. 세션 매니저로 접속 root 15229 1.0 1.5 543752 15912 ? Sl 10:30 0:00 _ /usr/bin/ssm-session-worker root-0f7a9e1a4bbc90b i-052ebb4feade551 ssm-user 15242 0.0 0.3 124264 3280 pts/0 Ss 10:30 0:00 _ sh ...

갑자기 블로그가 안열렸다. 따로 모니터링을 설정한건 아니라서 다운된지 몰랐다. 먼저 aws console 에서 인스턴스의 상태를 확인해 보기로 했다. 상태검사를 통과 하지못한 인스턴스가 확인된다. 이럴땐 ec2 상태검사 탭을 확인한다. 서버가 죽은지 벌써10시간째. 모니터링을 설정해 놨어야 했는데 불찰이 느껴진다. 일 단 트러블 슈팅을 시작한다. 첫번째로 로그인을 진행해 본다. ssm 세션매니저를 통해서 접속해본다. 응. 안돼. 돌아가 접속할수 없다. 그럼 차선책으로 인스턴스의 스크린샷을 확인해 본다. 인스턴스 설정에서 시스템로그 가져오기는 dmesg 를 보여준다 그래서 이경우에 필요가 없다. 인스턴스가 행이 아니라 리부팅중 멈추거나 인스턴스 부팅 장애의 경우에는 시스템 로그가져오기로 봐야한다. ...