スクリプト類とメニューボタン

トップ ソフト 雑記 日記 リンク

2022/07/24

企業・有名人の分散SNSの始め方

これから書く内容は、個人的な考察です。実際はまだまだ発展途上なため、もっと別のアプローチが出てくるかもしれません。

新しいSNSとして「マストドン」という言葉を聞くようになってきました。
新しいと言っても、2016年から始まって(日本では2017年から流行)いますので、2022年でもう5年ちょっとになります。
雰囲気としては、気の合う仲間と日常やネタや時事をワイワイやっているという感じですが、フォローしていない人でも共有で回ってきて、だいたい活動している人のアイコンは何度か見たことがあるという、Twitterが大爆発的に流行るちょっと前の「日本語をしゃべってる人はだいたい見たことある」というあんな感じの状況です。

さて分散SNSと比べられるTwitterも、ネットをそれなりに使っている人なら1アカウントは持っているというような状況になり、様々な企業や有名人、国までもが情報発信ツールとして使っている状況です。
しかしTwitterも色々な問題があり、飛び出す人たちがいます。ここでは、分散SNSとはなんぞやという詳しい話や、中央集権がどうとかいう話はしません。そのあたりの記事は2017年頃にたくさん出ていたのでそちらを参照してください。
ある程度有名な人たちが、分散SNSで活動して行くに当たって、どうするのが良いかというのを考えてみたいと思います。

まずはアカウントを作る。
情報発信をするにはアカウントを作る必要があります。これは分散SNSでも違いはありません。
しかし、ただアカウントを作ると言っても、いくつかのパターンが考えられます。ここが分散SNSの使い心地や、企業・有名人ブランド力の強化に繋がってくると考えています。

  1. 既存のサーバにアカウントを作る
  2. 一番簡単なパターンです。分散SNSが出てきた当初は、サーバを用意するには技術的な知識が必要となりハードルが高かったという問題がありました。
    そのため数あるサーバの中から、どれかを選んで、そのサーバにアカウントを作るというものです。
    企業や、ITジャーナリストや、作家さんなんかでこのパターンが見られます。

    メリットとしては
    • 簡単
    • 他の人に見つけてもらいやすい
    デメリットとしては
    • そのアカウントが本物かどうか見分けが付きにくい
    • 自分の意思とは関係なくサーバ運営が終了してしまう可能性がある

    Twitterと違って、現在見られる分散SNS向けサーバシステム「マストドン」「Misskey」「Pleroma」などでは、バッジ機能はありません。そのため、作られたアカウントが本当にあの企業のものなの?あの有名人なの?という区別がつきません。
    対処方法としては、Twitterや、サイトから「このアカウントは本物ですよ」とリンクを張っておくことぐらいです。
    また、サーバ運営者には企業や個人がありますが、圧倒的に個人が多いです。事業継続性まで考慮されているサーバは一握りしかないと考えていいでしょう。サーバの運営が終了するとき、必然的に他のサーバへ移動する必要がでてきます。もちろん他のサーバへ移動しても同じように活動は継続できますが、終了したサーバにある過去の投稿などは消えてしまうでしょう。(拙作notestockを使えば保存は可能ですが。)


    例)
    @hakone_garasunomori@mstdn.jp箱根ガラスの森美術館
    @miraicorp@matitodon.com未来情報産業株式会社
    @nelsoncoffeeroaster@pawoo.netNelson Coffee Roaster
    @comicLO_YLNT@pawoo.net茜新社刊「COMIC LO」公式アカウント
    @careltokyo@mstdn.jp完全個室メンズエステサロン『ケアル麻布十番&白金高輪店』
    @mikamiyoh@mstdn.jpITジャーナリスト三上洋氏
    そのほか、pawooに多数の作家さん

  3. 組織としてサーバを立てて、その中にアカウントを作る
  4. 確実にブランド力が示せるパターンです。例えば、「example株式会社」が「example.co.jp」のドメインでウェブサイトを公開していたりするとき、「sns.example.co.jp」みたいなドメインで分散SNSサーバを用意するのです。
    ドメインというのは持ち物ですので、サイトのドメインに組み込んでしまう(サブドメインと言います)と、確実にその組織のサーバであると知らしめることができます。
    またこの場合、サーバ内に複数のアカウントを作って別々の運用を行うこともやりやすいです。

    @info@sns.example.co.jp組織としての総合的なお知らせ
    @pr@sns.example.co.jp広報担当者のアカウント
    @support@sns.example.co.jpサポート窓口のアカウント
    @sugoiseihin@sns.example.co.jp「(仮称)すごい製品」のプロモーションアカウント
    @top@sns.example.co.jp社長のアカウント

    みたいなことができます。

    タレント事務所なら、所属タレント毎にアカウントを作るということもできるでしょう。ただし、そのタレントが移籍したときに、過去の資産を引き継げないという問題があるので、このあたりは考慮する必要があります。そのうち、投稿内容まで含めて引っ越しできる分散SNSが出てくるかもしれません。(移行先のアカウントを表示できる機能があったりしますが、前の所属会社での活動や宣伝を引き継ぐ必要あるか?という問題もあるでしょうし、お互い納得いくように取り決めてください。)
    またグループ企業や仲の良い企業連合でサーバをひとまとめにすると、コストが圧縮できるかもしれません。(経理的なところは分からないので、上手いことしてください。)

    メリットとしては
    • 本物である証明が容易
    • ブランドを示しやすい
    デメリットとしては
    • 見つけてもらうのが難しい

    見つけてもらうのが難しいというのは何かというと、分散SNS向けサーバシステムの傾向として「フォローしてくれている人がいるサーバに向けて投稿を送信する」という動作が一般的なためです。
    多くの分散SNSでは「連合タイムライン」と呼ばれる表示がありますが、ここにはサーバが受信した投稿を含めて表示されています。各サーバの連合タイムラインに表示されていないと、そのサーバの会員に認識されていないと考えてください。(ベテランの方へ、非公開とか未収載のツッコミは飲み込んでください、ややこしくなるので。)
    できたばかりの組織サーバで投稿しても、他のサーバからは全く投稿が見えないかと思います。他のサーバの人からフォローされていませんしね。
    そこで必要になるのは、他のサーバに認識してもらうための行動です。

    簡単な方法としては「他のサーバの人をフォローする」です。
    フォローされると相手に通知が届きます。それによって、相手にアカウントやサーバの存在に気づいてもらえるようになります。
    ここで無差別フォローなどをすると嫌われる傾向があります。いいねを付けたり、返信(リプライ)で絡んでいくのも良いでしょうね。このあたりは数多の「企業Twitterアカウント運用指南書」みたいなものに書かれているのと同じかと思います。
    検索サイト(tootsearch)などで、興味ありそうな人を絞り込んでアプローチを掛けた方が良いかもしれません。
    アカウントを作っただけでフォローしても、フォロー返しは無いかもしれません。ある程度そのアカウントがどういう感じになるのか、いくつか先に投稿しておくと良いでしょう。

    やってしまいがちな間違いとしては「example株式会社のSNSを作りました!みんな登録してくださいね」と一般開放してしまうことです。
    必ずしも間違いとは言えないのですが、たいていの場合運用コストが膨れ上がってしまい、どうにもならなくなってしまうと考えられます。
    その会社の製品について話をして欲しかったのかもしれませんが、関係の無い話が投稿されたり、企業のドメインから公開しておくと問題が出る投稿をされたり、会員同士のもめ事が起きたり、それらの投稿内容の管理にコストが掛かります。
    「みんなが書き込める、会社のサポート掲示板」という感覚で解放すると、きっとそれ以上のコストが掛かると考えた方がよいです。
    一般の人たちは他のサーバにアカウントを作ってもらって、情報発信側のドメインは関係者からの発信のみに絞るという形です。

    もう一つ、これは分散SNSだけに限った話ではありませんが、やってしまいがちなものとして「example株式会社(サイト example.co.jp)のSNSを作りました。 example-sns.comです!」これは、似た名前の偽サイトかもしれませんし、「ドメイン放棄 危険」あたりで検索してもらえばいろいろ出てきますが、分散SNSの運用方針を変えたときに困ったりすると思うので避けた方がいいです。

    例)
    unnerv.jp特務機関NERV(Twitterで災害情報などを流しているゲヒルン株式会社)
    social.farend.co.jpファーエンドテクノロジー株式会社
    FLOSS.social自由・無料・オープンソースソフトウェアに関するアカウントのサーバ
    botsin.spaceボット運営に特化したサーバ

    ここまで組織という単位で話を進めていましたが、一人の個人事業だけど発信元として明確にしたいんだけど・・・、と感じる有名人もおられるかもしれません。
    大丈夫です。サーバを検索できるサービス、fediverse searchで「お一人様」をキーワードに検索してみてください。
    世の中には、こんなにも個人でサーバを運営している人がいるのです。

今の個人的お勧めは、断然に2番です。
サーバを用意するのが難しいという話がありましたが、現在はサーバを貸してくれるサービス(hostdon、Masto.hostなど)があります。

分散SNS原理主義(打倒中央集権!とか)に基づくと、そういうサービスも使わずに、サーバソフトウェアも自前で維持するべきとなるのですが、少なくとも多くの企業や有名人で法律に乗っ取った範囲で投稿するのであれば、サーバ貸しサービスで問題ないはずです。
もちろん、これらのサービスが無くなってしまう可能性もあるので、そのあたりの判断は必要です。過去に一社撤退したサーバ貸しサービス会社があります。

それなら1番の既存サーバでアカウント運営をしている人たちもいるし、いいんじゃないの?という判断もあるでしょう。
多くの場合、一般にも開放しているサーバを運営している人は、手弁当で運営している酔狂な人たちです。寄付などを受け付けているところもあるようですので、サーバ維持のためにも寄付してみることをお勧めします。(しかし個人へ寄付したときの経理的な部分や稟議的な部分で、多分ややこしいですよね。)


これを書こうと思ったきっかけなど。
先日、ガーシー2というサーバが公開され、参加者が大量に登録され運営コストが大変だという話題がありました。
中心となる人物のいろいろな情報発信アカウントが無効にされてしまったために、新たな情報発信アカウントとしての運用を目指したのだと思いますが、一般の登録を受け付け同じような思想を持つ人たちの集まりとなりました。
分散SNSでは、同じ話題に詳しい人たち(Twitterなんかでもクラスタと呼ばれる)で集まると盛り上がりやすいという傾向があります。絵描きが集まっているサーバや、特定のゲームプレイヤーが集まっているサーバや、バイク好きが集まっているサーバや、酒好きが集まっているサーバなど。ですので、ガーシー2サーバが一般登録者を受け入れたということ自体は、必ずしも間違いでは無いという部分に当たるかと思います。ただし「サイバーカスケード」や「エコーチェンバー現象」などに気をつける必要があります。
それらの問題を分散サーバ同士で繋がることによって、内部では濃い話題をしつつも、外部から「それはちょっとおかしいんじゃないの?」とツッコミを入れてもらえる環境というのは、ある程度大事なのではないかとも考えています。
しかしそのツッコミをきっかけに、先に紹介したように、一般の登録参加者が余計な発言を生み出す可能性を考慮すると、有名人のアカウントを用意するサーバは、その有名人の情報発信のみに徹し、信奉者と非信奉者同士のレスバトルは外部でやってもらうという、責任を持ちたくない部分で責任を持たないという運用の形もあるのではないかと思っています。

過去に国会議員や、有名なコスプレイヤーが既存の一般公開サーバに登録されたことがありました。著名な人だけあってアンチな人もいたようで、色々と嫌な目を受けられたようで去って行かれてしまいました。こういうとき、クラスタ同士で集まったサーバでわいわいとしていれば、ある程度気も紛れたのではないかとか、また自分たちで管理しているサーバなら、あまりにもひどい言動に対しては自分たちでサーバから閉め出す、連合サーバ間でも無視扱いにするなどの管理をすることが可能でした。
なので「有名人が情報発信専用サーバを用意する」または「クラスタで集まれるようにサーバを公開する」という選択は、ブランド(クラスタ?)の運営方針としてどちらも考えられるため、サーバを立てる前にこの部分を慎重に考える必要があるかと思います。
個人的には、せっかく分散していて嫌いなもの同士が同じサーバに同居する必要が無い仕組みなんだから、分かれて嫌いなら無視しておけば良いのに、わざわざちょっかいを掛けに行く方がどうかしているとは思うのですが。

そんな感じで、新しいSNSと言えども個人が大きな発言力を手に入れたSNSという仕組みでは、どこへ行ってもいざこざは発生してしまうかもしれません。ですが、せっかく新しい分散SNSという仕組みを手に入れたのならば、それを活用してあたらしい情報伝達方法も試せるのではないか、という提案でした。


2022/05/14

データベースサーバのファイルシステムをzfsからbtrfsに切り替えた

1月末から少しずつ作業をしていて、3月に完全切り替えをして、多分もう大丈夫そうなので書き記しておく。 

2014年11月頃から、2TBのSATA HDD 5台をmdadmによる管理でRAID5化していたのですが、障害が出ることが多く、安定性で評判を聞いていたzfs(ZFS on Linux)によるRAID5に切り替えました。

2016年9月頃から速度に不満が出てきて、1ヶ月毎にSSDに入れ替え、オールSSD化されました。

使っていたSSDは、CrucialのCT2050MX300SSD1。これは、HDDから差し替える際に、2TB・2048GBのディスク領域をそのまま移行できるということで選択されました。

この機種を選択した他の理由として、S.M.A.R.T.による監視でドライブの寿命を予測できたというところです。HDDでも、S.M.A.R.T.による監視はできましたが、どうしても駆動部品があるということで、突然死の心配がありました。SSDは駆動部分がないため安定しており、さらにSSDに使われているメモリの書き換え回数に限界があるということで、ある程度寿命に予測が付くのでしょう。

データベースサーバでは、24時間365日、大量の書き込みを行っており、S.M.A.R.T.で取得できる「寿命値」は一定の間隔で下がってくるという様子でした。

S.M.A.R.T.記録グラフ。ここで50%以下にあるグラフがCT2050MX300SSD1。

しかしこの「寿命値」も調べてみると、あくまでも計算式によるもので、0になった瞬間に壊れるわけではないようです。0になった時点で予測されるメモリチップの書き換え回数を消費したということで、0以降はいつ壊れてもおかしくないという状態だそうです。逆に言うと、性能不足のチップがあった場合は0に達する前に壊れる可能性もあるわけです。

実質2017年から使われてきたSSDも2021年で5年間、残り寿命が30%を切りそろそろ不安を覚えるようになりました。

ドライブ寿命については2年ぐらい前から気にしており、HDDからSSDへ切り替えたときのように、また1台ずつ入れ替えていけば良いだろうと、交換するドライブを見繕ってみるとCT2050MX300SSD1は1台6万円ぐらいしていたのに、2TBのSSDが2万円ぐらいまで下がっていました。量産化効果ってすごいですね。しかし容量が2000GBのドライブばかり出てきます。2TiBと2TBの違いでしょうか。

構成サイズが小さくなるようなドライブ交換は、zfsでは対応していないようです。どうしても一度RAIDを解いて、再度組み直す必要があるようです。しかも容量が小さい方に合わせられてしまう。以前仕事で触ったことのあるSynologyのNASでは、Synology Hybrid RAIDという仕様があり、サイズの異なるドライブを組み合わせて無駄なく領域を使ったRAIDが組めるというものでした。こんな仕組みが有ればいいのにと考えていました。

2022年になって、そろそろ次のストレージ構成を真剣に考えなければということで、再び調査をしてみました。相変わらずzfsでは容量減少は対応しておらず、btrfsのRAID5は動作が怪しい。

しかしbtrfsでは異なるサイズのドライブを組み合わせて容量の無駄を極力抑えた状態でRAIDが組めるという情報を見つけました。RAID5のパリティ計算をするCPU負荷も気になっていたので、この際RAID5はやめて、RAID1あたりで構成してみるか?と検討してみました。

Hyper-Vで環境を作り、サイズの異なるディスクの組み合わせでテストしてみたところ、問題なく動作するようです。障害時の復旧手順なども一通りテストして感覚をつかみました。

ということで2000GBのドライブを購入。今回は、CrucialのCT2000MX500SSD1とWESTERN DIGITALのWD Red SA500 WDS200T1R0Aです。他のメーカーを混ぜてみたのは、最近はNVMeのドライブしか買っていなかったので、2TB SATA SSDの使い心地が分からず、Crucial以外の品質も見ておきたかったためです。

新しい2000GBのドライブ2台でbtrfsのRAID1を組み、そこへzfsのデータをコピー。運用してみて動作に問題ないことを確認した後、zfsのRAID5を解放し、従来の2050GBドライブを1台ずつ2台混ぜて4台のRAID1に変更しました。運用しながらRAID構成を変更できるので便利ですね。

しかし思ったより速度が出ず、space_cacheの設定をv1からv2に切り替えてみたりしたもののずっとディスクが足を引っ張るようになりました。1ヶ月ほど調べてみたものの原因がつかめず、最終的にRAID1からRAID10へ切り替え。btrfs的にどのようなドライブの分け方になっているのか分かりませんが、なんとか処理速度も回復しました。

今後は古いドライブから死んでいくはずなので、RAID10に組み込んでいない残りの2050GBのドライブを順次入れ替えつつ、最終的に全部が新しいドライブに入れ替わる予定です。

zfsを運用していた間は、数回だけドライブを認識しなくなることがありましたが、RAID5に組み込み直すとすぐに復旧できたので、信頼度はかなり高いです。ただしzfsはカーネルアップデートの度にビルドし直す必要があります。手元で運用していたときは、画面上ではアップデートが成功しているのに再起動するとzfs領域を認識できなくなるという状態に毎回なりました。一度モジュールを完全にアンインストールして、再度インストールする必要があったので、そこだけが面倒でしたね。

btrfsはカーネルでのサポートも期待できるので、さらに安定した運用ができそうです。


2022/02/21

notestock機能追加(これすき検索、Qiitadon特殊対応)

いつも応援ありがとうございます。
今回はnotestock( https://notestock.osa-p.net )に機能追加を行ったのでお知らせです。

  • notestockに新しい検索機能「これすきモード」が付きました
    一部界隈(わたしも含む)で、アナウンス(ブーストとかrenoteとか)した後「これすき」と投稿する習慣があるのですが、それだけを検索したいなと思って追加しました。
    作ったときはすごい欲しかったんだけど、完成したらそれほど使う機会無さそうで、暇なときに見返してニヤニヤする感じかなぁと思ったりもしつつ。どんどん「これすき」していきましょう。
    これすきって正規表現で言う「これら?(すごい|めっちゃ|死ぬほど|狂おしいほど)?すき」などの派生があるので「すき」だけで検索しています。misskeyサーバを表す「○まるすきー」とかも引っかかっちゃうけど。
    デフォルトを変更したい人が多そうなら、設定画面で変えられるようにします。

  • MastoOwn対応
    (この機能は2023年1月現在、停止中)
    またQiitadon終了前と言うことで、notestockおよびMastoOwn( https://hidao80.github.io/MastoOwn/ )に機能追加して反映してもらいました。
    Qiitadonのアカウントをnotestockに登録していただいている方は、notestock登録以前の投稿が掘り返し登録されていないかと思います。Qiitadonのバージョンアップを期待し続けていましたが、見通しがなくなったので、ちょっと強引な方法で取り込めるようにしました。
    Qiitadonの対象アカウントで、各自MastoOwnの操作していただく必要があります。MastoOwnのオプションにある「notestockへ送信」にチェックを付けてください。
    notestockへの反映は即時ではありません。設定画面に残り件数が表示されます。

  • fantia以外の寄付方式に対応
    fantiaで寄付するのはちょっと・・・という声を見かけたため、Liberapayとko-fiでも受け付けられるようにしました。
    応援ユーザーの表示は、現在Liberapayだけ追加されています。
    Liberapayとko-fiだと、寄付者を非公開にすることも可能です(たしか)
    寄付先については、 https://osa-p.net/#Donation を参照してください。

notestockの公開検索対象や各種検索サービスで、notestockが含まれている投稿をときどき確認していますので、何かあれば投稿しておいてもらえると、反応したりしなかったりします。
よろしくお願いします。

 

広告