発明のための再発明

Webプログラマーが、プログラムの内部動作を通してプログラムを作る時の参考になるような情報を書くブログ(サーバーサイドやDevOpsメイン)

CoreDNSにおけるプラグインチェーンの実装

はじめに

f:id:mrasu:20190217162512p:plain

CoreDNSはサービスディスカバリ機能を持ったDNSです。
CNCFでGraduatedになっているプロジェクトで、KubernetesのデフォルトDNSにもなっています。

この記事では、CoreDNSはプラグイン方式で拡張するようになっているので、その実装を見ていきます。
※ 実装はde2f63d78747b48ae458b8f2c327a01e44cf725cを基にしています。

プラグイン登録

CoreDNSのプラグインは動的にロードするのではなく、Caddyの仕組みを使ってビルド時に組み込まれます。
また、プラグインの実行順序もビルド時に決定されています。
プラグイン情報はzdirectives.goというファイルに定義されていて、zdirectives.goの作成がタスク化されています。
以下のステップを経ることで、プラグインがCoreDNSに組み込まれます。

plugin.cfgに定義

plugin.cfgにはビルドに使用するプラグインと、実行順序が定義されています。
plugin.cfgの内容は以下のようなものです。

metadata:metadata
tls:tls
reload:reload
...
on:github.com/mholt/caddy/onevent

左がプラグイン名で、右がパッケージ名です。
ここに書かれている順番で、プラグインが実行されます。

go generate を実行

go generateは以下のように動きます。

  1. go run directives_generate.goが呼ばれる
  2. zdirectives.goと関連ファイルを作成される

これによって、以下の内容がzdirectives.goに書き込まれます。

var Directives = []string{
    "metadata",
    "tls",
    "reload",
    ...
    "on",
}

このDirectivesが、プラグインの順序を定義しています。

go build を実行

go buildの実行時に、zdirectives.goが使用されます

プラグインチェーンの実行

次は、CoreDNSのプラグインは、実行時の振る舞いについて

開始時に初期化

CoreDNSの開始時に各プラグインを初期化して、zdirectives.goに書かれている順番でプラグインチェーンに登録します

プラグインチェーンの参照

リクエストが来たら、プラグインチェーンにある最初のプラグインが実行されます
server.goh.pluginChain.ServeDNSからプラグインチェーンが開始されます

最初のプラグインを実行

最初のプラグインが実行されます
プラグインはServeDNSというインターフェースを持つので、それが実行されます

後続プラグインの実行

次のプラグインが実行される
plugin#NextOrFailureを呼び出すことで次のプラグインが実行されるので、その関数の前後がプラグイン独自のコードを書く場所です。

まとめ

以上、CoreDNSが実装しているプラグインチェーンを紹介しました。

このブログでは、この記事のようにプログラムを作る時の参考になることを書き続けるつもりです。
もし興味があれば、twitterやブログのフォローしていただけると嬉しいです。

稼働システムのマイグレーションの痛みを和らげる技法

はじめに

サービスを長く継続すると避けられないのが「マイグレーション」です。
しかし、マイグレーションには多くの手間がかかる上に致命的なバグも出やすく、難しい作業です。
そんなマイグレーションを実践し、詳細を公開している企業があります。
それを参考にどのような工夫ができるのかを見ていきます。

紹介するのは以下の企業です。

各事例には元記事へのリンクを書いているので、興味があればリンク先も覗いてみてください。

食べログ: Railsからマイクロサービスへの移行

元スライド: 食べログのマイクロサービス化PJについて

まずは、食べログのマイクロサービス移行についてです。
移行に際しては、共有しているDBをいきなり物理的に分けるのではなく、はじめに論理的に分割する方法を取ったようです。

※ 2018年9月末時点で進行中なので、現在も進行していると思われます。

移行理由

既存のシステムでは、

  • メインのデータベースが一つ
  • modelやlibをアプリケーション間で共有している
  • デプロイは全アプリケーション同時に行う

というアーキテクチャをもっているため、共有されたデータ構造を変更する際に影響範囲が広く対応が大変だそうです。
そのため、マイクロサービスへと移行し始めたそうです。

移行方法

移行の手順をまとめると、

  • 始めからサービスを細かく分解することを諦める
  • まずは境界が明確な2つのサービス(下図)へと分割し、境界の横断にはAPIを使うように修正する
  • 全サービスがAPIを使用するようにできたら、DBを分割する(予定)

このように、DBの共有を止めたいけれど、ビッグバンリリースでは大変なので、まずは、ソースコードの修正によって論理的にDBを分割します。
その後に、物理的にDBを分けるという戦略です。

The Guardian: MongoDBからPostgreSQLへの移行

元記事: Bye bye Mongo, Hello Postgres

次は、イギリスの新聞社である「The Guardian」がMongoDBを捨てて、PostgreSQLへ移行した方法についてです。
旧コードを本格稼働させつつ新コードにも同内容を実行することで、新旧コードが同じ結果になることを確かめながら移行したようです。

移行理由

The Guardianには記事の管理に使用している内製CMSツールがあり、MongoDBとマネジメントツールであるOpsManagerを使用していたのですが、

  • AWS上に自分たちでMongoDBとOpsManagerを建てて、管理する必要がある (マネージドサービスが使えなかった)
  • 障害時にMongoDBもOpsManagerも助けにならなかった
  • OpsManagerを入れれば管理が楽になると思ったが、そうでもなかった
  • 価格が高い

という要因が合わさり、移行先を探し始めてPostgreSQLへ決めたそうです。
ちなみに、移行時にスキーマを作り直すことはせず、JSONB型の列を用意してMongoDBの内容をそのまま持っていったようです。

移行方法

移行は下の手順で行ったそうです。

  1. 新DB(PostgreSQL)への書き込みAPIを用意する
  2. 前段にプロキシを用意して、新旧両方のAPIに同一のリクエストが流れるようにする(プライマリは旧API)
  3. 新DBへデータを移行
  4. 新旧APIのレスポンスが同一であることをチェック (別の結果が返ってきたら、新DBのデータを巻き戻してやり直し)
  5. APIをプライマリにする
  6. 旧DB(MongoDB)を削除

f:id:mrasu:20190115011442p:plain

プロキシを用意して変更の有無を確認することで、ユーザーに影響を与えずに新APIのエラー検出が出来るようになっています。
また、APIはelasticsearchなどとも連携しているので、APIが間違ったデータを返してしまうと影響が大きかったことからも、慎重に確認したかったようです。

Dropbox: 複数RPCからgRPCへの統合

元記事: Courier: Dropbox migration to gRPC

最後は、Dropboxが行ったRPCの統合についてです。
かつてDropboxは自作プロトコルでのRPCや、ApacheThrift、http1.1でのRPCを使用していたのを、CourierというgRPCを使うための新フレームワークへ移行したそうです。

移行理由

旧RPCフレームワークに変わり、Courierという新フレームワークを作成することで以下のことを可能にしたそうです。

  • サーバー・クライアントを認証・認可するためのDropbox内部にある機構との統合
  • ログや統計などの情報の統合・可視化
  • タイムアウト・サーキットブレーカー設定の強制

移行方法

移行に際しては、旧フレームワークからの移行を開発者が簡単に出来るように注意しつつ、以下のステップを踏んだそうです。

  1. 旧RPCフレームワークのコードのフリーズ
  2. Courierと旧フレームワーク双方を使用できる共通インターフェースの作成
  3. 共通インターフェースを使用するようにコードを変更 (稼働させるのは旧RPC)
  4. 旧RPCサーバーとCourierサーバーを同時稼働
  5. クライアントをCourierへ切り替え
  6. 旧コードの削除

フレームワークへの機能追加を止めることで開発者たちへ移行のインセンティブを与えたことと、新旧フレームワークを同時に使えるようにして順次切り替えを行い「移行」に対するリスクを抑えたという、工夫が見れます。

まとめ

以上、各企業がマイグレーションをした方法とその理由を掲載している記事を紹介しました。

このブログでは、この記事のようにプログラムを作る時の参考になることを書き続けるつもりです。
もし興味があれば、twitterやブログのフォローしていただけると嬉しいです。

分散ストレージ Ceph - "Ceph: A Scalable, High-Performance Distributed File System"

はじめに

分散ストレージであるCephについての論文を読んだので紹介します。

最近CybozuのNecoプロジェクトが始まり、面白そうなことをやっているな、と思っていたたところ、Cephについてのブログが出ました。
これを読んで、「Ceph読んでみたいな」と思ったので、理解の足がかりになるかなと思い論文("Ceph: A Scalable, High-Performance Distributed File System")を読みました。

ただし、この論文は2006年に発表されたもので、当時のCephの概要について説明されたものです。
現在の実装とは大きく違うと思います。
たとえば、この論文では「CephはEBOFSという独自ファイルシステムを採用している」とあるのですが、GitHubにはそのようなものは存在せず、2009年ごろに "osd: do not use ebofs"というコミットとともに削除された形跡が伺えます。
それでも、分散ストレージは「自分で作ってみたいシステムランキング」の上位にあるものなので興味深く読みました。
また、論文に出てくる「CRUSH」と「RADOS」はデータの配置と冗長化という、分散ストレージに欠かせない仕組みで、Cybozuのブログを読む限り今も現役なようです。

Cephについて

Ceph自体の説明については、
Cybozuの記事にまとまっているので、そちらが参考になります。: https://blog.cybozu.io/entry/2018/12/13/103039
公式: https://ceph.com

ちなみに、CNCFのIncubating ProjectになっているRookもCeph連携をしています。

論文の概要

"Ceph: A Scalable, High-Performance Distributed File System"では、Cephにおける

  • メタデータの管理
  • データの管理
  • クライアントとサーバーの関係

という、おおよそCephの全体像を書いています。
簡単にまとめると、
Cephは

で構成されていて、クライアントはこの2つのクラスタに問い合わせることでファイル情報や内容をやり取りします。
MDSクラスタの大きな特徴は、「ファイルの位置情報」を保管せずに、計算によって対象ファイルを保持するOSDがわかるということです。
また、OSDクラスタは冗長、耐障害を考慮された設計です。

OSD(object storage devices)とは、ディスク(またはRAID)と、それに付随するCPU・ネットワーク・キャッシュを含むデバイスの呼び方です。長いですが、「ファイルコンテンツの一部を持ったデバイスOSDというだな」という理解で十分だと思います。

以下、詳細です。


System Overview

この章は、Ceph全体についての説明です。次章以降、各機能が説明されます。

メタデータの分離

Cephでは、open, renameなどのメタデータに対する操作はメタデータサーバー(MDS)で一括管理されていますが、read,writeのようなIO操作はクライアントとOSDが直接通信するようになっています。
また、データがどのOSDに格納されているかという情報はメタデータサーバーでは管理していません。その代わりに、CRUSHを使うことで場所が計算できるようになっています。

メタデータの動的管理・分散管理

メタデータに対する操作はCeph全体の負荷の半分にもなる可能性があるので、メタデータを効率的に管理したいところです。そのために、Dynamic Subtree Partitioningという手法を使用しています。

RADOS (Relaiable Automatic Distributed Object Storage)

Cephは数千を超えるデバイスを持つシステムなので、以下のことが想定されます

  • バイスが追加、削除される
  • 故障が頻繁に起こる
  • 大きなデータが追加・移動・削除される

なので、Cephはデータのmigration,replication,failure detection, failure recoveryの機能を持っています。(詳細は後述)

クライアント操作から見る Ceph

capability

クライアント操作時には、"capability"という操作許可が各クライアントに発行されます。
例えば次のようなcapabilityの移動があります。

read時:
クライアントがread用にopen操作をMDSに要求すると、MDSがreadのcapabilityを与える。
capbilityを与えられたら、クライアントはメタデータ情報を使って、OSDクラスタへアクセスして、データを取得する。

write時:
writeのためのopenの場合には、writeのcapabilityを与える。
その後にクライアントはデータを変更して、closeする。
close操作の時に、MDSはファイルサイズを更新して、capabilityを破棄する。

同期

POSIXでは、読み込み時には書き込み済みのデータを読み込むこと、書き込みはatomicであることを要求しています。つまり、操作は発生順(order of occurrence)に結果を持つことを要求しています。
しかしCephでは、「複数書き込む場合」や、「書き込みと読み込みが同時に発生した場合」には、キャッシュ読み込みとバッファ書き込みのcapabilityが取り消されて、各操作の同期が強制されます。
この方法は、同期IOになるので遅くなりますが、通常のユースケースでは読みと書きが同時に起きることは少ないので、許容できると判断しています。
ただし、許容出来ない場合に備えて一貫性を犠牲にする選択肢も有るようです。

名前空間に関する操作

名前空間に関する「読み(readdir, statなど)」、「書き(unlink,chmodなど)」の操作はMDSに対して行われますが、ロックはありません。これは、シンプルさと最適化を求めた結果だそうです。
例えば、ls -lのようなreaddir+statの操作はよく実行される操作ですが、巨大なディレクトリに対してはパフォーマンスキラーです。
なので、デフォルトではキャッシュが使われます。
そのせいで、一貫性が損なわれますが、パフォーマンスのためには歓迎される犠牲だとして採用しています。

動的に分散されるメタデータ

Cephのメタデータは分散されつつも動的に場所が変わり、以下の特性があります

  1. ディレクトリのコンテンツは同一のOSDクラスタにある
  2. MDSに配置されるデータはアクセス量に従って動的に変化する(どこかのMDSにアクセスが偏る場合は、一部のディレクトリを別のMDSに移動します)
  3. メタデータの一貫性のポリシーは、security(ownerやmode),file(size,mtime),immutable(inode number, ctime, layout)の3種類存在し、目的に適したものを使っている。
  4. 大量のアクセスが同一のディレクトリやファイルに来た場合には、レプリケーションを拡大して、クライアントにレプリケーションへアクセスするように指示する

Distributed Object Storage

クライアントやMDSにとって、OSDクラスタは論理的に一つのストレージであるとみなして扱います。
それを実現するために、以下の工夫をしています。

CRUSH (Controlled Replication Under Scalable Hashing)

ファイルはobjectに分解され、objectはPG(placement group)というグループに割り当てられます。PGはCRUSHを使用して、各OSDに割り当てられます。
CRUSHでは、PGとPGに紐づくOSDのリストがあればデータを持つOSDがわかるようになっています。
この仕組みのおかげで、クライアントやMDSは独立して保存場所を計算することができ、メタデータが持つ情報の更新が少なく済むようになっています。
つまり、CRUSHでは、distribution(どこにデータを置くべきか)とlocation(どこにデータが有るか)の問題を同時に解決しています。

レプリケーションとデータ保全

データは複数PGにレプリケーションされます。
クライアントがプライマリPGのOSDにデータを送ると、対象のOSDは受け取ったデータをレプリケーションにも流して、待機します。
そして、レプリケーションの書き込みが終わってから、クライアントに完了を知らせます。
こうすることで、複数デバイスへの書き込みが保証されます。

Failure detection

ディスク障害などはODSから障害を通知しますが、ネットワーク障害の場合には各OSDのピアが生存確認できなくなった時に、中央に報告が上げられます。
そして、中央がシステム障害なのか一時的なものなのかを判断します。
Cephにはdownとoutの2つの障害状態を用意していて、OSDが通信できなくなるとdownとなりprimaryから外されます。そのままdownの状態が続くようだと、outの状態に遷移してPGには別のOSDが割り当てられます。
このように状態をもつことによって、(停電でOSDの半分がダウンするなど)大規模な障害が起きた時に状態を"down"に留めることによって、大規模なデータの再配置を避けることができるようになっています。

OSDクラスタ情報の更新

Cephの持つクラスタ情報がOSDの追加や削除によって変更されると、各OSDは自身の情報との差異に気づき次第、OSDの「あるべき姿」へと変化します。(「あるべき姿」になるために、プライマリの変更やデータの移行などが発生します)
このように、各OSDは独立して変化するので、あるOSDが落ちた場合には、影響を受けた各PGは並行して復帰します。

EBOFS (Extent and B-tree based Object File System)

Cephでは、メタデータとデータのatomicな操作が出来なかったので、ext3(古い!)のような既存のファイルシステムは使わずにEBOFSというものを作ったそうです。
EBOFSは以下の特徴を持ったファイルシステムです。

  1. atomic transactionをサポートすると同時に、ディスクへの書き込みは非同期に行われる。
  2. (既存のファイルシステムが時間を開けるのに対して)ディスクへのflushは積極的にスケジューリングされ、IO操作が不要になったときにはキャンセルすることもできる。
  3. オブジェクトのディスクへの配置、block allocation, index collectionには、B-treeが使われている。

終わりに

以上、"Ceph: A Scalable, High-Performance Distributed File System"の内容でした。
今回の記事のように、このブログではプログラムを作る時の参考になることを書き続けるつもりです。
もし興味があれば、twitterやブログのフォローしていただけると嬉しいです。