Mastodon Meetup at Tokyo 2018 @ Internet Initiative Japan Inc.

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

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

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

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

Mastodonを知るきっかけ

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

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

うちのインスタンス紹介

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

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

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

当インスタンスの沿革  第一次構成(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 加えたりしながら徐々に進化中

第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

第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

第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

第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#2: 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) Worker#3: 8vCPU/6GB RAM/120GB VHD 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

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

主な構成要素・構成動機 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を手がかりに技術の幅が広がった事例

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

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

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 永続ボリューム（ホスト内)

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

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サーバへアクセスを中継する。

ストレージ設計 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 ReplicationController mstdn-sidekiq- default ReplicationController mstdn-sidekiq-other ReplicationController 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記載にて定められたとおりのボリュームをマウントする

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

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

構成  外部からは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 ⇒大して金額差がない ※西日本リージョン

Verizon PremiumのAdvanced Report

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

Kibanaでログ確認を行う

DR拠点への移転

コンテナ環境(サイト冗長構成) 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 (東西日本) 引越！

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

サイト移転(1) 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 (建造中) 【手順3】 nginxの設定をscpにてコピー構成データをすべてコピー nginxの構成は必要に応じて修正【手順1】 DBデータをExport 【手順2】 ExportされたDBデータはRepoサーバを通じて NASへ保管

サイト移転(2) 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 (建造中) 【手順4】リポジトリデータをDRサイトへ転送【手順5】リポジトリデータと構成データ (YAML)を用いて、コンテナを DR環境上に再構築

サイト移転(3) 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 (建造中) 【手順6】 DBデータをインポート【手順8】 .env.productionの修正【手順7】 Redisは再構築【手順9】 AP系は最後に起動【手順10】権威DNSレコードの修正

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

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

現在 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 (東西日本) Mastodon Pleroma/ブログ

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

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

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

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

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

Mastodon Meetup at Tokyo 2018 @ Internet Initiative Japan Inc.

Mastodon Meetup at Tokyo 2018 @ Internet Initiative Japan Inc.

More Decks by YuYu

Other Decks in Technology

Featured

Transcript