堅牢なデータBDを作る。

以前に堅牢なデータ保管用BDを作成する手法を考えたのですが、この手法で書き込んだディスクはマウント方法が煩雑。で、もっと良い手法で書き込みが可能だったのでやり方を記しておきます。

構成

• dvdisasterでディスク全体を保護する
• ディスク全体をLUKSで暗号化する
• ファイルシステムはEXT4

www.frederickding.com
ほぼこの記事の通り。

手順

1. truncate -s 19000M image.iso
2. ディスクユーティリティで作成したイメージをアタッチ(もしくはsudo losetup /dev/loopXX image.iso)
3. ディスクユーティリティでアタッチしたイメージ内にLUKS+EXT4のボリュームを作成
4. ファイル投入してアンマウント
5. dvdisaster -c -i image.iso -mRS02 -n BD
6. BDへイメージを書き込み

自分のための場所を作る。

少し前にMateChaが死んで、モバイルでTwitterを読み書きするには別の方法が必要になった。まぁオフィシャルなアプリを入れるなりウェブアクセスでやるなり方法は色々あるんだろうけど、そもそもTwitterアレだしなーと思ってなんか別のやつを使おうかな、という判断をした。
で、NostrやBlueskyみたいなのが色々出てきてはいるけどああいうのってiPhone限定でしょ?という雑な理解をしていたり、そもそも招待状要るらしいし……ってんで順当にMastodonのようなActivityPubを喋るやつにしよう、それも出来れば自分用のサーバを立てよう、という方針に決定。

実装の評価

方針が決まったので次は使用するサーバソフトウェアを決める必要がある。以下の観点で検討を行った。

• 収容人数は数名で良い
• フットプリントが小さいか
• 一通りの機能が揃っているか
• 運用コストが低いか

これらの条件に合致しそうな実装をいくつか評価した。

Wildebeest

• Cloudflareによる実装だけあってCloudflareのプロダクトをふんだんに使ってスケールするように実装されている。大人数を収容できそうだが量によって伸び縮みするだろうから人数の問題はない。
• 基本料金がかかるプロダクトを要求するため数ドル程度の固定費が掛かる
• 標準的な機能を実装済み
• マネージドサービスを使うためメンテナンス性は高い(はず)

GoToSocial

• Golangで書かれた実装
• 数名での使用を前提にしているように見える
  • オンラインサインアップが未実装になっている(adminがアカウントを発行する必要がある)など
• 非常に軽量
• 標準的な機能が実装されている

Honk

• Golangで書かれた実装
• 非常に軽量
• 独特の世界観、"あえて実装しない"機能があるらしい

→ GoToSocialを選択。

インフラ

以下の構成でデプロイした。特に変わった点はない。

• Compute Engine e2-micro
• nginx
• certbot
• gotosocial
  • RDBはSQLite
• Litestream
  • ストレージはCloud Storageを使用

収容人数は最大でも数名の予定なのでRDBはSQLiteで十分と判断。LitestreamでCloud Storageへレプリケーションして最低限の冗長性を確保する。手癖でnginxを前段に置いてcertbotで証明書を取るようにしたけど、GoToSocialは組み込みの証明書取得機能があるのでそれを使ったほうが楽そう。

良かったらフォローしてみて下さい。
2023/10/21追記: Pleromaに移行しました↓
tl1.yumenosora.net

この手に雲をつかむ話。

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

必要とする機能

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

方針

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

構成

• Web UI
  • ReactでSPAとして実装
  • Firebase Hostingで配信
• データベース
  • Firestoreを使用
  • イベント情報・投稿内容(ファイル除く)を格納
• 投稿ファイル格納・配信
  • Backblaze B2を使用
• 補助用バックエンド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:確定申告とか

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

うふ pic.twitter.com/Le6YmfZriJ

— 殊海夕音 (@yune_kotomi) 2019年5月7日

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

機内ドリンクサービスのスープ、ANAのはネスレでJALのは明治という知識を得た。
ちなみにAIRDOのは(株)グリーンズ北見である。

— 殊海夕音 (@yune_kotomi) 2018年6月6日

販路もパッケージングも違って、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でライブパッチは使えなさそう。

手元の端末で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上では専用のカーネルが使われるけど、ソレにライブパッチは使えない、みたい。残念。