木曜日TweetContents久しぶりに書きました。blog読者プレゼントキャンペーンTwitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント!応募期間は2019/11/29~2019/12/31まで。詳細はこちらをご覧ください。久しぶりに書きました。九州支社で働くとみです。実は2016年に一つ記事を投稿したのですが、実に3年半経過した今になってアドベントカレンダーの話が聞こえてきたので、久方ぶりに書いてみることにしました。当時はこんな記事なんかを書いてたわけですが、この記事を書いてから3年間色々あったので、その中の一つを書いてみようかなと思います。ON-PREMISEと言われてもおかしくないような、どインフラなエンジニアをやっていました・・・。仕事でももちろん検証環境があり、それを活用して勉強しますが、個人責任でやったほうが楽なものなどに関しては、自宅に型落ちのエンタープライズ機器を配して実際に構築してみるなど色々やってきています。(下図はそんな自宅に設置しているサーバ機器)クラウドはどちらかというと「よくわかんなーい」という状態で、そもそも興味を抱くことがありませんでした。このインフラの仕事を始めて当時でも13年続けており、当時の年齢としても「アラフォー」&「厄年」が近づいてきてるような年齢です(今はもう40突破済み)んで、技術的に飽和するのかなーと思ってました。(当時はバックエンドなインフラばかり扱っていて、OSプラットフォームやハードウェア、ストレージを中心に触ってました)やっぱり技術者として歩むには少し限界が見えてきたのかなー、今後はマネジメントかぁーとか漠然と考えていたりもしました。それから今日まで、まぁ色々ありました。とあるきっかけがあり、こんな技術を覚えだしました。意外と人間ってやればできるもんだ。WeaveNet)CDNやリバースプロキシ、証明書の取り扱いなどこうした経験が意外にも現在流行りのパブリッククラウドを理解していく一つの助けになっていて、クラウドへシフトすることに悲観をするでもなく、かなり広範囲に技術習得をしながらお仕事にも趣味にも対応することができていて結構楽しいです。今後も技術者であろうという心を持ち続ける契機にもなりました。その技術視野を広げるのに良いきっかけになったのが今回お話しする『分散SNS』という奴です。)」というキーワードのほうが分かりやすいのかもしれないですね。分散SNSを実現するソフトウェアの中で最も名の知れたものがそれです。Pubというプロトコルを使用した複数のSNSサーバで構成されている、連合的なコミュニティが該当します。(最近こうした全体像に対して「Fediverse」という言葉が使われていることを知りました。ActivityPub以外にも連合形成できるプロトコルは幾つかあるようです。ニコフレといった巨大なSNSサーバが日本にあり、そこにTwitterから抜けた人が殺到して盛り上がっていたのですが、今はそうした巨大なSNSサーバよりも、連合コミュニティの特性を生かした多数の中小規模SNSサーバ間でリモートフォローを利用したコミュニケーションをとるほうがだいぶ主体的になってるような気がします(特に技術者系のコミュニケーションを見てると)ActivityPubActivityPubはW3C勧告も行われているソーシャルネットワーキングサービスにおける、SNS間のデータ送受信における共通規約です。APIを用いてやり取りすることにより、異なるSNSサーバソフトウェア間の情報交換を可能にしたものです。下図は例としてユーザがクライアントから何かつぶやいたときの動作を簡単に図示したものです。データフォーマットはチュートリアルから読み取った限りではこんな感じで実装されてました。各データで定義するTypeの値によってさまざまなアクションをとることが可能になっていますし、TO/CCの設定を変えることで、その発言の公開範囲を変更することが可能になっているようです。これを主だったソフトウェアではWebsocketを使用したStreaming機能で行っており、それゆえ昔Twitterも行っていたような「リアルタイムなタイムライン配信」を可能にしています。データフォーマットおよび処理単位となるオブジェクトに対する規約であるため、実装方式は各ソフトウェアでまちまちですし、オブジェクトに対する扱いもActivityPubで定めた規約さえ守ればカスタマイズされた状態で実装されていることもあるのかなと思います。様々なソフトウェア当然Mastodon以外にもそうしたプロトコルを利用したSNSサーバソフトウェアがあり、他にはこんなのがあります。(当然掲載しているもの以外にも沢山あるよ。APIのことを指すのかなと思う)で実装、サーバ間の連合アクセスにActivityPubを使用しているケースが多いように見受けられます。)最古参の分散SNSソフトウェアであり、Ostatusというプロトコルを用いて他のSNSサーバと連携をする仕組みだった(Mastodonも初期バージョンは同様だった)が、2018年にActivityPubに切り替え、現在も他のSNSサーバと連携することが可能になっている。PHPベースで作成されている。)Elixirというプログラミング言語で書かれた分散SNSソフトウェア。非常に軽量でリソース消費が少ないのがウリらしい。Mastodonとの互換性が結構高く、Mastodon向けに作られたアプリケーションが動く点は便利だと思う。)Node.jsベースで組まれた国産の分散SNSソフトウェア。ActivityPubによって他のSNSサーバと連携する。私が現在使っているのはこれ。Webインタフェースの機能が多彩で、見た目的なところは一番扱いやすいような気がする。ゲーム機能も搭載されている。)ある意味番外編ですが、WordpressをActivityPubに対応させて、記事のフォローをしたりできる機能があります。私はこれが大盛り上がりしていた2017年4月頃にたまたまこの存在を知り、5月頃にMastodonを組み入れたサーバを立ち上げて遊ぶようになりました。当初は単なるユーザとして入ったということもあり、「こんなんすぐ飽きられるやろ」と思ったりしたんですが、「リモートフォロー」という仕組みと「連合タイムライン」というものに惹かれ、自分でサーバを立ててみることにしました。分散SNSは先に述べたような「連合」の機能を活用して、私のSNSサーバが独りぼっちでも、「リモートフォロー」という機能を使用することで、他のSNSサーバ上のユーザをフォローすることができ、ブースト/リノート(Twitterで言うリツイート)ができ、もちろんFavoriteもつけることができます。サーバを立てることで、実に多くのサーバと連携して、それなりに多くのトラフィックをサーバに呼び込み、どこに負荷がかかってるのか、どういうプロトコルでどういうメッセージが飛び交うのか、サーバ構成において効率を高める方法はないか?といった多くの学びポイントを見つけることができたかなと思います。それこそが、私が未だに分散SNSサーバを継続させている理由です。当時のSNSサーバは私のオペミスで消失してしまったんですが、その後Misskeyという別のActivityPubを使用するソフトウェアを利用して再建しています。分散SNSで学んだことMastodonのアーキテクチャを節穴な私の視点で書くとこんな感じです。(2018年頃の知識で止まってますので最新はもう少し違うんだろうか)ユーザはリバースプロキシを経由して原則ウェブフロントエンドへアクセスします。そこで書き込まれた文はデータベースへ蓄えられるとともにジョブスケジューラの管理下に置かれます。Redis上のキャッシュに送り込まれます。それがStreamingサーバにてWebSocketを通じて連携するサーバへ順次配信され、結果としてリアルタイムでそのSNSで発言する内容がタイムラインに反映されていくという動きをしているようです。やり取りされる際に使われるプロトコルが先ほど述べましたActivityPubというもので、実際ログを覗いてみると、JSONフォーマットで書かれたメッセージが飛び交っていました。Pubが導入されてからは、サーバを過去時点に復旧してもすぐ疎通が図れる(Ostatusの頃はトークン期限が終了するまで、連合組んでたインスタンスと疎通できなかった)というところでした。分散SNSを通じて得た視野というのは非常に広範囲で深く、ある意味人生史上最強の衝撃を与えたに近いものがあったのですが、特にこのソフトウェアをきっかけに一気に視野を広げたのはほかでもないコンテナでした。コンテナとネットワークこのソフトウェアはDockerでの運用も想定しているため、さっと環境が組めるようにDocker-compose用のYAMLファイルも配置されています。コンテナとして何が必要か、どこにデータを配置するかといった設定も見ることができ、構成の大まかな内容をおさえることができました。(下図は2018年4月頃にGithub上のMastodonにあったDocker-composeファイルを読んだ結果です。検索機能であるElasticsearchは含んでません)また、アプリケーション部分は水平分散が非常に容易であり、Sidekiqなどは役割単位で起動させることができますし、数を増やせば自動的に自身のSNSサーバ配下に加えて性能強化が行えます。下図のようにコンテナをばらすことで、アプリケーションのコンテナ(青枠)は簡単にスケールアウトできます。職場の上長から「こんなのがあるらしい」と名前だけ聞いていて気になって触り始めていたのがKubernetesでした。Kubernetes(k8s)は最近色々なところで知られるようになってきたんじゃないかと思うのですが、コンテナホストを複数台並べてクラスタを構成し、管理することのできるコンテナオーケストレータの一種です。それまで単一VMで構成していたサーバをオーケストレーターの中に放り込むことで容易に状況に合わせてリソース使用量を調整できるなーなどと考えまして、このアプリケーションをKubernetesに放り込んでみたのが2018年5月頃です。2017年5月に建てた時点では単一サーバにすべての機能を詰め込んだオールインワンパッケージでしたが、最終的に2018年11月頃の最大構成としては以下の通りとなっています。オブジェクトストレージを利用している人も多く、自宅で出来るオブジェクトストレージとしてオープンソースが公開されているCephも、この時試しに実装して仕様の把握をしたり、オブジェクトストレージというのがどんなところに注意が必要なのか・・・を学んだりしました。Calicoに触れました。略称であり、Kubernetesに限らずコンテナホスト間でコンテナネットワークを形成するためのインタフェース及びネットワーク構造を指します。CNIってどの製品も特色があって、「これぞSDN」という一つの形を見せているようなものが多いです。Calico」はほぼL3に依存して通信を行い、その経路制御をBGPだけでやってるという面白い仕組みになっています。BGPというと「なんだかネットワーク屋さんが取り扱う途方もないものだなー」位だったのが、今はもうクラウドに対する閉域網を構成する際に欠かせないプロトコルになってきていることからも、実はクラウド関連のSIを行うにあたり必要な技術要素になっており、コンテナに興味を抱いたというのは本当に偶然だったけど大きいことだなーと感じています。ここからSDNって面白そう・・って印象を受けてLagopus触る->Pythonおもしろそう->Ansibleもっとおもしろそう->・・・という方向に興味を持って行ったというのもこの時期だったりします。Azureを中心としたパブリッククラウドの理解でした。CodeなりEclipseなり入れてみましたが、十数年前で時が止まってる私には衝撃だった)というところかなぁ。WebAppだとデプロイメントスロットはリンククローン的なイメージでコンテナを作るから、切り替えが楽(スロットのスワップとか)スケール操作もPortal経由で数値決めてボタンポチーで簡単に調整できるアプリケーションデプロイは色々方式があるけれど、Gitも使えるしVisualStudioの配信機能もあるし、バージョン管理含めてだいぶ楽に運営できそうな気がするステートレスなサービスであれば簡単にサーバをスケール出来るのも多いかなと思いますし、それをほぼ意識せずに済む。そりゃこれが望まれるわけだ・・と感じました。PaaSそれ単独で何も対策せずに動かすと結構セキュリティリスクが大きいということも分かりました。すべてがパブリックIPで動作するから。なにも設定してなければ世界に向かって作って生まれたその日からフル公開です。それが許される業界もあるのだとは思うのですが、許されぬ業界もあり、そうしたところはやっぱり意識付けが必要なのかなと感じました。PaaSのように抽象化されたところでもインフラの技術なりがある程度わかることは必要であり、重要なんだなということを知ることもできました。これからも技術を追いかけられる人でありたい私はいつか年齢を重ねるうちに技術を手放さなければならなくなるのではないだろうか?と、当社に入る前までは思ってました。うわさで聞いたSNSをのぞき込んで知りもしないWebアプリケーションの世界に首を突っ込み実際に自分で組んでみてこりゃ面白いと感じリソース利用方法に疑問をもってコンテナに手を出しコンテナの話題から雑談でKubernetesを知り自身のSNSシステムをKubernetesに組み込みKubernetesの技術要素であるCNIの技術からBGPの使い方を覚えとどめにパブリッククラウドの扱い方を学び、それで飯食ってるとは当時の自分だと絶対思わないんじゃないかな。それこそ点と点が線でつながる瞬間を垣間見たような気がします。して色んな初挑戦系のものに取り組み続けた結果、意外にもまだ技術畑でゴリゴリと機能検証を進めたり、知らなかった技術知見の収集は継続出来ていて。意外と続けられるものなんだなーと感じています。仕事に結びつかないところではあるけど、いろいろ開発関連のわずかな知識ではあるけれど、これを生かして開発ベンダーの方とコミュニケーションをとる際、少しは開発者側の目線に近づいてコミュニケーションが取れるようにはなりました。いろんな方面に連携をとれるというのは中々にありがたいスキルなんだなぁ・・・と感じています。いつ、どこに、どんなきっかけが埋まってるかわからない。いくつかの記事を参考に記載させていただきました。知識習得の際に参照したサイトを以下の通り掲載します。地方拠点の一つ、九州支社で細々と働いています。オンプレミス環境の仮想化インフラ・ストレージに関する提案・設計および構築業務を中心に対応しています。Office365/Azureにも手を出しました。2018年も、気が付けばあっという間に師走です。紹介記事、第三弾です。