2023 AWS re:Invent — Safe Migration at Netflix안녕하세요, 스푼라디오 Service Platform Team의 백엔드 개발자 Elliott입니다. 개발자로서의 커리어에서 처음으로 AWS re:Invent에 참여하게 되었는데요, 이번 행사에서 다양한 키노트와 세션들을 경험하며 많은 인사이트를 얻을 수 있었습니다. 여기서 제가 가장 인상 깊었던 세션과 그 내용에 대해 소개해드리고자 합니다.AWS re:InventAWS re:Invent는 아마존 웹 서비스가 주최하는 대규모 기술 컨퍼런스로, 클라우드 컴퓨팅과 관련된 최신 트렌드와 기술을 공유하는 장입니다. 매년 라스베가스에서 열리며, 전 세계의 개발자, 엔지니어, IT 전문가들이 모여 새로운 아이디어와 기술을 나눕니다.AWS re:Invent 2023 행사장 입구KeyNoteAWS CEO 아담 셀립스키최근 산업계 전반의 패러다임이 인공지능(AI)을 중심으로 전환되면서, AWS re:Invent의 발표 내용 대부분은 AI 관련 신규 서비스와 기존 서비스의 업데이트, 새로운 버전 등에 집중되었습니다. 특히 주목할 만한 부분은, 엔비디아(NVIDIA)의 CEO인 젠슨 황이 연사로 초청되어 현재 AWS와 엔비디아 간의 협업에 대해 발표한 점입니다. 이 협업은 AI와 관련된 기술 개발에 중요한 역할을 하고 있으며, 이번 행사에서 중요한 하이라이트 중 하나로 다뤄졌습니다.Technologies세션 내용을 소개하기 전에, 먼저 세션에서 다룬 주요 기술들에 대해 간략히 설명드리겠습니다.CassandraApache Cassandra는 고성능, 분산형 NoSQL 데이터베이스 관리 시스템으로, 뛰어난 확장성과 가용성을 제공합니다. Cassandra는 대규모 데이터셋을 다루는 빅데이터 애플리케이션에 적합하며, 특히 많은 양의 데이터를 쓰고 읽는 작업에 최적화되어 있습니다.분산 아키텍처: Cassandra는 데이터를 여러 노드(서버)에 걸쳐 분산시키며, 이는 높은 확장성과 장애 내성을 보장합니다.스케일 아웃: 수평적 확장이 가능해, 데이터양이 증가함에 따라 더 많은 노드를 추가할 수 있으며, 이는 시스템의 성능을 균일하게 유지합니다.마스터리스 아키텍처: 모든 노드가 동일한 역할을 하므로, 단일 장애 지점(Single Point of Failure)이 없습니다.복제: 데이터는 자동으로 여러 노드에 복제되어, 어느 하나의 노드가 실패해도 데이터의 손실이 없습니다.고성능: 특히 대량의 데이터를 빠르게 쓰고 읽는 데 최적화되어 있습니다.Cassandra ThriftCassandra Thrift는 Apache Cassandra의 초기 데이터베이스 인터페이스 중 하나입니다. Thrift는 아파치 소프트웨어 재단에서 개발한 크로스-플랫폼 및 언어 간 서비스 개발 프레임워크로, 여러 프로그래밍 언어를 지원합니다. Cassandra Thrift 인터페이스는 Cassandra의 초기 버전에서 클라이언트 애플리케이션과 데이터베이스 간의 통신을 위해 사용되었습니다.언어 중립성: Thrift는 여러 프

> LINE DEV Meetup #11 LINE 서버 개발자들이 말한다! Armeria 아직도 안 써요?에서 이희승 님이 발표하신 > Three Principles of a Good Framework 세션 내용을 옮긴 글입니다. 안녕하세요. LINE에서 Armeria를 개발했고 현재는 Databricks로 옮겨 RPC 프레임워크 관련 작업을 진행하고 있는 이희승입니다. 이번 글에서는 Armeria 개발 뒤에 숨겨진 세 가지 원칙이 무엇인지 소개하려고 합니다. 많은 분들이 이 세 가지 원칙을 이해하시고 현재 진행하고 있는 혹은 진행하게 될 프로젝트에 적용하면 좋을 것 같다는 생각이 들어서 이렇게 자리를 마련했습니다.   좋은 프레임워크의 세 가지 원칙 Armeria 홈페이지에 들어가면 Armeria의 슬로건과 함께 간단하게 프로젝트 설명이 나옵니다. 이 화면이 Armeria 프로젝트가 어떤 철학을 바탕으로 운영되고, 개발되고 있는지를 잘 나타냅니다. 그럼 각각의 원칙이 무엇인지 하나씩 살펴보겠습니다. 원칙 1: 각자의 페이스로 개발할 수 있게  홈페이지에 들어가면 가장 먼저 Build a reactive microservice at your pace, not theirs라는 문구를 볼 수 있습니다. 문구에서는 at your pace 부분이 강조돼 있는데요. 이게 바로 Armeria의 첫 번째 철학이라고 할 수 있습니다. 개발할 때 다른 사람들의 페이스에 휘말리지 않고 본인의 페이스로 진행할 수 있게 해 준다는 것입니다.  Armeria는 처음에 서버를 개발할 때 아주 작고 단순한 형태로 시작할 수 있게 디자인돼 있습니다. 아래 코드를 보시겠습니다. Server라는 클래스가 있습니다. builder를 만든 다음에 포트 번호를 지정하고, service에서 hello와 경로 파라미터 name에 바인딩합니다. 요청이 들어오면 람다 표현식으로 응답을 생성합니다. 생성한 service를 앞선 경로에 바인딩한 뒤 서버를 build하면 서버가 생성됩니다. 단 몇 줄로 간단하게 RESTful API를 구현할 수 있습니다. 하지만 실제로 서비스를 개발하다 보면 이것만으로는 부족하지 않겠어요? 로깅과 같은 것을 추가하는 작업들이 필요하겠죠. Armeria는 위와 같은 간단한 코드에서 시작해 조금씩 조금씩 살을 붙여 가면서 서비스를 개발할 수 있도록 디자인돼 있습니다. 아래 코드를 보면 decorator라는 메서드를 이용해서 LoggingService라는 것을 추가했습니다. Decorator는 service가 호출되기 전에 공통으로 필요한 기능을 수행하는 역할을 합니다. 처음에 혼자 개발할 때는 로깅 정도만 추가해도 충분하겠지만 프로젝트가 커진다면 Prometheus 지표를 표시하거나 로드 밸런서가 헬스 체크 요청을 보냈을 때 응답하는 기능과 같은 더 다양한 기능이 필요하겠죠. 아래 코드를 보겠습니다. PrometheusExpositionService와 HealthCheckService 서비스를 추가했고 요청에 대한 지표를 수집하기 위해 MetricCollec

안녕하세요. LINE+에서 오픈소스 Armeria와 Central Dogma를 개발하고 있는 엄익훈입니다. 지난 포스팅에선 Reactive Streams의 개념을 살펴보았는데요. 이번 포스팅에선 Reactive Streams를 오픈 소스 비동기 HTTP/2, RPC, REST 클라이언트/서버 라이브러리인 Armeria에서 사용하는 방법에 대해 공유하려고 합니다. Whats Armeria? Armeria는 Java 8 및 Netty, Thrift, gRPC에 기반한 오픈 소스 비동기 HTTP/2, RPC, REST 클라이언트/서버 라이브러리입니다. Armeria는 경량(Lightweight) 마이크로 서비스 프레임워크지만 지원하는 기능은 다른 풀 스택(full stack) 웹 프레임워크와 비교해도 손색이 없습니다. 먼저 Armeria에서 Reactive Streams를 활용한 서버를 구현하기 위해선 기본적으로 알아야 할 것들을 알려드리겠습니다. 지원하는 프로토콜 Armeria에서는 HTTP/1과 HTTP/2를 모두 지원하고, 이 두 개의 프로토콜은 cleartext와 TLS(Transport Layer Security) 암호화 통신을 모두 지원합니다. HTTP/1에서 HTTP/2로의 호환성을 지원하기 위한 프로토콜 업그레이드 면에선, HTTP/2의 connection preface와 HTTP/1의 upgrade request를 모두 지원하고 있습니다. 또한 Armeria에선 gRPC와 Thrift가 HTTP/1과 HTTP/2, 양쪽에서 모두 동작합니다. 이는 Armeria만의 특별한 기능인데요. gRPC는 HTTP/1을 지원하지 않고, 기존의 Thrift에선 HTTP/2를 지원하지 않습니다. 하지만 Armeria에서는 모두 지원하고 있어서 다양한 비즈니스 환경에서 유연하게 사용할 수 있습니다. 또한 리눅스 환경에선 JNI(Java Native Interface) 기반의 소켓 IO와 BoringSSL 기반의 TLS를 통해서 더욱더 빠른 성능으로 프로덕션에 사용할 수 있습니다. 그럼 예제 코드와 함께 Armeria에 대해서 하나씩 알아보겠습니다. 예제 코드로 알아보는 Armeria Armeria는 사용자 친화적인 API입니다. 코드가 간결하고 사용하기 쉽습니다. Hello world 서버를 실행하고 싶다면 아래와 같이 5줄만 작성하면 됩니다.  // Build your own server under 5 lines. var server = Server.builder() .http(8080) .service(/, (ctx, req) -> HttpResponse.of(Hello, World!)) .build(); server.start(); 서버를 쉽게 실행할 수 있다는 점은 마이크로 서비스 환경에서 각각의 비즈니스 컴포넌트를 분리하여 독립된 서버로 관리하려고 할 때 핵심이 되는 사항입니다. 또한 서버 아키텍처를 단순하게 만들 수 있습니다. HTTPS나 HTTP/2를 사용하기 위해 별도로 사이드카(sidecar)인 Nginx나 Apache Htt

2016년 중반 마이크로서비스로의 전환을 결정했습니다. 마이크로서비스는 이론상 다른 서비스에 영향을 주지 않고 내부 기술을 바꿀 수 있습니다. 하지만 마이크로서비스 간의 통신 방법은 한번 결정하면 쉽게 바뀌기 어려울 것 같아서 가장 많이 고민했습니다. 그리고 Thrift를 선택했습니다. 이번 글에서는 그 이유와 이후의 상황에 관해 설명하겠습니다. 마이크로서비스에 대한 글들을 찾아보면 대부분은 통신 방법도 REST API를 많이 얘기하고 있습니다. (예. Introduction to Microservices | NGINX) 그러나 이전 글에서 썼듯이 REST API에 불편함을 느끼고 있었습니다. 특히 마이크로서비스 간에는 REST로 표현하기 어려운 더 다양한 API가 필요해질 것 같았습니다. 그래서 대안을 찾아봤습니다. 그 당시 고려했던 대안은 Thrift, Avro, Protocol Buffers였던 것으로 기억합니다. 지금 시점에 괜찮아 보이는 gRPC는 이상하게 당시 고려대상에서 벗어나 있었던 것 같습니다. 아마 RPC 보다는 데이터 직렬화 쪽을 더 중점적으로 생각했던 것 같습니다. 데이터- 특히 배열 -를 JSON으로 만들면 크기가 매우 크기 때문에 데이터 크기가 줄어드는 게 매력적으로 다가왔습니다. 그중에서 Thrift를 선택한 건 다음과 같은 이유가 있었던 것 같습니다. Avro 방식보다는 Thrift / Protocol Buffers 방식이 더 작은 사이즈를 만들 것 같았습니다. Protocol Buffers는 JavaScript를 잘 지원하는 듯이 보이지 않았습니다. (공식 문서의 튜토리얼에 없음) VCNC에서 Thrift를 쓰고 있다는 글을 봐서 어느 정도 검증이 됐으리라 봤습니다. 그렇게 Thrift를 마이크로서비스 간의 통신에 적용하는 작업을 시작했는데 생각만큼 잘 동작하지는 않았습니다. 몇 가지 문제가 있긴 하지만, 오랜 시간에 걸쳐 안정화되어 현재 수백개의 Thrift API가 존재하고 있습니다. 크로키닷컴만의 특이한 규칙이 하나 있다면 Read API에서 모든 필드 요청을 피하기 위해서 받기를 원하는 필드를 지정할 수 있도록 구성되어 있다는 것입니다. Update API도 하나로 여러 요구 사항에 대응하기 위해 업데이트를 할 필드를 같이 주도록 했습니다. /// 지그재그 공지사항 struct ZigzagNotice { /// 레코드 ID 1: optional i32 id /// 공지사항 내용 2: optional string contents /// 공지 날짜 3: optional i32 date /// 배포 대상 OS 타입 (0:common,1:none,2:iOS,3:Android) 4: optional i32 os /// 공지사항에 필요한 링크 URL 5: optional string link } service ZigzagNoticeService { /** * 해당 레코드 ID의 공지사항을 반환한다. * * fields는 ZigzagNotice의 구조체 필드 ID로 빈 경우 레코드 ID만 반환한다. */ Zig