'전체 글'에 해당되는 글 209건

이번시간엔 Context Switching(문맥교환)에 대해 포스팅 해보려고 한다. synchronous blocking, non-blocking쪽을 공부하다가 나온 개념이었다. 그래서 이게 어떤것인지 정확하게 알지 못해서 Context Switching에 대해 공부를했다. 그 결과를 포스팅해보고자 한다.

Context Switching(문맥교환)은 우리나라 말로 해석하게 되면 문맥교환이란 의미가 된다. 컴퓨터에서도 마찬가지이다. 서로 정보를 교환한다. 하지만 이것이 어떻게 교환되는지 자세히알아보자. 

1. Context Switching은 어떤것인지?

 Ready 상태인 A 프로세스와 Running 상태인 B 프로세스가 있다고 가정하자. 이 프로세스는 인터럽트의 요청을 받게 된다고 또 가정을 하게 된다면 인터럽트에 의해서 서로 상태가 전이된다. 즉, A프로세스는 Running 상태가 되고 B프로세스는 Ready상태가 된다. 그럼 도데체 거기에 저장되어 있던 데이터는 어디로 갔을까? 만약 저장되어 있었던 기존의 데이터들이 저장되지 않고 그대로 교환되어버리면 데이터들이 날아가버리는 불쌍사가 발생한다. 그래서 A프로세스의 상태 또는 레지스터 값 등이 PCB에 저장되고, A 프로세스의 정보를 PCB에서 CPU로 적재시킨다. 그렇게 되면 또 B프로세스는 현재 저장된 A프로세스의 데이터들을 메모리 공간에 저장해두게 된다. 이것이 Context Switching이다. 서로 맞교환을 하지만 그 전에 저장되어있던 데이터들을 다 백업에 백업을 거쳐서 저장해놓기 때문에 Context Switching이 일어나도 그 전에 있던 데이터들은 항상 보존되게 된다.

2. 그럼 PCB는 무엇인지?

PCB는 Process Control Block의 약자로 프로세스나 레지스터의 값같은 데이터들을 저장할수 있는 공간이며, 프로세스마다 고유한 PCB의 값을 가지게 된다. 

3. Context Switching에 대한 모식도

출저: http://mooneegee.blogspot.kr, 윤성우의 시스템프로그래밍

이 그림이 가장 이해하기도 편해서 포스팅한다. Running상태인 A 프로세스와 Ready 상태인 B 프로세스가 Context Switching이 일어났다고 가정을 했을때 그림인데, A프로세스 데이터는 CPU에 적재되어 있고 B프로세스 데이터들은 메모리에 적재되어 있음을 보여주고 있는 상태이다.

4. 그럼 Context Switching의 단점은?

단점이 없는게 아니다. 제일 대표적인 단점이 CPU의 과부하다. 프로세스가 서로 변경되는 과정에서 데이터들을 서로 백업하고 백업하는 과정을 거치기때문에 당연히 그 과정에서 CPU가 큰 부담을 느낄 수 밖에 없다. 프로세스가 실행이 많이되면 많이 될수록 당연히 Context Switching의 과정은 많아질 수 밖에 없다. 그래서 운영체제 설계자들은 이러한것을 줄이기 위해 연구중이라고 한다. 

이렇게 Context Switching에 대해서 포스팅을 해봤는데 최대한 쉽게 풀어써보려고 노력했다. 내가 이해했던 내용을 썼지만 어려운 개념일 수도 있기 때문에 좀 더 많은 책들을 찾아보는 노력도 필요할 것 같다.

본 실습은 Mac을 기준이다. 

이제 진짜로 mongodb Replica Set을 만들어보자. 먼저 mongodb를 설치해야한다.

•  brew install mongodb

다음으로 Replica Set member(Primary1, Secondary2, Arbiter1)와 log를 위한 디렉토리를 생성한다.

•  sudo mkdir /data/db/replSet1
•  sudo mkdir /data/db/replSet2
•  sudo mkdir /data/db/replSet3
•  sudo mkdir /data/db/replSet_Arbiter
•  sudo mkdir /data/db/replSet_Log

아래의 4개 명령어를 수행하여 Replica Set 4개를 실행한다. 

•  sudo mongod --port 20000 --dbpath /data/db/replSet1 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet1.log
•  sudo mongod --port 30000 --dbpath /data/db/replSet2 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet2.log
•  sudo mongod --port 40000 --dbpath /data/db/replSet3 --replSet Mongo_study --smallfiles --oplogSize 128 --logpath /data/db/replSet_Log/mongo_replSet3.log
•  sudo mongod --port 20017 --dbpath /data/db/replSet_Arbiter --replSet Mongo_study --smallfiles --noprealloc --nojournal --logpath /data/db/replSet_Log/mongo-replSet_Arbiter.log

모두 정상적으로 따라왔다면 현 prompt에서 다음과 같이 명령어를 수행시켜 준다.

•  rs.add(“localhost:40000”)
•  rs.addArb(“localhost:20017”)
•  rs.add(“localhost:30000”)

이제 rs member 4개가 정상적으로 동작을 하게된다.

다음으로 rs 설정을 변경하는 법을 알아보겠습니다. 아래 그림처럼 config 변수에 rs의 config 내용을 받아온다.

실행을 정상적으로 시켰다면 대강 이런 화면이 나올 것이다.

[그림1 rs config 내용 받아오기]

제대로 받아왔는지 확인해보려면 아래의 명령어를 통해 rs 멤버들의 설정을 확인해 보면 된다.

실행시키면 이런 화면이 출력이된다. 아래에 조금 더 내용이 있지만 좀 길어서 대강 저렇게 나온다만 이야기 하겠다.

[그림2 rs config 확인하기]

아래 그림처럼 원하는 rs 멤버만 콕 집어서 확인할 수도 있다.

[그림3 특정 rs member의 config 확인하기]

“localhost:20000” host를 가지는 멤버의 “votes”와 “priority”를 수정해보자.

[그림4 특정 rs member의 config 변경하기]

“rs.conf()” 명령어를 통해 한 번 확인해 보면 설정이 잘 변경됐음을 확인할 수 있다. 여기서 한가지 주의해야 할 점은 “localhost:30000” host를 가지는 rs 멤버의 설정을 변경해 본다. 단, priority를 가장 높은 값을 갖도록 설정해야 한다.

실행을 하면 아래와 같은 그림이 펼쳐진다.

[그림5 priority 변경 후 발생하는 상황]

이번시간엔 zookeeper의 필요성에 대해 포스팅 해보려고 한다. 이 포스팅 내용자체가 mongodb Replica Set의 개념이 있어야 이해가 가능한 내용이기때문에 꼭 mongodb 내용부터 확실하게 이해를 하고 봐야 이해가능한 내용이다.

1. Mongodb Replica Set의 여전히 해결되지 않는 문제점

‘Mongodb Replica Set 만들기’에서 살펴본 바 같이 rs가 Primary1, Secondary2, Arbiter1 으로 구성돼 있다면 Primary가 죽었다고 하더라도 2개의 Secondary 중 하나가 Arbiter의 존재로 인해 Primary로 선출된다.

하지만 여전히 문제점은 존재하게 된다. 

[그림1 Election for New Primary: Secondary2, Arbiter1]

죽었던 Primary는 어떻게 살려내야할까? 만약 Arbiter가 죽으면 이건 또 어떻게 해결할 수 있을까?

아래의 그림은 아비터가 죽었다고 가정한 가상의 모식도이다.

[그림2 rs(Primary1, Secondary2, Arbiter1) 멤버 중 Arbiter가 죽은 경우]

그리고 이 상태에서 Primary가 죽게된다면 어떻게 될까? Election을 통해 Primary가 선출되지 않을 것이다. 그렇게 된다면 선출할 수 있는 권한을 가진 Arbiter가 없기때문에 큰 문제가 발생한다. 이건 Arbiter를 다시 꼭 살려야한다.

하지만 다행히도 Arbiter는 죽을 일이 거의 없긴하다. 투표권을 행사하지만 Replication 되지도 않으며 Client에게 Read를 수행하는 경우도 없기 때문이다.

현 상황은 ‘그림1’ 과정을 거쳐 Primary 하나와 Secondary 하나, Arbiter 하나가 살아있는 상태라고 가정한 그림이다.

[그림3 ‘그림1’과정을 거친 후 rs 멤버의 모습]

이번시간엔 MVC패턴에 대해 포스팅해보려고 한다. MVC패턴은 프로그램을 설계할때 매우 중요한 이론이며, 소프트웨어공학아키텍쳐 과목에서도 중요하게 다뤄지는 이론이기때문에 확실히 알아둘 필요성이 있다.

1. MVC패턴 그림

2. MVC에 대한 개념

애플리케이션의 시각적인 요소와 비즈니스 로직을 서로의 영향 없이 수정이 가능한 구조적 패턴이다.

① Model = 애플리케이션에서의 데이터를 나타낸다.

② View = 사용자가 보여지는 시각적인 요소를 나타낸다.

③ Controller = 데이터와 비즈니스 로직의 상호작용을 나타낸다.

3. MVC 패턴의 logic의 예

<출저: 생활코딩>

생활코딩이란 블로그에서 MVC패턴에 대한 정보가 굉장히 잘 정리되어 있어서 많은 참고를 하였다. 조금은 어떤건지만 알고 있었는데 생활코딩이란 블로그를 읽어보면서 MVC패턴이 무엇인지 개념정리가 확실히 되었다. 이렇듯 프로그램을 설계하는데 있어서 MVC패턴을 알고 모르는 것은 천지차이이고, 진정한 소프트웨어공학자가 되기위해선 꼭 알아야할 개념이라고 생각한다. 참고로 MVC패턴은 서버쪽에서도 많이 사용되고 있다.

이번시간에는 데이터베이스의 Sharding에 대해 포스팅해보려고 한다. Sharding에 대한 개념 자체는 크게 어려운 건 아니지만 알아두면 굉장히 유용한 개념이다.

데이터베이스에서의 Sharding이라 하면 관계형데이터베이스를 여러개로 분할해서 데이터를 저장하는 기능을 뜻한다. 현시대에는 사람들의 사용이 증가하면서 엄청난양의 데이터를 저장해야하기 때문에 자연스럽게 Sharding의 기능이 많이 필요하게 되었다. sharding의 방법은 수평적 sharding과 수직적 sharding이 있다.

Figure 1 Vertical Sharding

Figure 2 Horizontal Sharding

<사진출저: 조대협의 블로그>

Sharding의 기능이 여러모로 좋긴하다. 데이터베이스를 한군데에 몰리게 되면 요즘같이 사용자도 많은 시대에 서버과부하가 걸릴 확률도 매우 높고 만약 그 DB가 다운되어서 정지된다면 모든게 다 중단될 것이다. 하지만 이렇게 Sharding방법으로 여러개의 데이터를 나누어서 저장하는 방식은 굉장히 혁신적이었다. 하지만 이것도 모두 장점만이 있는건 아니다. 단점도 존재하게 되는데 직접 Application에서 구현할 경우 Key에 따라서 DB Instance를 선택적으로 고를 수 있는 구조를 가져야 하며, 특히 다른 Shard간의 데이터 Join등은 불가능하기 때문에, 구현을 할때에는 잘 고려해서 설계해야한다. 그리고 Sharding기능을 쓰게되면 Application의 복잡도가 올라가기 때문에 여러가지 요소들을 잘 고려해서 설계를 해야한다. 또한 하나의 트랜잭션에는 두개의 Sharding이 한번에 접근 할 수가 없기때문에 이 또한 잘 반영해서 설계해야한다.

지난 3개의 포스팅을 통해 Replica Set과 Election 및 Secondary가 두 개일 경우 Arbiter가 있어야 하는 이유에 대해 알게 됐을 것이다. 그런데 여기서 한가지 궁금한 점이 있을 것이다. 애초에 아비터 없이 Secondary만 3개 있으면 되지 않을까?

아래와 같이 백엔드에서 Read가 600만큼 req가 오고 있는 것이 보일 것이다.

[그림1 Read req가 600인 경우]

Secondary에서 300씩 처리하는데 가장 이상적이라고 한다면 Primary 하나와 Secondary 두개가 가장 이상적일 것이다.

[그림2 Read req가 600이고 primary1, secondary2인 rs의 경우]

물론 read req가 900이라면?

[그림3 Read req가 900인 경우]

각 Secondary가 300씩 처리하는게 이상적이라면 Primary 하나와 Secondary 세 개가 적당할 것이다.

[그림4 Read req가 900이고 primary1, secondary3인 rs의 경우]

하지만 Primary 입장에서 생각을 해보게 된다면 ‘그림5’와 같이 Primary는 각 Secondary에게 Replication 해 주어야 한다.

[그림5 mongodb rs: Primary1, Secondary2]

Secondary가 세 개라면 그만큼 Primary의 부담도 더 증가 한다는 뜻이된다. 반면 Arbiter는 Primary로부터 Data Replication을 지원받을 필요가 없으며 실제로 지원받지도 않는다. 그저 Primary 선출시 투표권을 가지고 있을 뿐이다.

<출저: https://unagi44.wordpress.com/Developer Lee>

이번시간엔 지난시간에 이어 mongodb Replica Set Election에 대해 포스팅 해보려고 한다. 아마 지난시간에 설명한 Arbiter의 내용은 다 이해하고 왔을 거라고 생각한다. 그러면 Election은 또 어떤건지 자세히 알아보도록 하자.

‘그림1’처럼 Primary 하나와 Secondary 둘이 rs를 구성하고 있다고 가정해보자.

[그림1 mongodb rs: Primary1, Secondary2]

​​

‘그림2’와 같이 Primary가 죽고 Secondary 둘만 남은 상황이다.

[그림2 Primary1, Secondary2 rs에서 Primary가 죽은경우]

그럼 저상황에서 Election을 진행하는데 서로 1표씩 받은 상황이다. 그럼 결국엔 1:1 무승부가 되었기때문에 Primary는 선출되지 않는다. 그럼 또 이럴땐 어떻게 해야할까?

[그림3 Election for New Primary: 1 vs 1 무승부]

아래와 같이 mongodb를 실행시켜보면 Replica Set 구성원은 “votes”라는 투표권을 가지고 있다.

[그림4 rs member가 가지는 votes]

그렇다면 투표권 숫자를 변경해 Primary가 선출될 수 있도록 설정하면 될거같지않은가? 투표권이 각각 3, 2, 1로 설정된다면 Primary 선출에 아무런 지장이 없을테니 말이다.

하지만 또하나의 변수는 있다. 아래의 그림을 보자.

[그림5 rs member의 votes 특성]

“must be 0 or 1” 문구를 보면 알 수 있듯이 “votes” 값은 ‘0’ 혹은 ‘1’로 설정해야한다. 그렇다면 Primary 투표권을 ‘1’로 Secondary의 투표권을 각각 ‘0’, ‘1’로 설정하면 되지 않을까?아래 그림과 같이 Primary에 장애가 생겼다.

[그림6 Primary, Secondary2가 각각 1, 0, 1 votes를 가지고 Primary가 죽은 경우]

Secondary 둘이 Election을 진행하게 된다. 서로 가진 투표권은 각각 ‘0’, ‘1’이다. Secondary 둘이 Election을 진행한 결과 아래 그림과 같이 각각 ‘1’, ‘0’표씩 받았다. 그렇다면 1표를 받은 Secondary가 Primary로 선출되지않을까?

[그림7 Secondary 둘이 Election 진행한 결과]

하지만 투표자 들의 투표 숫자(1표)가 전체 투표 숫자(2표)의 과반수(1표)를 넘지 못한다는걸 볼 수 있다. 이로 인해 1표를 받은 Secondary는 Primary로 선출되지 못한다. mongodb는 Election 시에 투표자들의 투표 숫자가 전체 투표 숫자의 과반수를 넘어야 진행이 되도록 하고 있다. 그렇다면 Primary의 투표권이 ‘0’이고 Secondary 투표권이 각각 ‘0’, ‘1’이라면 되지 않을까??

이렇게 설정하려 하면 다음과 같은 문구를 보게 된다.

[그림8 rs member들의 votes 합이 1개인 경우]

위의 문구를 보면 알 수 있듯이 “not enough voting nodes”라고 경고하고 있다. 적어도 2개의 투표권이 있어야 한다. 따라서 투표권을 하나씩 가지고 있는 상황에서 투표를 하는 서버는 3개 이상의 홀수개로 존재하여야 Primary가 정상적으로 선출이 된다. 만약 짝수의 서버가 Election을 진행하면 N:N 무승부로 Primary 선출이 정상적으로 진행되지 않을 수 있기 때문이다.

하지만 Primary 하나와 Secondary 둘, Arbiter 하나가 있는 상황에서 Primary가 죽는다면? ‘그림9’와 같이 된다. Primary와 Secondary, Arbiter가 모두 투표권을 ‘1’개씩 가지고 있는 상황이라면 투표자들의 투표 숫자(3)가 전체 투표 숫자(4)의 과반수를 넘긴다는 것을 알 수 있다.

이번시간엔 지난번에 생긴 궁금증에 대해 이어서 포스팅 해보고자 한다. 친구가 했던 내용을 글로 쓰는거지만 나 나름대로 내용을 알고 있는 상태에서 글을 썼고 모르는 내용이나 어설프게 아는 내용이었다면 포스팅 하지 않았다. 컴퓨터 개발자나 보안전문가들은 항상 겸손하다. 왜나면 아는것 같아도 또 모르는게 계속 있기 때문에 끊임없이 공부해야하기 때문이다. 아무튼 내가 알게 된 지식도 겸비해 글을 쓰겠다.

1. mongodb rs(replica set) 구조에서 Write를 수행하는 DB는 “Primary”라고 하고, Read를 수행하는 DB는 “Secondary”라고 부른다.

[그림1 rs: Primary, Secondary]

’그림2’와 같이 Primary에 장애가 생겨 서비스 장애가 발생했다. 그렇다면 이상황에 대해서는 어떻게 해야할까? 이래서 Primary쪽은 관리를 잘해야 하는 것 같다.

[그림2 rs: Primary에 장애가 생긴 경우]

그림3’처럼 Primary가 죽은 것을 빠르게 catch한 후 Secondary 중 하나가 Primary로 선출된다면 다시 정상적인 서비스가 가능해질 것이다.

​

[그림3 rs: Primary를 새롭게 선출]