この手に雲をつかむ話。

Web 開発

創作物を一斉に一定期間匿名で公開し、期間終了後に作者名を公開するというイベントがあります。このイベント用のいわゆるアップローダに類するサービスを開発しました。

必要とする機能

  • 作者は
    • 制作物をアップロードできる
    • 説明文とあとがきを記載できる
  • イベント主催者は
    • 制作物のファイル実体・作者名を公開・非公開にできる
    • 各作者が投稿した説明文・あとがきを(別途作ったイベントページへ)転記できる

方針

イベント用なのでトラフィックのスパイクに耐えうる設計が必要で、トレーニングも兼ねてクラウドネイティブな手法を取ることとしました。

構成

  • Web UI
    • ReactでSPAとして実装
    • Firebase Hostingで配信
  • データベース
    • Firestoreを使用
    • イベント情報・投稿内容(ファイル除く)を格納
  • 投稿ファイル格納・配信
  • 補助用バックエンドAPI
    • Cloud Run上にSinatraで実装したバックエンドAPIを配備
    • アップロードの中継、配信用signed URLの生成及びバケットの権限操作を行う

実装

Projects · 殊海夕音 / bibai-event-uploader · GitLab

感想

従来の手法(IaaS上のLinux VMにRailsで構築したアプリケーションを走らせるやり方)と記述量はさほど変わらないという印象。バックエンドとしてFirestoreを使おうが、Postgresを読み書きするRails実装のバックエンドを置こうが、大部分の処理はブラウザ上のReact実装というのであれば、その差は微々たるものなのかもしれず。ただし許容トラフィック量を考えれば圧倒的に有利なはず。従来手法で同等の性能を出そうとするとかなりの追加作業と運用コストがかかるのではないかと。
リリースとロールバックが簡単なのは便利。小規模個人プロジェクトでは持て余すものの、A/Bテストやらcanary releaseなんかがコンソールから簡単に出来るのも便利そう。


どうぞご利用ください。*1

*1:イベントが開催されたら

Tardigradeで安価くオブジェクトストレージを使う。

開発

ブロックチェーンを使って遊休ストレージを共有する仕組みを作っているStorj Labsという会社が、Google Cloud Storageのようなオブジェクトストレージサービス"Tardigrade"をリリースしました。
100GBで月1USDと安価く、法定通貨で請求されるから仮想通貨にまつわる面倒事*1も無いのでなかなか良さそう。なお、ingressは無料でegressは1GB辺り$0.045、最初の5GBは無料。また、サポートに連絡するまで5GBの制限があります。
実際に試してみました。

まずhttps://tardigrade.io/に行き、Get Startedからユーザ登録をします。実際に使う場所から近いリージョンが良いでしょう。そしてプロジェクトを作成します。
プロジェクトが出来たら、クライアントをインストールしましょう。

$ cd ~/Downloads
$ curl -L https://github.com/storj/storj/releases/latest/download/uplink_linux_amd64.zip -o uplink_linux_amd64.zip
$ unzip -o uplink_linux_amd64.zip
$ chmod 755 uplink
$ sudo mv uplink /usr/local/bin/uplink
$ which uplink
/usr/local/bin/uplink

プロジェクトページからAPIキーを発行して、uplink CLIに投入。同時にアップロードするファイルの暗号化パスフレーズも要求されるので投入しましょう。

$ uplink setup

バケットを作成してやれば準備完了です。

$ uplink mb sj://hoge

ファイルをアップロードしてみましょう。

$ uplink cp /path/to/file sj://hoge

標準入力からアップロードするならこう。tarで固めつつアップロードするなんかに重宝するかと。

$ echo 'hogehoge' | uplink put sj://hoge/stdin.txt

取り出しもuplink cpで行えます。標準出力に吐かせるならput。

$ uplink cp sj://hoge/file /path/to
$ uplink put sj://hoge/file

Uplink S3 Gatewayを使えばAmazon S3互換のAPIが使えるので、S3対応のアプリケーションのストレージをすげ替えて使うのも出来そう。

*1:確定申告とか

空飛ぶコンソメスープを飲み比べる。


ANAとJALのスープの粉が両方手に入ったので、飲み比べてみたんですよ。
機内で飲む分には、間が開いてるのもあって*1特に違いは気づかなかったんだけど、並べてみるとかなり味が違う。
ANAの方が甘みがあって、JALの方が辛めでスパイシーな感じ。好みを言うとANAの方かなと思いつつも、単にそれは馴染みがあるからってだけな気もする。JALのやつの方はクルトンが入っていて、食事に添えるには良いかも*2。
尚、メーカーが別なんだし味が違うのは当然ではある。
販路もパッケージングも違って、ANAのやつは20袋入りで空港売店だけで売ってる。対してJALのは4袋入りのがその辺のスーパーで売られている。

*1:毎日のように飛んでるわけじゃないので

*2:機内で出る分には入ってない。市販用にアレンジされてる

監視をStackdriveで行う。

ログ管理やアラートメール送信って邪魔くさくないですか？ElasticSearchやKibanaなんかで作る今時のログサーバがあると便利だろうけど、小規模サービスにはオーバースペックだし、メールを使わないサービスなのにわざわざメールサーバ用意してアラートメール送信できるようにするのも本末転倒な気がする。単純な送信ロジックだと、似たようなアラートが大量に出るとメールボムになるから、案外気を使うところも多い。
そこでカケラの樹では、Stackdriverを使ってみることに。

前提

  • Railsアプリケーション
  • Compute Engine上のUbuntuで実行

導入方法

Railsアプリケーションの場合、最低限Gemfileでstackdriver gemを追加するだけで動作する。設定項目は次のドキュメントを参考に。
googleapis.dev

カケラの樹での変更は以下のコミットのとおり。
gitlab.com
config.google_cloud.logging.log_nameに日本語を入れるとログ収集が行われなくなったので、アルファベットにしておいたほうが良さそう。

できること

他にも色々機能があるが、とりあえず簡単に使えるものをいくつか。

ログ閲覧・検索

GCPのコンソールからLoggingを開くと、ログがブラウザから閲覧できる。検索も可能。

アラート通知

アラートが発生すると通知される。デフォルトではGCPのモバイルアプリへのプッシュ通知が送信される。メールを受信したい場合、コンソール右上の設定を開き、Stackdriver Error Reportingのメールアドレスの項目にチェックを入れる。
類似した例外が複数発生した場合、勝手にまとめてくれる。

デバッグ

画面上から指定した位置での呼び出し履歴を調べたり、変数の値のウォッチが出来る。本番環境で実行中のインスタンスを観察できるのでこれは便利。
ウォッチ式等の副作用でアプリケーションの動作が変わるのを防ぐ仕組みが入っていてかなり厳しいので、誤検知の場合は式全体をGoogle::Cloud::Debugger.allow_mutating_methods!で囲んでやるとよい。

GCEでライブパッチは使えなさそう。

開発 Web カケラの樹

手元の端末でcanonical-livepatchが動いてるのを見て、そういえば3台までいけるんだからサーバでも使おうか、と思った。

$ uname -a
Linux yumenosora 4.15.0-1024-gcp #25~16.04.2-Ubuntu SMP Tue Oct 30 14:14:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ sudo snap install canonical-livepatch
canonical-livepatch 8.0.6 from 'canonical' installed
$ sudo canonical-livepatch enable [トークン]
2018/11/19 14:20:31 cannot use livepatch: your kernel "4.15.0-1024-gcp" is not eligible for livepatch updates

にゃうーん。Compute Engine上では専用のカーネルが使われるけど、ソレにライブパッチは使えない、みたい。残念。

さよならはてなダイアリー。

雑記

はてダからの移行作業を行いました。混んでて中断されてるって話を聞いてたから今までやらなかったんだけど、そろそろほとぼりも冷めたんかな。さほど記事数が無いからっていうのもあると思うけど、30分程度でインポート完了。
一時期に比べて書く量はすごい減ったけど、これからはこっちでいろいろと書いていきます。

DNS over HTTPSで名前解決を保護する。

PC

角川の金盾の件も頭の片隅には置きつつ、それ以前に、名前解決が平文で行われるのはセキュアではないよね、と思ったので、最近話題のDNS over HTTPSを使って名前解決が出来るようにしてみる。
環境はUbuntu 18.04 LTS。
まずはdnscrpyt-proxyをインストールする。

sudo add-apt-repository ppa:shevchuk/dnscrypt-proxy
sudo apt install dnscrypt-proxy

で、設定ファイルを変更。
/etc/dnscrypt-proxy/dnscrypt-proxy.toml

--- dnscrypt-proxy.toml.orig	2018-10-16 21:15:17.821726742 +0900
+++ dnscrypt-proxy.toml	2018-10-16 21:23:20.394256628 +0900
@@ -27,13 +27,13 @@
 ## The proxy will automatically pick the fastest, working servers from the list.
 ## Remove the leading # first to enable this; lines starting with # are ignored.
 
-# server_names = ['scaleway-fr', 'google', 'yandex', 'cloudflare']
+server_names = ['google', 'cloudflare']
 
 
 ## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6.
 ## Note: When using systemd socket activation, choose an empty set (i.e. [] ).
 
-listen_addresses = []
+listen_addresses = ['127.0.0.1:53']

server_namesはお好みで。GoogleのとCloudflareのがあればいいだろうって判断したけど、検閲絡みのハナシを考えるとscaleway-fr(フランス?)とかyandex(ロシア)のも入れておいたほうがいいのかな。とはいえ起動時のRTT判定で十中八九Cloudflareが選択されるので変化はないかも。
このままでは起動しなかったので、systemdのUnitファイルにちょっと書き足す。
/lib/systemd/system/dnscrypt-proxy.service

--- dnscrypt-proxy.service.orig	2018-10-16 21:16:23.818348613 +0900
+++ dnscrypt-proxy.service	2018-10-16 23:09:48.422039898 +0900
@@ -20,6 +20,7 @@
 CacheDirectory=dnscrypt-proxy
 LogsDirectory=dnscrypt-proxy
 RuntimeDirectory=dnscrypt-proxy
+AmbientCapabilities=CAP_NET_BIND_SERVICE
 
 [Install]
 Also=dnscrypt-proxy.socket

この変更入れないと、DynamicUser=yesだから一般ユーザとして起動するのに、53番をlistenしようとしてコケるんだよね。
で、systemd-resolvedを殺す。

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

最後に、名前解決をlocalhostでやるようにする。

$ cat /etc/resolv.conf
nameserver 127.0.0.1:53

再起動して完了。システムごとでもいいし、サービス再起動でも動くはず。

sudo systemctl restart dnscrypt-proxy
sudo systemctl restart NetworkManager