no image
Elasticsearch 시작하기 (2)
이번에는 Elasticsearch Mapping에 대해 알아보자 먼저 classes라는 인덱스를 생성해주자curl -XPUT 'http://localhost:9200/classes'생성 이후 GET 메서드로 조회를 해보면 아래와 같이 'mappings' 필드가 비어있는 것을 볼 수 있다. Mapping은 데이터베이스의 스키마와 같다. 직접 매핑을 설정해주지 않아도 Elasticsearch에 저장하는 것은 무리가 없지만 추후에 Kibana를 활용해 데이터를 시각화 할 때 날짜를 문자로 인식할 수 있는 에러를 방지하기 위해 Mapping은 필수다. Mapping 정보는 아래와 같고 미리 mapping.json 파일에 저장해두자{ "properties": { "title": { "type": ..
2025.01.30
no image
Elasticsearch 시작하기 (1)
설날 이후 System Engineer 면접이 있어서 ELK 스택에 대해 공부해보려고 한다. ELK 스택이란 Elasticsearch, Logstash, Kibana의 세 가지 인기 있는 프로젝트로 구성된 스택을 의미하는 약어이다. 실행 환경 : Oracle VM (Ubuntu 20.04)참고 : https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started.html Index and search data using Elasticsearch APIs | Elasticsearch Guide [8.17] | ElasticDeleting an index permanently deletes its documents, shards, ..
2025.01.26
no image
OSI 7 Layer 3편 -Transport Layer
이전 Network Layer에서는 다음과 같은 문제가 있었다. 1. 한 번에 하나의 통신만 가능 -> 여러 어플리케이션이 동시에 통신 불가능 (카톡, 유튜브, 인터넷)2. 패킷등의 순서 보장 / 유실에 대한 대응 불가능 해당 문제를 해결하기 위해 전송 계층이 활용된다. Transport Layer- 통신 주체끼리 데이터 전달의 신뢰성을 확보하는 방법을 정의- 주요 단위 : 세그먼트- 주요 구성 요소 : TCP/UDP TCP(Transmission Control Protocol)- 패킷의 전달 과정에서 순서를 보장하고 유실되지 않도록 보장할 수 있는 통신 규약 -> 패킷 안에 세그먼트를 담아 주고 받아 로직을 처리- 연결 지향 -> 지속적으로 채널을 수립하여 전달 여부를 확인하고 무결성을 확인     지..
2024.09.26
no image
OSI 7 Layer 2편 -Network Layer
이전 1편에서 같은 로컬 네트워크 클라이언트 끼리의 통신 과정을 알아봤다. 같은 로컬 네트워크가 아닌 다른 로컬 네트워크로의 통신은 어떻게 진행되는지 알아보자.   네트워크 계층(Network Layer) - 여러 노드의 경로를 찾고 올바르게 전달될 수 있는 기능과 수단을 정의- 주요 단위 : 패킷- 주요 구성 요소 : Router, IP, ARP- 서로 떨어진 Local Network 간의 통신을 지원   먼저 통신을 하려면 목적지의 주소를 알아야 한다. 인터넷 세계에서는 IP를 주소로 사용한다.IP (Internet Protocol)- 인터넷 프로토콜 상에서 통신 주체를 식별하기 위한 아이디- 두 가지 종류 (IPv4, IPv6) CIDR (Classless Inter Domain Routing)- ..
2024.09.26
no image
OSI 7 Layer 1편 -Physical/Data Link Layer
OSI 7계층- 컴퓨터 네트워크 및 통신을 7개의 레이어로 표현한 모델- 하위 계층의 기능을 활용해 역할을 수행하고 상위 계층으로 처리 결과를 전달- 각 계층이 독립적으로 설계되므로, 특정 계층의 변경이 다른 계층에 영향을 미치지 않음  Physical Layer - 장치를 연결하기 위한 매체의 물리적인 사항- 전압, 주기, 시간, 전선의 규격, 거리 등- 단위 Bits- 대표 구성 요소 : 케이블, 안테나, 허브, 리피터 - 여러 Client 끼리의 1:1 통신은 위 그림처럼 Client 가 많아질수록 복잡해짐 허브 - 피지컬 계층에서 다수의 기기들을 연결해주는 장치- 허브는 스위치 처럼 똑똑하지 않아서 다음과 같은 특징을 가짐 1. 누구에게 전송하든 모두에게 전송됨 (Broad Cast)2. 충돌 감..
2024.09.24
no image
리눅스 주요 디렉토리 구조
리눅스의 주요 디렉토리 리눅스 디렉토리의 구조는 배포판마다 다소 다르다. 대부분의 대표적인 디렉토리를 알아보자. FHS(Filesystem Hierarchy Standard) 표준 사양을 따른다.  /bin 일반 사용자 및 관리자가 사용하는 명령어의 실행 파일이 배치되어 있는 디렉터리. 주로 시스템과 관련된 중요도가 높은 명령어를 포함 /dev 디바이스 파일(디스크, 키보드 등 하드웨어를 다루기 위한)이 배치되어 있는 디렉토리 /home 사용자별로 할당되는 개인용 홈 디렉터리가 배치되는 디렉터리, 사용자 이름이 디렉터리 이름으로 사용됨 /sbin /bin와 비슷하게 실행 파일을 포함하는 디렉터리, 관리자용 명령어가 포함됨(ex : shutdown) /tmp 임시 파일이 들어 있는 디렉터리, 애플리케이션 ..
2024.08.27
no image
IAM 이란
IAM 이란AWS Identity and Access Management는 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스 입니다.IAM을 사용하면 사용자가 액세스할 수 있는 권한을 관리할 수 있습니다. IAM은 리전(서울, 미국, 일본 등)에 속하는 서비스가 아닌 글로벌 서비스 입니다. 루트 계정은 최초 생성 이후 가능하면 사용하지 말 것, IAM계정의 사용자는 필요한 최소한의 권한만 부여(최소권한의 원칙) 사용자(User)- 개인 또는 애플리케이션을 위한 용도- 특정 권한을 가진 ID (ex: EC2 FullAccess, Administrator)- AWS 전반에 IAM 사용자를 특별하게 식별할 필요가 있는 경우 ARN(Amazon Resource Number)을 사용합니다. 일반적..
2024.08.22
AWS
no image
운영 체제란
운영 체제  운영 체제는 시스템 소프트웨어로 컴퓨터 하드웨어와 소프트웨어 리소스를 관리하고 컴퓨터 프로그램에 서비스를 제공한다.간단히 컴퓨터 하드웨어와 유저의 브릿지 역할을 한다. 운영 체제 타입 1. DeskTop Operating Systems : Microsoft Windows, macOs, Linux, Ubuntu2. Server Operating Systems : Windows Server, Linux distributions (CentOs, Red Hat)3. Mobile Operating Systems : Android, iOS, Windows Mobile4. Embedded Operating Systems : smart TV, automobiles etc.5. Real-Time Operat..
2024.08.20
no image
제조업 전산실 취업 후기
[머리말] 이 글은 개발자를 준비하면서 흘러 흘러 전산실에 취업하게 된 나의 이야기를 써 보려고 한다. 전산실 업무가 궁금한 사람에게 도움이 될 수도 있고 미래에 내가 이 당시 어떠한 생각을 했었는지 기억할 수 있게 기록으로 남기고 싶다. [수료 이후 취업 준비] 2024년 1월 31일에 야놀자 백엔드 부트캠프를 수료했다. 수료하기 이전부터 수강생들은 다들 분주하게 취업 준비를 하였지만 나는 수료 이후부터 지원서를 돌리기 시작했다. 2월부터 사람인, 잡코리아 서울, 경기 소재로 등록되어 있는 개발자 모집 공고에만 200개 넘게 지원을 했던 것 같다. 2월부터 4월까지 총 10~15개 회사에 서류 합격이 진행되어 면접을 진행했다. 정말 가고 싶은 곳은 2차 면접, 과제 전형까지 준비했지만 최종에서 떨어지고..
2024.07.03

이번에는 Elasticsearch Mapping에 대해 알아보자

 

먼저 classes라는 인덱스를 생성해주자

curl -XPUT 'http://localhost:9200/classes'

생성 이후 GET 메서드로 조회를 해보면 아래와 같이 'mappings' 필드가 비어있는 것을 볼 수 있다.

 

Mapping은 데이터베이스의 스키마와 같다. 직접 매핑을 설정해주지 않아도 Elasticsearch에 저장하는 것은 무리가 없지만 추후에 Kibana를 활용해 데이터를 시각화 할 때 날짜를 문자로 인식할 수 있는 에러를 방지하기 위해 Mapping은 필수다.

 

Mapping 정보는 아래와 같고 미리 mapping.json 파일에 저장해두자

{
  "properties": {
    "title": {
      "type": "text"
    },
    "professor": {
      "type": "text"
    },
    "major": {
      "type": "text"
    },
    "semester": {
      "type": "text"
    },
    "student_count": {
      "type": "integer"
    },
    "unit": {
      "type": "integer"
    },
    "rating": {
      "type": "integer"
    },
    "submit_date": {
      "type": "date",
      "format": "yyyy-MM-dd"
    },
    "school_location": {
      "type": "geo_point"
    }
  }
}

 

해당 json 파일을 통해 다음 curl 요청으로 Mapping을 진행하자

curl -XPUT 'http://localhost:9200/classes/_mapping' -H "Content-Type: application/json" -d @mapping.json

 

Mapping 이후 classes 인덱스를 조회하면 이전과 다르게 Mapping 항목이 채워진 것을 볼 수 있다.

 

 

Mapping 이후 bulk를 사용해서 데이터를 넣어보자

curl -X POST 'http://localhost:9200/_bulk' -H "Content-Type: application/json" --data-binary @data.json


##data.json
{ "index" : { "_index" : "classes", "_id" : "1" } }
{"title" : "Machine Learning","Professor" : "Minsuk Heo","major" : "Computer Science","semester" : ["spring", "fall"],"student_count" : 100,"unit" : 3,"rating" : 5, "submit_date" : "2016-01-02", "school_location" : {"lat" : 36.00, "lon" : -120.00}}
{ "index" : { "_index" : "classes", "_id" : "2" } }
{"title" : "Network","Professor" : "Minsuk Heo","major" : "Computer Science","semester" : ["fall"],"student_count" : 50,"unit" : 3,"rating" : 4, "submit_date" : "2016-02-02", "school_location" : {"lat" : 36.00, "lon" : -120.00}}
{ "index" : { "_index" : "classes", "_id" : "3" } }
{"title" : "Operating System","Professor" : "Minsuk Heo","major" : "Computer Science","semester" : ["spring"],"student_count" : 50,"unit" : 3,"rating" : 4, "submit_date" : "2016-03-02", "school_location" : {"lat" : 36.00, "lon" : -120.00}}
{ "index" : { "_index" : "classes", "_id" : "5" } }
{"title" : "Machine Learning","Professor" : "Tim Cook","major" : "Computer Science","semester" : ["spring"],"student_count" : 40,"unit" : 3,"rating" : 2, "submit_date" : "2016-04-02", "school_location" : {"lat" : 39.00, "lon" : -112.00}}
{ "index" : { "_index" : "classes", "_id" : "6" } }
{"title" : "Network","Professor" : "Tim Cook","major" : "Computer Science","semester" : ["summer"],"student_count" : 30,"unit" : 3,"rating" : 2, "submit_date" : "2016-02-02", "school_location" : {"lat" : 36.00, "lon" : -120.00}}

 

classes 인덱스를 조회해보면 다음과 같이 데이터가 잘 들어간 것을 볼 수 있다.

 

 

참고: [ELK 스택] Youtube 강의 허민석

https://www.youtube.com/watch?v=uzPTOgXe7-Q&t=274s

 

설날 이후 System Engineer 면접이 있어서 ELK 스택에 대해 공부해보려고 한다.

 

ELK 스택이란 

Elasticsearch, Logstash, Kibana의 세 가지 인기 있는 프로젝트로 구성된 스택을 의미하는 약어이다.

 

실행 환경 : Oracle VM (Ubuntu 20.04)

참고 : https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started.html

 

Index and search data using Elasticsearch APIs | Elasticsearch Guide [8.17] | Elastic

Deleting an index permanently deletes its documents, shards, and metadata.

www.elastic.co

 

해당 문서의 curl 명령어를 사용하면 Docker에서 Elasticsearch와 Kibana를 빠르게 설정한다.

curl -fsSL https://elastic.co/start-local | sh

 

 

UserName, Password

 

 

ElasticSearch API가 잘 동작하는지 확인해보기 위해 아래와 같은 get 요청을 보내보자

curl -u elastic:PqCJ0W6N http://localhost:9200

# -u : curl 인증에 사용
# elastic:PqCJ0W6N <사용자 이름 : 패스워드>

 

사용자 이름과 비밀번호를 환경변수로 설정하여 API에 요청을 보낼 때 사용해보자

 

export ES_USER="elastic"
export ES_PASS="PqCJ0W6N"

curl -u $ES_USER:$ES_PASS http://localhost:9200

 

 

아래 요청은 PUT 메서드로 books 인덱스를 생성(Create)하는 명령이다.

#<요청>
master@master:~$ curl -u $ES_USER:$ES_PASS -X PUT "http://localhost:9200/books"

 

#<결과>
{
"acknowledged":true,
"shards_acknowledged":true,
"index":"bookss"
}

 

acknowledged : 요청이 성공적으로 처리되었음을 나타냄

shards_acknowledged : Elasticsearch는 데이터를 여러 샤드(shard) 에 분산 저장함. 모든 샤드가 성공적으로 초기화되었음, 인덱스의 샤드가 정상적으로 설정됨

 

생성된 인덱스에 데이터를 추가해보자

 

curl -u $ES_USER:$ES_PASS -X POST "http://localhost:9200/books/_doc" -H "Content-Type: application/json" -d '
{
   "name":"Snow Crash",
   "author":"Neal Stephenson",
   "release_date":"1992-06-01",
   "page_count":470
}'
{
   "_index":"books",				
   "_id":"eVOknZQBfdxMJEeRCzQv",		
   "_version":1,				
   "result":"created",				
   "_shards":{					
      "total":2,				
      "successful":1,			
      "failed":0				
   },
   "_seq_no":0,
   "_primary_term":1
}

 

index:books : 문서(Document)가 추가된 인덱스 이름

_id:eVOknZQBfdxMJEeRCzQv : 문서의 고유 식별자

_version:1 : 문서의 버전

result:created : 인덱싱 작업의 결과

_shards : 인덱싱 작업이 진행된 샤드에 대한 정보, 0은 실패가 없음을 나타냄

_seq_no : 문서의 시퀀스 번호, 문서 변경 이력을 추정하는데 사용, 새로 생성된 경우 0번

_primary_term : 문서가 속한 주 샤드(Primary Shard)의 버전을 나타냄, 샤드는 재배치 가능함

 

shards 항목에서 total은 2개인데 1개만 성공한 이유는 인덱스의 구조가 2개의 샤드로 구성되어 있지만, 문서를 추가하는(POST)요청이 1개의 샤드에만 적용된 상황인 것 같다. Elasticsearch의 샤드 분산 처리 방식에 따른 것 같다.

 

 

_bulk 엔드포인트는 여러 개의 문서를 한 번에 추가, 수정, 삭제할 수 있는 기능이다. 성능을 향상시키고 네트워크 요청의 수를 줄이는데 도움이 된다.

 

아래와 같이 curl 요청을 보내면 여러 개의 문서를 한 번에 등록할 수 있다.

curl -u $ES_USER:$ES_PASS -X POST "http://localhost:9200/_bulk" -H "Content-Type: application/json" -d '
{ "index" : { "_index" : "books" } }
{"name": "Revelation Space", "author": "Alastair Reynolds", "release_date": "2000-03-15", "page_count": 585}
{ "index" : { "_index" : "books" } }
{"name": "1984", "author": "George Orwell", "release_date": "1985-06-01", "page_count": 328}
'
#생략

 

{
   "errors":false,
   "took":0,
   "items":[
      {
         "index":{
            "_index":"books",
            "_id":"elO3nZQBfdxMJEeRNzSC",
            "_version":1,
            "result":"created",
            "_shards":{
               "total":2,
               "successful":1,
               "failed":0
            },
            "_seq_no":1,
            "_primary_term":1,
            "status":201
         }
      },
      {
         "index":{
            "_index":"books",
            "_id":"e1O3nZQBfdxMJEeRNzSC",
            "_version":1,
            "result":"created",
            "_shards":{
               "total":2,
               "successful":1,
               "failed":0
            },
            "_seq_no":2,
            "_primary_term":1,
            "status":201
         }
      }
      ,
      , #생략
      ,
   ]
}

 

수정, 삭제, 동적, 정적 매핑에 관련해서는 다음 포스팅으로 작성하자

 

이전 Network Layer에서는 다음과 같은 문제가 있었다.

 

1. 한 번에 하나의 통신만 가능 -> 여러 어플리케이션이 동시에 통신 불가능 (카톡, 유튜브, 인터넷)

2. 패킷등의 순서 보장 / 유실에 대한 대응 불가능

 

해당 문제를 해결하기 위해 전송 계층이 활용된다.

 

Transport Layer

- 통신 주체끼리 데이터 전달의 신뢰성을 확보하는 방법을 정의

- 주요 단위 : 세그먼트

- 주요 구성 요소 : TCP/UDP

 

TCP(Transmission Control Protocol)

- 패킷의 전달 과정에서 순서를 보장하고 유실되지 않도록 보장할 수 있는 통신 규약

 -> 패킷 안에 세그먼트를 담아 주고 받아 로직을 처리

- 연결 지향

 -> 지속적으로 채널을 수립하여 전달 여부를 확인하고 무결성을 확인

     지속, 무결성을 확보하는 과정에서 비교적 느리고 복잡한 과정 필요

- 주요 사용 사례 : 웹 페이지(HTTP/HTTPS), 이메일, 파일 전송, SSH 등

 

Segment(세그먼트)

- TCP/UDP의 데이터 전달 단위

- Port (Source/Destination)

- Sequence/Acknowledgement Number : 통신 주체끼리 데이터를 주고 받았는지 확인에 사용

- Flags : Segment의 목적 등을 정의 (ACK, SYN, FIN)

- Window Size : 세그먼트를 만든 주체가 얼마나 많은 데이터를 받을지 전달

- Urgent Pointer : 세그먼트의 중요도를 설정

- 기타 (checksum 등), 실제 데이터

 

 

TCP Segment

 

 

아래 그림은 네트워크 레이어에서 클라이언트가 데이터를 전송할 때 여러 노드를 거쳐서 전달하기 때문에 순서/복원이 보장되지 않는 상황을 나타낸다. 이를 해결 하기 위해서는 전송 계층이 필요하다.

 

패킷의 무작위 도착 순서

 

 

TCP 프로토콜은 상대 클라이언트가 패킷을 수신 했는지를 확인한 이후, 다음 패킷을 보내는 방식으로 순서를 보장한다.

클라이언트 A가 B에게 1번 패킷을 보내면 클라이언트 B가 정상적으로 1번 패킷을 수령한 후, 다음 패킷을 받을 준비가 되었다는 ack 패킷을 보낸다.

 

TCP 동작

 

무사히 전달된 패킷은 클라이언트에서 실행 중인 어떤 프로그램에게 도착한건지 패킷만으로는 확인이 불가능하다. 

이를 확인하기 위해 Port를 사용한다.

 


Port

- IP 프로토콜에서 패킷을 올바른 프로세스로 라우팅 하기 위한 논리적 단위

- TCP Port / UDP Port로 구분

- Well Known Port : 주로 서버에서 사용하는 App/Protocol 별로 미리 지정된 포트

   80 : HTTP, 443 : HTTPS

   22 : SSH, 3306 : MySQL

- Ephemeral Port : 클라이언트에서 사용하는 포트로 연결할 때 마다 임의로 지정

 

Process 별 포트

 

 

TCP 프로토콜은 처음 연결될 때, TCP HandShake 과정을 거친다.

 

TCP Handshake

- TCP Protocol에서 통신을 수립하고 서로를 인식하는 첫 과정

- 3-Way-Handshake으로 부르며 3가지 과정으로 구분

1. Syn(Synchronize) : 첫 요청으로 사용할 첫 클라이언트 Sequence Number(CS)를 전달

2. Syn-Ack(Synchronize-Acknowledge) : Syn에 대한 응답으로 CS+1과 서버 Sequence Number(SS)를 전달

3. ACK(Acknowledge) : 마지막 단계로 연결이 수립되었음을 알려주며 CS+1과 SS+1을 전달

 

3-Way-Handshake 과정

 

 

TCP는 연결 지향 프로토콜이라면, 반대로 비연결 지향 UDP 프로토콜도 존재한다.

 

UDP(User Datagram Protocol)

- 빠르고 간단하게 데이터를 주고 받을 수 있는 방법을 정의

- 연결 지향과는 달리 데이터의 무결성, 순서, 전달여부를 체크하지 않음

- 패킷이 순서대로 오지 않거나, 중복, 유실될 수 있음

- 스트리밍, 보이스톡, 온라인 게임 등 패킷이 반드시 연속적이어야 할 상황이 아닌? 사용 사례

- TCP와 달리 세그먼트에 담겨진 정보가 적으므로 비교적 빠르다. 

 

UDP Segment

 

 

이번 시간까지 OSI 7 Layer중 하드웨어 계층을 담당하는 1-4 계층을 배웠다. 다음 시간에는 소프트웨어 계층을 알아보자.

OSI 7 Layer

 

 

출처 : 유튜브 AWS 강의실

 

 

이전 1편에서 같은 로컬 네트워크 클라이언트 끼리의 통신 과정을 알아봤다. 같은 로컬 네트워크가 아닌 다른 로컬 네트워크로의 통신은 어떻게 진행되는지 알아보자.

 

 

두 개의 서로 다른 로컬 네트워크

 

네트워크 계층(Network Layer)

 

- 여러 노드의 경로를 찾고 올바르게 전달될 수 있는 기능과 수단을 정의

- 주요 단위 : 패킷

- 주요 구성 요소 : Router, IP, ARP

- 서로 떨어진 Local Network 간의 통신을 지원

 

노드를 활용한 인터넷 라우팅 과정

 

 

먼저 통신을 하려면 목적지의 주소를 알아야 한다. 인터넷 세계에서는 IP를 주소로 사용한다.

IP (Internet Protocol)

- 인터넷 프로토콜 상에서 통신 주체를 식별하기 위한 아이디

- 두 가지 종류 (IPv4, IPv6)

 

CIDR (Classless Inter Domain Routing)

- IP 주소의 영역을 여러 네트워크 영역으로 나누기 위해 IP를 묶는 방식

- CIDR Notation : IP 주소의 집합

- 네트워크 주소와 호스트 주소로 구성 (ex 10.0.1.0/24, 172.16.0.0/12)

- 네트워크 주소가 같은 클라이언트는 같은 로컬 네트워크에 있는 것으로 인식 

 

네트워크 주소, 호스트 주소

 

Router

- 네트워크간에 패킷을 주고 받는 L3 장치

- 보내려는 데이터가 같은 네트워크 주소에 있지 않는 경우 라우터로 전송

- IP 대역별 최적의 경로를 수집 및 관리

- 어떤 경로의 노드를 경유해야 가장 효율적으로 도착하는지 라우팅 테이블 사용

- 자신의 로컬 네트워크가 아니라면 라우터로 전달 (서브넷 마스크 활용)

- 패킷을 프레임 안에 넣어 최적 경로에 따른 다른 라우터로 전달

- IP 주소에 따른 Frame 확인 방법 : ARP

Subnet Mask

- 어느 부분이 호스트 비트인지, 어느 부분이 네트워크 비트인지 구분해주는 Mask

- AND 연산을 활용해 네트워크 주소를 필터링

 

서브넷 마스크 AND 연산

 

ARP (Address Resolution Protocol)

- IP를 통해 로컬 네트워크의 클라이언트, 라우터 등의 Mac 어드레스를 찾는 프로토콜

- BroadCast (Mac : FF:FF:FF:FF:FF:FF)으로 IP 요청

- 응답 받은 IP Mac Address를 기반으로 테이블에 저장

 

ARP 요청 과정


1. 클라이언트 A가 MAC FF 주소로 ARP 요청을 보내게 되면 스위치는 이를 모든 클라이언트에게 전송한다.

2. 클라이언트 C,D는 자신의 IP가 아니므로 프레임을 버리게 된다.

3. 클라이언트 B의 경우 자신의 MAC 주소를 스위치를 통해 클라이언트 A에게 전송한다.

 

ARP 응답 과정

 

위와 같은 과정으로 라우터의 MAC 주소를 얻어낸 후 다른 네트워크 (63.12.33.12)으로 데이터를 전송한다고 가정하자

 

라우터로의 데이터 전송

 

같은 로컬 네트워크에 없다고 판별한 이후 라우터로 패킷을 전송한다.

 

패킷 전달 과정

 

1. 네트워크 계층 -> 데이터 계층 -> 물리 계층 순서로 패킷을 전달하게 된다.

2. 패킷의 주요 구성 

 - 헤더 : 출발지/목적지 IP, TTL(패킷의 생존 시간), 프로토콜 정보(예 TCP,UDP)

 - 페이로드 : 실제 전송할 데이터

 

라우터 내부 동작

 

클라이언트로부터 데이터를 받은 라우터는 해당 프레임을 복원하여 패킷을 열어 어떤 목적지로 보내지는지 확인한다.

라우터의 동작은 다음과 같다.

 

1. 패킷 수신 :클라이언트로부터 패킷으 수신, 출발지와 목적지 IP 주소가 포함되어 있음

2. 라우팅 테이블 조회 : 자신의 라우팅 테이블을 참조하여 패킷의 목적지 주소에 대한 HOP을 결정

3. 패킷 포워딩 : 결정된 다음 HOP에 따라 패킷을 전송할 인터페이스 선택

 

Next Hop 동작 과정

 

 

최적의 경로로 Microsoft 라우터로 프레임이 전송된 경우 해당 라우터에서도 프레임을 분해하여 위와 같은 과정을 거친 후 최적의 Next Hop인 Netflix 라우터로 전송된다.

 

최종 도착

 

Netflix 라우터에서 프레임을 열어 대상 IP를 확인해보니 같은 네트워크 주소임을 확인했다. (63.12.33.0)

따라서 해당 패킷을 스위치로 전달하여 데이터는 도착지 IP 주소와 일치하는 클라이언트에게 전달된다.

 

패킷 복원 과정

 

이렇게 목적지 IP를 가진 클라이언트 B에서 물리 -> 데이터 -> 네트워크 계층을 거쳐 패킷에 들어있는 PayLoad를 확인할 수 있다.

 

네트워크 계층을 통해 서로 다른 네트워크가 통신하는 과정을 간단하게 알 수 있지만 문제가 몇 가지 있다.

 

1. 한 번의 하나의 통신만 가능

해당 패킷이 어떤 어플리케이션으로 보내진 패킷인지 알 수 없다.

 

2. 패킷의 순서가 보장되지 않는다.

여러 노드를 통해서 데이터가 전달 될텐데 전송 속도가 전부 다를 수 있어 패킷의 순서가 엉망일 수 있다.

 

다음 계층을 통해 해결 방법을 알아보자.

 

 

출처 : 유튜브 AWS 강의실

OSI 7계층

- 컴퓨터 네트워크 및 통신을 7개의 레이어로 표현한 모델

- 하위 계층의 기능을 활용해 역할을 수행하고 상위 계층으로 처리 결과를 전달
- 각 계층이 독립적으로 설계되므로, 특정 계층의 변경이 다른 계층에 영향을 미치지 않음

 

[그림 1] OSI 7계층 구성도

 

Physical Layer

 

- 장치를 연결하기 위한 매체의 물리적인 사항

- 전압, 주기, 시간, 전선의 규격, 거리 등

- 단위 Bits

- 대표 구성 요소 : 케이블, 안테나, 허브, 리피터

[그림 2] 컴퓨터 통신

 

- 여러 Client 끼리의 1:1 통신은 위 그림처럼 Client 가 많아질수록 복잡해짐

 

허브

[그림 3] 허브를 사용한 통신

 

- 피지컬 계층에서 다수의 기기들을 연결해주는 장치

- 허브는 스위치 처럼 똑똑하지 않아서 다음과 같은 특징을 가짐

 

1. 누구에게 전송하든 모두에게 전송됨 (Broad Cast)

2. 충돌 감지 불가 (CSMA/CD)

 

Data Link Layer

 

- 물리적인 통신을 제어하여 디바이스와 디바이스간 통신 및 전송을 안정화 하기 위한 프로토콜

- 주요 단위 Frame

- 주요 구성 요소 : Mac Address, Switch

- CSMA/CD 방식을 활용하여 디바이스간 통신을 원활하게 연결

- 대상을 구별하여 디바이스간 통신을 지원 (Uni Cast)

 

스위치

[그림 4] 스위치를 사용한 통신

 

스위치가 등장함으로써 허브와 달라진 점

 

- MAC 주소를 기반으로 특정 포트에만 데이터를 전송 -> Uni Cast 지원

- 각 포트가 개별적인 충돌 도메인을 형성하므로, 여러 장치가 동시에 전송 가능 -> 충돌 도메인 해결

- 각 포트에 독립적인 대역폭을 제공하여, 더 높은 데이터 전송 속도 지원

 

 

프레임

[그림 5] 프레임

1. 프레임 헤더

- 목적지 MAC 주소

- 출발지 MAC 주소

- 타입/길이 : 프로토콜 유형, 데이터의 길이

 

2. 데이터 Payload

- 전송할 실제 데이터가 포함 (IP 패킷, ARP 요청 등)

 

3. 프레임 트레일러

- FCS(Frame Check Sequence)  : 오류 검출을 위한 체크섬으로, 데이터의 손상 유무를 확인

 

 

[그림 6] 스위치 내부 동작

 

프레임 스토리지

 

- 스위치가 네트워크에서 수신한 데이터를 임시로 저장하는 메모리 공간

- 목적지 포트가 사용 중일 경우 데이터를 대기

- 네트워크의 트래픽이 과다할 경우 전송 속도 조절 가능

- VLAN, QoS와 같은 다양한 기능을 지원

 

MAC 주소 테이블

 

- 스위치는 수신한 프레임의 출발지 MAC 주소를 읽고 어떤 포트로 들어왔는지 기록

- 수신한 프레임의 목적지 MAC 주소를 확인하고 해당 포트로만 프레임 전송

- 주소 테이블의 각 항목은 일정 시간 동안만 유효하며, 사용되지 않는 주소는 삭제 

 

 

사진 출처

그림 1 AWS 공식

그림 2~6 유튜브 AWS 강의실

 

리눅스의 주요 디렉토리

 리눅스 디렉토리의 구조는 배포판마다 다소 다르다. 대부분의 대표적인 디렉토리를 알아보자. FHS(Filesystem Hierarchy Standard) 표준 사양을 따른다.

 

리눅스 디렉터리 구조

 

/bin

 일반 사용자 및 관리자가 사용하는 명령어의 실행 파일이 배치되어 있는 디렉터리. 주로 시스템과 관련된 중요도가 높은 명령어를 포함

 

/dev

 디바이스 파일(디스크, 키보드 등 하드웨어를 다루기 위한)이 배치되어 있는 디렉토리

 

/home

 사용자별로 할당되는 개인용 홈 디렉터리가 배치되는 디렉터리, 사용자 이름이 디렉터리 이름으로 사용됨

 

/sbin

 /bin와 비슷하게 실행 파일을 포함하는 디렉터리, 관리자용 명령어가 포함됨(ex : shutdown)

 

/tmp

 임시 파일이 들어 있는 디렉터리, 애플리케이션 실행 중 임시로 작업 결과를 파일로 보존할 때 사용

 

/usr

 설치한 애플리케이션의 실행 파일, 문서, 라이브러리 등 포함됨. 하위 디렉터리에 bin, sbin, etc등이 있어 루트 디렉터리와 구조가 유사함

 

/var

 변화하는(Variable) 데이터를 저장하기 위한 디렉터리, 애플리케이션 실행 중 만들어진 데이터, 로그, 메일 등이 저장됨

 

 

 

https://www.pathname.com/fhs/

 

Filesystem Hierarchy Standard

Filesystem Hierarchy Standard Introduction This page is the home of the Filesystem Hierarchy Standard (FHS). The current version is 2.3. It was announced on January 29, 2004. The filesystem standard has been designed to be used by Unix distribution develop

www.pathname.com

, 모두의 리눅스(길벗)

IAM 이란

균민이
|2024. 8. 22. 23:31

 

IAM 이란

AWS Identity and Access Management는 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스 입니다.

IAM을 사용하면 사용자가 액세스할 수 있는 권한을 관리할 수 있습니다. IAM은 리전(서울, 미국, 일본 등)에 속하는 서비스가 아닌 글로벌 서비스 입니다. 루트 계정은 최초 생성 이후 가능하면 사용하지 말 것, IAM계정의 사용자는 필요한 최소한의 권한만 부여(최소권한의 원칙)

 

사용자(User)

- 개인 또는 애플리케이션을 위한 용도

- 특정 권한을 가진 ID (ex: EC2 FullAccess, Administrator)

- AWS 전반에 IAM 사용자를 특별하게 식별할 필요가 있는 경우 ARN(Amazon Resource Number)을 사용합니다. 일반적인 ARN은 아래와 같이 이루어져있습니다.

 

ARN 구성

 

IAM 사용자(Richard)의 ARN의 예시는 아래와 같습니다.

 

IAM 사용자 ARN 예시

 

그룹(Group)

- 개발팀, 운영팀 등의 사용자의 집합

- 다수의 사용자들에 대한 권한을 지정함으로써 해당 사용자들에 대한 권한을 더 쉽게 관리할 수 있음

Group 예제 ,출처 AWS

 

역할(Role)

- 특정 개인에 속하지 않는 특정 권한을 가진 ID

- 자격 증명이 할 수 있는 것과 없는 것을 결정하는 권한 정책을 갖춘 AWS 자격 증명이라는 점에서 IAM User와 유사함

- 역할은 한 사람하고만 연관되지 않고 역할이 필요한 사람이라면 누구든지 맡을 수 있음

- 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없음, 임시 보안 자격 증명이 제공됨

 

사용 예시
1. AWS 리소스에 액세스할 수 없는 사용자, APP, Service에 액세스 권한을 위임하는 경우

2. 모바일 앱에서 AWS 리소스를 사용할 수 있도록 허용하되 앱에 AWS키를 내장하기 원치 않는 경우

3. 기업 디렉터리에서 AWS외부에 정의된 자격 증명을 이미 보유하고 있는 경우

4. 타사 계정에 대한 액세스 권한을 부여하여 리소스에 대한 감사를 수행할 수 있어야 하는 경우

 

 

정책(Policy)

 정책은 자격 증명이나 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체입니다. AWS는 IAM 보안 주체(사용자 or 역할)가 요청을 보낼 때 이러한 정책을 평가합니다. 대부분의 정책은 AWS의 JSON 문서로 저장됩니다. AWS에서 정책은 아래와 같습니다.

 

- 자격 증명 기반 정책(관리형, 보안 인증 기반)

- 리소스 기반 정책

- 권한 경계

- 서비스 제어 정책 (Organizations SCP)

- 액세스 제어 목록(ACL)

- 세션 정책

 

 

JSON 정책 문서 구조

 

 

JSON 정책 구조, 출처 AWS

 

Version : 사용하고자 하는 정책 언어의 버전을 지정합니다.

 

Statement : 이 주요 정책 요소를 다음 요소의 컨테이너로 사용합니다. 정책에 설명문 둘 이상을 포함할 수 있습니다.

 

Sid(선택) : 선택 설명문 ID를 포함하여 설명문을 구분합니다.

 

Effect : Allow, Deny 을 사용하여 액세스를 허용, 거부 여부를 설명합니다.

 

Principal(일부 상황에 필요) : 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시합니다. 사용자 또는 역할에 연결할 IAM 권한 정책을 생성하면 이 요소를 포함할 수 없습니다.

 

Action : 정책이 허용하거나 거부하는 작업 목록을 포함합니다.

 

Resource(일부 상황에 필요) : IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정해야 합니다. 리소스 기반 정책을 생성하는 경우 이 요소는 선택사항입니다.

 

Condition(선택) : 정책에서 권한을 부여하는 상황을 지정합니다.

 

 

참고

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction.html

 

IAM이란 무엇입니까? - AWS Identity and Access Management

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/reference_policies_elements.html

 

IAM JSON 정책 요소 참조 - AWS Identity and Access Management

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

, 인프런 코드바나나 AWS 자격증 준비하기

 

운영 체제란

균민이
|2024. 8. 20. 23:17

운영 체제

 

 운영 체제는 시스템 소프트웨어로 컴퓨터 하드웨어와 소프트웨어 리소스를 관리하고 컴퓨터 프로그램에 서비스를 제공한다.

간단히 컴퓨터 하드웨어와 유저의 브릿지 역할을 한다.

 

운영 체제 타입

 

1. DeskTop Operating Systems : Microsoft Windows, macOs, Linux, Ubuntu

2. Server Operating Systems : Windows Server, Linux distributions (CentOs, Red Hat)

3. Mobile Operating Systems : Android, iOS, Windows Mobile

4. Embedded Operating Systems : smart TV, automobiles etc.

5. Real-Time Operating Systems : critical systems (medical equipment, car ECUs, network firewalls,,)

 

 

[머리말]

 

이 글은 개발자를 준비하면서 흘러 흘러 전산실에 취업하게 된 나의 이야기를 써 보려고 한다. 전산실 업무가 궁금한 사람에게 도움이 될 수도 있고 미래에 내가 이 당시 어떠한 생각을 했었는지 기억할 수 있게 기록으로 남기고 싶다.

 

[수료 이후 취업 준비]

 

2024년 1월 31일에 야놀자 백엔드 부트캠프를 수료했다. 수료하기 이전부터 수강생들은 다들 분주하게 취업 준비를 하였지만 나는 수료 이후부터 지원서를 돌리기 시작했다. 2월부터 사람인, 잡코리아 서울, 경기 소재로 등록되어 있는 개발자 모집 공고에만 200개 넘게 지원을 했던 것 같다.

 

2월부터 4월까지 총 10~15개 회사에 서류 합격이 진행되어 면접을 진행했다. 정말 가고 싶은 곳은 2차 면접, 과제 전형까지 준비했지만 최종에서 떨어지고, 그나마 붙은 곳들은 취업하고 당장 다음주에 중국으로 출장을 간다거나 .. 결국 4월을 마무리 하면서 입사 지원을 쉬어가기로 했다.

 

그래도 면접에서 얻은 것이 있다면 내 개발 실력이 부족한 것이지 인성 면접은 모두 합격을 했다는 점이다 ..ㅎㅎㅎ

 

[무료해지는 일상]

 

4월 마지막 면접을 끝내고 극도의 불안함과 스트레스가 몰려왔다. 물론 내가 열심히 준비 안한 결과가 이제 나타나는 것이다.

학원 초반에 강태공 좋아하시는 강사님께서 했던 열심히 안 하면 나중에 후회한다는 말이 정말 옳았다.

 

그건 이미 지나간 일이니깐.. 남들이 하지 말라고 해도 막상 자신이 진심으로 해야할 필요성을 느끼지 못하면 변하기 어려운 것 같다 ㅎㅎ..

 

그렇게 자존감이 떨어짐과 동시에 통장 잔고도 떨어지고 있었다. 국가에서 지원금으로 주는 돈은 다 저금을 하고 있었으므로 돈벌이가 필요했다. 물론 당장 취업을 하면 되지만 잠시 쉬어가고자 전에 일했던 닭발집 아르바이트를 하기로 했다.

 

[확실히 사람은 밖을 나가야 해]

 

집에서 있을 때와는 달리 아르바이트는 재밌고 신났다. 일은 쉽고 익숙하기에 여유 있게 즐길 수 있었고 사람들에게 웃으면서 인사하고, 생각할 시간 없이 바삐 움직이고, 시끌시끌 사람 사는 소리를 들으니 확실히 용돈도 벌고 복잡했던 마음이 편해졌다. 하지만 취업이라는 두려움은 아직 남아있었다.

 

[다시 취업 준비를 시작하자]

 

아르바이트를 하면서 2달 동안 취업 준비를 하지 않았다. 내 포트폴리오가 하찮게 느껴지고 어디서부터 손을 봐야 할지 막막했기에 그냥 그대로 방치했었다. 유튜브에 개발자 신입 스펙을 보면 도커, 레디스, 메세지 버스, AWS, 쿠버네티스 등 내가 따라가기엔 버거운 스펙을 가진 사람들이 많이 있었다. 6월까지 취업하겠다는 엄마와의 약속도 있었고 당장 공부를 해서 그 사람들을 이겨가면서 취업을 할 수 없다고 판단했기에 취업의 방향을 다른 쪽으로 돌리기로 했다.

 

[개발자의 무덤이라 불리는 전산실]

 

전산실이라 하면 개발자의 무덤이라는 말을 많이 들었던 것 같다. 개발자를 하다가 전산실로 전향은 가능하지만 그 역은 가능하지 않다. 그만큼 전산실 업무가 단순 반복적이며, 미래 지향적이지 않고 코딩을 하지 않으므로 다들 기피하는 직무인 것 같다.

 

하지만 취업은 해야겠고 개발자를 준비한 기간이 있긴 하지만 경쟁률도 200~300씩 몰리고, 내 개발 실력을 객관적으로 봤을 때 경쟁력이 부족하다고 생각했다. 학원에서 팀 프로젝트를 경험하면서 나는 당장 내 코드에만 신경이 쏠려있어서 전반적인 프로젝트의 구조, 인프라는 잘 이해하지 못했는데 전산 업무의 경우 네트워크와 같이 큰 숲을 볼 수 있을 것 같아서 흥미로웠다.

 

[지원부터 출근 까지 단 5일]

 

일단 희망사다리 조건을 채우고자 사람인에 중견기업, 매출액 5,000억 미만 기업을 찾기 시작했다. 그렇게 집 가까운 곳 위주로 10군데 지원을 했으며 3군데 면접 제안이 왔다. 

 

사실 개발자를 준비하면서 많이 듣는 소리는 정보처리기사 같은 자격증은 있으면 좋지 없어도 상관없다라는 말이었다. 그래서 나는 자격증이 없다. 단지 지방대 4년제 졸업장만 가지고 지원서를 돌리고 있었다.

 

운이 좋게 어느 중견 제조업 전산실에 면접을 보러 갔다. 제조 회사라 그런지 화학 약품 냄새가 나를 반겼다. 

 

개발자 면접 질문은 어느정도 정해져 있어서 달달 외우고 갔는데 전산실 면접을 처음이라.. 일단 몸만 갔다.

 

면접 질문의 수준은 상당히 쉬웠다. 컴퓨터 조립은 해봤는지, 정보처리기사는 왜 없는지, 개발자와 전산실의 차이는 뭔지 알고 지원한 건지 물었고 잘 대답을 했던 것 같다. 면접을 몇 번 봤냐고 물으시길래 여러 번 봤다고 하니 확실히 잘한다고 칭찬을 해주셨다. 나는 말을 매우 더듬은 기억밖에 없는데 ㅎㅎㅎ.. 아마 분위기를 풀어주려고 한 것 같다.

 

그렇게 20분 만에 면접을 끝내고 바로 다음날 합격 통지를 받았다. 일은 배우면 그만이고 인성과 끈기를 좋게 봐서 합격한 것 같다. 이런 걸 보면 취업은 운이 맞는 것 같다. 간절하게 원하는 직장은 탈락하고, 하나도 기대를 안하는 직장은 합격하는 느낌이 있다.

 

[취업 확정]

 

개발 공부를 준비한 기간도 있고, 개발자의 자유로운 근무 환경을 꿈꿔왔던 것도 맞지만, 내 객관적인 개발 실력과 집에서 출퇴근 소요시간, 당장의 신입 개발자 초봉의 1.5배에 달하는 급여, 취업을 원하는 엄마의 심정도 걱정되었기에 취업을 확정 지었다.

 

[회사 분위기]

 

확실히 딱딱하다. 개발자는 새로운 제품을 개발하는 역할이라면, 전산업무는 잘 만들어진 제품을 안정적이고 효율적으로 운영하는데 노력한다. 그래서 그런지 우리 부서는 말소리도 없고 선후임 관계도 조용한 것 같다. 이미 각오하고 들어왔으므로 문제 되지 않는다. 아직 신입사원이므로 간단한 업무부터 시작할 것 같다. 컴퓨터 수리, 금액 전표 관리, 네트워크 점검 등 확실히 쉽고 반복적인 일을 하는 것 같다. 직급이 있는 분들은 쿼리문도 날리고 서버도 설치하고 그러는 것 같기도 하네요

 

[앞으로의 계획]

 

나는 희망사다리 사업 수혜자이다. 4번 수혜 받았으므로 한 기업에서 1년 6개월 근무를 해야한다. 1년 6개월동안 자격증을 따야겠다.

정보처리기사 실기, 네트워크 관리사 2급, SQLD, CCNA, 리눅스 마스터 1급, MS Server 관련 자격증을 따는 것이 목표이다. 이정도면 어느정도 네트워크 지식에 대해 알 수 있을 것 같고 그 이후에는 클라우드 공부도 하면서 방향을 생각해보고 싶고 토익 공부도 하면서  회사 인테리어가 예쁜 곳을 다니면서 돈을 모아 미래를 도모하고 싶다.