現在の制約と今後の展望
Zebrimは比較的アーリーなステージのスタートアップであり、コアな機能（いわゆるMVP）の開発に注力している段階である。Gavin氏によれば、現時点で利用する際には以下のような制限がある。
- SaaSサービスとしてのみ提供。オンプレミスでの提供は対応していない
- 日本語含むマルチバイト文字への非対応
- テキスト以外のフォーマット（たとえばバイナリログ）へは非対応
シリコンバレーのスタートアップが早期のマネタイズとスケーラビリティを重視してSaaSへシフトしていることは、全般的な傾向であり、Zebriumもその例に漏れない。SaaSで実現可能なものをオンプレ化することは、技術的には可能なことであり、Zebriumとしても「オンプレミスにビジネス機会があれば検討する」(Gavin氏)というスタンスである。
オンプレミス環境が好まれる理由としては、特に公共や金融における個人情報含むクリティカルなデータを第三者へ提供することの法的制約などが第一に考えられる。しかし、システム解析に必要となるログに記録されるのは純粋にアプリケーションやミドルウェアの動作や状態を記録するものがほとんどであり、業務データを含んでいる可能性は低いだろう（注4）。
Zebriumは現在でもマルチテナントに対応しているため、利用しているユーザのデータが他ユーザに見られることはないよう制御されている。それでも不安な場合は、専用のVPCに環境を構築するオプションを用意している。いずれの場合でも、保存されるユーザデータと通信に対する暗号化は施される。
マルチバイト文字に関しても同様で、Zebriumが日本進出を企図する際には対応が望まれる機能であるが、現時点での同社内での優先度は高くない。もっとも、日本で利用されるミドルウェアやOSが出力するログにおいても、基本的に英語ベースで記述されていることが多く、それほど大きな問題にはならないと思われる（独自に実装されたアプリケーションのログでマルチバイト文字が使われている可能性は否定できないが）。
障害解析で利用されるログの中で、テキスト以外のフォーマットで出力される例としては、JVMのヒープダンプやスレッドダンプ、OSのコアダンプなどがある。こうした非テキストログについて、Zebriumは直接サポートしておらず、何らかの手段でテキストに変換してから読み込むという方針である。一刻を争う障害対応において、非テキストログのフォーマット変換まで行う運用が現実的かどうかは、検討の余地がある。こうしたログについてはベンダやOSSとして解析ツールが用意されていることが多く、それを利用する方がよい可能性もあるが、これはユースケースにも依存するであろう。
Zebriumは、決してそれ自身が障害を一挙に解決する「銀の弾丸」ではない。構造化、異常検知、そしてヒートマップによって、被疑箇所の絞り込みを迅速化してくれることは間違いないが、障害原因の特定には、最終的にエンジニアの知見と判断が必要になる。これは他のAI系のソリューションと同じだ。しかし、これまで多くの運用現場が課題を抱えていた「多種多様な（しかもきれいとは言えない）ログフォーマットの整形」と「複数のログを突き合わせた被疑箇所の絞り込み」という問題に対して、AIによる新たなアプローチで解決を試みている点でユニークなスタートアップである。
現在もベータ版を試すことができるので、興味ある読者はオフィシャルサイトよりアクセスしていただきたい。また、今後日本展開を企図する際にはぜひ注目していただきたいスタートアップの一つである。
注4
最も懸念されるとすれば、データベースへ発行するクエリが記録されているログであろうが、近年、まともなセキュリティ設計がなされていれば、クエリの中に業務データがハードコードされるようなことは、まずないだろう。
