맥북 면접준비 백업
플젝
직접 구현한 API 중 기억나는 API
테이블 구성은 어떤 식으로 했는지
Delivery와 order table을 다대일 관계로 연결했고 order table과 product table을 일대일 관계로 연결했습니다. 우선 delivery table과 order table은 주문이 들어오면 채워지는 table이고 product table은 미리 store에 있는 item을 등록해 놓은 table입니다. Delivery table에서는 주문의 user정보,시간정보, 주문상태 정보 등을 저장하고 order table에서는 어떤 product가 몇 개 주문됐는지를 product별로 관리합니다.
Q. 기술적인 도전은 뭐했어?
Aws lambda와 DB 다중 컬럼 indexing이 가장 큰 도전이었다.
Q. 컨테이너가 뭐야?
컨테이너는 어떤 환경에서나 실행하기 위해 필요한 모든 요소(library, dependency, binary)를 포함하고 운영체제를 가상화한 소프트웨어 패키지입니다. 컨테이너는 운영체제를 가리지 않고 어느 환경에서나 구동되므로 개발 및 배포가 크게 쉬워집니다. 컨테이너는 다른 애플리케이션으로부터 논리적으로 격리된 OS 환경을 제공합니다.
Q. MySQL 선택한 이유는 뭐야?
스키마가 설정되어 있어서 table에 data를 추가할 때 안정성이 보장된다.
table간에 관계를 설정할 수 있어서 중복 data가 매우 적어져 용량이나 일관성 관리에서 효율적이다.
현업에서도 data 수정이 필요없고 table간의 관계가 없는 경우이거나 정말 엄청 많은 data가 요구되는 것이 아니면 NoSQL은 사용하지 않는다고 알고 있다.
Q. 트래픽 관점에서 대처했던 부분은 있어?
INDEXING
ColdStart
Lambda를 사용할 때 가장 큰 문제점. eventTrigger를 붙일 수 있는 특성 때문에 높은 트래픽이 터졌을 때 scaling을 시행해주는 함수를 실행하면 높은 트래픽을 감당할 수 있을 것이라 생각했다. 하지만 실제로는 coldStart issue 때문에 잘 작동하지 않는다. Aws lambda가 실행되기 위해서는 instance가 떠있어야 한다. 하지만 lambda function의 실행사이의 간격이 클 경우 instance는 내려간다. 그러면 다음 lambda function 요청이 들어올 때 instance를 다시 올리는데 latency가 발생하게 되는데 이것을 coldstart라고 한다. 추가로 lambda function요청이 많이 들어와서 queue에서 대기시간이 많이 발생하여 coldstart가 생길 수도 있다.
coldStart 해결법
lambda function 요청이 주기적으로 들어오는 것이 best. 그렇지 않다면 lambda 사양을 높여 instance가 오래 떠있게 하거나 자체적으로 warm start를 한다.
EventBridge
AWS의 경우 AWS 서비스에 대한 이벤트를 감지합니다. eventBridge는 이벤트 버스를 통해서 이벤트를 수신하고 등록된 이벤트와 일치하는지 확인하고 일치한다면 다른 이벤트에 결과를 라우팅해주는 역할을 수행합니다. 저는 lambda function에서 event trigger 역할로 eventBridge를 사용했습니다.
apiGateway
서버로 전달되는 모든 api요청의 gateway역할을 하는 서버시스템의 구조를 내부로 숨기고 외부의 요청에 대한 응답만을 수행함. 서버에 오고 가는 요청과 응답을 모니터링할 수 있어서 lambda function의 event trigger역할로 사용.
REDIS
Remote dictionary server, 싱글 스레드, 인메모리 db, nosql, 휘발성, 다양한 자료구조 -> sorted set
JWT에 대해서 간단히 설명해주세요.
JWT란 토큰 인증 방식에서 쓰이는 토큰의 한 형식입니다.
JWT는 헤더, 페이로드, 시그니쳐로 구분됩니다. 헤더는 토큰의 타입, 암호화 알고리즘을 담고 있고, 페이로드는 토큰의 정보를 담는 부분이며, 시그니처는 토큰의 정보가 신뢰할 수 있는 것인지 판단할 수 있도록 합니다.
JWT는 세션 기반 인증과 주로 대비됩니다. 세션기반 인증은 서버에서 세션 정보를 관리해야하는 비용이 들게됩니다. 하지만 JWT는 그 자체로 정보를 가지고 있기 때문에 세션의 단점을 보완할 수 있습니다.
Payload의 데이터는 암호화되는 것이 아니라 인코딩 되는 것이므로 민감한 데이터를 넣으면 안된다.
Signature -> 비밀키로만 암호화,복호화 할 수 있다.
Payload, header -> base 64 방식을 사용하여 encoding 했으므로 클라이언트에서도 base 64 방식으로 decode하여 정보를 열람할 수 있다. Base 64 -> ascII코드로 바꾸는 것
accessToken, refreshToken
CI/CD
CI (Continuous Integration) 다수의 개발자가 작성·수정한 소스코드를 지속적으로 통합·테스트하는 것을 의미한다.
CD (Continuous Delivery/Deployment)란 개발, 통합, 배포, 릴리즈, 테스트를 자동화하여 지속적으로 배포하는 것을 의미한다.
Spinaker CD, zenkins CI -> packer 통해서 ami 구성, ansible통해서 ec2 provisioning
Bake, no bake ,incremental bake
DOM이 무엇인가?
Document Object Model로 html문서의 tag들을 js에서 사용할 수 있도록 객체화 한것이다.
Ajax와 axios의 차이
단순하게 WEB화면에서 무언가 부르거나 데이터를 조회하고 싶을 경우, 페이지 전체를 새로고침하지 않기 위해 사용한다고 볼 수 있다.
Ajax는 promise 방식이 아님.
Promise vs async/await
둘다 microtask queue로 감.
Async/await 방식은 error처리를 할 수 없어서 try catch문을 사용해야 하지만 가독성이 좋다.
Promise then지옥
Callback 지옥
'왜 그 기술을 사용했나요?', '그 기술 말고 다른 기술은 왜 사용하지 않았나요?', '대체할만한 기술이 있나요?
Res.json, res.send
https://haeguri.github.io/2018/12/30/compare-response-json-send-func/
객체란
class에서 정의된 내용을 기반으로 실제 메모리를 차지하고 있는 데이터
Middleware
클라이언트에게 요청이 오고 그 요청을 보내기 위해 응답하려는 중간에 목적에 맞는 처리를 하게해주고 다음의 미들웨어 함수에 대한 엑세스 권한을 갖는 함수
어플리케이션 레벨 미들웨어
app 오브젝트의 인스턴스에 바인드 시킨다. cors()
라우터 레벨 미들웨어
라우터 인스턴스에 바인드
객체랑 인스턴스랑 다른가?
객체는 모든 인스턴스를 대표하는 포괄적인 의미를 갖는다.
인스턴스는 객체에 포함되는 개념.
객체를 소프트웨어에 실체화하면 그것을 ‘인스턴스’라고 부른다.
ES6에서 바뀐 것
Let var 차이
Es6 버전에서 나온 것이 let.
Var의 재선언되는 단점을 보완. Let은 재선언 안됨, let/const는 블록 레벨 스코프를 따르고 var은 함수레벨 스코프를 따른다.
(function () {
aName = "Barry";
console.log(aName);
})();
// aName은 내 의도와 상관없이, 자바스크립트 global scope에 선언이 되어 버린다.
console.log(aName);
다음과 같은 상황을 조심해야 한다.
또한 var를 쓸 경우 호이스팅이 일어나 개발자의 뜻대로 코드가 작동되지 않을 수도 있다.
그리고 var는 함수레벨 스코프여서 함수로 감싸주지 않으면 전역변수를 오염시킬 가능성도 있다.
모듈
재사용하기 위한 코드 조각들을 의미. export, import로 모듈을 내보내고 불러올 수 있다.
Promise 프로미스
비동기를 위한 객체, 어떤 일의 진행 상태를 나타내는 객체로 상태와 값이라는 속성을 갖고 있다. resolve, reject 를 호출하여 진행 상태를 결정할 수 있다. promise의 값은 resolve, reject를 호출할 때 넘긴 인자에 의해 결정된다.
then(), catch() 는 일의 진행 상태를 나타내는 객체로, promise가 fullfilled일 때 then()에 등록된 함수를 실행하고 promise가 rejected 일 때 아무것도 하지 않는다
Pending, fulfilled, rejected -> pending에서 비동기 작업이 resolve/reject 를 호출하면 각각 then/catch 문을 실행
event queue, job queue
call stack에 실행되야 하는 함수가 쌓임. 그러다가 비동기 요청이 들어오면 해당 요청을 event queue에 넣고 call stack이 비워지면 event queue에 있는 요청 실행. Job queue는 promise에서 지원하는 queue로 event queue보다 우선권을 갖고 먼저 실행된다.
함수 레벨 스코프(Function-level Scope)
함수 내에서 선언된 변수는 함수 내에서만 유효하며 함수 외부에서는 참조할 수 없다. 즉, 함수 내부에서 선언한 변수는 지역 변수이며 함수 외부에서 선언한 변수는 모두 전역 변수이다.
블록 레벨 스코프(Block-level Scope)
모든 코드 블록(함수,if문,for문,while문,try/catch문 등)내에서 선언된 변수는 코드 블록 내에서만 유효하며 코드 블록 외부에서는 참조할 수 없다. 즉, 코드 블록 내부에서 선언한 변수는 지역 변수이다.
인성
자기소개
안녕하십니까. 삼성전자 mx사업부 지원자 최정재입니다. 저는 꾸준함을 중요시하는 사람입니다. 이와 관련하여 말씀드릴게 두 가지 있습니다. 우선 4년동안 꾸준히 헬스를 해오고 있고 헬스 시작 전보다 10kg가량 커진 몸을 갖게 되었습니다. 올해 초부터 시작하여 9개월간 꾸준히 기술블로그를 운영해왔습니다. 복습용으로 운영하는 블로그인데 Cs, 개인프로젝트, 알고리즘 등 다양한 글을 작성하여 지금은 100개가 넘는 게시물이 올라가 있습니다. 주기적으로 과거에 공부한 내용을 다시 보고있는데 성장에 정말 많은 도움이 되었습니다.
삼성전자에 입사하여서 팀원들에게 제 꾸준함을 전파하겠습니다. 스터디를 열어서 자기개발을 꾸준히 하는 분위기를 조성하고 퇴근후에 헬스장 가는 모임을 만들어 건강한 회사를 만들겠습니다.
직무지원동기
먼저 개발자라는 직업을 택한 계기를 말씀드리겠습니다. 작년 여름 카이스트 몰입캠프에 참가하여 한 달동안 주마다 100시간의 코딩을 했습니다. 캠프에서 개발에 흥미를 갖게 되었고 이후에 개인프로젝트를 시작했습니다. 그러던 어느날 식사를 하던 중간에 멍을 때리면서 코드를 어떻게 짜야할지 고민하는 자신을 발견하고 개발자라는 직업에 확신을 갖게 되었습니다.
그 이후에 개발공부를 꾸준히 해오면서 느낀 개발의 가장 큰 매력은 개발이 ‘다양한 문제해결의 연속’이라는 것 이었습니다. 삼성전자 급의 대기업은 정말 다양한 문제를 다루게 될 것이고 이것은 방금 말씀드린 제 가치관과 맞아 떨어졌습니다. 이것이 첫번째 이유입니다.
그 다음 이유는 고객 숫자 입니다. 갤럭시 버즈나 삼성페이 같은 서비스는 전 국민이 사용하는 서비스입니다. 이러한 서비스의 개발을 맡으면 훨씬 다양한 피드백을 받을 수 있고 이 과정에서 많은 성장을 이룰 수 있을 것입니다. 또한 많은 사람들이 제가 만든 서비스를 사용한다는 자체로 큰 자부심을 느낄 수 있을 것이라 생각했습니다. 이것이 두번째 이유입니다.
기초/전문 역량을 갖추기 위한 노력
카이스트 몰캠 -> 개인프로젝트 -> 인턴
지원분야와 관련된 자신의 강점
깊게 파고드는 성격이 저의 가장 큰 강점이라 생각합니다. 이전에 pos 웹앱을 구현할 때 client 주변의 가게를 반환해주는 api를 만들며 db i/o 시간을 줄이는 방법에 대해 깊은 고민을 한 적이 있습니다. table을 행정구역별로 나누는 것, redis를 통해 캐쉬서버를 만드는 것이 있었지만 결국 택한 것은 다중컬럼 indexing을 통해 최대한 시간을 줄여보는 것이었습니다. 하지만 위도,경도 두개로 index를 설정하고 부등호 쿼리를 두개 날리자 위도로만 index를 타고 나머지는 full scan을 수행하는 것을 확인했습니다. 문제를 해결하기 위해 ‘Real MySQL’이라는 책을 읽었고 부등호 연산이 일어나면 b+tree 끝까지 내려가서 ~
그래서 위도로만 구성. 1만개 정도의 data로 Performance test 시간이 20%정도 감소한 것을 측정. R-tree라는 자료구조를 쓸 예정.
마지막으로 할 말
현재 다니고 있는 회사에서 ‘면접볼때는 이렇게 친화력 좋을지 몰랐다’ 라는 피드백을 받은적이 있습니다. 앞서 공부에 대한 얘기만 많이 했는데 말씀못드린 제 강점중 하나가 친화력입니다. 3학년1학기에 들은 축구수업에서 자원한 것이 아니라 교수님께서 지정하셔서 한학기동안 주장으로 활동했습니다. 매 수업마다 축구 시합을 했는데 경기간에 커뮤니케이션을 주도했고 팀원들과도 가깝게 지냈습니다. 이런 제 성격은 이후에 sk 하이닉스의 팀웤에 긍정적으로 기여할 수 있을 것입니다.
창의성 발휘한 썰
띵스플로우 비트윈팀에서 인턴을 할 때 splash 광고를 내려주는 api를 제작한 경험이 있습니다. 이때 test 코드를 작성하면서 생긴 문제를 창의적으로 해결한 경험이 있습니다. Test 광고와 연결된 user id로 접속할 경우 test 광고를 제대로 내려주는지 검사하는 test 코드였습니다. 퇴사가 얼마 남지 않아 복잡한 user table 접근 과정을 mocking 하는 것은 비효율적이라 판단했습니다. 대신에 싱글톤 class를 하나 선언하여 user 정보를 초기화하고 이를 db처럼 활용하여 test 코드를 완성할 수 있었습니다.
학점에 대해 어떻게 생각하는지?
높은 점수는 아니지만 내가 실무에 필요한 전공지식을 갖췄다는 것을 증명하기에는 충분하다고 생각한다.
왜 낮은지?
동기부여가 잘 안됐기 때문이다. 대학에 처음와서 전공에 흥미를 느끼지 못하였고 이는 학점이라는 결과로 나타났다. 낮은 학점은 저에대한 주변 사람과 저 스스로의 기대감을 낮췄고 낮은 동기부여로 이어졌다. 그만큼 나는 첫 단추가 중요한 사람이다. 나는 이런 내 성격을 잘 알고 있으므로 처음 입사해서 첫 단추를 잘 끼워 주변과 내 스스로 높은 기대치를 갖게 하면 동기부여를 잘 할 수 있을 것이다.
못하면?
아버지께서 본인이 열심히 살아온 이유는 쪽팔리기 싫어서 였다는 말씀을 하신적이 있습니다. 이 말이 제게 크게 와닿았습니다. 첫 단추를 말씀하신 대로 잘 못끼울 수도 있습니다. 하지만 대학생때 처럼 첫 단추 한번 잘못 끼운것에 흔들린다면 그건 정말 창피한 일이라 생각합니다. 직장에서 인정받을 때까지 이악물고 노력할 생각입니다.
자신을 채용해야 하는 이유
띵스플로우에서 쌓은 4개월의 실무경험을 말씀드리겠습니다. 학교에서 쌓은 전공지식을 바탕으로 config distribution admin 서버 개발, splash 광고 api 제작을 한 경험이 있습니다. Splash 광고 api 제작시에는 기획을 이해하고 api 설계 및 제작, test 코드 작성까지 도맡아 했습니다. 또한 회사에서 개발자 롤모델을 만나 ‘어떤식으로 일하면 되겠다’라는 확신을 갖게 되었습니다. 그분은 본인 업무를 잘하는 것은 물론, 어떠한 업무지시도 결국 해내고 본인 업무뿐만 아니라 프로덕트의 전체를 이해하고 팀 전체의 계획을 생각하는 개발자였습니다. 저도 개발자라는 틀에 저를 가둬두지 않고 팀 전체 프로세스를 이해하는 개발자가 되고 싶습니다.
영어점수가 낮은 이유는 무엇인가?
영어회화 공부를 한 적이 별로 없어서 낮은 점수가 나왔다. 하지만 오픽 시험 점수를 보고 회화공부 필요성을 깨달았습니다. 영어가 나중에 제 자신이 나아가는데 걸림돌이 되지 않도록 입사이후에 전화영어로 회화공부를 꾸준히 할 생각입니다.
삼성전자에 대해 아는대로 말해봐라.
삼성전자는 제조분야에서 세계 최고의 기술력을 보유한 기업입니다. 최근에 미국에서 진행된 개발자 컨퍼런스에서는 여러 파트너 기업, 의료기관들과 협업하여 헬스 생태계를 확대할 것이라는 방침을 공개했습니다. 하만과 협업하여 만든 레디케어, 구글과 협업하여 만든 헬스 커넥트 등이 그 예시입니다.
자기소개에서도 말씀드렸듯이 저는 운동에 많은 관심을 갖고 있고 이는 건강한 삶을 살기 위함도 있습니다. 따라서 삼성전자의 이러한 사업은 제 관심분야와 잘 맞아 떨어집니다. 업무 도메인이 본인의 관심분야와 맞아 떨어지는 것은 최고의 시너지효과를 기대할 수 있다고 생각합니다. 헬스 케어 서비스의 도메인 지식을 빨리 습득하여 헬스 케어 사업에 도움이 되고 싶습니다.
이외에도 ve, 폴더블 폰을 기점으로 한 프리미엄 폰 시장,
지원분야가 본인과 잘 안맞으면?
우선 잘 안맞는다라는 결정을 함부로 하지 않을 것입니다. 심사숙고하여 내린 결정이 저와 잘 맞지 않는다면 우선 그 원인을 최대한 분석하려 할 것입니다. 부서 변경 요청을 하였는데 또 맞지 않는다면 회사와 저 모두에게 너무나도 큰 손해이기 때문입니다.
스트레스 해소법
헬스, 축구, 런닝
희망하지 않는 분야에 배치된다면?
사전 지식만으로는 잘못판단했을 가능성이 있으므로 배치된 부서에서 최선을 다해보고 충분한 도메인 지식이 쌓였는데도 생각이 변하지 않는다면 원인을 분석하고나서 다른 부서로의 배치를 요구할 것이다.
리더형 팔로워형
리더형. 말씀드릴게 두 가지가 있다. 축구. 기정리 팀플. 열심히 참여하지 않는 팀원의 참여를 이끌어냄.
회사에서 중요하다고 생각하는 가치
회사가 필요로 하는 사람이 되는 것. 개인적인 성장도 물론 중요하지만 성장의 궁극적인 목표 역시 회사가 필요로 하는 사람이 되는 것이다. 어떻게 하면 회사 일에 더 기여하여 회사가 나를 필요로 하게 될지를 끊임없이 고민할 것 입니다.
단점 3가지
친화력이 좋아 사람들과 어울리는 것을 좋아하는 만큼 외로움을 많이탄다.
오지랖이 넓다.
주변 친구들과 계속 비교한다.
친구를 사귈 때 가장 중요하게 보는 것?
배울점이 있는 사람
좋아하는일 잘하는 일?
잘 하는 일. 프로가 된다는 것은 돈을 받고 일을 해주는 것. 퀄리티를 보장해야함.
리더십이 무엇인가?
회사에서의 리더십과 인간 관계에서의 리더십은 다르다고 생각한다. 인간 관계에서의 리더십은 그 사람이 따르고 싶어져야 하고 이것은 능력, 인품 등에 대한 존경심에 기반을 둔다. 하지만 회사에서의 리더십은 얘기가 다르다. 한정된 resource로 지속가능한 최대한의 효율을 뽑아내는 것이 회사에서의 리더십이라 생각한다. 물론 이 두가지가 합쳐지면 금상첨화지만 둘 중 하나를 선택해야 한다면 회사에서는 회사에서의 리더십을 따르는게 맞다고 생각한다.
가장 힘들었던 경험?
간부들이 나를 행보관의 앞잡이로 생각한 것.
서버 개발자한테 가장 중요한 것이 뭐라고 생각하는지
겸손
상반기 대체적으로 어느 분야에 지원했는지
많은 트래픽
성격의 장점
친화력
그로 인한 단점과 극복하기 위해 시도했던 노력
혼자있는 시간 즐기기, 운동, 런닝
프로젝트하면서 느낀점
Cs에 대한 이해가 굉장히 중요하다는 것을 느낌
Index, cors
블로그는 언제부터, 왜 시작했는지
밑 빠진 독에 물 붓기
재미있게 들었던 학교 수업과 기억나는 내용
컴네, google.com 입력하면 생기는 일
10년 후 어떤 개발자가 되고 싶은지
새로운 기술이 나와도 빨리 습득하는 개발자.
입사한다면 어떤 일을 하고 싶은지
가장 재밌었던게 indexing해서 latency 줄이는 일, 성능 개선
Tdd 개발 배우기
Q. 다른 지원한 곳은?
지원동기
트래픽을 경험하고 싶다.
Q. 프로젝트 진행시 가장 중요시 여겼던 부분은?
일단 구현을 가장 우선시 여겼습니다. 그리고 그 다음으로 중요하게 여긴 것이 사용자의 편의성입니다. 자동마감 시스템, 주문 알람
Q. 개발적으로 수업때문에 읽은 책 말고 읽은 책과 책 제목은?
이것이 취업을 위한 코딩테스트다
Q. 개발 지식 쌓는 방법은 어떻게?
블로그, 공식문서, 개인블로그정리
Q. 백엔드 개발자 되고 싶은데 부족한 부분 뭐라고 생각해?
영어
Q. 뭘 잘할 것 같아?
주니어 때는 적극적으로 배우고자 하는 자세로 방해가 안되는 선에서 많은 질문을 할 것 같다. 시니어가 되면 주니어 개발자 실력을 향상시키는 일에 적극적으로 나설 것 같다.
Q. 좋은 코드를 짜기 위해 어떤 것을 생각해?
중복되는 코드 없애기, 다른 사람이 봐도 역할을 알 수 있게 변수명, 함수명 짓기,
Q. 앞으로 볼 예정인 책 있어?
Q. NoSQL에서 No의 무슨 뜻이야?
Q. 의견 불일치 시 어떻게 했어?
적극적으로 상대방을 설득하되 내가 틀릴수도 있겠다는 마음가짐을 베이스로 임함. 의사소통이 중요.
Q. 마지막 할 말
dns,ddns,gslb,cdn
url/uri 차이점 -> 위치지정자/ 식별자
결론부터 말하면 URI는 URL의 의미를 품고있다.
URL(Uniform Resource Locator)은 자원이 실제로 존재하는 위치를 가리키며, URI(Uniform Resource Identifier)는 자원의 위치뿐만 아니라 자원에 대한 고유 식별자로서 URL을 의미를 포함한다.
DB 커넥션 pool이 부족해서 error가 발생했다 어떻게 처리할 것인가?
라인 쇼핑에서 한정판 아이템의 발매가 있는 상황의 로그인 과정에서 DB connection pool이 부족해져 wait이 발생하는 상황이라고 하자. 이상적인 목표는 최대한 많은 사람이 빠른 시간안에 로그인에 성공하게 하는 것이다. 그러기 위해서는 maxWait 시간 전에 사용자가 세션을 종료하면 안된다. 우선 대기자 숫자 안내 메시지를 띄워 사용자들에게 처리가 진행중임을 알려 세션을 종료하는 경우를 줄이겠다. 또한 기존에 발생했던 다른 사례를 분석하여 미리 connection 객체를 더 많이 만들어 놓겠다.
공유기 작동원리
Dns 작동원리
< 주소창에 url입력하면 벌어지는 일 >
1.host파일
호스트 이름에 대응하는 IP 주소가 저장되어 있어서 도메인 이름 시스템(DNS)에서 주소 정보를 제공받지 않고도 서버의 위치를 찾게 해주는 파일.
장점: 인터넷 속도 향상, 리소스 사용 줄임,
단점: 악용되거나 오류가 생길시에 사이트 방문이 차단될 수 있다.
2.dns cache 뒤지고 브라우저, os ,라우터 ,isp 순으로 뒤짐.
3.없으면 질의하는데 공유기가 있는 경우에는 공유기한테 질의를 보내면 공유기가 dns에게 질의를 넘기고 dns가 ip주소 찾아서 공유기를 통해서 client로 보냄, dns한테 직접 질의할 수도
4.ip
설정이 안되어 있으면 기본적으로 isp에서 전달해주는 dns 설정을 사용
5.tcp연결
6.http request
7. response
GSLB 구현방법: CDN
CDN(콘텐츠 전송 네트워크)은 지리적으로 분산된 여러 개의 서버입니다. 웹 콘텐츠를 사용자와 가까운 곳에서 전송함으로써 전송 속도를 높입니다.
CDN은 웹사이트 콘텐츠를 캐싱해 전 세계 여러 곳의 ‘PoP(Points of Presence)’에 저장합니다. 이러한 PoP는 자체 캐싱 서버를 갖고 있으며 가까운 사용자에게 해당 콘텐츠를 전송합니다.
기본적으로 인터넷은 대량의 데이터 처리할 수 있도록 설계되지 않았는데 CDN은 이런 인터넷 성능을 개선하도록 설계되었습니다.
CDN서버에 요청이 들어오면 CDN서버에는 IP주소와 해당 IP주소의 위치정보가 있는 DB가 있는데 이걸 보고 가장 가까운 서버와 연결시켜준다.
CDN을 통해 GSLB를 구현한다 했는데 GSLB를 구현하려면 CDN의 이러한 기능에 Health Check기능이 추가되어야 한다. 여러 장소에 위치한 서버가 정상적인 상태인지 계속해서 Check하고 장애가 발생한 상태이면 가장 가까운 다른 서버로 forwarding 해주어야 한다.
추가로 정교한 load balancing 가능, 서버의 load를 모니터링 하기 때문 dns에서는 라운드 로빈방식으로 loadbalancing을 구현하였는데 정교하지 못함.
http/ https 차이: HTTPS는 HTTP에 보안 계층을 추가한 것입니다. HTTPS는 제3자 인증, 비대칭키 암호화, 대칭키 암호화를 사용합니다.
https 암호화 과정
대칭키
비대칭키
- 공개키 암호화
- 개인키 암호화
isp
인터넷에 접속하는 수단을 제공하는 주체, 일반 사용자, 기업체. 기관 등이 인터넷에 접속하여 인터넷을 이용할 수 있도록 돕는 사업자. 현재는 KT, U+, SKT 같은 ISP가 인터넷 서비스를 제공.
https://rebro.kr/169 , b tree 삭제, 삽입 과정
https://rebro.kr/167?category=484170 b+ tree
Q. 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유?
A. Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순처적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정한다.
GET과 POST의 차이점에 대해서 설명해보세요.
GET요청은 서버에 존재하는 정보를 요청합니다. 일반적으로 Request Body는 입력하지 않는 것이 일반적이며, 캐싱을 수행하기 때문에 캐싱되지 않는 요청은 GET 요청이 맞지 않을 수 있습니다. GET 요청 캐싱을 사용할 수 있게 하면 동일한 사용자가 이전에 제출한 자원 데이터에 대한 요청의 응답 시간을 개선할 수 있습니다. 캐싱이 사용 가능으로 설정되면 서버의 비즈니스 오브젝트 대신 브라우저 캐시에서 데이터가 검색됩니다. 일반적인 캐싱 엔트리의 형태는 다음과 같습니다
영구적인 리다이렉트: 301 (Moved Permanently) 응답.
오류 응답: 404 (Not Found) 결과 페이지.
완전하지 않은 결과: 206 (Partial Content) 응답.
캐시 키로 사용하기에 적절한 무언가가 정의된 경우의 GET 이외의 응답.
400 bad request, 403 forbidden
또한 cache-control 헤더에다가 캐싱 메커니즘을 어떻게 할지 정의해서 사용한다.
POST요청은 서버에 정보를 생성하는 것을 요청합니다. POST 요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않습니다. 보통 Request Body에 요청하는 데이터를 담아 전송합니다.
HTTP 메서드와 이것이 하는 역할에 대해서 설명해보세요.
GET 요청은 서버에 존재하는 데이터를 요청하는 것입니다. CRUD로 따지면 R입니다.
POST 요청은 서버에 데이터를 생성하는 것을 요청합니다. CRUD로 따지면 C입니다.
PUT 요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성합니다. CRUD로 따지면 C,U입니다.
DELETE 요청은 서버에 데이터를 제거할 것을 요청합니다. 존재하지 않아도 동일하게 동작합니다. CRUD로 따지면 D입니다.
PATCH 요청은 서버에 존재하는 데이터를 일부 수정합니다. CRUD로 따지면 U입니다.
Put, patch 멱등성의 차이
https://oen-blog.tistory.com/211
RESTful이란 무엇이며, 이것에 대해서 아는대로 설명해보세요.
URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는 것입니다. HTTP URI를 통해 자원을 표시하고 HTTP 메소드를 통해 자원에 대한 처리를 표현합니다. HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영합니다. REST의 요소로는 크게 리소스, 메소드, 메세지 3가지 요소로 구성됩니다. 리소스는 http://myweb/users라는 형태의 URI로 표현되며, 메소드는 HTTP 메소드, 메세지는 JSON 문서를 이용해서 표현됩니다.
Restful하게 API를 디자인한다는 것은 URI를 규칙에 맞게 잘 설계했는지의 여부입니다. 규칙의 항목으로는 아래와 같습니다.
1. 동일한 URI(End point)의 행위에 맞게 GET, POST, PUT, DELETE등의 메소드를 사용한다.
2. 명사를 사용한다. 리스트를 표현할 때는 복수형을 사용한다.
3. URI Path에 불필요한 파라미터를 넣지 않는다. 즉, 단계를 심플하게 설계한다.
단점으로는 명확한 표준이 존재하지 않는다는 점, RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점(그런 REST API로 괜찮은가 참고)이 있습니다.
Self-descriptive 해야한다. -> api 설명만을 보고 어떤 api인지 이해가 가능해야 한다. content-type과 변수의 의미를 적어야 한다.
헤티오스-> 애플리케이션의 상태가 항상 하이퍼링크를 통해 전송되어야한다.
이런 것들은 uniform interface라는 규약인데 이 규약의 목적은 서버와 클라이언트의 독립적 진화이다. api가 업데이트 된다고 해도 클라이언트는 바뀌지 않아도 됨을 의미한다.
Rest의 이러한 특성은 웹의 상호운용성을 중요시하는 독립적 진화에도 영향을 주었다.
이렇게 rest는 웹 html 구성에서는 잘 지켜졌지만 오늘날 rest api라고 불리는 api들은 대부분 rest를 만족하지 못한다. Api 문서를 api는 json으로 구성하는데 여기서 json은 각 key에 대한 정의를 따로 내리지 못하고 hyperlink를 지원하지 않기 때문이다. 해결법은 따로 문서를 만들고 value값에 문자열로 hyperlink를 넣으면 된다.
CORS
브라우저에서는 보안적인 이유로 cross-origin HTTP 요청들을 제한합니다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요합니다. 이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing)라고 부릅니다.
cross-origin
cross-origin이란 다음 중 한 가지라도 다른 경우를 말합니다.
프로토콜 - http와 https는 프로토콜이 다르다.
도메인 - domain.com과 other-domain.com은 다르다.
포트 번호 - 8080포트와 3000포트는 다르다.
프레임워크 라이브러러 차이
Framework란 소프트웨어 환경에서 복잡한 문제를 해결하거나 서술하는데 사용되는 기본 개념 구조입니다. 프레임워크는 설계자가 의도한 여러 디자인 패턴으로 구성되어 있습니다. 따라서 개발자가 에플리케이션의 구조적 설계를 신경 쓸 필요가 없습니다. 또한 일정 수준 이상의 품질을 보증하는 코드를 비교적 빠르고 편하게 완성 및 유지보수할 수 있는 솔루션이라고 할 수 있습니다.
라이브러리는 특정 기능이 필요할 때 호출해서 쓰는 도구 모음입니다. 프레임워크는 지켜야 되는 룰이 있는 반면 라이브러리는 쓰든 개발자 마음대로 할 수 있다는 점에서 차이가 있습니다.
OSI7계층과 그 존재 이유, TCP/IP 4계층에 대해 설명해보세요.
OSI7계층은 네트워크 통신을 구성하는 요소들 7개의 계층으로 표준화한 것입니다. 이렇게 표준화하는 것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기 용이해집니다. 또한 어느 회사에서 통신용 장비를 만든다 할 때 표준 모델이 정해져 있어야 타사 제품과 호환성이 좋은 제품을 생성할 수 있습니다.
실제로 우리가 대부분 사용하는 네트워크는 TCP/IP 4계층입니다. 통신에 실제로 사용되는 계층이고 1,2 계층이 1계층, 5, 6, 7계층이 4계층으로 운영됩니다.
비대칭키 암호화, 대칭키 암호화에 대해 간단히 설명해주세요.
TDD를 알고 있나요? TDD에 대해서 어떻게 생각하나요?
코드를 수정하거나 기능을 추가할 때 수시로 빠르게 검증할 수 있다.
리팩토링 시에 안정성을 확보할 수 있다.
개발 및 테스팅에 대한 시간과 비용을 절감할 수 있다.
좋은 test 특징 -> First
Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
Repeatable: 어느 환경에서도 반복 가능해야 한다.
Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.
Status code
1xx(informational): 요청이 수신돼 처리 중(거의 사용하지 않음)
2xx(successful): 요청 정상 처리됨
3xx(redirection): 요청을 완료하려면 추가적인 처리가 필요함
4xx(client error): 클라이언트 오류. 잘못된 문법 등으로 인해 서버가 요청을 수행할 수 없음
5xx(server error): 서버 오류. 서버가 정상적인 요청을 처리하지 못함
쿠키와 세션의 차이점
저장 위치
쿠키 : 클라이언트
세션 : 서버
보안
쿠키 : 클라이언트에 저장되므로 보안에 취약하다.
세션 : 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋다.
라이프사이클
쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다.
세션 : 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.
속도
쿠키 : 클라이언트에 저장되어서 서버에 요청 시 빠르다.
세션 : 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느리다.
RDBMS와 NoSQL
NoSQL은 RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장했다.
장점
정해진 스키마가 없어 자유롭게 데이터를 저장할 수 있다.
Scale out에 의한 서버 확장에 용이하다. 점진적으로 노드를 추가할 수 있어야 하고 이는 파티셔닝을 통해서 가능하다(가용성). NoSQL 데이터베이스는 키-값, 문서, 그래프 등 성능과 규모 확장에 최적화된 다양한 데이터 모델을 제공합니다.
쿼리 프로세싱이 단순화되어 속도가 빨라졌고 대용량 데이터를 처리하는 성능이 뛰어나다.
단점
데이터가 중복되므로 데이터베이스 일관성에 약하다.
스키마가 정해져 있지 않아, 데이터에 대한 규격화가 되어 있지 않다.
데이터가 여러 컬렉션에 중복되어 있어서 데이터를 UPDATE 하는 경우 모든 컬렉션에서 수행해야하기 때문에 느리다.
NoSQL 사용시 효율적인 상황
아주 낮은 응답 지연시간(latency) 이 요구됨
다루는 데이터가 비정형이라 관계형 데이터가 아니다
아주 많은 양의 데이터를 저장할 필요가 있을 때
Update가 자주 일어나지 않는 자료
-> sql은 수평적 확장이 어렵다. nosql에서는 가능. 아마 table간의 relation 때문인 것 같음. nosql이 수평적 확장이 쉽도록 설게됨.
BASE
ACID와 대조적으로 가용성와 성능을 중시하는 특성을 가진 분산 시스템의 특성. NOSQL은 이 철학을 따른다.
Basic Availability(기본적인 가용성): 데이터베이스는 대부분의 시간동안 동작하는 것처럼 보인다. 즉, 분산 DB에서 몇 개의 다른 DB는 문제가 있다고 하더라도, 살아있는 것이 있으므로 사용자에게는 계속 가용한 것으로 보인다는 것
Soft-state: 저장소(store)는 작성 일관성(write-consistent)일 필요 없으며, 또한, 서로 다른 복제본들(replica) 또한 상호간에 항상 일관적일 필요가 없다. 즉, 각 노드의 값들이 어느 정도 비일관적으로 유지될 수 있다. 현재 노드가 반드시 최신으로 유지되지 않을 수도있고, 썻다고 바로 모든 노드에 적용되는 것은 아니다. 이는 다시 eventual consistency와 동일한 개념으로 받아들여질 수 있다.
Eventual consistency: 일시적으로 비일관적인 상태가 되어도 최종적으로는 일관성이 있는 상태가 된다. 분산 DB가 기본적으로 가지는, 통신에 따른 지연 시간으로 발생하는 비일관적인 상태를 가질 수 있지만, 결과적으로는 일관적이어야 한다는 이야기.
정리하면 ‘최종적으로는 정확하고, 일관적이지만, 분산된 노드별로 좀 일관적이지 않은 애들도 있고 서로 다른 애들도 있다. 어쨌거나, 결론적으로는, 약간의 부정확성을 통해서 빠르게 대응할 수 있도록 하는 것을 위한 DB’라고 생각하면 된다.
ACID의 Durability
- 내구성은 예기치 못한 시스템 장애 또는 정전 시 마지막으로 알려진 상태로 복구하는 기능을 필요로 합니다.
파티셔닝의 개념
큰 table이나 index를, 관리하기 쉬운 partition이라는 작은 단위로 물리적으로 분할하는 것을 의미한다.
물리적인 데이터 분할이 있더라도, DB에 접근하는 application의 입장에서는 이를 인식하지 못한다.
'파티셔닝(Partitioning)'기법을 통해 소프트웨어적으로 데이터베이스를 분산 처리하여 성능이 저하되는 것을 방지하고 관리를 보다 수월하게 할 수 있게 되었다.
파티셔닝의 장점
관리적 측면 : partition 단위 백업, 추가, 삭제, 변경
전체 데이터를 손실할 가능성이 줄어들어 데이터 가용성이 향상된다.
partition별로 백업 및 복구가 가능하다.
성능적 측면 : partition 단위 조회 및 DML(데이터 조작어 -> select, insert, update, delete) 수행
데이터 전체 검색 시 필요한 부분만 탐색해 성능이 증가한다.
즉, Full Scan에서 데이터 Access의 범위를 줄여 성능 향상을 가져온다.
Ddl -> create drop 같은 애들. 데이터 구조 관련 명령어들
파티셔닝의 단점
table간 JOIN에 대한 비용이 증가한다.
table과 index를 별도로 파티셔닝할 수 없다.
table과 index를 같이 파티셔닝해야 한다. -> 수직 파티셔닝에서 문제
샤딩
db자체를 나누는 것. 파티셔닝은 테이블을 쪼개는 것이고 샤딩은 db를 나누는 것이다. 하나의 transaction에서 하나의 샤드만 조회가 가능하고 서로다른 db끼리 join연산이 불가능 하다는 한계가 있다.
프로세스와 스레드 차이
프로세스는 os로부터 자원을 할당받는 작업의 단위이고 스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위입니다. 프로세스는 실행될 때 os로부터 cpu, 필요한 주소공간, 메모리 등의 자원을 할당 받습니다. 스레드는 한 프로세스 내에서 동작하는 여러 실행 흐름으로 프로세스의 자원을 일부는 공유하고 일부는 따로 할당 받습니다. 또한 스레드는 {code, data, file(heap)}을 공유하므로 IPC도 더 효율적으로 할 수 있고 context switch시에도 캐쉬 전체를 비울 필요가 없으므로 훨씬 빠르게 동작합니다.
컨텍스트 스위칭에 대해 설명해보세요.
multiprocessing에서는 한 process가 끝날 때까지 기다리는 것이 아니라 여러 작업을 번갈아가며 실행해서 동시에 처리될 수 있도록 하는데 이때 실행되고 있는 process를 바꾸는 작업을 context switch라고 합니다.
인터럽트가 발생하면 현재 프로세스의 상태를 PCB에 저장하고 새로운 프로세스의 상태를 레지스터에 저장하는 방식으로 동작합니다. 이 때, CPU는 아무런 일을 하지 않으므로 잦은 컨텍스트 스위칭은 성능저하를 일으킬 수 있습니다.
스레드는 서로 {code, data, file(heap)} 영역을 공유하고 있어서 이 부분을 제외한 부분만 캐시메모리에서 지우고 다시 올리면 되므로 상대적으로 더 빠른 컨텍스트 스위칭이 일어날 수 있습니다.
멀티스레드 프로그래밍에 대해 설명해보세요.
멀티스레드 프로그래밍은 하나의 프로세스에서 여러개의 스레드를 만들어 자원의 생성과 관리의 중복을 최소화하는 것을 멀티스레드 프로그래밍이라고 합니다.
주의점
어떤 TASK를 멀티스레드로 처리할 것인가? 병렬
Thread 마다 적절하게 task를 배분
장점
멀티 프로세스에 비해 메모리 자원소모가 줄어듭니다.
힙 영역을 통해서 스레드간 통신이 가능해서 프로세스간 통신보다 간단합니다.
스레드의 컨텍스트 스위칭은 프로세스의 컨텍스트 스위칭보다 빠릅니다.
단점
힙 영역에 있는 자원을 사용할 때는 동기화를 해야합니다.
동기화를 위해서 락을 과도하게 사용하면 성능이 저하될 수 있습니다.
하나의 스레드가 비정상적으로 동작하면 다른 스레드도 종료될 수 있습니다.
Thread-safe 하다는 의미와 설계하는 법을 설명해보세요.
멀티 스레드 프로그래밍에서 일반적으로 어떤 함수나 변수, 혹은 객체가 여러 스레드로부터 동시에 접근이 이루어져도 각 스레드에서의 수행 결과가 올바로 나오는 것으로 정의한다.
- Re-entrancy
어떤 함수가 한 스레드에 의해 호출되어 실행 중일 때, 다른 스레드가 그 함수를 호출하더라도 그 결과가 각각에게 올바로 주어져야 한다. - Thread-local storage
공유 자원의 사용을 최대한 줄여 각각의 스레드에서만 접근 가능한 저장소들을 사용함으로써 동시 접근을 막는다. - Mutual exclusion
공유 자원을 꼭 사용해야 할 경우 해당 자원의 접근을 세마포어, Mutex 등의 락으로 통제한다 - Atomic operations
공유 자원에 접근할 때 원자 연산을 이용하거나 '원자적'으로 정의된 접근 방법을 사용함으로써 상호 배제를 구현할 수 있다.
프로세스 동기화에 대해 설명해보세요.
다중 프로세스 환경에서 Race condition을 막고 데이터의 일관성을 유지하기 위해 Critical section에 한 프로세스만이 접근 가능하도록 하는 것입니다.
상호 배제(Mutual Exclusion): 한 프로세스가 임계구역에서 동작중이면 다른 프로세스는 접근할 수 없다.
진행(Progress): 임계구역에서 작업중인 프로세스가 없다면 임계구역으로 진입하려는 프로세스를 적절히 선택해서 진입할 수 있도록 합니다.
유한 대기(Bounded Waiting): 한 프로세스가 임계영역으로 진입을 요청한 후 다른 프로세스는 진입이 유한한 횟수로 제한되어야 합니다. (기아상태 방지)
Race condition에 대해 설명해보세요.
Race Condition(경쟁 상태): 여러 프로세스나 스레드가 동기화 메커니즘 없이 자원에 접근하려는 상황을 가리킵니다. 공유된 자원에 대한 접근 순서에 따라 실행 결과가 달라질 수 있는 상황을 의미합니다. deadlock, starvation등의 문제가 나타납니다.
Deadlock에 대해 설명해보세요
서로 다른 프로세스가 서로 점유하고 있는 자원의 반납을 대기하고 있는 상태를 의미합니다.
[발생조건]
상호 배제: 한 번에 한 프로세스만 해당 자원을 사용할 수 있어야 합니다.
점유 대기: 할당된 자원을 가진 상태에서 다른 자원을 기다립니다.
비선점: 다른 프로세스가 자원의 사용을 끝낼 때까지 자원을 뺏을 수 없습니다.
순환대기: 각 프로세스가 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있습니다.
[해결방법]
예방: 4가지 조건 중 하나라도 만족되지 않도록 합니다.
회피: 알고리즘을 데드락이 발생하지 않도록 합니다. -> 은행원 알고리즘
회복: 교착상태가 발생할 때, 해결합니다.
무시: 회복과정의 성능저하가 심하다면 그냥 무시합니다.
은행원 알고리즘
교착상태가 일어나는지 점검한 후에 안일어난다고 판단되면 자원을 할당. 사전에 손님이 요구할 최대 돈, 손님의 현재 돈, 은행이 제공할 수 있는 돈을 알아야 하므로 전제 조건이 많이 필요하다.
Starvation에 대해 설명해보세요.
여러 프로세스가 부족한 자원을 점유하기 위해 경쟁할 때, 특정 프로세스가 영원히 자원 할당이 되지 않는 경우입니다.
[해결방법]
우선순위를 변경합니다.(우선순위를 수시로 변경하거나, 오래 기다린 프로세스의 우선순위를 높여주거나, Queue를 사용합니다.)
세마포어와 뮤텍스의 차이에 대해 설명해보세요.
세마포어는 여러개의 프로세스가 접근 가능한 공유자원을 관리하는 방식이고, 뮤텍스가 될 수 있지만, 뮤텍스는 한 번에 한 개의 프로세스만 접근 가능하도록 관리하는 방식입니다. 따라서 뮤텍스는 세마포어가 될 수 없습니다.
또, 세마포어는 다른 프로세스가 세마포어를 해제할 수 있지만, 뮤텍스는 락을 획득한 프로세스만 락을 반환할 수 있습니다.
가상 메모리에 대해 설명해보세요.
흔히 말하는 Swap 영역, 실제 메모리에서 공간이 부족한 경우 보조 기억 장치(auxiliary storage, secondary storage)에서 임시로 사용하는 영역.
OS 에서 관리하며 프로세스는 이것이 실제 메모리인지, Swap 영역인지 모릅니다
당연히 실제 메모리가 아니기 때문에 지연시간이 많이 발생하며, 가급적이면 swap메모리를 사용하지 않도록 설계하는 것이 좋고, 만약 계속해서 사용하는 양이 증가한다면 메모리 누수를 의심해 볼 수 있습니다.
Msa 아키텍쳐
장점: 서비스별 배포가 가능하다. 특정 서비스에 대한 확장성이 용이하다. 장애가 전체 서비스로 확장될 가능성이 적다. 코드/유지보수가 편리하다.
단점: 서비스 간 호출 시 api를 사용하므로 latency가 증가한다. 데이터가 여러 서비스에 걸쳐서 분산되어 한 번에 조회가 어렵다.
모놀리식 아키첵쳐
장점: 배포 간단(한번 하면 되므로)
단점: 빌드 및 배포시간이 길어진다. 조그마한 수정사항이 있어도 서버 전체를 다시 빌드하고 배포해야 한다.유지보수가 어렵고 한부분의 에러가 전체로 퍼질 수 있다.
CSR(클라이언트 사이드 렌더링)과 SSR(서버 사이드 렌더링)의 차이점
CSR(클라이언트 사이드 렌더링)
장점
1. 필요한, 변경된 데이터만 받아서 그리기 때문에 트래픽이 감소한다.
2. 새로고침이 발생하지 않아 사용자가 네이티브 앱과 비슷한 경험을 할 수 있다.
단점
1. 검색엔진(SEO)
JS 위주로 돌아가는 프로젝트는 JS 엔진이 돌아가지 않으면 원하는 정보를 표시해주지 못한다. 구글의 검색엔진에는 JS 엔진이 내장되어 있지만 네이버, 다음 등의 검색엔진은 제대로 크롤링하지 못하기 때문에 SSR을 따로 구현해야한다. ssr의 html 파일은 비어있으므로 검색엔진이 사전에 정보를 수집하지 못하여 발생하는 문제.
SSR(서버 사이드 렌더링)
장점
1.SEO 가능(JS엔진 없이 완전한 페이지를 받기 떄문에 SEO가 가능)
2.성능 개선
첫 렌더링된 html을 클라이언트에게 전달해주기 때문에 초기 로딩속도를 많이 줄여줄 수 있다. JS 파일을 불러오고 렌더링 작업이 완료되기 전에 사용자가 사이트 컨텐츠를 이용할 수 있게 된다.
단점
1.페이지를 이동할 때마다 전체에 대한 요청을 보내기 때문에 트래픽이 증가한다.
2.페이지를 이동할 때 화면이 깜빡거리는 문제가 있다.
SPA(single page application)
서비스에 필요한 코드들을 처음 접속시 다 받아와서 csr 방식으로 작동하는 app
장점: ssr과 비교해서 배포가 간단하다. 서비스 이용시 새로운 페이지를 요청할 때 필요한 data만 요청하므로 전체적인 트래픽이 감소한다. 전체 페이지를 렌더링하지 않고 필요한 부분만 렌더링하므로 새로고침이 발생하지 않아 네이티브앱과 유사한 경험을 제공한다.
단점: 모든 정적 리소스를 한번에 다운로드하기 때문에 초기 구동속도가 상대적으로 느리다. Seo 이슈를 해결해야 한다.
SEO(Search Engine Optimization)
검색봇이 js를 읽을 수 없어서 발생하는 문제. Ssr 또는 pre-rendering을 통해서 해결.
자바스크립트의 number 타입은 다른 언어와 차이점이 무엇인가?
다른언어는 다양한 숫자 타입이 있지만, JS number 타입은 모든 수를 실수로 처리한다.
undefined와 null의 차이점
undefined는 개발자가 의도적으로 할당하기 위한 값이 아니라 자바스크립트 엔진이 변수를 초기화할 때 사용하는 값이다. 그래서 변수를 참조했을때 undefined가 반환된다면 초기화하지 않은 변수라는 것을 알 수 있다.
null은 변수에 값이 없다는 것을 의도적으로 명시할 때 사용한다. (의도적 부재) 이는 이전에 할당되어 있던 값에 대한 참조를 명시적으로 제거하는 것을 의미하며, 자바스크립트 엔진은 누구도 참조하지 않는 메모리 공간에 대해 가비지 콜렉션을 수행한다.
==와 ===의 차이점
동등 비교(==) 연산자는 좌항과 우항을 비교할 때, 암묵적 타입 변환을 통해 타입을 일치시킨 후, 같은 값인지 비교한다. 따라서 타입이 다르더라도 암묵적 타입 변환 후에 같은 값이라면 true를 반환한다.
일치 비교(===) 연산자는 좌항과 우항의 피연산자가 타입이 같고, 값이 같은 경우에 한하여 true를 반환한다.
1 == “1” true
1 === “1” false
쿠키 vs LocalStorage
저장공간: 4kb(쿠키), 5~10mb(LS)
서버접근: 쿠키 가능 , LS 불가능
쿠키는 http request시 자동으로 포함된다.
쿠키는 Httponly 설정을 추가하여 js에서의 접근을 막을 수 있다. 또한 secure 설정ㅇ르 추가하여 https를 통해서만
전송 가능하게 하여 네트워크에서 토큰이 탈취되는 것을 막을 수 있다.
보안성을 따지면 쿠키가 좋다. 하지만 써본결과 cookie는 ; 단위로 끊겨있는 문자열로 주어지므로 사용이 조금 불편
하다.
node도 os 독립적인가?
-> jvm을 os에 맞게 설치하듯이 node도 os에 맞게 설치한다. jvm에서 바이트 코드를 os독립적으로 해석할 수 있듯이 node에서도 js코드를 os독립적으로 해석한다.
쿠키
서버가 HTTP 응답 헤더(header)의 Set-Cookie에 내용을 넣어 전달하면, 브라우저는 이 내용을 자체적으로 브라우저에 저장합니다. 이게 바로 쿠키입니다. 브라우저는 사용자가 쿠키를 생성하도록 한 동일 서버(사이트)에 접속할 때마다 쿠키의 내용을 Cookie 요청 헤더에 넣어서 함께 전달합니다.
세션
사용자가 로그인하면 서버는 HTTP 응답 헤더의 Set-Cookie에 담긴 “세션 식별자(session identifier)” 정보를 사용해 쿠키를 설정합니다.
사용자가 동일 도메인에 접속하려고 하면 브라우저는 HTTP Cookie 헤더에 인증 정보가 담긴 고윳값(세션 식별자)을 함께 실어 서버에 요청을 보냅니다.
서버는 브라우저가 보낸 요청 헤더의 세션 식별자를 읽어 사용자를 식별합니다.
서드 파티 쿠키
사용자가 방문중인 도메인이 아닌 다른 도메인에서 생성한 쿠키. 특정 페이지에서 광고 이미지 배너가 있
다고 하자. 해당 배너를 불러올 때 해당 광고 사이트에서 쿠키를 생성한다. 그리고 다른 사이트에 접속 했
을 때 또 같은 배너가 있으면 client는 해당 서버로 쿠키를 자동 전송하게 되어있고 서버에서는 client의 동
선 추적이 가능해진다.
함수형 프로그래밍 특징
순수함수
동일한 입력에 대해 항상 같은 값을 return 해야 한다.
함수 내부에서 외부 인자의 값을 변경하거나 프로그램에 영향을 미치면 안된다.
-
불변성
data는 변하지 않는다. 변경이 필요한 경우 복사하여 사용한다. -
선언형 함수
명령형 프로그래밍은 무엇을 어떻게 할 것 인가에 주목하고, 선언헌 프로그래밍은 무엇을 할 것 인가에 주목한다. -
1급객체, 고차함수
1급객체: 파라미터로 함수를 전달할 수 있어야 하고 자료구조안에 담을 수 있어야함. 반환값으로 사용할 수 있어야 한다.
고차함수: Return 값을 통해 다시 함수를 호출할 수 있어야함.
장점: 높은 수준의 추상화 제공, 불변성을 지향하므로 결과 예측이 쉬워짐.
단점: 코드의 가독성이 좋지 않아질 수 있음. 반복을 for문 등이 아니라 재귀를 통해서 구현하는데 재귀는 무한루프에 빠질 수 있다.
메소드 체이닝
메소드에서 this를 return하여 return값을 통해 해당 객체에 접근하여 메소드를 다시 호출할 수 있게 한 방식.
가비지 컬렌션
도달가능성을 체크하여 현재 root(현재 함수 지역변수, 파라미터, 전역변수, 중첩함수의 지역변수)에서 도달가능하지 않으면 삭제.
Mark-and-sweep 알고리즘: root가 참고하는 객체를 모두 mark, root에서 방문가능한 객체에 모두 mark, 더 이상 mark 할 객체가 없을 때 까지 반복. mark 안된 객체 삭제.
도메인 주도 설계
1. Core Domain 영역에 집중해라.
2. 도메인 전문과와 끈임없이 협업해라
3. Bounded Context(문맥의 경계)안에서 유비쿼터트 언어로 이야기해라.
도메인이란 문제의 영역이다. 해결해야 하는 문제별로 영역을 쪼개놓은 것. 유비쿼터스 언어를 통해 기획자-개발자-디자이너 가 모두 같은 언어로 얘기해야한다. 이 뜻은 예를 들어 기획자가 ‘member’는 ‘sign-in’할 수 있어야 한다. 라고 하면 개발자는 member 도메인을 생성하고 해당 도메인이 sign-in 기능을 가지게 설계한다.
Redis -> 핵심은 싱글 스레드, 토스에서 동시성문제 해결할 때 redis 를 써야 동시에 들어오는 쿼리에 대한 처리가 가능하다.
Q16. Docker란?
애플리케이션을 컨테이너로서 좀더 쉽게 사용할수 있게 만들어진 오픈소스 프로젝트
Q16-1. 가상머신과 도커 컨테이너의 차이
게스트 os가 없다 도커컨테이너는 그래서 호스트os의 시스템 콜을 직접 호출한다.
도커이미지에 서버 운영을 위한 프로그램과 라이브러리들이 포함되어 있는데 이런 이미지들은 도커로 각각 격리되어 설치된다.
도커엔진이 도커 이미지를 설치할때 마치 가상머신처럼 분리시켜준다. 하지만 호스트 OS는 공유한다.
Q16-2. 도커 허브란?
도커는 이미지 생성과 배포에 특화된 기능을 제공하는데 이걸 깃처럼 이용하면 이미지를 pull/push할 수 있다.
이것들을 공유하는 github같은 도커허브가 제공된다.
Q16-3. 도커 이미지와 컨테이너의 차이
도커이미지는 베이스 이미지에서 몇가지 라이브러리나 프로그램 소스코드등을 추가/설치/저장한 이미지이다.
컨테이너는 이미지가 실행된 상태
Q16-4. 도커 컴포즈란?
컨테이너 옵션들을 설정한 파일 , 도커 컴포즈가 없다면 도커 실행명령(run)뒤에 옵션으로 길게 붙여서 실행해야된다.
도커 컴포즈를 사용하면 빌드와 실행시 명령어가 간단해진다.
Serverless
event가 트리거 될 때만 서버가 켜진다. 사용자는 이때 사용된 서버비만 지불하면 된다.
서버리스를 활용하면 운영 체제 및 파일 시스템 관리, 보안 패치, 부하 분산, 용량 관리, 스케일링, 로깅, 모니터링과 같은 일상적인 태스크를 모두 클라우드 서비스 제공업체에 이관할 수 있습니다.
Index 설정할 떄 주의할 점
다중 컬럼 인덱스에서 Cardinality 가 높은 column을 index에서 먼저 설정하는 것이 좋다. index는 메모리 공간을 차지하므로 많은 index를 띄우면 메모리 공간을 많이차지하여 좋지않다. 또한 update,delete에 많은 cost가 소요되고 index가 많으면 옵티마이저가 잘못된 index를 선택할 확률도 커진다. 따라서 3~4개의 index가 적당하다.
정적 팩토리 메소드
객체 생성의 역할을 하는 클래스 메서드.
이름을 가질 수 있다. 메소드니까.
입력 매개변수에 따라 매번 다른 클래스의 객체를 반활할 수 있다.
정적 팩토리 메소드는 개발자가 찾기 어렵다. -> API문서를 잘 쓰고 메소드 이름을 알려진 규약에 따라 짓는 식으로 완화시켜야 함.
상속을 하려면 public이나 protected 생성자가 필요한데 정적 팩토리 메소드만 제공하는 class이면 하위 클래스를 만들 수 없다.
Ssh 역할
네트워크 프로토콜 중 하나로 컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해서 서로 통신을 할 때 보안적으로 안전하게 통신을 하기 위해 사용하는 프로토콜이다.
데이터를 전송하거나 명령을 내릴 수 있다.
TCP 흐름제어
-
Stop and wait
-
Sliding window
-> Window : TCP/IP를 사용하는 모든 호스트들은 송신하기 위한 것과 수신하기 위한 2개의 Window를 가지고 있다. 호스트들은 실제 데이터를 보내기 전에 '3 way handshaking'을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다.
TCP 혼잡제어
AIMD 방식
처음 패킷 하나를 보내 문제가 없다면 Window Size를 1씩 증가시키는 방식. RTT마다. Rtt 는 계속 바뀐다. (Rount trip time)
문제가 발생하면 Window Size를 절반으로 줄인다.
초기에 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리고 네트워크가 혼잡해지는 상황을 미리 감지하지 못한다.
Slow start 방식
처음 패킷을 하나씩 보내는 것은 같지만 매 전송마다 2배씩 증가하여 데이터의 크기가 지수함수적으로 증가한다.
전송되는 데이터의 크기가 임계값에 도달하면 혼잡 회피 단계로 넘어간다.
혼잡 현상이 발생하면 Window size를 1로 줄인다.
혼잡 현상이 발생했던 Window Size 절반 까지는 지수함수 꼴로 증가하고 이후부터는 1씩 증가한다.
Fast recovery 방식
혼잡 시 1로 줄이지 않고 절반으로 줄이고 선형 증가
Fast Retransmit 방식
- 재전송 타이머 값이 종종 상대적으로 길어지므로, 손실된 패킷의 재전송 전에 지연시간이 커진다.
- 위의 상항을 해결하고자 중복 ACKs를 통해 손실된 세그먼트를 검출한다.
- 송신측에서 바로바로 여러 개의 세그먼트를 전송할 경우, 세그먼트가 손실되면 수신측에서는 중복 ACK를 보내게 되는데, 타임아웃 전에 송신측에서 중복 ACK를 3번받게 되면 세그먼트를 즉시 전송한다. 즉, 수신측이 기다리는 순서번호의 세그먼트보다 큰 순서번호의 세그먼트가 3개 도착할 경우를 의미한다.
4 way-handshake 어느쪽에서? 양쪽다 가능맞나?
Client. - fin -> server
Client < - ack - server
Client < - fin - server
Client - ack - > server
Client time wait ( 서버 측 fin 보다 늦게 오는 패킷이 있을 수 있으므로 일정 시간동안 socket을 닫지 않고 기다린다)
포트
네트워크를 통해 데이터를 주고받는 프로세스를 식별하기 위해 호스트 내부적으로 프로세스가 할당받는 고유한 값
소켓
프로세스가 커널에 접근하기 위해서 쓰는 인터페이스
네트워크상에서 동작하는 프로그램 간 통신의 종착점(Endpoint)
두 시스템 사이의 네트워크 연결을 나타내는 객체
소켓을 열기 위해선 호스트에 할당된 IP, 포트 번호, 프로토콜이 필요하다.
위 세가지가 소켓을 정의할 수 있지만 유일하게 식별하지는 않는다.
보내는 쪽과 받는 쪽 모두 소켓을 열어야 한다.
하나의 프로세스가 같은 포트를 갖고 여러 개의 소켓을 열 수 있다.
- src port, src ip, dst port, dst ip로 구별
Synchronous -> 외부 프로세스를 호출하고 답변을 계속 기다림.
Asynchronous -> 외부 프로세스를 호출하고 답변을 기다리지 않음. 자기 할 일 함.
Blocking -> 외부 프로세스를 호출할 때 제어권(작업을 할 권리)가 외부 프로세스로 넘어가서 답변할 때 돌아옴.
Nonblocking -> 제어권이 호출할 때 외부 프로세스로 넘어갔다가 거의 바로 다시 돌아옴.
sync_blocking, async_nonblocking 이 보통.
sync_nonblocking -> polling
async_blocking -> 제어권이 없어서 답변을 기다리지도 않는데 아무일을 못함. sync_blocking이랑 차이가 없다. 그래서 안쓰는데 의도치 않게 구현되는 경우가 있다. 대표적인 예로 js에서 비동기로 mysql을 호출하면 mysql은 blocking으로 작동하므로 async_blocking이 된다.
http 0.9
http 헤더도 없었고 get 연결만 가능. 보낼때마다 3-way handshake 과정이 필요했음. Html 파일만 보낼 수 있었고 response code 도 보낼 수 없었다.
http 1.0
http 헤더가 생겼다. 따라서 response code도 보낼 수 있게 됐고 content-type에다가 파일종류를 적어서 html 말고 다른 파일들도 전송이 가능해졌다. 커넥션 하나당 요청하나 응답하나만 처리가능했다. 보낼때 마다 3-way 하는건 아직 해결 못함.
http 1.1
Persistent connection: 지정한 시간동안 connection을 닫지않음.
Pipelining: 하나의 요청을 보내고 응답을 기다리지 않고 다음 요청이 있으면 순차적으로 다 보냄. 하지만 요청이 간 순서로 응답이 와야하므로 레이턴시가 많이 생긴다. 젤 먼저 간애가 오래걸리면 뒤에 애들이 먼저 끝나도 오래 기다려야 하기 때문이다. (Head of line blocking)
Header 데이터의 중복문제도 생긴다. 패킷이 여러개 보내질 때 헤더에 이전에 보낸 정보도 계속 보내짐.
http 2.0
가장 큰 변화는 메세지 전송방식의 변화이다. 이전에는 text 형식으로 보냈는데 2.0에서는 binary framing 을 도입해서 text를 frame 단위로 나누고 binary로 인코딩한다. binary이므로 파싱,전송속도가 향상됐다.
이것에 의해 head of line blocking이 해결 됐는데 frame으로 data를 쪼개서 보내니까 중간에 다른 data가 끼어들 수 있어져서 data의 요청,응답 순서가 상관 없어졌다.(multiplexing)
Stream prioritization과 server push,header compression(헤더 중복 제거) 기능이 추가됨.
A1,b1,c1 보내고 a2,b2,c2 보내고.. 이렇게 한 패킷에 묶어서 보내는데 b2만 없어져도 tcp 오류제어에 의해 b2 만 오류가 나도 a2,c2,까지 다시 보내야되는 문제가 생긴다.
Tcp 설정에 따라 그 뒤에 패킷도 다 다시보내야 될수도.
http 3.0
구글에서 만든 http3.0에서는 tcp가 아니라 udp를 써서 오류제어가 강제되지 않으므로 quic이라는 프로토콜을 사용하여 quic에서 오류제어를 조절한다. 그래서 b2가 오류가 나면 a3,b2,c3를 함께 보내게 된다. 유튜브에서 quic을 사용한다.
Java 와 c/c++ 차이중 하나: java 는 컴파일 이후에 byte code를 jvm이 기계어로 번역하는 과정이 필요하지만 c/c++는 컴파일 과정에서 바로 기계어로 번역되므로 java보다 빠르다. 하지만 java도 JIT 컴파일러등의 활용을 통해 속도를 많이 따라잡았다.
가상머신 종류
호스트 os, 하이버 파이저, 컨테이너
Cpu 스케줄링
선점형: 프로세스에 cpu 자원이 할당되고 나서 다른 프로세스가 그 자원을 가져갈 수 있는 스케줄링 방식. 우선순위, 시분할 등 다양한 방식에 의해 스케줄링이 이루어 질 수 있다. 하지만 기아현상이 발생할 수 있고 프로세스의 완료시간을 예측하기 힘들어진다.
Round robin: 각 프로세스들은 같은 시간을 할당받는다. context switching이 일어나면서 multi tasking이 일어난다.
비선점형: 프로세스에 cpu 자원이 할당되고 나서 다른 프로세스가 이 자원을 가져갈 수 없다. 중요 프로세스가 늦게 수행될 수 있고 앞에 시간이 오래 걸리는 작업이 있으면 뒤에 다른 짧은 프로세스들도 병목현상에 의해 완료 시점이 늦어진다. 하지만 완료시간을 예측하기 용이하다.
fifo
NoSQL
NoSQL은 Not Only SQL의 약자이다. 기본 RDBMS의 한계를 극복하기 위해 만들어진 새로운 형태의 데이터베이스다. 릴레이션이 아니므로 고정된 스키마가 없고 조인이 힘들다. 빅데이터를 다룰 때, RDBMS로만 트래픽을 감당하기 어려워졌고, 이를 해결하려고 NoSQL이 탄생했다. NoSQL은 분산 환경에서 대용량의 데이터를 빠르게 처리하기 위해서 개발되었다. 핵심은 Horizontal Scalability(수평확장)과 High Availability(고가용성)이다.
RDBMS의 한계
많은 데이터량과 데이터 처리량이 계속적으로 증가한다면 RDBMS는 아래와 같은 문제점을 만난다.
•
• 스키마 문제 : 빅데이터를 RDB의 스키마에 맞춰 변경해서 넣으려면 매우 긴 시간의 down time이 발생
• 스케일업의 한계 : RDBMS는 애초부터 스케일 아웃을 염두에 두고 설계되지 않았다. 관계 모델과 트랜잭션의 연산, 일관성, 속성을 유지하면서 분산환경(스케일아웃)에서 RDBMS를 조작하는 것은 어렵다.
2. 특징과 장점
•
• 거대한 Map으로서 key-value 형식을 지원한다.
• RDBMS가 데이터의 관계를 Foreign Key 등으로 정의하고 Join 등 관계형 연상을 하지만 NoSQL은 관계를 정의하지 않는다.
• 대용량 데이터 저장을 한다.
• 분산형 구조를 통해 여러대의 서버에 분산하여 저장하고 상호복제하여 데이터 유실이나 서비스 중지에 대비한다.
• Schema-less
• 읽기 작업보다 쓰기 작업이 더 빠르며, 일반적으로 RDBMS에 비하여 쓰기와 읽기 성능이 빠르다.
- CAP
분산형 구조는 일관성(Consistency), 가용성(Availability), 분산 허용(Partitioning Tolerance)의 3가지 특징을 가지고 있다. CAP 이론은 이 중 2가지만 만족할 수 있다는 이론이다. NoSQL은 대부분 이 CAP 이론을 따르고 있다.
1
2 일관성(Consistency) : 분산된 노드 중 어느 노드로 접근하더라도 데이터 값이 같아야 한다. (데이터 복제 중에 쿼리가 되는 일관성을 제공하지 않는 시스템의 경우 다른 데이터 값이 쿼리될 수 있다.)
3 가용성(Availability) : 클러스터링된 노드 중 하나 이상의 노드가 실패(Fail)라도 정상적으로 요청을 처리할 수 있는 기능을 제공한다.
4 분산 허용(Partition Tolerance): 클러스터링 노드 간에 통신하는 네트워크가 장애가 나더라도 정상적으로 서비스를 수행한다. 노드 간 물리적으로 전혀 다른 네트워크공간에 위치도 가능하다.
일반적으로 RDBMS는 일관성과 가용성을 만족한다. NoSQL은 가용성과 분산허용을 만족하는 제품군과 일관성과 분산허용을 만족하는 제품군으로 나눌 수 있다.
예를들어 atm기기가 a,b 두 개가 있고 사용자가 한 명있다. A,b사이의 통신이 끊어진 상황에 사용자는 a atm기기에서 계좌에 입금을 한다. 일단 p가 만족되면 a,b는 각자 정상 작동한다. 하지만 여기서 c,a를 선택해야 한다. c를 선택하면 입금을 거부할 것이고 a를 선택하면 입금을 허용한 후 차후에 b에 입금내역을 공유할 것이다.
출처: https://sjh836.tistory.com/97 [빨간색코딩:티스토리]
Spring mvc 패턴 동작 방식
Dispatcher servlet으로
시스템콜이 트랩이다.
