使われていない、を知る

この記事について

既存の仕組みを「捨てる」というのは得てして影響が大きく、それを実行するには準備と勇気がいる。

builderscon 2019 で聴講した fujiwara さんの「レガシーサーバーを現代の技術で再構築する」の質疑応答で「再構築にあたり、使われていないものを捨てるときにどのように"使われていない"ことを確認するのか」質問させていただいたことを期に、日頃考えていたり、過去に経験したりといったことを書き出してみたくなった。

builderscon.io

セッションの内容は大変すばらしいものだったので、ぜひスライドや動画を見ていただきたい。スライドのリンクを見つけられなかったので、セッション詳細のページを紹介しておく。

builderscon.io

あまりまとまりがないものになるが、個人のメモだと思ってご容赦いただきたい。

前提

この記事では、主に会社や部署など特定の組織内で利用されているもの。特に Web アプリケーションを対象に扱い、BtoC など組織外の利用者がいるケースは想定していない。

また、以降は対象のアプリケーションや仕組みのことを簡便のために「システム」と呼ぶことにする。

「使われていない」ことを知るために

使われていないという状態は、どのように知ることができるだろう。

現時点で思いつく限りを列挙してみる。

  • アクセスログやデータの作成・更新日時から知る
  • 運用マニュアルなどが存在する場合は、そのドキュメントを参照する
  • 利用者が特定できる場合は、ヒアリングをする
  • 利用者にアンケートを取る
  • 計画的に対象を停止し、利用者からの反応を見る

アクセスログやデータの作成・更新日時から知る

アクセスログやデータから利用情報を知るというのは、ごく一般的かつ、信頼性の高い方法だと思う。

Web アプリケーションという前提においては、期間はさておき何らかの形でアクセスログは残る。

また、データベースやファイルシステムに保存されたデータの量や更新日時などから、どれぐらい回数や量、どの程度の頻度で利用されているかを掴むことができると。

運用マニュアルなどが存在する場合は、そのドキュメントを参照する

特定の組織内で利用するシステムには、マニュアルや業務フローなどのドキュメント類が整備・定義されていることも多い。

それらの情報に触れることができる場合は、ドキュメントから利用シーン、利用頻度などを読み解くこともできる。

ただし、こういったドキュメント類は「使われていない＝メンテナンスされない」となるケースも多く、現在そのドキュメントが取り扱うシステムが使われているかどうかの判断材料にはならないことが多いように思う。

利用者が特定できる場合は、ヒアリングをする

組織内でも特定の部署や担当者が利用するシステムで、それが明らかな場合は、ヒアリングを行うことも有用だ。

対象のシステムが扱う業務ドメインについても豊富な知識を持つ担当者にヒアリングができれば、システムがどのように使われているか、またはいつから使われなくなったか、なぜ使われなくなったかなど、前述のふたつの方法では知ることのできない情報を得ることができることが多い。

しかし、相手は人間になるので、ヒアリングをしてもその場で思い出せなかった、言いそびれてしまった、忘れてしまったということは簡単に起こりうるので、前述の方法で得た情報とあわせてヒアリング内容を精査したほうがよい。

利用者にアンケートを取る

組織内でも不特定。というには大げさだが、組織横断的に利用されているシステムでは、利用者が定まらないようなケースもある。

その場合、何らかの方法でアンケートを取ったり、意見を求めたりすることも利用状況を知る方法となる。

これによって、今まで知りえなかったような情報を想定外の利用者から提供してもらえることなどが期待できるが、アンケートのような手法を取ると、アンケートの設問の設計、回収率などの頭を抱えることになるかもしれない。

計画的に対象を停止し、利用者からの反応を見る

これは当日の質問でも登壇者や参加者、質問者である私も思わず笑ってしまった方法ではあるが、現実においてはあながちトンデモな方法と言えなくもないし、むしろ実践的とも言える側面もあると思う。

前述のどのような方法をとっても、実際にシステムを止めてみないとそれが使われているかどうかを真に知ることは難しい。

ただし、この方法は業務フローに大きな影響を与えてしまう可能性を含んでいるため、計画や実施を慎重におこの合う必要がある。

たとえば、以下のような段階を考えることができる。

  • システムの一時停止を告知し、そのスケジュールにあわせてシステムを停止する
  • システムの一時停止を告知せず、システムを短期間停止する

各段階のいずれにおいても、ロールバック(再開)の手順は必ず用意しておく。

また、実施する時間帯は業務にあわせて計画する。

早朝や休日など明らかに利用者が居ない時間帯や日程で実行しても得られる情報は少なくなるし、かといって月末、月初、期末の多忙な時期にシステムの停止をすると、リカバリーが難しい規模の業務停止を引き起こしてしまう可能性もある。

まとめ

個人の経験からいくつかの例を挙げつつ、それぞれの方法について意見を書いてみた。

ここで挙げられなかった方法や、こんな方法を取ったことがある。などがあれば、どんな形でもいいので教えてほしい。

この記事が、誰かにとっての Discover Something New になっていたら嬉しい。

f:id:ariarijp:20190831145157j:plain

あとがき

この記事は builderscon 2019 会場近くのイタリアントマトで書きました。

参加者にランチを提供していただいた、さくらインターネットさん、ごちそうさまでした。

Redash で 502 Bad Gateway が発生したときに見直すべき Gunicorn のタイムアウト

業務で使い倒している Redash で、あるクエリーの結果をダウンロードすると、「502 Bad Gateway」が発生していたので調査・対応したメモ

発生していた現象

行数約28,000行、列数約70の結果を返すクエリーを Excel ダウンロードしようとすると nginx の 「502 Bad Gateway」エラーが発生しファイルがダウンロードできない。条件を絞って取得行数を減らすとダウンロードできる。

調査

nginx のエラーログには以下のようなメッセージが記録されていた。

... upstream prematurely closed connection while reading response header from upstream, client: xxx.xxx.xxx.xxx ...

また、server コンテナのログには、ワーカーがタイムアウトしたようなログが記録されていた(詳細は割愛)

ここでの「ワーカー」は Celery 上で動く Redash のワーカーではなく、Redash がアプリケーションサーバーとして使用している Gunicorn のワーカーのこと。

対応

エラーログから Gunicorn がタイムアウトしていると推測し、設定を調査した。

結果として、タイムアウトのオプションがあり、それはデフォルトで 30 秒になっていることがわかった。

docs.gunicorn.org

また、Gunicorn のオプションはコマンドライン引数として与える以外にも、以下のように環境変数で渡すことができる。

$ GUNICORN_CMD_ARGS="--bind=127.0.0.1 --workers=3" gunicorn app:app

Redash は現在 Docker 環境を推奨しているため、コマンドラインオプションの変更ははイメージの再構築が必要になってしまい、相性が悪い。

その点、GUNICORN_CMD_ARGS 環境変数を使えば docker-compose.yml の変更のみでオプションを適用できる。

これらを踏まえて、以下の設定を docker-compose.yml の server サービス内、 environment に追加した。

GUNICORN_CMD_ARGS: "--timeout 90"

90秒という設定は適当。

docker-compose.yml を編集後、docker-compose down、docker-compose up -d でコンテナを再起動。

エラーが出ていたクエリをブラウザで表示し、クエリー結果を Excel ダウンロードしたところ、ダウンロード成功。

まとめ

Redash でファイルダウンロード時に 502 エラーが発生した際は、Gunicorn のタイムアウトを見直すことで解決することがある。

この記事では Docker 環境で動作している Redash を扱っているが、レガシー(Ubuntu に直接導入)セットアップでも似たような対応ができるはず。

Mackerel アンバサダーになりました

f:id:ariarijp:20190406094516p:plain

アンバサダープログラムについては以下の記事に詳しく書いてあります。

mackerel.io

Mackerel 関連の活動ふりかえり

アンバサダーに選出していただいたので、これまでの活動をざっくり振り返ってみました。

プラグイン開発への参加

github.com

Mackerel はエージェントやプラグインを OSS として公開していますが、私も以下のプラグインの開発に微力ながら参加しました。

個人の OSS

個人的にもいくつか Mackerel 関連の OSS を公開しています。実装が中途半端なものも多いですが、以下の2つはそれなりに使える状態になっていると思います。

ブログなどでの記事公開

改めて振り返ってみると。意外といろいろ書いていました。

イベントでの LT 登壇

参加者としては以下のイベント意外にも参加したことがありますが、2度ほど LT 枠で登壇したこともありました。

今後の活動について

アンバサダーになったからといって、変に気負って Mackerel 関連の活動をすることは無いと思いますが、Mackerel は気に入っているプロダクトのひとつなので、今後もなんらかの形でコミュニティやエコシステムに関わりたいと思っています。

Happy Monitoring !!

Mac から Windows への移行を試したメモ

モチベーション

去年、Surface Laptop を衝動買いしたことをきっかけに、ここ数年 Mac で開発していたけど Windows に移行できるか試したくなった

やったこと

今のところの感想

  • キーボードの打ち間違いがとにかく多い。特に Mac の Cmd-Tab とか Cmd-S や IME の切り替えを指癖で打とうとすると Win-Tab、Win-S などをタイプしてしまいストレスがたまる、キーマップをいじるべきか悩む
  • Mac ではトラックパッドを使っているけど、Surface Laptop のトラックパッドは少し厳しい。物理スイッチのトラックパッドにはもう戻れないと思った
  • マウスを使っているけど、4年ぐらいマウス使わない生活をしていたので、これもすごく違和感がある
  • キーボードとマウスをしばらく使っていたら、Thinkpad のキーボードが恋しくなった。家のどこかにあるはずなんだけど見当たらないので、Bluetooth 版のやつを買おうか悩んでいる
  • WSL があるおかげで CLI 操作が以前の Windows と比べると格段によくなっている
  • WSL で Docker が動くようになったけど、Docker Compose はまだ使えないため、今のところ Docker は WSL の外で使うことになりそう
  • 開発環境は Windows 側に作るか WSL 内に作るか悩む。今は WSL に寄せてるけど、VSCode を使うとなると Window 側にも Python や Nodejs を導入する必要がありそうな気がしている
  • Mac でできて Windows でできないことはいくつかある（Xcode 使えないとか）が、だいたいのことは Windows でも慣れればなんとかなるかなと思い始めた
  • 以前使っていた Windows は前職で貸与されていた DELL のラップトップだったんだけど、最近のものはどれも見た目とか質感がいいなと思った。Surface Laptop もかなり気に入ってる
  • Surface 製品全般に言えることかもしれないけど、製品の特性上修理ではなく交換になることが多いらしいので、故障のリスクはちょっと怖い
  • とりあえず、まずはプライベートでなにかするときは Surface Laptop を使い続けてみることにした

今後やること

  • Redash の開発環境を整えてみる
  • PyCharm など JetBrains 製品をいくつかインストールする

レノボ・ジャパン ThinkPad Bluetooth ワイヤレス・トラックポイント・キーボード - 日本語 0B47181

レノボ・ジャパン ThinkPad Bluetooth ワイヤレス・トラックポイント・キーボード - 日本語 0B47181

Ubuntu 上で環境構築していた Redash を Docker 上で動作する環境に移行する手順

この記事は Redash Advent Calendar 2018 25日目。最終日の記事です！

adventar.org

参加いただいたみなさまも、読んでいただいた皆様もありがとうございます！

お題

現在、Redash の環境構築は Docker を使用する方法のみが公式ドキュメントなどでも記載されていますが、古くからの Redash ユーザーにとっては、Ubuntu の上にインストールする形で運用している方も多く、私もそのひとりです。

この記事では、旧来の Ubuntu 上に環境構築された Redash(以降、レガシーセットアップ)を Docker で構築された Redash（以降、Docker セットアップ）に移行する方法を紹介します。

注意事項

この記事で紹介する方法はあらゆる環境を網羅したものではありません。

お使いの環境を移行する際は、必ずご自身で検証してください。

また、この手順は私が業務で Redash を移行する際にも利用しているため、移行作業の結果によって、この記事を加筆修正する場合があります。

前提条件

この記事の検証で使用した Ubuntu と Docker、 Docker Compose のバージョンは以下となっています。

  • Ubuntu 16.04.4 LTS
  • Docker version 18.09.0, build 4d60db4
  • docker-compose version 1.8.0, build unknown

この記事では Docker の導入については割愛しますが、私は以下の記事を参考にして Docker を導入しました。

How To Install and Use Docker on Ubuntu 16.04 | DigitalOcean

手順

PostgreSQL 以外の Redash 関連のサービスを停止

PostgreSQL の DB ダンプを取得する前に、Redash 関連のサービスをすべて停止します。

$ sudo service nginx stop
$ sudo service supervisord stop
$ sudo service redis_6379 stop

サービス名は Redash をどのバージョンから利用しているかによって異なる場合があります。

既存の Redash から DB ダンプを取得する

Docker セットアップ環境で使用する PostgreSQL にリストアするための DB ダンプを取得します。 レガシーセットアップでは PostgreSQL に redash ユーザーを作成しますが、Docker セットアップでは postgres ユーザーを使いますが、そのため、既存環境のダンプファイル取得時にオーナー情報を除去しておきます。

$ sudo -u postgres bash -c "pg_dump --no-owner --no-acl redash | gzip > /tmp/dump.sql.gz"

ダンプファイルの出力先は /opt/docker/redash として、この記事内では以降の説明でも、このディレクトリ内で作業します

既存の PostgreSQL を停止

ダンプファイルを取得したら、既存の PostgreSQL は不要になるためサービスを停止します。

$ sudo service postgresql stop

docker-compose.yml をダウンロードする

移行先バージョンの docker-compose.production.yml をダウンロードします。

この記事では移行先に v5.0.2 を使用するため、GitHub 上でタグを指定してダウンロードしています。

$ wget -o /opt/docker/redash/docker-compose.yml https://raw.githubusercontent.com/getredash/redash/v5.0.2/docker-compose.production.yml

docker-compose.yml を書き換える

Docker セットアップで使用するバージョンに合わせて docker-compose.yml を書き換えます。

バージョンの指定

Docker イメージのタグ一覧 を参照し、利用したいバージョンのタグを指定します。

$ sed -i s/redash\\/redash:latest/redash\\/redash:5.0.2.b5486/g /opt/docker/redash/docker-compose.yml

postgres サービスのボリューム指定

PostgreSQL のデータを保持するボリュームを指定します。

postgres サービスの volumes がコメントアウトされているので、これをアンコメントしてホスト側のパスを書き換えます

...省略...
  postgres:
    image: postgres:9.5.6-alpine
    volumes:
      - /opt/docker/redash/postgres-data:/var/lib/postgresql/data
    restart: always
...省略...

環境変数を設定する

既存の Redash の .env から必要な設定を server, worker サービスの environment に設定します。

ここでは詳細な説明を省きますが、メールサーバーの設定などは .env にで設定することが多いので、忘れずに設定しましょう。

また、server のみに設定してしまい worker に環境変数が適用されないというケースもあるので、忘れずに両方の environment に設定してください。

Docker Compose で起動する

準備ができたら、サービスを起動します。

$ sudo docker-compose up -d

postgres にダンプファイルをコピーする。

新規インストールの手順であればここで create_db を実行するところですが、今回は既存環境からの移行なので、データベースの作成はせずに、先程取得したダンプファイルをリストアします。

そのため、ダンプファイルを postgres サービスが動いているコンテナにコピーします。

$ sudo docker cp /tmp/dump.sql.gz `sudo docker ps|grep postgres|awk '{print $1}'`:/tmp/

DB をリストアする

コピーしたダンプファイルを使って、以下のコマンドでリストアします。

$ sudo docker-compose exec postgres bash -c "zcat /tmp/dump.sql.gz | psql -U postgres"

マイグレーションを実行する

この時点で、DB は作られていますが、古いバージョンのテーブル構造のままになっているため、マイグレーションを実行して移行先のバージョンにあったテーブル構成にします。

$ sudo docker-compose run --rm server manage db upgrade

ここまででレガシーセットアップから Docker セットアップへの移行は完了です。

疎通確認

最後に、curl で簡単に疎通確認してみます。

$ curl -I localhost/api/config

JSON 文字列が表示されていれば、移行した Redash が動作していることが確認できています。

まとめ

バージョンアップにくらべ、さらに腰が重くなるような移行作業ですが、私も今後のアップグレードも見据えて移行を進めています。移行は計画的に進めましょう。