기본 콘텐츠로 건너뛰기

라벨이 aws인 게시물 표시

AWS는 몇 년 다녀야 할까요? 아무도 알려주지 않는 연봉 구조의 비밀..

듣기 버전 :  https://youtu.be/4F543vZqSi4 주변에 물어보니 생각보다 많은 사람들이 AWS의 SA가 되고 싶다거나 하는 이야기를 하는 사람들이 많네요. 그래서 실제 AWS에 다니는 사람에게서 얻은 정보를 기반으로 준비했습니다. Aws는 몇 년 다녀야 할까요? 갑작스럽게 제 친척이 된 사람이 있습니다. 갑자기 가족이 되어서 대학을 포기하고 바로 취업을 하려고 하는데 그렇게 되면 최종 학력은 고졸이 되어버려서 한국에서의 취직에는 타격이 크지요. 이 상황에서 어떻게 하면 빠른 시간내에 궤도에 오를 수 있는지 제게 상담을 해서 물어봤죠.. 아무리 어려워도 할 각오가 있냐고.. 그 사람은 각오가 되어 있다고 했습니다. 그래서 추천을 해주었지요. 바로 오라클을 배우고 직업을 구하면 안정적으로 성장할 수 있을 거라고 했습니다. 그는 근성으로 2년을 국비지원 교육을 받고 오라클 업무를 전문적으로 하는 SI업체에 들어갔습니다. SI업체는 빡시지만 초봉도 높고 많은 경험을 단시간에 배울 수 있어서 좋은 선택이라고 했습니다. SI업체에서 4년 다니다 보니 오라클 본사에 취직 기회가 생겼는데, 아마도 그의 열심히 하는 모습을 본 오라클 본사 직원지 추천해 준 듯 합니다. 그 때 제가 오라클 본사로 들어가면 생각보다 현업을 배우는 것보다는 오라클 제품에 대해 더 깊이있게 배우고 그걸 기반으로 고객을 지원하는 업무가 많을거라고 했습니다. 때문에 오래 다닐 사람에게는 좋지만 평생 직장으로 삼을게 아니라면 5년을 넘기지 말고 전직하는 것을 추천 했습니다. 5년 정도면 다음 직장에서 오라클에 다녔다는 좋은 이력이 생기니까요. 그는 저의 조언을 참고로 오라클에서 오래 다니려고 들어갔으나 내부 정치나 자기가 원하는 기술업무가 점점 줄어드는 여러가지 상황 때문에 5년 정도까지 버티고 다시 옮기게 되었습니다. 그 떄 또 몇 가지 선택지 중에서 조언을 해줬는데, 그 중에 AWS에서도 입사 기회도 있었지요. AWS에선 빡시지만 도움이 될테니 그 쪽으로 들어가면 괜찮을 거라 했는

당신은 AWS파? Azure파? 클라우드를 선택하는 기준을 설명드립니다!

듣기 버전 :  https://youtu.be/G7zSPa90kd8 AWS와 Azure중에 무엇을 선택하면 좋을지에 대한 질문이 좀 있어서 올려봅니다. 한국에선 당연히 AWS라고 하고 또 레밍스 하고 있잖아요? 하지만 일본에서는 Azure의 쉐어도 엄청납니다. 이유를 좀 알아봐야겠지요? 일단 세계 클라우드 쉐어 입니다. 다들 아시다 시피 AWS가 1위이지만 거의 성장이 멈추어 있고, 가깝게 추격하면서 싸우는게 Azure지요? 그런데, 일본 총무성에는 이런 자료도 있습니다. Microsoft가 17.2%로 1위네요? 제가 지난 DB선택 코너에도 말씀 드렸듯이 1위 라는 것은 무엇을 기준으로 하느냐에 따라 달라집니다. Microsoft는 클라우드 서비스 전체 매출이 1위입니다. 말이 되냐구요? 역시 한국에서보는 정보 만으로는 그렇게 될 수밖에 없지요.. 다양한 글로벌 정보를 보시면 도움이 될 것입니다. AWS와 Azure의 커스터머 사이즈를 볼까요? 가장 초대규모 커스터머를 AWS는 23%밖에 못쥐고 있는데 비해 Azure는 33%나 가지고 있습니다. 대규모 커스터머 역시 AWS는 23%에 Azure는 33%네요.. 그런데 AWS는 미들 이하 사이즈에서는 압도적입니다. 자, 한국에서도 다시 한 번 주변을 보시겠어요? 스타트업 등의 기업들은 당연히 AWS를 쓰지만 중대형 규모의 기업들은 AWS를 쓰시나요? 여기서 일본과 극명하게 달라지는데요.. 한국의 MS매출을 볼까요? 1조원.. 엄청나죠? 그럼 일본의 MS매출을 볼까요? 1조엔.. 언제나 제가 비교하는 자료는 한국 대비 10배정도 차이나고 있군요.. 제가 예전부터 MS랑 같이 일본에서 많이 일을 해서 듣는 얘기인데요.. MS의 일본 매출은 중국을 제외한 APEC전체 매출보다 높다고 합니다. 불법복제가 만연하는 한국에선 당연히 MS를 선호할리가 없지만, 일본에선 대기업은 당연하게 MS가 엄청난 수익을 내고 있고, 그 때문에 MS는 대기업의 규모에 따라서 담당 컨설턴트를 붙여서 Azure도입을 가이드 해주고 있습니다

AWS 관련 정보 정리 링크

AWS는 IOPS가 굉장히 민감하기 때문에  자기의 Instance가 지원되는 IOPS인지를 체크해야 한다.  Instance의 IO Network Bandwidth와 EBS의 Throughput 과 IOPS 중 하나라도 느리면 그 곳에서 병목이 발생한다.  EBS Specification:  https://aws.amazon.com/jp/ebs/volume-types/   EBS Volume Type :  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html 일단 정리용으로 대충 올려 놓음.. giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

요즘은 아키텍트(Architect) 되기가 더욱 힘들어진 거 같아요.

얼마전 aws위에서 mongodb를 올려서 서비스를 구성한 구성표를 보았다.  이 구성표를 만든 팀은 예전에 내가 도와준다고 했을 때 이미 많은 서비스를 mongodb를 이용해서 서비스 했다고 자만하던 팀이라 그냥 지켜보기로 했던 팀이었다.  2Core/4GB의 mongos 2대가 서비스 헤더, 1대가 관리헤더 2Core/4GB의 mongoc 3대가 metadata, 3대가 로그의 metadata.  4Core/16GB VM을 5대를 올려서 3대를 mongod를 올리고 2대를 서비스로그를 저장하도록 구성 했다.  물론 세세한건 보지 않았지만,  당연히 EBS가 30GB이니 30GB모두 하나의 shard로 하여 1 shard 3 replica 이지 않았을까? 안에서 추가로 쪼개기에는 EBS사이즈가 작으니.. 개발 서버 포함 총 15대의 VM으로 구성된 예상비용은 월 약1200달러.  이것을 26대로 늘리고 월 약 1100달러로 줄이는 설계를 보여줬다.  그리고 성능은 기존의 약 6배. 비용으로 환산한다면 월 7200달러 어치의 성능을 1100달러로 보여준 것이다.  AWS HW의 특성상 IOPS성능이 일반 HW보다 1/5 수준으로 떨어지는 것을 어떻게 메꿀 수 있는지가 중요하다. 특히나 EBS가 SSD라고 할지언정 물리적으로 연결되어 있는 디스크가 아닌 이상 Storage Network의 처리 성능이 가장큰 병목이 발생한다. (AWS 및 Storage를 Network로 연결하는 클라우드 아키텍쳐는 모두 같은 문제) 그리고 AWS의 특성상 1vCPU는 1Core가 아니다. 예전에는 1vCPU의 성능 수치가 있었지만 지속적인 하드웨어 추가로 인해 기존 하드웨어와의 CPU모델이 달라져 성능이 다르게 나오고 있어 이 지표는 사라졌다. 1vCPU의 성능이 얼마만큼 나오는지를 이해하여야 한다.  그 다음으로 Virtualization의 성능(Para-virtualization, Full virtualization)에 따른 퍼포먼스 저하가 얼마나 일어나는지, Linux라는

AWS에서 VM을 Gateway서버로 사용하기 - 텔레워크의 기초

요즘 텔레워크가 많아지면서 가장 큰 이슈가 보안 이슈이다. 이 중에서 특정 IP에서만 작업이 가능한 환경이 많다. 이 때문에 VPN을 준비해줄 여력이 없는 작은 기업 또는 프리랜서들은 자신만의 고정 IP가 필요한 상황이다.  이 경우 AWS에서 VM을 생성하여 VPN설정을 하는 경우가 많은데,  가장 많이 걸리는 경우가  일반적인 VPN프로토콜을 사용하는 경우  1723 Port외에 GRE Port를 오픈해 주어야 한다.  하지만 AWS에서는 GRE Port를 개방해 주지 않아서 멈춘다.  그렇다고 VPC를 direct connect를 이용하여 무지 비싸지게 구성할 수는 없다.  이 경우 openvpn만을 이용하여 UDP로 빠르게 구성할 수 있다.  우선 AWS에서 ubuntu vm을 small로 작은 것을 만들자.  그리고 openvpn인스톨 $ sudo apt install binutils $ sudo yum -y install openvpn 그 뒤에는 조금 복잡하지만 그냥 아래 커맨드를 복붙으로.. $ wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.6/EasyRSA-unix-v3.0.6.tgz $ tar -xvzf EasyRSA-unix-v3.0.6.tgz $ sudo mv EasyRSA-v3.0.6 /usr/local/EasyRSA $ cd /usr/local/EasyRSA/ $ cp -p vars.example vars $ vi vars set_var EASYRSA_CERT_EXPIRE 3650 $ cd /usr/local/EasyRSA/ $ ./easyrsa init-pki $ ./easyrsa build-ca $ ./easyrsa gen-dh $ ./easyrsa build-server-full server nopass $ ./easyrsa build-client-full client1 nopass 중간에 vi vars는 그 아래의 EASYRSA_CERT_EXPIRE값을 3

이제와서 물어볼 수 없는 퍼블릭 클라우드 vs. 프라이빗 클라우드 vs. 하이브리드 클라우드

사람들이 많이 사용하는 내용중에 퍼블릭 클라우드(Public Cloud), 프라이빗 클라우드(Private Cloud), 하이브리드 클라우드(Hybrid Cloud)라는 용어를 자주 사용하곤 한다. 이 외에도 인터 클라우드(Inter Cloud)라는 용어도 있다. AWS(Amazon Web Service)에서는 VPC(Virtual Private Cloud, 가상 프라이빗 클라우드) 라는 용어를 쓰기도 한다. 얘네들은 도대체 어떻게 구분을 하는 것일까? AWS처럼 일반인들을 대상으로 시스템을 제공해주고 그 틀에 맞추어 여러 사람이 같이 자원을 나누어 사용하면서 가격적인 매리트를 살린 것이 퍼블릭 클라우드(Public Cloud)이다. 대신 시스템을 그대로 사용해야 하기 때문에 시스템의 한계를 알고 이용을 해야 한다. 퍼블릭 클라우드의 장점은 쉐어를 하기 때문에 비용이 저렴하다는 것이다. AWS는 워낙 많은 기능을 서비스로서 제공을 하기 때문에 거의 한계가 없지만, U Cloud는 vNIC 기능이 안되어 IP를 두 개로 나누어 글로벌, 로컬 네트워크 처럼 나누거나 할 수 없다. Cloud N은 스토리지 이중화가 기본으로 되어있지 않아 스스로 두 배를 신청해서 동기 시키거나 백업을 시켜야 한다.(물론 RAID구성은 되어있지만..) Azure는 Elastic IP가 없어 서버를 리부팅 하면 IP가 바뀐다. 도메인 베이스로 설정을 해야한다. 프라이빗 클라우드(Private Cloud)는 직접 인프라를 가지고 있는데 이를 활용하여 클라우드 인프라 환경을 만들고자 할 때 사용한다. 이 때 많이 사용하는 툴이 VMWare, Hyper-V, Xen 등이 있는데 이를 자동으로 리소스풀링(Resource Pooling)을 하기 위해서는 각각의 관리 시스템이 필요하다. VMWare의 VCenter, Hyper-V의 System Center, Xen의 XenCenter 등이 바로 그것이다. 이러한 관리시스템은 고가이기 때문에 대부분 그냥 Hypervisor

Azure Cloud Compting

글로벌 노드를 구축하기 위해 AWS(Amazon Web Service)와 Azure를 테스트 하는 중이다. 모두들 AWS를 벤치마크해서 서비스를 준비하기 때문에 모든 기준이 AWS이다.. 그래도 MS의 Azure도 테스트를 해야해서 VM도 만들고 이것저것 해보았다.. 기본 성능 테스트를 했을때.. Azure의 성능이 AWS를 압도적으로 능가했다.. RDP의 반응속도나 SSH반응속도, 네트워크 처리속도등... 그럼 Azure만 쓰면 되는거 아녀? 하고 Azure로 LB까지 세팅해서 만반의 준비를 다 했다.. 서비스하려고 보니.. 응? IP가 바꼈넹.. AWS의 Elastic IP같은거 없나? 아무리 찾아봐도 없다. MS에 물어봤다.. 답변이 왔다.. "연내 출시할 예정입니다." .... 서비스를 하란 말이냐! 참고로, Azure는 VM하나하나 리부팅할때마다 IP바뀌는 것도 모자라.. Windows서버를 디폴트 세팅같은거 해서 실수로 LB밑에 VM 네 개가 수요일 새벽 3시에 동시 리붓하면... LB의 VIP(Virtual IP)도 바껴 버린다... =ㅅ=;;;; 어이어이... 이건 좀 아니지 않아? 결국... 훌륭한 인터페이스니 성능이 있어도.. 아직까지 일반 서비스로 하기에는... 좀.. 뭐, 도메인 베이스의 서비스를 한다면 가능할 수도 있겠지만..