AWS Managed Flink + Kinesis DataStream 실시간 데이터 처리 시스템 개요

1. 개요

최근 데이터 처리 환경은 “실시간”이라는 키워드가 핵심입니다.

대용량 이벤트 스트림을 빠르게 수집하고, 실시간으로 분석·가공한 뒤 다양한 시스템에 전달해야 하는 요구가 있어서

AWS에서 제공되고 있는 Amazon Kinesis DataStream와 **Amazon Managed Service for Apache Flink(이하 Managed Flink)**를 활용해봤습니다.

이번 글에서는 이 두 서비스를 활용해 실시간 데이터 파이프라인을 구축하는 기본 개념과 설계 포인트를 정리해봅니다.

2. 서비스 개요

2.1 Amazon Kinesis

Kinesis는 AWS의 완전관리형 스트리밍 데이터 서비스입니다. (Kafka 와 유사하다고 생각하시면 됩니다.)

이 중 **Kinesis Data Streams(KDS)**를 사용하면 초당 수백 MB~GB급 이벤트를 안정적으로 수집·버퍼링할 수 있습니다.

특징

• 샤드(Shard) 단위로 처리량 확장 가능 -> 파티션 과 유사
• 순서 보장 및 재처리 지원
• 초당 수천 TPS 가능
• SDK, Firehose, CLI 등 다양한 연동 방식

2.2 Amazon Managed Flink

Apache Flink를 완전관리형으로 제공하는 서비스입니다.

Managed Flink를 사용하면 클러스터 관리나 배포 인프라 고민 없이, Flink 애플리케이션 개발에 집중할 수 있습니다.

단, 기본 Flink와 다르게 조정할 수 없는 Configuration 들이 있으니 공식문서를 참조해야 합니다.

특징

• Flink 버전 업그레이드 및 인프라 관리 자동화
• Kinesis, S3, DynamoDB 등 AWS 서비스와 Native 연동
• Checkpoint/Savepoint를 통한 상태(State) 복구 지원
• Scaling 자동화(Parallelism 조정)

3. 시스템 아키텍처 개요

1. Producer: 실시간 Event 수집 Platform
2. Kinesis Data Streams: 실시간 데이터 Queue
3. Managed Flink: 실시간 데이터 처리(Enrichment, Filtering, Aggregation)
4. Sink: 결과 저장(S3)

4. 구현 시 주요 고려사항

4.1 데이터 모델 & 직렬화

• Flink와 Kinesis 간 전송 데이터는 기본사용은 kryo사용(reflect방식)으로 성능이 떨어지기 때문에 추후 스키마 진화를 생각하면 Avro, Protobuf 등 직렬화 포맷 선택하는것이 유리하다.

4.2 상태 관리(State Management)

• Flink는 Keyed State와 Operator State를 제공
• 상태 크기가 커질수록 Checkpoint 주기와 저장소 성능이 중요하다.
• AWS에서는 기본적으로 S3에 Checkpoint/Savepoint 저장하며 사용자는 접근이 불가능하다.

4.3 Checkpoint / Savepoint 전략

• Checkpoint: 장애 시 자동 복구
• Savepoint: 버전 배포·롤백 시 수동 복구
• 체크포인트 주기는 1분~5분 권장, 처리량과 지연 시간에 따라 조정

4.4 Source/Sink Connector

• Source: KinesisStreamsSource 또는 Flink Kinesis Connector
• Sink: S3 로 기본사용

4.5 확장성(Scaling)

• Kinesis는 샤드 수로 확장
• Flink는 parallelism 조정 
• 병목 지점(Shard → Flink 병렬도) 일치 여부 체크 필요
• Parallelism과 KPU가 자동으로 계산되는데  4.2의 상태관리와 연관되어 재기동시 backpressure , 지연이 발생하지 않도록 처리시간 + 복원시간을 고려해야 한다.

5. 운영 팁

1. CloudWatch + Managed Flink Metrics로 레이턴시, 백프레셔(backpressure) 모니터링
2. Kinesis 샤드 모니터링 → 샤드 split/merge 자동화 스크립트 준비
3. Flink 애플리케이션 버전 관리 → Git + CI/CD (CodePipeline, CodeBuild) 연동 , Flink재기동은 자동보다는 수동을 추천
4. Data retention: Kinesis는 최대 7일, 그 이상은 S3에 Raw Data 저장
5. 배포 전 로컬 환경에서 Flink MiniCluster로 테스트
6. Flink 내 ProecssFunction에 대해서는 Harness를 이용해서 최대한 Test Code를 작성해둔다.

6. 간단한 예제 플로우

• Source: Kinesis에서 JSON 데이터 읽기
• KeyBy: UserId 단위 처리
• ProcessFunction: 룰 매핑, 데이터 보강
• Sink: S3 저장

DataStream<Event> source = env
    .fromSource(kinesisSource, WatermarkStrategy.noWatermarks(), "Kinesis Source")
    .map(json -> parseJson(json));

source
    .keyBy(Event::getUserId)
    .process(new CustomEnrichmentFunction())
    .addSink(s3Sink);

7.  결론

AWS Managed Flink + Kinesis 조합은 실시간 데이터 분석 파이프라인을 빠르고 안정적으로 구축할 수 있는 강력한 도구입니다.

인프라 운영 부담을 줄이고, 비즈니스 로직에 집중할 수 있다는 점이 가장 큰 장점입니다.

다만, 체크포인트 전략, 상태 크기 관리, Kinesis 샤드 수 조정 등 운영 노하우가 중요하니, 충분히 검증 / 모니터링을 후 본격 도입하는 것을 추천드립니다.

OAuth 2.0 Resource Server에서 JWT 토큰을 검증하고 권한을 처리하는 방법에 대해 알아보겠습니다. Spring Security를 사용하여 Resource Server를 구성하고, JWT 토큰의 scope와 roles 클레임을 권한으로 변환하는 과정을 살펴볼 것입니다. 또한, 자주 발생하는 SSL 관련 오류와 그 해결 방법에 대해서도 다룰 예정입니다.

OAuth2 Authorization Server Setup

개요

AWS RDS와 DynamoDB의 비용 및 성능 비교는 데이터베이스 선택 시 중요한 고려사항입니다. 이 분석에서는 두 서비스의 비용 구조, 성능 특성, 그리고 대규모 쓰기 작업 시나리오에서의 비용 효율성을 살펴보았습니다. 또한 고가용성을 위한 중복 구성 시의 비용과 Spring Boot와의 연동 방법에 대해서도 논의하였습니다.

<개요>

• 테스트의 크기는 되도록이면 작게
• 각 테스트 단위는 독립적으로 주입할 수 있도록
• 필요한 것만 주입받고 테스트 해야하며
• 최대한 빠르게 테스트 실행이 가능해야 함

<내용>

• Layer
  • Controller
    • Web을 통한 호출시 PathVariable, RequestBody, Header, 인증등 을 담당하는 역할
  • Service
    • Biz Logic 구현
    • Biz Transaction 이 필요할 경우
  • Repository
    • Storage 와 Application 의 다리역할
    • 객체변환, 타입검증
  • POJO
    • 독립된 구현
    • 주로 Input / Output 을 통합 로직 수행
• 공통사항
  • Given / When / Then 으로 작성하면 편함 (준비-실행-검증)
• 각 Layer 별 테스트 코드는 다른 레이어가 정상동작한다는 가정으로 테스트하는 것이 원칙
  • Controller Layer
    • WebMvc에 관련된 Context만 로딩 (WebMvcTest)
    • 사용할 Bean들만 TestConfiguration 으로 정의하여 Context의 가동범위를 최소한 으로 한다.  

@RunWith(SpringRunner.class)
@WebMvcTest(BizController.class
)
@Import(SecurityConfig.class)
@ContextConfiguration(classes = SpringSecurityWebAuthTestConfig.class)
public class BizControllerTest {

    @Autowired
    private MockMvc mvc;
    @MockBean
    private BizService bizService;
   
    @Test
    @WithUserDetails("admin")
    public void getAllData() throws Exception{
        List<DataDto> datas = new ArrayList<>();

        DataDto dataDto = new DataDto();
        dataDto.setDataId(1);
        String dataName = "ttt";
        dataDto.setDataName(dataName);
        dataDto.setUserId(1);
        datas.add(dataDto);

        Page<DataDto> pages=new PageImpl<>(datas, Pageable.unpaged(), 1);

        //given
        given(bizService.findAllDatas(PageRequest.of(0,1))).willReturn(pages);
        //when , then
        this.mvc.perform(get("/datas/all?page=0&size=1"))
                .andExpect(jsonPath("content").isNotEmpty())
                .andExpect(jsonPath("content[0].dataId").value(1))
                .andExpect(status().isOk());
    }

• • 테스트 메소드 작성
    • MockBean : Mockup 대상
    • given : 테스트 범위내에서 정상동작할 경우의 응답, 혹은 주어진 조건
    • when : mvc.perform : 수행
    • then : andExpect : 기대값
• Service Layer
  • JUnit으로만 테스트 (Spring Mvc 필요없음)
  • 테스트 대상인 Service 만 Inject, 나머지는 Mock

@RunWith(MockitoJUnitRunner.class)
public class BizServiceTest {
    @Mock
    private BizRepository dataRepository;
    @Mock
    private ModelMapper modelMapper;
    @InjectMocks
    private BizService bizService;

    @Test
    public void createService() throws Exception {
        DataDto dataDto = new DataDto();
        dataDto.setDataId(1);
        dataDto.setUserId(1);
        dataDto.setDataName("text");
        
        DataEntity dataEntity = new DataEntity();
        dataEntity.setDataId(1);
        dataEntity.setUserId(1);
        dataEntity.setDataName("text");
				
        //given
        given(modelMapper.map(dataDto, DataEntity.class)).willReturn(dataEntity);
        given(modelMapper.map(dataEntity, DataDto.class)).willReturn(dataDto);
        //when
        DataDto result = dataService.createData(dataDto);
        //then
        Assert.assertEquals(dataDto, result);

    }

• • 테스트 메소드 작성
    • given : 테스트 범위내에서 정상동작할 경우의 응답, 혹은 주어진 조건
    • when : 테스트 대상
    • then : assertEquals ( expected, actual)
• Repository Layer
  • DataJpaTest 관련된 Context만 로딩
  • 사용할 Bean들만 정의하여 가동범위 최소한으로

  @RunWith(SpringRunner.class)
  @DataJpaTest
  @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
  @Import({EnableEncryptablePropertiesConfiguration.class, JasyptConfig.class, SpringSecurityWebAuthTestConfig.class, TestJpaAuditingConfig.class})
  public class NewsRepositoryTest {
  
      @Autowired
      private NewsRepository newsRepository;
  
      @Test
      public void findAllByEnabled(){
          //given
          Pageable pageable = PageRequest.of(0,10);
  	//when
          Page<NewsEntity> newsEntityPage = newsRepository.findAllByEnabled(true, pageable);
  	//then
          Assert.assertEquals(1, newsEntityPage.getTotalElements());
      }

  • 테스트 메소드 작성
    • given : 테스트 범위내에서 정상동작할 경우의 응답, 혹은 주어진 조건
    • when : 테스트 대상
    • then : assertEquals ( expected, actual )
  • Local Test의 경우 H2 나 기타 메모리DB로 기동될때마다 테스트 데이터를 넣어놓으면 독립적인 테스트가 가능하기 때문에 편리하다.
• 독립 Module
  • Context 기동없이 가능

  public class EmailValidationTest {
  
      @Test
      public void validation(){
          Pattern codePattern = PatternValidator.ValidationType.EMAIL.getMyPattern();
  
          Matcher matcher = codePattern.matcher("terst@gmail.com");
          Assert.assertTrue(matcher.matches());
  
          matcher = codePattern.matcher("test-1@naver.com");
          Assert.assertTrue(matcher.matches());

  • Bean주입없이 그냥 Java new로 POJO 테스트

public class JasyptTest {

	@Test
	public void encryptDecrypt() throws Exception {
		PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
		SimpleStringPBEConfig config = new SimpleStringPBEConfig();
		config.setPassword("");
		config.setAlgorithm("PBEWithMD5AndDES");
		config.setKeyObtentionIterations("1000");
		config.setPoolSize("1");
		config.setSaltGeneratorClassName("org.jasypt.salt.RandomSaltGenerator");
		config.setStringOutputType("base64");
		encryptor.setConfig(config);

		String raw = "abcdefg";
		String encrypted = encryptor.encrypt(raw);

		String decrypted = encryptor.decrypt(encrypted);
		Assert.assertEquals(raw , decrypted);
	}

Git Remote Repository에 Push하기전에 Local Test Case를 모두 통과하는지 반드시 확인해야 한다.

<개요>

우리가 많이 들어본 콘웨이 법칙이다.

- 조직/조직구조의 커뮤니케이션 구조가 소프트웨어의 구조를 결정한다.

우리가 일반적으로 사용하고 있는 MVC구조도 사실 여기에서 영향을 받았다. (UI - 벡엔드 - 데이터)  그래서 비지니스 적으로는 응집력이 낮기 때문에 다른 여러가지 시도가 이루어지고 있는 것이다.

 
한편 역 콘웨이 법칙도 존재한다.

- 소프트웨어 아키텍처 구조가 회사 조직구조를 결정한다.
그래서 만들고 싶은 소프트웨어의 방향에 따라서 조직구성을 인위적으로 하는 것이다. 그리고 그 구성을 매우 유연하게 자주 바꿀 수 있도록 한다.
 

콘웨이법칙은 워낙 개발자들 사이에서 진리를 통하는 법칙인지라 다양한 인용과 해석이 존재하는데 재미있는 표현 몇가지를 찾아봤다.

- 하나의 컴파일러를 만들기 위해서 4개의 팀이 조직된다면, 4단계로 빌드하는 컴파일러가 나오게 된다.

- N명의 그룹이 코볼컴파일러를 구현한다면 N-1단계가 될것이다. (왜냐하면 한명은 관리자가 되어야 하기 때문에)

- 영웅개발자가 만든 소프트웨어는 기발할지 모르지만 에러도 무지 많다.

- 시스템 설계를 자유롭게 하고 싶다면 조직역시 변화에 대비해야 한다.

조직의 구조때문에 만들 수 없다고 여기고 있는 더 나은 설계가 존재하는가

<Self 적용>

요즘은 이런 생각을 한다.
MSA라는 구조가 매우 일반적이되었는데 이것은 특정 소프트웨어 조직의 커뮤니케이션 구조라기보다는 이 세상의 일반적인 동작방식과 유사하다는 생각이 들었다. 

- 아주 예전에 작성했던 글
https://icthuman.tistory.com/entry/IT%EC%8B%9C%EC%8A%A4%ED%85%9C%EA%B3%BC-%ED%98%84%EC%8B%A4%EC%84%B8%EA%B3%84%EC%9D%98-%EA%B4%80%EA%B3%84

- Rebecca Wirfs-Brock 선생님 께서 Nature of Order 를 SW에 비교하여 설명하신 내용
(Nature of Order 라는 자연적 질서에 대해 서술한 책이 있는데 매우 재미있다.)
https://www.youtube.com/watch?v=NZ5mI6-tNUc

1. Message, Event

개인을 각각의 서비스로 상상해보면 일반적인 의사소통을 하면 전달하는방식 (언어, 글쓰기 등)은 유사하지만 그 안에 담기는 내용은 다르며, 같은 메시지도 해석하여 동작하는 방식이 다르다.
 유사한 내용을 다루어 본 사람끼리 더 잘 통하고 이해하며, 내가 잘 모르는 내용에 대해서는 반만 듣고 반은 버린다.
때로는 상대의 공격적인 언행에 대해서는 그냥 내가 필터링을 하거나 한귀로 듣고 한귀로 흘려버리기도 한다.
 
또  어느날 어떤 사람이 컨디션이 평상시와 다르면 말을 더 많이 하거나, 혹은 말을 하지 않기도 하며
가끔은 누군가 괜찮은지 안부인사를 묻기도 한다.
 
2. Service
개인을 각 서비스로 또 상상해보자.
서비스가 동작하는 것은 누군가에게 어떠한 기능을 제공해주기 위해서 존재하기도 하지만 스스로의 목적을 추구하기도 한다.
누군가를 위해서 어떤 일을 해주기도 하고 혹은 누군가가 해주는 어떤 일을 받기도 해서 내가 원하는 바를 달성한다.
혼자서 모든일 을 처리할 수 없기 때문에 다양한 타인/조직, 물건,생물등 소통하는 것은 당연한 것이다.
 
3. Role
맡고 있는 역할과 책임이 존재한다. 
누군가의 스승, 누군가의 동료, 누군가의 배우자. 
각각의 역할에는 기대하는 바가 있고 그 기대하는 바가 적절히 충족되어야 상대방이 만족한다.
만약 그 기대하는 바가 완벽하게 충족되지 않는다면 스스로 방법을 찾아보거나 부족한 부분을 대신할 수 있는 다른 것을 찾게 된다.
 
4. Error / Fault / Failure
Error는 언제나 발생한다. 늦잠을 잘 수도 있고, 과식을 할 수도 있고, 물건을 놓칠 수도 있다.
Error가 가끔은 Fault로 연결된다. 지각을 하기도 하고, 소화가 안되고, 물건이 땅에 떨어진다. (놓쳐다가 잡으면 안떨어진거니까..)
그리고 이것들이 누적되면 Failure로 연결되며 우리는 타격을 입게 된다.
성적을 망친다던지, 앓아눕던지, 소중한 물건을 망가뜨리거나..
 
실수를 막기 위해서 시계알람을 울리거나, 미끄럼 방지스티커를 부착하는 것 같이 작은 안전장치가 큰 불이익을 막을 수 있다.
 
5. Waiting
전자제품이 고장났다. ->  AS센터에 전화를 한다. -> 전화를 안받는다. 받을 때까지 전화를 건다. ->
전화를 받았다. -> 담당AS기사를 확인해보고 10분뒤에 전화를 준다고 한다. -> 10분동안 전화를 기다린다. -> 전화가 다시 온다.
글로만 읽어도 답답하고 에너지소모가 많다.
 
요즘은
전자제품이 고장났다 -> App을 통해서 접수한다.  -> 내 할일 한다.
잠시 후 담당AS기사 방문일정이 알람으로 온다. -> 확인하고 다시 내 할일 한다.
 
물론 매우 중요한 일은 여전히 기다려야 한다. e.g) 인증, 결제 ARS
 

<정리>

우리의 이러한 생활을 관찰하다보면 Software Architecture에서의 해답점과 연결점을 많이 찾아낼 수 있다.

1. Protocol

- 주고 받는 메시지의 규약을 정하고, 그에 해당하는 메시지를 받았을 때 수행하는 동작을 서로 약속한다. (e.g HTTP, TCP/IP, Json 등)

- Health Check를 통해서 각 노드/서비스의 상태를 주기적으로 확인한다.

 
2. Component / Sequence

- 최종 얻기 위한 결과물을 위해서 필요한 구성요소를 정의하고 (Component)

- 어떠한 순서로 요청하여 받은 결과물을 활용할 것인지 그려본다. (Sequence)

3. Exception Catch / Retry / Side-car

- 명시적으로 일어날 수 있는 오류에 대해서는 사전에 처리를 하고 예방한다.

- 일시적인 오류에 대해서는 다시 시도해보고

- 보다 큰 오류로 전파되는 것을 미리 막아둔다. (나만 죽는게 낫다)

 
4. Async / Non-blocking / Timeout

- 반드시 모든 작업이 동시에 끝나야 할 필요는 없다. (Async)

- 오래 기다려야 하는 작업(내가 제어할 수 없는 일) 은 맡겨놓고 다른 작업을 한다. (Non-blocking)

- 완료되었다는 것을 인지하면 그 때 후속작업을 수행한다. (callback, future)

- 동시에 끝나야 하는 작업이 있을 수도 있고, 응답을 반드시 확인해야 하는 경우도 있다. (Sync)

- 언제까지 끝난다고 장담할 수 있는 일은 없다. 적절한 시점에는 포기해야 한다. (unbounded delay, timeout)
 

<참조>

https://johngrib.github.io/wiki/Conway-s-law/ 
https://wiki.wooridle.net/NatureOfOrder

1. Authorization Code

- 권한 부여 승인을 위해서 자체생성한 Authorization Code를 전달하는 방식

- 기본이 되는 방식

- Refresh Token 사용이 가능

2. Client Credentials

- 클라이언트의 자격증명만으로 Access Token을 획득하는 방식

- 가장 간단한 방식

- 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 함

- Refresh Token 사용 불가능

3. Implicit Grant

- 자격증명을 안전하게 저장하기 힘든 클라이언트에게 최적화된 방식

- Access Token이 바로 발급되기 때문에 만료기간을 짧게 설정할 필요가 있음

- Refresh Token 사용 불가능

4. Resource Owner Password Credentials Grant

- username, password로 Access Token을 받는 방식

- 클라이언트가 외부 프로그램일 경우 사용하면 안됨

- 권한서버, 리소스서버, 클라이언트가 모두 같은 시스템에 속해 있을때 사용해야 함 (대부분 비권장)

- 요청이 성공한 클라이언트는 메모리에서 자격증명을 폐기해야 함

- Refresh Token 사용 가능

<정리>

<참조>

- https://learn.microsoft.com/ko-kr/azure/active-directory/develop/v2-oauth2-auth-code-flow

- https://www.rfc-editor.org/rfc/rfc6749

<개요>

- Designing Data-Intensive Applications 를 읽고 그 중 분산시스템의 오류처리에 대한 부분 정리

https://icthuman.tistory.com/entry/The-Trouble-with-Distributed-Systems-1

<내용>

6. Timeouts and Unbounded Delays

- Timeout이 Fault를 감지하는 확실한 방법이라면 얼마로 설정해야 할까?

- Long timeout : Node가 죽었다는 것을 인지하기 위해서는 오래 기다려한다. (사용자는 기다리거나 에러메시지를 확인한다.)

- Short timeout : fault를 빠르게 감시할 수 있지만 잘못 인식할 있는 위험이 있다. (spike같이 일시적인 현상도 있기 때문에)

* 문제점

- 작업이 살아있고 수행하는 중이었는데 Node를 죽은 것으로 간주한다면, 작업이 종료되기 전에 다시 수행해서 중복 수행될 수 있다.

- 만약에 노드가 죽었다면 다른 노드에 이 사실을 전달해야하고 이것은 다른 노드나 네트워크에 추가적인 부하상황으로 이어질 수 있다.

  이미 시스템이 고부하상황이었고 노드가 죽었다고 잘못 판단할 경우 상황은 더 악화될 수 있다.

  특히 죽은 것이 아니라 overload로 인해서 응답이 지연되고 있었다면 (죽은게 아니었다면) 에러가 계속 전파되어서 모든 노드가 죽었다고 판단하면서 모든 작업이 멈춰버릴 수도 있는 극단의 상황도..

*아름다운 상상으로 접근 (fictitious system)

- 모든 패킷이 d 시간내에 전달된다고 하고, 살아있는 노드는 해당 request를 처리할때 r 시간내에 가능하다면 

- 모든 성공적인 request는 response time이 2d + r내로 들어올 것이고

- 해당 시간동안 응답을 받지 못한다면 network 나 node 가 동작하지 않는 것으로 간주할 수 있다.

- 그렇다면 2d + r 은 reasonable timeout 으로 사용할 수 있다.

*현실

- 불행하게도 대부분의 시스템은 이를 보장할 수가 없다.

- Asynchronous network 는 unbounded dealy를 가지고 있다.( 최대한 빨리 도착하도록 노력은 하지만.. upper limit이 존재하지 않는다는 점)

- 대부분의 서버 구현에서는 maximum time을 보장할 수가 없다. (Response time guarantees)

- Failure Detection을 위해서는 시스템이 빠르다는 것만으로는 충분하지 않다. Timeout이 너무 짧으면 위에서 살펴본것처럼 spike등이 발생하였을 때 system off-balance

* Network congestion and queueing

- 네트워크의 패킷 지연현상은 대부분 queueing 때문이다.

a. 여러 노드에서 동시에 한 곳으로 패킷을 보내면, 네트워크 스위치는 Queue에 채우고 Destination network link에 하나씩 넣어줘야 하는데, 패킷을 얻기 위해서 잠시 기다려야할 수도 있고 만약 Queue가 가득 차게되면 packet 이 drop되어서 다시 보내야한다.

b. 패킷이 Desination 머신에 도착했을 때 Cpu core가 모두 사용중이면 request처리준비를 할때까지 OS에서 queued된다.

c. 가상환경을 사용중이라면 OS가 종종 중지된다. 이 시간동안 VM은 network로부터 데이터를 소비할 수 없기 때문에 VM monitor에 의해서 queued (buffered) 된다.

d. TCP는 flow control을 수행하여 과부하를 방지하도록 속도를 제어하기도 한다. 또 TCP는 손실되는 패킷에 대해서 재전송을 해야하기 때문에 Delay를 두면서 timeout to expired 나 retransmitted packet을 기다린다.

(그래서 우리에게 이러한 기능이 필요없다면, 즉 유실방지,유량제어가 필요없고 지연된 데이터는 가치가 없는 상황이라면 UDP를 사용하는 것이 더 좋은 선택이 된다. 예를 들어서 VoIP call)

* 환경적인 문제

 Public Cloud 같이 여러 고객들이 같이 사용하는 네트워크 자원 (link, switch) ,각 NIC, CPU 등은 공유가 된다. 또 MapReduce같은 작업들은 병렬처리를 진행하면서 네트워크를 사용하기도 한다.

* 네트워크의 round trip시간의 분포를 적절하게 측정하여 예상되는 Delay 변동성을 결정하고,  Application의 특성을 고려하여 Failure detection delay  과  Risk of premature timeouts 간의 적절한 Trade Off를 결정할 수 있습니다.

* 더 좋은 방법은 상수값의 timeout보다는 Response time 과 Jitter를 지속적으로 측정하고 관찰된 응답시간의 분포에 따라서 Timeouts을 자동으로 조정하는 것입니다.

-  Phi Accrual failure detector (for example, Akka and Cassandra)

- TCP retransmission timeouts

<개요>

- Designing Data-Intensive Applications 를 읽고 그 중 분산시스템의 오류처리에 대한 부분 정리

- 언제나 늘 그렇듯이 새로운 개념이라기 보다는 얼마나 체계적으로 잘 정리해서 핵심을 간직하는가에 집중

<내용>

1. Faults and Partial Failures

- Single Computer에서 작업을 할 경우 same operation은 same result를 만들어낸다. (deterministic)

- 우리가 수 대의 컴퓨터에서 동작하는 소프트웨어를 개발할 때 (즉, 네트워크로 연결되어 있는 상태)는 이와는 다르다.

- 분산처리 시스템에서는 예측할 수 없니 특정 부분에서 문제가 발생하는 경우가 있는데 이를 partial failure 라고 부른다.

- partial failure의 어려운 점은 non-deterministic이라는 점이다. 여러 노드와 네트워크에 걸쳐서 무언가를 했을때 예상과는 다르게 성공하기도 하고 실패하기도 한다는 점인데 이러한 부분이 분산처리 시스템을 어렵게 만든다.

2. Building a Reliable System from Unreliable Components

- unreliable한 구성요소를 가지고 어떻게 하면 reliable한 시스템을 만들수 있을까? 몇 가지 아이디어를 소개한다.

a. error-correcting code를 가지고 어느부분이 오류가 발생했는지 체크하고 정확하게 전송할 수 있다.

b. TCP/IP : IP는 unreliable하다. 사라지거나 늦게 도착하거나 혹은 중복되거나.. 순서보장도 안된다. 여기에 TCP가 Transpory layer의 역할을 상위에서 해줌으로 사라진것은 다시 보내주고, 중복된것은 재거해주며, 발송순서에 맞게 재조립을 해준다.

물론 언제나 한계점은 존재한다. 데이터의 양이나, 혹은 네트워크 자체의 지연현상등은 커버하기 어렵다. 하지만 까다로운 일반적인 문제를 제거하고 나면 훨씬 쉬워지는것도 사실이다.

3. Unreliable Networks

- 분산처리에서는 shared-nothing구조를 유지하는 것이 일반적이다. 왜냐하면 다른 machine끼리는 네트워크로 연결이 되며 각자의 disk나 메모리등에는 접근할 수 없기 때문이다.

- 인터넷 환경에서 각 데이터 센터는 멀리 떨어져 있기 때문에 더욱 이러한 구조인데 대부분 비동기처리로 진행이 된다.(asynchronous packet networks)

- 메시지를 보내기는 하지만 언제 도착할지, 도착이 하기는 할지.. 보장할 수가 없다. 

* 이러한 문제를 처리하는 방법이 일반적으로 "Timeout" 이다. 기다리는 것을 포기하는 것이다.

수신 node가 받았는지, 메시지가 사라졌는지는 여전히 알 수 없지만...

4. Network Faults in Practice

- 위에서 살펴본것처럼 reliable한 시스템을 만드는 법은 완벽한것은 없다. (왜? 네트워크는 여전히 불안하기 때문에..)

- 결국 소프트웨어에서 이를 처리할 수 있도록 해야한다. (이것을 지속적으로 테스트하도록 만든 프레임워크가 바로 Chaos Monkey)

5. Detecting Faults

- Faults를 감지해야 이후의 처리를 할수 있으니 감지하는 법을 살펴보자.

- 불확실성을 통해서 작동여부를 판단하는 것은 어려우니, 거꾸로 특정상황에서 작동하지 않는다는 것을 명시적으로 알려주는 FeedBack !

 a. 대상 포트에서 수신 프로세스가 없는 경우 OS에서 RST 또는 FIN을 전송한다.

 b. 노드 프로세스가 죽었지만 OS가 여전히 실행중이면 script로 다른 노드에 알릴 수 있다. (e.g Hbase)

 c. 데이터 센터에서 NIC 관리 기능을 사용중이면 하드웨어 수준으로 감지 할 수 있다.

 d. 라우터가 해당 IP에 연결할 수 없다고 확신하면 ICMP destination unreachable 패킷으로 응답할 수 있다. 

- 이렇게 빠르게 feedback처리를 하면 매우 유용함을 알 수 있다. 하지만 이것도 역시 신뢰할 수는 없다! (네트워크이니까)

- 결국 request가 성공적으로 처리되었는지는 application레벨에서의 positive response를 받는 것이 필요하다.