어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
많이 들어보기는 했지만 정작 무슨 일을 하는지는 감이 잘 안오는 DevOps. 왜 실리콘밸리의 구글과 같은 선도적인 기업들에서는 DevOps나 SRE(Site Reliability Engineering)조직이 생기는걸까?그 조직에서는 무슨 일을 하는지, 그 일이 왜 중요한지, 어떤 사람들이 그 곳에서 일을 하는지, 그들은 어떤 기술을 사용하고 어떤 커리어로 성장하는지에 대해 북미에서 6년간 DevOps팀에서 일한 경험을 바탕으로 50분 동안 청중들에게 그 이야기를 해보고자 합니다. 또, DevOps 개발자(엔지니어)가 되려면 무엇을 준비해야 하는지에 대해서도 짚어보려 합니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
많이 들어보기는 했지만 정작 무슨 일을 하는지는 감이 잘 안오는 DevOps. 왜 실리콘밸리의 구글과 같은 선도적인 기업들에서는 DevOps나 SRE(Site Reliability Engineering)조직이 생기는걸까?그 조직에서는 무슨 일을 하는지, 그 일이 왜 중요한지, 어떤 사람들이 그 곳에서 일을 하는지, 그들은 어떤 기술을 사용하고 어떤 커리어로 성장하는지에 대해 북미에서 6년간 DevOps팀에서 일한 경험을 바탕으로 50분 동안 청중들에게 그 이야기를 해보고자 합니다. 또, DevOps 개발자(엔지니어)가 되려면 무엇을 준비해야 하는지에 대해서도 짚어보려 합니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
커빙의 Django, Celery, Azure Cloud, SNS 연동, 컨텐츠 수집 기술을 한눈에 볼 수 있도록 소개한 자료 입니다.
커빙을 처음 개발하면서 많은 어려움이 있었지만
많은 분들의 도움으로 좋은 결과를 얻을 수 있었답니다!
이에 다른 분들에게 조금이나마 도움이 되었으면 좋겠다는 마음으로 공유합니다 : )
커빙의 Django, Celery, Azure Cloud, SNS 연동, 컨텐츠 수집 기술을 한눈에 볼 수 있도록 소개한 자료 입니다.
커빙을 처음 개발하면서 많은 어려움이 있었고,
또 많은 분들의 도움으로 좋은 결과를 얻을 수 있었습니다.
조금 더 깊은 내용을 다뤘으면 하는 아쉬움이 있지만,
다른 분들에게 조금이나마 도움이 되었으면 좋겠네요!
[Uws] enterprise application architecture, msa, java9, spring 소개HYUN-JOO LEE
회사 교육용으로 만든 자료입니다. 엔터프라이즈 어플리케이션 아키텍처의 개념부터 시작하여 마이크로서비스 아키텍처와 기존 모놀리식 아키텍처 비교하고 왜 우리가 자바9에 집중해야 하는지 설명하려고 만든 자료입니다. 현재 회사에서 진행하고 있는 클라우드 어플리케이션 통합/아키텍처링 사업과 PoC 플랫폼 개발을 위한 회사 내부 교육용으로 만들었습니다. MSA 부분은 IBM Blumix 밋업 자료에서 발췌했습니다. 잘못된 부분이나 다른 의견이 있으신 분 댓글이나 메세지 주세요. hjlee@uws.co.kr
designing, implementing and delivering microservices with event storming, spr...uEngine Solutions
Implementing Microservices is something like an adventure. Analyzing and decomposing microservices with applying DDD and make them into code, all is not easy. With new simple approach - Event storming, designing and implementing an event-driven MSA became easier ever seen before.
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
초고속 웹사이트 개발을 위한 Codeigniter PHP FrameworkInseok Lee
지난 10월에 연구실에서 진행했던 세미나 자료입니다.
웹개발에 대한 기본적인 개념이나 프레임웤에 대한 내용을 전혀 모르는 학부 학생들과 연세가 있으신 박사과정 학생들을 위해 제작되었습니다.
Codeigniter의 내용보다도 왜 Codeigniter를 쓰면 좋은지, 그리고 웹 개발 방법은 어떻게 바뀌어 왔는지 등을 이곳저곳의 슬라이드(Codeigniter 한국사용자 포럼의 웅파님, 다음커뮤니케이션의 윤석찬님)를 정리하였습니다.
초보자를 대상으로 하는 강의에서 참고하면 좋을 것 같아용~
관련 문의는 Codeigniter 한국사용자 포럼 codeigniter-kr.org 에서 해주세요~
모바일 게임과 앱을 위한 오픈소스 게임서버 엔진 프로젝트 CloudBread 프로젝트Dae Kim
CloudBread
클라우드 기반 무료 오픈소스 프로젝트로, 모바일 게임과 모바일 앱에 최적화된 게임 서버 엔진입니다. 모든 서비스는 마이크로소프트의 클라우드 서비스인 Azure에 최적화되어 동작하며, 안정성과 확장성을 목표로 개발 중입니다.
기능
•PaaS / DaaS 서버 엔진•PaaS, DaaS 로 손쉬운 개발 및 서비스 즉시 배포
•Real Auto Scale - PaaS
•개발/테스트/배포 = 통합 환경
•서비스 규모에 따른 앱 변경 없음
글로벌 론칭 아키텍처
•글로벌 론칭+데이터 동기화
•설계 부터 클라우드에 최적화된 아키텍처 및 프레임워크로 개발
•오픈소스 프레임워크 활용 개발
보안, 관리, 기술교육
•저장/통신에 표준 암호화 기술 적용
•기본 관리자 서비스 및 커스터마이징
•분석/관리 배치 작업 추가 제작 가능
개발자 그룹
•페이스북 사용자 그룹 : https://www.facebook.com/groups/cloudBreadProject/
지원되는 모바일 & 클라이언트환경
•iOS, Android, Windows Phone, Windows 스토어앱, Xamarin, PhoneGap, Sencha 등
•Microsoft Azure Mobile Service가 지원하는 모바일 및 다양한 클라이언트 플랫폼 지원 : http://azure.microsoft.com/ko-kr/documentation/services/mobile-services/
설치
•Wiki의 튜토리얼 설치 참조
프로젝트 설명
•모바일게임과 모바일 앱에서 사용되는 사용자의 패턴과 액션을 기록해 기능들을 제공
•클라이언트 모바일 디바이스는 게임서버로 JSON 방식의 데이터를 요청하고 서버가 해당 데이터를 처리 후 응답
•약 100여개의 비즈니스 로직이 기본제공(Wiki 참조)
•클라이언트는 마이크로소프트가 오픈소스로 직접 만들어 제공하는 라이브러리를 통해 서버로 API를 호출
실행 예제와 API 리스트는 Wiki 참조
Contribute/질문/토론
•페이스북 사용자 그룹 : https://www.facebook.com/groups/cloudBreadProject/
이노베이션 아카데미 멘토로서 3년 간의 혁신교육 경험을 글로 정리했습니다.
- 독자 : 개발자 학교, 부트캠프 등
- 했던 일 :
- 42 Seoul (에꼴42 서울캠퍼스) 교육지원
- 새로운 교육모델 연구개발 (집단학습모델, 학습 커뮤니티 연구)
pdf 파일로 누구나 다운로드 가능합니다.
출처명기 후 얼마든지 인용 및 활용 가능합니다. (6.5 MB, 224페이지)
좋은 후배 많이 양성해주세요.
오탈자 양해 부탁드립니다.
소개글 : https://subokim.wordpress.com/2023/03/20/3years_in_innoaca/
제가 멘토로 참여한 한 팀과제를 올려봅니다.
참여 팀원들 모두 고생하셨습니다.
---
관심 : 장애인복지시설 개선에 대한 관심으로 시작,
주제 : 평균 1시간 이상씩 걸리는 "장애인콜택시" 대기시간 분석
목표 : 어떻게 개선할 수 있을까를 도출함.
참고 : http://data.seoul.go.kr
교육과정 : SBA 빅데이터 교육과정, PBL 과제
앱서비스에서 결제를 하고 싶어하는 팀을 위한 안내서.
개념 잡기용이며 상세한 것은 링크를 참조하셔서 공부하세요.
- 독자 : 결제, 정산을 구현하고 싶은 개발자 (입문자 이상)
- 내용 : 결제를 개발할 때 내 서버에 구현해야 할 것들
- 특이사항 : 요즘은 '아임포트' 같은 걸 이용해서 쉽게 연동이 가능합니다만...
OKJSP 'SI프리랜서 개발자들을 위한 5 Step Manual' 이라는 행사에서 발표한 내용입니다. 청중의 50%정도는 SI 개발자분들이셨고 50%정도는 프리랜서를 고민하는 분들이었습니다. 주로 미래에 대한 불안이 많으셨는데요. 스스로를 어떻게 가꾸고 알릴 것인가를 말씀드렸습니다.
OKJSP, '개발자의 삶' 행사에서 발표한 내용입니다.
개발자들이 어떻게 살아야 할지 이야기를 해주는 경우가 많지 않아 초기 취업과 이직에 실패하는 분들이 적지 않은데요.
부족하지만 제 경험들을 바탕으로 얻는 노하우를 함께 공유해드렸습니다.
- 독자 : 5년차 이하의 개발자분들
- 주제 : 취업관련 진로고민
- 주요 내용 : 내가 경험해본 회사들과 특징
- 인용시 출처명기
대형 병원의 교양 세미나에서 발표한 자료입니다.
이미 기술 지식은 충분하셨고 사례를 많이 궁금해 하셨습니다. 그래서 제 경험을 통해 얻었던 인사이트를 많이 나누었습니다. 하지만 의료현장은 플랫폼이나 기술보다는 의료기기로 접근하지 않으면 사용되기 힘들다는 생각이 들었습니다.
3. 용어정리
3
Linux
Apache
Tomcat
*.jar
서버 어플리케이션
-개발자가 코딩을 해서 기능이 작동하는 실행파일
- ex. *.jar, *.js, *.py …
웹 어플리케이션 서버(WAS)
- 서버 어플리케이션이 동작할 수 있도록 해주는 실행 소프트웨어
- 웹 프로토콜로 호출이 가능하게 해준다.
- 기본적으로 깔려 있지 않고 설치를 해야 한다.
- ex. Node.js, Tomcat, Django …
웹서버
- 웹 페이지를 PC나 단말로 보내주는 기능을 하는 프로세스
- 기본적으로 깔려 있지 않고 설치를 해야 한다.
- ex. Apache, nginx
서비스
- 서버 어플리케이션들이 모여서 무형의 서비스를 제공해주는 단위
- ex. 인증 서비스, 찜하기 서비스
프로세스 vs 어플리케이션 vs 프로그램
- 프로세스 : 서버에서 메모리를 점유하고 있는 단위
- 어플리케이션 : 기능을 제공하고 있는 단위
- 프로그램 : 소프트웨어 개발자가 개발한 결과물을 통칭
- 막 혼용해서 사용됨
막 혼용되어서 사용되지만, 그래도 알아는 둡시다.
4. 서버 개발자가 부닥치게 되는 것들
4
구분 내용 실력 늘이기
어플리케이션 개발 • 기획에 맞게 기능을 개발하는 것을 말합니다. • 프로젝트를 많이 해보시고, 좋은
소스를 많이 보세요.
모델링 • 서버는 눈에 보이지 않기 때문에 모델링이 중요합
니다. 기능이 많거나 협업을 해야 한다면 필수.
• 기초가 매우 중요. 좋은 책과 강의
로 공부를 하세요. 창의력과 논리적
사고가 중요합니다.
서버 엔지니어링 • 여러 개의 프로세스나 기능이 하드웨어 상에서 잘
작동하도록 튜닝 하거나 구조를 잡는 작업을 말합
니다.
• 책도 없고 가르쳐 주는 곳도 없습
니다. 현업에서 배우는 수 밖에 없습
니다. 이론과 현장의 느낌이 많이 다
릅니다.
시스템 엔지니어링 • 서버라는 하드웨어 자체를 튜닝하는 일을 말합니
다. OS 설정을 변경하는 일이 많습니다.
네트워크 개론 • 사설 네트워크에서는 이상하게 작동하는 경우가
있습니다. 부하분산이 이상하게 작동하기도 합니다.
장비 문제는 대부분 어플리케이션 변경으로 대처합
니다.
시스템 소프트웨어 • Web Server, WAS, DB 등에 대해 충분한 지식이
있어야 합니다. 서비스 목적에 맞게 기능과 성능을
100% 활용할 수 있으면 좋습니다.
• 홈페이지, 구글링을 통해서 단편적
으로 해결할 수 있습니다.
• 벤더 교육을 별도로 받으세요.
아키텍쳐링 • 이 모든 것을 이해해서 전체적인 구조를 잡는 것
을 말합니다.
• 좋은 스승이 필요합니다. 경험이
없으면 좋은 설계를 하기 힘듭니다.
그래서 좋은 선배를 만나는 것과 다양한 환경에서 일하는 것이 중요합니다.
스타트업에 있다면 아래 것은 다 개발자 몫입니다. 다른 경우도 비슷합니다.
5. 가상의 앱을 만들어 봅시다.
5
① 제가 경험했던 것으로는 발표할 수 없어서
② 가장 유명하면서도 설명하기 쉬운 앱으로 선정
③ 설명을 위해서 핵심적인 내용만 추려서
④ 경험을 섞은 사례를 만들었습니다.
Anstagram
6. 앱 + 서비스
6
☞ 해결하고 싶었던 문제점들
- 모바일 사진은 그다지 멋있지 않다. 필터가 전문가의 사진처럼 보여줄 것이다.
- 여러 플랫폼에 공유하는 것이 힘들다. 당신은 찍어라. 우리가 공유해 주겠다.
- 사진을 업로드하기 힘들고 오래 걸린다. 우리는 빠르고 간편하게 만들고 싶다.
☞ 우리의 미션
- 내가 경험하는 멋있는 순간들을 사진을 통해 친구들과 나누고 싶다.
7. 제공하고 싶은 기능
7
Home – Timeline
- 팔로워들의 사진이 올라온다
- 좋아요와 댓글들이 요약되어
보여진다.
사용자 수 * 컨텐츠 수
Filter & Upload
- 사진을 선택해서 필터한 후
- 서버에 업로드 한다.
전송 Fail, 사진의 크기
해상도
My Info
- 내 정보와 내 소개
- 내가 찍은 사진들이 보여진다.
내 팔로워, 팔로잉 수
Popular
- 인기 사진들이 보여진다.
- 내 성향과 비슷한 사진들이 보
여진다.
인기사진 추출 정책
사용자 수 * 추천 페이지 수
Notification
- 내 팔로워의 알림을 수신한다.
- 내 사진에 일어난 일들을 수신한다.
사용자 수 * 알림 수
Photos
- 내가 찍은 사진과
- 좋아요와 댓글들이 모두 보인다.
태그, 좋아요, 댓글
알림
8. 구현해야 할 세부 기능들
8
타임라인
팔로잉
댓글
# 검색
사진 필터
해상도 조정
전송기능
타임라인
동기화
사진 보기
댓글보기
좋아요
댓글달기
타임라인
동기화
인기사진
선정처리
선호사진
선정처리
실시간 추천
사용자 검색
좋아요 알림
댓글 알림
친구활동
알림
푸쉬기능
내 정보 조회
변경
내 팔로우
정보
내 사진 조회
위치기반
조회
사용자 인증
이메일 확인
비밀번호
조회, 변경
SNS 공유
보안기능
9. 실제 서버 구조 둘러보기(2011)
9
※ 번역글 : http://bit.ly/instatechhist
※ 원 문 : http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances
가입자 1,400 만명, 서버 수백 대, 개발자 3명
- 심플하게 유지한다. (=기능의 추가 및 변경, 관리가 용이한 구조로 만든다.)
- 바퀴를 재발명 하지 않는다. (=가능한 인프라를 활용한다.)
- 가능한 명확하고 증명된 방법을 이용한다. (=최신기술의 시행착오를 줄인다.)
DNS DNS
WAS WAS WAS
DB #1 DB #2 DB #3
WAS
1번유저 2번유저 3번유저
nginx 를 이용하여 Round Robin으로 호분배
현재는 Amazon의 ELB를 사용
DNS는 Amazon의 Router53 사용
SSL과 ELB레벨 종료 (성능향상)
High-CPU Extra Large 25대
- 7GB Memory
- 20 Unit
- Django
Quadruple Extra Large 12대
- PostgreSQL
- Horizontal Sharding
Image
Server
Amazon S3
Cache Server Amazon CloudFront
Search PostgreSQL Apache Solr
- Geo Search에서 Media Search로 확장
Feed Redis
Cache Memcached Elastic Cache
Push
Open Source twisted
- Pyapns
- 200개 worker
Monitoring Munin, Pingdom, PagerDuty, Sentry
- 100대 이상의 서버관리
Scale Out
Scale Out
10. 사용자와 사용량의 증가
10
☞ 사용자의 증가(2010~2013) ☞ 사진 업로드량의 증가 (2010~2012)
☞ 서비스 회사의 투자와 기대수익의 패턴
11. 서비스 성장에 따른 기술구조 변화
11
정답은 아니지만 많은 서비스가 이러한 성장 패턴을 따라 갑니다.
단말 어플
서비스로직
인프라 임대
단말 어플
서비스로직
임대 인프라
상용 데이터
단말 어플
서비스로직
임대 인프라
상용 데이터
인프라 구축
단말 어플
서비스로직
임대 인프라
상용 데이터
인프라 서비스
인프라 구축
파일럿
서비스오픈
수익화
플랫폼화
프로젝트 팀 서비스 사용자 제휴 사업자 연계 서비스
• 아이디어를 시스템화
하는 단계
• 유즈케이스 정리
• 데이터항목 정리
• 사용자 패턴에 적합
한 기술구조로 구축
• 실전 데이터 축적
• 클라우드 인프라
• 제휴사업 기능 개발
• 수익화 로직 추가
• 제휴사업용 데이터가공
• 3rd Party 기능 개발
• 수수료 기반 유통플랫폼
개발
12. 스타트업에 필요한 기본 서버들
12
분류 서버 내용
서비스
관련
DNS 서버 도메인(예: ok.co.kr)을 구매해야 함.
보통 Whois 개인 DNS Smart DNS
웹서버 Apache, nginx
웹 서비스, 이벤트의 랜딩페이지
아이디, 비밀번호 찾기
API 서버 Node.js, Django, Tomcat …
REST API 권장, 인프라는 J2EE 많이 사용함
DB 서버 초기 파일럿은 Document oriented database(mongodb) 권장
상용 서비스는 RDBMS (MySQL, Maria DB) 권장 이유는 구두 설명
업무관련 메일 서버 구글앱스, 네이버웍스, 다음 스마트 워크
블로그 서버 네이버 블로그, 티스토리, 워드프레스
보안 서버보안 서버 해킹에 대한 대처
서버, 네트워크 : Linux Default Firewall 사용
DB 보안 : 제한된 ip, port 보안
아무리 작게 만들어도 최소한 아래 정도의 서버를 구축하게 됩니다.
• 웹서버, API 서버, DB서버를 1대 내에 설치는 가능하지만 보통 DB서버는 따로 설치합니다.
• 초반에는 CPU, 메모리 사용률을 기준으로 서버를 나누기도 합니다.
13. 아무도 말하지 않지만 만들게 되는 기능들
13
분류 기능 설명 일반 대처방안
서비스
공통기능
로그인 기능 트위터, 페이스북, 구글, 자체 ID로그인 기능 오픈 API & 직접 구현
회원 가입 ID찾기, 비밀번호 찾기(질문,답변)
국내) 어린이, 성인, 외국인
직접 구현
단말 인증 1사람이 여러대의 단말 사용
유효한 단말인지 인증
Oauth 시스템 직접 구현
구글 앱엔진 이용
이메일 인증 이메일이 유효한지 체크하는 로직 직접 구현
푸쉬서버
(알림기능)
안드로이드, 아이폰 동시 발송 (버전별 대응)
대량 전송 가능, 안정된 성공율
오픈 API 활용 or 직접 구현
컨텐츠 관리 신고, 차단, ID정지, 스팸 필터링
컨텐츠 노출 차단 및 컨텐츠 삭제
직접 구현
SNS 공유 트위터, 페이스북 등 SNS 공유기능
인증 토큰 관리, 호출건수 관리
오픈 라이브러리 활용
서버 모듈은 직접 구현
데이터 암호화 비밀번호, 특정 정보는 암호화 암호화 모듈은 오픈 라이브러리 활용
암호화 프로세스는 직접 구현
국내 실명 인증 아이핀 인증, 휴대폰 인증 공공 API 연동
결제 모듈 카드사 연동, 현금 이체, 포인트 연계 API 연동, 법인등록(유통판매업 신고)
관리기능 서버 모니터링 서버 상태 감시 (메모리, 디스크, 프로세스 상태)
네트워크 상태 모니터링
직접 구현
- Ganglia, Munin, Zabbix
서비스 모니터링 서비스 현항에 대한 각종 통계
(요청 건수, 일일 누적 건수, 에러 건수 등)
1 Call 응답시간
Google Analytics 권장
사후 통계는 개발
실시간 통계는 오픈 라이브러리 활용
14. 여기서 짚고 넘어가는 클라우드
14
구분 BEFORE AFTER 비고
IaaS
- Infra as a Service
- 하드웨어 빌려줌
• 서버를 사서 IDC에 넣음
• ip를 받아 회사에서 접속
• 이미지 서버 개발
• IDC 이용료 (자리이용료
+NW 이용료)
• 웹으로 접속해서 신청버튼
• 그럼 ip가 나옴. 접속
• AWS S3 API를 사용함
• 이용료(무료 ~ 시분할방식)
• cafe24, AWS
• 스타트업에 유리
(초기 비용이 낮음)
• 파일럿 서비스 개발
PaaS
- Platform as a
Service
- 개발 인프라 서비스?
• push 서버를 개발해야 함
• 문자발송 서버도 개발함
• 푸쉬 라이브러리 다운받음
• 문자발송 API 호출함
• 이용료 (무료 ~ 다양)
• parse.com
• 스타트업에 유리
• 제휴전략에 유리
SaaS
- Software as a
Service
• 서버를 삼
• 회계관리 소프트웨어 설치
• 용량 부족시 증설
• 웹으로 신청함
• 로그인해서 사용함
• 이용료를 냄
• 중소기업 대상
• ERP등 필수제품
클라우드는“CPU나 디스크가 놀고 있는 PC들을 모아서 하나의 커다란 가상 컴퓨터를 만들 수 있지
않을까?” 에서 시작되었습니다. 그래도 개발자라면 아래 용어의 차이 정도는 알고 있어야겠지요?
15. Level 0. 파일럿 단계
15
서버 기능을 만들기 위한 상세한 기능명세가 확정되지 않은 상태입니다.
그래서 기능명세를 확정하는데 초점을 둡니다.
앱을 만들면서 세부 기획 사항들이 결정되는 단계입니다.
서버가 많아야 1~2대 입니다.
구분 설명
기획 • 기획 의도, 철학, 비전, 미션 등이 정의되어 있음
• 개발자가 이해하고 있어야 기술 구조, 기능 구현의 우선순위를 결정할 수
있음
기능명세 • 더 좋은 UI/UX 를 위해 화면이 변할 수 있음
• 더 좋은 선택을 위해 비즈니스 기능이 변할 수 있음
• 실제 사용자들이 어떻게 반응할 수 알 수 없음
핵심
고려사항
• Try & Error를 많이 하기 위해 투자비용(개발시간 외)을 최소화할 수 있는
기술 선택
• 빨리 서비스 기능을 시험해 볼 수 있도록 개발이 간편한 기술
- 기획의도를 제대로 구현할 수 있어야 함.
- 완성도 보다는 기획 의도의 올바른 구현에 집중
• 사용자들의 반응을 추적할 수 있도록 기술적 장치 필요
16. Level 0. 파일럿을 위한 기술 구조
16
단말 로직
단말 화면
Node.js
mongodb
1. 가능하면 PaaS를 활용하세요.
- 서버를 맨 땅에서부터 구축하지 않아도 됩니다. 그리고 여러 가지 프레임워크
와 인프라를 제공하기 때문에 핵심 로직에 집중할 수 있습니다. 주요 사이트로
는 구글 앱엔진, Parse.com 이 있습니다.
2. 사용자 피드백 수집은 Google Analytics를 활용하세요
- 추적하고 싶은 내용을 설계하고, 서비스 코드에 삽입해야 합니다.
- 사용자들이 기획의도대로 쓰고 있는지 확인할 방법을 미리 결정해야 합니다.
※ 자료 : 오늘 밤부터 쓰는 GA
http://www.slideshare.net/yongho/ga-47277482
3. DB로는 mongodb를 추천해요.
- mongodb는 데이터모델링을 미리 하지 않아도 좋습니다.
- 처음에는 화면과 DB를 1:1 매핑해서 쓰세요.
4. 독립서버를 구축해야 한다면 mean.io를 써보세요.
- mongodb + express.js + angular.js + node.js
- JavaScript Full Stack 입니다.
5. 이 기간동안 정리해야 할 것
- 서버 개발은 눈에 보이지 않기 때문에 모델링이 중요합니다. 모델링이 필요없
을 정도로 간단한 경우가 아니라면 어플리케이션 모델링을 해두세요.
어플리케이션을 만들 때 변경이 용이한 스크립트 기반 언어 사용을 추천합니다.
이 기간 동안에는 어플리케이션 모델링을 튼튼하게 하세요.
17. Level 0. 중요한 모델링
17
화면개발은 로직이 화면의 움직임에서 시작되는 경
우가 많습니다. 그래서, 굳이 UML을 쓰지 않고도 쉽
게 어플리케이션의 구조를 파악할 수 있습니다.
그러나 서버는 눈에 보이지 않습니다. 그래서 UML
모델링이 필수적입니다. UML은 복잡한 서버개발을
위한 설계도입니다.
그러나, 기능 중심인 게이트웨이 서버는 UML을 만
들지 않습니다. 비즈니스가 없기 때문입니다. 이런
중계 서버는 Call Flow가 더 중요합니다. 하지만,
SNS서비스라면 아마 초반에 중계 서버를 만들 일이
없을 겁니다.
18. Level 0. 채팅을 만들어야 해요.
18 연산처리
Parser
연산처리
Parser
DB
화면
Text(JSON, XML)
http
http
socket
socket
get, post, put, delete
connect, transfer
disconnect
Disconnected
Oriented
Transaction
Connected
Oriented
Transaction
자료를 요청할 때마다 연결을 맺음
다수의 사용자가 자원을 공유해서 써야 할 때
속도를 희생
불특정 다수의 요청을 처리하는 서비스에 적합
이미 연결된 채널에 데이터 요청을 함
응답이 빠름. 그러나 서버쪽 자원소모가 큼
인프라 내부 구성에 적합
채팅은 서버 쪽이 얼마나 자원을 소모하는지 측정해 두어야 함.
채팅방이 많을수록 메모리 사용량이 늘기도 함
잘 짜면 사용자가 많을 때만 메모리 사용량이 늘어남
일반적인 웹 서비스 개발의 경우 REST API가 바이블입니다. (CRDU)
채팅과 같은 경우는 Socket 통신. 웹이라면 node.js + socket.io 를 써보세요.
19. Level 1. 서비스 오픈 단계
19
서버 기능을 만들어도 좋을 만큼 상세한 기능명세가 확정된 상태입니다.
서비스 오픈을 한 후에도 기능의 추가와 삭제가 적지 않게 일어납니다.
사용자가 에러 때문에 이탈하지 않게 완성도를 높여야 하는 단계입니다.
서버가 10여 대 이하입니다.
구분 설명
기능명세 • 대부분의 화면이 확정되어 있지만 사소한 변경들은 발생
• 중요한 기능들은 정해졌지만 로직 변경과 기능 추가는 계속 생김.
• 서비스의 지표(사용량, 사용패턴)를 알 수 있어야 함.
핵심
고려사항
• 기능의 추가, 현재 모듈의 변경 비용이 기하급수적으로 늘어나지 않게
- 느슨한 모델링
- 기능 재활용이 가능한 구조
• 충분한 어플리케이션 완성도
- 최소한 사용자 이탈의 원인이 되지 않아야 함
- 오류 빈도가 높은 것보다 기능이 없는게 낫다.
• 서비스 안정성이 중요
- 사용량 증가로 인한 서버 장애는 즐거운 일
- 반면 작은 증가에도 서버 어플리케이션이 죽는다면 안될 일
- 관리하기 편리한 기술 구조
• 서비스의 지속적인 모니터링이 중요
- 사용자 반응은 Google Analytics로 추적이 가능
- 전체 사용량과 이용통계는 별도로 구축해야 함
20. Level 1. 서비스 오픈을 위한 기술 구조
20
단말 로직
단말 화면
Node.js / Django
MySQL
1. 여전히 PaaS를 활용하세요.
- 핵심 서비스 로직에 집중하기 위해서 PaaS는 여전히 편리합니다.
- 사용량 증가에 따른 대처방안도 고민해야 합니다.
※ 참고 : 왜 레진코믹스는 구글앱엔진을 선택했나?
http://www.slideshare.net/curioe_/lezhincomics-google-appengine-30453946
2. 서비스 지표를 정하세요.
- Google Analytics는 이미 기본입니다. 사용자들의 변화를 눈치챌 수 있는 지표
여야 합니다. 시스템의 사용량도 알 수 있어야 합니다.
3. RDBMS를 추천해요.
- 사전에 데이터 모델링을 해야 하는 불편함이 있습니다. 분석시스템을 따로 만
들지 않으려면 RDBMS가 편리합니다.
4. 독립서버를 구축한다면 구글앱엔진을 써보세요.
- AWS와 구글앱엔진은 장단점이 다릅니다. 비용, 서비스 성격, 개발인력 등의 변
수에 따라 선택이 달라집니다.
5. 이 기간 동안 정리해야 할 것
- 복잡해지는 모델링의 현행화
- 사용량 증가에 대응하기 위한 기술 구조 (자동 배포, 모니터링, 병목구간)
- 복잡성에 대비한 어플리케이션 구조(모듈 분리, 기능 공통화 등)
- 지속적인 리팩토링과 리엔지니어링 필요 (필요수준에서)
Batch Server
어플리케이션을 다시 개발하세요. 파일럿 경험을 바탕으로 기술 구조도 다시 잡고요.
나도 모르게 Batch Server란 걸 만들게 되는 단계입니다.
21. Level 1. 단말팀과 계속 싸우게 되요
21
작업을 어떻게 나눌 것인가로 자꾸 싸우게 되나요? 우선 어플리케이션 모델에 합의를
하세요. 일반적으로는 Thin Client를 선호합니다.
※ 출처 : http://www.leaseweblabs.com/2013/10/api-first-architecture-fat-vs-thin-server-debate/
22. Level 1. 데이터베이스를 선택해 봅시다.
22
데이터베이스 SW는 그 특징과 사용방법이 달라서 미리 공부해야 합니다. 구현해야 할 서비스로직과
어플리케이션의 성격에 따라서 선택이 많이 달라집니다. 포털 쪽은 mongodb, MySQL을 많이 쓰고
일반 기업들은 Oracle을 많이 쓰고 있습니다. 물론 둘 다 섞어 씁니다.
구분 종류 설명
NoSQL mongodb 페이지 단위의 데이터 조작이 많을 때
대량 데이터에 유리
HBase SQL을 지원. Hadoop 위에 설치
RDBMS MySQL 소호규모에 유리 But 글로벌 서비스에도 많이 씀
Maria DB MySQL을 오라클이 인수하자 개발자가 새로 만든 DB
PostgreSQL Spatial 검색기능이 장착된 DB
Oracle 백업과 복구기능이 매우 강화된 DB
SUN 인수 직후 구글과 특허분쟁을 함으로써 악의 축으로 등극
Memory DB Redis Key-Value 타입의 메모리 데이터 조작
Memcached 캐시 서버. DB가 추가로 있어야 함
Altibase 상용 DB 서버. SQL 지원. 다양하고 복잡한 기술 지원
23. Level 1. 웹 개발도 해야 되요
23
※ 출처 : http://www.optisolbusiness.com/insight/how-to-integrate-angularjs-with-rails
웹 브라우저 상에서 안드로이드 앱처럼 동작하게 만들기도 합니다. 그러다보니 웹 화면도 MVC 패
턴으로 설계를 해야 합니다. 엄밀히 말하면 프론트 엔드 개발자의 영역이지만, 서버개발자로 일이
넘어오는 경우도 있습니다. 가능하면 프론트 엔드 개발자를 찾아 보세요.
24. Level 2. 수익화 단계
24
사업 담당자가 제휴사업계획를 가지고 옵니다.
서비스와 별 관련이 없는 듯한 새로운 숙제를 받은 듯한 느낌이 듭니다.
개발량도 만만치 않고 애자일을 포기하고 싶은 유혹도 생깁니다.
이 때는 별도의 개발팀이 필요한 단계입니다.
그간 관리했던 상세한 모델링 데이터가 가장 필요해지는 시기입니다.
서버가 30~40대 정도로 불어납니다.
구분 설명
기능명세 • 제휴 조건에 따라 구현해야 할 기능의 내용이 바뀜.
• 일반적으로 API 연동을 많이 사용함 (기능 공유, 데이터 전달)
• 광고는 서비스 화면에 표현되는 경우도 있음
핵심
고려사항
• 서비스 로직의 청결 유지
- 제휴 기능의 변화, 중지, 추가에도 서비스 흐름이 안정적일 것
- 제휴가 늘어나도 서비스가 불편하지 않을 것
• 제휴 인프라는 별도로 구축해야 함
- 수익성 트래픽을 서비스와 분리
- 정확한 계량과 정산 처리가 필요함
25. Level 2. 수익화를 위한 기술 구조
25
단말 로직
단말 화면
Node.js / Django
MySQL
1. 제휴 인프라는 별도 구축하세요.
- 서비스 간섭 현상을 방지하기 위해 서버를 따로 구축하세요.
- 정산, 결제, 인증 등은 공통 인프라로 별도 구축하세요.
2. API로 트랜잭션 분리
- 서비스와 제휴는 개발과 운영 방법이 상이합니다. 그리고 어플리케이션이 서로
다른 라이프사이클을 가지고 있습니다. API로 연동하시고 에러처리를 잘 해서
장애파급이 나지 않게 잘 분리하세요.
3. 어플리케이션 구조의 단순화
- 제휴가 복잡해질수록 서비스가 복잡해지게 됩니다. 관리하고 대응하기 쉽게
어플리케이션을 자주 리팩토링하세요. 그리고 필요하면 서버 리엔지니어링도 하
세요.
- 중요한 건 개발자가 변경 관리하기 쉽게 유지하는 것입니다.
5. 이 기간동안 정리해야 할 것
- 팀간 협업문제가 발생하므로 업그레이드 계획이나 사전 테스트가 중요해집니
다. 그리고 배포 후 확인 절차도 중요해집니다. 따라서 제휴 인프라와 서비스 간
에 연계된 서버 및 어플리케이션 호출 구조 등이 눈에 보이는 문서로 관리되어
야 합니다.
Batch Server
제휴 인프라
풀이법이 다양하지만 하나인 듯 하나가 아니게 구축해야 하는 숙제입니다.
API 기술을 잘 활용하세요.
모든게 까다로워지고, 유지보수 노력이 갑자기 두 배 이상 증가되는 시기입니다.
26. Level 3. 플랫폼화 단계
26
여기까지 왔다면 이미 몇 차례의 투자를 받았을 것이고,
회사가 충분히 돈을 벌고 있을 겁니다.
좋은 CTO를 모시고 좋은 전략을 가지고 문제를 풀어가시기 바랍니다.
27. 산업별로 서버의 기술 구조가 다릅니다.
27
구분 포털 금융권 이동통신사
비즈니스 환
경
• 많은 사용자가 많이 조회
• 단순 조회성 트래픽 중심
• 응답시간이 느리면 사용자 이탈
• 화면 구성이 빠르게 변화됨
• 신규 기능의 추가 빈도가 높음
• 서비스 간의 의존도가 적음
• 일정한 사용자 일정한 사용 패턴
• 응답시간이 느려도 대기
• 신규 기능이 규제에 따라 생성됨
• 업무가 먼저, 기능은 나중
• 일정한 패턴으로 서비스 연계
• 회선을 다양한 상품으로 패키징
• 통신 인프라 판매 서비스
• 제휴 서비스 선호,유무선 통합 상품
• 회선과 과금 대행 인프라가 핵심
• 무선포털사업은 사라짐
• 최근 전략 변화가 심함
주요 기술
구조
• 대량 단순 조회 트래픽 간단한
기술구조 선호
• 비용절감 이슈로 오픈소스 선호
• 스택 중심의 기술구조
• 느슨한 업무 모델링
• 스크립트 기반의 언어 선호
• 복잡한 아키텍쳐 + 단순한 기능개
발
• 안정성을 위한 상용소프트웨어 선
호
• 통제된 운영 환경과 최적화된 기술
구조
• 컴파일 기반의 언어 선호
• 미들웨어 중심의 트랜잭션 처리
• 업무 변화가 심해 기능 중심의 구조
• 오래전부터 인프라와 플랫폼 공통
• 다양한 장비로 인한 GW 가 많음
• 운영계는 오픈소스, 과금계는 상용
소프트웨어 선호
특징 • 운영 데이터가 사용자 분석을 위한
중요자료로 활용됨
• 운영 개발 (DevOps) 스트레스가 매
우 높음
• 운영업무와 구축업무가 확연히 분
리되며 운영이 보수적임
• 상품이나 서비스의 변화가 심해 업
무 자동화 및 구조화가 매우 어려움
어떤 비즈니스인가에 따라 기술구조가 달라집니다. 따라서 적성에 맞는 직장을 찾는
것도 매우 중요합니다. 산업 영역을 갈아탈 때 많은 경험과 기존 지식들이 인정받지 못
하게 됩니다.
28. 보너스. IDC가 어떻게 생겼지?
28
Internet Data Center
- 일정한 온도와 습도
- 안정된 전력과 정전 백업 장치
- 내진 설계, No 먼지
Server Rack
- 여러 대의 Server, Disk
- 관리하기 편리하게 모아서 배치
HP ProLiant DL360 G3
- Rack 설치용 Blade 타입 케이스
- 강력한 냉각팬
Main Board
- Multi CPU, Multi Memory Slot
- 여러 개의 HDD Bay
- HDD 핫스왑 기능
29. 보너스. 서버가 어떻게 생겼지?
29
Scale Out
- 서버 대수를 늘려서 전체 트래픽 처리량을 늘림
- 서버가 나누어서 일처리 할 수 있도록 하드웨어를
잘 구성해야 함
- 서버가 나누어서 일처리 할 수 있도록 소프트웨어
배치 및 기능 구성을 잘 해야 함
- 블로그 서비스와 같은 경우에 적합
(많은 사용자, 단순한 기능, 빠른 응답)
- 웹서버로 많이 사용됨
Scale Up
- CPU와 메모리를 추가해서 처리성능을 높임
- 메인보드가 허용하는 한계까지만 추가가 가능
- OS (Unix, Windows 등)가 CPU를 인식해야 함
- 1개의 프로세스가 모든 CPU를 사용하지는 못함
- 2개의 프로세스가 2개의 CPU를 사용하도록 구성
해야 함
- 데이터 분석 서비스에 적합
(소수 분석가, 복잡한 연산처리, 많은 데이터 로딩,
후처리가 전처리에 의존적)
- DB서버로 많이 사용됨
30. 보너스. 네트워크가 어떻게 생겼지?
30
Cisco Router
- 데이터 패킷을 전송해준다.
- 인터넷의 실체(?)
L4 Switch
- 특정 ip에만 데이터 전송
Eathernet Hub
- 연결된 곳에 모두 데이터 전송
Redis Server #1 Redis Server #2 Redis Server #3
Router
Router
Router
Router
Internet
- Router와 회선을 타고 형성된 가상의 네트워크