Visual Studio 에서 C++ 로 사용하기 위한 protobuf 설치

구글 protobuf 를 새로 개발하고 있는 서버에 적용해보려고 찾아보았다. 설치에 대한 링크는 구글 Protocol Buffer VS 설치라는 글이 보였는데 2015년에 작성된 글이라 그런지 지금과 맞지 않았다. vsproject라는 폴더가 있다고 하는데 이런 폴더 자체가 없었으니.

그래서 새로 빌드해보기로 하고 그 과정을 정리해본다.

구글 protobuf 홈페이지로 이동한다.

https://github.com/google/protobuf/

C++에서 사용하기 위해 Protobuf Runtime Installation 항목으로 이동했더니 src 폴더로 가보라고 되어있다.

https://github.com/google/protobuf/tree/master/src 에 가서 밑의 README.md 파일 내용을 읽어보니 C++ Installation – Windows 항목이 있어 이 내용을 읽어본다.

If you only need the protoc binary, you can download it from the release page:

https://github.com/google/protobuf/releases

In the downloads section, download the zip file protoc-$VERSION-win32.zip. It contains the protoc binary as well as public proto files of protobuf library.

To build from source using Microsoft Visual C++, see cmake/README.md.

To build from source using Cygwin or MinGW, follow the Unix installation instructions, above.

안내문에서 지시하는대로 cmake/README.md 파일을 열어보았다.

https://github.com/google/protobuf/blob/master/cmake/README.md

환경설정을 진행하고 cmake를 다운로드한다. 구글에서 cmake 를 검색하여 Win64용의 cmake 프로그램을 설치.

이미 윈도우용 git이 설치되어 있으므로 VS2015용 개발자 명령 프롬프트창을 열고 라이브러리를 모아놓은 폴더에 가서 소스를 다운 받는다. 릴리즈 버전은 지금 최신버전인 3.5.0 으로 받았다. 개발자 명령 프롬프트가 아니라 cmd 창으로 열면 컴파일러인 cl.exe가 인식이 안되기 때문에 오류가 난다.

git clone -b v3.5.0 https://github.com/google/protobuf.git

폴더가 만들어지면 그 안으로 들어가서 gmock 도 받는다.

git clone -b release-1.7.0 https://github.com/google/googlemock.git gmock

그 안으로 들어가 googletest 코드도 받는다.

git clone -b release-1.7.0 https://github.com/google/googletest.git gtest

protobuf를 받은 위치에서 cmake 라는 폴더를 들어간다. 이 밑에 build 라는 디렉토리를 만들고 그 밑에 debug, release, solution 이라는 3개의 디렉토리를 만든다.

debug 폴더로 이동하여 다음 명령 실행

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../../../../install ../..

release 폴더로 이동하여 다음 명령 실행

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=../../../../install ../..

solution 폴더로 이동하여 다음 명령 실행

cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_INSTALL_PREFIX=../../../../install ../..

설명서에는 Visual Studio 12 2013 으로 설명되어 있지만 난 VS2015를 사용하므로 그에 맞도록 수정했다.

빌드하기 위해 release 폴더혹은 debug 폴더에서 nmake 명령과 nmake check 명령을 차례대로 실행한다.

nmake check 이후 아무 문제 없다면 nmake install 을 진행하면 되나 나같은 경우에는 아래와 같은 에러메시지가 떴다.

[----------] Global test environment tear-down
[==========] 2009 tests from 194 test cases ran. (54957 ms total)
[  PASSED  ] 2001 tests.
[  FAILED  ] 8 tests, listed below:
[  FAILED  ] CommandLineInterfaceTest.Win32ErrorMessage
[  FAILED  ] BootstrapTest.GeneratedDescriptorMatches
[  FAILED  ] CsharpBootstrapTest.GeneratedCsharpDescriptorMatches
[  FAILED  ] RubyGeneratorTest.GeneratorTest
[  FAILED  ] TokenizerTest.ParseString
[  FAILED  ] TextFormatMapTest.Sorted
[  FAILED  ] TextFormatTest.Basic
[  FAILED  ] TextFormatExtensionsTest.Extensions

이 에러메시지를 해결하기 위해 구글에 검색해봤지만 딱히 좋은 대안은 찾지 못했다. 자연스러운 에러메시지(?)라는 글도 있긴했다.

빌드가 완료되면 lib 파일들과 헤더파일들이 생성되는데 이 생성되는 위치가 protobuf 폴더 바로 위의 install 이라는 폴더에 생성된다.

lib 파일을 비주얼스튜디오에 연결하고 헤더파일을 가져다 사용하면 된다. 이에 대한 내용은 Protobuf 실제 사용글을 참조하면 된다. 아니면 검색엔진에 검색해봐도 많이 나온다.

자세한 사용방법은 protobuf 홈페이지에서. https://developers.google.com/protocol-buffers/docs/cpptutorial

MySQL 라이브러리 사용시 config.h 파일 문제

리눅스에서 빌드시 다음과 같은 오류가 있었다.

In file included from /root/DServer2/src/dserver/protocol/../../dserver/database.h:6:0,
from /root/DServer2/src/dserver/protocol/../../dserver/define.h:41,
from /root/DServer2/src/dserver/protocol/base_protocol.h:3,
from /root/DServer2/src/dserver/protocol/base_protocol.cpp:1:
/root/Library/mysql-connector-c++-1.1.9/cppconn/resultset.h:30:20: fatal error: config.h: 그런 파일이나 디렉터리가 없습니다
#include "config.h"
^

config.h 파일이 없다는 에러 메시지인데 cppconn 디렉토리를 살펴보면 config.h.cm 파일이 있다.

mysql 커넥터를 다운 받은 디렉토리로 가서 cmake를 실행한다. 실행이 되지 않는다면 yum 으로 cmake를 설치한다.

[root@localhost Library]# cmake mysql-connector-c++-1.1.9
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Could NOT find Boost
-- Could NOT find Boost
CMake Error at CMakeLists.txt:194 (MESSAGE):
Boost or some of its libraries found. If not in standard place please set
-DBOOST_ROOT:STRING=


-- Configuring incomplete, errors occurred!
See also "/root/Library/CMakeFiles/CMakeOutput.log".
[root@localhost Library]#

https://dev.mysql.com/doc/connector-cpp/en/connector-cpp-installation-source-unix.html 를 참조했다.

https://dev.mysql.com/doc/connector-cpp/en/connector-cpp-source-configuration-options.html 를 읽어봤더니 BOOST 경로를 설정해줘야한다.

/etc/profile 에 BOOST_ROOT 경로를 지정한다.

export BOOST_ROOT=/부스트경로/

다시 cmake를 실행했다.

[root@localhost mysql-connector-c++-1.1.9]# cmake .
-- Boost version: 1.65.1
-- BOOST_INCLUDE_DIRS=/root/Library/boost_1_65_1
-- You will link dynamically to the MySQL client library (set with -DMYSQLCLIENT_STATIC_LINKING=<bool>)
-- Searching for dynamic libraries with the base name(s) "mysqlclient_r mysqlclient"
CMake Error at FindMySQL.cmake:531 (message):
Could not find "mysql.h" from searching "/usr/include/mysql
/usr/local/include/mysql /opt/mysql/mysql/include
/opt/mysql/mysql/include/mysql /usr/local/mysql/include
/usr/local/mysql/include/mysql /MySQL/*/include /MySQL/*/include"
Call Stack (most recent call first):
CMakeLists.txt:252 (INCLUDE)


-- Configuring incomplete, errors occurred!
See also "/root/Library/mysql-connector-c++-1.1.9/CMakeFiles/CMakeOutput.log".
[root@localhost mysql-connector-c++-1.1.9]#

mysql 라이브러리 파일이 있어야한다고 나온다. CentOS 7에서는 MySQL이 빠지고 그대신 MariaDB가 들어가 있기 때문에 mariadb-libs 와 mariadb-devel 을 yum으로 설치해준다.

다시 cmake 하니…

[root@localhost mysql-connector-c++-1.1.9]# cmake .
-- Boost version: 1.65.1
-- BOOST_INCLUDE_DIRS=/root/Library/boost_1_65_1
-- You will link dynamically to the MySQL client library (set with -DMYSQLCLIENT_STATIC_LINKING=<bool>)
-- Searching for dynamic libraries with the base name(s) "mysqlclient_r mysqlclient"
-- mysql_config was found /usr/bin/mysql_config
-- MySQL client environment/cmake variables set that the user can override
--   MYSQL_DIR                   :
--   MYSQL_INCLUDE_DIR           : /usr/include/mysql
--   MYSQL_LIB_DIR               : /usr/lib64/mysql
--   MYSQL_CONFIG_EXECUTABLE     : /usr/bin/mysql_config
--   MYSQL_CXX_LINKAGE           :
--   MYSQL_CFLAGS                : -I/usr/include/mysql
--   MYSQL_CXXFLAGS              : -I/usr/include/mysql

(...중략...)

-- Configuring performance test - statement
-- Configuring bugs test cases - unsorted
-- Configuring unit tests - group template_bug
-- Configuring done
CMake Warning (dev) in driver/CMakeLists.txt:
  Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
  interface.  Run "cmake --help-policy CMP0022" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target "mysqlcppconn" has an INTERFACE_LINK_LIBRARIES property which
  differs from its LINK_INTERFACE_LIBRARIES properties.

  INTERFACE_LINK_LIBRARIES:

    mysqlclient;pthread;z;m;ssl;crypto;dl

  LINK_INTERFACE_LIBRARIES:



This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /root/Library/mysql-connector-c++-1.1.9
[root@localhost mysql-connector-c++-1.1.9]#

이제서야 완료. config.h 파일이 정상적으로 생성되었다.

InitializeCriticalSectionAndSpinCount, CriticalSection에 대한 정보 이것저것

개인적으로 만들고 있는 프로젝트, 프로그램들은 대부분 리눅스/윈도우간의 크로스플랫폼을 지향하고 있는데 그래서 그런지 락을 쓸 때는 std::mutex를 자주 쓰고 있다.

최근에는 윈도우의 critical section이 더 빠르다는 얘기가 자꾸 들려서 윈도우일 때는 critical section을 더 쓰도록 변경하는 중.

그러다가 InitializeCriticalSection 이라는 초기화함수 대신 InitializeCriticalSectionAndSpinCount 라는 함수를 보게 되었는데 이게 무엇인지 찾아보았다. 이 함수의 인자는 2개인데 첫번쨰는 당연히 크리티컬섹션 객체의 포인터이고 뒤에 붙는 인자는 스핀 횟수이다.

어떤 스레드가 작업을 하다가 크리티컬섹션에 걸려서 InitializeCriticalSection 을 썼다면 대기상태에 들어가게 된다. InitializeCriticalSectionAndSpinCount 를 썼다면 바로 대기상태에 들어가지 않고 인자로 줬던 SpinCount 횟수만큼 기다리게 된다. 만약 그 사이에 크리티컬섹션이 풀리면 바로 다시 작업 진행. SpinCount 횟수만큼 기다렸는데도 크리티컬섹션이 풀리지 않았다면 대기상태로 들어간다.

InitializeCriticalSectionAndSpinCount는 멀티프로세서 시스템에서만 유효하며 싱글프로세서 시스템에서는 뒤에  SpinCount 값은 무시되고 0으로 설정된다. 멀티프로세서 시스템인 경우, 크리티컬섹션에 걸려 대기에 들어가지 않으므로써 스레드간 Context Switching이 적어지므로 결과적으로 InitializeCriticalSection 을 사용할 때보다 성능이 더 나아질 수 있다.

또한 InitializeCriticalSection 의 리턴은 void 이기 때문에 크리티컬섹션 초기화가 제대로 되었는지 알 수가 없다. 메모리 부족 상황 등에서 초기화 실패가 일어날 수 있고 이 경우 InitializeCriticalSection 함수 부분에서 exception이 일어나게 되어 추적하기 힘든 버그가 발생할 수 있다. InitializeCriticalSectionAndSpinCount 함수는 리턴값이 있고 이러한 버그 상황을 피할 수 있도록 만들어준다.

예제 코드

CRITICAL_SECTION g_cs;
int main()
{
    if (!InitializeCriticalSectionAndSpinCount(&g_cs, 4000))
    {
        // 예외 처리
    }
    ...
}
// [출처] [VC++] 크리티컬 섹션 초기화 관련 간단 팁|작성자 데브머신

이와 관련하여 스핀카운트의 단위가 무엇인지, 스레드 컨텍스트 스위칭이 이루어지지 않고 크리티컬섹션이 풀릴 때까지 어디서 어떻게 기다리는지 더 알아보고 싶지만 구글을 뒤져봐도 자료가 없는듯하다.

<참고자료>

메모리복사시 침범 문제

boost asio를 이용하여 코드를 작성 중에 다음과 같은 부분이 있었다.

클래스의 멤버변수로 네트워크 처리에 사용할 버퍼를 만들고 변수를 생성한 코드다.

class BasicSocket : public std::enable_shared_from_this<BasicSocket>
{
// 중략
protected:
    std::shared_ptr<Socket> socket_ptr_;

    Socket socket_;

    char packet_buffer_[RECV_BUFFER_SIZE * 2];
    int32_t remain_size_;

    char recv_buffer_[RECV_BUFFER_SIZE];
    char send_buffer_[SEND_BUFFER_SIZE];
};

이후 이 변수들을 사용해서 다음과 같은 코드를 작성했다.

std::cout << "OnReceive 1 remain_size_:" << remain_size_ << " - bytes_transferred:" << bytes_transferred << std::endl;

// 패킷을 담아둘 버퍼에 수신버퍼의 내용을 복사한다.
memcpy(&packet_buffer_[remain_size_], recv_buffer_, bytes_transferred);

std::cout << "OnReceive 2 remain_size_:" << remain_size_ << " - bytes_transferred:" << bytes_transferred << std::endl;

데이터 수신 후 처리하는 부분인데 단순히 packet_buffer에 memcpy를 하기만했는데 remain_size의 값이 변화한다는 사실.

위에서 출력된 remain_size와 밑에서 출력된 remain_size의 값이 다르다는 것이었다. 더 문제는 이 출력이 어떤 경우에는 정상적이고 어떤 경우에는 다르게 출력되었다. remain 값을 변화시키는게 없는데 왜 그럴까 한참 살펴보다가 VS2015의 메모리 디버거를 보다가 허탈하게 이유를 알아냈다.

remain_size가 할당된 위치가 packet_buffer의 바로 다음 메모리 공간이었다. 메모리 복사시, recv_buffer와 packet_buffer 크기가 같고 remain_size가 0보다 크다면, packet_buffer 바로 다음 메모리 공간(=remain_size가 할당된 위치)까지 메모리 복사가 일어나서 오염되었던 것.

그런데 이와 동일한 코드를 쓴 다른 서버는 같은 코드임에도 에러가 일어나지 않았다. 같은 코드더라도 프로그램마다 메모리 공간 할당이 다르게 이루어진다는 것으로 이해해야할까.

boost::property_tree의 위험성

.ini 파일을 파싱하기 위해 boost::property_tree 클래스를 사용했었다.

서버의 성능을 테스트하던 도중 어디사 CPU를 많이 잡아먹나 계속 테스트했는데 네트워크 전송 부분이 계속 문제였다. 아무리 수정을 해도 고쳐지지 않는 상황. 비주얼스튜디오의 성능프로파일러를 돌려보니 boost::property_tree 가 문제의 원인이었다. 환경설정에서 특정한 값을 가져오기 위해 쓰느 코드가 네트워크 속도를 느리게 만드는데 기여하고 있었다.

이 부분을 수정하고나니 CPU 점유율이 아주 낮아졌다.

boost를 마구 쓰면 안된다는걸 깨닫게되었네.

boost에서 메모리풀 사용

프로그램 구현 중 메모리풀이 필요한 경우가 있어 어떻게 할까 하다가 boost의 메모리풀을 찾아보게 되었다.

boost의 메모리풀은 4가지.

  1. pool
  2. singleton_pool
  3. pool_alloc
  4. object_pool

네가지 메모리풀 중에 어떤 것이 어떤 상황에 가장 적합한지는 많이 써봐야 알 수 있을듯하다. 찾아보니 내가 가지고 있던 몇몇 게임서버 소스는 singleton_pool을 사용하고 있는 케이스가 있었다. 이것부터 먼저 찾아보는 것으로.

singleton_pool은 다른 메모리풀 클래스들과는 다르게 스레드-세이프 특성을 지니고 있어서 가장 유용하게 쓰일 것 같다.

singleton_pool을 아래와 같은 코드로 좀더 편하게 사용 가능. 출처는 ‘아지크의 좌충우돌 IT 이야기’

#include <stdio.h>
#include <iostream>
#include <vector>
#include <boost/pool/singleton_pool.hpp>
#include <boost/pool/pool_alloc.hpp>


template<typename T,  unsigned int NEXT_SIZE = 32U, unsigned int  MAX_POOL_SIZE = 0U>
class CMemoryPoolT
{
public:
     static void* operator new(size_t size)
     {
          return boost::singleton_pool<T,
               sizeof(T),
               boost::default_user_allocator_new_delete,
               boost::details::pool::default_mutex,
               NEXT_SIZE,
               MAX_POOL_SIZE>::malloc();
     }

     static void operator delete(void* p)
     {
          boost::singleton_pool<T,
               sizeof(T),
               boost::default_user_allocator_new_delete,
               boost::details::pool::default_mutex,
               NEXT_SIZE,
               MAX_POOL_SIZE>::free(p);
     }
};


class CMemoryPoolTest  :public CMemoryPoolT<CMemoryPoolTest>
{
public:
     char Dumy[124] ;
};


int _tmain(int argc, _TCHAR* argv[])
{
     using std::vector ;

     CMemoryPoolTest *p = new CMemoryPoolTest() ;

     delete p ;

     printf("Using MemoryPool... \n") ;


     return 0;
}

프로그램 종료시에는 purge_memory()를 꼭 호출해주어야 한다고 한다.

혹은 다음과 같은 방법으로도 사용 가능하다.

struct SEND_BUFFER_TAG {};
typedef boost::singleton_pool<SEND_BUFFER_TAG, SEND_BUFFER_SIZE> SendBufferPool;

사용할 클래스의 헤더파일에서 위와 같이 선언. TAG를 여러개 사용하고 메모리풀마다 다르게 적용하면 서로 다른 메모리풀이 된다.

메모리를 할당 받고 싶다면,

char* send_data = static_cast<char*>(SendBufferPool::malloc()); // 메모리를 할당 받는다.

SendBufferPool::free(send_data); // 다 사용한 메모리를 해제한다.

종료시에는 당연히,

SendBufferPool::purge_memory();

를 호출해야한다.

출처와 참고사이트

 

Github 에서 내용에서 민감한 정보 삭제하기

github에 소스코드를 올리면서 중요한 코드를 삭제하지 않고 올렸다는걸 나중에서야 알게되었다. github에서 코드를 지워야하는 상황.

구글에 검색해보니 몇가지 답이 나왔다. 명령어를 입력해서 처리하는 방법과 bfg라는 툴을 이용하는 방법 두가지가 있는데 일단 bfg는 좀 귀찮았고(많은 설명들에서 bfg가 무엇인지 안나와있는데 github에서 bfg를 검색해보면 된다.) 명령어를 입력해서 처리해보기로 결정.

여튼 검색된 문서의 이런저런 방법대로 해봐도 잘 안되서 마지막은 github에서 공식적으로 안내된 문서대로 해보았더니 바로 적용되었다. (https://help.github.com/articles/removing-sensitive-data-from-a-repository)

일단 삭제할 내용이 포함된 파일을 백업한 다음, 입력할 명령어는 다음과 같다.

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch 삭제될파일의_전체경로' --prune-empty --tag-name-filter cat -- --all

이것을 입력하고 일단 무언가 텍스트들이 잠시 지나가길 기다린 다음, 마지막으로 push를 하면 된다. 삭제될 파일의 경로는 정확하게 경로 모두와 파일명 전부를 적어줘야한다.

git push origin --force --all

그리고 나면 해당 파일이 삭제되어 있다. 백업했던 파일을 수정한 다음 원래 위치로 다시 복구하고, add, commit, push를 차례대로 해준다.

그러면 복구 완료.

lightsail 로 서버 이전 후기

계속 사용해오던 cloudv의 가상서버에서 aws의 새로운 서비스인 lightsail로 이전했다.

굳이 웹호스팅을 쓰지 않고 가상서버로 구성해서 사용하는 것은 git 저장소도 한몫했는데 일단 혼자서 사용하다보니 뭐하러 이런걸 해야하나…라는 회의감과 그럴거면 차라리 github에서 사람들과 같이 코드를 만들고 올리고 하는게 더 낫겠다는 생각이 들었기 때문이었다. 그래서 차라리 웹데이터들은 더 저렴한 lightsail로 이전하고 git 데이터들은 github.com 으로 이전하기로 했다.

lightsail은 사용해보니 그냥 흔히 알고있는 가상서버다. 우리나라에서는 이미 많이 서비스하고 있는.

그런데 가격이 생각보다 싸다. 내 경우에는 월 5달러의 제일 저렴한 리눅스 서버로 골랐다. 메모리 512MB에 20GB의 디스크다. 디스크야 어차피 git 데이터가 github로 넘어간 이상 많이 필요치 않았지만, 너무 적은 메모리와 알 수 없는 cpu 성능 때문에 고민을 했다. 고민 끝에 최대한 메모리를 적게 쓰도록 아파치를 쓰지 않고 nginx로 쓰기로 했다.

그리고 어차피 방문객이 많지도 않고 방문객이 많으면 인스턴스를 늘리면 끝이니까.

bitnami의 여러 스택이 있었는데 사용하기 편하게 wordpress 스택을 선택하려 했지만 이 경우에는 멀티사이트를 만들기에 불편할 것 같아서 그냥 nginx 스택을 선택하고 직접 설정해서 아내의 홈페이지와 내 블로그 두개를 설치했다. nginx 설정 파일이 익숙치 않아서 약간 헤매었지만 금방 적응했다. bitnami류의 패키지 시스템이 마음에 들지 않았지만 직접 써보니 생각보다 괜찮았다. 멀티앱/멀티사이트간 여러 설정 파일들이 서로 꼬이지 않게 잘 정리되어 있었다. (물론 그런 이유로 인해 뭔가 하나 고치려면 한참 경로를 타고 들어가야 한다는건 불편하다.)

여튼 그렇게 설치하고 아파치에서 nginx로 변경했는데 와우… 속도가 생각보다 괜찮았다. 내가 아파치로 혼자 가상서버를 쓰는 것보다 훨씬 빨랐다.

접속방법에서 약간의 불편함은 있지만 어차피 접속할 일도 별로 없고… 게다가 1TB의 트래픽은 트래픽 걱정할 필요는 아예 없을만큼 정말 여유로웠다.

며칠간 여러 데이터들을 이전해본 후기

  1. 생각보다 속도가 빠름.
    도쿄 리전이고 가상서버에다가 메모리도 겨우 512MB라서 느릴 것으로 예상했지만 기존 서버보다 훨씬 빠른 느낌. 아파치와 엔진엑스의 차이인지도…
  2. 시간대 재설정 필요함.
    설치하게 되면 서버 시간을 한국에 맞춰야한다. ( https://gist.github.com/dongbum/1673616e33fb331ff8e876ee62216988 으로 저장해둔다.)
  3. 설정파일 트리구조를 잘 파악해둘 것.
    엔진엑스에 익숙치 않거니와 구조가 좀 복잡하긴하다.
  4. DNS 응답 속도가 아주 빨라짐.
    BIND나 PowerDNS로 네임서버를 직접 구성해서 썼었는데 그렇게 쓰는것보다 lightsail에서 제공하는 DNS의 응답속도가 훨씬 속도가 빨랐다. 거의 100배 정도.
  5. lightsail의 DNS는 Route 53과 약간 다름.
    lightsail에서도 300만 쿼리까지는 무료로 DNS를 제공해주는데 사용하기는 너무 편하게 되어있지만 기능적인 면에서는 Route 53 보다는 떨어진다.
  6. 512MB의 메모리로도 충분함.
    가장 저렴한 512MB 메모리의 인스턴스로도 블로그와 몇가지 개인서비스를 운영하는데에는 차고 넘치는 느낌이다.
  7. 사용상 몇가지 불편함이 있음.
    bitnami 패키지의 특성인지 보안을 위해 암호 같은게 어렵게 설정되어 있어서 약간 불편함. 암호를 일일히 바꾸고 쓰기보다는 그냥 쓰기로 결정했다.

공구통 물품 선택

지난 제주도 라이딩에서 공구통을 통째로 잃어버렸다.

호텔 지하 계산에 자전거를 묶어둔 후 다음날 잃어버린 것. 자전거에 공구통을 꽂아놓고 왔는데 누가 훔쳐간 것인지 내가 잃어버린 것인지는 나도 모르겠다. 사실 기억이 잘 안난다.

지난번 공구통을 사용하며 느낀 점과, 펑크를 수리해보며 느낀 것을 종합해보면,

  • 토픽 헥서스는 다양한 기능을 할 수 있는 도구이지만 너무 무거웠다.
  • 실제로 쓰는 물건은 튜브와 타이어레버였다.
  • 헥서스에 있는 육각렌치는 렉서스 모양 때문에 좁은 곳에는 들어가질 않아서 쓸일이 잘 없었다. 예를 들면, 물통케이지를 장착하려고 했는데 물통케이지 사이로 넣기에는 부피가 너무 커서 힘들었다. 휴대하고 다니기에는 무게만 무겁고 정작 쓰기에는 불편한 계륵 같은 아이템.
  • 그러니까 차라리 긴 육각렌치 한두개가 낫겠다.
  • 하지만 난 카본 자전거니까 토크렌치로 조여야할 일이 많을꺼다. 정식 토크렌치보다는 토크키 한개 정도면 적당할듯하다.
  • 물티슈보다는 차라리 일회용 장갑을 가지고 다니는게 낫다. 물티슈는 손에 묻은 기름때가 잘 지워지지 않는다.

그래서 다시 구입해야할 물품들을 정리해본다.

공구통 – 토픽, 비엠웍스 등 많은 브랜드가 있음. 사실 거기서 거기인듯하다. 지금 보기에는 비엠웍스 제품이 제일 좋아보인다.

육각렌치 – 파크툴 제품으로 구입 예정. 많은거 필요 없고 길면 될것 같다. 2/3/4/5 정도만 있어도 될듯.

타이어레버 – 어느 제품이나 상관 없을듯하다. 하지만 3개짜리 세트 구입 필요. 파크툴 제품이 제일 괜찮아 보인다.

체인링크 플라이어 – 공구통에 넣고 다닐 물건은 아니지만 집에서 사용할 예정인 도구. 슈퍼비 TB-3323 체인링크 플라이어 구입 예정. 체인링크 분리 외에도 결합시에도 사용 가능하다.

장갑 – 기존에 사두었던 실리콘 재질 장갑을 써도 되고 코스트코에서 파는 장갑을 사다 써도 좋을 것 같다. 물티슈 빼고 장갑이나 하나 넣어야지.