Mastodon Meetup at Tokyo 2018 @ Internet Initiative Japan Inc.

BLUECORE.NET
Home IT infrastructure hobbyist
Mastodonに対する私のコレまで、コレから。
～Social.BLUECORE.NETのご紹介～
2018/11/03 第三版
BLUECORE.NET ろーかるゆーざー
<(_ _)>
ﾄﾞｰｿﾞﾖﾛｼｸｵﾅｼｬｰｽ

View Slide

Home IT infrastructure hobbyist -BLUECORE.NET
話の進行内容について
自己紹介
沿革
技術的な事例
Kubernetesネタ
CDN/Elasticsearchネタ
DRネタ
最後になんか適当に
喋りきれないときはスキップすることがあります。
予めご了承ください。

View Slide

自己紹介
 ろーかるゆーざー(localYouser)/ Yuichi Tominaga：40歳
 20年前からこのHandle Nameであり、某社とは一切関連がございません。
 九州在住のITオンプレ専門インフラエンジニア（？）をやっています。
 Mastodonアカウントは、@[email protected]
 Webサイトは https://www.bluecore.net

View Slide

2017年3月当時の私の能力
 よく扱うもの
 サーバ・ストレージ製品(ミッドレンジから少しハイエンドあたりまで)・vSphere(SMBレベル)
 OSはプラットフォーム階層まで。ミドルウェアレイヤー以上はあまり得意としてない。
 時々扱うもの
 ネットワーク製品(LANぼちぼち、WANチョットだけと言うレベル)。
 主にプロジェクトリーダー活動が多く、チョットだけプロジェクトマネージャ業をやっている
私には、実は「開発経験」が
ほぼ皆無

View Slide

Mastodonを知るきっかけ

View Slide

Mastodonを知るきっかけ
 2017年3月頃に、「TwitterみたいなSNSが登場」と言うのは聞こえてた
 Mastodonと言うネーミングをきいて「なんかえらく厳ついな」と言うイメージ
 試しにmstdn.jpにユーザ登録を行い、流速の速さに驚く(よくブラウザが死んだ)
 自分でインスタンスを立てられることを知る
 自分で立てたインスタンスを他のインスタンスと連携できることを知る
じゃぁ、せっかくだし
自宅のマシンで立ててみるか

View Slide

Mastodonに魅力を感じた点
 人が集まらなければ意味がない
 アクセスがなければDBには何も溜まらないし、
何も動かない
 コンテンツも集まらない
 一人で投稿しても寂しいだけ
従来のSNS(OpenPNE等) Mastodon
 人が集まらなくても、繋がれる
 他インスタンスのトラフィック流入
 システムとしての挙動をよりリアル
なものとして確認できる

View Slide

うちのインスタンス紹介

View Slide

まず、作ったインスタンスがこちら

View Slide

特徴？
 あまり当インスタンスをコミュニティスペースと
して考えてない
 突発メンテナンスとか、ざら。
 知った技術は使ってみないと気がすまない
 コンテナオーケストレーター(Kubernetes/Docker)
 分散ストレージ(Ceph)
 SDN(純L3ネットワーク）
技術的興味が最優先
 カテゴリとかはあまり気にしてない
 楽しければソレで良い（超適当）
 実は人生相談とかもOK牧場
雑談大好き
 運用してたらだいたい何かしら壊れる
 壊れても戻せるように
 壊れるのを恐れてたら何もできない、だが壊れて
復旧不能というのは色々つらい
データ保全

View Slide

成長の軌跡
～だが、何処まで行ってもお一人様～

View Slide

当インスタンスの沿革
 第一次構成(2017/4 - 5)：Ver.1.2.1
 Docker-composeを使用した単一ホスト/コンテナ構成
 第二次構成(2017/5 - 2018/5)：Ver.1.3.1-2.2.0
 非Docker-3台構成(AP/DB/Redis)
 ストレージは外部NFSストレージを使用
 EMC UNITY VSA Community Editionを使用、2台構成で相互Replicator構成
 第三次構成(2018/5 - 7)：Ver.2.2.0-2.3.3
 Kubernetesを使用したDockerコンテナ構成
 ストレージは外部NFSストレージを使用
 第四次構成(2018/7 - 現在)：Ver.2.3.4-2.5.0
 Kubernetesを使用したDockerコンテナ構成
 ストレージは分散ブロックストレージ(Ceph)を使用
 DR構成も作った(現在、一部DR構成で稼働中）
1からスタート
最も長持ちした構成
DB構成変更に失敗
DBが吹っ飛んで消えた
NFS Storageは2ベイNAS
スペックの割に性能がしょぼかった
安定した性能を求めてCephに手を出す。
度々崩壊しつつも、現在SSD Cache
加えたりしながら徐々に進化中

View Slide

第1次構成(お試し)
Internet
UTM(WAF)
Mastodon Server(12vCPU/8GB RAM/300GB VHD/CentOS7)
Nginx(HTTPS)
SSL証明書
インストール
SSL証明書
インストール
証明書は格安のKing-SSLを使用
（衝撃の980円/年)
Mastodon
_db_1
Mastodon
_redis_1
Mastodon
_streaming_1
Mastodon
_sidekiq_1
Mastodon
_web_1
Mastodon
_web_run_1
Docker

View Slide

第2次構成(非Docker構成)
Router
REDIS
(2vCPU/2GB RAM)
AP
(4vCPU/4GB RAM)
DB
(2vCPU/2GB RAM)
Redis
Data
mastodon/live DB data
Unity VSA#1
Redis live
DB
data
BKUP
Unity VSA#2
De
Dupe
StorOnce VSA
静的NAT/Firewall
Bacula使って
データバックアップ
NAS間はReplication
障害時は手動F/O
構成データは片っ端か
らNFS NASにデータを
配置する
nginx
puma
sidekiq
streaming
SSL終端
pgsql
redis

View Slide

第3次構成(k8s導入)
sns-ap
mastodon-
data
redis-data
NAS
物理ネットワーク
(1GbE)
IPv6 Gateway (IIJ SEIL/x86)
IPv4 NAT Gateway(YAMAHA RTX-3000)
search
engine
IPv6
Backbone RT
(LS3610)
IPv6
Backbone RT
(RB2011UiAS)
4vCPU/2GB RAM/40GB VHD
12vCPU/10GB RAM
40GB VHD
【全体】
1Master/4Worker
Master: 8vCPU/5GB RAM
Worker: 8vCPU/6GB RAM
【AP】
7Podsスケールアウト構成
Mastodon Github記載の内容に従い、必
要領域は外部切り出し
負荷分散はServiceリソースが行う
【DB】
2Pods構成
PostgreSQL Cluster使用
各Workerノードの領域を使用
【Redis】
3Podsx2セット構成
Redis Cluster + Sentinel使用
MasterのみNFSデータ使用
IPv6 IPv4
Service Name
port
5432
DB1 DB2
port
6379
Service Name
MASTER
SLAVE
SLAVE
port
26379
Service Name
SENTINEL
SENTINEL
SENTINEL
DB-BACKUP
Project Calicoが提供する共通セグメント
(16bit maskだが、実際にはホスト毎に26bit mask)
Service Name
x4
puma
x2 x4
Sidekiq
Streaming
port
4000
port
3000

View Slide

第4次構成(Ceph導入)
Ceph-01
Ceph-02
Ceph-03
Ceph-04
admin
osd
mon
admin
osd
mon
admin
osd
mon
admin
osd
StoragePool
Master:
8vCPU/8GB RAM/120GB VHD
Worker#1: 8vCPU/6GB RAM/120GB VHD
Worker#4:8vCPU/8GB RAM/120GB VHD
puma
sidekiq
default
sidekiq
other
puma
sidekiq
default
sidekiq
other
stream
ing
sidekiq
default
sidekiq
other
stream
ing
sidekiq
default
sidekiq
other
Redis
5GiB
DB-1
20GiB
sns-ap
External router/UTM
コンテナ向け
SDN
サーバ用物理NW
(GbE)
AP
200G
libra
NFS
repo
6vCPU
8GB RAM
300GB VHD
4vCPU
8GB RAM
300GB VHD
6vCPU
8GB RAM
300GB VHD
4vCPU
8GB RAM
300GB VHD
主要構成要素
物理2ノード内、
仮想12ノード
物理総リソース量：
CPU: 12Core
RAM: 168GB
HDD: 10TB
Ceph用
内部NW

View Slide

主な構成要素・構成動機
コンテナ技術
分散ストレージ
リソース集約度を向上させたかった
メモリをどんなに増設しても、リソースがカツカツで、
とにかく余裕を確保したかった
コンテナベースで安定したブロックプロビジョニングを
手軽にしたかった(たまたまProvisionerコンテナがあった)
物忘れがひどい人間なので、補佐するツールが欲しかった
必要に迫られて実装したものが多い
構成管理
IPS(侵入防御装置) セキュリティ技術に疎く、とにかく把握してない脅威
から身を守りたかった。
ログ分析をし、行き交う情報をある程度把握したかった
ログ分析基盤

View Slide

主な構成要素・構成動機
Contents
Delivery
Network
運用・監視
仕事上、知らないのはまずいと直感した
実際何が拾えるのか、クラウドとどう連携すればよいかを
知りたかった
ZABBIXがどうしても使いこなせなかったので違うツールを求めた
Looks&Feelが某J○1という製品にクリソツで、ある程度使えれば
仕事上でも役に立つだろうと考えた
仕事上、必要性を感じて構成したケースも有るが、
Mastodonあってこそ得た技術も非常に多い
Webインフラ元々Webインフラ系の知見が浅く、危機感を抱いていた
DBも某神託製品でトラウマを持ってから苦手としていた
Mastodonを通じて、少しずつ理解を深めていった
Mastodonの知り合いを通じてOSC福岡の存在を知る
⇒そこでLagopus SwitchとRyuを知る
⇒Ryuのコードを見ながら「Python触りたいなーとか思う」
⇒Pythonのインフラ方面の触り方をJANOGで学び、NAPALMとANSIBLEを本格的
に触りだす⇒Mastodonを手がかりに技術の幅が広がった事例

View Slide

Mastodonのコンテナ化(?)
～k8sに取り込んでリソース集約度向上～
kubernetes：コンテナオーケストレータの一つで、Googleが開発。

View Slide

非Docker->Docker？というよりk8s
1master+4worker
Masterイメージ配置
Reverse Proxy 専任
他のURLも合わせて処理
集約・高可用性
リソース消費が少ないリカバリーがラク可用性が高い
• 動かしてみたら実際軽かった
• 思った以上に多くのコンテナ
が動いた
• 一度Dockerfile作ってコンテ
ナを作り、それをリポジトリ
に置けば、復旧はものすごく
簡単
• Kubernetesのオートヒーリング
• 負荷分散機能との連携が大前提
Kubernetesを活用すると、コンテナって面白そう！

View Slide

Docker-composeファイルから構成を読み取り
Web Sidekiq Streaming
DB Redis
3000/tcp 4000/tcp
External-network
Internal-network
./public/packs
./public/system
./public/aseets
./postgres
./redis
/data
/var/lib/postgresql/data
/mastodon/public/packs
/mastodon/public/system
永続ボリューム
（ホスト内)

View Slide

Mastodonインスタンスネットワーク設計
Web
Sidekiq
default
Streaming DB Redis
3000/tcp 4000/tcp
Container Network
(10.240.0.0/16)
Sidekiq
other
Mail/Push/Pull
x2
x2
x2 x2 Replication pair
Redis
SENTINEL
Master/Slave Redis Controll
ext_puma
ext_
streaming
ext_
postgres
ext_
Redis
ext_
SENTINEL
Cluster Network
(10.96.0.0/12)
31300/tcp 31400/tcp
5432/tcp 6379/tcp 26379/tcp
Master Worker
Worker
Worker Worker
31300/tcp
31400/tcp
31300/tcp
31400/tcp
31300/tcp
31400/tcp
31300/tcp
31400/tcp
31300/tcp
31400/tcp
Server Network
(192.168.100.0/24) Nginx

View Slide

Mastodonコアとバックエンドの通信設計
Web
Sidekiq
default
Streaming
Sidekiq
other
ext_
postgres
DB
Redis
ext_
Redis
Kube-dns
名前解決はkube-dnsを使用する
対象サービスは***.bluecore-net.svc.cluster.localにて定義されている
各フロントエンドはkube-dnsへ名前解決を行い、実際の通信をサービスあ
てに対して行う。
サービスはポートフォワードを行い、実DBサーバ/Redisサーバへアクセス
を中継する。

View Slide

ストレージ設計
share_root
sns_ap
live
public
assets
packs
system
Nginx
nfs-mstdn-
front-assets
nfs-mstdn-
front-packs
nfs-mstdn-
front-system
pvc-nfs-mstdn-
front-assets
pvc-nfs-mstdn-
front-packs
pvc-nfs-mstdn-
front-system
ReplicationController
mstdn-puma
mstdn-sidekiq-
default
mstdn-sidekiq-other
mstdn-streaming
NFS Share Storage
/home/mastodon/live/public/assets
/home/mastodon/live/public/packs
/home/mastodon/live/public/system
/home/mastodon/live/public/packs
/home/mastodon/live/public/system
/home/mastodon
nginxのDocumentRoot
PersistentVolume
ReadWriteMany
PersistentVolumeClaim
ReadWriteMany
• ストレージは既存で使用しているNFS NAS上の領域をそのまま使用する
• k8sからのボリュームマウントはPersistent Volumeを使用する
• 各コンテナはdocker-compose記載にて定められたとおりのボリューム
をマウントする

View Slide

k8s化したメリット
 可搬性に優れる
 Private Repositry間の移動が超簡単
 docker pullした後に違うタグつけてdocker pushするだけでいい
 リソース集約率が上がる
 1コンテナ＝なんぼかのプロセスで、オーバーヘッドがほぼない
 1コンテナあたりに求められるリソースが少なくて済む
⇒きめ細かい分散⇒バランス向上
 スケールしやすい
 Sidekiq, Puma共に純粋に数を増やせば簡単にスケールする
 よりCPUを効率的に使用できる
ブログやPleromaと共に、Webインフラ集約化に寄与

View Slide

アクセス分析をやってみる
～ELK(Elasticsearch+Logstash+Kibana)と
Microsoft Azure CDN～

View Slide

構成
 外部からはAzureCDNで収集
 レポート機能を必要とするので、
Verizon Premiumプランを使用
 ブログも当該CDNを使っている
 内部からはElasticsearchで収集
 シングルノードで動作
 rsyslogを集積するログサーバの役割
 CDNはDNSと連携する
 外部権威DNSはRoute53を使用
 外部フォワーダはQuad9を使用
 内部権威DNSはWindows-DNS
 内部キャッシュDNSはpdns-recursor
Sophos UTM9
IPS/NAT
Mikrotik RB2011
Router
SNS-AP
RevProxy
Kube-master
Container
Kube-worker
Container
Kube-worker
Container
Kube-worker
Container
Kube-worker
Container
AzureCDN
(VERIZON Premium)
Interlink
Ganesa
Logsvr
Verizon Standard = 18円/GB
Verizon Premium = 23円/GB
⇒大して金額差がない
※西日本リージョン

View Slide

Verizon PremiumのAdvanced Report

View Slide

グラフ・ランキング
【ファイルタイプランキング】
【ブラウザランキング】

View Slide

Kibanaでログ確認を行う

View Slide

DR拠点への移転

View Slide

コンテナ環境(サイト冗長構成)
1master+4worker
6vCPU/8GB RAM
/120GB VHD
1master+2worker
2-4vCPU/4GB RAM
/80GB VHD
5.5TB
NFS Server
500GB
Distributed Storage
(80GB SSD+300GB HDD)x4node
4vCPU/8GB RAM
120GB VHD
4vCPU/6GB RAM
120GB VHD
4vCPU/6GB RAM
80GB VHD
Internet VPN
DRサイト(北九州)
本番サイト(福岡)
Azure
(東西日本)
引越！

View Slide

サーバスペックの比較
12Core
(Nehalem+Westmere)
158GB RAM
10TiB Storage
6Core
(Penryn+SandyBridge)
56GB RAM
1.5TiB Storage
これ、仕事だとゲロ吐くほど辛い要件です
でも、我が家だからこそ
「動けばええんじゃヨイヨイヨイヨイ」

View Slide

サイト移転(1)
1master+4worker
6vCPU/8GB RAM
/120GB VHD
1master+2worker
2-4vCPU/4GB RAM
/80GB VHD
5.5TB
NFS Server
500GB
Distributed Storage
4vCPU/8GB RAM
120GB VHD
4vCPU/6GB RAM
120GB VHD
4vCPU/6GB RAM
80GB VHD
Internet VPN
DRサイト
本番サイト
Azure
(建造中)
【手順3】
nginxの設定をscpにてコピー
構成データをすべてコピー
nginxの構成は必要に応じて修正
【手順1】
DBデータをExport
【手順2】
ExportされたDBデータ
はRepoサーバを通じて
NASへ保管

View Slide

サイト移転(2)
1master+4worker
6vCPU/8GB RAM
/120GB VHD
1master+2worker
2-4vCPU/4GB RAM
/80GB VHD
5.5TB
NFS Server
500GB
Distributed Storage
4vCPU/8GB RAM
120GB VHD
4vCPU/6GB RAM
120GB VHD
4vCPU/6GB RAM
80GB VHD
Internet VPN
DRサイト
本番サイト
Azure
(建造中)
【手順4】
リポジトリデータをDRサイトへ
転送
【手順5】
リポジトリデータと構成データ
(YAML)を用いて、コンテナを
DR環境上に再構築

View Slide

サイト移転(3)
1master+4worker
6vCPU/8GB RAM
/120GB VHD
1master+2worker
2-4vCPU/4GB RAM
/80GB VHD
5.5TB
NFS Server
500GB
Distributed Storage
4vCPU/8GB RAM
120GB VHD
4vCPU/6GB RAM
120GB VHD
4vCPU/6GB RAM
80GB VHD
Internet VPN
DRサイト
本番サイト
Azure
(建造中) 【手順6】
DBデータをインポート
【手順8】
.env.productionの
修正
【手順7】
Redisは再構築
【手順9】
AP系は最後に起
動
【手順10】
権威DNSレコードの修正

View Slide

結果
2018年10月13日、旧宅から機材搬出
その後もMastodonは無事生存中
時々過負荷でコンテナが落ちてるけどね
切替時は、5時間ほどサービスが
落っこちました・・・Orz

View Slide

課題
 自分がtootするとSidekiqが詰まる
 予定ジョブが一気に数百単位で増えてまぁびっくり
 キュー数を最大24まで増やしてみたが、焼け石に水
 リレー接続も一時的にDisableにしたが、コレまた焼け石に水（ジュッ）
 自分のtootが20分程度遅延する
 忘れた頃に反響が帰ってきてまじビビる（え、なになに？って感じ)
 五七五botの応答には感謝。(いつ頃受け取ってくれたのかが分かる）
 先行切り戻しをするに良い機会になった
 よく落っこちる
 だいたい1日に1回もしくは2日に1回ぐらいでコンテナがCrashBackoffしてサービスダ
ウンする。
 Calico/Blog/Pleromaが巻き添えを食ってサービス障害に
 Pleromaは逆にサクサク動いたので、コレはコレで良い発見。
性能不足に悩まされた

View Slide

現在
1master+4worker
6vCPU/8GB RAM
/120GB VHD
1master+2worker
2-4vCPU/4GB RAM
/80GB VHD
5.5TB
NFS Server
500GB
Distributed Storage
4vCPU/8GB RAM
120GB VHD
4vCPU/6GB RAM
120GB VHD
4vCPU/6GB RAM
80GB VHD
Internet VPN
DRサイト(北九州)
本番サイト(福岡)
Azure
(東西日本)
Mastodon
Pleroma/ブログ

View Slide

技術的興味はどこから？
何をやり込む原動力にするの？

View Slide

知るきっかけはどんなもの？
物理ストレージ以外のこともやってみません？
例えばコンテナとかKubernetesとか
上司：A課長(40代・男)
⇒上司のさりげない一言
⇒オブジェクトストレージ
障害ニュース
あれだけ可用性を意識した構成で、
なぜにあんな障害が起きるのだろう・・？
俺： (40代・オス)
S3QL
⇒仕事で知った製品の仕組みを
知りたい欲を代替品で
満たせないか？
Panzura、あれは面白いストレージだなぁ
あれを1mmでも体験できるいいものはないかな
俺： (40代・オス)
ふとした疑問、ふとした言葉から好奇心は生まれる
「やってみたいな」と思うならやってみるのが一番
今の時代、手段はいくらでもある

View Slide

経験上から考える心構え
好奇心⇒やってみる
楽しそうならやりこむ
やったことは
大抵「忘れる」
好奇心⇒行動の間には「知ったかぶりは嫌だな」という感情があった。
仕組みを知ってみて、コレはもっとはまれそうだと思ったらやりこんでみる
仕組みをある程度理解したときの達成感は半端ない
どんなことでも人は時が経てば忘れる
そして、良い思い出だけが残る
「忘れたくなければ実行証跡を、手順を残そう」
形に残したものは
後の財産になる
経験の積み重ねをより確実なものにすることができる
塵も積もれば山となる
表面の技術よりも、習得技術の共通項を押さえておくと後々つぶしが利く

View Slide

今後
 開発を少しかじりたい
 まずはPython。
 フレームワーク(Django)やIDE(spider)を扱えるようになりたい。
 マークアップ言語への理解
 JSONの扱いと全文検索との連携への理解
 ElasticsearchあるいはX-Packに対する理解の追求
 クラウドというものへの理解

View Slide

ご静聴、ありがとうございました。
<(_ _)>
ﾄﾞｰﾓｱｼﾞｬｯｼﾀｰ

View Slide

Mastodon Meetup at Tokyo 2018 @ Internet Initiative Japan Inc.

Mastodon Meetup at Tokyo 2018 @ Internet Initiative Japan Inc.

localYouser

More Decks by localYouser

Other Decks in Technology

Featured

Transcript