出典について
この記事はInfluxData BlogのPaul Dix氏によるInfluxDB 1.0 GA Released: A Retrospective and What’s Next(2016/9/8)を翻訳したものです。
本日、オープンソースの時系列データベース InfluxDBと、高可用構成と高スループットを実現するためのクラスタリングのスケールアウトをサポートした商用版であるInfluxEnterpriseの1.0版のリリースをご案内します。本日は、我々の会社の歴史上最も重要な日となりました。このリリースまでには約3年もの年月がかかり、これを機にプロジェクトの歴史を振り返り、ユーザーの皆さんに1.x系のリリースでどのような互換性を持たせるのかお知らせし、InfluxDBの次の展開についてお話ししようと思います。
本日リリースをお伝えしておりますが、InfluxDBは世界中で10000社にご利用いただいております。InfluxDBは様々なものの監視に利用されており、ネットワーク基盤、セキュリティー、コンテナ基盤、太陽電池パネル、農業、科学実験、ユーザー分析、BI(Buisiness Intelligence)、家庭内の自動化、そして、その他にも数えきれない程の利用例があります。時系列データを管理するためにInfluxDBがどのように利用されているかを詳しく知りたい方は、現在では100以上の会社がリスト化されたお客様の声のページをご覧ください。あなたはどのようご利用されているでしょうか？
なぜ時系列データベースか？
2013年の9月にTodd PersonとJohn Shahidと私はErrplane社に勤めており、リアルタイム計測・監視を行うSaaSアプリケーションに従事していました。Toddと私は2012年に会社を立ち上げ、Y Combinatorの2013年 冬期バッチの助けをえたにも関わらず、思い通りにはいきませんでした。すぐに立ちゆかなくならないようにいくらかの資金を獲得していましたが、実際の顧客をうまく獲得できませんでした。
2013年の8月はほとんどすべきことに取り組んでおり、一方で9月の終わりにベルリンで開かれるMonitoramaでデビューしようと考えていました。これはモニタリングに関する会議で、新しいモニタリング製品に興味のある聴衆をみつけるにはよいのではないかと考えました。私はここで新しい製品ではなく、長い間放っておいたアイデア、つまりオープンソースの時系列データベースに見込みあることに気が付きました。
このアイデアの大元となる部分はErrplane社の前に遡ります。2011年、Johnと私はFinTechのスタートアップで出会い、そこでは数万もの金融商品をリアルタイムで追跡することを計画していました。最初はOneTickという商用の時系列データベースを使っていました。しかし、これは数万もの時系列データの動きを追跡するようには作られていなかったため、代替となるものを探し始めました。
オープンソースの世界でOpenTSDB、Graphite、RRDを見つけましたが、それ以外の選択肢はあまりありませんでした。これらのプロジェクト全てにおいて、私のユースケースではうまくいかない制約がありました。特殊な要望の1つとしては、不規則な時系列データを保存できて欲しい、というものがありました。つまり、マーケットにおける取引のような特殊なイベントで生成されるデータです。そこで我々は「時系列データベース」をScalaで書かれたウェブサービスとして開発し始めました。Cassandra上で動き、Redisをリアルタイムのインデックス生成に使うものでした。
もう少し後で、2012年にErrplaneで最初のAPIを開発した時も、同じ技術を利用していました。同じ問題を2度にわたり、全く違ったユースケースに対して解決しました。どちらのときも相当量のバックエンドのコードを時系列が「とにかく動く」ように書きました。
これは既存の技術で時系列データを扱うにはどれほど大変か、を学ぶ成長期の経験となりました。2012年にToddと私がY Combinatorに応募したときには、Errplane社がうまくいかなかった場合の第2のアイデアとして「オープンソースの時系列データベース」を用意しました。
2013年9月のMonitoramaに戻ると、大きな組織のDevOpsエンジニアと一緒に、他のモニタリングとサーバー分析の会社の人々と話をしました。私は時系列データの保存、クエリー発行がスケールしない問題の解決方法をみな探しているという話を、何度も何度も耳にしました。みんな同じ車輪の再発明をしていました。
これでオープンソースの時系列データベースのアイデアを形にする確信をえて、InfluxDBがうまれました。すぐに牽引力が生まれこれに完全にフォーカスするようにしました。2014年末にはMayfieldとTrinityから$8.1Mを調達し物事が加速しました。
過去3年間で、時系列データをスケールして保存する方法、時系列の負荷に対する分散システムの構築、維持可能なオープンソースの会社を作り革新を続けること、について多くの困難な課題に学びをえてきました。
我々はTSM Treeと呼ばれる時系列データ用の独自のオープンソースのストレージエンジンを作りました。商用製品としてInfluxEnterpriseと呼ばれる製品を作り、これはInfluxDBに高可用とクラスタリングの機能を追加し、我々がオープンソースのソフトウェアの開発を続けるための生きる道ともなりました。InfluxCloudという形でAWS上のスケーラブルなマネージドInfluxDBクラスターもリリースしました。
昨年は2つのオープンソースのプロジェクトを新しく作りました。時系列データおよびメトリクスを収集するTelegraf、時系列データの処理、監視、アラートをつかさどるKapacitorです。これらのプロジェクトによってInfluxDataは時系列データを扱うためのプラットフォームとして、データの保存とクエリーが発行できる機能というInfluxDBが提供する機能を超えるものとなりました。
最後に、我々は今年の後半に再構成し完全にオープンソース化したChronografを利用しオープンソースの範囲を拡大する予定です。これはダッシュボードではなく、コンテナ、Kubernetes、Docker Swarmをモニタリングするための創造的なユーザーエクスペリアンスを提供する予定です。興味があって早期の機能評価に参加したい場合はご連絡ください。
1.x系のAPI互換および安定性
1.0のリリースでもっとも重要な特徴は、これがAPIとストレージフォーマットの安定化を示すことです。過去3年間我々は積極的に改善を重ね、しばしばその過程でAPIの互換を崩してきました。1.0のリリースと共に、1.x系のリリースで次の事項を守ることを宣言します。
互換のないHTTP APIの変更をしない: HTTP APIに関しては1.0で動作するコマンドは1.x系のリリースでは変更なしに動作します... 1点注意付きで。我々はクエリー言語にキーワードの追加を行う予定です。新しいキーワードは全ての識別子をダブルクォートで、全てのリテラルをシングルクォートで囲んでいればクエリーに影響を与えません。これは一般的にベストプラクティスと考えられていますので、どちらにしろこのルールに沿ったほうが良いでしょう。このガイドラインに沿うユーザーに対しては、クエリー、取込み(ingestion) APIは全ての1.x系のリリースで互換のない変更を行いません。本プロジェクトのGo言語のソースコードはこれに含まれないことにご注意ください。InfluxDB内のGo APIは1.x系の開発過程で変更されるでしょう。ユーザーの方はHTTP API経由でInfluxDBにアクセスするようにしてください。
ストレージエンジンの安定化: TSMストレージエンジンのファイルフォーマットは、現在バージョン1です。1.x系のリリースで新しいバージョンのフォーマットを導入するかもしれませんが、以前のバージョンと共存して動作するようにする予定です。これはユーザーの方々にとっては、1.xのあるバージョンから違うバージョンにアップグレードする際に長時間を要する移行が発生しないであろうことを意味します。
追加の変更: クエリーエンジンは新しいリリースを重ねる過程で追加の変更を行う予定です。新しいクエリ関数と新機能を後方互換を損なうことなく追加します。新しいプロトコルのエンドポイント(バイナリフォーマットなど)、ラインプロトコルのバージョン、クエリーAPIをパフォーマンスおよび機能の向上させるために追加予定です。これらは既存のバージョンと並行して動作するものです。既存のバージョンは1.x系のリリースで完全にサポートされます。
サポートの継続: 1.x系のラインプロトコル、クエリーAPI、TSMストレージフォーマットのバグ修正を継続します。ユーザーがバグを修正するためには最新の1.x.xリリースにアップグレードすることが期待されますが、これらのリリースは1.0のAPIと互換がありかつデータ移行の必要はないでしょう。例えば、あるユーザーが1.1を利用しており、1.2でバグ修正がリリースされた場合、1.2にアップグレードするとよいでしょう。1.3がリリースされるまでは、1.2.xにパッチ修正が入ります。将来の1.x系のリリースは以前の1.xリリースの当座の代替となりますので、ユーザーが全てのバグ修正を適用するためには最新の1.x系にアップグレードする必要があります。
今後の展開
来るべき1.x系のリリースで多くの改善を実施予定で、この内のいくつかに既に着手しています。概してオープンソースと商用版の取組が継続します。我々のプロジェクトが改善スピードが速いことで知られるように、このペースを継続する予定です。唯一の違いは、現在はセマンティック バージョニング に沿ってAPIを維持することです。
我々はデータベースの「高カーディナリティー」の制約を解決し、ユーザーがタグ付きの数億シリーズに対するインデックス生成をメモリーを無制限に消費することなく出来るようになるよう取り組んでいます。自動的まるめや低精度データへのクエリー発行を行うためのインテリジェントな命令セット作成に取り組んでおり、これによって短い時間から数ヶ月あるいは数年単位にズームする際の表示を効率よく快適に行えるようになります。
我々はクエリー言語の機能追加もする予定で、複数のメジャメントにわたる計算、異った計算でのシリーズの連結、サブクエリー、ランキングクエリーなどにとりくみます。
InfluxDBのリリースサイクルに関していえば、現在と同じように最善策を実施していくつもりです。発生した重要なバグについては1.0へのパッチがリリースされることを期待して良いでしょう。1.1のリリースは現在から2, 3ヶ月後を目標としています。興味のある方は何が1.1に含まれるか何がクローズされマージされたかの1.1のマイルストーンをウォッチするとよいでしょう。リリースの時期が予測可能であったほうが良いと思いますので、マイルストーンにある全てのオープンな機能はお約束できませんが、何が進行中であるかは感じ取ることができるでしょう。
3年間の後、InfluxDB 1.0は私が今までに最初から最後まで関わった、最大そして最長のプロジェクトとなりました。我々が成しえたことにはこの上なく誇りに思いますし、近い将来の素晴らしい機能や開発を楽しみにしています。時系列分野はエキサイティングで、まだ始まったばかりのように思います!
コントリビューターへの感謝
締めくくりとして我々が1.0にたどり着くにあたって助けてくれた何名かのコミュニティーのメンバーのコントリビューションをご紹介したいと思います。
- John Shahid: Toddと私とともにプロジェクトの初年度に全体の立ち上げを行い、休み無しに働いていただきました。
- Philip O’Toole: 0.9全体の再設計/書き換えを我々とともにおこない、TSMの初期バージョン作成を助けていただきました。
- Paulo Pires: 昨年度、複数のバグ修正と機能追加をしていただきました。
- Kun Oiooj: 0.10および複数の0.9系の修正、そして来るべき1.1の新機能を実装いただきました。
- Adarsha Mvadu: InfluxDBがWindows上で動作させるための多くのバグ修正をしていただきました。
- Jon Seymour: TSMやその他のバグ修正をしていただきました。
多くの感謝すべき方々がおり、どこかでまとめてご紹介しなければなりません。過去3年間でコントリビューターの方が200名を超えました。今までにバグを修正、ドキュメントを更新したり、機能を追加したり、我々がここに至るまでに助けていただいた全ての方に感謝します。
次のステップ
- ダウンロード: TICKスタックの1.0 GAのダウンロードは"downloads"ページにあります。
- クラウド上でのご利用: フルマネージドのクラスター、KapacitorそしてGrafanaの機能をもつInfluxCloudを無料でお試しいただけます。
- サーバー上でのご利用: ご自分のサーバー上でInfluxDBクラスターを動かしてみたいですか？InfluxEnterpriseを14日間無料でお試しいただけます。デプロイ時の直感的なUI、モニタリング、クラスターのリバランス、バックアップ/レストアの管理機能を提供します。
- 使い方を教えてください: 100を超える会社がInfluxDBをどのように活用しているか紹介してくれています。あなたの声を投稿していただければ、お礼として限定版のInfluxDBのパーカーを差し上げます。
