카테고리 보관물: Personal projects

연관 컨테이너에 find_if()를 쓴다구요?

연관 컨테이너는 데이터를 추가 할 때 내부에 hash table이나 tree 구조를 유지해서 많은 원소가 삽입 되더라도 원하는 값을 빠른 속도로 검색 하는것이 가능하도록 해준다.

어떤 key가 주어 졌을 때 이것이 정확히 원하는 값이 아니 더 라도 특정한 범위에 들면 해당 Block을 반환하는 코딩을 하고 있었는데, 생각보다 map이나 set 같은 연관 컨테이너에 find_if()로 조건을 주는 코드 레퍼런스들이 많았다. 예를 들면 다음과 같이 주어진 set에 대해 find_if()로 모든 원소들을 돌면서 주어진 key가 들어 갈 수 있는 Block 찾는 것과 같은 경우이다.

find_if(
  s.begin(), s.end(),
  [findKey](const Block* el) {
    return findKey >= el->blkBase \
      && findKey < (el->blkBase + el->blkSize); });

주어진 원소의 수가 얼마 없다면 이런 종류의 코드가 별 무리가 없겠지만, 원소의 수가 많아지면 두드러지는 성능 차이를 보인다. 다음은 이와 같이 find_if()로 모든 원소들을 방문해 가며 range에 속하는지 검사하는 코드를 vector, map, set에 대해서 10만개의 원소로 돌린 것인데, 오히려 vector에 비해 map과 set이 각각 4배에서 6배 정도의 느린 검색 성능을 보여 준다.

[Vector]
100000 items pushed to vector.
Insertion: 13ms
Searching: 28879ms

[Map]
100000 items pushed to map.
Insertion: 63ms
Searching: 120259ms

[Set]
100000 items pushed to set.
Insertion: 60ms
Searching: 193998ms

연관 컨테이너 들은 원소를 추가할 때 효율적인 검색을 위한 부가적인 동작을 수행해야 하므로 insertion에 시간이 조금 더 걸리는 건 그렇다 쳐도, 원소의 수에 따라 선형적으로 검색 시간이 증가하는 vector에 비해 4배에서 6배 정도의 검색 시간이 더 드는 결과는 연관 컨테이너에 대해 find_if()를 들이 대는 자체가 현명한 생각인가 하는 의구심이 들게 한다. 즉, find_if()를 사용하면 주어진 컨테이너의 구조에 맞게 효율적으로 iteration을 해 주고 그런거 없다. 적어도 g++(v7.5.0)에서는.

그렇다면 이 경우 처럼, C++에서 특정한 값이 아니라 주어진 키가 범위에 드는지 검사하고 싶은 경우는 어떻게 해야 할까? Java의 Navigatable* 만큼은 세부적이진 않지만 C++의 map과 set 모두 주어진 key에서 가장 가까운 값을 반환하는 lower_bound() / upper_bound()를 제공한다. 이를 이용해서 다음과 같이 반환된 객체에 대해서만 추가로 검사를 해서 범위에 드는지 확인하면 보다 효율적으로 구현할 수 있다.

auto re = s.lower_bound(&findBlk);
auto el = *re;
if (re != s.end()
    && (findKey >= el->blkBase && findKey < (el->blkBase + el->blkSize))) {
}

이렇게 find_if()로 모든 원소들을 방문하는 것이 아닌, lower_bound()로 반환 받은 결과만 검사하는 방법으로 위와 같은 10만개의 원소에 대해 돌려보면 기대했던 바와 같이 vector보다 훨씬 좋은 연관 컨테이너의 검색 속도를 볼 수 있다.

[Vector]
100000 items pushed to vector.
Insertion: 13ms
Searching: 29765ms

[Map]
100000 items pushed to map.
Insertion: 62ms
Searching: 35ms

[Set]
100000 items pushed to set.
Insertion: 62ms
Searching: 36ms

시험에 사용한 전체 코드는 GitHub Gist에 붙여둔다.

Lightsail Ubuntu 20.04 업그레이드 후 ssh 접속 불가 현상

Lightsail의 이미지를 Ubuntu 20.04 LTS로 업그레이드 한 후 web 환경에서 SSH 접속이 되지 않아서 또 망했다며 머리를 쥐어 뜯고 있는데, 우연히, 당연히 안 될 거라고 생각했던 터미널 프로그램을 통한 SSH 접속은 또 되는 기현상을 발견했다. 이 대로도 나쁘진 않지만 좀 찜찜 하기도 하고 해서 좀 더 찾아 보았다.

접속 오류가 발생할 때의 로그를 보면 다음과 같은데,

$ cat /var/log/auth.log|tail
...
sshd[4528]: userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]
...

이 문제의 해결책에 대해 아주 자세히 설명된 Use RSA CA Certificates with OpenSSH 8.2에 따르면, (Ubuntu 20.04에 포함된) OpenSSH 8.2 부터는 보안 문제로 SHA-1 기반인 ssh-rsa가 기본 CA signature 항목에서 빠지면서 이러한 문제가 발생하게 된다고 한다. 해결 방법은 CASignatureAlgorithms에 ssh-rsa를 지원하도록 명시하는 것이다.

$ cat /etc/ssh/sshd_config|tail
...
# Use RSA CA cert.
# https://ibug.io/blog/2020/04/ssh-8.2-rsa-ca/
CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

위의 링크에서 제안하는 대로 sshd_config 파일에 CASignatureAlgorithms 항목을 위와 같이 추가 하고 sshd service를 재 실행 하고나니, web 환경 SSH가 잘 동작하게 되었다. 물론, 터미널도 그대로 잘 된다.

Lightshail Ubuntu 배포판 업그레이드 후 ssh 접속이 안된다.

망했다! Litghtsail의 Ubuntu 배포판이 너무 오래전 것이라 콘솔에 접근해서 조심스럽게 screen session도 새로 만들어 가면서 업그레이드를 했는데 끝나고 나니 SSH가 안된다. 아마도 중간에 SSH관련 환경설정을 파일을 변경할 것인지 묻는 선택메뉴가 나왔는데, 현재 설정을 그냥 쓰겠다고 했던게 문제인것 같다. 다행히 blogging service는 잘돌아 가고 있지만 SSH가 안되면 서버관리를 할 방법이 없는데…

Workaound

다행히 세상은 생각보다 넓고 인간은 같은 실수를 반복하기에 이전에 같은 실수를 한 사람의 비슷한 경험을 정보의 바다에서 찾을 수 있었다 (SSH stops working after upgrade to Ubuntu 18.04 on AWS Lightsail). 대충 Ubuntu 18.04 LTS로 올라가면서 SSH 환경설정 파일에 변경이 있었는데 메인테이너 버전을 적용하지 않으면 문제가 되는가 보다. 이 포스팅은 위의 링크에 있는 내용을 기준으로 정리한 것이다. (Lightsail 한정이고 EC2를 사용하고 있다면 아래와 같이 번거로운 작업을 할 필요가 없다고 한다)

순서 요약

  1. SSH접속이 안되는 instance로 부터 스냅샷을 하나 만든다.
  2. 스냅샷의 시작 스크립트에 ssh 환경설정을 수정하는 명령어를 넣고 새로운 인스턴스를 만든다.
  3. 잘 되면 새로운 인스턴스를 고정 IP에 연결하고 이전 인스턴스를 지운다.

스냅샷 생성

SSH 접속이 안되는 인스턴스로 부터 스냅샷을 하나 만든다. 관리 -> 스냅샷 수동 스냅샷 아래의 ‘+ 스냅샷 생성’을 클릭.

생성이 완료될 때까지 조금 기다렸다가 이 스냅샷으로 부터 새로운 인스턴스를 하나 만든다.

시작 스크립트를 추가하고 인스턴스를 실행

새 인스턴스 생성 메뉴에 보면 “시작 스크립트”를 넣는 곳이 있는데 이곳을 선택하고 ssh config를 변경해 줄 다음의 sed 명령어를 입력한다.

sudo sed -i 's/^Ciphers .*/Ciphers +aes256-cbc,aes192-cbc,aes128-cbc/' /etc/ssh/sshd_config
sudo service sshd stop
sudo service sshd start

그리고 나서 인스턴스를 실행하면 처음에는 여전히 SSH 접속이 되지 않는데, 꽤 오랜 시간 (10~20분)이 지나고 나서야 가능해 진다.

고정 IP 변경과 정리

네트워킹 -> Static IP에서 고정 IP를 분리하고 새로운 인스턴스에 새로 연결해 준다.

새로운 인스턴스를 고정 IP에 할당 한 후 기존 서버를 끄고 도메인에 접속해서 잘 돌아가는 지 확인한 후 스냅샷과 기존 인스턴스를 지워준다. 스냅샷 생성 기능은 예전에 한 번 백업용으로 좋겠다 싶어서 만들어 봤다가 추가 요금이 나온적이 있다. 🙁

결론

다음 부터는 이미지를 업데이트 하고 싶을 땐 먼저 백업을 만들어서 작업 및 확인하고 최종으로 IP를 변경 하도록 하자.

TensorFlow에서 CUBLAS_STATUS_NOT_INITIALIZED 오류 문제

failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED

이 문제는 TensorFlow의 GPU memory growth 설정과 관련이 있다. 이 경우 GPU의 allow_grouth option을 True로 설정하면 문제를 해결할 수 있는데, Use a GPU 페이지에 따르면 tf.config.experimental.set_memory_growth()를 통해 True로 설정하거나 혹은 환경변수 TF_FORCE_GPU_ALLOW_GROWTH를 설정해서 해결 할 수 있다.

코드에 다음과 같이 환경 변수를 설정해 줄 수도 있지만,

# Fix CUBLAS_STATUS_NOT_INITIALIZED error.
#  - failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED
os.environ [ "TF_FORCE_GPU_ALLOW_GROWTH" ] = "true"

실행 환경에 따라 문제가 발생하지 않을 수도 있어서, 나는 주로 command line에서 다음과 같이 script를 실행할 때 이 값을 함께 설정한다.

# Command terminal
TF_FORCE_CPU_ALLOW_GROWTH=true flask run --host=0.0.0.9 

Transpose convolution의 출력 크기

Keras의 transpose convolution 2D (Conv2DTranspose) 레이어로 DCGAN을 실습해보고 있었는데 generator가 생성해야 하는 image가 나누다 보면 소수(prime number)가 되는 직사각형 크기인 178×218 였다.

많은 예제 코드들에서 transpose convolution 2D의 padding을 “same”으로 지정하기 때문에 Conv2DTranspose의 출력 크기는 stride의 배수여야 한다고 오해 했었는데, 실은 padding을 “same”으로 설정하느냐 혹은 “valid”로 설정하느냐에 따라 출력의 크기가 다음과 같이 달라진다.

# padding을 ‘same’으로 설정 했을 때
Output = Input \times stride

# padding을 ‘valid’로 설정 했을 때
Output = (Input - 1) \times stride+ filter

예를 들어 다음 layer를 선언하고 (44, 54, 3) tensor를 주면 소수 값의 (89, 109, 64) tensor가 출력된다.

# padding을 “valid”로 설정
Conv2DTRanspose(64, kernel_size=3, strides=2, padding=‘valid’)