こんにちは！インフラの市橋です。今年の冬は晴れが多くて過ごしやすいので助かります。
ところで私は新卒なのですが、最初の大仕事としてTableau ServerをAWS上で構築する仕事を任されました。チーフと二人三脚で進めていったのですが、そんな中でいくつかの反省点が生まれました。
そこで今回は、Linux版Tableau Serverを構築する上で躓いた事、こうしておけばよかったと思うことを書いていきます。
経緯
社内では以前よりWindows版Tableauサーバーが運用されていました。これは社内からのアクセスのみを前提としたTableauサーバーでした。
しかし今回、社外に特定の経路からTableauサーバー上のビューを公開する必要が出てきました。そこで、セキュリティ的な理由から社外向け専用環境が必要になりました。
というわけで自社でのTableau Server管理が必要になりましたが、既存のWindows版の運用にて
- 本番とテスト間の構成ドリフトが起きている
- 誰がどのような変更をしたのかがよくわからない
- Windowsの運用が辛い
- もう触りたくない
といった声が上がっていました。
そこで今回は
- IaCの導入
- テスト環境と本番環境の統一性を保つ
- 変更はgitのログとして残す
- 何度でも環境をつくり直せるようにする
- Linux版を使う
による運用負荷の低いTableauサーバー運用を目指しました。
前提
- Tableau Server 2019.1の最新バージョンを使用
- 環境はAWS
- 1ノード構成で前段にALBがいる
気をつけること
ライセンスをデアクティベートしないと上限に達する
Tableauサーバーは一つのライセンスでも、テスト環境などでの利用を想定して複数回のアクティベートができます。
しかし当然無制限ではなく、いつかはアクティベート数上限に達します。
構築時の検証段階では何度もインフラ削除、再構築を行なっていたのですが、その際にデアクティベートを行わなかったためにライセンス認証が不可能になることがありました。
こうなるとデアクティベートはサポートに連絡してやってもらう必要があります。
インフラを壊す前にデアクティベートするようにしましょう。
tsmadminグループに入っていてもpasswordを要求される (v2019.1まで)
現在のTableauサーバーには、Tableau Servece Managerと呼ばれるWeb UIとCLIが導入されました。 おそらくクロスプラットフォームを意識してこのようになったんだと思われます。
ところでTSMの使用には認証が必要です。そしてその認証には su が使われます。 つまり、Linuxサーバー上に
存在するユーザーアカウントのユーザー名、パスワードを利用して認証を行います。これはWeb UI, CLI共に必要になります。
この認証があることは問題ではありませんが、tsmコマンドを実行する際に厄介なことになります。
バックアップスクリプトやansibleにて、そのコマンドの実行ユーザーのパスワードを与える必要があるためです。なんらかの方法でパスワードを安全に渡す必要があります。
解決策1. SSMパラメータストアを使う
SSMパラメータストアでは、KMSを使ったパラメータの暗号化ができます。
今回はこれを利用して、tsmコマンドを実行する際は、SSMパラメータストアからパスワードを取得するようにしました。
ただしこの方法はansibleの実行ログにパスワードが出てしまいます。本来はここにもパスワードを出したくなかったので、望ましい解決策とは言えない状態です。
解決策2. 2019.2以降を使う
2019.2から、tsmadminグループに所属するユーザーはtsmコマンドの認証が不要になりました。
というわけで2019.2以降を使うのが良いでしょう。
現在の最新版は2019.4のため、最新の1つ前を利用するポリシーでも2019.2以降が使えます。アップデートしなきゃなぁ……
Ansibleでautomated_installerを使うと色々辛い
automated_installer というツールを使うと、必要な認証情報、設定ファイルを渡せばワンコマンドでTableau Serverのセットアップが完了します。
ですが、もしなんらかの問題がありセットアップに失敗したとします。 すると、automated_installerによるインストールが失敗するようになります。
対処としてはTableau Serverの完全削除を行えば良いのですが、
Ansibleを使ってインストールするならば initialize-tsm や各種 tsm サブコマンドを使って
セットアップする方が原因の特定もリトライもしやすくなるでしょう。
ALBのオートスケーリングの影響で信頼された認証がうまくいかなくなることがある
Tableau Serverには信頼された認証という仕組みがあります。
ビューを他のサーバー経由で表示する時などに使用する機能で、とあるアクセス元かつ、
Tableauサーバーが発行したトークンを持っていれば、認証不要でビューを取得できるというものです。
このとあるアクセス元についてですが、以下の二つの要素があります。
- source IPが特定のものかどうか
- proxyが指定されたものかどうか
今回構築したTableauサーバーは前段にALBを挟んでいました。
そのためproxyとしてALBのプライベートIPを書いておく必要があります。
ところで、ALBはオートスケーリングします。つまりproxyは増えたり、IPが変化したりします。
当初はこのことを失念していたため、経由したALBによってビューが表示されたりされなかったりする現象が起きていました。
ALBが取り得るIPを全て登録する
しかし対処は簡単です。要するにALBの取りうるIPをCIDRなどで指定すればいいからです。
では指定方法を見てみましょう。
ロード バランサーの IPv4 アドレスまたはコンピューター名を指定します。 server の値は、次のようなコンマ区切りリストです。
tsm configuration set -k gateway.trusted -v "10.32.139.45, 10.32.139.46, 10.32.139.47"または
tsm configuration set -k gateway.trusted -v "proxy1, proxy2, proxy3"(https://help.tableau.com/v2019.1/server-linux/ja-jp/distrib_lb.htm から引用)
どうやらカンマ区切りの文字列として渡せばいいようです。しかし範囲指定できません。つまり、取りうるIPをすべてカンマ区切りで指定する必要があります。
そのため、ALBの所属するサブネットのCIDRを元に、取りうるIPを取得するスクリプトを作成しました。
ips = sum([["10.200.41.{}".format(i + (offset * 16)) for i in range(4, 15)] for offset in range(0, 3)], []) print(",".join(ips))
このスクリプトは
10.200.41.0/2810.200.41.16/2810.200.41.32/28
の三つのサブネットにて、ALBが取り得るIPを、先ほどのコマンドの引数として渡せる形式で生成してくれます。
(必須ではない) サブネットの範囲制限
気になることとして、コマンド長制限があります。Amazon Linux 2 では
$ getconf ARG_MAX 2097152
つまり2MBが上限です。IPは高々15byteなので、14万個くらいが上限になります。
サブネットマスクが/16でも65536個なので、量は十分でしょう。
ただ、この設定は tsm settings export で出力されるjsonファイルにもかかれます。
サブネットマスクが /24でもそこに255個のIPが書かれる事になります。
中身を読む必要が出た時障害になりそうだと感じた他、
今回のユースケースではそんなにたくさんのALBが同時に必要になるとは考えにくかったため、
サブネットマスクは/28にして、1サブネットあたり12個までしかALBが作られないようにしました。
バックグラウンダープロセスが定期的にデグレードする
結論から言うと、仕様です。
バックグラウンダープロセスはメモリ開放を目的とした定期再起動が行われているそうです。
そのため、プロセス監視を行う際はそのことを織り込んでおく必要があります。
アラートをセットする場合は、ある程度長時間のデグレードを持ってして通知するようにしましょう。
終わりに
Tableau Server on Linux構築の、TSM CLIを使った構築の参考になればと思います！
