アドベントカレンダー

この記事はMastodonアドベントカレンダーの12/9(日)に割り当てられた記事です。他にもいろんな記事がリリースされていますので、どーぞご覧いただければと思います。

私の中のMastodonの位置づけ

過日、11/3(土)に飯田橋グラン・ブルーム((株)インターネットイニシアティブ：本社)にてMastodon meetupが開催され、そこで私自身も登壇発表を行いました。本当に機会とそれを聞いてくださった方、感想をアウトプットしてくださった方々、本当にありがとうございました。

それを通じて、色んな人のいろんな考え方が発信され、それを私自身も受け止める中で、「そもそも私にとってMastodonってどういう位置づけなんだろう？」というのを振り返ったりしていました。

私の中の「Mastodon」の位置付け、それはやっぱり「重要」ではあるけれども、「一つのきっかけ」ということなのかなぁと感じました。

要は、連合が面白い

私がなぜMastodonを辞めることなく続けられてるのかって、それは

• 連合があるから、廃れない
• 自分でシステムを組み立てられ、それが活性したシステムとして長らく生きる

からであり、かつ、最初に知った類似システムの中で「Mastodonが最初に知ったシステムであったから」に過ぎません。要は、知った順がMastodonよりも前に「GNU Social」だったり「Pleroma」だったり「Misskey」であれば、恐らくそれが長らく使われることになったであろうシステムだったんじゃないかなーと思うのです。

Mastodonがそれなりに名が売れ、それゆえ、私自身知ることになった、その時たまたま検証ネタが枯渇して、少し視野を広げたいと思っていた、色々なことが重なって、たまたまこれが打ち込むネタになった、そのことはすごく大きいと感じています。

あくまで打ち込んだのはインフラ技術

自分自身はやっぱりインフラ構築がメインのお仕事してますので、そちら側に興味が行きまして、覚えたものってサーバ・ストレージ・ネットワークネタが圧倒的に多いです。

そうだなぁ、例えるなら、恐らく大半の方はMastodonそのものあるいは、ある一定の拡張を視野に入れてサーバ運営をしていると思います。私はどちらかというと、おのれの知る技術をこのソフトウェア・システムに適用するにはどうしたらいいか？という観点で拡張をしています。

インフラ技術って

どうやらインフラの世界って、一括りに「ネットワーク」って扱いを受けることが多そうなのですが、意外とインフラ分野の技術も奥が深くて、大きく分けて「サーバ」「ストレージ」「ネットワーク」「セキュリティ」「データベース」「ミドルウェア」・・・・・・って感じに分かれます。
さらにそこから、多岐にわたって分野が分かれており、学んでも学んでも学び足りない何とも言えぬ未知の世界だったりします。インフラエンジニアがどう見えているのか、私にはよくわからないのですが、それなりに学ぶことが多くて結構大変・・・・と言う気持ちで私も職務にあたってます。

• サーバ：ハードウェア(構成/ファームウェア)・OSプラットフォーム(OS/ドライバ)・仮想化技術
• ストレージ：ストレージアプライアンス・ストレージネットワーク・ストレージパラメタチューニング(サーバ側・ストレージ側)
• ネットワーク：LAN/WAN/バックボーンという範囲面絡みた技術もあれば、OSIモデルに基づくレイヤーごとの技術というのもある
• セキュリティ：WAF(Web Application Firewall)・セキュリティ技術情報収集/分析・
• データベース：データベース物理設計・パラメタチューニング・運用ジョブ設計等
• ミドルウェア：バックアップ・運用管理・認証・ファイルサーバ等など、基盤技術に関わるソフトウェア群の設計・構築など
• 運用：運用設計・運用ツールの設計/構築
• ファシリティ：ラック・設備・配線・設置技術・・・
• その他もろもろ

結局取り組んだ技術はインフラ技術だった

やっぱり仕事上で専門分野外のところも押さえなきゃと考え、取り組んだのは、それでもインフラ技術の世界でした。このMastodonインスタンスをエンタープライズチックに組むとどういう風になるだろうか？と言う感じで組んでいます。

それ故興味を持った領域に対して、Mastodonインスタンスを適用させていくと言う形で色々組んでいった次第です。気づけば構成が以下のようになっていたのはMastodon Meetupの壇上でお話差し上げたとおりです。

よって、「こんな複雑にしてどーすんの？」っておっしゃる人もいるのでしょうが(ってーか実際にいらっしゃいましたし）、ぶっちゃけMastdonそれ自体もコア部分なので非常に重要な位置づけにあることは確かですが、あくまでそこはベース部分であり、恐らくは発展させるベクトルが、それに向ける視野が少し違うんだと思います。

発展のさせ方は多種多様でいいじゃない？

Mastodonの発展のさせ方、啓発のさせ方には、メジャーな方法として大きく2通りあるのかなーと思ってます。

• コミュニティとしてのMastodon
• アプリケーションとしてのMastodon

私は、そこからは外れた、少し変わった使い方をしてるだけ・・ということなんだろうと思ってます。生きたシステムに、こんな仕組みを組み込んだらどうだろう？？どういう挙動をするんだろう？
いろいろな意味で実験台みたいなもんです。

でも、一つの新しい観点として、私のような使い方があってもいいんじゃない？その発展させた姿を誇るぐらいいいじゃない？と思うんです。

最ものめり込んで、闘ったのはストレージ

さて、Mastodonというコアに、色々なインフラ技術をお試しで突っ込んでは拡張させていった当インスタンスですが、その中でも一番ハマった技術はストレージでした。今回、当インスタンスで実装しているCephと言うソフトウェアについて述べようかなと思います。

Cephと言うソフトウェア

Cephとは、オープンソースソフトウェアで、いわゆる分散ストレージを構成するためのソフトウェアです。分散ストレージというのは、サーバ単位でバラバラに配置されているストレージを一つあるいは少数に束ね、可用性を確保すると共に負荷分散を行い、安全性＋可用性＋高性能を実現するストレージの一形態です。
その中でも、このCephは比較的安定度が高く、エンタープライズ方面でも使用されるケースが有ると聞きます。

実際、富士通なんかはこのCephをベースにした分散ストレージシステムを売り出していたりします。

Fujitsu ETERNUS CD10000 S2
 http://www.fujitsu.com/jp/products/computing/storage/eternus-cd/

インタフェースも豊富で、CIFS/NFSやBlockデバイス、オブジェクトストレージとしても動いてくれるというすぐれものです。

というか、実はベースとして動いてる部分はオブジェクトストレージであり、オブジェクトストレージをファイルストレージであったり、ブロックストレージであったりに見せたりする製品というのが実際です。

下図は例として、オブジェクトがどう定義されているかを見せるかを簡単に図示したものです。そして、可用性を担保する機能はRAIDとは異なる技術を使用しています。

分散ストレージ自体、基本的にはRAIDとは異なる思想で構成されていることが多いです。

我が家の構成

我が家の構成において、Mastodon、他Webサービスをコンテナ化している先のデータ領域はこのCephで構成した分散ストレージを使っています。具体的な構成は以下のとおりです。

紆余曲折はあったんですが、4台あるCephノードにまず1台のVMからRBD(Block)デバイスとしてマウントを行い、そこでNFS公開すると言う形でKubernetesや統合リバースプロキシからアクセスできるようにしています。

OSDと呼ばれる領域が、いわゆる各ノードに配置されたディスク領域で、これを増やしたり、ノードを増やしたりすることで領域の拡張を行うことが可能になります。

ネットワークは2系統あり、サービスとして提供するネットワークと、インターコネクトと呼ばれるノード間通信に限定したネットワークがあり、例えば障害復旧時のデータ復元処理などは裏側のインターコネクトを使用して行われます。

以下のグラフは、障害回復処理時のインターコネクト間の使用帯域(各ESXiホスト)です。結構な帯域消費が発生していることがわかるかと思います。(単位が異なるのはESXiのバージョンが微妙に違うからっすね・・・1号機は6.0U2、2号機は6.0U3です。)

これらのネットワークは、実は現在10GbEで構成しています。1GbE構成時もLACPを構成し、極力広帯域で通信できるよう構成していたのですが、恐らくは復旧処理においてのオブジェクトのやり取りに関して、かなりショートパケットでやり取りしてるのではないかと推察しています。

パケット処理性能も10GbEではかなり上がるんで、その要因もあるとは思うんですが、それ以上に、接続していたL2スイッチが性能的に厳しかったんじゃないかと予想しています。

SSDを使用したWriteback Cache

Cephにはいろいろな機能があるんですが、特にパフォーマンスの面で効果が顕著に出た機能が、SSDによる2次キャッシュ機能です。

Cephはパフォーマンスの面で少々残念なポイントが有り、それは「ストレージの保全を目的として、同期方式がSynchronusであること」なのです。

どういうことか？と言いますと、可用性を担保しなければならないので、書き込まれたデータは一旦他のOSDと呼ばれるストレージ単位に複製されます。この複製処理が完全に終了しないと、クライアントに応答を返しません。(例えば一般的なストレージアレイ製品とかでは、データ分散処理や実際の書き込み処理が完結する前に応答を返すよう作られてることが多いです(これをAsynchronus/非同期と呼びます））

そのため、HDDだけで構成した領域へのアクセスは少し動きがもっさりします。あまりに多くのIO要求が殺到すると、このコピー処理が追いつかなくなり、IO遅延につながったりします。
IO遅延が発生すると、同期Writeなストレージなので、クライアントは書き込んだあとの応答を待たねばなりません。それがTimeoutになると、当然その書き込みはエラーとなってしまいます。それではぶっちゃけ、実稼働させるには、お話になりません。

そこで、Cache Tierが役に立ちます。
Cache Tierに構成されたSSDはまずClientからのIO要求を前面で受付け、一旦そこにデータをストアします。その後、直近でRead要求あればそこから出し、当面使われなさそうなデータは、一定間隔でStorage Tierへ転送します。
つまりは、疑似的な非同期書き込みを実現するわけでして。
Cache Tierにないデータは適宜Storage Tierから取り出し、これにより何が嬉しいかと言うと、

• Cache Hit率が高ければ、SSDの性能がそのまま活かせる
• そうでなくてもデータの一次書き込みはSSDが受け付ける形になるので、HDDとやり取りするよりは高速にできる。
• Storage Tierは直接Clientとやり取りするのではなく、基本的にCache Tierとやり取りすることになる。ランダムRead/Writeの苦手なStorage Tierはシーケンシャル転送に近い形でデータがやり取りされるので、より限界に近い性能を発揮できる
• 結果的に、それぞれの得意とするアクセス特性でデータのやり取りができるため、性能効率が向上する

ということで、特にCephを構成した直後はHDDだけで組んでいたので、これを組み込んだら結構IO遅延が減りました。

問題がないわけでもない

そんな風にインフラをコツコツ拡張している私ですが、問題が発生してないわけでもないです。実際、トラブルの大半はこのストレージが原因で起きています。しかも障害の内容が「データのロスト」ですから、まぁこれが本当に実案件とかじゃなくてよかったよね・・・・って気持ちになったりもします。

一番の理由は「このCephと言うソフトウェアに対する理解がまったくもって足りない」ことです。

Cephを自宅環境なり個人なりで扱ってる人って意外と少なく、ましてやエンタープライズ方面で活用してるところもだいぶ限られています。それ故、国内の情報があまり豊富でない。

加えて、英語の情報も意外と公式ドキュメントだけでは痒いところに手が届かない内容で、英語圏のコミュニティサイトや、下手すれば中国語圏のコミュニティサイトを見て回らないと仕様がわからないということもありました。

今でも実は、時々オブジェクト配置マップ(Crushmapと呼ぶ)が崩れ、使用可能容量が突如激減し、トラブルに成ることがちょいちょいあります。一つ一つ調べてみたり、回復Tipsを組み立てたりしながら、壊れちゃ直しを繰り返しつつ運用を続けて遊んでいます。

こうしたところに果敢に挑みつつ、そしてトラブルが起きてもある程度復旧を模索する、そういうところは自宅環境だからこそ、実質ほぼおひとりさまだからこそできることなのかなーと感じています。

一応調べた限りで情報はまとめていて、こんな形にしてます。

分散ストレージの要注意ポイント

ずばり、オートヒーリング機能です。障害が発生したときに、データを自己修復する機能を指しますが、これは別にCephに限った機能ではなく、コンテナオーケストレータの一つであるKubernetesでも使われる機能です。

例えばメンテナンスの為にすべてのノードを停止する、そして起動する、これだけで実はノードの停止タイミングのズレなどにより、一時的にデータが崩れます。これは立派な障害であり、当然ソフトウェアは修復処理を行って、状態回復を図ろうとします。

この時、ノードやインターコネクトに対して莫大な処理が走り、システム全体として過負荷に陥ることがあります。それが故にクラスタ全体のパフォーマンスが大幅に低下したり、下手すれば停止することだってあります。

こうした時重要なのは「障害時の処理を想定してサイジングすること」と「メンテナンス時はデータの移動や修復処理を抑制する設定を実施すること」です。このあたりの対応が雑だったりすると、不測の事態が発生した時、思いがけぬ二次障害・三次障害に発展することも十分考えられます。

「分散している」＝「構成パーツが増える」＝「障害ポイントが増える」

と言う考え方も、ある程度必要なんじゃないかなーと、個人的には感じています。

これからも

今回、Mastodonを動かしていく中で身につけた技術の一つとして、分散ストレージを紹介しました。これまで、技術習得のトリガーは基本的に仕事絡みであることが多かったのですが、Mastodonのように、完全に個人趣味の世界からここまで好奇心をひろげ、システム拡張しまくったケースは初めてなんじゃないかなぁ・・？と思います。

これからも、この面白いアプリケーションを通じて、さらなる技術的開拓を続けていきたいと思います。できれば、爺になっても続けていきたいかなぁ・・？と。私の好奇心がどこまで続くのか？というところもあるのですけどね。

長文読んでいただき、ありがとうございました。