ここに全て書いてあった。
go: Using environment variables in configuration files - M. Tarık Yurt
ioutilでReadFileした後に、string型にしてos.ExpandEnvを一回噛ませて、Unmarshalすればよいだけ。超簡単。 つまりこんな感じ。
func LoadFile(filename string, v interface{}) error { content, err := ioutil.ReadFile(filename) if err != nil { return err } expandContent := []byte(os.ExpandEnv(string(content))) err = yaml.UnmarshalStrict(expandContent, v) if err != nil { return fmt.Errorf("parsing YAML file %s: %v", filename, err) } return nil }
先人の知恵に感謝。
Hiveによってデータを洗い替えする際の処理パターンを検討する
Hive、というよりHDFSにおいてデータはimmutableな物として扱ったほうが良い。 パフォーマンスの観点から追記や更新を表現するような処理パターンは避けた方が無難である。 なぜならHDFSはHDD上に大量のデータをシーケンシャルに一気に書き込む事でパフォーマンスを稼ぐ事を前提に設計されているためである。 追記のような処理あるいは部分更新を実現するために過剰なパーティション構造にすると、細分化されたファイルが大量にできる。 細分化されたファイルはランダムリードの増加やNameNodeの負荷増加に繋がる。 更新や追記をヘビーに使いたい用途においてはHBaseやKuduを使った方が良い。 しかし、処理によってはどうしてもHDFS上のデータを更新したいケースが出てくる。
そういたケースでは、対象のデータあるいはパーティションをまるっと作り直した方が、参照のパフォーマンスは良くなる。 もちろん対象のデータセットのサイズにもよるが、十分大きいクラスタであれば大概のデータは作り直せる。
前提として対象データはExternalテーブルとする。 まず対象データのDDLにおいて通常の処理で利用するパーティション階層に加えてversionというパーティションを加える。
CREATE EXTERNAL TABLE access_log ( remote_host STRING, ident STRING, user STRING, time STRING, raw_request STRING, respons_code INT, byte INT, referrer STRING, user_agent STRING, response_time_microsecond INT, host STRING ) PARTITIONED BY(dt STRING, version STRING) STORED AS ORC LOCATION '/data/kanga333/access_log/';
そして適当なクエリでデータを挿入する。（以下のクエリは一例。わかりやすさのためdtを明示的な値として渡している）
FROM access_log_origin INSERT OVERWRITE TABLE access_log partition(dt, version) SELECT *, '20180101', '1';
作成したテーブルはHDFSから見ると以下のようなディレクトリ構造となる。
/data/kanga333/access_log/dt=20180105/version=1
この状態において以下のクエリを実行し、HDFS上にエイリアスのパーティション’latest’を作成する。
ALTER TABLE access_log ADD PARTITION (dt = '20180101', version = 'latest') location '/data/kanga333/access_log/dt=20180101/version=1'
基本的に該当テーブルに対する参照クエリはversionパーティションをlatestに指定してクエリを実行する。
SELECT count(*) FROM access_log WHERE dt = '20180101' AND version = 'latest'
データを作り直したくなった場合はversionパーティションをインクリメントして新しいパーティションを作成する。
FROM access_log_origin INSERT OVERWRITE TABLE access_log partition(dt, version) SELECT *, '20180101', '2';
その後、latestパーティションの向き先をalterにより変更する。
ALTER TABLE access_log PARTITION (dt = '20180101', version = 'latest') SET LOCATION '/data/kanga333/access_log/dt=20180101/version=2'
これにより参照を止めることなく、データの作り直しが可能になる。
年の瀬なので2017年を振り返ってみる。
2017年は以下のような抱負を掲げていた。
今年は草を生やして行きたいです。
— かんが (@kanga333) 2016年12月31日
実際はどうだったかというと
微妙な結果だ。
今年は2度のタイミングで"Write Code Every Day"を実行しようと試みた。しかし、どちらも途中で挫折してしまっている。その形跡が1月~2月と4月~7月あたりに見て取れる。 毎日コードをコミットするのはそれなりに大変だ。時として突発的な飲み会に参加してコードを書く時間が用意できない場合など出てくる。そんな時はREADMEをちょっと弄ったり、中途半端な修正状況でコミットするという小手先のコミットをしてしまう。そのようなコミット続けると”意味の無いことをやっているのでは”とか”毎日のコミットに固執せず、ちゃんと意味のある本質的なコミットをしたほうが良いのでは"という考えが頭をよぎってしまう。そうして草を一日落とす。すると草を落とす事に抵抗が無くなってしまう。そしていつの間にかコードを書く習慣から遠ざかってしまう。
それらを踏まえて来年に向けた対策を挙げる。
来年こそは"Write Code Every Day"を続けていきたいと思っている。しかし6月に新婚旅行を予定しているため、そこで草は一度途絶えてしまうだろう。そのことが自分のモチベーションにどう影響するかは不明だ。
今年は以下のアウトプットを行った。
去年がほぼ0であったことを考えるとすこしづつマシなエンジニアに近づきつつあるような気がする。しかし自分の年齢を鑑みると、まだまだアウトプットの量が足りないので来年は倍以上にしていきたい。
技術検証や導入を主にやっていた。会社にはそれなりに評価して貰っていると思う。しかし、検証してるだけでは会社のシステムへ貢献にはならないので、しっかり導入をやり切って良いシステムを作っていきたい。そして来年はインフラまわりの仕事は抑えて、コードを書く割合を半分くらいまで増やしたい。
他には最近、採用活動に携わる事が増えてきた。対外的な求人力を高める事は、自分の働く環境を良くする事につながるのでそちらも力を入れていきたい。
10月頃から副業を始めた。前職の同期が企業したのでそのよしみでインフラ周りを手伝っている。 会社で使っている技術と違う技術が使えるためそれなりに面白い。しかし、学習時間が中々取れなくなってしまうので副業タスクをどう効率化していくかというのが来年の課題だ。
資産運用を始めた。そろそろお金でお金を生むスキルを身に着けないと人生厳しそうだなと感じる。今年はとりあえずNIISAを始めて、401kを真面目に設定し直した。来年は勉強して一部の資産でもう少しアグレッシブな運用をしてみようと思う。
つらつらと今年を振り返った。振り返って感じたことだが、今年は色々と始めてみた年だったようだ。来年は始めてみたことを良いサイクルに乗せれるようにしていきたい。
こんな便利な時代に自前でPostgreSQLを立てる必要が出た。悲しきオンプレのさだめよ。 当方PostgreSQL素人なのでいちから構築手順をメモしていく。
ミドルウェアが利用するPostgreSQLでそんなにパフォーマンスも容量もいらない。 でも、ちゃんと冗長化していて欲しいし、障害時にはフェイルオーバして欲しい。そんな感じ。
とりあえずPostgreSQLの同期レプリケーションでアクティブ/スタンバイの構成を作りたい。
ここにある。
PostgreSQL RPM Repository (with Yum)
以下のコマンドにてpostgresqlのレポジトリがyum.repoに追加される。
yum install -y https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6-3.noarch.rpm
そして実際のpostgresqlサーバのインストール。
yum install -y postgresql96-server
サービスを起動するまえにデータベースディレクトリが必要なそうな。データベースあるある。
/usr/pgsql-9.6/bin/postgresql96-setup initdb
/var/lib/pgsql/9.6/data/を覗くと色々ファイルができていた。
初期化後にサービスを立ち上げるとpostgresqlが立ちあがる。
# systemctl start postgresql-9.6
# systemctl status postgresql-9.6
● postgresql-9.6.service - PostgreSQL 9.6 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.6.service; disabled; vendor preset: disabled)
Active: active (running) since 水 2017-10-04 04:40:31 UTC; 5s ago
Process: 28155 ExecStartPre=/usr/pgsql-9.6/bin/postgresql96-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 28161 (postmaster)
CGroup: /system.slice/postgresql-9.6.service
├─28161 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
├─28163 postgres: logger process
├─28165 postgres: checkpointer process
├─28166 postgres: writer process
├─28167 postgres: wal writer process
├─28168 postgres: autovacuum launcher process
└─28169 postgres: stats collector process
10月 04 04:40:31 test-pg-1 systemd[1]: Starting PostgreSQL 9.6 database server...
10月 04 04:40:31 test-pg-1 postmaster[28161]: < 2017-10-04 04:40:31.246 UTC > LOG: redirecting log output to logging collector process
10月 04 04:40:31 test-pg-1 postmaster[28161]: < 2017-10-04 04:40:31.246 UTC > HINT: Future log output will appear in directory "pg_log".
10月 04 04:40:31 test-pg-1 systemd[1]: Started PostgreSQL 9.6 database server.
おKおK
一旦、Postgresqlサーバを止めて各種設定を確定させて行く。前述したとおりパフォーマンス要件は厳しく無いので、セキュリティやloggingの設定を主に注意してやっていく。
が、ここで問題が発生して、どうもpostgresqlの設定ファイルはinitdbで作成するディレクトリの/var/lib/pgsql/9.6/data/の下にできるそうな。
個人的には設定ファイルは/etc/pgsqlの下におかれていて欲しいなぁ。。。と思っていたと所、以下のドキュメントを発見した。
PostgreSQL: Documentation: 9.6: File Locations
これを読む限り、config_fileパラメータを起動時に渡してやれば諸々上手くいくそうだ。systemdのユニットファイルをいじれば良さそう。
以下は個々のconfigファイルについて
listen_addresses = '*'
全部のIPで待ち受けますよ的なおなじみのやつ。
wal_level = replica max_wal_senders = 5 max_replication_slots = 2 track_commit_timestamp = on
synchronous_standby_names = '1 (pg2, pg3)'
同期レプリするための設定なので、レプリ先がいない状態で反映すると動かなくなる
hot_standby = on
スタンバイ側でクエリを許可
log_destination = 'stderr' logging_collector = on log_directory = '/var/log/pg_log' log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_rotation_age = 1d log_line_prefix = '< %m > ' log_timezone = 'UTC'
ほとんどデフォルトでコメントアウトされていなかったパラメータそのまま。 log_directoryだけ、/var/log下に書き込まれるとうにへんこうした、、、がlog_destinationが'stderr'なので本当に吐かれるかは疑問。 log_destinationをstderrのままにしているのはsystemdのjournaldにログを監視してもらうため。
datestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english'
デフォルトでコメントアウトされていなかったパラメータそのまま。
何度も言うが、パフォーマンス要件は厳しく無い。 基本的なパフォーマンスの設定だけ抑えておけると良いのだが、何か良い記事は無いかとあさってるといかのページにたどり着いた。
なにやらHW状態に合わせて設定を生成してくれるらしい。これを使って実運用で問題出たら都度チューニングしていこう。 検証環境に合わせて生成すると以下の感じになった。
max_connections = 1024 shared_buffers = 1GB effective_cache_size = 3GB work_mem = 1MB maintenance_work_mem = 256MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.7 wal_buffers = 16MB default_statistics_target = 100
include_dir = 'conf.d'
コンフィグファイルは分割してincludeできるみたいなので、よしなにincludeさせる。
ホスト認証周りの設定はpg_hba.confで行うようだ。
とりあえず、社内DCにいるサーバにはhogeユーザでhogeデータベースにパスワード指定でログイン可能なようにゆるく許可を与える。
あと検証なので、レプリもゆるく開けている。
# TYPE DATABASE USER ADDRESS METHOD local all all peer host sameuser hoge 192.168.0.0/16 md5 host replication postgres 192.168.0.0/16 trust
一瞬、このファイルを設定変更した際、リスタートせんとアカンのん？？と思ったが、SIGHUPでリロードしてくれるらしい。ですよねー。良かった。
個別の設定ファイルをロードさせるためにsystemdのUnitファイルを変更する。
[Unit]
Description=PostgreSQL 9.6 database server
After=syslog.target
After=network.target
[Service]
Type=notify
User=postgres
Group=postgres
PermissionsStartOnly=true
Environment=PGDATA=/var/lib/pgsql/9.6/data/
Environment=PGCONFIG=/etc/pgsql/
OOMScoreAdjust=-1000
ExecStartPre=-/usr/pgsql-9.6/bin/postgresql96-setup initdb
ExecStartPre=/usr/pgsql-9.6/bin/postgresql96-check-db-dir ${PGDATA}
ExecStart=/usr/pgsql-9.6/bin/postmaster \
-c config_file=${PGCONFIG}/postgresql.conf \
-c hba_file=${PGCONFIG}/pg_hba.conf \
-c ident_file=${PGCONFIG}/pg_ident.conf \
-D ${PGDATA}
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=300
[Install]
WantedBy=multi-user.target
ExecStartPreでinitdbを行うように変更した。あと、configを読む箇所を変えたいので起動時パラメータでコンフィグのロード先を指定している。
こんな感じになった。
/etc/systemd/system/postgresql.service[Unit]
Description=PostgreSQL 9.6 database server
After=syslog.target
After=network.target
[Service]
Type=notify
User=postgres
Group=postgres
PermissionsStartOnly=true
Environment=PGDATA=/var/lib/pgsql/9.6/data/
Environment=PGCONFIG=/etc/pgsql/
OOMScoreAdjust=-1000
ExecStartPre=-/usr/pgsql-9.6/bin/postgresql96-setup initdb
ExecStartPre=/usr/pgsql-9.6/bin/postgresql96-check-db-dir ${PGDATA}
ExecStart=/usr/pgsql-9.6/bin/postmaster \
-c config_file=${PGCONFIG}/postgresql.conf \
-c hba_file=${PGCONFIG}/pg_hba.conf \
-c ident_file=${PGCONFIG}/pg_ident.conf \
-D ${PGDATA}
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=300
[Install]
WantedBy=multi-user.target
/etc/pgsql/postgresql.conflisten_addresses = '*' include_dir = 'conf.d'
/etc/pgsql/conf.d/replication.confwal_level = replica max_wal_senders = 5 max_replication_slots = 2 track_commit_timestamp = on
/etc/pgsql/conf.d/master.confsynchronous_standby_names = '1 (pg2, pg3)'
/etc/pgsql/conf.d/slave.confhot_standby = on
/etc/pgsql/conf.d/logging.conflog_destination = 'stderr' logging_collector = on log_directory = '/var/log/pg_log' log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_rotation_age = 1d log_line_prefix = '< %m > ' log_timezone = 'UTC'
/etc/pgsql/conf.d/client.confdatestyle = 'iso, mdy' timezone = 'UTC' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english'
/etc/pgsql/conf.d/pgtune.confmax_connections = 1024 shared_buffers = 1GB effective_cache_size = 3GB work_mem = 1MB maintenance_work_mem = 256MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.7 wal_buffers = 16MB default_statistics_target = 100
/etc/pgsql/pg_hba.conf# TYPE DATABASE USER ADDRESS METHOD local all all peer host sameuser hoge 192.168.0.0/16 md5 host replication postgres 192.168.0.0/16 trust
/etc/pgsql/pg_ident.conf使わないので空ファイル
ファイル巻き終わったらsystemdを更新して既存のデータディレクトリも消して再起動を行う。
systemctl daemon-reload rm -rf /var/lib/pgsql/9.6/data/* systemctl restart postgresql
この状態だと起動はするけど同期レプリケーションがいないので書き込みができない。 なのでスレイブを作成してきどうさせる必要がある。
同じ設定をアクティブと同様に巻く。 撒いた後はbg_backupコマンドを使ってSlave用のデータディレクトリを構成する。
su -c "pg_basebackup -R -D /var/lib/pgsql/9.6/data/ -h 192.168.0.1 -p 5432 -U postgres" postgres
バックアップを取った後、recovery.confを編集する必要がある。 色々調べたけど、このファイルはDataディレクトリにないといけないみたいだ。。。皆デプロイどうしてんだろう？
standby_mode = 'on' primary_conninfo = 'user=postgres host=192.168.0.1 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres application_name=pg2'
application_name=pg2を追加する必要がある。
設定が終わったら起動させる。
systemctl start postgresql.service
su -c 'psql -c "SELECT * FROM pg_stat_replication" -x' postgres -[ RECORD 1 ]----+------------------------------ pid | 30960 usesysid | 10 usename | postgres application_name | pg2 client_addr | 192.168.0.2 client_hostname | client_port | 51696 backend_start | 2017-10-05 04:58:13.243582+00 backend_xmin | state | streaming sent_location | 0/7000060 write_location | 0/7000060 flush_location | 0/7000060 replay_location | 0/7000060 sync_priority | 1 sync_state | sync
同期レプリされてるっぽいぞ。 おｋおｋ。
postgresqlの設定をイジってレプリが組めるところまで実施した。 本番デプロイに向けて、後はフェイルオーバーをコントロールするサーバと同期レプリカの候補サーバがもう一台あったほうが良いだろう。
私の所属する会社は未だバリバリにkyoto tycoon(kt)というkvsを使っている。 このktをいっちょDocker化したるか！と思ったら色々ハマったので備忘兼ねて記録を残す。
ネットを漁ると、すでにDocker化している方がいた。
先人の知恵に感謝しつつも、上記のDockerfileを覗くと、alpineのバージョンが3.4で固定されいる。
怪訝に思いながらも、それ以外に、会社で使用するkyototycoonはluaスクリプトによる拡張を有効化する必要があっため、大部分を参考にしつつ自前でDockerfile書くことにした。
ついでにalpineも最新の3.5で作ることにした。
自前で書く、といってもluaのパッケージを追加して、make前のconfigureで--enable-luaオプションを付加するだけだろうと思っていた。
いざDockerfileを書いてbuildしようしたが、alpine3.5だと以下のようなエラーが出てmakeでこけてしまった。
g++ -c -I. -I/usr/local/include -I/usr/local/include -DNDEBUG -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D__EXTENSIONS__ -D_MYZLIB -D_MYGCCATOMIC -D_KC_PREFIX="\"/usr/local\"" -D_KC_INCLUDEDIR="\"/usr/local/include\"" -D_KC_LIBDIR="\"/usr/local/lib\"" -D_KC_BINDIR="\"/usr/local/bin\"" -D_KC_LIBEXECDIR="\"/usr/local/libexec\"" -D_KC_APPINC="\"-I/usr/local/include\"" -D_KC_APPLIBS="\"-L/usr/local/lib -lkyotocabinet -lz -lstdc++ -lrt -lpthread -lm -lc \"" -std=c++11 -march=native -m64 -g -O2 -Wall -fPIC -fsigned-char -g0 -O2 -Wno-unused-but-set-variable -Wno-unused-but-set-parameter kcdbext.cc
In file included from kcdbext.cc:16:0:
kcdbext.h: In member function 'char* kyotocabinet::IndexDB::get(const char*, size_t, size_t*)':
kcdbext.h:1281:14: error: cannot convert 'bool' to 'char*' in return
return false;
^~~~~
make: *** [Makefile:76: kcdbext.o] Error 1
luaの部分がおかしいのかと思いきや、alpine3.4だと上手くいく。 コンパイルでエラーが出ているので、alpine3.4と3.5のg++とgccのバージョンを確認すると、alpine3.4のほうがgccのバージョンが5系でalpine3.5のほうがgccが6系となっていた。 デフォルトのコンパイルオプションとかが変わったのかな？とか思いながら、ググっていると以下の記事にたどり着いた。
どうやらgccの6系は標準で利用するc++の規格が変わってしまったようだ。 ktは古いプログラムなので、上手くコンパイルできないのであろう。
というわけでDockerfile内でsedを使って強引にMakefileを書き換えて、c++98を使ってbuildするようにすれば、makeが通るようになった。
sed -i -e "s/CXXFLAGS =/CXXFLAGS = -std=c++98/" ./Makefile && \ sed -i -e "s/CFLAGS =/CFLAGS = -std=c++98/" ./Makefile
色々なDockefileを見てるとsedで強引にファイルを書き換えているものを良く見るが、個人的にこれはイマイチな気がしている。 しかし、他にいい方法も思いつかないので、安易にsedっている。 Dockerfileでshell芸よろしくゴリゴリ書くの、みんな満足しているのだろうか？？ 個人的には何かキッティングツールが欲しいと思うのだが、いまいちPackerとかがDockerのビルドに使われてる感を感じないんだなぁ。
ありがたいことに会社で同僚に指摘してもらった。sedなんかせずともconfigure実行時にパラメータをつければ良いらしい。 ふむふむ後でDockerfileも変更しとこう、ついでにmulti-stage build化でもしとくかな。
./configure CFLAGS='-std=c++98' CXXFLAGS='-std=c++98' --enable-lua --with-kc=/usr/local
今回作ったDockerImageは以下にアップした。