Redis 연결오류 해결기 사건 배경 심기가 불편한 일요일 오후 서버는 울기 시작했다. “응애! 응애! Connection closed by server! 응애!” 서버의 웹훅 관련 캐시서버와의 연결이 끊어졌다는 오류들이었다. 웹훅을 수신하면 웹훅 캐시서버에 횟수를 기록하기 위한 작업이 이뤄지는데 이떄 서버로부터 연결이 끊겼다는 에러였다. Traceback 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 Traceback (most recent call last): File "/code/core/webhook/utils/webhook.py", line 156, in record_webhook_event redis_client.zadd(key, {member: score}) File "/usr/local/lib/python3.11/site-packages/redis/commands/core.py", line 4187, in zadd return self.execute_command("ZADD", name, *pieces, **options) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/ddtrace/contrib/redis/patch.py", line 148, in _traced_execute_command return _run_redis_command(span=span, func=func, args=args, kwargs=kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/ddtrace/contrib/redis/patch.py", line 128, in _run_redis_command result = func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 559, in execute_command return self._execute_command(*args, **options) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 567, in _execute_command return conn.retry.call_with_retry( ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/retry.py", line 65, in call_with_retry fail(error) File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 571, in <lambda> lambda error: self._disconnect_raise(conn, error), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 555, in _disconnect_raise raise error File "/usr/local/lib/python3.11/site-packages/redis/retry.py", line 62, in call_with_retry return do() ^^^^ File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 568, in <lambda> lambda: self._send_command_parse_response( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 542, in _send_command_parse_response return self.parse_response(conn, command_name, **options) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 584, in parse_response response = connection.read_response() ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 592, in read_response response = self._parser.read_response(disable_decoding=disable_decoding) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/_parsers/resp2.py", line 15, in read_response result = self._read_response(disable_decoding=disable_decoding) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/_parsers/resp2.py", line 25, in _read_response raw = self._buffer.readline() ^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/redis/_parsers/socket.py", line 115, in readline self._read_from_socket() File "/usr/local/lib/python3.11/site-packages/redis/_parsers/socket.py", line 68, in _read_from_socket raise ConnectionError(SERVER_CLOSED_CONNECTION_ERROR) redis.exceptions.ConnectionError: Connection closed by server. 웹훅 오류에 발작버튼이 달려있는 나는 황급히 웹훅 캐시 지표를 확인했다. ...

07-1 다양한 보조 기억 장치 하드 디스크 하드 디스크(Hard Disk Drive) 자기 디스크(magnetic disk) 자기적인 방식으로 데이터를 저장하는 보조 기억 장치 구성요소 플래터(platter): 하드 디스크에서 실질적으로 데이터가 저장되는 곳 트랙(track): 플래터를 여러 동심원으로 나누었을 때 그중 하나의 원 섹터(sector): 트랙을 나눈 한 조각 블록(block): 다수의 섹터 묶음 실린더(cylinder): 여러 겹의 플래터 상에서 같은 트랙이 위치한 곳을 모아 연결한 논리적 단위 연속된 정보는 보통 한 실린더에 기록 스핀들(spindle): 플래터를 회전시키는 구성 요소 RPM(Revolution Per Minute): 플래터가 돌아가는 분당 회전수 헤드(head): 플래터를 대상으로 데이터를 읽고 쓰는 구성 요소 디스크 암(disk arm): 헤드를 원하는 위치로 이동시키는 부품 접근 과정 탐색 시간(seek time): 접근하려는 데이터가 저장된 트랙까지 헤드를 이동시키는 시간 **다중 헤드 디스크(multiple-head disk)**에선 소요되지 않는 시간 다중 헤드 디스크 = 고정 헤드 디스크(fixed-head disk) 회전 지연(rotational latency): 헤드가 있는 곳으로 플래터를 회전시키는 시간 전송 시간(transfer time): 하드 디스크와 컴퓨터 간에 데이터를 전송하는 시간 하드 디스크가 데이터에 접근하는 시간 = 탐색 시간 + 회전 지연 + 전송 시간 컴퓨터 내 소요 시간(ns = 10^-9) 내용 소요 시간 L1 캐시 참조 시간 0.5ns L2 캐시 참조 시간 5ns 메모리 참조 시간 7ns 메모리에서 1MB를 순차적으로 읽는 시간 250,000ns 하드 디스크 탐색 시간 10,000,000ns 하드 디스크에서 1MB를 순차적으로 읽는 시간 30,000,000ns 한 패킷이 캘리포니아에서 네덜란드까지 왕복하는 시간 150,000,000ns 플래시 메모리 플래시 메모리(flash memory): 전기적으로 데이터를 읽고 쓸 수 있는 반도체 기반의 저장 장치 ...

이기적 유전자 지은이: 리처드 도킨스 옮긴이: 양억관 출판사: 민음사 감상 오래전부터 들어온 과학 교양 서적이라 읽어 보았다. 나름 일반 생물학까지는 공부해본 사람으로서 교양서적이 얼마나 어렵겠냐 싶었지만 상당히 어려웠다. 우리가 흔히 ‘유전자는 인간의 몸에 대한 설계서다’라는 생각을 돌려서, 유전자가 본체이고 각 생명(개체)는 유전자를 전파하기 위한 생체 기계일 뿐이라는 이야기들의 반복이다. 이를 뒷받침하기 위한 저자의 설명들이 계속 된다. 어떤 생물이 본능적으로 하는 그 행동이 왜 유전자를 전파하기 위한 행동인가에 대한 내용. 너무 어렵고, 너무 방대하다. 추천하지는 않는 책 ...

06-1 RAM의 특징과 종류 RAM의 특징 실행할 프로그램의 명령어와 데이터가 저장 휘발성 저장 장치(volatile memory) 전원을 끄면 저장된 명령어와 데이터가 사라짐 CPU가 실행할 대상을 저장 비휘발성 저장 장치(non-volatile memory) 전원을 꺼도 저장된 내용을 유지. 하드 디스크, USB 같은 보조기억장치 CPU는 보조기억장치에 접근하지 못함 RAM의 용량과 성능 RAM 용량이 크면 실행할 프로그램을 많이 저장할 수 있음. 따라서 동시에 여러 프로그램을 빠르게 처리할 수 있음 RAM의 종류 DRAM Dynamic RAM 시간이 지나면 저장된 데이터가 점차 사라짐 따라서 일정 주기로 데이터를 재활성화(다시 저장)해야 함 소비 전력이 낮고, 저렴하고, 집적도가 높아 대용량으로 설계하기 용이함 SRAM Static RAM 시간이 지나도 데이터가 사라지지 않음 소비 전력이 높고, 비싸고, 집적도가 낮음 캐시 메모리등에 사용 정확히는 CPU 내부의 캐시 메모리에서 사용한다. SRAM은 데이터 재활성화가 필요없어 액세스 속도가 매우 빠르다. CPU의 캐시 용량은 메인 메모리(16GB, 32GB, …)에 비해선 여전히 작음(수십 MB) SDRAM Synchronous Dynamic RAM 또는 SDR SDRAM(Single Data Rate SDRAM) 클럭 신호와 동기화된, 발전도니 형태의 DRAM 클럭 타이밍에 맞춰 CPU와 정보를 주고 받을 수 있음 클럭 타이밍을 맞추는게 중요한 이유 정확히는 데이터 전송의 타이밍을 CPU의 동작 속도(시스템 쿨럭)과 맞춘다는 의미임 DRAM등 에서는 데이터를 언제 줄지 몰라 유휴시간이 존재하는 등 비효율성이 발생했음 SDRAM은 클럭에 맞춰 오기떄문에 정확한 타이밍을 위해 준비할 수 있음 클럭속도? 클럭속도는 시스템 전체가 공유하는 기본 타이밍 신호임 여러 종류가 있으나 CPU와 RAM은 주로 시스템 클럭(System Clock) 기반의 신호들을 공유 시스템 클럭은 메인보드에 있는 클럭 제너레이터(Clock Generator)에서 생성됨 이게 CPU, RAM, 칩셋에게 공유 오버클럭등을 이용해 클럭신호는 바뀔수 있음 CPU와 SDRAM은 클럭 제너레이터가 만드는 클럭 신호를 기반으로 같은 타이밍에 통신함 DDR SDRAM Double Date Rate SDRAM **대역폭(data rate)**을 넓혀 속도를 빠르게 만든 SDRAM 대역폭: 데이터를 주고 받는 길의 너비 DDR2(2배), DDR3(4배), … 질문 SDRAM이 클럭 을 따지는게 뭔상관이지 어차피 CPU랑 주고받는데? 정확히는 데이터 전송의 타이밍을 CPU의 동작 속도(시스템 쿨럭)과 맞춘다. 기존에는 데이터를 언제 줄지 몰라 유휴시간이 존재하는 등 비효율성 발생했음 SDRAM은 클럭에 맞춰 오기떄문에 정확한 타이밍을 위해 준비할 수 있음 클럭속도는 시스템전체가 공유하나? SDRAM이 어떻게알지? 이건 안변하나? 클럭속도는 시스템 전체가 공유하는 기본 타이밍 신호 여러 종류가 있으나 CPU와 RAM은 주로 시스템 클럭(System Clock) 기반의 신호들을 공유 시스템 클럭은 메인보드에 있는 클럭 제너레이터(Clock Generator)에서 생성됨. 이게 CPU, RAM, 칩셋에게 공유 오버클럭등을 이용해 클럭신호는 바뀔수 있음 캐시도 이제 용량이 커서 몇기가씩 되는데 그래도 SRAM을 쓰나? 정확히는 CPU 내부의 캐시 메모리에서 사용한다. SRAM은 데이터 재활성화가 필요없어 액세스 속도가 매우 빠르다. CPU의 캐시 용량은 메인 메모리(16GB, 32GB, …)에 비해선 여전히 작음(수십 MB) 06-2 메모리의 주소 공간 물리 주소: 메모리 하드웨어가 사용하는 주소 ...

업스트림(Upstream)과 다운스트림(Downstream) 1. 기본 정의 : 흐르는 강물(Stream) 이 용어는 데이터와 요청의 흐름을 강물에 비유한 것 업스트림 (Upstream, 상류): 데이터(물)의 원천이 되는 곳 다운스트림 (Downstream, 하류): 데이터(물)를 받아서 소비하는 곳 흐름의 법칙 데이터(응답): 상류 → 하류 (위에서 아래로 흐름) 요청(Request): 하류 → 상류 (거슬러 올라감) 2. 핵심 개념 : “위치는 상대적이다” 업스트림과 다운스트림은 절대적인 역할이 고정된 것이 아님 “누구를 기준(주체)으로 보느냐"에 따라 달라지는 상대적인 개념 전체 흐름이 다음과 같을 때를 가정 ...

05-1 빠른 CPU를 위한 설계 기법 클럭 컴퓨터 부품들은 ‘클럭 신호’에 맞춰 일사불란하게 움직인다. CPU는 ‘명령어 사이클’이라는 정해진 흐름에 맞춰 명령어들을 실행한다. 클럭 속도: 헤르츠(Hz) 단위로 측정. 초당 반복되는 횟수 오버클럭킹(overclocking): CPU의 최대 클럭 속도를 강제로 더 끌어올림 코어와 멀티코어 기존의 CPU: 전통적인 관점에서는 ‘명령어를 실행하는 부품’ 하나 ⇒ 현재는 코어(Core) 현재의 CPU: 여러 개의 코어를 포함하는 부품 ⇒ 멀티코어 CPU(multi-core CPU), 멀티코어 프로세서 스레드와 멀티스레드 스레드(thread) 사전적 정의: 실행 흐름의 단위 하드웨어적 스레드: 하나의 코어가 동시에 처리하는 명령어의 단위 소프트웨어적 스레드: 하나의 프로그램에서 독립적으로 실행되는 단위 하드웨어적 스레드 이하 하드웨어 스레드 하나의 코어가 동시에 처리하는 명렁어 단위 하나의 코어에 스레드가 많으면 동시에 여러 명령어를 처리할 수 있음 멀티스레드(multithread) 프로세서, 멀티스레드 CPU 하이퍼스레딩(hyper-threading) in Intel 메모리 속 프로그램의 입장에선 각 하드웨어 스레드는 CPU로 보임(하나의 명령어를 처리하니까) 따라서 **논리 프로세서(logical processor)**라고 부름 소프트웨어적 스레드 이하 스레드 하나의 프로그램에서 독립적으로 실행되는 단위 프로그래밍 언어, 운영체제에서 이야기하는 스레드 한 프로그램에서 여러 부분이 동시에 실행될 수 있다. ex) 워드 프로세서 입력받은 내용 화면 출력 맞춤법 검사 상시 저장 멀티스레드 프로세서 멀티스레드 프로세서: 레지스터 세트(프로그램 카운터, 스택 포인터, MBR, MAR 등)를 여러 개 가지면 된다. ...

프로 개발자(?)가 된지 어느덧 2년이 되었다. 마침 입사가 11월이라 올 한해를 되돌아보는 회고를 하기에도 알맞은 때라고 느껴진다. 올 한해 나는 어땠는지, 개발자로서 두번째 해를 곱씹어보려고 한다. 첫 해는 어땠을까? 작년 9월에 쓴 글을 보았다. 나는 능동적인 노력이 부족한 사람이라고 자평했지만, 분명 노력하고 있었다. 끊임없이 새로운 서비스를 만들어내고 있었고, 매번 이전의 문제점과 아쉬운 점을 개선하기 위해 노력했다. 마지막에 만들었던 인스타그램 관련 서비스는 가끔 코드를 보면 1년차 혼자 만든 것 치고 꽤 괜찮아보인다. 물론 고칠 곳도 투성이긴 하지만.. ...

안녕하세요. 배준수입니다. 먹고 사는게 바쁘다는 핑계로 꽤 오래 방치해뒀던 블로그를 오랜만에 좀 손봤습니다. 이 블로그를 개선하려면 jekyll, ruby, liquid에 대한 이해가 필요한데 이 부분을 공부할 여력이 없었습니다. 특히 제가 취약한 CSS는 말할 것도 없구요.. 이미 현업에 대한 공부로도 벅찹니다. 다행히 AI가 정말 많이 발전해서 이젠 지식이 전혀 없어도 원하는 것을 다 반영할 수 있게 되었습니다. 추가적으로, 이전처럼 매일 하루의 TIL을 올리긴 어렵습니다. 제 작업들이 하루 이틀에 끝날 정도로 작지 않은 경우가 많고, 이제 모르는 것보단 이미 알고 있는 것에 대한 작업물이 훨씬 많으며 나름 2년차가 된 만큼, 글의 퀄리티가 더 높아져야 한다고 생각하기 때문입니다. 따라서 최근(?)에 Step Functions를 이용한 웹훅 처리 글이 그만큼 길었습니다. 앞으로는 못해도 1달에 한번, 가능하면 일주일에 한번이라도 올리기 위해 노력하겠습니다. 헤더 크기 축소로 첫 화면에서 컨텐츠의 영역 크기를 늘렸습니다. 사이드바를 개선하였습니다. 각 페이지에 검색기능을 생성하고, 게시글 1개의 크기를 줄였습니다. 아카이브 페이지를 개선하고 검색기능을 추가하였습니다. about 페이지 내 컨텐츠를 개선했습니다. 더 자주 찾아오겠습니다! 안녕~ ...

4장 CPU의 작동 원리 04-1 ALU와 제어장치 CPU의 구성 ALU: 계산을 담당 제어장치: 명령어를 읽어 들이고 해석 레지스터: 작은 임시 저장 장치 ALU Input 피연산자: 레지스터를 통해 받는 연산의 대상 제어 신호: 수행할 연산에 대한 정보 Output 계산 결괏값, 플래그 연산 수행의 결과는 특정 데이터일 수도, 메모리 주소가 될 수 있다. 결괏값은 바로 메모리에 저장되지 않고 일시적으로 레지스터에 저장 CPU가 메모리에 접근하는 속도 < CPU가 레지스터에 접근하는 속도 플래그(flag) 연산 결과에 대한 추가적인 정보 부호 플래그, 제로 플래그, 캐리 플래그 등 플래그 레지스터에 저장 오버플로우(overflow): 연산결과가 연산을 담을 레지스터보다 큰 상황 제어장치 제어 신호를 내보내고, 명령어를 해석하는 부품 제어신호: 컴퓨터 부품들을 관리하고 작동시키기 위한 일종의 전기 신호 Input 클럭 신호 클럭(clock): 컴퓨터의 모든 부품을 움직이는 시간 단위 컴퓨터의 모든 부품은 클럭 신호에 맞춰 작동 하지만 모든 부품이 한 클럭마다 작동하는 것은 아님 해석해야 할 명령어 명령어 레지스터에 저장된 명령어 명령어를 받아 해석한 뒤, 제어 신호를 발생시켜 컴퓨터 부품들에 수행해야할 내용을 전달 플래그 레지스터 속 플래그 값 ALU 연산에 대한 추가적인 상태 정보 제어버스로 전달된 제어 신호 입출력장치를 비롯한 CPU 외부 장치가 발생시킨 제어 신호도 포함 Output CPU 외부에 전달하는 제어 신호 입출력장치: 입출력장치의 값을 읽거나 새로운 값을 쓸 때 메모리: 메모리에 저장된 값을 읽거나 새로운 값을 쓸 때 CPU 내부에 전달하는 제어 신호 ALU: 수행할 연산을 지시하기 위해 레지스터: 레지스터 간에 데이터롤 이동시키거나 저장된 명령어를 해석하기 위해 04-2 레지스터 반드시 알아야 할 레지스터 많은 CPU가 공통으로 포함하는 레지스터들 ...

3장 명령어 03-1 소스 코드와 명령어 고급 언어와 저급 언어 고급 언어(high-level programming language): 사람을 위한 언어 Python, C, Java, … 저급 언어(low-level programming language): 컴퓨터가 직접 이해하고 실행할 수 있는 언어 기계어(machine code): 0과 1의 명령어 비트로 이루어진 언어 어셈블리어(assembly lanaguage): 기계어를 읽기 편한 형태로 번역한 언어 고급 언어로 작성된 소스 코드가 실행되려면 저급 언어(명령어)로 변환되어야 함 컴파일 언어와 인터프리터 언어 컴파일 언어 컴파일러에 의해 소스 코드 전체가 저급 언어로 변환되어 실행되는 고급 언어 ex) C 컴파일(compile): 컴파일 언어로 작성된 소스 코드의 전체가 저급 언어로 변환되는 과정 컴파일러(compiler): 컴파일을 수행해 주는 도구 컴파일러가 소스 코드 내에서 오류를 하나라도 발견하면 컴파일에 실패 목적 코드(object code): 컴파일러를 통해 저급 언어로 변환된 코드 목적 파일: 목적 코드로 이루어진 파일 컴파일러는 소스코드를 컴파일하여 목적 코드를 생성한다. 목적 코드는 컴퓨터가 이해하고 실행할 수 있는 저급 언어라 빠름 인터프리티 언어 인터프리터에 의해 소스 코드가 한 줄씩 실행되는 고급 언어 ex) Python 한 줄씩 저급 언어로 변환하여 실행 인터프리터(interpreter): 한 줄씩 실행하는 도구 소스 코드 전체를 저급 언어로 변환하는 시간을 기다릴 필요가 없음 한 줄씩 실행되어 오류가 발견되기 전까지는 올바르게 수행 한 줄씩 저급언어로 해석하며 실행하여 느림 둘은 명확히 분리된 개념이 아니라 둘 모두에 속하는 언어도 존재함 링킹(linking) 컴파일된 목적파일에서 사용하는 기능을 연결 목적 코드 ≠ 실행 파일 어떤 목적파일에서 실행하는 기능이 다른 목적파일에 있다면 두 목적 파일을 연결해야 한다. 03-2 명령어의 구조 연산 코드와 오퍼랜드 명령어 = 연산 코드 + 오퍼랜드 연산 코드(operation code, 연산자): 명령어가 수행할 연산 연산 코드 필드: 연산 코드가 담기는 영역 오퍼랜드(operand, 피연산자): 연산에 사용할 데이터 또는 데이터가 저장된 주소 오퍼랜드 필드(주소 필드): 오퍼랜드가 담기는 필드 오퍼랜드 N-주소 명령어: 오퍼랜드 N개 (0개 이상) 연산 코드 데이터 전송, 산술/논리 연산, 제어 흐름 변경, 입출력 제어 등 주소 지정 방식 오퍼랜드에 데이터를 담을 경우: 오퍼랜드에 할당된 크기 만큼만 데이터를 처리 가능 ex) n비트 명령어에 m비트가 연산 코드 필드라면, 오퍼랜드에 담는 데이터의 가짓수는 2^(n-m) 뿐 주소를 담으면 주소의 크기만큼 처리 가능한 데이터의 가짓수가 증가 ex) 오퍼랜드에 한 주소에 16비트를 저장하는 메모리의 주소를 담으면 데이터 가짓수는 2^16 유효 주소(effective address): 연산의 대상이 되는 데이터가 저장된 위치 주소 지정 방식(addressing mode): 연산에 사용할 데이터 위치를 찾는 방법 즉, 유효 주소 찾는 방법 CPU 외부에 있는 메모리에 접근하는 것보다 CPU 내부에 있는 레지스터에 접근하는 것이 더 빠름 즉시 주소 지정 방식 immediate addressing mode 연산에 사용할 데이터를 오퍼랜드 필드에 직접 명시 빠르지만, 표현할 수 있는 데이터의 크기가 작음 직접 주소 지정 방식 direct addressing mode 오퍼랜드 필드에 유효 주소를 직접 명시 오퍼랜드 필드의 길이만큼 표현할 수 있는 주소의 크기가 작아짐 간접 주소 지정 방식 indirect addressing mode 오퍼랜드 필드에 유효 주소의 주소를 명시 표현할 수 있는 유효 주소의 범위는 넓어짐 메모리 접근이 2번 필요하여 느림 레지스터 주소 지정 방식 register addresing mode 연산에 사용할 데이터를 저장한 레지스터를 오퍼랜드 필드에 직접 명시 직접 주소 지정 방식보다 빠름(레지스터 읽기의 속도 > 메모리 읽기의 속도) 레지스터 간접 주소 지정 방식 register indirect addressing mode 연산에 사용할 데이터를 메모리에 저장 그 유효 주소를 저장한 레지스터를 오퍼랜드 필드에 저장 레지스터 접근 + 메모리 1회 접근이라 간접 주소 지정 방식보다 빠름 스택과 큐 스택 스택(stack): LIFO(Last In First Out) 자료구조 PUSH(데이터 저장), POP(데이터 추출) 큐 큐(queue): FIFO(First In First Out) 자료구조