Re:Invent 1일 차 Recap
첫날부터 열정적으로!!
드디어 AWS Re:Invent 2023 세션이 시작했다. 수많은 사람들이 속속들이 세션장에 모여들었다. 세션을 듣는 게 치열하다는 이야기를 많이 듣긴 했는데, 이 정도로 과다할 줄은 상상도 못 했다. 30분 전에 와도 못 듣는 경우도 있었다. 그래도 이리저리 뛰어다닌 덕에, 원하는 세션 일부를 들을 수 있었다.
이번 포스트에서는 Re:Invent 2023 1일 차에 듣고 배운 내용에 대해서 공유하고자 한다.
AWS ReinventEdge Computing: Snow 시리즈의 매력
예전에 AWS Solutions Architect 자격증을 준비할 때 잠깐 공부한 이후로, Edge Computing에 대한 솔루션을 살펴본 적이 없었다. 그러다 이번에 엣지 컴퓨팅에 관한 세션을 하나 들었는데, 생각보다 놀라운 프로젝트가 많이 이루어지고 있어서 놀라웠다.
엣지 컴퓨팅은 대체로 스마트 카, 카메라, 휴대폰 등 사용자가 직접 사용하는 기기와 연결하여 워크로드를 처리하는 컴퓨팅 아키텍처를 의미한다. 예컨대, 자동차에서 나오는 데이터를 실제 클라우드로 전송하기 전에 차량 자체의 컴퓨팅 파워를 통해 워크로드를 처리할 수 있다. 다시 말해, 기존에 서버를 보관하던 데이터센터가 작은 사이즈로 축약되어 실제 사용자 기기 곁에 존재한다는 의미이다.
AWS에서는 엣지 컴퓨팅을 위해서 다양한 솔루션을 제공하고 있다. 그중에서 별도의 디바이스를 제공하여 대용량 데이터를 처리하고 저장할 수 있는 기술로 Snow Family가 있다. 이러한 Snow Family 솔루션을 사용하여 혁신을 이룬 사례에 대해서 공유하고자 한다.
먼저, 우크라이나는 러시아와의 전쟁 당시, AWS SnowBall Edge를 사용하여 정부 문서를 AWS에 백업했다. 아마 당시 상황은 매우 급박했을 것이다. 전쟁은 시작해 혼란스러운 상황에서, 문서가 담긴 서버가 안전하리라고 보장하기 어려웠을 터였다. 그래서 우크라이나는 AWS SnowBall Edge 장비를 사용하여 10페타바이트가 넘는 데이터를 빠르게 클라우드로 옮겼다. 말로만 듣던 엣지 컴퓨팅 기술이 적재적소에 잘 쓰인 좋은 사례가 아닌가 생각했다.
또한 NASA에서는 AWS Snowcone이라는 작은 사이즈의 컴퓨팅 파워를 가진 엣지 컴퓨팅 도구를 사용해, 실제 우주선 내에서 이미지를 처리하기도 했다. AWS Snowcone은 2 CPU에 4GB 메모리를 가졌지만, 14TB까지 저장이 가능한 SSD를 내장하고 있다. NASA는 지구에서 머신러닝 모델을 테스트했고, 이를 snowcone에 탑재했다. 우주에서 찍은 사진은 NAS를 거쳐 Snowcone으로 전달되고, Snowcone에 올린 모델을 사용해 바로 결과를 추출할 수 있었다. 고해상도의 이미지를 지구와 우주정거장 사이에 제한된 대역폭을 통해 전달하지 않고도, 바로 이미지를 처리할 수 있게 된 것이다. 모델을 수정하거나 버그가 생기면, 놀랍게도 지구에서 SSH로 붙어서 해결했다고 하니, 그저 놀라울 따름이다.
이번 발표를 들으면서, AWS가 지원하고 있는 고객층이 정말로 다양하고, 많은 사람들이 AWS를 통해 사명을 건 놀라운 프로젝트를 하고 있다는 생각이 들었다. 지금 내가 하고 있는 일도 물론 가치 있지만, 빠른 시일 내에 이러한 획기적이고 보람 있는 프로젝트를 한번 해보고 싶다.
Stripe의 Cost Effective 한 Observability
Stripe는 결제 모듈을 제공해 주는 SaaS 업체이다. 최근 Black Friday와 Cyber Monday에서 초당 2만 개의 요청을 받고도 99.9999%의 API가 성공했다고 한다. Stripe는 결제를 책임지는 솔루션이기 때문에, 만약 Stripe에서 장애가 발생하면, 고객(기업) 입장에서는 매출을 놓치게 된다. 5분만 장애가 나도, 엄청나게 큰 타격을 받을지도 모른다. 이러한 상황을 종합적으로 고려해 보면, Stripe의 엔지니어링 기술력이 엄청나게 높다는 생각이 들었다.
트래픽이 많을수록, 모니터링 트래픽도 자연스럽게 늘어난다. 왜냐하면 트래픽을 수치화하거나, 트래픽으로부터 나오는 로그를 수집하는 것이 가장 보편적인 방식이기 때문이다. Stripe에서도 트래픽이 많은 상황에서 비용 효율적으로 모니터링 시스템을 구축하고자 시도했다. 이번 발표가 바로 그 과정에서 얻은 경험에 대한 이야기였다.
Stripe에서 발표한 엔지니어는 Observability 팀에서 일하고 있었다. Stripe가 직면한 어려움은 모니터링을 강화보다도, 비용 효율적인 모니터링 시스템을 구축하는 것이었다. 그래서 비용을 줄이기 위해 실제로 사용하고 있는 메트릭 수를 조사했는데, 아래와 같이 2% ~ 20% 정도만 사용하고 있었다고 밝혔다. 즉, 대부분의 매트릭은 수집하지만 실제로 사용하지 않는 경우가 많다는 의미이다.
출처: AWS Reinvent 2023또한, 4만 개가 넘는 알람(Alert)과 15만 개가 넘는 대시보드가 있음에도, 오직 수십 개의 쿼리가 대부분의 알람을 구성하고 있었다.
출처: AWS Reinvent 2023요약하자면, 실제로 수집하고 있는 매트릭과 실제 알람을 받고 있는 쿼리들을 확인해 보면 상당히 제한적임에도 모든 메트릭을 데이터베이스에 저장해서 언제든 쿼리 할 수 있도록 방치하고 있다는 의미이다. 발표자는 이렇게 데이터베이스 중심의 모니터링 시스템이 아니라, 실제 데이터를 처리하는 구간(Data Plane)에서 모니터링 시스템을 구축하라고 조언한다.
발표자가 제안한 5가지 기술적 방법은 다음과 같다.
1. Sharding: 안정성 확보를 위해 이른 시점부터 샤딩을 하는 편이 좋다. 파티션 키를 적절하게 만들어서 샤딩을 하면 하나의 사드가 죽더라도 다른 데이터에 손상이 가지 않고, 모니터링 시스템이 작동하지 않을 가능성을 높여준다.
2. Aggregation: 데이터를 모두 수집하지 말고, Aggregator를 통해서 데이터 중에 필요한 것만 취합하여 저장한다. 나머지는 버리거나, 다른 방식으로 저장할 수 있다. 이때, 지나치게 많이 버리게 되면 필요한 정보를 얻지 못할 수 있으니 주의가 필요하다.
3. Tiered Storage: 주요하게 보는 20% 내의 데이터만 Timeseries 데이터베이스에 저장하고, 중요하지 않은 데이터는 cold 데이터 저장소에 넣으면 비용을 많이 절감할 수 있다.
4. Streaming Alerts: 알람이 필요한 경우, 데이터베이스에 저장하기 전 Streaming 과정에서 알람 여부를 판단하면 비용을 크게 절감할 수 있다. 또한 쿼리를 해서 알람 여부를 판단하는 부담감도 줄일 수 있다. 알람을 보내고 나면, 실제 데이터는 데이터베이스에 넣어도 되고, 넣지 않아도 된다.
5. Isolation: 운영 안정성을 확보하기 위해서는 직접 운영보다 완전 관리형 솔루션을 사용하는 것도 방법이다. 실제 운영에 발생하는 운영 비용까지 계산하면 비용 절감 효과를 누릴 수도 있다.
이 중에 가장 인상 깊었던 건, Streaming Alerts이다. 실제로 알람을 받기 위해 태그를 추가하는 경우가 있을 수 있다. 만약 알람 이후에 대시보드에서 보지 않는다고 하면, 알람을 보내고 나서 태그를 지우고 데이터를 저장할 수도 있다. 만약 데이터 자체가 필요하지 않다면 데이터를 아예 저장하지 않을 수도 있다. 그러면 알람을 더 일찍 받으면서도 데이터 저장에 대한 비용도 아낄 수 있다.
우리 회사는 Stripe처럼 Observability 팀이 따로 있지는 않아, 내가 속한 팀에서 모니터링 시스템을 구축하고 있는 실정이다. 현재는 데이터가 그리 많지 않아서 비용이 부담되지 않지만, 트래픽이 많아지게 되면, 분명히 고도화해야 하는 날이 올 것이라고 생각한다. 그때, Stripe 사례에서처럼 비용을 최적화하면서 동시에 운영 안정성을 높일 수 있는 방안을 도입해 볼 수 있을 것 같다.
이번 발표가 개인적으로 좋았던 이유는 특정 기술을 소개하거나 Stripe의 결과물을 보여주기보다는 그 과정에서 고민했던 것들을 자세하게 설명해 주었던 점이었다. 아키텍처는 상황이 바뀌면 계속 모습이 바뀔 수 있는데, 그 기저에 깔려있는 원칙은 크게 바뀌지 않을 가능성이 높다. 나는 발표를 듣고 나서, 추후에 우리 서비스의 모니터링 시스템을 개편한다고 할 때, 비슷한 사고방식을 적용하여 문제를 해결할 수 있겠다는 생각이 문득 들었다. 마치 성공하는 구체적 방법보다는 개념적인 조언을 해주는 자기 계발서를 읽는 느낌이었다.
Amazon Q on AWS QuickSight를 활용한 셀프서비스
Amazon Q는 이번 reinvent 2023에서 출시된 Generative AI 솔루션이다. Amazon Q를 사용하여 사용자는 자사의 기업을 위한 어시스턴트를 만들 수 있다. 또한 AWS Console, Amazon QuickSight 등의 솔루션에 탑재되어 쉽고 편리하게 서비스를 이용할 수도 있다.
이 중에서, 나는 Amazon Q를 Amazon QuickSight와 연동하여 비개발자도 누구나 편리하게 지표를 만들어내는 데모를 보았다. Amazon QuickSight는 AWS에서 제공해 주는 BI 솔루션이다.
기존에는 지표를 그리기 위해서 지표에 대해서 자세하게 알고, 그래프를 그리는 것도 배워야 했다. 이는 기술을 다뤄본 적 없는 비개발자 혹은 C-레벨 의사결정권자가 보기에는 쉽지 않았다. 그래서 이것만 그려주는 BI 팀이 따로 있는 회사도 있다.
그런데 이제는 Amazon Q에게 자연어로 질의하여 원하는 지표를 손쉽게 얻을 수 있게 되었다. 즉, 누구든지 BI팀에 문의하지 않고 직접 보고 싶은 데이터를 바로 확인할 수도 있다. 예컨대, C 레벨 의사결정 회의에서 직접 보고 싶은 데이터를 볼 수 있다면, 직접 의사결정을 하는 입장에서 큰 도움을 받을 수 있다.
출처: AWS 공식 문서예전에 누군가 AI는 정답을 주는 도구가 아니라 인사이트를 주는 도우미라고 말한 적이 있었다. Amazon Q의 서비스 설명에도 Assistant라는 말이 붙듯이 Amazon Q는 우리에게 정답을 주는 도구가 아니라 도움을 주는 서비스이다. 나는 Amazon Q on Amazon QuickSight는 단순히 편리성을 제공해 준 것이 아니라, 의사결정이 필요한 사람에게 인사이트를 제공해 줄 수 있다는 점에서 매우 놀라운 서비스라고 생각한다.
다른 말로 하면, "과연 Amazon Q가 제공해 준 정보를 해석하는 사람이 올바른 판단을 할 수 있을까"에 대한 답변은 "사용자가 그만큼 인사이트를 가질 수 있을 만큼 충분히 능력이 있어야 한다."이다. 즉, 자연어를 통해 원하는 지표를 얻었다고 하더라도, 해당 지표가 믿을 만큼 정확한 정보인지, 혹은 해당 지표를 보고 인사이트를 찾아낼 수 있는지는 정보를 보는 사용자의 몫이라는 점이다.
요컨대, Amazon Q를 통해 AWS가 많은 서비스에서 편리함에 제공해 줄 것으로 생각하지만, 그렇다고 우리가 해야 할 일을 대체할 수 있다고 생각하지는 않는다. Amazon Q의 도움을 통해 정보를 쉽고 간편하게 얻을 수 있는 만큼, 스스로 그 정보를 올바르게 해석하고 인사이트를 찾을 수 있는 사람이 되어야 한다.
이번 데모를 보면서, 이제는 데이터를 추출하는 기술보다 데이터를 보고 판단할 수 있는 능력을 길러야 할 때가 아닐까 하는 생각이 들었다.
EKS 신규 기능과 Slack의 사례
EKS는 AWS에서 가장 핫한 서비스 중 하나이다. 많은 기업들이 워크로드 대부분을 쿠버네티스 환경에 올리고 있고, AWS는 EKS 서비스를 통해 고객에게 견고한 컨트롤 플레인 서비스를 제공한다. 이번 ReInvent 세션에서 가장 인기 있던 세션 중 하나가 바로 "The Future of EKS"였다. (사람이 너무 많아서 나는 실제 세션장에는 들어가지 못했는데, 다행히 이원 생중계해주는 곳에 자리가 있어서 들을 수 있었다.)
발표는 EKS의 5년 역사를 빠르게 회고하면서 시작되었다. 이후 신규 기능에 대해 소개가 이어졌다. 신규 기능 중 가장 눈에 띄었던 건, AWS Pod Identity였다. 기존에는 Pod에 IAM 역할을 별도로 설정하려면 IRSA 기능을 통해서 설정해줘야 했다. 이를 위해서 OIDC Provider를 만들고 이를 사용하기 위한 IAM Role을 만든 후에, Pod가 사용하는 Service Account에 Annotation을 설정했다.
이제는 이러한 불편함을 감수하지 않아도 된다. AWS Pod Identity Add On을 통해 Agent를 설치하면, 손쉽게 Pod에 IAM을 주입할 수 있다. Agent가 설치되고 나면, Pod Identity Assocation을 AWS Console에서 생성할 수 있다. 이때, 내가 사용할 IAM과 어떤 파드가 사용하게 할지 정보를 추가할 수 있다. 이 기능이 특별하게 간편한 이유는 AWS API 수준에서 작동하기 때문에 테라폼에서 한 번에 설정할 수 있기 때문이다.
또한 이제는 클러스터마다 별도로 IAM Role을 사용하지 않아도 된다. 즉, 클러스터 제약 없이 하나의 IAM Role을 매핑하여 사용할 수 있다. 클러스터마다 공통으로 사용되는 서비스가 있다면 하나의 IAM을 사용함으로써 리소스를 중복해서 생성해야 하는 부담을 줄일 수 있다.
발표에서 공개한 또 하나의 기능은 바로 Extended Support이다. AWS는 특정 EKS 버전을 원래 14개월 동안만 책임지고 유지/보수한다. 예컨대, CVE 보안 취약점 등이 발생되었을 때 해당 버전에 무중단으로 패치를 해주는 작업도 여기에 포함된다. 만약 14개월 동안 해당 버전을 사용한다면 AWS는 강제로 다음 버전으로 업그레이드되었다.
그런데 1.23 버전부터 AWS는 12개월 동안 추가로 유지 보수를 연장해 주는 기능을 출시했다. 사용자는 총 26개월 동안 특정 버전을 사용할 수 있고, 그 안에만 업그레이드하면 안전하게 EKS를 사용할 수 있다. 하지만, 연장기간인 12개월은 연장에 대한 비용을 추가적으로 지불해야 한다. 현재는 Preview 단계라서 사용하더라도 추가 비용이 없지만, 24년 1월 중에 비용이 정해질 것으로 예상하고 있다.
위 기능이 출시된 이유는 AWS에서 고객에게 업그레이드에 대한 여유 시간을 벌어주기 위함이다. 클러스터 업그레이드는 서비스에 영향을 미치는 작업인 만큼 시간을 가지고 영향도를 파악해야 한다. 만약 이러한 사전점검이나 테스트 없이 강제로 업그레이드된다면 서비스에 문제가 발생할 수 있다.
다만, 1년 동안 AWS는 이전 버전을 책임지고 유지/보수해야 하기 때문에 내부적으로 운영에 대한 유지비용이 발생한다. 또한 연장 지원을 무료로 제공하면, 사용자가 업그레이드에 대한 필요성을 느끼지 못하는 경우가 발생할 수 있다. 이 두 가지 이유로 AWS는 비용을 받고 추가로 연장기간을 제공하는 것으로 보인다.
AWS가 쿠버네티스 버전을 지원하는 속도가 점점 빨라지고 있는 만큼, 사용자도 이전 버전이 EOS 되는 것에 대한 압박을 느낄 수 있다. 14개월이면 1년이 조금 넘는 시간인데, 비용을 추가로 납부하기 싫다면 최소 1년에 한 번씩은 업그레이드를 진행하는 편이 좋다. 쿠버네티스는 3개 버전 까지는 컨트롤 플레인과 노드 간의 버전 호환을 지원한다. 예컨대, 1.25 버전 노드는 1.25 ~ 1.28 버전의 EKS 클러스에서 문제없이 동작한다. 즉, 시간이 없다면 EKS 버전을 먼저 올리고, 노드 버전은 나중에 올려도 된다는 의미이다. 물론 현재로서는 마이너 버전 업그레이드에 대해서만 유효하다.
https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html추가로, 얼핏 듣기로는 aws-auth 설정도 이제 사라질 예정이라고 한다. aws-auth는 클러스터 접근 시에 필요한 설정인데, 이를 다른 방식으로 대체하여, EKS 리소스 수정 없이 AWS API만으로 클러스터 접근을 제어할 수 있도록 변경할 것으로 보인다.
부가적으로, 발표 중간에 Slack에서 EKS를 사용한 플랫폼 엔지니어링 사례를 소개했다. 슬랙은 내부적으로 Bedrock이라는 플랫폼을 통해 개발자가 자신을 코드를 빠르게 배포하고 테스트할 수 있는 기능을 제공한다. 개발자는 코드를 작성한 후에 간단한 YAMl파일을 작성하면, 이미지 빌드부터 CI/CD 파이프라인, 쿠버네티스 배포, Nebula(내부 FIrewall 솔루션) 등이 자동으로 설정된다. 즉, 개발자는 이러한 기능을 몰라도 자신의 서비스를 간편하게 테스트하고 출시할 수 있다.
나는 Slack의 은 상당히 높은 수준의 플랫폼 엔지니어링이라고 생각한다. 개인적으로 플랫폼 엔지니어링을 도입할 때 가장 우려스러운 점은 개발자가 현재 인프라 상황과 맞지 않는 코드를 작성하거나 아키텍처 고민 없이 획일화된 구조에서 서비스를 만들 수 있다는 점이다. Slack의 경우에는 개발자 수준이 전반적으로 높기 때문에 그러한 우려사항이 적을 수도 있지만, 현실적으로 한국에서는 쉽지 않아 보인다. 다만, 발전하는 기술과 산업을 따라가기 위해 빠르게 서비스를 출시하려면, Slack의 Bedrock과 같은 플랫폼이 필요하다고 생각한다. Slack의 Bedrock을 통해 우리가 최종적으로 나아가야 할 방향 중 하나를 이번 발표에서 볼 수 있어서 개인적으로 만족스러웠다.
넷플릭스의 IPv6 Journey
1일 차 세션 중에 가장 놀라웠던 내용은 바로 넷플릭스의 IPv6 마이그레이션 사례였다. 넷플릭스는 AWS를 사용하는 고객 중에서도 가장 엔지니어링 수준이 높기로 유명한 회사이다. 넷플릭스 세션은 주제를 막론하고 reinvent에서 가장 인기 있는 세션 중 하나이다. 그중 우연히도 최근 관심을 가지고 지켜봤던 IPv6 마이그레이션 사례를 들을 수 있었다.
최근에 내가 IPv6 도입을 고민했던 이유는 회사 내 사설 IP가 고갈 위기이기 때문이었다. 클라우드를 도입하면서 사설 네트워크를 자유롭게 설정할 수 있게 되었는데, 도입 과정에서 관리가 제대로 되지 않아 IP 대역이 겹치는 사례가 지속적으로 발생하고 있다. 이를 해결할 수 있는 다양한 방법이 있지만, 그중 하나의 옵션으로 IPv6를 생각하고 있었다.
반면, 넷플릭스는 비용과 네트워크 복잡도를 줄이기 위해서 IPv6를 도입했다. (이미 프로젝트는 21년부터 진행했고, 해당 내용은 21년 reinvent에서도 한 적이 있다). IPv4를 사용하면 내부 통신과 외부 통신 대역을 구분해야 하고, 그 중간을 메우기 위해 NAT Gateway, Direct Connect, Peering 등과 같은 기능들이 필요하다. 또한 IP 대역이 겹치게 되면 중간에 라우팅을 위한 별도의 인프라도 구축해야 한다. 넥플릭스처럼 규모가 큰 기업에서는 네트워크 복잡도가 증가할수록 운영 비용도 커지는데, 그 대표적인 원인이 바로 NAT와 Transit 라우팅이다.
IPv6를 사용하면 프라이빗과 퍼블릭의 경계가 없어지고, NAT를 할 이유가 사라진다. 왜냐하면 IPv6는 전 세계적으로 고유하기 때문이다. 즉, 모든 통신은 인터넷 게이트웨이를 통해 가능하다. 따라서 외부 혹은 VPC 간 통신 구분 없이 하나의 라우팅 테이블 규칙만으로 설정이 가능하다. 자신의 VPC가 아니면 모두 egress 전용 인터넷 게이트웨이로 나가도록 설정하면 된다.
https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html발표를 들으면서 부러웠던 점은 보안팀이 기술과 의도를 이해하고 넘어갔다는 점이다. 지극히 개인적인 경험에 비추어보면, 대부분의 한국 보안 담당자는 외부 통신을 꺼려한다. 인터넷으로 트래픽이 나간다고 하면 일단 불편해한다. 실제로 사내에서도 외부 통신이 가능함에도 불구하고 내부 통신을 하도록 가이드하는 경우가 많다. 물론 한국과 미국의 통신망법 등이 다르다는 점도 있겠지만, 결과적으로 기술적으로 대화해서 안전한 방법을 함께 찾아나가는 부분이 너무나도 부러웠다.
(어려움) 넷플릭스는 어떻게 IPv4로 나가야 하는 트래픽을 IPv6에서 사용했을까?
참고로, 넷플릭스는 클라이언트가 IPv6를 지원하지 않는 경우를 위해 외부로 노출된 인터페이스는 dual stack을 사용한다. dual stack을 사용하면 IPv4와 IPv6로 모두 통신이 가능하다. AWS ALB에서는 간단한 설정 한 번으로 dual stack을 지원한다.
그런데 문제는 outbound이다. IPv6 Only 모드에서 IPv4 서버와 통신을 할 때 NAT가 필요하다. 왜냐하면 IPv6 only 네임스페이스에는 IPv4로 가는 라우팅이 없기 때문이다. 넷플릭스는 이 문제를 해결하기 위해서 TSA(Titus Syscall Agent)를 사용했다. Titus는 자체 멀티테넌트 컨테이너 플랫폼으로 쿠버네티스와 유사한 역할을 한다고 생각하면 된다.
TSA의 동작 원리는 다음과 같다. TCP 네트워크 연결을 위해서는 connect()라는 syscall을 사용한다. 이때 커널은 해당 프로세스의 네임스페이스 내 라우팅 정보에서 목적지에 일치하는 라우팅 규칙을 찾지 못하면 에러를 반환한다. 예컨대, IPv6 Only 네임스페이스에서는 IPv4로 가는 라우팅을 찾을 수 없어 통신이 불가하다. TSA는 이 connect()라는 syscall을 가로채서 조작하기 위해 seccomp 필터를 사용한다.
seccomp은 커널 시스템 콜을 가로챌 수 있는 필터이다. 사용자는 seccomp 필터를 통해서 프로세스가 사용할 수 있는 시스템 콜을 제한할 수 있다. 이때 seccomp의 notify 기능을 사용하면 가로챈 시스템 콜을 notification fd(파일 디스크립터)로 보내줄 수 있다. 즉, 현재 컨테이너 프로세스에서 사용한 시스템 콜을 커널이 수신할 때 notification fd로 보내주고, notification fd를 사용하는 프로세스에서 syscall을 조작할 수 있다. 여기서는 TSA가 바로 syscall을 조작하는 주인공이다.
실제 시스템 콜을 가로채는 과정은 다음과 같다.
https://www.youtube.com/watch?v=ZEd0ZAskY7E그러면 IPv6에서 IPv4로 통신할 때는 어떻게 connect()를 조작하는 것일까?
먼저 IPv6 Only 네임스페이스를 사용하는 태스크에서 IPv4 목적지로 connect() 시스템 콜을 보냈다고 해보자. 그러면 TSA가 이 시스템 콜을 가로채서 라우팅 정보를 확인한다. 당연히 IPv6 Only 네임스페이스이기 때문에 라우팅 정보가 없다. 이때 TSA는 에러를 반환하지 않고, 자신이 직접 IPv4 목적지와 connect()를 시도한다. TSA는 IPv4 네임스페이스를 사용하기 때문에 통신이 가능하다. 그러면 TSA에서 목적지로 패킷을 보낼 수 있는 fd가 별도로 생성된다. 해당 fd를 통하면 IPv4대역으로 통신이 가능하다. 따라서 TSA는 원래 Task에 connect() 요청에 대한 응답을 보낼 때 원래 보냈던 fd를 새롭게 생성한 fd로 바꿔치기한다. 그 이후에는 원래 Task는 TSA가 생성한 fd를 사용하여 패킷을 전송하기 때문에 중간에 TSA가 관여하지 않는다. 즉, IPv6와 IPv4 간의 연결을 TSA가 대신해주고, 연결된 fd를 원래 task에 전달해서 둘 간 통신이 가능하도록 해준 셈이다.
이렇게 내가 1일 차에서 배운 내용을 정리해 보았다. 첫날부터 흥미롭고 재밌는 세션들이 많아서 벌써 많이 배운 느낌이 들었다. 참고로 본문에서 사용한 장표는 모두 인터넷에 공개되어 있다.
