코로나 4차 대유행 / 4단계 거리두기가 시작 되었다. 2학년인 둘째는 원격수업을 안 하다가 이번에는 시작하게 되었다. 컴퓨터 방에 컴퓨터가 옹기종기 모여 있지만 수업을 같이 하기에는 안 좋을 것 같아서 거실에서 수업을 들을 계획인데 노트북으로 수업을 하는 첫째에게 패드로 수업 듣는 친구가 있냐 물었더니 많다고 한다.
그래서 그냥 패드로 수업을 듣게 하려다가.. 첫째에게 패드로 수업 듣는 친구가 혹시 수업 듣기 어려운 점이 있는지 물었더니 의외로 많이 있길래 적어 본다.
수업시간에 손들기를 시키면 실제로 드는 경우도 있으나 이모지로 표현하는 경우가 있는데 패드의 경우 접근성이 떨어져서 순발력/순서에서는 느리다고 한다.
PC에서는 멀티보기로 선생님을 항상 고정하고 여러 친구의 모습을 볼 수 있는데 타블렛은 그참여자 한눈에 보는 슬롯이 적어 선생님을 항상 보면서 수업을 듣기 어려운 모양이다.
학교에서 학습지를 받아오지 못한 경우 출력을 위한 파일을 전달 받게 되었는데 패드에서 프린터 설정을 해 놓지 않았다면 인쇄를 못하는 친구가 있다고 한다.
타 사이트 오픈
선생님이 수업에 참고되는 사이트 링크를 주는 경우가 있는데 아이패드 사용자의 경우 카메라 연결이 끊기는 모양.
참고 사이트는 마우스 대응으로 되어 있고 터치 되응이 안되는 사이트가 적은 모양
영어는 퀴즐렛 과학은 가상 용수철 중력 실험 사이트
미술시간에 그림판으로 그리기를 하는데 패드는 할 수 없다.
카메라 위치 변경
노트북이나 패드는 카메라 방향 조정이 번거로운데 가끔 과제를 손으로 쓰고 있는 모습의 촬영이나 체육 시간에는 서서 율동하는 모습을 보여주려면 카메라 위치 조정이 수월해야 할 것 같다.
성능
타블렛 성능에 따라 원격수업 중에 화면이 끊기거나 급기야 선생님 목소리가 끊겨 들리는 듯 보인다고 한다.
나이가 만 41살이 되었다. 직장에서 꽤 높은 위치에 있는 것 같다. 나 스스로는 아직 젊다고 생각하고 사원 대리급과 농담 따먹기도 잘 한다고 생각하는데 그들은 나를 어떻게 생각할까? 마침 아내가 공직에서 30~40명을 거느린(?) 팀장이 되어서 처음 팀원들을 만날 때의 인상에 대한 얘기를 하다가 급 깨닫는 것이 있어 정리해 본다.
친한 친구와의 거침없음
나에게는 좋아하는 동생 둘이 있는데 나를 포함해서 3명이 있는 카톡방에서 그렇게들 서로 거침 없이 말을 뱉는다. 지금이야 익숙해 졌지만 사이가 안 좋거나 싸우는 줄 알았다. 시간이 지난 후 그들이 불알친구고 그럴 수 밖에 없다는 것을 알았다.
그런데 그 느낌이 뭔지 알 것 같다. 나도 학창시절 친구들을 만나면 그 때의 나이로 돌아가 말투가 그 때로 돌아간다. 그야말로 욕도 하면서 서로 까고 논다. 그러면서도 우리는 기분이 나쁘지 않고 즐겁다. 그 모습 또한 누가 보면 싸우는 것 같이 보이기도 할 것 같다.
가끔 만나는 친구들. 그 친구를 처음 만났을 때 그 느낌으로 대화 분위기가 바뀐다. 내가 몇 살이 되든 상관이 없다. 이렇듯 회사에서 만나는 사람과도 그 대화 방식이 고정이 되는 것을 느낀다. 물론 처음 어색할 때와 조금 친해지고 나서 조금은 바뀔 수는 있다.
첫 만남 그대로
처음부터 말을 놓는 사람은 나중에 더 가까워지면 꼰대가 되는 것 같고 처음에는 존대를 하다가 가까워져서 말을 놓는 하는 사람은 그래도 말투만 친해졌지 여전히 마음가짐과 태도에는 변화가 없는 것을 느낄 수 있다.
그래서 첫 인상이 중요하다고 하는가? 일종의 목표를 갖고 처음부터 확 휘어잡고 싶은 사람은 처음부터 말을 놓는 경우가 많다. 그것이 결국 그가 만나는 사람들과의 관계의 출발선이다. 처음부터 지위의 격차를 강조하고자 하는 사람이 만나는 사람은 아무리 친해지고 싶어도 이미 첫 인상이 그렇기에 반감이 생기고 굳어지게 마련이다. 그래서 그 이후에는 잘 하고 싶어도 결코 가까워질 수 없는 벽이 생기는 것 같다.
가족도 마찬가지
이 원리는 아버지와 나와의 관계에서도 나타나는데 아빠는 항상 나를 어린아이로 보는 것 같다. 아빠가 나를 이제는 어른으로 대해주길 바라지만 이미 성인이 된지 20년이 흘렀는데도 여전히 나는 아버지에게 어린아이다. 바꿀 수 없다.
나는 개발자니까 웬만하면 편하게 입는 편이지만 면접을 보거나 첫 만남을 가질 때는 거의 비즈니스룩을 하는 편이다. 그러면 꼭 편하게 입어도 되는데~ 라고 거드는 사람이 있다. 그렇지만 나는 첫 인상을 중요하게 여기므로 바뀌지 않는 편이다.
사람간의 관계에서 처음 굳어진 그 관계를 깨기란 어려운 것 같다. 그렇다면 나는 직장 생활에서 만나는 사람과의 관계를 어떻게 정리해야 할 것인가? 첫인상 첫 마음가짐 그것이 관계를 만드는 것이다.
장비, 네트워크 분야는 물리적인 H/W를 필요로 하는지라 공부에 대해 이론적 접근성 대비 실습과 그 실행에는 어려움이 많았습니다.
full stack 개발자로서 항상 아쉬운 것이 방화벽과 네트워크 서브네팅과 이중화 구성이었고
H/W의 제약사항을 없앤 것이 저에게는 클라우드 컴퓨팅의 매력이었습니다. 거기에 스케일링과 비용 효율화는 덤입니다.
그래서 이번에 full stack 개발자 + 아키텍팅 까지 다 해보자라는 생각이 들었습니다.
# 동시 취득을 목표로 하면 노력대비 성과가 좋음
그래서 aws solutions architect (이하 SAA) 공부를 시작했고 연속해서 certified Developer(이하 DVA) 까지 연속 취득 하였습니다. 각설하고 결론부터 말하자면 누구든 시작을 결심 한다면 이왕이면 2개를 동시에 따면 좋겠다는 것입니다.
합격에 도움이 되는 블로그가 많이 있어서.. 구지 제가 또 어떻게 하면 합격하는데 도움이 되겠다라며 적는 것은 정보 과잉을 양산하는 것이라 지양하고자 합니다. 2가지 시험을 보고 나니 거의 절반 이상의 내용이 겹쳐 있고 이왕이면 한번에 2개를 따면 좋겠다는 글과 코로나 시국에 aws 자격증 외에 언젠가 치루게 되실 온라인 시험에 대한 제 경험담을 적어보고자 합니다.
가용성을 지원하는 시스템 아키텍쳐, 네트워크 설계를 위한 Solutions Architect 를 공부하면서 배운 것 중에 절반은 Developer 공부에 중복되면서도 반드시 필요한 부분이었습니다. 그래서 Developer 공부는 매우 수월했고 복습하는 기분으로 훑고 지나가 공부 기간은 절반에 가까웠는데도 불구하고 합격 점수가 훨씬 더 높았습니다.
SAA를 따고 나서 하루이틀 결과 발표를 기다리는 와중에 사내 게시판에 자격증 2개 동시취득자의 글이 올라와 자극을 받게 되었습니다. 그 때 DVA 도 따버리자 라고 생각했는데 지금 생각하면 매우 잘 한 것 같습니다. 오히려 동시 취득을 안 했으면 억울 했을 것 같습니다. (그만큼 범위가 겹치는 부분이 많습니다.)
SAA 때는 대충 긴가민가 알고 넘겼던 것을 DVA 딸 때 더 깊이 공부할 수 있었고 DVA 공부하면서 알던 것을 SAA 할 때도 알았으면 더 높은 점수를 받지 않았을까 싶습니다. 그만큼 서로의 자격증이 상호 보완적입니다. 이런면에서도 2개 동시 취득을 강력하게 추천하고 싶습니다.
SAA는 전체적으로 모든 솔루션을 훓게 되며 DVA는 Code series (commit, build, deploy, pipeline) 그리고 cli 명령어의 파라미터의 이름과 DynamoDB 의 RCU, WCU 계산, 그리고 서버리스구축을 위한 aws gateway / lamba 그리고 cognito 에 집중됩니다. 또한 cloudformation 과 SAM 의 개념도 알아야 합니다.
# 공부방법 (유료 강의와 유료 덤프)
SAA 는 약 3주간 평일 풀타임 (15 업무일) 으로 공부를 하였으며 DVA는 2주 (10 업무일) 의 시간이 소요 되었습니다. 아마 반대 순서로 땄으면 거꾸로 DVA 15일, SAA 10일 걸렸을 것 같습니다.
Udemy에서 강의를 검색해서 들었는데 난생 처음 듣는 영어 강의였 습니다.
그런데 모두 그림이 친절하고 강의 특성상 엄청 천천히 발음을 친절하게 강의를 해줘서
사실 처음에는 지레 겁먹었지만 강의가 후반부에 갈 수록 1.5배속에 심지어 1.75배속으로 듣고 있는 저를 발견하게 되었습니다.
2개의 강의가 앞의 절반은 겹치고 뒷부분 반이 영역이 약간 나뉘게 되어서 DVA 강의 앞의 절반은 건너 뛰어 시간을 절약했습니다.
Udemy 에 예상문제 각각 6회 강의를 추가로 구매하였습니다. 유료 문제 풀의 강의의 강점으로는 내가 어느 부분에 취약한지 카테고리를 분석해 주고 문제 번호와 보기의 랜덤 배치로 재 시험을 치룰 수 있습니다. 또한 실제 시험과 같은 자세를 취할 수 있도록 도와줍니다.
Udemy 는 최초 가입시 모든 강의가 만원 중반으로 결제 할 수 있고, 다음 강의는 장바구니에 넣어두고 결제 안하고 있으면 이메일로 왕창 할인 해줄테니 결제 해달라고 쿠폰이 오고 아니면 이메일을 여러개 만들어서 결제 하면 됩니다. 모두 만원대에 결제 하였습니다.
일단 강의 1회 수강 예상 문제를 풀고 틀린것에 대해서 aws 공식 문서를 읽고 시험 전날, 다시 다 풀어보고 그래도 또 틀린 것을 다시 aws 공식 문서를 보는 순으로 진행 하였습니다.
# 시험은 aws FAQ 문서에서
강의 외 내용이 시험에 나오면 구글에서 검색을 하면 거의 모든 문서가 검색이 되기는 하는데 aws 공식 문서의 한글 버전은 대부분 기계 번역이라 잘 이해 안되는 것은 영어로 보거나 본문을 구글 번역기로 돌리면 훨씬 이해하기 쉽습니다. FAQ 에는 사례와 해결 방법이 많이 나오는데 모두 다 시험 예상 문제 입니다.
다른 블로그를 참고해도 덤프 보는 것보다 FAQ를 정독하라는 얘기도 많이 볼 수 있습니다.
덤프를 공유해 달라는 등의 요청을 가끔 받게 되는데 인터넷에 널린게 덤프입니다. 찾아내는게 어렵지가 않습니다. 다만 몇가지 풀어보니 오답이 너무 많습니다. 오답을 외우는 사람이 없기를 바랍니다.
위에서도 썼지만 udemy 에서는 유료 예상 문제 과정을 제공합니다. 질문하면 답도 잘 달아주고 특히 SAA는 한글 문제 풀이 과정이 있어서 수월했습니다. (문제는 기계번역된 FAQ로 문제를 낸거라 문제 자체의 이해가 어려움)
바쁜 현대인에게 필요한 것이 덤프로 합격하는 것인지 강의를 듣고 배움을 내재화 하는 것인지는 본인이 판단하면 되겠습니다. 그럼에도 덤프는 여전히 필요합니다. 공부를 하고, 내가 모르는게 무엇인지 체크하는 최적의 방법입니다. 하지만 공부를 하기 전에 일단 덤프로 모르는 것을 하나씩 찾아 나가는 것도 틀린 방법은 아니라 하겠지만.. 전체적인 흐름을 한번이라도 보는 것이 여전히 고집스럽게 좋은 방법이라고 말하고 싶습니다.
# 시험 문제와 현행화 준비
실제 시험 문제가 랜덤이라 아까 낸 문제를 왜 또 내지? 싶은 문제도 있습니다. 혹은… 특정 제품의 사용을 밀고 싶어서 시험응시자들를 세뇌시키는 것은 아닌가 싶기도 했습니다. aws 시험문제가 재밌는게 5줄이라 치면 4줄은 거의 상황 설명이고 마지막 한두줄만 시험에 필요한 내용이라 시험을 치면서도 이럴때 이렇게 하면 되겠구나라는 상상의 나래를 펼치게 만들어 주어서 문제를 읽어 보는 것 만으로도 많은 배움을 얻게 됩니다.
시험문제의 현행화가 꽤 변수입니다. 불과 몇개월 전까지만해도 되지 않던 기능이 “이제 됩니다!!” 라고 홍보 기사가 올라 오면 그게 시험문제로 나오는 경우가 있습니다. 기존 경험으로는 당연히 안되던 것인데 이제는 오답일 수 있습니다. 예를 들어 s3 의 GetObject 는 원래 eventual consistency 인데 2020년 12월 부터는 strong consistency 입니다.
시험은 한글로 신청 하면 기계 번역된 한글 문제가 나오는데 “English” 라는 버튼을 누르면 원문을 볼 수 있어 대조 이해가 가능합니다. English 에 자신이 있다고 하더라도 한글 버전과 영문 버전을 동시에 볼 수 있는 것이 문제의 이해에 도움이 될 것 같다는 생각이 듭니다.
# 온라인 시험 준비
시험은 온라인 (피어슨뷰) 으로 치루었는데 노트북 화상카메라를 통해 감독관이 계속 쳐다보고 있는 가운데 치뤄지게 됩니다.
당일 예약은 안되는 것 같고 익일 24시간 중에 선택 할 수 있는데 일요일은 그 시간이 매우 한정적이라 없다고 보면 됩니다. 시험 날짜가 몇가지로 정해져 있으면 좋은데 내가 마음껏 선택할 수 있으니 자꾸 하루이틀 미루게 되는 것 같습니다. 목표일자를 정하지 않으면 공부 기간이 길어져서 점점 피곤해 집니다. 내일 보자! 고 결정하는 결심히 매우 중요합니다. 결제는 회사 법인카드 (visa 카드임) 로 진행합니다.
시험 10분 전에 피어슨뷰 등 싸이트에 로그인해서 전용 시험 코드를 확인 하고 미리 다운로드 해둔 전용 브라우저에 코드를 입력해서 로그인, 휴대폰에 전송되는 링크를 통해 시험실 동서남북을 사진찍어서 업로드 해야 하고 여권도 찍어 올려야 합니다.
시험이 시작되면 감독관과 약간의 대화를 하게 되는데 pardon? text me please~~ 등으로 하면 친절하게 채팅으로 대화를 전환한다.
노트북을 들어서 책상 밑을 찍어보라는 둥 몇가지 요구사항을 충족하면 시험을 시작한다. 저의 경우는 토즈 독서실의 2인 회의실에서 시험을 치뤘습니다. 시험 치루는 중에 손이 닿는 곳에서는 아무것도 없어야 한다는 조건을 만족시키기에 적절한 공간이었습니다. 벽면에 토즈 독서실 이용하는 방법에 대한 코팅 인쇄물이 붙어 있어 첫 시험에는 가림판으로 가렸고 두번째 시험에서는 뜯어버려야 했습니다.
전용 브라우저를 PC/mac 에 미리 설치해서 시스템 호환성을 미리 체크 하세요. 크롬북은 안될 수 있습니다. 참고로 호환성 체크할 때는 문제가 없었는데 막상 시험 때 휴대폰 테더링으로 시험을 시작하니 영상이 안 보인다 하여 급히 토즈 wifi 로 변경하여 겨우 시험을 치뤘습니다. 두번째는 랜선을 가져가서 유선으로 시험을 치루었습니다.
# 온라인 시험 단축키 팁
마우스로 정답을 찍어도 되고 단축키를 이용해도 됩니다. 보기 abcd 는 키보드로 타이핑 하면 정답이 체크 되고 다음 문제는 alt+N 이전 문제는 alt+P 등을 이용해 네비게이션 할 수 있습니다. 갑자기 단축키가 잘 안되는 경우가 있는데 몇번 해보니까 alt+tab 을 눌러보면 (실제로 화면 전환은 없지만) 갑자기 다시 잘 됩니다. 단축키에 익숙해 지시면 시험에 더욱 집중하는데 도움이 되실 것 같습니다. 주의할 점은 abcd 를 한번 더 누르면 정답 체크 한 것이 uncheck 가 되어 나중에 전체 검토 화면에서 풀지 않은 문제로 표기 됩니다. alt+F 로 flag 를 걸어서 헛갈리는 문제만 나중에 검토할 수 있습니다. ctrl +- 로 문제 폰트의 크기를 키우거나 줄일 수 있습니다. 폰트가 너무 커서 미처 보기를 다 보지 못할 정도로 확대 되었다고 판단되며 보기가 더 있는데 다음 문제 풀거냐는 경고도 친절하게 해줍니다.
# 온라인 시험 마무리
시험 문제 검토 후, 제출 버튼을 누르면 진짜 제출하겠냐는 조마조마한 버튼이 또 한번 나오고. 돌이킬 수 없는 버튼을 누르는 순간 합격 여부가 표시 됩니다. 혹시 떨어진 경우의 실망감을 감독관이 감당할 필요 없도록 하는 배려인지 제출 버튼을 누른 순간부터 감독관도 사라져 버립니다. 그래서 카메라는 켜 있는 와중에 그냥 노트북 뚜껑을 닫아버리고 집에 가도 무관합니다. 이미 당락은 결정 난 것입니다.
# 다음 목표
다음 시험으로는 Solutions Architect Pro 또는 DevOps Pro 로 다음 자격증을 노려보려고 합니다. 이 또한 많은 부분이 겹칠 것이나 pro 자격증은 여전히 객관식이지만 2개 심지어는 3개 이상의 복수 정답을 골라야 하므로 찍어서 맞추는 일은 없을 것 같습니다.
실기도 없는 객관식 자격증이라는 것이 꼭 아키텍처와 개발자 역량으로 확실히 구별지어지는 부분은 아니라서 (아느냐 모르느냐 vs 할 수 있느냐 없느냐) 일단 각각의 자격증의 예상 문제지를 풀어보고, 왠지 더 많이 알 것 같은 자격증을 노리는 것도 수월한 합격에는 도움이 될지도 모르겠습니다.
이번에 두번째 제안 작업을 시작하게 된다. 인생에서 처음으로 제안서를 썼을 때는 제대로 정리가 되지 않았던 것 같은데.. 이제 조금은 알 것 같다. 제안서도 일종의 면접이다. 내가 아는 기술을 총 동원 하되, 실제로 할 수 있는 범위 내에서 써야 한다. 내가 낸 답안지가 회사의 답안지고 고객이 채점을 한다. 그런데 고객 요청사항에 엉뚱한 대답을 했다면 그것을 채점하는 고객이 얼마나 민망할까? 우리 회사를 다시 쓰고 싶을까?
제안서는 우리 회사의 기술력이 대변되는 것이다. 혹시 떨어지더라도 다시 만날 준비는 되어야 하므로, 완전하지 못한 답변은 면접관 앞에서 헛소리를 하는 것이랑 다르지 않는 것 같다. 그래서 제안서 작업은 그야말로 “미리 준비된 자들의 집합”의 마스터 피스가 되어야 한다. 그런 관점에서 보면, 면접자가 면접에 합격을 하기 위해 최선을 다하듯 회사도 최선을 다 해야 한다.
그런데 최선을 다한다는 것이 무엇일까? 회사는 조직이다. 한순간 최선을 다한다는 명목으로 관련해서 아는 모든 직원을 한 곳에 모을 수는 없다. 다행인 것은 경쟁 관계에 있는 회사라고 해서 그렇게 하는 것도 아닐 것이다.
그래서 제안 요청사항의 전문적인 분야에 능통한 팀에 무언가를 부탁해서 제안서를 완성하는 것을 기대하는 것은 쉽지 않은 일이다.
그럼에도 제안이 선택되기 위해서는 마스터피스를 만들어야 한다면 기술 난이도가 깊은 사람도 필요하고 두루두루 알고 경험을 해 본 사람도 꼭 필요하다. 젊었을 때는 기술의 난이도만을 중요하게 생각했고 나이가 들어가면서 개발자에서 PL 이나 아키텍처로 가는 길은 되도록 피해왔던 것 같다. 하지만 누군가는 분명히 다방면의 기술을 아는 사람도 필요하겠다는 생각이 든다.
요즘과 같은 세상에는 어떤 문제에 대한 해결책을 찾아내고 제품을 선정하는 것은 어려운 일이 아닌 것 같다. 기술적으로 적용하는 것은 예제가 많아서 접근성이 좋다. 그러나 올바른 설계에 대해서는 해답이 없다. 다양한 best practice 를 탐독하고 경험하며 설계 자체의 고민을 할 수 있는 시간이 나에게 주어져서 다행이다.
다음의 가이드를 따르면 되는데, 이 가이드를 따르면 java client 가 parameter store 에서 값을 가져오기 위한 access key 를 알아야 한다. 그러나 ec2 자체에 해당 IAM role 을 부여 했다면 그럴 필요도 없다. system 에서 curl 등으로 paramter store 의 값을 가져와 java에서 로딩 하면 된다.
DNS의 A 레코드에는 IP 가 지정되어 있으므로 쿼리시 바로 반환하고 CNAME 레코드는 일종의 symbolic link 와 같이 연결된 레코드를 반환한다. 그럼 연속해서 A 레코드 까지 찾아가서 IP를 알아낸다.
RDS 의 endpoint 는 mydbname.xrandomx.as-east-2.rds.amazonaws.com 등으로 외우기는 어렵게 복잡하게 만들어지고 aws 에서는 cname 을 사용해서 간소화 할 수는 있다고 한다. 이는 aws의 route 53 dㅔ서 A alias 에서 선택이 안되므로 어쩔 수 없는 선택사항 이기는 하지만 왜 A alias 로는 선택을 못하게 했을까가 의문이었다.
그러나 S3, Cloudfront, Elastic Beans Talk, ELB 등은 A alias 의 사용을 할 수 있도록 되어 있다. 게다가 이 때 사용하는 route 53 사용료는 무료.
Cloudfront 의 aws 에 의해 주어진 URL에 대해서 A alias 가 아닌 CNAME 을 사용하면 어떻게 될까?
에서 설명하고 있듯 CNAME 으로 xrandomx.cloudfront.net 을 cf.mydomain.com 으로 간소화 하면 cf.mydomain.com 을 lookup 했을 때 xrandomx.cloudfront.net 의 모든 IP가 다 나오는데 cf가 ipv6 를 지원하며, 사용자 입장에서는 ipv6와 ipv4 를 선택지로 받게 되고 우선순위에 따라 ipv6 부터 라우팅 하게 된다.
에 따르면, 이론적으로 NAT 를 할 필요 없는 IPv6 가 빠르지만 IPv4의 성숙도 때문에 IPv4 가 더 빠르다고 한다. 따라서 CNAME 으로 CF 의 주소를 지정하면 빠르게 하려고 선택한 CF 가 오히려 느리게 될 수 있다.
aws 에 의해 A alias 로 target 지정이 (선택이) 가능한 서비스는 위에 언급한 대로 CF, LB, S3 등 속도에 민감하며, IP가 언제든 바뀔 수 있으며, 특히 외부에 직접적으로 노출 해야만 하는 상황이 있는 솔루션 들이다. (그 각각 서비스의 endpoint 주소가 사용자 브라우저에 노출되면 이쁘지 않을 수 있는) 그리고 alias 에 대한 사용료는 aws 에 내지 않아도 된다. (CNAME 은 호출 사용료를 낸다.)
이 좋은 서비스 (A alias) 를 왜 RDS 등에는 제공하지 않을까?
이는 대외적으로 Open 해야만 하는 서비스 s3 나 CF의 주소에 대해서는 비용을 받지 않고 대외에 오픈할 필요가 없는 endpoint 주소에 대한 단축에 대해서는 (사실 꼭 해야만 하는 이유가 없는) 그 사용 비용을 받겠다는 뜻 같다.
에 의하면 100만건의 호출에 대해서 0.4$ 다. 만일 하루에 SQL쿼리를 서버에 몇번이나 날릴까? 하루에 10000건의 주문을 처리 하는 쇼핑몰이 있다고 치더라도 상품 조회를 위해서 수십배 많은 select Query 가 DB로 날라간다. 최종 사용자 들이 웹서핑을 하는 량에 따라 1백만건은 우습게 호출될 수도 있다. 그래도 고작 하루에 500원이다. 장애가 있거나 APP 배포 없이 DB를 교체 해야 하는 필요가 있는 경우가 있어 resonable 하다.
aws에는 랜덤으로 제시하는 URL이 많이 있는데, 이것을 모두 route53 에 등록해 둔다고 하면, 수조개의 쿼리가 route 53 에 집중 될 수 있을 것이다. on-premise DNS 서버를 쓴다고 하더라도 요청이 집중되는 것은 매한가지. 단지 endpoint URL 이 이쁘게 보이는게 다가 아니다.
RDS 의 endpoint 는 Multi-AZ를 고려한 DNS CNAME 이다.
RDS 도 죽는다. aws 가 무적은 아니다. DB 가 설치된 실제 장비의 네트워크가 죽거나 하드 디스크가 망가지거나 하면 sync 로 복제된 예비 장비로 RDS endpoint 가 이동한다.
예를 들어 RDS가 제공해준 DB 주소가 다음과 같다.
dbname.xrandomx.ap-east-1.rds.amazonaws.com
RDS console 에 들어가면 현재의 DB가 어느 AZ 에 위치하는지가 나오고 예비 DB의 zone 도 확인 가능하다.
nz@nzmain:/mnt/c/Users/nzin4$ nslookup database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com
Server: 172.21.32.1
Address: 172.21.32.1#53
Non-authoritative answer:
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com canonical name = ec2-3-227-127-64.compute-1.amazonaws.com.
Name: ec2-3-227-127-64.compute-1.amazonaws.com
Address: 3.227.127.64
nz@nzmain:/mnt/c/Users/nzin4$ host database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
ec2-3-227-127-64.compute-1.amazonaws.com has address 3.227.127.64
endpoint URL 로 lookup 또는 host 를 확인해 보면진짜 endpoint 는 ec2-3-227-127-64.compute-1.amazonaws.com 임을 알 수 있다.
하지만 우리는 main DB 장애 발생시에 자동으로 secondary zone 으로 전환해주는 RDS 의 multi-az 기능을 사용하므로 ec2-3-227-127-64.compute-1.amazonaws.com 를 직접 사용해서는 안될 것이다.
이제 failover 를 지원하는 리붓을 해 보면 어느 순간 RDS의 호스트 값이 바뀌는 것을 알 수 있다.
nz@nzmain:/mnt/c/Users/nzin4$ while true; do host database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com; sleep 5;done
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
ec2-3-227-127-64.compute-1.amazonaws.com has address 3.227.127.64
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
ec2-3-227-127-64.compute-1.amazonaws.com has address 3.227.127.64
...
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-35-174-35-60.compute-1.amazonaws.com.
ec2-35-174-35-60.compute-1.amazonaws.com has address 35.174.35.60
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-35-174-35-60.compute-1.amazonaws.com.
ec2-35-174-35-60.compute-1.amazonaws.com has address 35.174.35.60
리붓이 끝나더라도 이미 main db는 아까 secondary Multi-AZ의 DB가 main 으로 대체 된다.
us-east-1f 새로운 DB가 main 이 되었다.
host 조회시에 다음과 같이 조회가 되었는데
database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com is an alias for ec2-3-227-127-64.compute-1.amazonaws.com.
왼쪽은 조회한 것 우측은 CNAME 의 value 를 말한다. 즉 database-1.ch08nkgye4rw.us-east-1.rds.amazonaws.com 가 RDS 가 제시해준 대체 도메인 이름 (CNAME) 인 것이다.
나도 한때는 맥을 사용했다. 한 5년정도? 맥을 버린 이유는 2010년 당시 eclipse IDE 와 호환성이 별로였기 때문인데 마우스 없이 되는 것이 좀 있었던 기억이 난다. package explorer 에서 우측 클릭하면 tree 가 안 열렸는데 정확한 기억은 아니지만 뭔가 윈도우보다는 마우스를 써야만 하는 것들은 분명히 있었다.
2012년부터 windows 로 돌아왔고 약 10년 째 window 서버를 운영하고 있다. 왜냐면 노트북이나 타블렛에 돈을 많이 쓰고 싶지 않아서이기 때문이다. 항상 3G 무제한 테더링을 하면서 필요한 일이 있으면 서버에 붙어서 작업을 했다.
요즈음에도 뭔가 일이 있으면 일단 mstsc 로 원격으로 붙곤 한다. 예를 들어서 휴대폰을 수리 하러 가거나 어디 호텔에 PC를 잠깐 쓰더라도 일단 내 서버에 붙으면 무엇이든 빠른 속도로 할 수 있다.
개발자로서 많은 램을 필요로 하고 좋은 노트북에 돈을 많이 쓰기는 싫다. 16G 램이 달린 비싼 노트북을 살 수는 없다는 것과 터치되는 노트북이 없다는 것이, 바로 내가 맥으로 가지 못하는 이유인 것 같다.
또한 CPU 를 많이 사용하는 작업을 모바일 디바이스에서 하면 필연적으로 배터리를 많이 쓰게 된다. 또한 조용한 곳에서 쿨러가 돌게 만드는 것 또한 하기 싫다.
나는 thin client 가 좋다. 쿨러가 없어도 좋겠다. 그저 원격 터미널에만 잘 붙으면 좋겠다. 그러나 안드로이드나 mac 에서 윈도우 서버로 원격 터미널에 붙게 되면 windows 단축키나 한/영 전환에 어려움이 있다. 한/영전환은 크롬북에서도 잘 되지만 shift 가 계속 눌린채로 유지되는 버그가 있다.
거의 7년동안 무제한 3G 54 요금제를 SKT 로 쓰다가 v50 대란 때 LGUplus 로 넘어왔다. 그런데 신나게 테더링을 하는데 어느날 부터 안되는 것이다. 데이터 쉐어링 용량은 따로 제한이 있다고 한다. 상담을 받아보니 LTE 부터 생겼고 SKT 도 같을 것이라는 것이다.
인터넷 검색하면 APN 을 바꾸면 된다는데 뭔가 잠겨 있다.
v50 네트워크 모드를 진입한다 전화 앱에서 다음과 같이 입력
전화 앱 > 5457#*500# 입력
Service Menu 라는 화면에 진입하게 되는데 맨 밑에에서 6번째쯤 메뉴에 APN 편집이 언체크 되어 있다. 이것을 체크하고 나온다.
설정 > 네트워크 탭 > 모바일 네트워크 > 액세스 포인트 이름
에 접속하면 우측 상단에 … 메뉴 버튼을 누르면 APN 추가를 할 수 있다.
이름 : lg 5g
APN : internet.lguplus.co.kr
우측 상단 … 메뉴 > 저장
