DNS権威サーバの引っ越し手順メモ (BINDドキュメント)

だいぶ昔に同僚にBINDドキュメントを読むのがよいと言われたときに調べたことを社内wikiで発掘した。この手順では、NSレコードセットに新旧の権威サーバが含まれた中間状態を作ることになっていて、丁寧。実際は、JPRSのガイド に沿っていればだいたいうまくイメージ。

Q: How to change the nameservers for a zone?

A: Step 1: Ensure all nameservers, new and old, are serving the same zone content.

Step 2: Work out the maximum TTL of the NS RRset in the parent and child zones. This is the time it will take caches to be clear of a particular version of the NS RRset. If you are just removing nameservers you can skip to Step 6.

Step 3: Add new nameservers to the NS RRset for the zone and wait until all the servers for the zone are answering with this new NS RRset.

Step 4: Inform the parent zone of the new NS RRset then wait for all the parent servers to be answering with the new NS RRset.

Step 5: Wait for cache to be clear of the old NS RRset. See Step 2 for how long. If you are just adding nameservers you are done.

Step 6: Remove any old nameservers from the zones NS RRset and wait for all the servers for the zone to be serving the new NS RRset.

Step 7: Inform the parent zone of the new NS RRset then wait for all the parent servers to be answering with the new NS RRset.

Step 8: Wait for cache to be clear of the old NS RRset. See Step 2 for how long.

Step 9: Turn off the old nameservers or remove the zone entry from the configuration of the old nameservers.

Step 10: Increment the serial number and wait for the change to be visible in all nameservers for the zone. This ensures that zone transfers are still working after the old servers are decommissioned.

Note: the above procedure is designed to be transparent to dns clients. Decommissioning the old servers too early will result in some clients not being able to look up answers in the zone.

Note: while it is possible to run the addition and removal stages together it is not recommended.

http://www.opensource.apple.com/source/bind9/bind9-31/bind9/FAQ?txt

  • ステップ1: 新旧の権威サーバのゾーン内容が全て一致しているかチェックせよ。
  • ステップ2: 親と子の権威サーバのゾーンにあるNSレコードセットのうち、最大TTLをもつものを調べよ。それがNSレコードセットのキャッシュが切れるまでの時間である。
  • ステップ3: 対象ゾーンのNSレコードセットに新しい権威サーバを追加せよ。対象ゾーンの全ての権威サーバが新しいNSレコードセット付きで応答するのを待て。
  • ステップ4: 新しいNSレコードセットの親ゾーンを報告せよ。それから全ての親の(権威?)サーバが新しいNSレコードセット付きで応答するのを待て。
  • ステップ5: 古いNSレコードセットのキャッシュが切れるのを待て。待ち時間はステップ2をみよ。
  • ステップ6: NSレコードセットから古い権威サーバを削除せよ。それから対象ゾーンの全ての権威サーバが新しいNSレコードを応答するのを待て。
  • ステップ7: 新しいNSレコードセットの親ゾーンを報告せよ。それから全ての親の権威サーバが新しいNSレコードセット付きで応答するのを待て。
  • ステップ8: 古いNSレコードセットキャッシュが切れるのを待て。待ち時間はステップ2をみよ。
  • ステップ9: 古い権威サーバを止めて、古い権威サーバの設定からレコードエントリを全て削除せよ。
  • ステップ10: シリアル番号をインクリメントして、全ての権威サーバでその変更が見えるようになるのを待て。古い権威サーバが退役した後に、ゾーン転送がまだ動いているかどうかを確認している。

tcpdumpでMySQLサーバに流れてくるクエリをみる

社内のMySQLマスターのtcpdumpの様子。マスタ切り替えした後に切り替え先でクエリが流れているかをみる。単に3306ポートのパケットを流すだけでもよいが、接続確立に失敗しているがパケットは流れてくるという状況もあるので、SQL文が流れているかまでみるのがよい。

tcpdump -tttt -l -i eth0 -A -n -s 0 dst port 3306 | grep -iE "select|update|delete|insert"
  • -tttt は人間に読みやすい形式のタイムスタンプを付与する
  • -l は line buffered。パケット数の大きい環境で負荷を軽くする
  • -Aアスキー表示
  • -nIPアドレスの逆引きをしない。DNSゾルバに負荷をかけないため
  • -s 0 は出力をtruncateせずに全部だす
  • -iはネットワークインタフェースを指定。複数のインタフェースがついていることもあるので、ip aで確認しておこう
  • dst port 3306 宛先ポート番号が3306

tcpdumpのオプション、わかりきっているようで、そういえば line bufferedしてなかったとか、tの数何個だっけとかちょっとした気付きがある。

論文 TKDE'17, Time Series Management Systems: A Survey

Cyber Physical Systems*1の文脈における時系列データベース(TSDB)のサーベイ論文。論文中では、TSDBをTime Series Management System(TSMS)と表現されている。 Stream Processing*2とApproximate Query Processing(AQP) *3 TKDEは、SIGMODやVLDBといったトップのデータベース系国際会議と並ぶような位置づけのジャーナルらしい。 論文 BTW'17, Survey and Comparison of Open Source Time Series Databases - ゆううきメモ と比べると、読んでみて相当高品質という印象。 ただし、InfluxDBやPrometheusなど、アカデミアにでていないインダストリアルなTSDBはサーベイ対象ではない。

  • [1]: Jensen, Søren Kejser, et al. "Time Series Management Systems: A Survey." IEEE Transactions on Knowledge and Data Engineering, vol.29, no.11, 2017, pp. 2581-2600.

論文のPDFファイルを [1710.01077] Time Series Management Systems: A Survey からダウンロードできる。

先行研究との差分はなにか

おそらく明記されていないが、現存するTSMSのオーバビューだけでなく、次世代のTSMSの洞察をあたえることがこのサーベイで目指すこととされている。

サーベイ手法の要点はなにか

  • Google ScholarでTSMSのオーバビューを把握し、関連するカンファレンスや用語、関連リサーチャーを発見する。論文の参考文献、引用文献、全ての会議とジャーナル(SIGMOD、IEEE Big Data、PVLDBなど)、著者の論文(DBLPとGoogle Scholar、プロフィールページの組み合わせ)をデータスースとした。
  • 次の13の基準でTSMSを比較している。
    • Architecture, Year, Purpose, Motivatinal Use Case, Distributed, Maturity, Scale Shown, Processing Engine, API, Approximation, Stream Processing, Storage Engine, Storage Layout
  • TSMSを次の3つのカテゴリに分類している。
    • internal data stores、external data stores(GorillaやBTrDB、Druidなど)、RDBMS extention
  • 各TSMSについて、性能、デプロイメント、機能などについて定性的にまとめている。

議論はあるか

  • 分散TSMSは既存の外部DBMSを用いて開発されている一方で、内部データストアをもつTSMSは主に非分散システム。内部データストアTSMSは主に組み込みデバイス用かPoCであり、既存の外部DBMSをもつTSMSはビジネスクリティカルなところで使われる。
  • ドメインエキスパートがユーザ定義のメソッドやモデルを使って拡張できるインタフェースをもつものは一般的でない。
  • TSMSはリアルタイム更新、ユーザ定義関数によるストリームプロセッシング、historical dataとincoming dataの両方に対するクエリ実行を提供すべきである。

興味深い関連論文はなにか

多すぎるので割愛。TSDBに特化した部分であるpre-aggregation、approximate queryの各アーキテクチャの詳細や、AQPやNoSQLの比較などデータベース一般の観点で読みたいものがいろいろでてきた。

*1:IoTに近い用語

*2:ここでは、書き込み時の丸め処理、サンプリングなどを指す

*3:AQPは、サンプリングなどのテクニックで現実的なクエリ実行時間に落とし込む技術の総称という理解

論文 BTW'17, Survey and Comparison of Open Source Time Series Databases

  • [1]: B. Mitschang et al. 2017. Survey and Comparison of Open Source Time Series Databases. In BTW. slide

どんなものか

  • 全てのオープンソース時系列データベース(以下TSDB)の完全なリストと、人気のあるTSDBの機能リストを作成することが目的。
  • 機械的に検索した83個のTSDBのうち12個の主要なTSDBを比較する。

先行研究との差分はなにか

  • 先行研究では、機能比較よりは性能比較にフォーカスしている。
  • 先行研究では、すべてのユースケースを満たせない単一のデータベースはないということが示されている。
  • この研究では、上記のgapを埋める。*1

手法の要点はなにか

TSDBを以下の6つの基準グループ(合計27個の基準)で比較している。*2

  • 1: Distribution/Clusterability
    • 高可用性、スケーラビリティ、ロードバランシング機能で比較
  • 2: Functions
    • INS, UPD, READ, SCAN, AVG, SUM, CNT, DEL, MAX, and MIN の各functionで比較
  • 3: Tags, Continuous Calculation, Long-term Storage, and Matrix Time Series
  • 4: Granularity
    • データ粒度*3、ダウンサンプリング*4、最小粒度
  • 5: Interfaces and Extensibility
  • 6: Support and License

さらに、TSDBを4つのグループに分類している。

  • Group 1: TSDBs with a Requirement on other DBMS
  • Group 2: TSDBs with no Requirement on any DBMS
  • Group 3: RDBMS
  • Group 4: Proprietary

有効性をどのように示しているか

  • 12個のTSDBの選定基準は、Googleの検索ヒット数順。
    • https://www.google.com/webhp?gws_rd=cr,ssl&pws=0&hl=en&gl=us&filter=0&complete=0
  • 27個の基準を定性的に満たしているかいないかを表で示されている。

([1]のTab. 3: Comparison of Criteria Group 1: Distribution/Clusterability.より引用)

議論はあるか

  • Druidが多くの基準を満たすベストな選択肢。他のTSDBと比較して、5つのnode typeをもち、JavaScriptでself-writtenなaggregated functionをサポートする。次点で、InfuxDB, MonetDB, もしくは2つのRDBMS(MySQL, Postgres)。
  • 機能でTSDBを差別化できないが、性能で差別化できるかもしれない。
  • 次のステップは、repeatableでextensibleで任意のTSDB向けOSSベンチマーキングフレームワーク

興味深い関連論文はなにか

references.

  • [Ba16] Bader, A.: Comparison of Time Series Databases, Diploma Thesis, Institute of Parallel and Distributed Systems, University of Stuttgart, 2016. *5
  • [Wl12] Wlodarczyk, T.: Overview of Time Series Storage and Processing in a Cloud Environment. In: CloudCom. 2012.
  • [DMF12] Deri, L.; Mainardi, S.; Fusco, F.: tsdb: A Compressed Database for Time Series. In: Trafic Monitoring and Analysis. Springer, 2012.
  • [PFA09] Pungilă, C.; Fortiş, T.-F.; Aritoni, O.: Benchmarking Database Systems for the Requirements of Sensor Readings. IETE Technical Review 26/5, pp. 342Ű349, 2009.
  • [Th15] Thomsen, J. et al.: Darstellung des Konzeptes Ű DMA Decentralised Market Agent Ű zur Bewältigung zukünftiger Herausforderungen in Verteilnetzen. In: INFORMATIK 2015. Vol. P-246. LNI, 2015.

citations.

  • Jensen, Søren Kejser, et al. “Time Series Management Systems: A Survey.” IEEE Transactions on Knowledge and Data Engineering, vol. 29, no. 11, 2017, pp. 2581–2600.

see also

*1:gapが何を指しているかわかりづらかった。

*2:この基準は、NEMAR プロジェクトのコンテクストからきているとのこと [Th15]

*3:粒度は解像度とも呼ばれる

*4:rollup aggregationと呼ぶこともある。

*5:学位論文のようなので、質の程度は不明

論文 Middleware'17, Data-Driven Serverless Functions for Object Storage

  • [1]: Josep Sampé, Marc Sánchez-Artigas, Pedro García-López, Gerard París. 2017. Data-Driven Serverless Functions for Object Storage. In Middleware.
  • [2]: Josep Sampé. zion. https://github.com/JosepSampe/zion

論文のPDFは http://2017.middleware-conference.org/overview.html から手に入る。

どんなものか

  • オブジェクトストレージ向けのデータドリブンなサーバレスコンピューティングミドルウェアが提案されている。
  • データパイプライン上に、処理(computations)を注入することで、同期的なインタラクションを要求するユースケースに適している。例えば、動的コンテンツ生成やインタラクティブなクエリ、personalization、コンテンツの検証、アクセス制御など。

先行研究との差分はなにか

  • 従来のactive storage *1はデータ局所性を得るために、計算タスクをストレージノードに寄せている。そのため、ストレージノード数の分しかスケールアウトしない、計算リソースを共有するためリソース競合があるという課題がある。
  • 従来の非同期なイベントドリブンなサーバレスモデル*2とは異なり、オブジェクトストアに対するデータの読み書きを同期的にインターセプトできる。これをデータドリブンと呼んでいる。
    • AWS API Gatewayは余分なオーバヘッドともうひとつのAPIが増える
    • Amazon Lambda@EdgeはCloudFrontに対するリクエスト/レスポンスをインターセプトできるが、コンピューティングの制約が厳しい。ヘッダやメタデータの改ざん用にデザインされている。

手法の要点はなにか

[1]Figure 1より引用

  • Figure 1のようにstorage nodeとgateway nodeの間にcomputing nodeを配置し、レイテンシを削減する

有効性をどのように示しているか

実装

[1] Figure 2より引用

  • OpenStack Swift上にserverless frameworkのプロトタイプが実装されている。プロキシ側でリクエストをインターセプトするSwift Middlewareが唯一の変更点。[2]がおそらく公開されている実装。
  • computationレイヤは、Figure 2のように、Dockerコンテナで実装されている。

評価

  • 理想的な条件で、Swiftがstorage nodeでリソース競合することを確認
  • DockerとJavaのランタイムの起動時間が、0.85sec - 0.95secでAWS Lambdaの5倍速いことを確認
  • 10kBのオブジェクトに対して5,000 GETリクエストしたとき、Zion(提案手法)のオーバヘッドは9ms。ただし、Swiftへの内部ホップが5msなので実質+4ms。
  • アクセス制御、イメージリサイズ、署名検証、圧縮のそれぞれのfunctionについて、レスポンスタイムとスケーラビリティを評価し、レスポンスタイムについてはTPSを上げつづけてCPU 100%になるとレスポンスタイムが悪化することを確認し、スケーラビリティについてはstorage nodeを増やしてもTPSが向上せず、computingレイヤのワーカーを増やすとTPSがおおざっぱには線形増加することが示されている

議論はあるか

  • Amazon Athena、Redshift Spectrum、Facebook Prestoとの関連があり、Prestoのパイプライン実行により不必要なI/Oとレイテンシオーバヘッドを避けるところは、提案手法のモデルに似ているが、これらのシステムは汎用のfunctionを提供するわけではなく、インタラクティブなクエリ実行にフォーカスしている点が異なる。

興味深い関連論文はなにか

  • Scott Hendrickson, Stephen Sturdevant, Tyler Harter, Venkateshwaran Venkataramani, Andrea C Arpaci-Dusseau, and Remzi H Arpaci-Dusseau. 2016. Serverless computation with OpenLambda. In HotCloud.
  • Krste Asanovic and D Patterson. 2014. Firebox: A hardware building block or 2020 warehouse-scale computers. In FAST.
  • Peter X Gao, Akshay Narayan, Sagar Karandikar, Joao Carreira, Sangjin Han, Rachit Agarwal, Sylvia Ratnasamy, and Scott Shenker. 2016. Network requirements or resource disaggregation. In OSDI. 249-264.

*1:OpenStack Swiftなど

*2:AWS Lambdaなど