게임을 위한 다운로드 전송 최적화 | akamai...전송 최적화 수준을 평가하면...

2게임을 위한 다운로드 전송 최적화

개요

하나의 CDN을 사용할 때도 멀티 CDN 전략을 추구할 때에도 글로벌 트래픽을 파악하고

캐시 맵을 분석하는 일은 매우 중요합니다. 전송 최적화 수준을 평가하면 CDN의 성능을

최대화할 수 있습니다. 이 백서에서는 다운로드 전송의 모범 사례, 디폴트 값을 수정하는

타임아웃에 대한 세부 정보, 정기적인 새로운 릴리즈를 지원하는 방법, 페어런트 캐싱 범위를

개선하는 방법 등을 확인할 수 있습니다.

서론

게임업계는 새로운 릴리즈와 함께 매년 지속적으로 성장하고 있습니다. 동시에 최종 사용자

트래픽이 증가하면서 이에 대한 지원이 필요합니다. 결국 게이머들이 기대하는 우수한

성능과 높은 가용성을 구현하려면 고품질 포맷의 대용량 파일을 다운로드해야 합니다.

가용성과 성능은 OTA, 모바일 등 사용하는 디바이스와 네트워크에 상관없이 동일하게

중요합니다. Akamai는 관심이 집중되는 새로운 릴리즈, 소프트웨어 패치, 정기적 릴리즈에

대해 퍼블리싱 전략 최적화, 클라이언트 프로토콜 업그레이드, 캐싱 최적화(매핑 및 캐싱

범위 개선)를 통해 전송 성능을 개선할 수 있습니다. 또한 단일 CDN 또는 멀티 CDN 전략을

개발해 트래픽이 폭증하는 다운로드 이벤트 동안 가용성을 높게 유지하고 장애복구 기능을

원활하게 제공할 수 있습니다. 이 백서에서 논의할 내용은 다운로드 최적화에 대한 모범

사례와 접근 방식입니다.


목차

개요 2

서론 2

콘텐츠 퍼블리싱 4

패키징 4

버전 관리와 TTL 4

클라이언트 개선 사항 5

HTTP/2 5

QUIC(Quick UDP Internet Connection) 5

캐싱 최적화 7

용량 및 매핑 7

부분 오브젝트 캐싱 8

전송 최적화 9

TCP 최적화 9

프리페칭 10

고가용성 및 장애 복구 10

프리워밍/트래픽 폭주 11

장애 복구 환경 최적화 11

멀티 CDN 전략 13

지표 추적 13

결론 14

저자 약력 15


콘텐츠 퍼블리싱

Akamai는 전송 최적화를 위한 노력의 일환으로 먼저 전송 및 패키징 전략을 통해 콘텐츠

자체에 집중하고 있습니다. 동시에 캐싱 가능성을 높이기 위해 URL별 퍼블리싱에

주력합니다.

패키징

Akamai는 패키징을 최종 사용자에 대한 콘텐츠 퍼블리싱과 퍼블릭 접속 제공으로

정의합니다. 비디오 스트리밍의 경우 패키징된 콘텐츠를 HLS 또는 DASH를 통해 전송할

수 있고 사전에 세그먼트된 미디어 또는 바이트 범위 요청을 통해 콘텐츠를 가져올 수도

있습니다. 또한 HTTP를 통한 다운로드 전송의 경우 사전에 세그먼트된 미디어나 바이트 범위

요청을 활용하여 콘텐츠를 가져옴으로써 기타 최적화 기능은 물론 프리페칭(Prefetching)

같은 기능을 사용할 수 있습니다. 타임스탬프 기반 세그먼트 네이밍을 대신 사용하는 방식은

캐시에서 다음 세그먼트를 프리페칭할 수 없기 때문에 효과적이지 않습니다. 또한 이런

접근 방식은 FHD, UHD, VR 등 고품질 스트리밍과 롱테일 콘텐츠에 대해 CDN 성능 최적화

가능성을 제한합니다.

게임 분야에서 Akamai는 단일 파일(pkg 같은 포맷 컨테이너)과 개별 파일 세트(2개 이상의

컨테이너로 구성된 게임 SW) 등 여러 패키징 옵션이 있습니다. 개별 파일 세트를 사용할 경우

몇 가지 단점이 있습니다. 진행 중인 변경사항이 전체 패키지에 영향을 끼칠 수 있고 다음

요청을 미리 가져오는 프리페칭 기능이 게임 타이틀의 개별 파일에는 적용이 불가능합니다.

이런 상황에서는 게임 패키지의 개별 파일에 대해 프리페칭과 같은 최적화 기능을 사용할 수

없습니다. 따라서 패키징 방법에 따라 적용 가능한 최적화 기능이 무엇인지 반드시 고려해야

합니다.

버전 관리와 TTLTV 시리즈, 영화, 게임 SW, 디바이스 펌웨어 패치 등 몇몇 사용 사례에서는 버전 관리가

필요합니다. 예를 들어, TV 시리즈는 버전 관리 양식으로 날짜를 사용하는 반면, 게임 SW와

펌웨어 패치는 업데이트의 릴리즈 버전을 사용합니다. 업데이트를 캐싱하기 위해 콘텐츠가

원하는 기간만큼 캐시에 유지될 수 있도록 TTL(Time-to-Live)을 적용할 수 있습니다.

TTL 값은 인기도와 시간에 따라 결정되고 콘텐츠 리포지토리 내의 백엔드 변경 관리도

고려합니다. 백엔드 인프라의 부하를 경감하는 동시에 콘텐츠를 최종 사용자에게 가능한

빨리 전송하려면 7일, 30일, 365일 같이 TTL 값을 길게 설정하는 것이 좋습니다.


새로 출시된 영화, 게임 SW 업데이트 또는 디바이스 펌웨어 업데이트에 잘못되거나 오류가

있는 콘텐츠가 포함된 경우에는 TTL을 길게 사용한다 하더라도 콘텐츠를 신속하게 되돌리고

대체할 수 있어야 합니다. 캐싱 및 빈번한 업데이트가 필요한 경우 캐시에서 오브젝트를

무효화하기 위해 API 또는 인터페이스를 통해 CDN 퍼지(purging) 기능을 사용할 수

있습니다. 콘텐츠 버전을 정확하게 관리하고 콘텐츠를 신속하게 대체하려면 API 퍼지 기능을

사용하고 이 기능을 콘텐츠 퍼블리싱 사이클에 포함시키는 것이 좋습니다.

클라이언트 개선사항

최근에 클라이언트측 다운로드 시간, 전체 연결 시간 등 다양한 성능 관련 지표를 개선하기

위해 HTTP/2, QUIC 같은 여러 프로토콜이 등장했습니다.

HTTP/2

HTTP/2는 이전 HTTP/1.1의 단점을 보완할 목적으로 개발된 최신 TCP+TLS 기반

프로토콜입니다. 멀티플렉싱, 헤더 압축, 리소스 우선순위 지정 등 몇몇 주요 기능은 게임

패키지 또는 소프트웨어 업데이트의 다운로드 시간을 크게 단축합니다. 예를 들어, 헤더

압축은 기본적으로 요청 및 응답 페이로드의 크기를 크게 줄여주기 때문에 전송 시간을

단축할 수 있습니다. HTTP/2의 더 강력한 기능인 멀티플렉싱은 패키지 다운로드에 유용한

리소스 병렬 전송과 함께 연결 재사용을 지원합니다. 현재 Akamai 플랫폼을 기반으로 한

모든 웹 및 미디어 제품에서 HTTP/2를 활성화할 수 있습니다.

QUIC(QUICK UDP INTERNET CONNECTION)

HTTP/2가 여러 측면에서 성능을 개선시키기는 하지만 여전히 TCP 기반의 프로토콜입니다.

따라서, ‘안전한’ 혼잡 제어 알고리즘 등 기존에 알려진 문제를 동반합니다. 최적의 최종

사용자 경험을 위해서는 일관된 처리량이 필요하기 때문에 이로 인해 대용량의 고품질

다운로드에 영향을 미칠 수 있습니다.


어떻게 하면 HTTP/2의 장점을 유지하면서 TCP+TLS 스택의 단점과 제약을 극복할 수

있을까요? 새로운 UDP 기반 프로토콜인 QUIC를 사용하면 가능합니다. QUIC는 TCP와

관련된 여러 성능 제약 문제를 해결하기 위해 설계되었습니다. 이미 잘 알려진 대로 TCP

는 패킷 손실이 탐지될 때 상대적으로 보수적인 혼잡 제어 접근 방식을 적용합니다. 반면에

QUIC는 탐지된 패킷 손실의 결과로 발생할 수 있는 급격한 처리량 감소 문제를 해결합니다.

QUIC는 시작 지연 시간을 줄이기 위해 0-RTT/1-RTT로 설정하는 옵션도 제공합니다. 새

연결이 추가적인 왕복을 없애주고 기존 연결은 동일한 연결을 재사용합니다. 적극적인 혼잡

제어 설정을 함께 적용하면 다운로드 세션 동안 빠른 연결 구축, 안정적인 멀티플렉싱,

일관된 처리량을 기대할 수 있습니다. 트래픽 규모가 큰 사이트의 성능을 개선하는 효과가

입증되면서 QUIC는 표준으로 자리잡고 있습니다. 현재 Akamai 플랫폼을 기반으로 한

일부 미디어 제품에서 사용할 수 있습니다. 자세한 내용은 IAT(Internal Account Team)

에 문의하시기 바랍니다. 대규모로 배포하기 전에 먼저 철저하게 테스트를 진행하는 것을

권장합니다.

SYN

ACKClientHello

ClientKeyExchangeChangeCipherSpec

완료

애플리케이션 데이터

SYN ACK

ServerHello인증서ServerHelloDone

ChangeCipherSpec완료



캐싱 최적화

용량 및 매핑

Akamai Intelligent Platform은 전 세계적으로 최종 사용자와 가까운 위치에 배치된 수많은

서버로 구성됩니다. 이 플랫폼이 인기 있는 콘텐츠를 관측하면 로컬 사본(copy)을 저장하고

다음에 동일한 콘텐츠를 요청하는 사용자에게 해당 사본을 전송합니다. 최종 사용자와 가장

가까운 위치에 있는 서버와 통신이 이뤄지기 때문에 사용자 경험이 최적화되고 개선됩니다.

맵은 특정 지역(region)의 서버 세트입니다. Akamai는 콘텐츠 종류, 최종 사용자의 위치,

오리진 서버의 위치에 따라 최적의 방식으로 트래픽을 전송하는 매핑 프로필을 설정할 수

있습니다.

ClientHello(비어 있음)

ClientHello

ClientHello애플리케이션

데이터


거부SourceAddressTokens인증서



• 새 QUIC 연결의 경우 1RTT • 재연결의 경우 0RTT


오리진 서버의 부하를 분산하기 위해 최적화된 맵을 설정할 뿐만 아니라 Tiered

Distribution(TD·계층형 분산)을 사용할 수 있습니다. TD는 계층을 분리해 적은 수의

엣지 서버를 통해 오리진에 도달하도록 합니다. TD는 오리진과 통신할 수 있는 최적의

페어런트 서버를 선택하기 위해 Akamai의 인텔리전트 매핑을 사용합니다. 오리진의 부하를

추가적으로 분산시키기 위해 캐싱 계층을 추가하는 것입니다. 또한 콘텐츠의 페칭 또는

캐싱을 위해 동일한 서버 세트를 선택할 수 있도록 엣지에서 수신 오브젝트 URL을 '해싱

(hashing)'하여 멀티 계층형 접근 방식을 세밀하게 튜닝할 수 있습니다. 이 방식은 페어런트

서버 전반에 걸쳐 고객사의 캐싱 범위와 네트워크 트래픽을 일관적으로 확장합니다.

부분 오브젝트 캐싱

부분 오브젝트 캐싱은 대형 파일을 작은 청크(chunk)로 분할하며, 이렇게 분할된 오브젝트

청크는 최종 사용자가 요청할 때만 캐싱됩니다. 이 최적화 기능을 통해 오버다운로딩으로

인해 낭비되는 바이트를 최소화할 수 있습니다. 또한, TTL이 만료되었을 때 대형 파일

오브젝트 전체를 재검사하는 것이 아니라 부분 오브젝트 청크만 개별적으로 재검사할 수

있습니다. 콘텐츠 카탈로그가 너무 길면 페어런트 캐시와 오리진 서버로 향하는 재검사

요청이 급증할 수도 있습니다. 결과적으로 AWS S3 같은 써드파티 오리진의 경우 비용이

낭비되고 Netstorage 오리진의 경우 오리진 성능 저하를 초래할 수 있습니다. 이러한

잠재적인 위험 부담을 감안할 때 TTL을 30일, 365일 등 길게 설정하는 것이 중요합니다.

또한, 부분 오브젝트 재검사를 비활성화하면 추가적으로 요청 수를 줄이고 오리진의

부하를 경감할 수 있습니다. 전반적으로 모범 사례와 함께 부분 오브젝트 캐싱을 적용하면

NetStorage의 경우 성능을 개선하고 써드파티 스토리지의 경우 아웃바운드 비용을 절감할

수 있습니다. 아래 그래프는 POC TTL과 재검사 설정을 최적화했을 때 처리량, 지연 시간,

첫 번째 바이트 시간 등 성능이 어떻게 개선되는지 보여줍니다.

600Mbps

500Mbps

400Mbps

300Mbps

200Mbps

100Mbps

0kbps10/24 11/1 11/1 11/15

처리량(평균)

1.0s

800ms

600ms

400ms

200ms

0ms10/24 11/1 11/8 11/15

지연 시간(평균)

40ms

30ms

20ms

10ms

0ms

10/16 10/24 11/1 11/8

전환 시간(평균)


전송 최적화

TCP 최적화

TCP(Transmission Control Protocol)는 인터넷에서 웹사이트를 구성하는 데이터 패킷

(즉, HTTP 요청 또는 응답)의 전송을 보장하고 제어하는 데 사용되는 표준 전송 레이어

프로토콜입니다. 특히, TCP는 소스 및 목적지 시스템 사이의 연결 설정, 패킷 전송률, 패킷

손실 탐지, 복구 알고리즘을 제어합니다. Akamai는 연결 윈도우 최적화, TCP 타임아웃 및

손실 복구 조정, 영구적 연결 사용 극대화, 기타 TCP의 다른 측면 제어를 통해 사이트 성능을

개선할 수 있습니다. 궁극적으로 이런 최적화 기능은 Akamai 엣지 서버와 클라이언트 또는

오리진 서버 사이의 처리량을 극대화합니다.

600Mbps

500Mbps

400Mbps

300Mbps

200Mbps

100Mbps

0kbps10/24 11/1 11/1 11/15

처리량(평균)

1.0s

800ms

600ms

400ms

200ms

0ms10/24 11/1 11/8 11/15

지연 시간(평균)

40ms

30ms

20ms

10ms

0ms

10/16 10/24 11/1 11/8

전환 시간(평균)


프리페칭(PREFETCHING)

프리페칭은 미래에 필요할 것으로 예상되는 콘텐츠를 미리 가져오는 기능입니다. VOD 및

라이브 비디오 스트리밍의 경우, 프리페칭을 사용하여 다음 요청을 가져오고 콘텐츠를 준비

상태로 유지해야 합니다. VOD의 경우 스트림 길이를 알고 있기 때문에 몇몇 세그먼트를

미리 프리페칭할 수 있습니다. 라이브의 경우 1~2개 세그먼트를 미리 프리페칭해야 합니다.

부분 오브젝트 캐싱의 경우 다음 바이트 범위를 미리 프리페칭해야 하고 부분 오브젝트의

크기에 따라 프리페칭 범위가 달라집니다. 순차적 바이트 범위 요청은 성능을 극대화할 수

있습니다. 반면, 비순차적 바이트 범위 요청(바이트 범위 내/외에서 앞뒤로 점핑)은 캐시의

프리페칭된 부분 오브젝트를 낭비할 수 있다는 점에 유의해야 합니다. 콘텐츠를 미리

프리페칭했을 때 효과를 거둘 수 있는 사용 사례는 다음과 같습니다.

• 롱테일 또는 인기도가 낮은 자산, 일반적으로 많이 사용되지 않는 콘텐츠

• 다운로드 세션 내의 일관되지 않은 처리량

• 빠른 시작 및 게임 내 지연 시간

• 짧은 비디오(30초 광고)

• 대형 SW 패키지

고가용성 및 장애 복구

다운로드는 갈수록 규모가 커지고 있습니다. HD 영화의 용량은 10~20GB입니다. 게임

다운로드는 50GB를 초과합니다. 여러 국가에서 제품을 동시에 출시하는 것이 일반화되면서

소비자 분포도 글로벌화되고 있습니다.

현재 소비자들은 콘텐츠가 차질 없이 최대한 빨리 다운로드되기를 기대하고 있습니다.

따라서 이런 다운로드 패턴은 인프라에 큰 부담을 주고 있습니다. 고객의 기대치에

부합하려면 고가용성이 보장되어야 하고 장애가 발생했을 때 보이지 않는 곳에서 빠르게

장애 복구가 이루어져야 합니다.


프리워밍/트래픽 폭주

온라인 게임 분야에서 트래픽 폭주 기간은 충분히 예측 가능합니다. 이 문제를 해결하는

한 가지 방법은 특정 콘텐츠를 신중하게 선택한 엣지 서버에 미리 가져다 놓고 캐시에서

제공되는 콘텐츠를 극대화하는 것입니다. 프리워밍(prewarming)을 적용할 수 있는 적합한

사례는 정기적 소프트웨어 업데이트 또는 게임 릴리즈입니다. Akamai 고객 담당팀은

고객사와 긴밀히 협조하여 트래픽 폭주에 예상되는 기간에 맞춰 네트워크를 준비합니다.

장애 복구 환경 최적화

다운로드 전송 속도 개선에 집중하면서 장애 복구 환경을 최적화할 수 있는 방법을 간과하는

경우가 종종 있습니다. Akamai는 CDN 모델 내에서 CDN과 오리진 사이의 타임아웃, 재시도

(retry) 값 등 다양한 설정을 조정함으로써 보다 안정적인 장애 복구 환경을 최종 사용자에게

제공할 수 있습니다. 오리진의 평균 응답 시간에 따라 타임아웃 값을 설정해야 합니다.

또한, 트래픽이 폭증할 때 오리진을 보호하기 위해 재시도 횟수를 적정하게 설정하는 것이

좋습니다. 콘텐츠 전송을 위해 TD같은 다계층형 접근 방식을 사용하는 경우 요청이 도달한

각 계층별로 타임아웃 값을 설정할 수 있습니다. 이렇게 하면 응답 실패 메세지를 사용자에게

보내기 전에 대체 엣지 서버를 찾을 수 있는 충분한 시간을 확보할 수 있습니다.


앞서 언급한 권장사항을 적용하면 서버가 요청에 응답하는 충분한 시간을 확보할 수 있고

장애가 발생했을 때 에러 응답을 신속하게 보낼 수 있습니다. 만약 에러 응답이 전송되면

어떻게 해야 할까요? 접속 문제가 발생했을 때 원활하게 장애를 복구하려면 2차 오리진에

콘텐츠를 복제해야 합니다. 이를 통해 사용자에게 디폴트 또는 비정보성 오류가 표시되지

않도록 할 수 있습니다. Akamai Netstorage는 장애 복구 시나리오에서 오리진 서버를 대체할

수 있습니다. 예를 들어, 전체 가동 중단 시 유지 보수 페이지를 Netstorage에서 관리할 수

있고 예정된 릴리즈를 위한 정적 백업 파일도 Netstorage에서 관리할 수 있습니다. 보다

복잡한 가용성 및 장애복구 전략이 필요한 경우 멀티 CDN 접근방식을 고려하시기 바랍니다.

기본 페어런트 맵

빠른 재시도 경로

보조 페어런트 맵

엣지 리전

최종 사용자

오리진

페어런트 – 오리진SureRoute 맵


멀티 CDN 전략

가용성 및 장애 복구 계획의 일환으로 많은 고객사들은 멀티 CDN 전략을 추진하고 있습니다.

다음은 Akamai 고객사 중에서 CDN을 인텔리전트하게 선택하고 있는 사례입니다.

• 지역별 성능 고려 - 일반적으로 지리적 위치와 ISP를 고려해 의사 결정을 내리는

방법입니다. 전 세계적으로 CDN 서버의 범위는 다양하고 이에 따라 가용성과 성능

역시 달라집니다.

• 실제 사용자 모니터링 의사 결정 - 고객의 클라이언트가 다운로드 시간, 처리량, 최종

사용자 네트워크, 기타 성능 지표 같은 클라이언트측 데이터를 지속적으로 비콘으로

전송합니다. 이 데이터를 기반으로 클라이언트나 서버는 기존 CDN을 유지할지

아니면 다른 CDN으로 전환할지 결정할 수 있습니다. 이러한 경우에 해당 로직은

일반적으로 클라이언트의 SDK에 임베드됩니다.

지표 추적

콘텐츠 전송도 중요하지만 다양한 KPI를 추적하고 리포팅하는 방법도 고려해야 합니다. 예를

들어, 소프트웨어 다운로드, 게임 다운로드 등 특정 다운로드가 시작되고 완료된 횟수를

추적해야 합니다.

스트리밍의 경우 일반적으로 추적해야 하는 지표는 다음과 같습니다.

• 시작 시간 - 재생/다운로드가 시작될 때까지 최종 사용자가 기다려야 하는 시간을

추적합니다. 인내심이 부족한 사용자는 중간에 이탈하기도 합니다.

• 비트레이트 - 고객사가 멀티 비트레이트 스트림을 전송한다는 가정 하에 최종

사용자가 소비하는 평균 및 중간 품질을 추적하고 측정합니다.

• 세션 유지 시간 - 사용자가 콘텐츠를 시청하는 시간을 추적합니다. 요즘에는 수많은

비디오 콘텐츠가 광고를 통해 수익을 거두고 있습니다.


• 리버퍼링 비율 - 오늘날의 사용자는 다양한 옵션을 갖고 있으며 열악한 경험을 한

사이트는 재방문하지 않습니다. 따라서 이 지표를 추적하고 낮은 수준으로 유지해야

합니다.

• 처리량 - CDN에서 제공되는 처리량을 추적합니다.

• 다운로드 완료 - 이 지표는 다운로드와 관련성이 더 높지만 고객사는 다운로드가

완료된 비율(%)을 알고 싶어합니다. 사용자가 유료 게임 또는 소프트웨어를

다운로드할 때 다운로드가 완료되지 않으면 비즈니스 문제로 이어질 수 있기 때문에

완료율의 중요성은 점차 높아지고 있습니다.

Akamai의 미디어 보고서에서 일부 지표를 확인할 수 있습니다. 만약 클라이언트 측면에서

보다 세분화된 지표가 필요하다면 SDK(Akamai 또는 써드파티)를 설치해야 합니다.

결론

인터넷을 통해 대규모 다운로드를 까다로운 사용자에게 전송하는 일은 말처럼 쉽지

않습니다. 게이머는 기다리지 않습니다. 대신 콘텐츠가 즉각적으로 보여지기를 기대합니다.

콘텐츠 퍼블리셔는 비용, 성능, 가용성 사이에서 균형점을 찾아야 합니다. Akamai는 전

세계의 여러 대기업들과 지속적으로 협력해 온 경험을 바탕으로 이벤트를 원활히 진행하도록

지원할 수 있습니다. Akamai의 컨설팅팀([email protected] 으로 문의)은 인터넷에서

이뤄지는 대규모 다운로드 이벤트를 지원하고 관리할 수 있는 풍부한 경험과 전문 지식을

보유하고 있습니다.

mailto:[email protected]


저자 약력

사브리나 버니(Sabrina Burney)

엔터프라이즈 아키텍트

사브리나 버니는 산타클라라 대학교를 졸업한 후 각종

분야에서 다양한 경험을 쌓아왔습니다. 컴퓨터 엔지니어링

관련 경력과 IT 기술에 대한 열정을 갖고 있습니다. Akamai 입사 전후에 소프트웨어 개발,

웹 보안 뿐만 아니라 미디어와 웹 경험 분야에서 경력을 쌓았습니다. 사브리나는 여러

분야에서 근무한 경력을 토대로 전반적인 최종 사용자 경험, 특히 웹 탐색 기능 개선을

지원하고 있습니다. 최근에는 써드파티 콘텐츠와 관련 취약점 및 문제를 해결하는 방법에

주력하고 있으며, 이 분야에서 몇 개의 특허를 출원해 놓은 상태입니다. 업무 외적으로는

친한 동료들과 함께 축구하는 것을 좋아하고 가족들과 여행을 하기도 합니다.

라지브 램나스(Rajiv Ramnath)

엔터프라이즈 아키텍트

라지브 램나스는 Akamai의 엔터프라이즈 아키텍트로

슈퍼볼, 피파 월드컵 등 Akamai의 몇몇 대규모 이벤트를

지원한 경험이 있습니다. 라지브는 컴퓨터 엔지니어링

경력을 보유하고 있으며, Akamai 입사 전에는 싱가포르에서 소프트웨어 엔지니어로서

싱가포르 정부의 보안 프로젝트에 참여했습니다.


임창현

수석 엔터프라이즈 아키텍트

임창현은 Akamai 서울 오피스의 수석 엔터프라이즈

아키텍트입니다. 대형 방송사 라이브 이벤트의 서비스 품질

평가 및 맞춤형 보고서, 게임 및 펌웨어의 다운로드 전송에

대한 성능 평가, 오리진 트래픽 및 용량 최적화, 고객사 미디어 서비스의 아키텍처 설계 및

기술 로드맵 자문 측면을 맡아 다수의 데이터 중심 프로젝트를 주도적으로 이끌었습니다.

자신의 방법론을 개선하고 있고 적용할 수 있는 새로운 분야를 개발하고 있습니다. Akamai

입사 전에는 9년 동안 삼성전자의 엔터프라이즈 모빌리티 관리 플랫폼 및 모바일 방송

(DVB-H 및 mDTV(ATSC-MH)) 부서에서 SW 개발자, 아키텍트, 제품 매니저, 팀 매니저로

일하며 다양한 경험을 쌓았습니다. TCP 알고리즘 개선 연구로 박사 학위를 받았습니다.


Akamai는 전 세계 주요 기업들에게 안전하고 쾌적한 디지털 경험을 제공합니다. Akamai의 Intelligent Edge Platform은 기업과 클라우드 등 모든 곳으로 확장하고 있고 고객의 비즈니스가 빠르고, 스마트하며, 안전하게 운영될 수 있도록 지원합니다. 대표적인 글로벌 기업들은 Akamai 솔루션을 통해 멀티 클라우드 아키텍처를 강화하고 경쟁 우위를 확보하고 있습니다. Akamai는 가장 가까운 곳에서 사용자에게 의사 결정, 앱, 경험을 제공하고 공격과 위협을 먼 곳에서 차단합니다. Akamai 포트폴리오는 엣지 보안, 웹∙모바일 성능, 엔터프라이즈 접속, 비디오 전송 솔루션으로 구성되어 있고 우수한 고객 서비스, 애널리틱스, 24시간 연중무휴 모니터링 서비스를 제공합니다. 대표적인 기업과 기관에서 Akamai를 신뢰하는 이유를 알아보려면 Akamai 홈페이지(www.akamai.co.kr) 또는 블로그(blogs.akamai.com)를 방문하거나 Twitter에서 @Akamai를 팔로우하시기 바랍니다. 전 세계 Akamai 연락처 정보는 www.akamai.com/locations에서 확인할 수 있습니다. Akamai 코리아는 서울시 강남구 강남대로 382 메리츠타워 21층에 위치해 있으며 대표전화는 02-2193-7200입니다. 2019년 1월 발행.

https://www.akamai.com/kr/ko

blogs.akamai.com

https://twitter.com/Akamai

https://www.akamai.com/kr/ko/locations.jsp

게임을 위한 다운로드 전송 최적화 | akamai...전송 최적화 수준을 평가하면...

Documents