インスタンス運営の振り返り（2/2： データで振り返る）

こんにちは。前回の記事の続きです。

handon.hatenablog.jp

今日はデータで振り返るhandon.clubということで，これまでのインスタンス運営をデータから振り返ってみたいと思います。最後には総括も記載しています.

基本データ

まずはじめに基本データです。ユーザ数などは本日時点の値で以下の通りとなっています。

項目	値
開始	2017年4月14日
ユーザ数	237名
総トゥート数	274,556トゥート

ここで，ユーザ数は「237名」となっていますが，これはアカウントの削除やBANなどを考慮していません。実際にいらっしゃるユーザ数には誤差があります。

ユーザ数

handon.clubのこれまでのユーザ推移です。

ユーザ数の推移

プロットは，新規ユーザ登録があった日だけプロットしています。プロットのない期間は，新規ユーザの登録がなかったことを表しています。また前述の通り，アカウントを消したユーザのことは考慮しておらず，あくまで延べユーザ数のグラフとなります。

次に，handon.clubだけのユーザ数だけでなく，handon.clubが認識している他インスタンスの累計ユーザ数についても分析してみました。今度はユーザ総数ではなく，割合グラフにしてみました。本日のユーザ数を1とした場合，それまでの移行推移を示したグラフです。

ユーザ推移

現在のユーザのうち，12%程度（29名）は立ち上げ1週間以内に登録して頂いたユーザで，更に25%程度はTwitter APIの仕様変更が発表される2018年6月以前に登録していただいたユーザであることが分かります。また，やはり2018/8のTwitterAPI仕様変更の影響はとても大きく，その際にユーザが急増したことがよく分かるかと思います。実際，2018年8月の1ヶ月間に登録頂いたユーザは，現時点の全ユーザの登録者数のうち，36%程度（85名）をも占めています。

その後は，ユーザ数の頭打ちは見えてきたように見えますね。しかしその勢いは，まだまだ衰えてはいないようです。

なお，この傾向自体は，handon.clubに限った話でもないと思われます。Mastodonユーザ自体は増加している印象を受けています。しかし，今回のグラフで示した他インスタンスのユーザ数というのは，あくまで「handon.clubが認識している」＝「handon.clubからフォローされている/している」ユーザ数を示しています。このデータを見る上で，handon.clubのユーザ数と相関を持っている点には注意が必要です。

トゥート数

handon.clubユーザに限った累計トゥート数について，その時系列変化を示します。ユーザ急増後と急増前で傾きが大きく違うことがお分かり頂けるかと思います。また，ユーザ急増後，1日あたりおよそ2000トゥートが行われていますが，その傾きが安定していることもお分かり頂けるのではないでしょうか。

総トゥート数の推移

やはり2018年8月のTwitter API変更の影響はすごいですね。アカウント数よりもトゥート数の方が分かりやすく現れています。さらに，このブームは一過性のものかと思っていましたが，少なくともこのデータからは，その勢いは今も継続しているように見えますね。

ユーザの分析

全ユーザのトゥート数分布

handon.clubに所属している各ユーザについて，そのトゥート数をマッピングしてみました。綺麗なロングテールになっています。アクティブにトゥートしているユーザは全体の25%弱というところでしょうか。また，トゥート数0のユーザが想像より多いように思えるのではないでしょうか。これは，スパムアカウントとしてBANされたアカウントもかなりの数入ってしまっていることも影響しています（そういったアカウントは，過去のトゥートは削除されるため，0としてカウントされてしまいます）。ですので実際には, 「登録したけど1回もしゃべっていないユーザー」はこのグラフほど多くないと思います（データ上，スパムアカウントとあわせると，75人いらっしゃいます）。

ちなみに，トゥート数のトップは私でした。他のデータからも分かったことですが，やはり昔から登録頂いているユーザの方が，トゥート数が多いようです。

次にフォロワー数です。

全ユーザのフォロー・フォロワーの分布

分かっては居たことですが，トゥート数よりも緩やかなカーブになっています。トゥートは少ない閲覧専用（ROM専）ユーザも結構いらっしゃる認識なので，予想通りの結果かと思います。

最後に平均値や中央値を示します。どれも「0」のユーザが多いため，参考として「0を除いて平均値・中央値を取った値」も掲載しています。

値	トゥート数	フォロワー数	フォロー数
平均値	1161	31	30
(0のユーザを除いた)平均値	1710	44	40
中央値	21	9	11
(0をユーザを除いた)中央値	193	29	25

他のインスタンス

handon.clubはMastodonインスタンスの一つです。他のインスタンスとして，日本では，大規模インスタンスとして「mstdn.jp」「pawoo.net」「friends.nico」が有名です。Mastodonを語るにあたっては，こういった他のインスタンスの動向にも触れておきたいと思います。

まずはデータとして，handon.clubが認識している，他インスタンスのユーザ数推移を見てみたいと思います。

インスタンス毎の認知アカウント数の推移

繰り返しとなりますが，ご注意頂きたい点があります。これは handon.club からの「認知アカウント」の数を表しているだけであり，全ての登録アカウントを網羅している訳ではありません。ここでカウントされるのは，各インスタンス毎に，handon.clubのユーザをフォローしているまたはフォローされているユーザの数に限ります。そのため，実際にはこの何倍もユーザがいるであろうことはご承知置きください。そのため本来は，handon.clubのユーザ数（これは認知アカウント数ではなく「本当に登録して頂いているユーザの数」）を並べて表記するのは正しくありませんが，参考として記載しています。

当初は日本のインスタンスが多く見えてくるのは仕方がなかったのですが，最近は「mastodon.social」という巨大インスタンスのユーザが多く見えています。また，日本のインスタンスとしては，mstdn.jp／pawoo.netの2つがツートップというところでしょうか？

最後に，本日時点での，最新の認知アカウント数は以下の通りです。

インスタンス名	認知アカウント数
mastodon.social	4851
mstdn.jp	4155
pawoo.net	3737
friends.nico	966
mastodon.art	380
mstdn.maud.io	320
mastodon.cloud	264
cybre.space	225
knzk.me	196
misskey.xyz	194
octodon.social	169
niu.moe	149
theboss.tech	134
mstdn.io	125
mastodon.technology	122
mastodon.xyz	115
social.mikutter.hachune.net	114
imastodon.net	110
oransns.com	102
witches.town	92
mstdn-workers.com	86
chaos.social	82
mstdn.guru	78
bofa.lol	78
mstdn.kemono-friends.info	74
mstdn.beer	72
mamot.fr	61
mstdn.nere9.help	58
vocalodon.net	58
qiitadon.com	55
kirishima.cloud	53
baraag.net	50
wandering.shop	48
kirakiratter.com	48
toot.cafe	48
glitch.social	48
social.coop	48
pl.smuglo.li	48
switter.at	48
social.tchncs.de	48
toot.cafe	48
radical.town	44
fosstodon.org	44
botsin.space	42
icosahedron.website	42
gingadon.com	41
pokemon.mastportal.info	40
framapiaf.org	40
mastodon.sdf.org	38
todon.nl	38
mastodon.host	37
gensokyo.town	37
syasai.club	36
homoo.social	36
elekk.xyz	35
toot.cat	35
awoo.space	34
mstdn.poyo.me	32
snouts.online	31
mastodon.juggler.jp	30
otogamer.me	30
artalley.porn	29
queer.party	29
anticapitalist.party	29
chaosphere.hostdon.jp	28
gorone.xyz	28
chitter.xyz	28
shiroganedon.net	28
kemonodon.club	27
mstdn.club	26
linuxrocks.online	26
infosec.exchange	26
bitcoinhackers.org	25
mental.social	25
mstdn.love	24
vulpine.club	24
ichiji.social	24
ukadon.shillest.net	24
flower.afn.social	24
matitodon.com	23

振り返り

本当はもう少し詳細な分析をしようと思っていたのですが，タイムアップしてしまいました。これ以上やっていると年が明けてしまいそうなので，そろそろ振り返りをしたいと思います。

これまでのインスタンス運営を振り返って

大変でしたがとても楽しく運営できました。皆様にもいろいろとお助け頂き，本当にありがとうございました。

技術的な話です。先日の記事にも書いたとおり，サーバリソースは大幅に増強しました。また，別途アーキテクチャの説明はできたらと思っていますが，今後のリソース増強にも縮小にも対応出来るような作りにしてあります。ユーザ数の増減に合わせ，費用面も含めて無理なく，チューニングができるようにしたいと思います。

なお，サーバの心配をしていただき，ユーザ招待や画像付きのトゥートを控えて頂いている方もいらっしゃるようです。ご配慮は嬉しいのですが，今のところ，技術面でも費用面でも気にして頂く必要はありません。是非もっといっぱい使って頂いて，盛り上げて頂ければ幸いです。招待制にしているのも，知らない人が来るのを避けたいのではなく，スパム防止の意味合いが強いです。是非，お友達をお誘い頂ければと思います。

最後にコミュニティ的な話です。先日の記事にも書いたとおり，私はサーバというインフラの管理者であって，コミュニティの管理者ではありませんので，あくまで1人のユーザとしての振り返りです。

正直，始めた頃はここまで大きくなるとは思っていませんでしたね。今では時間帯によらずLTLが動いている状態で，トゥート数も増え続けています。オフ会もよく観測するようになってきましたね。また最近では，私の存じ上げない方でもかなりの数ご利用頂いているようで，嬉しい限りです。引き続き，様々な方にご利用頂ければと思います。

今後のインスタンス運営について

基本的にはこれまでと変えるつもりはありません。ただもし，技術観点でも，コミュニティ運用観点でも，改善して欲しいところがあれば気軽に連絡頂けると嬉しいです。全てにお答えすることができるかは分かりませんが，よりよいインスタンス運営のため，引き続き努力したいと思います。

それでは良いお年を。

インスタンスの振り返り（1/2：歴史で振り返る）

Mastodonインスタンス管理人，handon.clubのはんです。今年もお世話になりました。

2018年ももう終わりと言うことで，handon.clubについて，今年の振り返り記事を書きたいと思います。とはいっても，handon.club 自体は2017年から運営していますが，過去こういった振り返り記事は書いたことがありません。そこで，せっかくの機会ということで，handon.club 立ち上げ以後の運営を振り返った記事を書くことにしたいと思います。

ただし，書きたいことが多すぎてボリューミーになってしまいました。そこで，またまた2部制（前半・後半）とさせていただこうと思います。まずはhandon.clubの歴史について，私が覚えている範囲のことを書いてみようと思います。別途アップロード予定の後半の記事では，「データで振り返るhandon.club」として，もう少し定性的な評価を行ってみようと思います。

はじめに

この記事では，handon.clubというインスタンスの技術的な話と，handon.clubユーザによって形成されているコミュニティの話，両方を記載しています。

以下を読んで頂く前にお伝えしたいのは，コミュニティの雰囲気や話題に関する話は，あくまで「LTLを見ている1ユーザとしての感想」である，ということです。私の存じ上げない方がクローズドで会話されている場合もあります（実際にそういう事例がいくつかあることは知っています）。そういったトゥートについて，私は残念ながら見ることができませんので，私の観測範囲（※言葉が古い）での出来事だとご理解下さい。

まとめます。この記事では，技術的な話は「handon.clubの管理者」としての振り返りをしていますが，コミュニティの話についてはそうではありません。あくまで「handon.clubの一人のユーザ」としての振り返りである，としてご理解頂ければと思います。

2017/4/14 インスタンスの立ち上げ

完全にノリでインスタンスを立ち上げました。当初は自分専用の「おひとりさまインスタンス」にするつもりでしたが，公開してみたところ「使いたい」と言って頂いた方が多かったため，アカウント登録を受け付けました。この当時は，ここまでの規模に成長するとは思っておらず，サーバー構成もかなり適当でした。

2017/10/22 カスタム絵文字対応

少なくともhandon.clubに限れば，Mastodon自身の新機能追加にともなうアップデートのうち最も影響が大きかったのは，カスタム絵文字に対応した2.0へのアップデートだと思います。Mastodon界隈としても，他のインスタンスとの差別化が出来ずに居るなか，カスタム絵文字対応は差別化のため大きな要素となりました。

あまりに登録してある絵文字が多すぎると自分の使いたい絵文字を探すのが大変になってしまいますので，最近のhandon.clubでは，カスタム絵文字を大幅に整理し,クライアントからもWebからもできるだけ簡単にカスタム絵文字が探せるよう工夫しています。また，最近は絵文字の追加はユーザから要望があった場合のみにしています。場合によっては，利用頻度の少ない絵文字は削除したり，リネームを行っています。検索機能がもっと使いやすくなるとよいだけの話なのですが，当面はこういう地道な対応を続けていく予定です。

2018/4/2 初めての大規模障害

ソフトウェアのバグとオペレーションミスが重なり，丸1日サーバーを停止させました。思えばこれが，今までに一番大きな障害です。この障害発生時，データの消失リスクがあったため，とてもヒヤッとしたのをよく覚えています。この障害を契機に，データのバックアップを始めました。現在，トゥートやアカウント情報などの重要な情報は厳重なバックアップを行うようにしましたので，例えば東京が全て壊滅するくらいではデータは消えないようにしているつもりです。

なお，今年発生した障害は以下の通りです。皆様にはご迷惑をおかけし，申し訳ありません。今後，上記のバックアップに加え，監視体制強化（＝障害発生時にすぐ気づけるようにすること）にも取り組んでいきたいと思います。

#	発生日付	発生期間	原因	再発防止策
1	2018/4/2	24h程度	ソフトウェアバグ	検証環境の確立
2	2018/9/26	1h程度	さくらVPS 計画メンテナンス通知の見落とし	メールチェックの徹底
3	2018/10/28	0.5h程度	さくらVPS 障害	（リスク許容）
4	2018/10/29	0.5h程度	さくらVPS 障害	（リスク許容）

少し話は変わりますが，2017年4月のMastodon第一次ブーム直後，他のインスタンス管理者が「データを消失させた」という事故をよく聞きました。jp鯖も何度もデータのリセットを行っていましたよね。handon.clubでは，こうならないよう細心の注意を払っていました。その甲斐もあり，立ち上げ当初からのすべてのトゥート・全投稿画像を欠けることなく保持しています。一応これは，数少ない自慢です。

2018/8 ユーザの大規模増加

今年のhandon.club，ましてやMastodonの歴史を振り返るにあたり，忘れてはならないのはイベントは2018年8月でしょう。TwitterのAPI変更により，Userstreamが段階的に廃止され，またサードパーティクライアントも閉め出されるのではないかという懸念も後押しして，第二次Mastodonブームが勃発しました。

handon.clubも例外ではなく，このときに非常に多くのユーザが登録して頂きました。以下に示しているのは当時の負荷グラフで，緑の線がsidekiqと呼ばれる重要なプロセスが処理した仕事の量を表しています。8月に大幅に上昇していることが分かるかと思います。

負荷グラフ（sidekiq）

当時のhandon.clubは，一時的に高負荷になり，加えて軽い攻撃を受けていました。また，あまりのユーザ急増に耐えられず，新規ユーザ登録を数日中止したこともありました。当面はしのいでいましたが，この完全解決のために，前々より検討していた大容量のハイスペックサーバへの移転を決意しました。

また，私感ではありますが，この頃から，他のインスタンスとhandon.clubの間で「雰囲気の差」ができてたように思っています。これまでは他のインスタンスと同じような会話が多かったのですが，「LTL（ローカルタイムライン）の話題」と「FTL（連合タイムライン）の話題」に明らかな差が出てきたように思います。最初のきっかけは何だったのでしょうね。もしかしてヤクルトかな？

2018/9 サーバ移転

ユーザの皆さんは意識していないと思いますが，はんドンクラブは2018/9にかなり大規模なメンテナンスを行いました。このメンテナンスではスケールアップ（＝たくさんのユーザを収容できるようにすること）を目的に，ハイスペックサーバへ環境を移行するという作業を実施しました。つまり，全く別のサーバに，全く別の構成で，全てのデータを移行したのです。

この作業は非常に大変でした。特に苦労したのは，(1) 新しいサーバでの各種パラメータのチューニング，および(2)画像の移行でした。

前者は，できるだけ少ないリソースでスケールするサーバを構築するための努力を指します。実際にやっていることは，様々な設定ファイルのパラメータのチューニングです。やらなくても動くので，これはもはやエンジニアとしての意地みたいなものですね。

ただこの作業は，私にとって本当に勉強になりました。また，結果として，サーバもかなり安定動作するようになりました。

ちなみに，実は今でも，日々の細かなチューニングは続けています。最近では，データベース周りのパフォーマンスが少し改善したはずです（ユーザは気づかないレベルだと思いますが・・・）。引き続き安定運用に努めたいと思います。

後者は，データ量の多い画像データを，効率的かつ確実に移行する手立てを考える作業です。このためにAWSに検証サーバをたくさん立て，何度か移行の試験をしたのを覚えています。仕事でしか作ったことのなかった「手順書」も作成しました・・・。

2018/9 サーバのカンパ集め

前節で説明したとおり，9月にはハイスペックサーバへの移行を行いました。ただ，問題があります。スペックが高いということは，費用も高いということです。解決に向け非常に悩みましたが，皆さんからfantia経由でカンパを集めることにしました。その為に電気通信事業者の届出も行いました。

fantia.jp

実際には，私の想定を上回る額のカンパを頂いており，みなさんには感謝しかありません。。大変助かっています。fantiaで頂いたカンパは全てサーバ運営費用として活用しており，おかげで私の負担額はかなり少なくすんでいます。繰り返しですが，本当にありがとうございます。

なお，カンパは決して強制ではありませんので，無理なく続けていただければと思います。お金を払っていないから使ってはいけないということも決してありませんので，皆さん是非，たくさんサーバをいじめてあげて下さい（また頑張ってチューニングしないといけないのですが・・・）。

電気通信事業者については以下の記事もあわせてご参照下さい。

handon.hatenablog.jp

より細かいhandon.clubの歴史一覧

単純なバグ追加のアップデート等はこの記載から除外しています。

日付	分類	出来事
2017年4月14日	handon	handon.club開設、v1.2、ユーザ30名弱でスタート
2017年4月22日	一般	初めてのアップデート。他インスタンスでのデータ消失事故が多発
2017年5月	一般	mastodon.daily問題の多発
2017年9月17日	handon	機能追加アップデート（v1.6: activitypubへの対応）
2017年10月22日	handon	機能追加アップデート（v2.0: カスタム絵文字機能の追加）、カスタム絵文字会話が広がる
2017年12月16日	handon	機能追加アップデート（v2.1: リスト機能）、このころからアップデート時のダウンタイムを気にし始めた
2018年4月2日	handon	初の大規模障害、丸1日サーバ停止
2018年2月	handon	初めてオフ会を観測（※管理人目線）
2018年5月	handon	1ヶ月程度新規のリモートフォローが出来なかった問題を対処、このころからアップデート後のテストを強化
2018年7月	handon	初めてのスパム垢を観測、以後急増する
2018年8月	一般	TwitterでのUserstream廃止、Mastodonユーザ急増
2018年8月16日	handon	登録者数100名を突破
2018年8月17日	handon	ユーザ数急増のため緊急メンテを実施、新規ユーザ登録を受け付けられなくなる
2018年8月21日	handon	新規ユーザ登録受け付け再開
2018年8月26日	handon	大規模メンテ、6時間程度停止。画像サーバをスケールアップ。
2018年8月31日	handon	初の公式オフ会(?)
2019年8月末	一般	jp鯖、1回目の閉鎖騒動。その契機か、handon.clubのアカウント登録が増える
2018年9月1日	handon	届出電気通信事業者として手続き完了、カンパを集め始める
2018年9月2日	handon	利用規約を書いた
2018年9月頃	handon	LTLに変化、handon.club 限定の話題が多くなった印象 （※管理人目線）
2018年9月5日	handon	リソース増強のための大規模メンテ、2時間停止。GMO→さくらへサーバを移管
2018年9月5日	handon	機能追加アップデート（v2.5: ユーザプロフページの大幅変更）
2018年9月24日	handon	IPv6アクセスに対応
2018年9月	一般	jp鯖、2回目の閉鎖騒動。10月よりきぼうソフトへ移管することが発表
2018年9月26日	handon	大規模障害、1時間程度サーバ停止。その後トゥート時間がずれる問題が発生
2018年10月	一般	Pawooアプリの開発終了が発表
2018年10月27日	handon	完全招待制へ移行
2018年10月27日	handon	初の大規模オフ会（しゃぶしゃぶ）
2018年10月28日	handon	大規模障害、30分程度サーバ停止。さくらインターネットの障害
2018年12月6日	handon	公式マスコットキャラ（ドン美ちゃん）の誕生

おわりに

ここまででも大分長いですね。。 後半記事にもご期待下さい。

Mastodonを構成する技術要素（技術者向け）

こんばんは．今後，handon.clubのサーバ構成について詳細な説明記事を書く予定です．しかしそのためには，まずはMastodonの動作原理について解説しておいた方がよいかなと思います．この記事では，Mastodonを構成する技術要素について，特にスケーリングの観点を中心に説明します．

今日の記事は主に，ソフトウェア技術者向け（ある程度のバックグラウンドがある方向け）に書いてみます．ただ，それだけではおもしろくないので，後日一般向けの記事にもチャレンジしてみるつもりです．読んでみて，ちんぷんかんぷんだった方は次回をお待ち頂けると嬉しいです！

全体の概要

以下に，Mastodonの動作原理の概要図を示します．ここで，図中では，正確性は犠牲にしており，わかりやすさのため単純化していることはご留意下さい．

Mastodonの動作原理概要

まず，Mastodonはwebアプリケーションですので，全てのリクエストは一度webサーバ（公式ではnginxが推奨されています）で受け，その後適切な振り分けを行います．ここで図中では，上からユーザ（または他のインスタンス）からアクセスが行われるイメージで記載しています．

nginxからの振り分け先は3つで，Webページ（テキスト等）表示用にはrailsとNode.jsが，そして画像表示用にはS3またはSwiftなどのオブジェクトストレージが利用されています．また，Mastodonサーバ内部では，長期でデータを保持するDBとしてpostgresqlが，短期でデータを保持するキャッシュとしてredisが用意されています．更に，非同期処理はsidekiqで実現されています．

要素名	ソフトウェア名	概要
web server	nginx	HTTP/HTTPSリクエスト処理
web	rails	Web処理（通常処理）
streaming	Node.js	Web処理（Userstreamのみ）
media	swift	画像やカスタム絵文字の格納
db	postgresql	アカウント情報やトゥートの格納
cache	redis	キューキャッシュ
job queue	sidekiq	ジョブハンドラー

dockerについて

ここで注意点です．あなたがもしこれからMastodonサーバを建てようと思って調査を始めると，すぐに「docker環境」「非docker環境」という2つの環境があることに気づくと思います．dockerは，インストール済みのイメージをダウンロードしコンテナとして展開することで，自らの環境構築作業の手間を削減できる便利な技術です．Mastodonのgithubを参照すると分かりますが，Mastodon用のdockerコンテナとして，図中に記載している「web」「streaming」「db」「redis」「sidekiq」の5つのコンテナイメージおよびその設定ファイル（docker-compose.yml）が用意されています（nginxは自らホスト上に建てる必要があります）．当たり前なのですが，本記事で紹介する基本的な動作原理においては，「docker環境」であろうと「非docker環境」であろうと大きな差分はありません．

以下，それぞれ詳細を説明したいと思います．

Webサーバ（nginx）

nginx入門 from Takashi Takizawa

www.slideshare.net

みんな大好きnginxです．Apacheに比べとても軽量で，スケールすることが知られています．もちろんWebサーバならばなんでもよいのですが，MastodonのGithubリポジトリではnginxが推奨されており，サンプルの.confファイルも提供されています．

具体的な役割ですが，設定例を見ると分かりやすいです．そこで，イメージを以下に示します（ただし，この設定は説明用のため，本質ではないところは省略しています．決してコピペして使わないで下さい）．

# 1. HTTPをHTTPSへリダイレクト
server {
  listen 80;
  listen [::]:80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name example.com;

　# 2-1. HTTPSの設定
  ssl_protocols TLSv1.2;
  ssl_ciphers EECDH+AESGCM:EECDH+AES;
  ssl_ecdh_curve prime256v1;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;
  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  # 2-2. HSTSの設定
  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  # 3. 画像サーバへリダイレクトする際にCDN向けheaderを追加する設定
  location ~ ^/(emoji|packs|system/accounts/avatars|system/media_attachments/files) {
    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files $uri @proxy;
  }

  # 4-1.「web」（ブラウザからのリクエスト，REST API）へのリバースプロキシ
  location @proxy {
    proxy_pass http://127.0.0.1:3000;
  }

  # 4-2.「streaming」（Userstream）へのリバースプロキシ
  location /api/v1/streaming {
    proxy_pass http://127.0.0.1:4000;
  }

}

主な役割は以下の通りです．

項番	役割
1	HTTPをHTTPSへリダイレクトする
2	HTTPS，HSTSなどセキュリティ周りの設定を行う
3	特定のコンテンツに対してのみ，キャッシュを要求する
4	リバースプロキシ

1は分かりやすいと思いますので説明は割愛します．2, 3, 4について，以後で説明します．

Letsencript（HTTPS）

Let's Encrypt の使い方 - Let's Encrypt 総合ポータル

個人のWebサイトでHTTPS対応をする場合，数年前まではそれなりに高額な費用が発生していました．しかし今となっては，「letsencrypt」を使えば，無料でかつ簡単に証明書を取得することができます．

Mastodonでは，HTTPSを使うことが強く推奨されていますし，構築マニュアルでもこのletencryptが紹介されています．HTTPS対応をしない場合，Google Chromeで閲覧すると警告画面が出てしまうだけでなく，Google等の検索エンジン最適化（SEO）でも不利だと言われています．letsencryptを使って，是非HTTPS化には対応しておきたいところです．

letencryptは，提供されるいくつかの方法のうち，いずれか一つでサーバを認証すれば，HTTPS対応に必要な証明書を発行してくれます．nginxのconfig中の項番「2」に該当する「 /etc/letsencrypt/live/example.com/fullchain.pem 」等が，実際にletsencryptから発行された証明書を表しています．

余談ですが，letencryptは，通常の証明書に比べその有効期限が非常に短い（3ヶ月）です．そのため通常は，cronなどのジョブスケジューラを使って，3ヶ月に1回以上の頻度で自動の証明書更新を設定する必要があります．

CDNとキャッシュ

CDNの仕組み（JANOG36） from J-Stream Inc.

www.slideshare.net

CDN（Content Delivery Network）は，世界中に分散設置されたキャッシュサーバの塊です．例えばAppleが，iPhoneのOSイメージを配布するケースを考えましょう．アメリカのデータセンタにだけサーバを立ててしまうと，日本やヨーロッパからの大量のアクセスがあった場合，都度アメリカからデータを配信することになってしまいます．1万回ダウンロードの要求があれば，全く同じOSイメージが1万回も海を渡るのです．これでは非効率です．そこでCDNは，よくアクセスされるコンテンツを自動的にキャッシュします．そして，日本からのアクセスでは日本のキャッシュサーバから，ヨーロッパからのアクセスではヨーロッパのキャッシュサーバからコンテンツを配信します．

このCDNによって，ユーザがダウンロード時間の短縮というメリットを受けることができるだけではなく，配信サーバの管理者側もサーバ負荷を削減することができるのです．夢のような話ですね．これもLetencriptと同じで，昔は有料のサービス（Akamaiなど）しかなかったのですが，近年は「CloudFlare」に代表される無料CDNサービスが登場しました．なぜ無料なのか不思議でならないのですが，一定の制限はありつつも，普通に使えます．

Mastodonの場合，CDNを使うことは必須ではありません．しかしながら，特に投稿画像やカスタム絵文字などについては，CDNを通すことでユーザのレスポンスを大幅に改善することができます．更に，CDN事業者によっては，DDoS攻撃を緩和してくれるサービスを提供している場合もあります．つまり，CDNを通すことでセキュリティを高めることも可能なのです．そのため，一定規模以上のインスタンスでは，CDNを活用しているケースが多いようです．

さて，nginxの話に戻ります．項番「3」は，CDNを強く意識した設定です．これは，CDNサーバに対して，「emoji（カスタム絵文字）」や「media_attachments（投稿画像）」については最大限キャッシュして下さいね，という指示を送るための設定です．nginxではこういった設定までも簡単に行えるのです．

リバースプロキシ

プロキシサーバとリバースプロキシサーバの違い | ITSakura

残りの項番「4」は，リバースプロキシの設定です．リバースプロキシは様々な目的で用いられますが，これまでに説明したようなnginxを通すことによるメリットを教授するため，MastodonのWebサーバに直接接続するのではなくnginxを "噛ます" ための設定だとご理解下さい．

リバースプロキシは説明し始めると長いのでこの辺で終わりにします．

フロントエンド（rails，Node.js）

Mastodonの主要部分はRubyで書かれています．実際ソースコードを眺めると，かなりの部分がRuby on Railsで書かれていることが分かるかと思います．この部分は詳細を説明し始めると長くなりますので割愛します．ただ，基本部分は前述の通りrailsで実現されているものの，UserStreamだけはNode.jsで実現されていることがポイントかと思います．

Node.js

オタク×Node.js勉強会 from 虎の穴 開発室

www.slideshare.net

Node.jsはストリーミングAPIを提供することのできるサーバサイドJavascriptです．私はインフラ屋さんなのでWeb系の技術には大変疎いのですが，それでも知っている超有名なサーバサイドJavascriptです．「ノンブロッキングI/O」を実現していて，シングルスレッドで実行するにもかかわらず応答が帰ってくるまでの間の排他を必要としないため，非常に高速かつスケーラブルであることが知られています．つまり，多量のユーザから同時にUserstreamの受信要求があったとしても，ある程度スケーリングするようになっています．

DB（postgres，swift）

postgres

employment.en-japan.com pgtune.leopard.in.ua

基本的なデータベースとしてはSQLであるpostgresqlが採用されています．つまり，皆さんの過去のトゥートは，全てこのpostgresの中に入っていることになります．例えば，ユーザがタイムラインを表示してくれというアクセスをした場合、そのユーザはrails（web）やNode.js（streaming）を通して，postgresのDB内を参照しています．

なお，postgresは大変取り扱いやすいSQLではありますが，Mastodonにおいて最もスケーリングが難しい部分と言われています（まあ，DBがネックになるのはMastodonだけではないのですが・・・）．特にpostgresは，RAMをバカ食いします．RAMのチューニングがとても重要です．

チューニングについては，pgtuneというサイトが便利です．なんと自動で，マシン環境に応じた設定ファイルを生成してくれます．サンプルとして，以下に，pgtuneを使って作成した，postgresql.conf設定例を示します．

max_connections = 50
shared_buffers = 1GB
effective_cache_size = 3GB
maintenance_work_mem = 256MB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 4
effective_io_concurrency = 2
work_mem = 20971kB
min_wal_size = 1GB
max_wal_size = 2GB
max_worker_processes = 2
max_parallel_workers_per_gather = 1
max_parallel_workers = 2

一番上に記載している「max_connections」は，とても重要な設定です．同時接続コネクションをいくつまで許容するかを決定します．そのうえで，他の部分で各コネクション毎のメモリの使い方を指定することで，postgres全体のチューニングを行いますとなります．postgresでは，同時にたくさんのコネクションを接続するためには多数のRAMを必要とするため，RAMが少ないマシンではコネクションを制限してRAM消費を減らす，などの工夫が必要となります．もし，マシンの搭載RAMではまかないきれないようなコネクション数を許容する設定にしてしまうと，常にswapが発生する状態となり，パフォーマンスに大きく影響します．pgtuneでは，この辺りの設定を自動で行ってくれるのです．

ただ実際は，よほど大規模なインスタンスではない限り，pgbouncerと呼ばれるコネクションプールツールを使って，RAM不足の問題を簡単に解消することも可能です．コネクションプールは，postgresqlがスケーリングしない理由の一つである「同時にたくさんのコネクションを接続するためには多量のRAMを必要とする」という問題を解決してくれるツールです．

swift/S3

画像の格納にはオブジェクトストレージが使われています．当初はS3にしか対応していませんでしたが，いつからかswiftにも対応しました．本家のS3はお高いので，代わりにS3互換ストレージか，OpenStack swiftを使っている人が多い印象です．

前述の話と合わせると，大半の画像データはCDNがキャッシュしているので、「CDNがS3/Swiftに画像を取りに行く」とも言えますね．

格納されている画像は，「アイコン画像」「トゥートに添付された画像」「カスタム絵文字の画像」の3種類です．ここで，全ての種類の画像は，他のインスタンスから受信した画像も含まれる点に注意してください．言い換えると，自インスタンスの画像は，他インスタンスのDBにもキャッシュされていることになります．

なお，このような他インスタンスのキャッシュを持ち続けると，ストレージ容量が肥大化してしまいます．そこでMastodonでは，ある程度時間のたった古いトゥートに添付された画像については，簡単に削除できるツールが提供されています．もちろん，自インスタンスの画像は消さずに残すことが可能です．一般には，このツールをcron等の定期実行ツールで動かすことが多いです．

余談ですが，この仕様は，過去Pawoo関連で大きな問題を生みました．詳細は割愛しますが，「ポルノ画像が全世界のMastodonサーバーにキャッシュされ，インスタンス管理者が皆逮捕されてしまうのではないか？」との懸念から，Pawooをインスタンス単位でブロックする流れが生まれたのです．現在はインスタンス単位で画像をキャッシュする/しないを選択することができるため，ことなきを得ています（got ことなき）．

なお，「docker環境」で構築した場合含め，初期設定では，画像は全てローカルに保存されています．つまり，オブジェクトストレージを一切使わない設定になってしまいます．以前のJP鯖の管理人であるnullkal氏も発言していましたが，このローカル保存は本当にスケーリングしませんし，また後からの環境変更も困難です．スケーリングのためには，AWS S3とまでは言いませんが，S3互換ストレージ，またはswiftを使うべきです．

バックエンド（redis，sidekiq）

sidekiq

Mastodonの全ての動作は同期処理で行われているわけではありません．主に非同期処理を担うのがsidekiqです．sidekiqは，Railsアプリケーションでよく使われるジョブキューとなります．またsidekiqは，待っているジョブをキャッシュしておく場所として，redisを必要とします．そのため，Mastodonもredisを持っています．

Mastodonにおける非同期処理について説明します．例えば，Mastodonのインスタンス間のトゥート配信では，activitypubと呼ばれるプロトコルが使われています．例えばAさんが発言した場合，そのAさんが所属しているインスタンスは，Aさんをフォローしている人がいる他のインスタンス全てに対して，トゥートを配信しなくてはなりません．これは非常に重たい処理ですし，仮に落ちているインスタンスがあればリトライをしなくてはなりません．このような処理を同期処理で実施していては大事になってしまいます．そこで，Mastodonではこういった非同期処理をsidekiqに担わせているのです．

その他の非同期処理としては，トゥート本文中のURLのインラインプレビューを更新する作業，メール送信機能などが上げられます．これら非同期処理はいくつかの「キュー」に分類されていますので，インスタンス管理者は各キューにどれだけサーバリソースを割り当てるか設定することもできます．ただし，初期設定，特にdocker環境では，全ての「キュー」が対等に扱われるようになっています．

キュー

さて，「キュー」には，default，mail，pull，pushの4つがあります．pullとpushが他インスタンスとの連携（activitypub）に関するキューで，defaultとmailが自インスタンスに完結する処理に関するキューです．

キュー名	内容
default	インスタンス内部でのトゥート処理
mail	新規登録，フォロー通知などユーザへのメール配信
pull	他インスタンスからのトゥート受信
push	他インスタンスへのトゥート送信

ちなみに大規模インスタンスの一つであるPawooでは，スケーリングのためにわざわざこのキューを独自で拡張しているそうで，スケーリングのためにはキューを正しく使いこなすことが重要であることがお分かり頂けるかと思います．

スケーリングのために注意すべきは，sidekiqプロセス自体は，CPUのシングルスレッドしか使えないという点です．しかし，例えば4キューを別々のsidekiqプロセスで処理させることで，簡単にマルチスレッド化が可能です．つまり，使っているCPUが4スレッド以上あれば，うまく別スレッドに割り当てて互いの影響を最小限にすることが可能なのです．

よく，「sidekiqが詰まる」と言っているMastodonインスタンス管理者を見かける，という方もいらっしゃるのではないでしょうか．これは，処理が間に合わず，キューが増え続ける状態を指しています．このように，sidekiqは，特に小中規模インスタンスでは最もスケーリングが難しい部分です．ただし前述のとおり，プロセス数を増やすことで実行スレッドを簡単に増やせること，またDBのような排他処理も不要なため実行サーバを大量に増やすことで並列処理が容易なことから，サーバリソースさえつぎ込めばいくらでもスケールします．つまり，「金で殴る」ことが簡単な部分なのです．

オープンソースとライセンス

少し余談です．

当然，Mastodonを構成する全てのコンポーネントはオープンソースとして公開されています．ただし，Mastodonのソースコード自身は，AGPLライセンスで公開されていることに注意が必要です．

AGPLライセンスは，GPLと大変よく似たライセンスです．GPLの条項の中には，「利用者からソースコードを求められた場合，必ず公開しなくてはならない」という旨の規定があります．このように，オープンソースをベースに別人が追加開発したソフトウェアであっても，それがオープンソースとなることが保証される点が特徴です．オープンソース界の発展に繋がる，たいへん"強い"ライセンスではありますが，一部企業等からは自ら開発したソフトウェアの収益化が難しくなるため，避けられることもあるライセンスです．

AGPLとGPLの違いは，この「利用者」の定義です．端的に言うと，AGPLでは，利用者の定義が「Mastodonのソースコードを改変してWebに公開した場合，そのインスタンスに登録したりトゥートを閲覧する人」にまで広げられています．GPLよりも"強い"と言うことも出来ると思います．

Pawooやfriend.nicoなど，Mastodon本家のコードに追加開発を加えたインスタンスについても，そのソースコードが公開されていることは有名だとは思います．この理由はこのライセンス条項によるものだと考えられます．

終わりに

今日はMastodonを構成する技術要素について話をしました．私の運営する「handon.club」でどのような構成になっているか，という話まではできませんでしたので，今後の記事にご期待頂けると嬉しいです．また，非技術者向けにも分かりやすい解説記事についても書きたいと思っていますので，そちらを楽しみにしている方はしばしお待ち頂ければ幸いです．

もし当記事に明らかな誤り等有ればコメント等でご指摘頂けると大変嬉しいです・・・．

参考にさせて頂いた文献

私がMastodonの技術要素の理解だけでなく，インスタンス構築に当たっても参考にさせて頂いた記事のご紹介です．もちろんこれだけではありませんが，3つに絞ってみました．

qiita.com

inside.pixiv.blog

http://amzn.asia/d/49xq410amzn.asia

追記

2018/12/20 一部説明が不足していた部分を追記しました．まだまだ追記予定です．

電気通信事業者の登録について（後半）

先日の投稿では，電気通信事業者とはそもそも何なのか，また，どういったケースに電気通信事業者としての届出が必要なのか，といった点について説明をしました．

handon.hatenablog.jp

本当はもっと短く書きたかったのですが，制度が複雑なため，とても長編記事になってしまいました．しかし，もともとこの記事は，今後電気通信事業者として届出を考えている方の参考になればよいなという思いで書き始めたところがあります．前回の記事では届出方法など必要な情報が不足していたと思いますので，今回の記事では，具体的な申請内容について解説できればと思います．

届出先の確認

まずは届出先を確認しましょう．個人での電気通信事業を届け出る場合，住民票のある住所を元に，各地方の総合通信局または総合通信事務所に届け出をします．総合通信局は北海道・東北・関東・信越・北陸・東海・近畿・中国・四国・九州に，総合通信事務所は沖縄にあります．具体的な連絡先や郵送先は各総合通信局または総合通信事務所に問合せてください．

参考までに，関東地区の場合の連絡先は以下のURLのとおりです．

総務省｜関東総合通信局｜手続に関するお問い合わせ及び書類の提出先

届出書類の作成

必要な書類のリストは以下のURLに記載があります．確認して下さい．なお，このページは関東総合通信局内のページですが，届出書類自体はどの地域でもほぼ同様です．

総務省｜関東総合通信局｜届出書類（届出電気通信事業）のダウンロード

上記ページによると，新規の届出を行う場合，個人であれば以下の書類が必要となります．

【電気通信事業の届出に必要な書類（個人の場合）】

• 電気通信事業届出書 （様式第8）
• 提供する役務に関する書類（様式第4）
• ネットワーク構成図（様式第3）
• 住民票

それぞれフォーマットや記入例はURL中に記載がありますので，基本的には従っていればOKです．以下，何点か注意点を記載します．

様式第4

提供する役務を記載する書類です．ややこしいですが，私は「インターネット関連サービス（ＩＰ電話を除く）」を選択しました．

様式第3

ネットワーク構成図を記載する書類です．そこまで詳細に書く必要はないと思います．参考までに，私の書いた構成図を以下に示します．

ネットワーク構成図

届出

ここまで記入できたら，冒頭に述べたとおり，自分の居住地に応じた郵送先へ必要書類を郵送します．返信用封筒の同封が必要ですのでご注意下さい．なお，届出に際し，特段の費用は必要ありません．郵送料金のみで届出が可能です．

届出の完了

処理が全て完了したら，総合通信局または総合通信事務所より書類が返送されてきます．私の場合は，1週間程度で返送されてきました．書類には，自分の届出番号と届出年月日が記載されていますので，大事に保管しておきましょう．

おわりに

以上が届出の方法です．私感ですが，思ったより簡単だと思います．

繰り返しになりますが，前の記事に記載のとおり，Mastodonサーバを運営するにあたっては，電気通信事業を「営む」場合，届出が必須となります．届出を行わなかった場合は罰則規定もありますので，必ず届出をするようにしましょう．また，本記事には，個人の見解を記載している部分もありますので，詳細な規則等については，必ず総合通信局等に問合せるようにして下さい．

電気通信事業者の登録について（前半）

はんドンクラブは電気通信事業者として届出をしています．この記事では，今後同様の届出をすることを考えている方に向け，この背景をご説明できればと思います．2部制の予定です．

電気通信事業とは

まずは電気通信事業の定義です．総務省によると，以下3つを満たすものが電気通信事業と定義されています．

【電気通信事業の定義】

• 「電気通信設備を他人の通信の用に供する」
  • 自分以外が一切使わない場合は該当しない
• 「電気通信役務を他人の需要に応ずるために提供する」
  • 個人のWebページ開設など，自己の需要（言葉は悪いが『自己満足』）のためであれば該当しない
• 「事業である」
  • 一時的なものは該当しない

いくつか注意点を説明します．

まず，電気通信設備とは，ルータ・サーバ・無線装置・伝送路などを差します．ネットワーク機器に限らず，サーバであっても該当するのです．また，このサーバについては，他人の設備，例えばレンタルサーバやクラウドサービスを使って運用する場合であっても，電気通信設備に該当するため注意が必要です．物理サーバであるか論理サーバであるかは関係ないことになります．

また，「事業である」というのは，「利益を狙っている」という意味ではありません．あくまで，継続的・反復的に行うかどうか（一時的でないか），という意味です．

以上から，Mastodonサーバを継続して運営することは，サーバを建てる場所が自宅なのかクラウドなのかによらず，電気通信事業に該当するということになります．

電気通信事業者とは

さて，電気通信事業の定義ができたところで，次は「電気通信事業者」の定義です．一般にいう「電気通信事業者」には，登録電気通信事業者と届出電気通信事業者の2つが存在します．昔は第1種とか第2種とか呼んでいたものに近いです（厳密に同じなのかどうかは知りません）．さらに，「登録または届出を要しない電気通信事業」と呼ばれる電気通信事業もありますので，結果として，電気通信事業者が行う電気通信事業には以下3つのパターンがあることになります．

【電気通信事業の種別】

• 登録電気通信事業
• 届出電気通信事業
• 登録または届出を要しない電気通信事業

ただし，登録電気通信事業者は，自ら伝送路を敷設する場合など，大がかりな事業を行う事業社に限ると認識して問題ありません．実際に該当する社は日本全国で300社程度しかなく，NTTグループやKDDIと言ったキャリア社，JCOMなどのケーブルテレビ事業社が該当します．個人が電気通信事業を行うする場合，事実上，届出電気通信事業者のみが候補になると考えましょう．

さて，これまでの話を総合すると，個人がサーバを他人に使ってもらう場合，「届出電気通信事業」か「登録または届出を要しない電気通信事業」かという判断が必要 だということになります．もちろんMastodonサーバーも例外ではありません．「届出電気通信事業」に該当する場合は，申請書類を通信局に送付する必要がありますが，「登録または届出を要しない電気通信事業」に該当する場合，特段なんの手続きも必要ありません．

判断の方法ですが，実は非常に複雑です．私の理解ですが，基本的には以下を全て満たす場合，「届出電気通信事業者」であると理解しています．

【電気通信事業を行うにあたり届出が必要な条件（全て満たす場合必要）】

• 「多数のユーザにサービスを提供する場合」
• 「他人の通信を仲介する場合」
  • 不特定多数が閲覧可能な場所で表示される場合には仲介ではないため該当しない
• 「電気通信事業を営む場合」
  • 利益を上げようとしている場合は該当する（実際に儲かっているかどうかは関係無い）

1点目はインターネットにサーバーを公開する場合は必ず該当するため，2点目と3点目が議論ポイントになります．

まず，2点目の「他人の通信を仲介する場合」です．これは例えば，2ch（5ch）のような，不特定多数が閲覧できる掲示版は「他人の通信の仲介」には該当しないとされています．しかし，通信を行う者だけが閲覧できるメッセンジャーなどは「他人の通信の仲介」に該当するとされている点に注意が必要です．つまり，Mastodonのケースでは，公開されている普通の発言（トゥート）に関する機能だけであれば該当しなかったのですが，Direct Message機能という1対1で非公開の会話ができる機能が実装されているため，「他人の通信の仲介」を行っていると判断されます．

さて，ここまで述べてきたとおり，Mastodonサーバを建てる場合，上記3点目の「電気通信事業を営む場合」に該当するかどうかで，電気通信事業の届出が必要かどうか判断すべき と考えてよいことがお分かり頂けただけたかと思います．

当インスタンスにおける届出要否の判断

結果として，当インスタンスのはんドンクラブでは，「電気通信事業を営む」（＝利益を上げようとしている）ものだと判断し，電気通信事業者としての届出を行いました．ただし，直接的に利益を上げようとしている訳では決してありません．では，なぜ届出をしたのかというと，運営費用の一部をカンパでまかなうことにしたためです．カンパを募ることが「営む」と判断されるかは大変微妙なところだと思います．しかし，総務省の運用では，「宗教団体が立ち上げたSNSサービスは，そのサーバ代の一部が宗教への寄付でまかなわれていると考えられることから，届出電気通信事業者とみなす」ことになっています．つまり，「間接的に」一部費用を負担してもらう場合，さらに，強制ではなく「任意で」一部費用を負担してもらう場合であっても，電気通信事業を「営む」，と認識されるのです．私は，はんドンクラブも，（宗教団体ではありませんが，）ほぼ同様の事例に該当する可能性が高いと判断しました．

ちなみに，この判断自体は，通信局へ確認した訳ではなく．個人の見解である旨はご理解ください．しかし，「登録または届出を要しない電気通信事業」であっても届出をしてはいけない訳ではありませんので，安全側に倒して届出をしておくというのは一つの選択肢になるかと思います．

届出電気通信事業者の責任

届出方法については後編の記事に書くとして，届出電気通信事業者になるとなにが起こるのかを解説します．まず第一に，申請にはいくらかの費用がかかります．その上で，以下の義務が課せられます（明らかにMastodonサーバ運営に関係のないものは省いています）．

【届出電気通信事業者の義務】

• 通信の秘密を守ること
• 消費者を保護する，個人情報を保護すること
• 重大な事故を報告すること

1点目，2点目は想像が付くと思います．通信の秘密については，万が一漏洩があった場合，30日以内に総務省報告が必要な点だけ注意しておきましょう．3点目だけ注意が必要なので詳しく説明したいと思います．

電気通信事業者は，サービスの中断などの事故が発生した場合，総務省に報告する義務が生じます．報告には「即時報告」と「四半期報告」があり，それぞれ以下の要件で定義されています．

• 即時報告 ： 以下（＊）に該当する場合
• 四半期報告：　影響利用者数 3万 以上 又は 継続時間 2時間 以上の場合

（＊） 総務省｜安全・信頼性の向上｜重大な事故の報告

即時報告については，普通のMastodonインスタンスでは該当することはほぼないと思います（ユーザが3万以下の場合，絶対に該当しないためです）．

注意が必要なのは，四半期報告です．3万人以下の小規模インスタンスであっても，2時間以上継続して障害を発生させた場合は，総務省への報告が義務となるのです．義務を怠った場合，罰則規定もあります．メンテナンスなど予告をしたものは該当しないと思われますが，本当にオペレーションミス等で2時間以上サーバを落としてしまった場合は，必ず報告をするようにしましょう．

おわりに

まずは電気通信事業者とはなんぞや，という点に着目して記事を書きました．こんなにボリューミーになるとは思っていなかったので自分でも驚いています．次は届出方法について開設したいと思います．

なお，法律に関することは以下のPDF（電気通信事業参入マニュアル）が全てです．電気通信事業者に該当する可能性がある場合，当ブログ記事だけでなく，必ず原本もご確認下さい． http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/japanese/misc/Entry-Manual/TBmanual02/entry02_01.pdf

運営ブログを始めました。

Mastodonインスタンスの はんドンクラブ http://handon.club の運営ブログを始めました。運営上のお知らせ，技術的な解説などを予定しています。はんドンクラブに関係の無い記事も書くかもしれません。

handon.club