EMOCON 2017 S/S - 마음이 편해지는 글로벌 인프라 만들기
•Download as PPTX, PDF•
1 like•408 views
서비스가 안정적으로 운영되기 위해서는 유연한 인프라의 구성이 필수입니다. AWS 를 비롯한 Public Cloud 를 통한 인프라 구성이 일반화 되면서 많은 고민을 덜어주고 있지만, 실사용자의 관점에서라기 보다는 서비스를 운영하는 입장인 경우가 많습니다. 실사용자들의 성능과 경험을 높여주면서 운영하는 사람들의 노고를 덜어주어 보다 서비스에 집중할 수 있게 해주는 방법이 없을까요?
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (15)
Similar to EMOCON 2017 S/S - 마음이 편해지는 글로벌 인프라 만들기
Similar to EMOCON 2017 S/S - 마음이 편해지는 글로벌 인프라 만들기 (20)
EMOCON 2017 S/S - 마음이 편해지는 글로벌 인프라 만들기
- 1. 마음이 편해지는 글로벌 서비스 인프라 만들기 @nopd
- 2. 꿈 혹은 고민 진화 크게 그리고 작게 그럼에도 불구하고... 몰입 오늘부터 우리는!
- 3. 꿈 혹은 고민
- 4. 꿈의 나라, 환상의 세계로... 여기는... 0 200 400 600 800 1,000 1,200 1,400 1,600 1,800 2,000 Some Data...
- 5. 그곳으로 가는 길, 전에 없던 험난한 여정! Service Resume w/Big Update Normal Traffic Service Suspend Normal Traffic On-Going Patch Deploy 0.0 100.0 200.0 300.0 400.0 500.0 600.0 700.0 Bandwidth (Throughput)
- 6. 기대와 현실
- 7. 진화 - 크게, 더 크게
- 8. 서비스 인프라의 탄생과 성장 WEB WAS DB
- 9. 서비스 인프라의 탄생과 성장 WEB WAS DB
- 10. 서비스 인프라의 탄생과 성장 WEB WAS DB ? ? ? STORAGE?
- 11. 서비스 인프라의 탄생과 성장 WEB WAS DB ? ? ? STORAGE? On Premise (Legacy) Private Cloud
- 12. 서비스 인프라의 탄생과 성장 WEB WAS DB ? ? ? STORAGE? On Premise (Legacy)Public Cloud
- 13. 서비스 인프라의 탄생과 성장 WEB WAS DB ? ? ? STORAGE? On Premise (Legacy)Public Cloud Private Cloud
- 14. 서비스 인프라의 탄생과 성장 Public Cloud
- 15. 진화 - 작게, 더 작게
- 16. 비용 효율적이고 유연한 구조 - 인프라의 컴포넌트화 …… …… Public Cloud
- 17. 비용 효율적이고 유연한 구조 - 인프라의 컴포넌트화 …… …… Public Cloud
- 18. 그럼에도 불구하고...
- 19. 생각의 전환 - 인프라 중심에서 사용자 중심으로...
- 20. 오늘부터 우리는!
- 23. 분산 원본 구조를 가지고 있다면...
- 24. 분산 원본 구조를 가지고 있다면...
- 25. 사용자의 체감 성능을 높이려면...
- 26. 사용자의 체감 성능을 높이려면... 분산 캐시 플랫폼
- 27. 몰입에 관하여...
Editor's Notes
- 모두는 꿈을 꿉니다. 그리고 동시에 고민을 합니다. 꿈을 꾸고 고민을 하는 것은 개인의 자유영역이긴 하지만 피할 수 없는 것이라면 어떻게 현명하게 대처할 수 있을지 생각해 봐야합니다. 서비스가 성장함에 따라 인프라도 같이 진화를 합니다. 때로는 점점 더 커지기도 하고, 세상이 변화하면서 다시 또 작은 형태의 요소들로 대치되기도 합니다. 마치 생물처럼 말이죠. 신의 영역에 다가가고 있는 훌륭한 엔지니어들 덕분에 코드와 인프라는 유기적으로 짝을 이루어 효율성을 높여 가지만 여전히 숙제는 남아 있습니다. 그래서 우리는, 이 세션을 듣고 있는 우리는, 오늘부터 새로운 관점에서 생각을 하기 시작할 겁니다. 그럼으로써 정말로 사용자들이 우리 서비스를 즐길 수 있게 해주는 서비스의 개발, 코드의 개발에 집중 해보고자 합니다
- 난, 난 꿈이 있어요... 그 꿈을 믿어요... 나를 지켜... 봐요...
- 모험과 신비가 가득한 나라. 우리가 꿈꾸던 그 곳. 꿈의 나라, 환상의 세계로, 여기는 음~음~월드. 누구나 한번쯤 꿈꾸어 보는 것. 내가 만든 서비스가 사람들에게 사랑받고 지속적으로 성장하는 것이죠. 그 뒤에 따라올수도 있고, 그렇지 않을수도 있는 금전적인 보상도 무시할 수 없는 중요한 요소일 수 밖에 없습니다. 혹시 이 차트가 어떤 차트인지 아시겠어요...? 어렵지 않습니다. 여러분들이 매일매일 이 회사를 위해서 서비스를 열심히 사용하고 계십니다. 네, 바로 페이스북입니다. 세계 3대 인구 대국이었던 페이스북은 어느새 유일무이한 최대 인구 보유 국가가 되고 말았죠. 서두에 이야기 했던 “꿈”의 롤모델을 꼽으라면, 주저 없이 페이스북을 꼽는 분들이 많을 수 밖에 없는 이유를 이 그래프가 보여주고 있습니다 페이스북과 같은 전지구 규모의 서비스를 만드는 것은 굉장히 어렵습니다. 서비스가 제공하는 가치가 사용자들이 기꺼이 지갑을 열도록 하거나, 지갑을 연지도 몰랐는데 돈이 빠져나가고 있는 놀라운 경험을 하게 해줘야 하는 것은 기본이고 매력적이고 흥미진진한 컨텐츠들이 지체 없이 사용자들의 눈앞에 펼쳐져야 한다는 기본 명제가 지켜져야 하기 때문입니다.
- 화면 가운데 쯤에 보이는 삐죽 솟은 바늘은 무얼 의미하는 걸까요? 그래프의 세로축을 나타내는 숫자의 단위는 무엇이고 지렁이처럼 바닥에 꾸물거리던 그래프는 왜 어느순간 하늘로 치솟았던 것일까요? 가로축을 시간의 순서에 따라 잘라보겠습니다. 패턴을 가지고 있는 그래프의 파편들은 각각 서비스의 상태와 깊은 연관이 있습니다. 대부분의 “우리가” 월요일 아침부터 금요일 저녁 시간까지 시간을 보내는 것처럼 Normal Traffic 영역은 왠지 평온합니다. 이윽고 개구리가 멀리 뛰기 위해 몸을 움츠리듯, 서비스는 점검 공지와 함께 잠시 침묵을 유지합니다. 긴 밤이 지나고 여명이 밝아오면, 서비스 점검 메세지는 사라지고 월드워Z의 좀비들처럼 트레픽이 순식간에 산을 만들며 몰려듭니다. 이내 트레픽은 급격이 떨어지지만 늦으막히 서비스에 접근하는 사용자들을 위해 한동안 정성껏 리소스를 제공해야만 합니다 폭풍이 지나가면 언제 그랬냐는 듯 트레픽은 평온을 되찾고 간헐적인 패치와 업데이트가 사용자들을 사로잡기 위해 애를 씁니다. 이 차트의 가장 긴 바늘이 기록한 트래픽은 700Gbps 에 근접합니다. 이 트레픽을 감당하기 위해서 필요한 비용은 얼마나 될까요? 근래 회선 단가를 찾아보진 않았지만, 여러분의 상상을 초월하는 놀라운 비용이 소요될 겁니다 비용을 차치하더라도 이정도 규모의 요청을 소화할 수 있는 인프라를 만들고 구성하는 것도 만만치 않은 일이 될 수 밖에 없습니다. 하지만 이런 사용자들의 요청을 감당하지 못하면 서비스는 시장에 안착하기 힘들 수 밖에 없습니다. 유저들은 생각보다 매정하고 경쟁자들은 상상 이상으로 강하기 때문입니다.
- 서비스의 성공을 방해하기 위해 도사리는 방해꾼은 이 뿐만이 아닙니다. 새로운 서비스를 기획할 때는 빼놓을 수 없는 것이 시장 분석입니다. 아무리 글로벌 시대라 하더라도 지역별로 사람들의 선호도가 있고 지역 시장에서의 성공 방정식이 존재합니다. 서비스는 그런 지역적 특성에 맞게 기획되고 개발되어야 하고, 서비스를 위한 기반 인프라 역시 같은 맥락에서 준비되어야 합니다 그런데 고심끝에 만든 서비스를 오픈했을 때, 늘 준비된 내용과 예측했던 내용에 따라 사용자들이 인입되고 서비스의 성패가 결정되는 것은 아닙니다. 전혀 기대하지 않던 지역에서 뜨거운 인기를 얻기도 하고, 반대로 “못해도 중박!”을 예견하며 믿고 있던곳에서 안좋은 반응을 얻을 수도 있습니다. 타겟 시장에 맞춘 사이징과 인프라 준비가 되지 못했을 때 사용자들은 서비스에 쉽게 등을 돌릴 수 있습니다. 현지화나 서비스의 퀄리티는 물론이고 사용자와 인프라간의 지리적, 물리적 거리로 인해 발생하는 많은 문제들이 상존합니다. 그나마 예전보다 훨씬 쉽고 빠르게 인프라에 대한 복제와 조정을 할 수 있는 시대가 되긴 했지만 빠르게 시장 상황에 맞추어 변경을 진행하는 것은 상당히 큰 위험부담을 가질 수 밖에 없는게 현실입니다.
- 서비스가 가진 기능이 많아지고 사용자들이 증가하면 가장 먼저 하는 것은 인프라를 늘리는 일입니다. 몇 개 안되던 서버들이 수십대, 수백대가 되기도 하고 일당백으로 혼자서 감당하던 인프라 관리 업무도 팀 편제를 통해 수행하게 됩니다. 크게, 그리고 더 크게... 인프라는 늘어만 갑니다.
- 태초에 서버가 있었습니다. 아직 얼마나 많은 일을 해야 할지 잘 모르는 서버는 모든 일을 혼자 도맡아 하겠다는 의지를 보여주었습니다. 무슨일을 하게 될지 모른채 태어난 서버는 사람이 하라는 일을 싫다는 소리 한번 하지 않고 수행했습니다. HTML 과 CSS, 그리고 Javascript 로 점철된 정적인 웹 페이지는 물론이고 무언가 복잡하게 만들어져 CPU 를 괴롭히는 동적인 페이지와 디스크 잡아먹는 귀신 같은 데이터베이스 데몬까지 모두 품에 안고 일을 했습니다. 왠지 불안한 동거 같은 느낌이었지만 서버는 묵묵히 자신의 일을 했습니다. 무슨 문제라도 생기면 어쩌지 하는 불안감이 있었지만 실제로 발생한 문제는 없었습니다. 훌륭한 개발자들이 코드를 잘 만들어 준 덕분이기도 했지만 서비스를 사용하는 유저가 없다는 것이 더 큰 이유였습니다. 사용자가 있어야 문제가 생기는데, 사용자가 없으니 문제가 생길리 만무하겠죠.
- 서비스가 런칭된 이후 사람들로부터 좋은 반응을 얻기 시작하면 다양한 경로를 통해서 사용자들이 인입되기 시작합니다 발품이나 손품을 팔아가며 친구들에게도 홍보하고, 트위터나 페이스북에도 글을 올리실 겁니다. 운이 좋아서 매체나 파워블로거의 눈에 띄었거나 마케팅 용자의 도움으로 앱스토어 피쳐드에 등록되면 폭발적인 사용자 인입이라는 영광스러운 순간도 맞이할 수 있습니다. “사용자들이 증가하기 시작하는데… 우리도 인프라 캐파도 좀 늘리고 이제 레이어도 나눠야 하지 않을까요?” 인프라를 확장하는 가장 기본적인 방법은 역할별로, 혹은 티어별로 나누는 방법일겁니다. 티어별로 나누는 이유는 여러가지가 있겠지만 기본적으로 각 역할별로 필요한 리소스의 규모에 차이가 있기 때문입니다 보안적인 관점에서 볼때도 티어별로 요구되는 수준이 다르다는 것도 한몫 하고 있습니다 어쨌든 우리는 가장 성의 없고 쉬운 방법으로 하드웨어들에게 역할을 부여할 수 있게 되었고 이는 오랫동안 큰 논란 없이 “3-tier 아키텍쳐” 라는 이름으로 불리우고 사용되어 왔습니다.
- 옆으로 비대해지기 시작하는 인프라 “ 스케일 아웃이 시작되면서 비용 효율적인 구조에 대한 고민이 시작된다 ” 이렇게 나뉘어진 각 티어는 서비스의 성장에 따라 수평적인 확장을 시작합니다. 알음알음 이런저런 하드웨어가 엉덩이를 비집고 들어와 자리잡습니다. 인프라의 증가는 관리 포인트의 증가와 이에 따른 인건비의 증가로 이어집니다. 그런데, 막상 들여놓은 장비들이 탱자탱자 놀고 있는 상황이 발생하는 경우가 빈번합니다. 비싸게 들여놓은 장비들이 놀고 있는 모습을 보면 마음이 아프면서 동시에 싸한 기분을 느끼게 됩니다. “내가 이만큼 사야 한다고 이야기 했는데...” “다음에 새로 서버 품의 할때는 얼마나 사야 한다고 하지...” “노는 서버 관리하려고 사람을 더 뽑아야 하나...” “상면과 전기세는 또 어떻하지...” 서비스에 요구되는 성능과 리소스의 규모를 산정하고 정확한 계량을 하는 것은 어려울 수 밖에 없습니다. 특히 불특정한 다수를 상대로 하는 서비스라면 더욱 예측하기 힘듭니다.
- 인프라 담당자는 당면한 어려움을 해소하기 위하여 가상화에 눈독을 들이기 시작합니다. 주변 지인들을 통해 VMware 기반이 좋을지, MS 플랫폼이 좋을지 조언도 듣고 여기에서 조금 더 나아가 컨테이너 기술들에 대해서도 이런저런 검토를 하게 됩니다. ”사장님, 이제 가상화를 통해 인프라의 효율성을 극대화해야 합니다.” “컨테이너 기술이라고 들어보셨나요? 요즘 좀 날고 긴다는 회사들은 도커를 활용하여 유연함과 비용 두마리의 토끼를 잡는다고 합니다” 사장님은 왠지 속는 것 같은 기분에 찜찜함을 떨치기 힘들지만 과하게 투자된 물리적인 인프라를 한번 바라보고는 곧 승인을 해줍니다. 이제 가상화 기술의 도움으로 Private Cloud 를 도입하여 스케일링에 대한 고민을 어느정도 해소할 수 있게 되었습니다. 하지만 인프라 중에서도 가장 물리적인 속성을 가지고 있는 스토리지는 여전히 비용 효율적이지 못하고 인프라 관리 관점에서의 어느정도 효율화는 이루었지만 서비스에 접근하는 사용자 입장에서의 성능은 여전히 미궁입니다.
- 서비스에 따라서는 Private Cloud 가 아닌 Public Cloud 를 먼저 도입하게 되는 경우도 있을 수 있습니다. 규모가 큰 엔터프라이즈로 일수록 보수적인 성향을 띄기 때문에 Private Cloud 를 선호하지만 스타트업이나 작은 규모의 기업이면 Public Cloud 를 먼저 검토하는 경우가 많습니다. 특히, 해외에서의 사용자 유입이 많은 서비스라면 더더욱 핵심 지역에 팝을 가지고 있는 Public Cloud 를 선택하는 것이 합리적입니다. 예전이었다면 현지 IDC 를 통해 Co-location 이나 호스팅을 통한 “전진배치” 컨셉을 이용했겠지만 이제는 아마존 AWS나 마이크로소프트 애져와 같은 클라우드 서비스를 통한 “유연한 전진배치”가 대세가 된지 오래입니다. 얼마전 새롭게 리마스터되어 재출시된 스타크래프트 소식 다들 들어보셨을 겁니다. 스타크래프트의 기본적인 전략 중 하나가 본진 근방에 위치한 앞마당 확장입니다. 물론 스타크래프트에서의 앞마당 전략은 방어선을 확장해 나가는 의미라 서비스 인프라에서의 전진배치와 다소 목적이 다르지만 영역을 확대해 나가고 사용자와 서비스의 접점이 가까워 진다는 측면에서 같은 효과를 갖는다고 볼 수도 있습니다. 다만 스타크래프트에서도 본진에서 먼 곳에 새로운 진지가 생길수록 손놀림이 빨라져야 하고 신경써야 하는 것이 늘어나는 현상을 현실에서도 겪을 수 밖에 없습니다. 그럼에도 불구하고 가까워진 접점은 사용자의 성능을 높여줄 수 있는 중요한 포인트가 되기 때문에 앞마당, 원격지 전진배치 전략은 놓기 힘든 유혹일 수 밖에 없습니다. 이렇듯 Public 과 Private Cloud 는 각기 가지고 있는 장점과 단점이 있고 서비스를 위해 도움이 되는 점이 분명이 있습니다. 그래서 의욕이 넘치는 용자님들은 간혹 무리한 시도를 하기도 합니다.
- 머리가 미어터지기 시작하는 시점 On-Premise + Private Cloud + Public Cloud 스타 Architect 의 도움으로 인류는 기사회생하는 듯했다... 이런 경우는 많지 않겠습니다만, 하드코어한 아키텍트가 입사하면서 “인프라의 모든 것을 아우르겠어!” 를 출사표로 던질수도 있을 겁니다. 마이크로소프트의 애져 스택과 같은 도구를 통해 온 프레미스의 가상화를 도모하면서 퍼블릭 클라우드 서비스를 VPN 커넥터, VPC 구성등을 통해 통치하는 궁극의 인프라 스트럭쳐를 만들 수도 있을겁니다.
- 근래에는 애초부터 단일 인스턴스를 쓰더라도 퍼블릭 클라우드를 이용하는 경우가 상당히 많습니다. 쉽게 배포할 수 있고 유연하게 쓸 수 있다는 장점에 각종 프로모션, 왠지 써야만 할 것 같아서 쓴다 등 이유도 여러가지 입니다 하지만 퍼블릭 클라우드를 적극 사용한다는 것이 주는 궁극적인 메리트는 따로 있습니다. ”서비스 요소들을 관리 가능하고 스케일러블 하게 만들 수 있는 작은 단위로 쪼개는 것” 인프라는 아이를 키우는 것과 같습니다. 아이가 자라면서 몸이 커지면 크기에 맞는 옷을 사줘야 합니다. 누워만 있던 아기가 기어다니기 시작하고 걸어다니기 시작하면 그에 맞는 용품들을 준비해야 합니다. 너무 마르면 살을 찌우고 건강해질 수 있게 도와주고, 뚱뚱해지면 다이어트를 할 수 있도록 식단을 조절해 주기도 해야 합니다. 비대해진 인프라를 다이어트 시키고 유연하게 만들어 관리와 비용의 측면에서 효율성을 도모하는 것은 성장하는 서비스들이 꼭 거쳐야 하는 전공필수입니다. 마찬가지로 인프라의 세계에서도 “다이어트”와 “건강”에 대한 관심이 생기기 시작했습니다. 크게만 키우면 되는 줄 알았는데 그게 아니었던 것이죠.
- 초기 클라우드가 촛점을 맞추고 있던 영역은 스케일 이었습니다. 물리적인 인프라, 레가시 인프라를 가상화라는 레이어를 통해 추상화 할 수 있었고 이를 기반으로 오토스케일링(Auto-Scaling)과 같은 기술들이 사람들의 뜨거운 호응을 얻었습니다. 스케일 아웃, 스케일 인, 스케일 업, 스케일 다운은 물리적인 인프라의 한계를 뛰어 넘게 해주는 훌륭한 솔루션이었습니다. 하지만 근래에 가속화되고 있는 클라우드의 단위는 물리, 레가시 시스템을 단순히 가상화 하는 것을 넘어서고 있습니다. 처음 단일 서버, 단일 인스턴스에서 여러 레이어의 시스템으로 분화하여 비용, 관리의 효율성을 도모했다고 앞서 말씀드렸습니다. 같은 관점에서 이제 각 레이어의 시스템을 구성하고 있는 컴포넌트로 눈을 돌리기 시작했습니다. 여기서 컴포넌트는 쉽게 생각하면 “기능”을 수행하는 단위 정도라고 해석해도 무방합니다. 서버나 인스턴스를 자세히 살펴보면 여러가지 컴포넌트가 존재하고 각 컴포넌트별로 요구되는 리소스의 규모가 다를 수 밖에 없습니다 주요 퍼블릭 클라우드 사업자들이 근래 집중적으로 출시하고 있는 제품이나 서비스들은 기능 컴포넌트에 촛점이 맞추어져 있고 보다 세밀한 단위에서 스케일링 하고 관리 할 수 있는 방법론을 제시하고 있습니다
- 그렇다면 컴포넌트 레벨의 가상화, 스케일링에 대한 전략만으로 충분할까요? 인프라를 만들고 운영하는 입장에서는 충분할지 모르겠습니다. 하지만, 이러한 클라우드 서비스, 클라우드 플랫폼의 구조는 두가지 태생적인 한계를 가지고 있습니다. 하나는 Pop 중심의 사일로(Silo) 구조를 기본으로 하고 있다는 점이고 / 다른 하나는 이러한 인프라 구성이 모든 사용자를 위한 최적의 선택은 아닐 수 있다는 점입니다 오토스케일링이나 리전내 Failover 구조를 만들면서 사일로 구조를 가지고 있다는 것의 한계? 제약사항을 느끼신 분들이 많을 겁니다. 물론 컴포넌트나 가상머신들 사이에 발생할 수 있는 레이턴시(Latency)를 생각하면 사일로가 좋은 선택이긴 합니다. 다만 확장성의 관점에서 생각해 볼 때 발생하는 제약들의 기저에 사일로 구조가 있다는 사실은 명확합니다. 아마존을 기준으로 봤을때 리전과 엣지 로케이션이 별도로 구분되어 관리되는 것도 이와 연관이 있는 부분입니다. 리전에 배포되는 서비스, 제품과 엣지 로케이션에 배포되는 서비스, 제품에는 명확히 구분되는 기준이 있습니다 모든 사용자를 위한 최적의 선택이 아닐 수 있다는 것은 사용자들의 다양한 네트워크 환경과 관계가 있습니다. 클라우드 사업자들은 특정한 지역에 리전 계획을 수립하면서 현지 ISP 들의 마켓쉐어를 비롯하여 네트워크 환경을 고려하여 가용성 존을 구성합니다. 가용성 존의 구성 정책은 플랫폼의 failover 계획과도 관계가 있지만 ISP 들간의 관계로 인한 성능 관점의 고민도 포함될 수 밖에 없습니다. 트레픽이 망내인지, 망외인지에 따라 Cost 가 변화될 수 있고 회선 Bandwidth 의 문제나 성능의 이슈도 발생할 수 밖에 없습니다. 스케일링의 한계 지역적인 한계 극복의 어려움 : Pop vs. 분산네트워크 사용자의 체감 성능 향상의 한계 : Last Mile 유연함 != 사용자 체감 성능의 향상 >>>>>>>>>>> 사용자 관점에서 인프라를 다시 생각해보자 지금까지의 모든 이야기들이 “우리 서비스 인프라” 관점이었다면 이제 “사용자 경험”으로 관점을 바꿀 필요가 있습니다
- 열심히 준비한 인프라가 사용자들의 요청을 ”우수한 성능으로” 소화할 수 없다면 우리는 아직 소기의 목적을 달성하지 못한 겁니다. 그래서 우리는, 다시 사용자의 관점에서 성능을 보장할 수 있는 방법에 대해서 고민을 해야만 합니다. 인프라, 서비스 컴포넌트의 유연함을 극대화 하면서 실제 엔드 유저들의 만족도를 높이는 연결고리는 어떻게 만들어야 할까요?
- 뉴욕시의 급수 시스템을 살펴보면, 멀리 있는 수원지에서부터 도심까지 물길을 만들어 주는 대규모의 관수시설이 있고 실제 시민들이 언제나 콸콸콸 쏟아지는 물을 사용할 수 있도록 해주는 물탱크들이 도심 건물 곳곳에 위치하고 있습니다. 이 급수 시스템이 이야기 하는 것은 “가능한 사용자 근처에서 서비스를 해야 한다”는 보편적인 진리입니다. Pop 혹은 사일로는 도심에서 멀리 떨어진 저수지, 취수원이라 할 수 있고, 급수탑. 물탱크는 분산네트워크라 생각하면 틀리지 않습니다. 그런데 인터넷에서 분산네트워크는 급수 체계에서의 급수탑, 물탱크보다 더 중요한 의미를 갖습니다. 몇 가지 이유들을 들어보면, 인터넷의 불합리성 : 애초에 성능을 고려한 네트워크가 아님 사용자 환경의 다양성 : 수많은 ISP, Network 와 지역적인 성숙도 누구를 위한 앞마당인가 : 리전 - 서비스 제공자를 위한 앞마당, 분산네트워크 - 사용자를 위한 앞마당 소위 Last Mile 이라 부르는 영역에서의 성능 개선이 있어야 사용자들은 “이 서비스 정말 좋군!” 이라는 이야기를 하게 됩니다. 웹 퍼포먼스 최적화에 대한 많은 자료들을 살펴보면 파레토의 법칙처럼 80:20 룰을 이야기 하고 있습니다. Front End 에서의 개선이 전체 성능에 미치는 영향이 80 이라면 Back End 에서의 개선이 전체 성능에 미치는 영향은 “고작” 20 이라고 합니다. 즉, 묻지도 따지지도 말고 사용자들에게 앞마당을 제공함으로써 사용자 체감 성능의 향상을 이끌어 내야만 하는 것입니다.
- 지금까지의 모든 이야기들이 “우리 서비스 인프라” 관점이었다면 이제 “사용자 경험”으로 관점을 바꿀 필요가 있습니다 이미 알고 계신 분들도 있겠지만, 모르고 계셨다면 오늘부터라도 “사용자 경험”으로 인프라의 관점을 바꿔야 합니다.
- 소규모 인프라를 운영하는 경우 분산네트워크 구조의 캐시 인프라를 통해 크게 두가지 스팀팩의 효과를 얻을 수 있습니다. 첫번째는 레이턴시의 감소입니다. 수많은 사용자들이 원본 인프라까지 진입하는 경로는 물리적/논리적인 거리로 인한 레이턴시가 발생합니다. 분산네트워크를 통해 이러한 레이턴시를 줄일 수 있습니다. 다른 하나는 분산네트워크상의 서버들을 통해 원본이 소화해야 하는 부하를 분산킬 수 있습니다. 원본이 아주 스케일러블하게 구성되지 못했다 하더라도 상당히 높은 부하도 서비스가 소화할 수 있게 되는 것이죠. 우리가 흔히 캐시를 생각할 때 놓치는 것이 동적인 컨텐츠에 대한 캐시입니다. 정적인 컨텐츠는 물론이고 동적인 컨텐츠들 역시 캐시의 대상으로 포함시키는 것의 효과는 생각보다 대단합니다. 물론 주식 거래와 같은 서비스에서 동적인 컨텐츠 캐시는 이슈가 될 수 있지만 왠만한 서비스의 동적 컨텐츠는 캐시에 포함해도 큰 문제가 없습니다. 단 1초의 캐시 TTL 만으로도 소규모 인프라는 박지성처럼 달릴 수 있는 심장을 갖게됩니다. 사용자 앞마당에서 컨텐츠를 가져갈 수 있기 때문에 서비스 중단의 불확실성으로부터 벗어나고 낮은 레이턴시를 보장 받는 것도 가능해 집니다. 분산네트워크를 이용함으로써 원본 인프라를 사용자 요청 규모에 맞추어 스케일링 하지 않아도 되며 사용자 관점에서의 성능 개선을 취할 수 있기 때문에 일석이조가 될 수 있습니다. 혹시 있을지 모르는 악의적인 사용자들의 분산서비스공격에 대한 체력 강화는 부수적으로 얻을 수 있는 잇점입니다. 작은 인프라 구조라면 Cache Infra 를 통한 Capacity 증설의 효과를 보안 관점에서도 최고~! 단순한 소규모 인프라 구조를 충분히 커버해 줄 수 있는 아카마이의 22만대 서버들. 1초 혹은 0초의 TTL 값의 설정 만으로도 얻을 수 있는 잇점은 정말 많습니다. 전세계 20만대 이상의 서버를 내 인프라처럼! 계층형 캐시 구조를 통한 과도한 부하 경감 컨텐츠 특성에 맞는 네트워크 제공 원본 인프라 보호를 위한 Cloaking 제공 클라우드 스토리지를 이용한 부하 분산
- 컴퓨터의 두뇌인 CPU 의 성능을 결정짓는 요소는 여러가지가 있습니다. CPU 에 집적된 트랜지스터의 수에서부터 동작하는 클럭 주파수, 그리고 CPU 에 병합되어 있는 캐시 메모리의 크기가 대표적입니다. 분산네트워크에서도 이와 비슷한 컨셉으로 계층형 캐시 구조를 도입할 수 있습니다. 계층형 캐시 구조의 도입을 통해 얻을 수 있는 효과들이 몇가지 있습니다. Self DDoS 의 지양 : 분산네트워크가 너무 크고 전세게에서 요청들이 골고루 발생한다면 소규모 원본 인프라에게는 부담이 될 수 있습니다 사용자 체감 성능의 추가적인 향상 : 컨텐츠를 찾으러 원본까지 오는 횟수를 줄일 수 있습니다 / 에베레스트 원정대, 베이스캠프 Keep-Alive 를 활용한 성능의 최적화 : TCP 세션을 만드는데 발생하는 오버헤드마저 줄여버릴 수 있습니다. / http 표준은 생각보다 활용하기 좋은 기능들이 많이 정의되어 있음 계층형 캐시 구조의 도입 Self DDoS 는 하지 말아야... Self DDoS 를 지양하기 위한 대표적인 기술 Connection: Keep-Alive / Keep-Alive: 단순한 소규모 인프라 구조를 충분히 커버해 줄 수 있는 아카마이의 22만대 서버들. 1초 혹은 0초의 TTL 값의 설정 만으로도 얻을 수 있는 잇점은 정말 많습니다. 전세계 20만대 이상의 서버를 내 인프라처럼! 계층형 캐시 구조를 통한 과도한 부하 경감 컨텐츠 특성에 맞는 네트워크 제공 원본 인프라 보호를 위한 Cloaking 제공 클라우드 스토리지를 이용한 부하 분산
- 여러 리전에 분산되어 failover 와 스케일링에 대한 준비가 되어 있는 인프라 구조에서도 분산 네트워크는 효과를 발휘할 수 있습니다. 지역별로 사용자들을 구분할 필요가 있을 경우 분산네트워크상의 캐시 서버들이 사용자 프로파일링을 통해 적절한 원본 리전을 이용하도록 할 수 있습니다 특정한 리전의 리소스가 지나친 부하를 받는 경우, 구성된 인프라의 규모를 감안하여 애초에 인입되는 사용자 요청을 적절히 여러 리전으로 분산시킬 수도 있습니다 당연하겠습니다만 어떤 리전에 문제가 생겨 서비스가 불가한 경우에도 지구 반대편에 위치한 살아 있는 리전을 사용할 수 있도록 트레픽을 라우팅 하는 것도 가능합니다. 프락시 서버들이 애초에 가지고 있는 의무의 연장선상에서 분산네트워크는 대규모의 프락시 서버 군집으로서 동작하게 되기 때문입니다. 보다 효과적으로 분산 원본 구조를 활용하려면... Failover, 성능에 대한 고려... 전세계 여러 리전을 통해 다양한 서비스 인프라를 배치해 놓고 있는 상황. 어떻게 이런 인프라들을 보다 효과적으로 활용할 수 있도록 할 것인지에 대한 고민이 당연히 있을 수 밖에 없음. 하지만, 클라우드 플랫폼의 레벨에서 글로벌 자원을 효과적으로 활용하는 것은 사실 쉽지 않음. 싸일로(Silo) 혹은 팝(Pop)을 벗어날 수 없는 현실적인 이슈. 이런 상황에서 가장 효과적으로 각 리전들을 활용할 수 있게 해주는 것이 아카마이 플랫폼. 22만대의 엣지들이 사용자의 지역을 기반으로 한 분기처리를 할 수도 있고, 각 리전의 부하수준을 동적으로 체크하여 리소스에 여유가 있는 쪽으로 더 많은 사용자 트레픽을 라우팅 해주는 동적인 부하 분산 모델도 쉽게 구현할 수 있음. 지역별 비즈니스 요구사항에 기반한 트레픽 로드 밸런싱 리전별 성능 측정 결과를 이용한 동적인 부하 분산 모델 헬스 체크 / 응답 코드 등에 기반한 트레픽 라우팅
- ( 리전들을 유기적으로 활용하는 그림으로 애니메이션 )
- 우리가 서비스를 만들고 서비스를 위한 효과적인 인프라를 만드는 이유는 무엇일까요? 점점 고려할게 많아지고 복잡해지는 인프라의 세계에서 우리는 무엇을 생각해야 하고 어떤 것에 무게 중심을 두어야 하는 걸까요? 필요에 따라 원본 인프라를 다양한 최신 기술과 제품을 이용하여 만드는 것은 중요한 일입니다. 그렇지만 예측할 수 없는 사용자들의 사용 패턴, 시장 상황, 악의적인 공격자들에 의한 변수의 발생도 고려해야 합니다. 안타깝게도 이 모든 것을 완벽하게 소화하는 것은 사실 쉬운일이 아닙니다 초사이어인 같은 인프라 아키텍트가 설계를 하더라도 결국 극복하기 어려운 문제들이 발생하기 때문입니다. 페이스북을 비롯한 세계적인 기업들의 엔지니어링 블로그를 살펴보면 그들이 닥친 문제와 그것들을 어떻게 해결했는지를 잘 정리해서 올려두고 있습니다. 그들조차도 문제에 부딪히고 고민을 하고 해결방법을 계속 찾아나가고 있는 것이지요. 그런데 그들의 이야기를 가만히 들어보면 모든 것이 사용자들 입장에서의 이야기를 하고 있다는 것을 알 수 있습니다. 그래서 이제는 관점을 바꾸어 보았으면 좋겠습니다. 많은 성공한 인터넷 서비스 기업들이 가고 있는 길은 분명 이유가 있습니다. 빠르게 서비스를 런칭하고 사용자들에게 만족스러운 피드백을 받기 위해서 너무 심각하게 고민하고 세밀하게 인프라를 설계하는 것도 좋은 접근이지만 분산네트워크, 분산 캐시 플랫폼을 적극적으로 활용하여 마음 편안하게 서비스 인프라를 만들어 보면 어떨까요
- 우리의 진짜 고민은 “가치 있는 서비스를 만들고 사용자가 만족을 느낄 수 있게 하는 것” 입니다. 분산 캐시 플랫폼, 분산 네트워크는 그 고민에만 집중할 수 있도록 해주는 훌륭한 조력자가 될 수 있습니다.
- 시장은 무척 치열합니다. 오늘 혁신적인 서비스라고 일컫어 지는 것도 내일이면 카피캣이 등장할 수 있고 경쟁 사업자들이 금새 뒤따라오곤 합니다. 기술적으로 쉽게 따라오기 힘든 연구가 필요하다거나 특허로 보호받고 있는 무언가를 가지고 있는 것이 아니라면 추격자들을 따돌리기 위해 혹은 스스로가 추격자가 되어 시장을 차지하기 위한 싸움을 계속 할 수 밖에 없습니다. 우리가 클라우드 서비스를 이용하면서 스케일링과 자동화에 열광했던 것은 그것이 서비스에 보다 집중할 수 있게 해주었기 때문입니다. 마찬가지로 분산네트워크는, 클라우드 환경에서 혹은 클라우드가 아닌 환경에서, 극한의 유연한 Capacity 와 사용자 체감 성능 향상을 제공해 줄 수 있기 때문에 정말로 서비스를 만을 만들고 개발하면서 사용자들을 위한 생각을 하는데에만 몰입할 수 있게 해줄 것입니다.