Flink State vs 외부 저장소를 활용한 값 관리: 어떤 선택이 더 합리적일까?

개요

실시간 데이터 처리 파이프라인에서 흔히 등장하는 과제 중 하나는 “사용자 피로도, Aggregation등” 값 관리입니다.
예를 들어, 마케팅 알림이나 이벤트 푸시 발송 시스템에서 동일 사용자에게 너무 많은 알림이 전달되지 않도록 시간/횟수 기반 제약을 두어야 할 필요도 있고, 일정 시간내의 이벤트 Aggregation등의 처리가 필요한 경우도 있습니다.
 
이를 구현하는 방법은 크게 두 가지로 나눌 수 있습니다.

1. Flink State를 통한 관리
2. Redis 등 외부 저장소를 통한 관리

 실제 운영 환경에서 이 두 가지 접근법을 모두 검토했으며, 각 방식의 장단점과 보완 방법을 정리해 보았습니다.
 

Flink State 기반 관리

동작 방식

• Flink의 KeyedProcessFunction 또는 RichFlatMapFunction에서 ValueState, ListState, MapState 등을 활용.
• 사용자별 키(userId)로 state를 유지하고, 이벤트 처리 시 조건을 체크.
• checkpoint/restore 메커니즘을 통해 exactly-once 보장 가능.

장점

• 일관성 보장: Flink state는 checkpoint와 함께 관리되어 장애 상황에서도 데이터 유실 최소화.
• 처리 성능 최적화: 외부 호출 없이 JVM 내부 메모리/로컬 RocksDB로 state 접근 → 지연(latency) 최소화.
• 운영 단순화: 외부 저장소 장애와 무관하게 파이프라인 내에서 관리 가능.

단점

• 확장성 한계: State 크기가 커질수록 checkpoint 부하가 증가.
• 비즈니스 연계성 부족: 파이프라인 외부 서비스(예: CRM, 백오피스)에서 동일 피로도 정책 확인 어려움.
• 운영 가시성 부족: state는 Flink 내부에 있어 모니터링/조회가 불편.
• 복원 불안정 : Operator나 내부 Class등의 변경이 생길경우 복원이 정상적으로 되지 않음

보완 방법

• TTL(State Time-to-Live)을 활용해 불필요한 state 자동 정리.
• State backend(RocksDB) 튜닝으로 대규모 데이터 관리 가능.
• 필요 시 side-output 등으로 state snapshot을 외부 DB로 export하여 조회용 데이터 구축.

외부 저장소(Redis 등) 기반 관리

동작 방식

• 이벤트 처리 시 Redis에 사용자별 카운터 / 타임스탬프를 저장.
• 피로도 체크 시 Redis 조회 → 조건 충족 시 이벤트 처리, 아니면 drop.
• Redis의 INCR, EXPIRE 등을 활용하여 TTL 기반 제어 가능.

장점

• 외부 접근성 우수: CRM, 백오피스, API 등 다양한 외부 시스템에서 즉시 참조 가능.
• 운영 유연성: Redis 데이터만 보면 전체 상태 확인 가능.  (Prefix 를 이용, 전체 Keys는 운영중 절대 안됨!)
• 확장성: Redis Cluster 등으로 수평 확장 가능.
• 안정성 : Flink App의 재부팅 / 결함으로부터 자유로움

단점

• 일관성 취약: Flink 처리 중 실패/재처리 시 Redis 값이 중복 증가할 수 있음.
• 성능 부담: 외부 I/O 호출로 인해 latency 증가 가능.
• 운영 복잡성: Redis 장애 시 파이프라인도 영향 받을 수 있음.

보완 방법

• 원자적 연산(GET+INCR) 사용 및 Lua Script 기반 트랜잭션 처리.
• 배치 보정 파이프라인: 하루/주 단위로 Redis 카운트를 원천 이벤트 로그와 맞추어 정합성 보정.
• 모니터링/알림 : Redis Replica/Cluster 구성을 통한 가용성 확보

보관하는 값의 종류에 따른 차이점

운영 중 겪었던 문제

처음에는 모든  데이터를 Flink state로 관리하려 했습니다.
하지만 장애 복구 시 state 복원 크기가 커지면서 문제가 발생했습니다.

• 복원 사례: 수십 GB 단위 state를 가진 잡이 재시작될 때→ 그동안 KPU(Flink 작업 슬롯)를 넉넉하게 늘려야만 안정적인 복구 가능
• → 운영 비용과 복잡성이 증가
• → Checkpoint restore 시간이 수십 분 이상 소요

이 경험을 통해 모든 값을 state에 넣는 건 정답이 아님을 깨달았습니다.
 

State로 관리하면 좋은 값들

State는 Flink의 강력한 무기입니다. 특히 **“스트림 내에서 바로 계산되는 값”**에는 최적화되어 있습니다.

• 누적 값 (counters): 예) 특정 키(userId)의 이벤트 누적 개수
• 평균/합/통계치 (aggregation): 예) 지난 5분간 클릭률 평균
• 세션/윈도우 기반 임시 상태: 예) 10분 세션 동안 발생한 이벤트 패턴
• 비교적 작은 사이즈의 데이터: 예) 단일 사용자 최근 5개 이벤트 저장

➡️ 이런 값들은 Flink checkpoint/restore와 exactly-once 보장이 잘 맞아떨어집니다.
 

외부 저장소로 관리하면 좋은 값들

반면, **“외부에서 참조가 필요하거나, 중복 증가가 치명적이지 않은 값”**은 Redis 같은 외부 저장소가 더 적합합니다.

• Fatigue (발송 제약):→ CRM/운영툴에서 실시간 확인 가능
  • 중복으로 값이 과증가해도 보수적으로 동작 (안 보내는 쪽으로 기울어 안전)
• 장기 보존이 필요한 값:→ Redis/DB에 두면 조회와 보정(batch pipeline) 용이
  • Flink state에 두면 checkpoint 부하 ↑
• 운영 가시성이 중요한 값:
  • 운영자가 즉시 확인하고 조정해야 하는 데이터 (예: 사용자별 발송 제한 카운터)

➡️ 이런 값들은 Flink state보다 외부 저장소 + 보정 파이프라인이 더 안정적입니다
 

결론 및 선택 가이드

• Flink State 중심 전략: 성능과 일관성이 가장 중요할 때 선택.
  • 알림 피로도 관리가 파이프라인 내부 로직에 국한되고, 외부에서 별도 조회 필요성이 적을 경우 적합.
• Redis 중심 전략: 운영 가시성, 보수적 동작, 외부 연계성
  • 단, 재처리/중복 처리 리스크를 줄이기 위한 보완책이 필수.

맺음말

결국, fatigue 관리의 초점이 “실시간 정확성”인지 “운영 편의성”인지에 따라 선택지가 달라집니다.
저의 고민과 정리를 바탕으로, 비슷한 고민을 하고 계신 분들께 도움이 되길 바랍니다.

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