The document discusses the role of infrastructure engineers, emphasizing their responsibilities in maintaining, deploying, and improving systems while navigating internal communications and tool usage. It highlights the importance of understanding the history and purpose of tools like Kafka, advocating for thoughtful selection and use of technology. The message is a call for engineers to appreciate their critical role in building reliable systems for the future of the internet.

1. 시니어가 들려주는
“내가 알고 있는 걸
당신도 알게 된다면"
이성민
sungminl@netflix.com

2. Who am I?
● Netflix (~ Present)
○ Data Platform Infrastructure
● Zillow Group (2016 ~ 2020)
○ Application Infrastructure, CI/CD
● Oracle (2012~2016)
○ Solaris OS

3. Who am I?
● Netflix (~ Present)
○ Data Platform Infrastructure
● Zillow Group (2016 ~ 2020)
○ Application Infrastructure, CI/CD
● Oracle (2012~2016)
○ Solaris OS 🪦

4. 전제
● 학생, 주니어 엔지니어
● 인프라 엔지니어 (* Infrastructure, *Ops, SRE, Velocity, Delivery …)
● 열린 마음 😊

5. ● We design things
● We build things
● We test things
● We deploy things
● We maintain things
Infra Engineer vs Software Engineer

6. ● We design things
● We build things
● We test things
● We deploy things
● We maintain things
… for the customers
Infra Engineer vs Software Engineer

7. ● We design things
● We build things
● We test things
● We deploy things
● We maintain things
… for the customers
other engineers
Infra Engineer vs Software Engineer

8. ● We design things
● We build things
● We test things
● We deploy things
● We maintain things
… for the customers
other engineers
Infra Engineer vs Software Engineer

9. ● Internal communications
● Tools.. A lot of tools..
● Knowledge coverage
● production responsibility
인프라 엔지니어의 특수성

10. ● 엄청난 양의 내부 interruptions
○ Slack (or any other modern chat apps) can be toxic
○ “No” 라고 말 할 수 있는 용기
○ Shadowing approach (bus factor를 최소화)
○ 문제에 대한 자동화와 문서화
○ 대부분은 사내 문화적 문제
● 고질적인 문제에 대한 빠른 해결
○ 알려진 문제점에 대한 내용은 투명하게 공개
○ 빠른 시일 내에 해결하거나, 현재 고칠 수 없음을 명확히 고지
내부 커뮤니케이션의 함정

11. Over communicating > Under communicating
● 예상되는 큰 변경사항에 대해 적극적인 알림
○ 이메일, 슬랙, in-person
○ 주기적 리마인더
● Constant status update and fast feedback loop
○ 적극적 양방향 소통
○ Platform survey

12. 엄청난 양의 tool들

13. Source: https://landscape.cncf.io/images/landscape.png, https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.png

14. 엄청난 양의 tool들
● Tools are just tools
○ There is no silver bullet
○ 너무 많은 툴은 오히려 생산성을 저하
○ 툴은 필요에 의해서 사용 (so do you really need Istio?)
○ 시간이 될 때 많은 도구를 시도해 보는건 좋은 습관 (하지만 주객이 전도되지 않도록)
● 최소한의 tool로 최대한의 효율을 높일수록 🚀
○ 3 tier evaluation (must have, nice to have, no need) 로 핵심적 기능이 있다면 OK
○ 커뮤니티등을 통해 현재 사용되는 de facto standard들을 알아보기
● 도구 자체보다 도구가 작동 되는 원리를 이해
○ 필요하다면 과감히 새로운 툴을 만들 필요도 있어야
○ 이 툴이 나오게 된 배경을 이해 (이 도구가 해결하고자 한 문제점은?)
○ 문제점에 대한 적극적인 upstream contribution / vendor feedback
○ 필요시 언제든지 만들어 낼 수 있는 능력! (remember: we are engineers, not operators)

15. So Kubernetes?
● Google: Borg
● Facebook: Twine (formerly Tupperware)
● Uber: Peloton
● Netflix: Titus

16. “ take the time to understand the history of a tool
or technology when evaluating it. Knowing why
something was built and what problem it solves
will let you "pattern match" its effectiveness for
you and your challenges. For example: kafka.
Kafka was built to ingest beacon logs in a
datacenter at scale at LinkedIn originally. It was
not a general purpose pub/sub mechanism as its
marketed today, it was designed not for the cloud
and for commodity spinning disk, not EBS. A lot
of that is smoothed over today but when it was
first open sourced people jumped on it without
knowing why it was built and put it in AWS to do
things it wasn't meant to do.
Eric Lee (SRE, Eng Lead @ Github)
도구와 기술의 역사를 이해하는데 노력을
해보세요. 무언가가 왜 만들어졌고 어떤 문제를
해결하려 했는지를 아는 것이 당신이
해결하고자 하는 문제에 가장 효과적으로
매치할 수 있도록 해 줄 것입니다. 카프카를
예로 들 수 있겠네요. 카프카는 원래 당시의
LinkedIn 스케일에서의 데이터센터 로그 수집을
위해 만들어졌습니다. 당시의 카프카는 현재
사용되는 것과 달리 범용적인 pub/sub
mechanism을 위해 만들어진 것이 아니었고,
클라우드의 block storage가 아닌 spinning
disk를 위해 디자인 되었습니다. 많은 부분들이
오늘날에 와서 해결 되었지만, 카프카가 처음
오픈소스화 되었을때 많은 사람들은 이 툴이
개발 된 이유를 모른채 AWS에 올리고 본래
의도와는 다르게 사용하곤 했었습니다.

17. 광범위한 coverage
● 수평적 지식
○ 각 다른 스택의 패키징
○ 스택을 어우르는 observability integration
○ 각 스택간의 동작과 limitation 이해
● 수직적 지식
○ Kernel / network knowledge
○ Low level debugging (*trace, bpf, gdb)
○ Web knowledge (HTTP headers, caching, DNS, SSL)
● 한번에 모든 것을 알 수는 x
○ 지적 호기심은 성장의 자양분
○ Minimize “well, it recovered itself ¯_(ツ)_/¯”

18. Production Reliability
● Yes, 💩 happens
○ Could be you/your team, or could be other teams/devs
○ We are (easily) the one to be blamed 👈
● Learn from the failures
○ Monitoring and observability
○ Environment (dev, stage, preprod, prod, etc)의 중요성
○ 모든 것을 포용하는 멘탈
○ 다시한번 말하자면, 개발자들은 우리의 고객 👑

19. Production Reliability

20. “ (Whenever you are frustrated by the others
from the outages and the blames) the often times
you’ll find yourself thinking my work is thankless
and menial and that the other developer has
such sexy cool work. Take a step back when this
happens and realize that the work that you’re
actually doing is what it takes to scale and build
the Internet for what it is now and what it will be
in the future. You are a real plumber of the
Internet. There is no shame in that. Only glory at
a whole new level beyond the company you work
for.
Zane Williamson (Sr. Staff Engineer @ Flexport)
(outage로 인한 논쟁이 오가고 사람들로부터
좌절을 느낄때마다) 종종 당신은 당신이
하는 일이 감사 받지 못하거나 천대받는다
느끼고, 다른 개발자들이 훨씬 섹시하고
멋진 일들을 하고 있다고 느낄 수도
있습니다. 이런 일이 있을 땐 한 발 물러서
당신이 실제로 하고 있는 일은 지금과
미래의 인터넷 기술을 만들고 스케일하는
일이라는 점을 상기하세요. 당신이야 말로
진정한 (더러운 일을 마다하지 않는)
인터넷의 배관공이라고 할 수 있습니다.
거기에 수치스러움은 필요 없죠. 당신이
일하는 회사를 넘어선 새로운 가치의
영광이라고 볼 일입니다.