반응형

https://programmers.co.kr/learn/courses/30/lessons/42587?language=kotlin

 

코딩테스트 연습 - 프린터

일반적인 프린터는 인쇄 요청이 들어온 순서대로 인쇄합니다. 그렇기 때문에 중요한 문서가 나중에 인쇄될 수 있습니다. 이런 문제를 보완하기 위해 중요도가 높은 문서를 먼저 인쇄하는 프린

programmers.co.kr

data class Document(
    val priority: Int,
    val isTarget: Boolean
)

class Solution {
    fun solution(priorities: IntArray, location: Int): Int {
        var answer = 0
        
        val documents = priorities.mapIndexed { idx, priority ->
            Document(
                priority,
                if (location==idx) {
                    true
                } else {
                    false
                }
            )
        }.toMutableList()
        
        while(true) {
            var found:Boolean = false
            val firstDocument = documents.removeAt(0)
            var highestPriority = firstDocument.priority
            
            documents.forEach { document -> 
                if (document.priority > highestPriority) {
                    found = true
                    return@forEach
                }
            }
            
            if (found) {
                documents.add(firstDocument)
            } else {
                answer += 1
                if (firstDocument.isTarget) {
                    return answer
                }
            }
        }
    }
}

 

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
반응형

페이스북의 서버 다운이 이례적으로 복구되는데 까지 오래 걸렸습니다. (약 4시간~5시간)

정확히 말하자면 이는 서버 다운은 아니었습니다. 네트워크의 문제였죠.

그리고 이렇게 복구에 오래 걸리는 네트워크 관련 문제는 대부분 "DNS"에 의해 발생합니다.

실제로 페이스북, 인스타그램 접속 제한의 문제도 DNS였구요. 이전 게시글에서 BGP hijacking을 비롯한 BGP 관련 문제가 아닐까 단순히 '추정'하고 있었는데 그 추정이 사실이었습니다. https://www.zdnet.com/article/what-took-facebook-down-major-global-outage-drags-on/

 

What took Facebook down: Major global outage drags on | ZDNet

DNS appears to be a symptom of the root cause of Facebook's global failure. Don't expect a quick fix.

www.zdnet.com

BGP(Border Gateway Protocol)는 인터넷 최상위에 존재하는 autonomous systems (AS) (ex. KT, SKT, LGU+ 등 ISP)간에 라우팅에 사용되는 표준 프로토콜입니다. 그렇기 때문에 대부분의 사람들과 각 기업의 네트워크 관리자들은 이러한 BGP를 다룰 일이 없습니다.

그리고 이 문제는 단순히 서비스를 이용할 수 없는 것에서 그치는 것이 아니라 여러가지 성가신 문제를 야기하기도 했습니다.

As annoying as this is to you, it may be even more annoying to Facebook employees. There are reports that Facebook employees can't enter their buildings because their "smart" badges and doors were also disabled by this network failure. If true, Facebook's people literally can't enter the building to fix things.  

이 네트워크 장애로 인해 건물 출입문 인증 시스템 또한 무력화되어 복구를 위해 건물에 들어갈 수 없다는 것입니다.

그래서 BGP와 BGP Hijacking이 뭐길레 이런 문제가 발생했을까 궁금해 하실텐데요.

BGP

앞서 잠깐 설명 드렸듯 BGP는 인터넷 라우팅 프로토콜이며, 사용자의 트래픽이 목적지 IP 주소에 최대한 효율적으로 도달할 수 있도록 방향을 제공합니다.

사용자가 웹 브라우저에서 도메인 주소(ex. facebook.com)를 입력하면 DNS 서버에서 IP를 주소를 제공하고, BGP는 해당 IP 주소에 도달하는 가장 효율적인 방법을 제공하는 것이죠.

BGP Hijacking

각 BGP 라우터는 AS 간의 최적 경로가 포함된 라우팅 테이블을 저장하고 있습니다. 이들은 각 AS가 자신이 소유한 새로운 IP 접두사를 브로드캐스트함에 따라 거의 실시간으로 업데이트됩니다. 

여기서 문제가 발생합니다.

인터넷은 상호 연결된 여러 개의 대규모 네트워크로 구성되어 있습니다. 이들은 모두 분산되어 있기 때문에 데이터 패킷이 의도한 대상 IP 주소에 도달할 수 있도록 하는 관리 기관이나 교통 경찰이 따로 존재하지 않습니다. 그래서 BGP가 이 역할을 수행합니다. BGP가 없다면 웹 트래픽은 비효율적인 라우팅으로 인해 목적지에 도달하는 데 엄청난 시간이 걸리거나 의도한 목적지에 전혀 도달하지 못할 수도 있습니다.

그리고 각 BGP 라우터들은 AS의 업데이트를 무조건 신뢰합니다.

예를 들어, AS 100에 속하는 IP prefix가 192.0.2.0/24 라면, AS 100은 이웃하는 BGP peer 들에게 "192.0.2.0/24"에 속하는 주소는 자신에게 보내라고 알리는 것입니다. 그리고 이 전파는 또 다른 이웃 BGP peer에게 거의 실시간으로 전파되게 됩니다.

이를 이용한 하이재킹은 다음과 같은 방식으로 이루어집니다.

기존에 페이스북 IP에 대한 라우팅 정보를 갖고 있는 AS 1000이 있고, 페이스북의 IP Prefix는 다음과 같다고 가정해봅시다.
- 222.111.192.0/24
- 222.111.193.0/24
- 222.111.195.0/24
- 222.111.197.0/24
- 222.111.199.0/24

그런데 AS 2000이라는 곳에서 페이스북의 IP Prefix는 우리한테 연결해. 라고 브로드캐스트해버리는 것입니다.

그렇게 된다면 다른 BGP Peer들은 이 AS의 업데이트 요청을 신뢰하게 되고(가장 최근 브로드캐스트를 신뢰함) 실제로 페이스북 IP 주소로 연결되는 요청은 AS 2000으로 보내버리게 됩니다.

(아직까지 Hijacking인지, AS의 실수인지는 밝혀지지 않았습니다. 페이스북 CTO의 발표가 예정되어 있습니다.)

이것이 BGP와 BGP Hijacking 이며, 이를 방지하기 위해 RPKI와 BGPsec라는 솔루션이 제시되기도 했지만, 이러한 솔루션들은 아직까지 널리 적용/구현되지 않은 상태입니다.

즉, 우리가 매일 사용하고 있는 인터넷 세상은 Routing Security 관점에선 아직 완전하지 못하다 볼 수 있습니다.

--

소프트웨어를 개발하다보면 다양한 이유로 장애를 접하게 되는 경우가 많은데요. 개발자의 잘못된 코드로 인해 장애가 발생하는 경우는 최소화해야 할 것입니다. 하지만 늘 두렵고, 배포는 조심스러울 수 밖에 없죠.

꼼꼼하게 QA를 했는데 배포하자마자 장애가 발생해서 롤백했던 경험이 있으신가요? 새벽에 출근해서 배포를 했던 경험이 있으신가요?

장애 리스크를 없애고 새벽 배포의 스트레스도 줄일 수 있는 방법을 알려드립니다!

이번 웨비나에서는 구글, 아마존, 쿠팡과 같은 국내외 테크기업에서 활발히 사용되고 있는 기능 플래그를 활용하여 장애 리스크 없이 배포하는 방법에 대해 쿠팡 출신 개발자가 친절하게 설명해 드립니다.

https://youtu.be/IQxaV-HNjog

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
  1. 찎끄 2021.10.05 15:04

    좋은 글 감사합니다.

    • Aaron 2021.10.05 15:05

      좋은 댓글 감사합니다.

  2. ㅇㅇ 2021.10.06 20:29

    만약 정말로 하이재킹이라면 ㅎㄷㄷ한데요

반응형

페이스북은 서버 다운을 공지할 곳이 없어 Twitter에 글을 올렸다.

그리고 some people 이라는 표현을 썼는데.. 답글이 정곡을 찔러준다 ㅎㅎ

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
반응형

이런 류의 대규모 서버 다운이 연례 행사 수준으로 발생하기는 한다.

그러나 이번 서버 다운은 그 규모가 매우 크다고 볼 수 있다. BGP(Border Gateway Protocol)가 문제일 거라는 아티클이 이곳 저곳 공유되고 있는데,

CloudFlare에서 공유한 BGP Hijacking 아티클을 첨부한다.

https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/

아, 그리고 이번 다운에 영향 받는 서비스는 Facebook 산하의 모든 서비스다.

Facebook, Workplace, Oculus, WhatsApp, Instagram, ...

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
반응형

https://www.theverge.com/2021/10/4/22708989/instagram-facebook-outage-messenger-whatsapp-error

 

Facebook is down, along with Instagram, WhatsApp, Messenger, and Oculus VR

It’s always DNS.

www.theverge.com

Facebook down에 관한 새로운 소식이 공유되었다.

앞선 게시글에 추측했던 것 처럼 DNS와 관련된 문제는 맞는 것으로 보인다.

다만, 각 DNS 서버에서 IP가 아예 안 잡히는 경우도 있는 것으로 보아 DNS 서버 자체를 해킹한 것은 아니며 DNS 전파 과정에 개입한 것으로 추정된다.

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
반응형

Status page Unknown

https://status.fb.com/

Unknown은 해당 서버의 상태를 체크할 수 없음을 나타낸다. 즉, 서버 자체의 문제보다는 서버까지 도달하는 경로 상의 문제일 가능성이 높다.

History는 조회가 불가능한 상태이고.. 

https://status.fb.com/adsmanager/history

Facebook, Instagram, WhatsApp 모두 동시에 다운된 것과 facebook.com의 DNS 조회 조차 안되는 것으로 보아 DNS 서버에 공격을 받은 것으로 보인다.

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
반응형

얼마 전 카카오톡 서버가 다운 됐었는데, 이번엔 페이스북과 인스타그램이다.

아직 정확한 원인이 밝혀지진 않았지만 얼마 전 핫했던 페이스북과 관련된 그 기사 때문이 아닐까 생각된다.

* 그 기사: https://www.theverge.com/2021/10/3/22707860/facebook-whistleblower-leaked-documents-files-regulation

 

Facebook encourages hate speech for profit, says whistleblower

The whistleblower made numerous bombshell allegations to 60 Minutes

www.theverge.com

기사는 페이스북이 증오 발언을 부추겼다는 내용을 담고 있다. 해당 아티클로 인해 인터넷 전체가 시끌시끌했고, 이는 현재 진행형이다.

증오 발언을 대부분 그냥 두는 쪽으로 결정하는 이유는, 증오라는 감정이 다른 감정들보다 훨씬 강력해서 유저들 반응을 더 많이 끌어 낸다고 한다. 결국 이렇게 증가한 유저들의 반응은 결국 페이스북의 매출에 영향이 미치기 때문이라 볼 수 있다.

정확한 이유는 페이스북에서 공개해야 알 수 있겠지만 해당 이슈가 핫한 만큼 그에 반감을 가진 해커들의 공격 소행이 아닐까 추정된다.

반응형
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!
반응형

Context

깃헙은 Repository에 Push, Clone 등의 액션을 취할 때 계정을 인증하게끔 되어 있다. public repository라면 설정에 따라 크게 상관없을 수 있으나 private repository 이거나 권한이 엄격히 관리되는 repository라면 인증이 필수적이다.

일반적으로 계정 인증은 계정명/패스워드로 이루어지지만 현재 깃헙에서는 이러한 방식의 인증을 사용할 수 없도록 제한하고 있다.

이를 대체할 수 있는 가장 대표적인 방법이 SSH 인증 방식인데, 많은 사람들이 하나 Mac에서 여러 깃헙 계정을 운영하는 것에 어려움을 겪는 것을 보고 글을 남겨본다. Windows & Linux는 기본적으로 되는 것 같으나 Mac에서는 추가적인 작업이 필요하다.

깃헙 SSH Key 등록

SSH Key를 발급하고 GitHub 계정에 등록하는 과정은 공식 문서(링크)에 자세히 나와있으니 간략하게만 다루겠다. 공식 문서의 과정 중 config 파일 설정은 잠시 생략해도 좋다.

  1. 터미널 실행
  2. GitHub email address를 포함해 아래 명령어 입력
    $ ssh-keygen -t ed25519 -C "your_email@example.com"​
  3. GitHub 계정에 SSH 공개키 등록: 링크

config 파일을 이용한 여러 계정 운용하기

하나의 계정에 대한 ssh 키를 발행하고, GitHub에 공개키 등록까지 마쳤다면, 이제 ssh config 파일을 작성해야 한다.

$ vi ~/.ssh/config

이 곳에 아래와 같은 형태로 작성해주면 된다.

Host github.com
    IdentityFile ~/.ssh/{앞서 생성한 SSH 키 이름}
    HostName github.com
    User {GitHub 사용자명}
    
    
[작성 예시]
Host github.com
    IdentityFile ~/.ssh/github_960813
    HostName github.com
    User 960813

여기까지 완료되었다면 SSH 연동이 완료된 것이다.

이제 Repository를 클론해보자. 일반적인 HTTPS 방식이 아니라 SSH 방식을 사용해야 한다. GitHub Web에서는 Code 버튼을 눌러 URL을 찾을 수 있다.

$ git clone git@github.com:ev-incentive-board/system.git

정상적으로 클론 되었을 것이다.

우리는 여기서 Repository의 URL을 잘 살펴보아야 한다. URL은 크게 3가지 영역으로 구분되는데 이는 다음과 같다.

  • git: SSH 사용자가 git 임을 명시
  • @github.com: SSH를 이용해 액세스하려는 Host
  • ev-incentive-board/system.git: Repository 위치

@github.com 이 핵심이다. 이는 앞서 작성한 config 파일의 Host에 해당하는 부분이다. 즉, 여러 인증서를 사용하려면 이 부분을 적절히 바꿔 원하는 IdentifyFile을 사용하도록하면 된다.

Host github-960813
    HostName github.com
    IdentityFile ~/.ssh/github_960813
    User 960813

Host github-xxxxxxx
    IdentityFile ~/.ssh/github_xxxxxxx
    HostName github.com
    User xxxxxxx

config 파일을 위와같이 설정했다면, repository의 remote-url을 git@github-960813:..... / git@github-xxxxxxx:.... 꼴로 사용하면 정상 동작하는 것을 확인할 수 있을 것이다.

이미 local에서 사용하고 있는 repository라면 아래 명령어를 이용하자.

$ git remote set-url origin git@github-xxxxxx:....
반응형

'Git' 카테고리의 다른 글

여러 깃헙 계정을 SSH 방식으로 사용하는 방법  (0) 2021.10.02
잘못된 내용이 있다면, 다른분들에게 전달되지 않게끔 댓글로 지적 부탁드립니다!

+ Recent posts